Internet Engineering Task Force (IETF) K. Chittimaneni
Request for Comments: 7381 Dropbox, Inc.
Category: Informational T. Chown
ISSN: 2070-1721 University of Southampton
L. Howard
Time Warner Cable
V. Kuarsingh
Dyn, Inc.
Y. Pouffary
Hewlett Packard
E. Vyncke
Cisco Systems
October 2014
Internet Engineering Task Force (IETF) K. Chittimaneni
Request for Comments: 7381 Dropbox, Inc.
Category: Informational T. Chown
ISSN: 2070-1721 University of Southampton
L. Howard
Time Warner Cable
V. Kuarsingh
Dyn, Inc.
Y. Pouffary
Hewlett Packard
E. Vyncke
Cisco Systems
October 2014
Enterprise IPv6 Deployment Guidelines
企业IPv6部署指南
Abstract
摘要
Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers and have reasons for different priorities. The overall problem for many administrators will be to offer Internet-facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.
全世界的企业网络管理员正处于准备或将IPv6部署到其网络的不同阶段。与互联网接入提供商的运营商相比，管理员面临着不同的挑战，他们有不同优先级的理由。许多管理员面临的总体问题是，在继续支持IPv4的同时，通过IPv6提供面向Internet的服务，同时在企业IT网络中引入IPv6访问。总体过渡将使大多数网络从只使用IPv4的环境过渡到双栈网络环境，最终过渡到只使用IPv6的操作模式。该文档有助于为企业网络架构师或管理员提供一个框架，当他们考虑IPv6支持策略时，可能会面临许多这些挑战。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7381.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7381.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 5
1.2. IPv4-Only Considerations . . . . . . . . . . . . . . . . 5
1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 6
2. Preparation and Assessment Phase . . . . . . . . . . . . . . 7
2.1. Program Planning . . . . . . . . . . . . . . . . . . . . 7
2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Network Infrastructure Readiness Assessment . . . . . 8
2.2.2. Application Readiness Assessment . . . . . . . . . . 9
2.2.3. Importance of Readiness Validation and Testing . . . 9
2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. IPv6 Is No More Secure Than IPv4 . . . . . . . . . . 10
2.4.2. Similarities between IPv6 and IPv4 Security . . . . . 11
2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 11
2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 14
2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 16
3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 20
3.4. Servers and Applications . . . . . . . . . . . . . . . . 20
3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 21
4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 22
4.3. End-User Devices . . . . . . . . . . . . . . . . . . . . 23
4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 24
5. IPv6 Only . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Considerations for Specific Enterprises . . . . . . . . . . . 26
6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 26
6.2. Data Center Virtualization . . . . . . . . . . . . . . . 26
6.3. University Campus Networks . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Informative References . . . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 5
1.2. IPv4-Only Considerations . . . . . . . . . . . . . . . . 5
1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 6
2. Preparation and Assessment Phase . . . . . . . . . . . . . . 7
2.1. Program Planning . . . . . . . . . . . . . . . . . . . . 7
2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Network Infrastructure Readiness Assessment . . . . . 8
2.2.2. Application Readiness Assessment . . . . . . . . . . 9
2.2.3. Importance of Readiness Validation and Testing . . . 9
2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. IPv6 Is No More Secure Than IPv4 . . . . . . . . . . 10
2.4.2. Similarities between IPv6 and IPv4 Security . . . . . 11
2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 11
2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 14
2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 16
3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 20
3.4. Servers and Applications . . . . . . . . . . . . . . . . 20
3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 21
4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 22
4.3. End-User Devices . . . . . . . . . . . . . . . . . . . . 23
4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 24
5. IPv6 Only . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Considerations for Specific Enterprises . . . . . . . . . . . 26
6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 26
6.2. Data Center Virtualization . . . . . . . . . . . . . . . 26
6.3. University Campus Networks . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Informative References . . . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
An enterprise network is defined in [RFC4057] as a network that has multiple internal links, one or more router connections to one or more providers, and is actively managed by a network operations entity (the "administrator", whether a single person or a department of administrators). Administrators generally support an internal network, consisting of users' workstations; personal computers; mobile devices; other computing devices and related peripherals; a server network, consisting of accounting and business application servers; and an external network, consisting of Internet-accessible services such as web servers, email servers, VPN systems, and customer applications. This document is intended as guidance for enterprise network architects and administrators in planning their IPv6 deployments.
[RFC4057]将企业网络定义为具有多个内部链路、一个或多个路由器连接到一个或多个提供商的网络，并由网络运营实体（“管理员”，无论是个人还是管理员部门）主动管理。管理员通常支持由用户工作站组成的内部网络；个人电脑；移动设备；其他计算设备和相关外围设备；服务器网络，由会计和业务应用服务器组成；以及外部网络，由互联网可访问的服务组成，如web服务器、电子邮件服务器、VPN系统和客户应用程序。本文档旨在为企业网络架构师和管理员规划其IPv6部署提供指导。
The business reasons for spending time, effort, and money on IPv6 will be unique to each enterprise. The most common drivers are due to the fact that when Internet service providers, including mobile wireless carriers, run out of IPv4 addresses, they will provide native IPv6 and non-native IPv4. The non-native IPv4 service may be NAT64, NAT444, Dual-Stack Lite (DS-Lite), Mapping of Address and Port using Translation (MAP-T), Mapping of Address and Port using Encapsulation (MAP-E), or other transition technologies. Compared to tunneled or translated service, native traffic typically performs better and more reliably than non-native. For example, for client networks trying to reach enterprise networks, the IPv6 experience will be better than the transitional IPv4 if the enterprise deploys IPv6 in its public-facing services. The native IPv6 network path should also be simpler to manage and, if necessary, troubleshoot. Further, enterprises doing business in growing parts of the world may find IPv6 growing faster there, where again potential new customers, employees, and partners are using IPv6. It is thus in the enterprise's interest to deploy native IPv6 at the very least in its public-facing services but ultimately across the majority or all of its scope.
在IPv6上花费时间、精力和金钱的业务原因对于每个企业来说都是独一无二的。最常见的驱动因素是，当互联网服务提供商（包括移动无线运营商）用完IPv4地址时，他们将提供本机IPv6和非本机IPv4。非本机IPv4服务可以是NAT64、NAT444、双栈Lite（DS Lite）、使用转换的地址和端口映射（MAP-T）、使用封装的地址和端口映射（MAP-E）或其他转换技术。与隧道或转换服务相比，本机流量通常比非本机流量执行得更好、更可靠。例如，对于试图到达企业网络的客户端网络，如果企业在其面向公众的服务中部署IPv6，IPv6体验将优于过渡IPv4。本机IPv6网络路径也应更易于管理，如有必要，还应进行故障排除。此外，在世界上不断增长的地区开展业务的企业可能会发现IPv6在那里增长更快，而潜在的新客户、员工和合作伙伴也在使用IPv6。因此，至少在面向公众的服务中部署本机IPv6符合企业的利益，但最终要在其大部分或全部范围内部署本机IPv6。
The text in this document provides specific guidance for enterprise networks and complements other related work in the IETF, including [IPv6-DESIGN] and [RFC5375].
本文件中的文本为企业网络提供了具体指导，并补充了IETF中的其他相关工作，包括[IPv6设计]和[RFC5375]。
For the purpose of this document, we assume the following:
就本文件而言，我们假设：
o The administrator is considering deploying IPv6 (but see Section 1.2 below).
o 管理员正在考虑部署IPv6（但请参见下文第1.2节）。
o The administrator has existing IPv4 networks and devices that will continue to operate and be supported.
o 管理员拥有将继续运行并受支持的现有IPv4网络和设备。
o The administrator will want to minimize the level of disruption to the users and services by minimizing the number of technologies and functions that are needed to mediate any given application. In other words, provide native IP wherever possible.
o 管理员希望通过最小化调解任何给定应用程序所需的技术和功能的数量，将对用户和服务的中断程度降至最低。换句话说，尽可能提供本机IP。
Based on these assumptions, an administrator will want to use technologies that minimize the number of flows being tunneled, translated, or intercepted at any given time. The administrator will choose transition technologies or strategies that both allow most traffic to be native and manage non-native traffic. This will allow the administrator to minimize the cost of IPv6 transition technologies by containing the number and scale of transition systems.
基于这些假设，管理员将希望使用能够最大限度地减少在任何给定时间被隧道、转换或拦截的流数量的技术。管理员将选择过渡技术或策略，既允许大多数流量为本机流量，又管理非本机流量。这将允许管理员通过控制过渡系统的数量和规模，将IPv6过渡技术的成本降至最低。
Tunnels used for IPv6/IPv4 transition are expected as near-/mid-term mechanisms, while IPv6 tunneling will be used for many long-term operational purposes such as security, routing control, mobility, multihoming, traffic engineering, etc. We refer to the former class of tunnels as "transition tunnels".
用于IPv6/IPv4转换的隧道预计为近期/中期机制，而IPv6隧道将用于许多长期运营目的，如安全性、路由控制、移动性、多宿、流量工程等。我们将前一类隧道称为“转换隧道”。
As described in [RFC6302], administrators should take certain steps even if they are not considering IPv6. Specifically, Internet-facing servers should log the source port number, timestamp (from a reliable source), and the transport protocol. This will allow investigation of malefactors behind address-sharing technologies such as NAT444, MAP, or DS Lite. Such logs should be protected for integrity, safeguarded for privacy, and periodically purged within applicable regulations for log retention.
如[RFC6302]所述，即使管理员没有考虑IPv6，也应该采取某些步骤。具体来说，面向Internet的服务器应该记录源端口号、时间戳（来自可靠的源）和传输协议。这将允许调查NAT444、MAP或DS Lite等地址共享技术背后的恶意因素。应保护此类日志的完整性，保护隐私，并在适用的日志保留法规范围内定期清除。
Other IPv6 considerations may impact ostensibly IPv4-only networks, e.g., [RFC6104] describes the rogue IPv6 Router Advertisement (RA) problem, which may cause problems in IPv4-only networks where IPv6 is enabled in end systems on that network. Further discussion of the security implications of IPv6 in IPv4-only networks can be found in [RFC7123].
其他IPv6注意事项可能会影响表面上仅IPv4的网络，例如，[RFC6104]描述了恶意IPv6路由器广告（RA）问题，这可能会在仅IPv4的网络中导致问题，其中IPv6在该网络上的终端系统中启用。[RFC7123]中进一步讨论了IPv6在仅IPv4网络中的安全影响。
Given the challenges of transitioning user workstations, corporate systems, and Internet-facing servers, a phased approach allows incremental deployment of IPv6, based on the administrator's own determination of priorities. This document outlines suggested phases: a Preparation and Assessment Phase, an Internal Phase, and an External Phase. The Preparation Phase is highly recommended to all administrators, as it will save errors and complexity in later phases. Each administrator must decide whether to begin with an External Phase (enabling IPv6 for Internet-facing systems, as recommended in [RFC5211]) or an Internal Phase (enabling IPv6 for internal interconnections first).
考虑到过渡用户工作站、公司系统和面向Internet的服务器所面临的挑战，分阶段的方法允许根据管理员自己确定的优先级增量部署IPv6。本文件概述了建议的阶段：准备和评估阶段、内部阶段和外部阶段。强烈建议所有管理员使用准备阶段，因为它将在以后的阶段中避免错误和复杂性。每位管理员必须决定是从外部阶段开始（按照[RFC5211]中的建议，为面向Internet的系统启用IPv6）还是从内部阶段开始（首先为内部互连启用IPv6）。
Each scenario is likely to be different to some extent, but we can highlight some considerations:
每个场景可能在某种程度上有所不同，但我们可以强调一些注意事项：
o In many cases, customers outside the network will have IPv6 before the internal enterprise network. For these customers, IPv6 may well perform better, especially for certain applications, than translated or tunneled IPv4, so the administrator may want to prioritize the External Phase such that those customers have the simplest and most robust connectivity to the enterprise, or at least its external-facing elements.
o 在许多情况下，网络之外的客户将在内部企业网络之前拥有IPv6。对于这些客户，IPv6可能比转换或隧道式IPv4性能更好，特别是对于某些应用程序，因此管理员可能希望优先考虑外部阶段，以便这些客户与企业或至少其面向外部的元素具有最简单和最强健的连接。
o Employees who access internal systems by VPN may find that their ISPs provide translated IPv4, which does not support the required VPN protocols. In these cases, the administrator may want to prioritize the External Phase and any other remotely accessible internal systems. It is worth noting that a number of emerging VPN solutions provide dual-stack connectivity; thus, a VPN service may be useful for employees in IPv4-only access networks to access IPv6 resources in the enterprise network (much like many public tunnel broker services, but specifically for the enterprise). Some security considerations are described in [RFC7359].
o 通过VPN访问内部系统的员工可能会发现，他们的ISP提供的是经过翻译的IPv4，不支持所需的VPN协议。在这些情况下，管理员可能希望优先考虑外部阶段和任何其他远程可访问的内部系统。值得注意的是，许多新兴的VPN解决方案提供了双栈连接；因此，VPN服务对于仅IPv4访问网络中的员工访问企业网络中的IPv6资源可能很有用（与许多公共隧道代理服务非常相似，但特别适用于企业）。[RFC7359]中描述了一些安全注意事项。
o Internet-facing servers cannot be managed over IPv6 unless the management systems are IPv6 capable. These might be Network Management Systems (NMS), monitoring systems, or just remote management desktops. Thus, in some cases, the Internet-facing systems are dependent on IPv6-capable internal networks. However, dual-stack Internet-facing systems can still be managed over IPv4.
o 除非管理系统支持IPv6，否则无法通过IPv6管理面向Internet的服务器。这些可能是网络管理系统（NMS）、监控系统，或者只是远程管理桌面。因此，在某些情况下，面向Internet的系统依赖于支持IPv6的内部网络。但是，面向Internet的双栈系统仍然可以通过IPv4进行管理。
o Virtual Machines (VMs) may enable a faster rollout once initial system deployment is complete. Management of VMs over IPv6 is still dependent on the management software supporting IPv6.
o 一旦初始系统部署完成，虚拟机（VM）可以实现更快的部署。通过IPv6管理虚拟机仍然依赖于支持IPv6的管理软件。
o IPv6 is enabled by default on all modern operating systems, so it may be more urgent to manage and have visibility on the internal traffic. It is important to manage IPv6 for security purposes, even in an ostensibly IPv4-only network, as described in [RFC7123].
o 默认情况下，所有现代操作系统都启用了IPv6，因此管理和查看内部流量可能更为迫切。出于安全目的管理IPv6非常重要，即使是在表面上只有IPv4的网络中，如[RFC7123]所述。
o In many cases, the corporate accounting, payroll, human resource, and other internal systems may only need to be reachable from the internal network, so they may be a lower priority. As enterprises require their vendors to support IPv6, more internal applications will support IPv6 by default, and it can be expected that eventually new applications will only support IPv6. The inventory, as described in Section 2.2, will help determine the systems' readiness, as well as the readiness of the supporting network elements and security, which will be a consideration in prioritization of these corporate systems.
o 在许多情况下，企业会计、工资、人力资源和其他内部系统可能只需要从内部网络访问，因此它们的优先级可能较低。由于企业要求其供应商支持IPv6，默认情况下，更多的内部应用程序将支持IPv6，可以预期，最终新的应用程序将只支持IPv6。如第2.2节所述，清单将有助于确定系统的准备情况，以及支持网络元件和安全的准备情况，这将是这些公司系统优先顺序的一个考虑因素。
o Some large organizations (even when using private IPv4 addresses [RFC1918]) are facing IPv4 address exhaustion because of the internal network growth (for example, the vast number of VMs) or because of the acquisition of other companies that often raise private IPv4 address overlapping issues.
o 一些大型组织（即使在使用专用IPv4地址[RFC1918]时）也面临IPv4地址耗尽的问题，原因是内部网络增长（例如，大量虚拟机）或收购其他公司，这些公司通常会提出专用IPv4地址重叠问题。
o IPv6 restores end-to-end transparency even for internal applications (of course security policies must still be enforced). When two organizations or networks merge [RFC6879], the unique addressing of IPv6 can make the merger much easier and faster. A merger may, therefore, prioritize IPv6 for the affected systems.
o IPv6恢复了端到端的透明性，即使对于内部应用程序也是如此（当然，仍然必须强制执行安全策略）。当两个组织或网络合并[RFC6879]时，IPv6的独特寻址可以使合并更容易、更快。因此，合并可能会优先考虑受影响系统的IPv6。
These considerations are in conflict; each administrator must prioritize according to their company's conditions. It is worth noting that the reasons given in "A Large Corporate User's View of IPng", described in [RFC1687], for reluctance to deploy have largely been satisfied or overcome in the intervening years.
这些考虑相互冲突；每位管理员必须根据其公司的情况确定优先级。值得注意的是，[RFC1687]中描述的“大型企业用户对IPng的看法”中给出的不愿部署的原因在这几年中基本上得到了满足或克服。
Since enabling IPv6 is a change to the most fundamental Internet Protocol, and since there are so many interdependencies, having a professional project manager organize the work is highly recommended. In addition, an executive sponsor should be involved in determining the goals of enabling IPv6 (which will establish the order of the phases) and should receive regular updates.
由于启用IPv6是对最基本的Internet协议的更改，并且存在如此多的相互依赖性，因此强烈建议由专业项目经理组织工作。此外，执行发起人应参与确定启用IPv6的目标（这将确定阶段的顺序），并应定期收到更新。
It may be necessary to complete the Preparation Phase before determining whether to prioritize the Internal or External Phase,
在确定内部或外部阶段的优先级之前，可能需要完成准备阶段，
since needs and readiness assessments are part of that phase. For a large enterprise, it may take several iterations to really understand the level of effort required. Depending on the required schedule, it may be useful to roll IPv6 projects into other architectural upgrades -- this can be an excellent way to improve the network and reduce costs. However, by increasing the scope of projects, the schedule is often affected. For instance, a major systems upgrade may take a year to complete, where just patching existing systems may take only a few months.
因为需求和准备情况评估是该阶段的一部分。对于大型企业，可能需要多次迭代才能真正了解所需的工作级别。根据所需的时间表，将IPv6项目推广到其他体系结构升级中可能会很有用——这可能是改进网络和降低成本的一个很好的方法。然而，随着项目范围的扩大，进度往往受到影响。例如，大型系统升级可能需要一年时间才能完成，而仅仅修补现有系统可能只需要几个月。
The deployment of IPv6 will not generally stop all other technology work. Once IPv6 has been identified as an important initiative, all projects, both new and in progress, will need to be reviewed to ensure IPv6 support.
IPv6的部署通常不会停止所有其他技术工作。一旦IPv6被确定为一项重要的计划，所有新的和正在进行的项目都需要进行审查，以确保对IPv6的支持。
It is normal for assessments to continue in some areas while execution of the project begins in other areas. This is fine, as long as recommendations in other parts of this document are considered, especially regarding security (for instance, one should not deploy IPv6 on a system before security has been evaluated).
当项目在其他地区开始执行时，在某些地区继续进行评估是正常的。只要考虑了本文档其他部分中的建议，尤其是关于安全性的建议（例如，在评估安全性之前，不应在系统上部署IPv6），就可以了。
To comprehend the scope of the Inventory Phase, we recommend dividing the problem space in two: network infrastructure readiness and applications readiness.
为了理解清单阶段的范围，我们建议将问题空间分为两部分：网络基础设施就绪和应用程序就绪。
The goal of this assessment is to identify the level of IPv6 readiness of network equipment. This will identify the effort required to move to an infrastructure that supports IPv6 with the same functional service capabilities as the existing IPv4 network. This may also require a feature comparison and gap analysis between IPv4 and IPv6 functionality on the network equipment and software. IPv6 support will require testing; features often work differently in vendors' labs than production networks. Some devices and software will require IPv4 support for IPv6 to work.
此评估的目标是确定网络设备的IPv6就绪程度。这将确定迁移到支持IPv6的基础架构所需的工作，该基础架构具有与现有IPv4网络相同的功能服务能力。这可能还需要对网络设备和软件上的IPv4和IPv6功能进行功能比较和差距分析。IPv6支持需要测试；功能在供应商实验室的工作方式通常与生产网络不同。某些设备和软件需要IPv4支持才能使用IPv6。
The inventory will show which network devices are already capable, which devices can be made IPv6 ready with a code/firmware upgrade, and which devices will need to be replaced. The data collection consists of a network discovery to gain an understanding of the topology and inventory network infrastructure equipment and code versions with information gathered from static files and IP address management, DNS, and DHCP tools.
清单将显示哪些网络设备已经具备能力，哪些设备可以通过代码/固件升级为IPv6就绪，以及哪些设备需要更换。数据收集包括网络发现，以通过从静态文件和IP地址管理、DNS和DHCP工具收集的信息，了解拓扑和资源清册网络基础设施设备和代码版本。
Since IPv6 might already be present in the environment, through default configurations or VPNs, an infrastructure assessment (at minimum) is essential to evaluate potential security risks.
由于IPv6可能已经通过默认配置或VPN出现在环境中，因此基础设施评估（至少）对于评估潜在的安全风险至关重要。
Just like network equipment, application software needs to support IPv6. This includes OS, firmware, middleware, and applications (including internally developed applications). Vendors will typically handle IPv6 enablement of off-the-shelf products, but often enterprises need to request this support from vendors. For internally developed applications, it is the responsibility of the enterprise to enable them for IPv6. Analyzing how a given application communicates over the network will dictate the steps required to support IPv6. Applications should avoid instructions specific to a given IP address family. Any applications that use APIs, such as the C language, that expose the IP version specifically, need to be modified to also work with IPv6.
与网络设备一样，应用软件也需要支持IPv6。这包括操作系统、固件、中间件和应用程序（包括内部开发的应用程序）。供应商通常会处理现成产品的IPv6支持，但企业通常需要向供应商请求这种支持。对于内部开发的应用程序，企业有责任为其启用IPv6。分析给定的应用程序如何通过网络进行通信将决定支持IPv6所需的步骤。应用程序应避免特定于给定IP地址系列的指令。任何使用API（如C语言）并专门公开IP版本的应用程序都需要修改才能与IPv6一起使用。
There are two ways to IPv6-enable applications. The first approach is to have separate logic for IPv4 and IPv6, thus leaving the IPv4 code path mainly untouched. This approach causes the least disruption to the existing IPv4 logic flow, but introduces more complexity, since the application now has to deal with two logic loops with complex race conditions and error recovery mechanisms between these two logic loops. The second approach is to create a combined IPv4/IPv6 logic, which ensures operation regardless of the IP version used on the network. Knowing whether a given implementation will use IPv4 or IPv6 in a given deployment is a matter of some art; see Source Address Selection [RFC6724] and Happy Eyeballs [RFC6555]. It is generally recommended that the application developer use industry IPv6-porting tools to locate the code that needs to be updated. Some discussion of IPv6 application porting issues can be found in [RFC4038].
有两种方法可以启用IPv6应用程序。第一种方法是为IPv4和IPv6提供单独的逻辑，从而使IPv4代码路径基本保持不变。这种方法对现有IPv4逻辑流造成的中断最少，但会带来更大的复杂性，因为应用程序现在必须处理两个逻辑循环，这两个逻辑循环之间具有复杂的竞争条件和错误恢复机制。第二种方法是创建组合的IPv4/IPv6逻辑，无论网络上使用的IP版本如何，都可以确保操作。知道一个给定的实现在一个给定的部署中是使用IPv4还是IPv6是一件很有技巧的事情；参见源地址选择[RFC6724]和快乐眼球[RFC6555]。通常建议应用程序开发人员使用行业IPv6移植工具来定位需要更新的代码。有关IPv6应用程序移植问题的一些讨论，请参见[RFC4038]。
Lastly, IPv6 introduces a completely new way of addressing endpoints, which can have ramifications at the network layer all the way up to the applications. So to minimize disruption during the transition phase, we recommend complete functionality, scalability, and security testing to understand how IPv6 impacts the services and networking infrastructure.
最后，IPv6引入了一种全新的端点寻址方式，这种方式可以在网络层一直延伸到应用程序。因此，为了尽量减少过渡阶段的中断，我们建议进行完整的功能、可扩展性和安全测试，以了解IPv6对服务和网络基础设施的影响。
Many organizations falter in IPv6 deployment because of a perceived training gap. Training is important for those who work with addresses regularly, as with anyone whose work is changing. Better knowledge of the reasons IPv6 is being deployed will help inform the assessment of who needs training and what training they need.
许多组织在IPv6部署方面步履蹒跚，因为他们认为存在培训缺口。培训对于那些定期与地址打交道的人来说很重要，对于那些工作正在发生变化的人来说也是如此。更好地了解部署IPv6的原因将有助于评估谁需要培训以及他们需要什么培训。
It is obvious that IPv6 networks should be deployed in a secure way. The industry has learned a lot about network security with IPv4, so network operators should leverage this knowledge and expertise when deploying IPv6. IPv6 is not so different than IPv4: it is a connectionless network protocol using the same lower-layer service and delivering the same service to the upper layer. Therefore, the security issues and mitigation techniques are mostly identical with the same exceptions that are described further.
显然，IPv6网络应该以安全的方式部署。业界已经了解了很多关于IPv4网络安全的知识，因此网络运营商在部署IPv6时应该利用这些知识和专业技能。IPv6与IPv4没有太大区别：它是一种无连接的网络协议，使用相同的下层服务，并向上层提供相同的服务。因此，安全问题和缓解技术基本上是相同的，下面将进一步描述相同的例外情况。
Some people believe that IPv6 is inherently more secure than IPv4 because it is new. Nothing can be more wrong. Indeed, being a new protocol means that bugs in the implementations have yet to be discovered and fixed and that few people have the operational security expertise needed to operate securely an IPv6 network. This lack of operational expertise is the biggest threat when deploying IPv6: the importance of training is to be stressed again.
有些人认为IPv6本质上比IPv4更安全，因为它是新的。没有比这更糟糕的了。事实上，作为一种新协议，意味着实现中的漏洞尚未被发现和修复，而且很少有人具备安全操作IPv6网络所需的操作安全专业知识。在部署IPv6时，运营专业知识的缺乏是最大的威胁：培训的重要性需要再次强调。
One security myth is that, thanks to its huge address space, a network cannot be scanned by enumerating all IPv6 addresses in a /64 LAN; hence, a malevolent person cannot find a victim. [RFC5157] describes some alternate techniques to find potential targets on a network, for example, enumerating all DNS names in a zone. Additional advice in this area is also given in [HOST-SCANNING].
一个安全神话是，由于其巨大的地址空间，无法通过枚举a/64 LAN中的所有IPv6地址来扫描网络；因此，恶毒的人找不到受害者。[RFC5157]介绍了在网络上查找潜在目标的一些替代技术，例如，枚举区域中的所有DNS名称。这方面的其他建议也在[主机扫描]中给出。
Another security myth is that IPv6 is more secure because it mandates the use of IPsec everywhere. While the original IPv6 specifications may have implied this, [RFC6434] clearly states that IPsec support is not mandatory. Moreover, if all the intra-enterprise traffic is encrypted, both malefactors and security tools that rely on payload inspection (Intrusion Prevention System (IPS), firewall, Access Control List (ACL), IP Flow Information Export (IPFIX) ([RFC7011] and [RFC7012]), etc.) will be affected. Therefore, IPsec is as useful in IPv6 as in IPv4 (for example, to establish a VPN overlay over a non-trusted network or to reserve for some specific applications).
另一个安全神话是IPv6更安全，因为它要求在任何地方都使用IPsec。虽然最初的IPv6规范可能暗示了这一点，[RFC6434]明确指出IPsec支持不是强制性的。此外，如果对所有企业内部流量进行加密，则依赖有效负载检查的恶意因素和安全工具（入侵防御系统（IPS）、防火墙、访问控制列表（ACL）、IP流信息导出（IPFIX）（[RFC7011]和[RFC7012]）等）都将受到影响。因此，IPsec在IPv6中与在IPv4中一样有用（例如，在不受信任的网络上建立VPN覆盖或为某些特定应用程序保留）。
The last security myth is that amplification attacks (such as [SMURF]) do not exist in IPv6 because there is no more broadcast. Alas, this is not true as ICMP error (in some cases) or information messages can be generated by routers and hosts when forwarding or receiving a multicast message (see Section 2.4 of [RFC4443]). Therefore, the generation and the forwarding rate of ICMPv6 messages must be limited as in IPv4.
最后一个安全神话是，IPv6中不存在放大攻击（如[SMURF]），因为不再有广播。遗憾的是，这不是事实，因为转发或接收多播消息时，路由器和主机可能会生成ICMP错误（在某些情况下）或信息消息（请参阅[RFC4443]第2.4节）。因此，ICMPv6消息的生成和转发速率必须受到IPv4中的限制。
It should be noted that in a dual-stack network, the security implementation for both IPv4 and IPv6 needs to be considered, in addition to security considerations related to the interaction of (and transition between) the two, while they coexist.
应该注意的是，在双栈网络中，除了与IPv4和IPv6共存时的交互（以及两者之间的转换）相关的安全考虑之外，还需要考虑IPv4和IPv6的安全实现。
As mentioned earlier, IPv6 is quite similar to IPv4; therefore, several attacks apply for both protocol families, including:
如前所述，IPv6与IPv4非常相似；因此，两个协议系列都会受到几种攻击，包括：
o Application layer attacks: such as cross-site scripting or SQL injection
o 应用层攻击：如跨站点脚本或SQL注入
o Rogue device: such as a rogue Wi-Fi access point
o 恶意设备：例如恶意Wi-Fi接入点
o Flooding and all traffic-based denial of services (including the use of control plane policing for IPv6 traffic: see [RFC6192])
o 泛洪和所有基于流量的拒绝服务（包括对IPv6流量使用控制平面策略：请参阅[RFC6192]）
A specific case of congruence is IPv6 Unique Local Addresses (ULAs) [RFC4193] and IPv4 private addressing [RFC1918], which do not provide any security by 'magic'. In both cases, the edge router must apply strict filters to block those private addresses from entering and, just as importantly, leaving the network. This filtering can be done by the enterprise or by the ISP, but the cautious administrator will prefer to do it in the enterprise.
一致性的一个具体情况是IPv6唯一本地地址（ULA）[RFC4193]和IPv4专用地址[RFC1918]，它们不通过“魔术”提供任何安全性。在这两种情况下，边缘路由器必须应用严格的过滤器来阻止这些私有地址进入和离开网络，同样重要的是。这种过滤可以由企业或ISP完成，但谨慎的管理员更愿意在企业中完成。
IPv6 addresses can be spoofed as easily as IPv4 addresses, and there are packets with bogon IPv6 addresses (see [CYMRU]). Anti-bogon filtering must be done in the data and routing planes. It can be done by the enterprise or by the ISP, or both, but again the cautious administrator will prefer to do it in the enterprise.
IPv6地址可以像IPv4地址一样容易地被欺骗，并且存在具有bogon IPv6地址的数据包（请参见[CYMRU]）。反bogon过滤必须在数据和路由平面中进行。这可以由企业或ISP来完成，或者两者都可以，但同样谨慎的管理员更愿意在企业中完成。
Even if IPv6 is similar to IPv4, there are some differences that create some IPv6-only vulnerabilities or issues. We give examples of such differences in this section.
即使IPv6与IPv4类似，也存在一些差异，这些差异会造成一些仅限IPv6的漏洞或问题。我们在本节中给出了此类差异的示例。
Privacy extension addresses [RFC4941] are usually used to protect individual privacy by periodically changing the interface identifier
隐私扩展地址[RFC4941]通常用于通过定期更改接口标识符来保护个人隐私
part of the IPv6 address to avoid tracking a host by its otherwise always identical and unique 64-bit Extended Unique Identifier (EUI-64) based on Media Access Control (MAC). While this presents a real advantage on the Internet, moderated by the fact that the prefix part remains the same, it complicates the task of following an audit trail when a security officer or network operator wants to trace back a log entry to a host in their network because when the tracing is done, the searched IPv6 address could have disappeared from the network. Therefore, the use of privacy extension addresses usually requires additional monitoring and logging of the binding of the IPv6 address to a data-link layer address (see also the monitoring section in [IPv6-SECURITY], Section 2.5). Some early enterprise deployments have taken the approach of using tools that harvest IP/MAC address mappings from switch and router devices to provide address accountability; this approach has been shown to work, though it can involve gathering significantly more address data than in equivalent IPv4 networks. An alternative is to try to prevent the use of privacy extension addresses by enforcing the use of DHCPv6, such that hosts only get addresses assigned by a DHCPv6 server. This can be done by configuring routers to set the M bit in RAs, combined with all advertised prefixes being included without the A bit set (to prevent the use of stateless autoconfiguration). Of course, this technique requires that all hosts support stateful DHCPv6. It is important to note that not all operating systems exhibit the same behavior when processing RAs with the M bit set. The varying OS behavior is related to the lack of prescriptive definition around the A, M, and O bits within the Neighbor Discovery Protocol (NDP). [DHCPv6-SLAAC-PROBLEM] provides a much more detailed analysis on the interaction of the M bit and DHCPv6.
IPv6地址的一部分，以避免通过基于媒体访问控制（MAC）的始终相同且唯一的64位扩展唯一标识符（EUI-64）跟踪主机。虽然这在互联网上是一个真正的优势，但由于前缀部分保持不变，当安全官员或网络运营商想要将日志条目追溯到其网络中的主机时，跟踪审计跟踪的任务会变得复杂，因为当跟踪完成时，搜索到的IPv6地址可能已从网络中消失。因此，使用隐私扩展地址通常需要对IPv6地址与数据链路层地址的绑定进行额外的监控和记录（另请参见[IPv6安全]第2.5节中的监控部分）。一些早期的企业部署采用了使用从交换机和路由器设备获取IP/MAC地址映射的工具来提供地址责任的方法；这种方法已经被证明是有效的，尽管它可能需要收集比同等IPv4网络多得多的地址数据。另一种方法是通过强制使用DHCPv6来防止使用隐私扩展地址，这样主机只能获得DHCPv6服务器分配的地址。这可以通过配置路由器在RAs中设置M位来实现，并结合所有未设置A位的播发前缀（以防止使用无状态自动配置）。当然，这种技术要求所有主机都支持有状态DHCPv6。需要注意的是，并非所有操作系统在使用M位集处理RAs时都表现出相同的行为。不同的操作系统行为与邻居发现协议（NDP）中缺乏关于A、M和O位的规定性定义有关。[DHCPv6 SLAAC问题]对M位和DHCPv6的交互作用提供了更详细的分析。
Extension headers complicate the task of stateless packet filters such as ACLs. If ACLs are used to enforce a security policy, then the enterprise must verify whether its ACLs (but also stateful firewalls) are able to process extension headers (this means understand them enough to parse them to find the upper-layer payloads) and to block unwanted extension headers (e.g., to implement [RFC5095]). This topic is discussed further in [RFC7045].
扩展头使无状态数据包筛选器（如ACL）的任务复杂化。如果使用ACL强制执行安全策略，则企业必须验证其ACL（以及有状态防火墙）是否能够处理扩展头（这意味着充分理解它们以解析它们以找到上层有效负载）并阻止不需要的扩展头（例如，实现[RFC5095]）。[RFC7045]中进一步讨论了此主题。
Fragmentation is different in IPv6 because it is done only by the source host and never during a forwarding operation. This means that ICMPv6 packet-too-big messages must be allowed to pass through the network and not be filtered [RFC4890]. Fragments can also be used to evade some security mechanisms such as RA-Guard [RFC6105]. See also [RFC5722] and [RFC7113].
IPv6中的碎片是不同的，因为它仅由源主机完成，而不会在转发操作期间完成。这意味着ICMPv6数据包过大的消息必须允许通过网络，并且不能被过滤[RFC4890]。碎片还可以用来规避一些安全机制，如RA Guard[RFC6105]。另请参见[RFC5722]和[RFC7113]。
One of the biggest differences between IPv4 and IPv6 is the introduction of NDP [RFC4861], which includes a variety of important IPv6 protocol functions, including those provided in IPv4 by the
IPv4和IPv6之间最大的区别之一是引入了NDP[RFC4861]，其中包括各种重要的IPv6协议功能，包括
Address Resolution Protocol (ARP) [RFC0826]. NDP runs over ICMPv6 (which as stated above means that security policies must allow some ICMPv6 messages to pass, as described in RFC 4890), but has the same lack of security as, for example, ARP, in that there is no inherent message authentication. While Secure Neighbor Discovery (SEND) [RFC3971] and Cryptographically Generated Addresses (CGAs) [RFC3972] have been defined, they are not widely implemented). The threat model for RAs within the NDP suite is similar to that of DHCPv4 (and DHCPv6), in that a rogue host could be either a rogue router or a rogue DHCP server. An IPv4 network can be made more secure with the help of DHCPv4 snooping in edge switches, and likewise RA snooping can improve IPv6 network security (in IPv4-only networks as well). Thus, enterprises using such techniques for IPv4 should use the equivalent techniques for IPv6, including RA-Guard [RFC6105] and all work in progress from the Source Address Validation Improvement (SAVI) WG, e.g., [RFC6959], which is similar to the protection given by dynamic ARP monitoring in IPv4. Other DoS vulnerabilities are related to NDP cache exhaustion, and mitigation techniques can be found in ([RFC6583]).
地址解析协议（ARP）[RFC0826]。NDP在ICMPv6上运行（如上所述，这意味着安全策略必须允许某些ICMPv6消息通过，如RFC 4890中所述），但与例如ARP一样缺乏安全性，因为没有固有的消息身份验证。虽然已经定义了安全邻居发现（SEND）[RFC3971]和加密生成地址（CGA）[RFC3972]，但它们并未得到广泛实施）。NDP套件中RAs的威胁模型类似于DHCPv4（和DHCPv6），因为恶意主机可以是恶意路由器或恶意DHCP服务器。借助于边缘交换机中的DHCPv4窥探，IPv4网络可以变得更加安全，同样，RA窥探可以提高IPv6网络安全性（在仅IPv4的网络中也是如此）。因此，对IPv4使用此类技术的企业应使用与IPv6相同的技术，包括RA Guard[RFC6105]和源地址验证改进（SAVI）工作组正在进行的所有工作，例如[RFC6959]，这与IPv4中动态ARP监控提供的保护类似。其他DoS漏洞与NDP缓存耗尽有关，可以在（[RFC6583]）中找到缓解技术。
As stated previously, running a dual-stack network doubles the attack exposure as a malevolent person has now two attack vectors: IPv4 and IPv6. This simply means that all routers and hosts operating in a dual-stack environment with both protocol families enabled (even if by default) must have a congruent security policy for both protocol versions. For example, permit TCP ports 80 and 443 to all web servers and deny all other ports to the same servers must be implemented both for IPv4 and IPv6. It is thus important that the tools available to administrators readily support such behavior.
如前所述，运行双栈网络会使攻击暴露加倍，因为恶意用户现在有两种攻击载体：IPv4和IPv6。这仅仅意味着在启用了两个协议系列的双堆栈环境中运行的所有路由器和主机（即使默认情况下）必须为两个协议版本都具有一致的安全策略。例如，对于IPv4和IPv6，必须实现允许TCP端口80和443连接到所有web服务器，并拒绝所有其他端口连接到相同服务器。因此，重要的是，管理员可以使用的工具随时支持这种行为。
An important design choice to be made is what IGP is to use inside the network. A variety of IGPs (IS-IS, OSPFv3, and Routing Information Protocol Next Generation (RIPng)) support IPv6 today, and picking one over the other is a design choice that will be dictated mostly by existing operational policies in an enterprise network. As mentioned earlier, it would be beneficial to maintain operational parity between IPv4 and IPv6; therefore, it might make sense to continue using the same protocol family that is being used for IPv4. For example, in a network using OSPFv2 for IPv4, it might make sense to use OSPFv3 for IPv6. It is important to note that although OSPFv3 is similar to OSPFv2, they are not the same. On the other hand, some organizations may chose to run different routing protocols for different IP versions. For example, one may chose to run OSPFv2 for IPv4 and IS-IS for IPv6. An important design question to consider here is whether to support one IGP or two different IGPs in the longer term. [IPv6-DESIGN] presents advice on the design choices
一个重要的设计选择是在网络内部使用什么IGP。如今，各种IGP（IS-IS、OSPFv3和下一代路由信息协议（RIPng））都支持IPv6，选择其中之一是一种设计选择，主要取决于企业网络中现有的运营策略。如前所述，保持IPv4和IPv6之间的操作奇偶性将是有益的；因此，继续使用与IPv4相同的协议系列可能是有意义的。例如，在将OSPFv2用于IPv4的网络中，将OSPFv3用于IPv6可能是有意义的。值得注意的是，尽管OSPFv3与OSPFv2相似，但它们并不相同。另一方面，一些组织可能会选择为不同的IP版本运行不同的路由协议。例如，可以选择对IPv4运行OSPFv2，对IPv6运行IS-IS。这里需要考虑的一个重要设计问题是从长远来看是否支持一个IGP或两个不同的IGP。[IPv6设计]就设计选择提供建议
that arise when considering IGPs and discusses the advantages and disadvantages to different approaches in detail.
在考虑IGP时出现的问题，并详细讨论了不同方法的优缺点。
The most common problem encountered in IPv6 networking is in applying the same principles of conservation that are so important in IPv4. IPv6 addresses do not need to be assigned conservatively. In fact, a single, larger allocation is considered more conservative than multiple non-contiguous small blocks because a single block occupies only a single entry in a routing table. The advice in [RFC5375] is still sound and is recommended to the reader. If considering ULAs, give careful thought to how well it is supported, especially in multiple address and multicast scenarios, and assess the strength of the requirement for ULA. [ULA-USAGE] provides much more detailed analysis and recommendations on the usage of ULAs.
IPv6网络中遇到的最常见问题是应用IPv4中非常重要的保护原则。IPv6地址不需要保守地分配。事实上，单个较大的分配被认为比多个不连续的小块更保守，因为单个块只占用路由表中的一个条目。[RFC5375]中的建议仍然有效，建议读者阅读。如果考虑ULA，请仔细考虑它的支持程度，尤其是在多地址和多播场景中，并评估ULA需求的强度。[ULA-USAGE]对ULA的使用提供了更详细的分析和建议。
The enterprise administrator will want to evaluate whether the enterprise will request address space from a Local Internet Registry (LIR) such as an ISP; a Regional Internet Registry (RIR) such as AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC; or a National Internet Registry (NIR) operated in some countries. The normal allocation is Provider-Aggregated (PA) address space from the enterprise's ISP, but use of PA space implies renumbering when changing providers. Instead, an enterprise may request Provider-Independent (PI) space; this may involve an additional fee, but the enterprise may then be better able to be multihomed using that prefix and will avoid a renumbering process when changing ISPs (though it should be noted that renumbering caused by outgrowing the space, merger, or other internal reason would still not be avoided with PI space).
企业管理员需要评估企业是否会从本地互联网注册中心（LIR）请求地址空间，如ISP；区域互联网注册中心（RIR），如AfriNIC、APNIC、ARIN、LACNIC或RIME-NCC；或在某些国家运营的国家互联网注册中心（NIR）。正常分配是来自企业ISP的提供商聚合（PA）地址空间，但使用PA空间意味着在更改提供商时重新编号。相反，企业可以请求独立于提供商（PI）的空间；这可能需要额外的费用，但企业可能会更好地使用该前缀进行多址，并在更改ISP时避免重新编号过程（但应注意，PI space仍无法避免因空间过大、合并或其他内部原因导致的重新编号）。
The type of address selected (PI vs. PA) should be congruent with the routing needs of the enterprise. The selection of address type will determine if an operator will need to apply new routing techniques and may limit future flexibility. There is no right answer, but the needs of the External Phase may affect what address type is selected.
选择的地址类型（PI与PA）应与企业的路由需求一致。地址类型的选择将决定运营商是否需要应用新的路由技术，并可能限制未来的灵活性。没有正确的答案，但外部阶段的需要可能会影响所选择的地址类型。
Each network location or site will need a prefix assignment. Depending on the type of site/location, various prefix sizes may be used. In general, historical guidance suggests that each site should get at least a /48, as documented in RFC 5375 and [RFC6177]. In addition to allowing for simple planning, this can allow a site to use its prefix for local connectivity, should the need arise, and if the local ISP supports it.
每个网络位置或站点都需要前缀分配。根据站点/位置的类型，可以使用不同的前缀大小。一般来说，历史指南建议每个站点至少应获得a/48，如RFC 5375和[RFC6177]中所述。除了允许简单的规划外，如果需要，并且本地ISP支持，这还允许站点使用其前缀进行本地连接。
When assigning addresses to end systems, the enterprise may use manually configured addresses (common on servers) or Stateless Address Autoconfiguration (SLAAC) or DHCPv6 for client systems.
在向终端系统分配地址时，企业可以使用手动配置的地址（服务器上常见）或无状态地址自动配置（SLAAC）或DHCPv6（用于客户端系统）。
Early IPv6 enterprise deployments have used SLAAC both for its simplicity and the time DHCPv6 has taken to mature. However, DHCPv6 is now very mature; thus, workstations managed by an enterprise may use stateful DHCPv6 for addressing on corporate LAN segments. DHCPv6 allows for the additional configuration options often employed by enterprise administrators, and by using stateful DHCPv6, administrators correlating system logs know which system had which address at any given time. Such an accountability model is familiar from IPv4 management, though DHCPv6 hosts are identified by a DHCP Unique Identifier (DUID) rather than a MAC address. For equivalent accountability with SLAAC (and potentially privacy addresses), a monitoring system that harvests IP/MAC mappings from switch and router equipment could be used.
早期的IPv6企业部署使用了SLAAC，既因为它的简单性，也因为DHCPv6成熟所需的时间。然而，DHCPv6现在已经非常成熟；因此，企业管理的工作站可以使用有状态DHCPv6在企业LAN段上寻址。DHCPv6允许企业管理员经常使用的附加配置选项，通过使用有状态DHCPv6，关联系统日志的管理员可以知道在任何给定时间哪个系统拥有哪个地址。虽然DHCPv6主机是通过DHCP唯一标识符（DUID）而不是MAC地址来标识的，但这种责任模型在IPv4管理中很常见。对于SLAAC（以及潜在的隐私地址）的同等责任，可以使用从交换机和路由器设备获取IP/MAC映射的监控系统。
A common deployment consideration for any enterprise network is how to get host DNS records updated. Commonly, either the host will send DNS updates or the DHCP server will update records. If there is sufficient trust between the hosts and the DNS server, the hosts may update (and the enterprise may use SLAAC for addressing). Otherwise, the DHCPv6 server can be configured to update the DNS server. Note that an enterprise network with this more controlled environment will need to disable SLAAC on network segments and force end hosts to use DHCPv6 only.
任何企业网络的一个常见部署考虑事项是如何更新主机DNS记录。通常，主机将发送DNS更新或DHCP服务器将更新记录。如果主机和DNS服务器之间存在足够的信任，则主机可能会更新（企业可能会使用SLAAC进行寻址）。否则，可以将DHCPv6服务器配置为更新DNS服务器。请注意，具有这种更受控环境的企业网络将需要在网段上禁用SLAAC，并强制终端主机仅使用DHCPv6。
In the data center or server room, assume a /64 per VLAN. This applies even if each individual system is on a separate VLAN. In a /48 assignment, typical for a site, there are then still 65,535 /64 blocks. Some administrators reserve a /64 but configure a small subnet, such as /112, /126, or /127, to prevent rogue devices from attaching and getting numbers; an alternative is to monitor traffic for surprising addresses or Neighbor Discovery (ND) tables for new entries. Addresses are either configured manually on the server or reserved on a DHCPv6 server, which may also synchronize forward and reverse DNS (though see [RFC6866] for considerations on static addressing). SLAAC is not recommended for servers because of the need to synchronize RA timers with DNS Times to Live (TTLs) so that the DNS entry expires at the same time as the address.
在数据中心或服务器机房中，假设每个VLAN为a/64。即使每个单独的系统位于单独的VLAN上，这也适用。在a/48分配中（典型的站点分配），仍然有65535/64个块。一些管理员保留a/64，但配置一个小的子网，如/112、/126或/127，以防止恶意设备附加和获取号码；另一种方法是监视意外地址的通信量，或监视新条目的邻居发现（ND）表。地址可以在服务器上手动配置，也可以在DHCPv6服务器上保留，这也可以同步正向和反向DNS（尽管有关静态寻址的注意事项，请参阅[RFC6866]）。不建议服务器使用SLAAC，因为需要将RA计时器与DNS生存时间（TTLs）同步，以便DNS条目与地址同时过期。
All user access networks should be a /64. Point-to-point links where NDP is not used may also utilize a /127 (see [RFC6164]).
所有用户接入网络应为a/64。未使用NDP的点对点链路也可以使用a/127（见[RFC6164]）。
Plan to aggregate at every layer of network hierarchy. There is no need for variable length subnet mask (VLSM) [RFC1817] in IPv6, and addressing plans based on conservation of addresses are shortsighted. Use of prefixes longer then /64 on network segments will break common IPv6 functions such as SLAAC [RFC4862]. Where multiple VLANs or other Layer 2 domains converge, allow some room for expansion. Renumbering due to outgrowing the network plan is a nuisance, so
计划在网络层次结构的每一层进行聚合。IPv6中不需要可变长度子网掩码（VLSM）[RFC1817]，基于地址守恒的寻址计划是短视的。在网段上使用长于/64的前缀将破坏常见的IPv6功能，如SLAAC[RFC4862]。在多个VLAN或其他第2层域汇聚的地方，允许一些扩展空间。由于超出网络计划而重新编号是一件麻烦事，因此
allow room within it. Generally, plan to grow to about twice the current size that can be accommodated; where rapid growth is planned, allow for twice that growth. Also, if DNS (or reverse DNS) authority may be delegated to others in the enterprise, assignments need to be on nibble boundaries (that is, on a multiple of 4 bits, such as /64, /60, /56, ..., /48, /44), to ensure that delegated zones align with assigned prefixes.
在里面留出空间。一般来说，计划扩大到目前可容纳规模的两倍左右；在计划快速增长的地方，考虑两倍的增长。此外，如果可以将DNS（或反向DNS）权限委托给企业中的其他人，则分配需要在半字节边界上（即，在4位的倍数上，例如/64、/60、/56、/48、/44），以确保委托区域与分配的前缀对齐。
If using ULAs, it is important to note that AAAA and PTR records for ULAs are not recommended to be installed in the global DNS. Similarly, reverse (address-to-name) queries for ULA must not be sent to name servers outside of the organization, due to the load that such queries would create for the authoritative name servers for the ip6.arpa zone. For more details, please refer to Section 4.4 of [RFC4193].
如果使用ULA，请务必注意，不建议在全局DNS中安装ULA的AAAA和PTR记录。类似地，ULA的反向（地址到名称）查询不得发送到组织外部的名称服务器，因为此类查询将为ip6.arpa区域的权威名称服务器创建负载。有关更多详细信息，请参阅[RFC4193]第4.4节。
Enterprise networks are increasingly including virtual networks where a single, physical node may host many virtualized addressable devices. It is imperative that the addressing plans assigned to these virtual networks and devices be consistent and non-overlapping with the addresses assigned to real networks and nodes. For example, a virtual network established within an isolated lab environment may, at a later time, become attached to the production enterprise network.
企业网络越来越多地包括虚拟网络，其中单个物理节点可以承载许多虚拟可寻址设备。分配给这些虚拟网络和设备的寻址计划必须与分配给真实网络和节点的地址一致且不重叠。例如，在隔离实验室环境中建立的虚拟网络可能会在稍后连接到生产企业网络。
Enterprises will often have a number of operational tools and support systems that are used to provision, monitor, manage, and diagnose the network and systems within their environment. These tools and systems will need to be assessed for compatibility with IPv6. The compatibility may be related to the addressing and connectivity of various devices as well as IPv6 awareness of the tools and processing logic.
企业通常会有许多操作工具和支持系统，用于提供、监视、管理和诊断其环境中的网络和系统。需要评估这些工具和系统与IPv6的兼容性。兼容性可能与各种设备的寻址和连接以及对工具和处理逻辑的IPv6意识有关。
The tools within the organization fall into two general categories: those that focus on managing the network and those that are focused on managing systems and applications on the network. In either instance, the tools will run on platforms that may or may not be capable of operating in an IPv6 network. This lack in functionality may be related to operating system version or based on some hardware constraint. Those systems that are found to be incapable of utilizing an IPv6 connection, or which are dependent on an IPv4 stack, may need to be replaced or upgraded.
组织内的工具分为两大类：专注于管理网络的工具和专注于管理网络上的系统和应用程序的工具。在任何一种情况下，这些工具都将运行在能够或不能在IPv6网络中运行的平台上。这种功能缺失可能与操作系统版本有关，或者基于某些硬件约束。发现无法利用IPv6连接或依赖IPv4堆栈的系统可能需要更换或升级。
In addition to devices working on an IPv6 network natively, or via a transition tunnel, many tools and support systems may require additional software updates to be IPv6 aware or even a hardware
除了以本机方式或通过过渡隧道在IPv6网络上工作的设备外，许多工具和支持系统可能需要额外的软件更新以支持IPv6，甚至需要硬件
upgrade (usually for additional memory, IPv6 addresses are larger and for a while, IPv4 and IPv6 addresses will coexist in the tool). This awareness may include the ability to manage IPv6 elements and/or applications in addition to the ability to store and utilize IPv6 addresses.
升级（通常对于附加内存，IPv6地址更大，并且在一段时间内，IPv4和IPv6地址将共存于工具中）。除了存储和利用IPv6地址之外，这种意识还可能包括管理IPv6元素和/或应用程序的能力。
Considerations when assessing the tools and support systems may include the fact that IPv6 addresses are significantly larger than IPv4, requiring data stores to support the increased size. Such issues are among those discussed in [RFC5952]. Many organizations may also run dual-stack networks; therefore, the tools need to not only support IPv6 operation but may also need to support the monitoring, management, and intersection with both IPv6 and IPv4 simultaneously. It is important to note that managing IPv6 is not just constrained to using large IPv6 addresses, but also that IPv6 interfaces and nodes are likely to use two or more addresses as part of normal operation. Updating management systems to deal with these additional nuances will likely consume time and considerable effort.
评估工具和支持系统时的注意事项可能包括IPv6地址明显大于IPv4，需要数据存储来支持增加的大小。[RFC5952]中讨论了这些问题。许多组织也可能运行双堆栈网络；因此，这些工具不仅需要支持IPv6操作，还可能需要同时支持IPv6和IPv4的监视、管理和交叉。需要注意的是，管理IPv6不仅限于使用大型IPv6地址，而且IPv6接口和节点在正常操作中可能会使用两个或多个地址。更新管理系统以处理这些额外的细微差别可能需要花费大量时间和精力。
For networking systems, like node management systems, it is not always necessary to support local IPv6 addressing and connectivity. Operations such as SNMP MIB polling can occur over IPv4 transport while seeking responses related to IPv6 information. Where this may seem advantageous to some, it should be noted that without local IPv6 connectivity, the management system may not be able to perform all expected functions -- such as reachability and service checks.
对于网络系统，如节点管理系统，并不总是需要支持本地IPv6寻址和连接。在寻找与IPv6信息相关的响应时，可以通过IPv4传输执行SNMP MIB轮询等操作。如果这对某些人来说似乎是有利的，那么应该注意，如果没有本地IPv6连接，管理系统可能无法执行所有预期的功能，例如可达性和服务检查。
Organizations should be aware that changes to older IPv4-only SNMP MIB specifications have been made by the IETF and are related to legacy operation in [RFC2096] and [RFC2011]. Updated specifications are now available in [RFC4292] and [RFC4293] that modified the older MIB framework to be IP protocol agnostic, supporting both IPv4 and IPv6. Polling systems will need to be upgraded to support these updates as well as the end stations, which are polled.
组织应该知道，IETF已经对旧的仅IPv4 SNMP MIB规范进行了更改，并且与[RFC2096]和[RFC2011]中的旧操作相关。[RFC4292]和[RFC4293]中现在提供了更新的规范，这些规范将旧的MIB框架修改为IP协议无关，同时支持IPv4和IPv6。投票系统需要升级，以支持这些更新以及被投票的终端站。
The External Phase for enterprise IPv6 adoption covers topics that deal with how an organization connects its infrastructure to the external world. These external connections may be toward the Internet at large or to other networks. The External Phase covers connectivity, security and monitoring of various elements, and outward-facing or accessible services.
企业IPv6采用的外部阶段涵盖的主题涉及企业如何将其基础架构连接到外部世界。这些外部连接可能指向整个互联网或其他网络。外部阶段包括各种要素的连通性、安全性和监控，以及面向外部或可访问的服务。
The enterprise will need to work with one or more service providers to gain connectivity to the Internet or transport service infrastructure such as a BGP/MPLS IP VPN as described in [RFC4364] and [RFC4659]. One significant factor that will guide how an organization may need to communicate with the outside world will involve the use of PI and/or PA IPv6 space.
企业需要与一个或多个服务提供商合作，以获得与互联网或传输服务基础设施的连接，如[RFC4364]和[RFC4659]中所述的BGP/MPLS IP VPN。指导组织可能需要如何与外部世界沟通的一个重要因素将涉及PI和/或PA IPv6空间的使用。
Enterprises should be aware that, depending on which address type they selected (PI vs. PA) in their planning phase, they may need to implement new routing functions and/or behaviors to support their connectivity to the ISP. In the case of PI, the upstream ISP may offer options to route the prefix (typically a /48) on the enterprise's behalf and update the relevant routing databases. Otherwise, the enterprise may need to perform this task on their own and use BGP to inject the prefix into the global BGP system.
企业应该意识到，根据他们在规划阶段选择的地址类型（PI与PA），他们可能需要实施新的路由功能和/或行为，以支持与ISP的连接。在PI的情况下，上游ISP可以代表企业提供路由前缀（通常是a/48）的选项，并更新相关路由数据库。否则，企业可能需要自己执行此任务，并使用BGP将前缀注入全局BGP系统。
Note that the rules set by the RIRs for an enterprise acquiring PI address space have changed over time. For example, in the European region, the RIPE-NCC no longer requires an enterprise to be multihomed to be eligible for an IPv6 PI allocation. Requests can be made directly or via a LIR. It is possible that the rules may change again and may vary between RIRs.
请注意，RIRs为获取PI地址空间的企业设置的规则随着时间的推移而改变。例如，在欧洲地区，RIME-NCC不再要求企业必须是多址的，才有资格获得IPv6 PI分配。可以直接或通过LIR提出请求。规则可能会再次更改，并且在RIR之间可能会有所不同。
When seeking IPv6 connectivity to a service provider, native IPv6 connectivity is preferred since it provides the most robust and efficient form of connectivity. If native IPv6 connectivity is not possible due to technical or business limitations, the enterprise may utilize readily available transition tunnel IPv6 connectivity. There are IPv6 transit providers that provide robust tunneled IPv6 connectivity that can operate over IPv4 networks. It is important to understand the transition-tunnel mechanism used and to consider that it will have higher latency than native IPv4 or IPv6, and may have other problems, e.g., related to MTUs.
在寻求与服务提供商的IPv6连接时，首选本机IPv6连接，因为它提供了最强健、最高效的连接形式。如果由于技术或业务限制而无法实现本机IPv6连接，则企业可以利用现成的过渡隧道IPv6连接。有一些IPv6传输提供商提供可在IPv4网络上运行的强健的隧道式IPv6连接。重要的是要理解使用的过渡隧道机制，并考虑它将具有比本地IPv4或IPv6更高的延迟，并且可能存在其他问题，例如，与MTU有关。
It is important to evaluate MTU considerations when adding IPv6 to an existing IPv4 network. It is generally desirable to have the IPv6 and IPv4 MTU congruent to simplify operations (so the two address families behave similarly, that is, as expected). If the enterprise uses transition tunnels inside or externally for IPv6 connectivity, then modification of the MTU on hosts/routers may be needed as mid-stream fragmentation is no longer supported in IPv6. It is preferred that Path MTU Discovery (pMTUD) be used to optimize the MTU, so erroneous filtering of the related ICMPv6 message types should be monitored. Adjusting the MTU may be the only option if undesirable upstream ICMPv6 filtering cannot be removed.
将IPv6添加到现有IPv4网络时，评估MTU注意事项非常重要。通常希望IPv6和IPv4 MTU一致，以简化操作（因此这两个地址族的行为类似，也就是说，正如预期的那样）。如果企业在内部或外部使用过渡隧道进行IPv6连接，则可能需要修改主机/路由器上的MTU，因为IPv6不再支持中流分段。最好使用路径MTU发现（pMTUD）来优化MTU，因此应监控相关ICMPv6消息类型的错误过滤。如果无法移除不需要的上游ICMPv6过滤，则调整MTU可能是唯一选项。
The most important part of security for external IPv6 deployment is filtering and monitoring. Filtering can be done by stateless ACLs or a stateful firewall. The security policies must be consistent for IPv4 and IPv6 (or else the attacker will use the less-protected protocol stack), except that certain ICMPv6 messages must be allowed through and to the filtering device (see [RFC4890]):
外部IPv6部署的安全性最重要的部分是筛选和监视。过滤可以通过无状态ACL或有状态防火墙完成。IPv4和IPv6的安全策略必须一致（否则攻击者将使用受保护程度较低的协议栈），但必须允许某些ICMPv6消息通过和发送到过滤设备（请参阅[RFC4890]）：
o Packet Too Big: essential to allow Path MTU discovery to work
o 数据包太大：必须允许路径MTU发现工作
o Parameter Problem
o 参数问题
o Time Exceeded
o 超过时间
In addition, NDP messages (including Neighbor Solicitation, RAs, etc.) are required for local hosts.
此外，本地主机需要NDP消息（包括邻居请求、RAs等）。
It could also be safer to block all fragments where the transport layer header is not in the first fragment to avoid attacks as described in [RFC5722]. Some filtering devices allow this filtering. Ingress filters and firewalls should follow [RFC5095] in handling routing extension header type 0, dropping the packet and sending ICMPv6 Parameter Problem, unless Segments Left = 0 (in which case, ignore the header).
还可以更安全地阻止传输层头不在第一个片段中的所有片段，以避免[RFC5722]中所述的攻击。某些过滤设备允许此过滤。入口过滤器和防火墙在处理路由扩展头类型0、丢弃数据包和发送ICMPv6参数问题时应遵循[RFC5095]，除非Segments Left=0（在这种情况下，忽略该头）。
If an IPS is used for IPv4 traffic, then an IPS should also be used for IPv6 traffic. In general, make sure IPv6 security is at least as good as IPv4. This also includes all email content protection (anti-spam, content filtering, data leakage prevention, etc.).
如果IPS用于IPv4通信，则IPS也应用于IPv6通信。一般来说，确保IPv6安全性至少与IPv4一样好。这还包括所有电子邮件内容保护（反垃圾邮件、内容过滤、数据泄漏预防等）。
The edge router must also implement anti-spoofing techniques based on [RFC2827] (also known as BCP 38).
边缘路由器还必须实施基于[RFC2827]（也称为BCP 38）的反欺骗技术。
In order to protect the networking devices, it is advised to implement control plane policing as per [RFC6192].
为了保护联网设备，建议按照[RFC6192]实施控制平面监控。
The potential NDP cache exhaustion attack (see [RFC6583]) can be mitigated by two techniques:
潜在的NDP缓存耗尽攻击（请参见[RFC6583]）可以通过两种技术来缓解：
o Good NDP implementation with memory utilization limits as well as rate limiters and prioritization of requests.
o 具有内存利用率限制、速率限制和请求优先级的良好NDP实现。
o Or, as the external deployment usually involves just a couple of exposed statically configured IPv6 addresses (virtual addresses of web, email, and DNS servers), then it is straightforward to build an ingress ACL allowing traffic for those addresses and denying traffic to any other addresses. This actually prevents the attack
o 或者，由于外部部署通常只涉及几个公开的静态配置的IPv6地址（web、电子邮件和DNS服务器的虚拟地址），因此可以直接构建入口ACL，允许这些地址的通信，并拒绝任何其他地址的通信。这实际上可以防止攻击
as a packet for a random destination will be dropped and will never trigger a neighbor resolution.
因为随机目的地的数据包将被丢弃，并且永远不会触发邻居解析。
Monitoring the use of the Internet connectivity should be done for IPv6 as it is done for IPv4. This includes the use of IPFIX [RFC7012] to report abnormal traffic patterns (such as port scanning, SYN flooding, and related IP source addresses) from monitoring tools and evaluating data read from SNMP MIBs [RFC4293] (some of which also enable the detection of abnormal bandwidth utilization) and syslogs (finding server and system errors). Where NetFlow is used, Version 9 is required for IPv6 support. Monitoring systems should be able to examine IPv6 traffic, use IPv6 for connectivity, and record IPv6 addresses, and any log parsing tools and reporting need to support IPv6. Some of this data can be sensitive (including personally identifiable information) and care in securing it should be taken, with periodic purges. Integrity protection on logs and sources of log data is also important to detect unusual behavior (misconfigurations or attacks). Logs may be used in investigations, which depend on trustworthy data sources (tamper resistant).
监控互联网连接的使用应该针对IPv6，就像监控IPv4一样。这包括使用IPFIX[RFC7012]从监控工具报告异常流量模式（如端口扫描、SYN泛洪和相关IP源地址），并评估从SNMP MIB[RFC4293]读取的数据（其中一些还可以检测异常带宽利用率）和系统日志（查找服务器和系统错误）。在使用NetFlow的情况下，IPv6支持需要版本9。监控系统应该能够检查IPv6流量，使用IPv6进行连接，并记录IPv6地址，任何日志解析工具和报告都需要支持IPv6。其中一些数据可能是敏感的（包括个人身份信息），应注意保护这些数据，并定期清除。日志和日志数据源的完整性保护对于检测异常行为（错误配置或攻击）也很重要。日志可用于依赖可靠数据源（防篡改）的调查。
In addition, monitoring of external services (such as web sites) should be made address specific, so that people are notified when either the IPv4 or IPv6 version of a site fails.
此外，外部服务（如网站）的监控应针对具体地址，以便在网站的IPv4或IPv6版本出现故障时通知用户。
The path to the servers accessed from the Internet usually involves security devices (firewall and IPS), server load balancing (SLB), and real physical servers. The latter stage is also multi-tiered for scalability and security between presentation and data storage. The ideal transition is to enable native dual stack on all devices; but as part of the phased approach, operators have used the following techniques with success:
从Internet访问服务器的路径通常涉及安全设备（防火墙和IP）、服务器负载平衡（SLB）和实际物理服务器。后一阶段也是多层的，以实现演示和数据存储之间的可扩展性和安全性。理想的转换是在所有设备上启用本机双堆栈；但作为分阶段方法的一部分，运营商成功地使用了以下技术：
o Use a network device to apply NAT64 and basically translate an inbound TCP connection (or any other transport protocol) over IPv6 into a TCP connection over IPv4. This is the easiest to deploy as the path is mostly unchanged, but it hides all IPv6 remote users behind a single IPv4 address, which leads to several audit trail and security issues (see [RFC6302]).
o 使用网络设备应用NAT64，基本上将IPv6上的入站TCP连接（或任何其他传输协议）转换为IPv4上的TCP连接。这是最容易部署的，因为路径基本不变，但它将所有IPv6远程用户隐藏在单个IPv4地址后面，这会导致一些审计跟踪和安全问题（请参见[RFC6302]）。
o Use the server load balancer, which acts as an application proxy to do this translation. Compared to the NAT64, it has the potential benefit of going through the security devices as native IPv6 (so more audit and trace abilities) and is also able to insert an HTTP X-Forward-For header that contains the remote IPv6
o 使用服务器负载平衡器（充当应用程序代理）执行此转换。与NAT64相比，它具有作为本机IPv6通过安全设备的潜在优势（因此具有更多的审核和跟踪功能），并且还能够插入包含远程IPv6的HTTP X-Forward-For标头
address. The latter feature allows for logging and rate limiting on the real servers based on the IPV6 address even if those servers run only IPv4.
住址后一项功能允许基于IPV6地址在实际服务器上进行日志记录和速率限制，即使这些服务器仅运行IPv4。
In either of these cases, care should be taken to secure logs for privacy reasons and to periodically purge them.
在这两种情况下，出于隐私原因，应注意保护日志，并定期清除日志。
Network Prefix Translation for IPv6, or NPTv6 as described in [RFC6296], provides a framework to utilize prefix ranges within the internal network that are separate (address independent) from the assigned prefix from the upstream provider or registry. As mentioned above, while NPTv6 has potential use cases in IPv6 networks, the implications of its deployment need to be fully understood, particularly where any applications might embed IPv6 addresses in their payloads.
IPv6的网络前缀转换，或[RFC6296]中所述的NPTv6，提供了一个框架来利用内部网络中的前缀范围，这些范围与上游提供商或注册中心分配的前缀分开（独立于地址）。如上所述，虽然NPTv6在IPv6网络中有潜在的使用案例，但需要充分了解其部署的含义，特别是在任何应用程序可能在其有效负载中嵌入IPv6地址的情况下。
Use of NPTv6 can be chosen independently from how addresses are assigned and routed within the internal network, how prefixes are routed towards the Internet, or whether PA or PI addresses are used.
NPTv6的使用可以独立于内部网络中地址的分配和路由方式、前缀如何路由到Internet，或者是否使用PA或PI地址来选择。
This phase deals with the delivery of IPv6 to the internal user-facing side of the Information Technology (IT) infrastructure, which comprises various components such as network devices (routers, switches, etc.), end-user devices and peripherals (workstations, printers, etc.), and internal corporate systems.
该阶段涉及将IPv6交付给信息技术（IT）基础设施面向内部用户的一方，该基础设施包括各种组件，如网络设备（路由器、交换机等）、最终用户设备和外围设备（工作站、打印机等）以及内部公司系统。
An important design paradigm to consider during this phase is "dual stack when you can, tunnel when you must". Dual stacking allows a more robust, production-quality IPv6 network than is typically facilitated by internal use of transition tunnels that are harder to troubleshoot and support, and that may introduce scalability and performance issues. Of course, tunnels may still be used in production networks, but their use needs to be carefully considered, e.g., where the transition tunnel may be run through a security or filtering device. Tunnels do also provide a means to experiment with IPv6 and gain some operational experience with the protocol. [RFC4213] describes various transition mechanisms in more detail. [RFC6964] suggests operational guidance when using Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) tunnels [RFC5214], though we would recommend use of dual stack wherever possible.
在这个阶段要考虑的一个重要设计范例是“双栈，当你可以，隧道时，你必须”。与内部使用过渡通道相比，双堆叠允许一个更健壮、生产质量更高的IPv6网络，过渡通道更难进行故障排除和支持，并且可能会带来可扩展性和性能问题。当然，在生产网络中仍然可以使用隧道，但需要仔细考虑它们的使用，例如，在过渡隧道可能通过安全或过滤设备的情况下。隧道也提供了一种方法来试验IPv6，并获得一些使用该协议的操作经验。[RFC4213]更详细地描述了各种转换机制。[RFC6964]建议在使用站点内自动隧道寻址协议（ISATAP）隧道[RFC5214]时提供操作指南，尽管我们建议尽可能使用双堆栈。
IPv6 must be deployed in a secure way. This means that all existing IPv4 security policies must be extended to support IPv6; IPv6 security policies will be the IPv6 equivalent of the existing IPv4 ones (taking into account the difference for ICMPv6 [RFC4890]). As in IPv4, security policies for IPv6 will be enforced by firewalls, ACL, IPS, VPN, and so on.
IPv6必须以安全的方式部署。这意味着必须扩展所有现有IPv4安全策略以支持IPv6；IPv6安全策略将与现有IPv4策略的IPv6等效（考虑到ICMPv6[RFC4890]的差异）。与IPv4一样，IPv6的安全策略将由防火墙、ACL、IPS、VPN等实施。
Privacy extension addresses [RFC4941] raise a challenge for an audit trail as explained in Section 2.4.3 of this document. The enterprise may choose to attempt to enforce use of DHCPv6 or deploy monitoring tools that harvest accountability data from switches and routers (thus making the assumption that devices may use any addresses inside the network).
隐私扩展地址[RFC4941]对本文件第2.4.3节所述的审计跟踪提出了质疑。企业可以选择尝试强制使用DHCPv6或部署从交换机和路由器获取责任数据的监视工具（从而假设设备可以使用网络内的任何地址）。
One major issue is threats against ND. This means, for example, that the internal network at the access layer (where hosts connect to the network over wired or wireless) should implement RA-Guard [RFC6105] and the techniques being specified by the SAVI WG [RFC6959]; see also Section 2.4.3 of this document for more information.
一个主要问题是对ND的威胁。这意味着，例如，接入层的内部网络（其中主机通过有线或无线连接到网络）应实现RA-Guard[RFC6105]和SAVI-WG[RFC6959]指定的技术；更多信息请参见本文件第2.4.3节。
The typical enterprise network infrastructure comprises a combination of the following network elements -- wired access switches, wireless access points, and routers (although it is fairly common to find hardware that collapses switching and routing functionality into a single device). Basic wired access switches and access points operate only at the physical and link layers and don't really have any special IPv6 considerations other than being able to support IPv6 addresses themselves for management purposes. In many instances, these devices possess a lot more intelligence than simply switching packets. For example, some of these devices help assist with link-layer security by incorporating features such as ARP inspection and DHCP snooping, or they may help limit where multicast floods by using IGMP (or, in the case of IPv6, Multicast Listener Discovery (MLD)) snooping.
典型的企业网络基础设施包括以下网络元素的组合——有线接入交换机、无线接入点和路由器（尽管将交换和路由功能整合到单个设备中的硬件相当常见）。基本有线接入交换机和接入点仅在物理层和链路层运行，除了能够支持IPv6地址本身用于管理之外，实际上没有任何特殊的IPv6考虑因素。在许多情况下，这些设备比简单地交换数据包拥有更多的智能。例如，其中一些设备通过合并ARP检查和DHCP窥探等功能来帮助实现链路层安全，或者它们可以通过使用IGMP（或者，在IPv6的情况下，多播侦听器发现（MLD））窥探来帮助限制多播泛滥的位置。
Another important consideration in enterprise networks is first-hop router redundancy. This directly ties into network reachability from an end host's point of view. IPv6 ND [RFC4861] provides a node with the capability to maintain a list of available routers on the link, in order to be able to switch to a backup path should the primary be unreachable. By default, ND will detect a router failure in 38 seconds and cycle onto the next default router listed in its cache. While this feature provides a basic level of first-hop router redundancy, most enterprise IPv4 networks are designed to fail over
企业网络中的另一个重要考虑因素是第一跳路由器冗余。从终端主机的角度来看，这与网络可达性直接相关。IPv6 ND[RFC4861]为节点提供了在链路上维护可用路由器列表的能力，以便在主路由器无法访问时能够切换到备份路径。默认情况下，ND将在38秒内检测到路由器故障，并循环到其缓存中列出的下一个默认路由器。虽然此功能提供了基本级别的第一跳路由器冗余，但大多数企业IPv4网络设计为故障转移
much faster. Although this delay can be improved by adjusting the default timers, care must be taken to protect against transient failures and to account for increased traffic on the link. Another option in which to provide robust first-hop redundancy is to use the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for IPv6 [RFC5798]. This protocol provides a much faster switchover to an alternate default router than default ND parameters. Using VRRPv3, a backup router can take over for a failed default router in around three seconds (using VRRPv3 default parameters). This is done without any interaction with the hosts and a minimum amount of VRRP traffic.
快得多。虽然可以通过调整默认计时器来改善此延迟，但必须注意防止瞬时故障，并考虑链路上增加的通信量。提供健壮的第一跳冗余的另一个选项是使用IPv6的虚拟路由器冗余协议版本3（VRRPv3）[RFC5798]。该协议提供了比默认ND参数更快的到备用默认路由器的切换。使用VRRPv3，备份路由器可以在大约三秒钟内接管故障的默认路由器（使用VRRPv3默认参数）。这是在不与主机进行任何交互的情况下完成的，并且VRRP通信量最少。
Last but not least, one of the most important design choices to make while deploying IPv6 on the internal network is whether to use SLAAC [RFC4862], the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], or a combination thereof. Each option has advantages and disadvantages, and the choice will ultimately depend on the operational policies that guide each enterprise's network design. For example, if an enterprise is looking for ease of use, rapid deployment, and less administrative overhead, then SLAAC makes more sense for workstations. Manual or DHCPv6 assignments are still needed for servers, as described in the Address Plan and External Phase sections of this document; see Sections 2.6 and 3, respectively. However, if the operational policies call for precise control over IP address assignment for auditing, then DHCPv6 may be preferred. DHCPv6 also allows you to tie into DNS systems for host entry updates and gives you the ability to send other options and information to clients. It is worth noting that in general operation, RAs are still needed in DHCPv6 networks, as there is no DHCPv6 Default Gateway option. Similarly, DHCPv6 is needed in RA networks for other configuration information, e.g., NTP servers or, in the absence of support for DNS resolvers in RAs [RFC6106], DNS resolver information.
最后但并非最不重要的一点是，在内部网络上部署IPv6时，最重要的设计选择之一是使用SLAAC[RFC4862]、IPv6的动态主机配置协议（DHCPv6）[RFC3315]或其组合。每种选择都有优缺点，选择最终取决于指导每个企业网络设计的运营策略。例如，如果企业希望易于使用、快速部署和更少的管理开销，那么SLAAC对于工作站来说更有意义。如本文件地址计划和外部阶段部分所述，服务器仍需要手动或DHCPv6分配；分别见第2.6节和第3节。但是，如果操作策略要求对审核的IP地址分配进行精确控制，则DHCPv6可能是首选。DHCPv6还允许您连接到DNS系统进行主机条目更新，并使您能够向客户端发送其他选项和信息。值得注意的是，在一般操作中，DHCPv6网络中仍然需要RAs，因为没有DHCPv6默认网关选项。类似地，RA网络中需要DHCPv6来获取其他配置信息，例如NTP服务器，或者在RAs[RFC6106]中不支持DNS解析程序的情况下，需要DNS解析程序信息。
Most operating systems (OSes) that are loaded on workstations and laptops in a typical enterprise support IPv6 today. However, there are various out-of-the-box nuances that one should be mindful about. For example, the default behavior of OSes vary; some may have IPv6 turned off by default, some may only have certain features such as privacy extensions to IPv6 addresses (RFC 4941) turned off, while others have IPv6 fully enabled. Further, even when IPv6 is enabled, the choice of which address is used may be subject to source address selection (RFC 6724) and Happy Eyeballs (RFC 6555). Therefore, it is advised that enterprises investigate the default behavior of their installed OS base and account for it during the Inventory Phases of their IPv6 preparations. Furthermore, some OSes may have some
如今，在典型的企业中，大多数加载在工作站和笔记本电脑上的操作系统（OS）都支持IPv6。然而，有各种开箱即用的细微差别需要注意。例如，操作系统的默认行为各不相同；有些可能在默认情况下关闭了IPv6，有些可能只关闭了某些功能，例如IPv6地址的隐私扩展（RFC 4941），而另一些可能完全启用了IPv6。此外，即使启用了IPv6，使用哪个地址的选择也可能取决于源地址选择（RFC 6724）和快乐眼球（RFC 6555）。因此，建议企业调查其已安装操作系统的默认行为，并在IPv6准备的资源清册阶段对其进行说明。此外，某些操作系统可能有一些
transition tunneling mechanisms turned on by default, and in such cases, it is recommended to administratively shut down such interfaces unless required.
默认情况下，转换隧道机制处于打开状态，在这种情况下，除非需要，否则建议以管理方式关闭此类接口。
It is important to note that it is recommended that IPv6 be deployed at the network and system infrastructure level before it is rolled out to end-user devices; ensure IPv6 is running and routed on the wire, and secure and correctly monitored, before exposing IPv6 to end users.
需要注意的是，建议在向最终用户设备推出IPv6之前，在网络和系统基础设施级别部署IPv6；在向最终用户公开IPv6之前，确保IPv6在线路上运行和路由，并且安全且受到正确监控。
Smartphones and tablets are significant IPv6-capable platforms, depending on the support of the carrier's data network.
智能手机和平板电脑是支持IPv6的重要平台，这取决于运营商数据网络的支持。
IPv6 support for peripherals varies. Much like servers, printers are generally configured with a static address (or DHCP reservation) so clients can discover them reliably.
对外围设备的IPv6支持各不相同。与服务器非常相似，打印机通常配置有静态地址（或DHCP保留），以便客户端能够可靠地发现它们。
No IPv6 deployment will be successful without ensuring that all the corporate systems that an enterprise uses as part of its IT infrastructure support IPv6. Examples of such systems include, but are not limited to, email, video conferencing, telephony (VoIP), DNS, RADIUS, etc. All these systems must have their own detailed IPv6 rollout plan in conjunction with the network IPv6 rollout. It is important to note that DNS is one of the main anchors in an enterprise deployment, since most end hosts decide whether or not to use IPv6 depending on the presence of IPv6 AAAA records in a reply to a DNS query. It is recommended that system administrators selectively turn on AAAA records for various systems as and when they are IPv6 enabled; care must be taken though to ensure all services running on that host name are IPv6 enabled before adding the AAAA record. Care with web proxies is advised; a mismatch in the level of IPv6 support between the client, proxy, and server can cause communication problems. All monitoring and reporting tools across the enterprise will need to be modified to support IPv6.
如果不确保企业用作其IT基础架构一部分的所有公司系统都支持IPv6，则任何IPv6部署都不会成功。此类系统的示例包括但不限于电子邮件、视频会议、电话（VoIP）、DNS、RADIUS等。所有这些系统必须有自己的详细IPv6部署计划以及网络IPv6部署。需要注意的是，DNS是企业部署中的主要锚之一，因为大多数终端主机根据DNS查询回复中是否存在IPv6 AAAA记录来决定是否使用IPv6。建议系统管理员在启用IPv6时有选择地打开各种系统的AAAA记录；但是，在添加AAAA记录之前，必须小心确保在该主机名上运行的所有服务都已启用IPv6。建议谨慎使用网络代理；客户端、代理和服务器之间的IPv6支持级别不匹配可能会导致通信问题。整个企业的所有监控和报告工具都需要修改以支持IPv6。
Early IPv6 enterprise deployments have generally taken a dual-stack approach to enabling IPv6, i.e., the existing IPv4 services have not been turned off. Although IPv4 and IPv6 networks will coexist for a long time, the long-term enterprise network roadmap should include steps to simplify engineering and operations by deprecating IPv4 from the dual-stack network. In some extreme cases, deploying dual-stack networks may not even be a viable option for very large enterprises due to the address space described in RFC 1918 not being large enough to support the network's growth. In such cases, deploying IPv6-only
早期的IPv6企业部署通常采用双栈方法来启用IPv6，即现有的IPv4服务尚未关闭。虽然IPv4和IPv6网络将长期共存，但长期企业网络路线图应包括通过从双栈网络中弃用IPv4来简化工程和操作的步骤。在某些极端情况下，部署双栈网络甚至可能不是非常大的企业的可行选择，因为RFC 1918中描述的地址空间不足以支持网络的增长。在这种情况下，仅部署IPv6
networks might be the only choice available to sustain network growth. In other cases, there may be elements of an otherwise dual-stack network that may be run in IPv6 only.
网络可能是维持网络增长的唯一选择。在其他情况下，可能存在仅在IPv6中运行的双栈网络的元素。
If nodes in the network don't need to talk to an IPv4-only node, then deploying IPv6-only networks should be straightforward. However, most nodes will need to communicate with some IPv4-only nodes; an IPv6-only node may, therefore, require a translation mechanism. As [RFC6144] points out, it is important to look at address translation as a transition strategy towards running an IPv6-only network.
如果网络中的节点不需要与仅IPv4的节点通信，那么部署仅IPv6的网络应该很简单。但是，大多数节点将需要与一些仅IPv4节点通信；因此，仅IPv6节点可能需要转换机制。正如[RFC6144]所指出的，将地址转换视为运行纯IPv6网络的过渡策略非常重要。
There are various stateless and stateful IPv4/IPv6 translation methods available today that help IPv6-to-IPv4 communication. RFC 6144 provides a framework for IPv4/IPv6 translation and describes in detail various scenarios in which such translation mechanisms could be used. [RFC6145] describes stateless address translation. In this mode, a specific IPv6 address range will represent IPv4 systems (IPv4-converted addresses), and the IPv6 systems have addresses (IPv4-translatable addresses) that can be algorithmically mapped to a subset of the service provider's IPv4 addresses. NAT64 [RFC6146] describes stateful address translation. As the name suggests, the translation state is maintained between IPv4 address/port pairs and IPv6 address/port pairs, enabling IPv6 systems to open sessions with IPv4 systems. DNS64 [RFC6147] describes a mechanism for synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs 6146 and RFC 6147 provide a viable method for an IPv6-only client to initiate communications to an IPv4-only server. As described in Enterprise Assumptions, Section 1.1, the administrator will usually want most traffic or flows to be native and only translate as needed.
目前有多种无状态和有状态的IPv4/IPv6转换方法可用于帮助IPv6到IPv4的通信。RFC6144为IPv4/IPv6转换提供了一个框架，并详细描述了可以使用这种转换机制的各种场景。[RFC6145]描述无状态地址转换。在此模式下，特定IPv6地址范围将表示IPv4系统（IPv4转换地址），IPv6系统具有可通过算法映射到服务提供商IPv4地址子集的地址（IPv4可翻译地址）。NAT64[RFC6146]描述有状态地址转换。顾名思义，在IPv4地址/端口对和IPv6地址/端口对之间保持转换状态，使IPv6系统能够打开与IPv4系统的会话。DNS64[RFC6147]描述了从RRs合成AAAA资源记录（RRs）的机制。RFC6146和RFC6147共同为仅IPv6的客户端提供了一种可行的方法，用于启动与仅IPv4的服务器的通信。如第1.1节“企业假设”中所述，管理员通常希望大多数流量或流是本地的，并且只在需要时进行翻译。
The address translation mechanisms for the stateless and stateful translations are defined in [RFC6052]. It is important to note that both of these mechanisms have limitations as to which protocols they support. For example, RFC 6146 only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic only. The classic problems of IPv4 NAT also apply, e.g., handling IP literals in application payloads. The ultimate choice of which translation mechanism to chose will be dictated mostly by existing operational policies pertaining to application support, logging requirements, etc.
[RFC6052]中定义了无状态和有状态转换的地址转换机制。需要注意的是，这两种机制在支持哪些协议方面都存在局限性。例如，RFC6146仅定义有状态NAT64如何转换仅承载TCP、UDP和ICMP流量的单播数据包。IPv4 NAT的经典问题也适用，例如，在应用程序有效负载中处理IP文本。选择哪种转换机制的最终选择将主要取决于与应用程序支持、日志记录要求等相关的现有操作策略。
There is additional work being done in the area of address translation to enhance and/or optimize current mechanisms. For example, [DIVI] describes limitations with the current stateless translation, such as IPv4 address sharing and application layer gateway (ALG) problems, and presents the concept and implementation of dual-stateless IPv4/IPv6 translation (dIVI) to address those issues.
在地址翻译领域正在开展更多工作，以加强和/或优化现有机制。例如，[DIVI]描述了当前无状态转换的限制，例如IPv4地址共享和应用层网关（ALG）问题，并介绍了双无状态IPv4/IPv6转换（DIVI）的概念和实现，以解决这些问题。
It is worth noting that for IPv6-only access networks that use technologies such as NAT64, the more content providers (and enterprises) that make their content available over IPv6, the less the requirement to apply NAT64 to traffic leaving the access network. This particular point is important for enterprises that may start their IPv6 deployment well into the global IPv6 transition. As time progresses, and given the current growth in availability of IPv6 content, IPv6-only operation using NAT64 to manage some flows will become less expensive to run versus the traditional NAT44 deployments since only IPv6-to-IPv4 flows need translation. [RFC6883] provides guidance and suggestions for Internet Content Providers and Application Service Providers in this context.
值得注意的是，对于使用NAT64等技术的仅IPv6接入网络，通过IPv6提供内容的内容提供商（和企业）越多，对离开接入网络的流量应用NAT64的要求就越低。这一点对于可能在全球IPv6过渡期间开始部署IPv6的企业非常重要。随着时间的推移，并且考虑到当前IPv6内容可用性的增长，与传统的NAT44部署相比，使用NAT64管理某些流的纯IPv6操作的运行成本将降低，因为只有IPv6到IPv4流需要转换。[RFC6883]在这方面为互联网内容提供商和应用程序服务提供商提供指导和建议。
Enterprises should also be aware that networks may be subject to future convergence with other networks (i.e., mergers, acquisitions, etc.). An enterprise considering IPv6-only operation may need to be aware that additional transition technologies and/or connectivity strategies may be required depending on the level of IPv6 readiness and deployment in the merging networking.
企业还应意识到，未来网络可能会与其他网络融合（即合并、收购等）。考虑仅使用IPv6的企业可能需要意识到，可能需要额外的过渡技术和/或连接策略，具体取决于合并网络中IPv6的就绪程度和部署情况。
Some guidance for Internet Content and Application Service Providers can be found in [RFC6883], which includes a dedicated section on Content Delivery Networks (CDNs). An enterprise that relies on a CDN to deliver a 'better' e-commerce experience needs to ensure that their CDN provider also supports IPv4/IPv6 traffic selection so that they can ensure 'best' access to the content. A CDN could enable external IPv6 content delivery even if the enterprise provides that content over IPv4.
[RFC6883]中提供了有关互联网内容和应用程序服务提供商的一些指导，其中包括关于内容交付网络（CDN）的专门章节。依赖CDN提供“更好”电子商务体验的企业需要确保其CDN提供商也支持IPv4/IPv6流量选择，以便确保对内容的“最佳”访问。CDN可以启用外部IPv6内容交付，即使企业通过IPv4提供该内容。
IPv6 Data Center considerations are described in [IPv6-DC].
[IPv6 DC]中介绍了IPv6数据中心注意事项。
A number of campus networks around the world have made some initial IPv6 deployments. This has been encouraged by their National Research and Education Network (NREN) backbones, having made IPv6 available natively since the early 2000's. Universities are a natural place for IPv6 deployment to be considered at an early stage, perhaps compared to other enterprises, as they are involved by their very nature in research and education.
世界各地的许多校园网已经进行了一些初步的IPv6部署。他们的国家研究和教育网络（NREN）骨干网鼓励了这一点，自2000年初以来，该网络就在本地提供了IPv6。大学是早期考虑部署IPv6的自然场所，可能与其他企业相比，因为大学本身就参与研究和教育。
Campus networks can deploy IPv6 at their own pace; there is no need to deploy IPv6 across the entire enterprise from day one. Rather, specific projects can be identified for an initial deployment that are both deep enough to give the university experience but small enough to be a realistic first step. There are generally three areas in which such deployments are currently made.
校园网可以按照自己的速度部署IPv6；从第一天起，无需在整个企业中部署IPv6。相反，可以为初始部署确定具体的项目，这些项目既深到足以提供大学经验，又小到足以成为现实的第一步。目前通常在三个领域进行此类部署。
In particular, those initial areas commonly approached are:
特别是，通常采用的初始领域包括：
o External-facing services. Typically, the campus web presence and commonly also external-facing DNS and mail exchange (MX) services. This ensures early IPv6-only adopters elsewhere can access the campus services as simply and as robustly as possible.
o 面向外部的服务。通常，校园网的存在和通常也面向外部的DNS和邮件交换（MX）服务。这确保了其他地方早期的仅IPv6采用者能够尽可能简单、可靠地访问校园服务。
o Computer science department. This is where IPv6-related research and/or teaching is most likely to occur, and where many of the next generation of network engineers are studying, so enabling some or all of the campus computer science department network is a sensible first step.
o 计算机科学系。这是最有可能进行IPv6相关研究和/或教学的地方，也是许多下一代网络工程师正在学习的地方，因此启用部分或全部校园计算机科学系网络是明智的第一步。
o The eduroam wireless network. Eduroam [EDUROAM] is the de facto wireless roaming system for academic networks and uses authentication based on 802.1X, which is agnostic to the IP version used (unlike web-redirection gateway systems). Making a campus' eduroam network dual stack is a very viable early step.
o eduroam无线网络。Eduroam[Eduroam]是学术网络事实上的无线漫游系统，使用基于802.1X的身份验证，与使用的IP版本无关（与web重定向网关系统不同）。使校园的eduroam网络双堆栈是一个非常可行的早期步骤。
The general IPv6 deployment model in a campus enterprise will still follow the general principles described in this document. While the above early stage projects are commonly followed, these still require the campus to acquire IPv6 connectivity and address space from their NREN (or other provider in some parts of the world) and to enable IPv6 on the wire on at least part of the core of the campus network. This implies a requirement to have an initial address plan, and to ensure appropriate monitoring and security measures are in place, as described elsewhere in this document.
校园企业中的通用IPv6部署模型仍将遵循本文档中描述的一般原则。虽然通常遵循上述早期项目，但这些项目仍然要求校园从其NREN（或世界某些地区的其他提供商）获取IPv6连接和地址空间，并在校园网络的至少部分核心上启用有线IPv6。这意味着需要有一个初始地址计划，并确保适当的监控和安全措施到位，如本文件其他部分所述。
Campuses that have deployed to date do not use ULAs, nor do they use NPTv6. In general, campuses have very stable PA-based address allocations from their NRENs (or their equivalent). However, campus enterprises may consider applying for IPv6 PI; some have already done so. The discussions earlier in this text about PA vs. PI still apply.
迄今为止已部署的校园不使用ULA，也不使用NPTv6。一般来说，校园有非常稳定的基于PA的地址分配，从他们的NREN（或他们的等效物）。然而，校园企业可能会考虑申请IPv6 PI；有些已经这样做了。本文前面关于PA与PI的讨论仍然适用。
Finally, campuses may be more likely than many other enterprises to run multicast applications, such as IP TV or live lecture or seminar streaming, so they may wish to consider support for specific IPv6 multicast functionality, e.g., the Embedded Rendezvous Point
最后，校园可能比许多其他企业更可能运行多播应用，如IP电视或直播讲座或研讨会流，因此他们可能希望考虑对特定IPv6组播功能的支持，例如嵌入式交会点。
(Embedded-RP) [RFC3956] in routers and MLDv1 and MLDv2 snooping in switches.
（嵌入式RP）[RFC3956]在路由器中，MLDv1和MLDv2在交换机中窥探。
This document has multiple security sections detailing with how to securely deploy an IPv6 network within an enterprise network.
本文档有多个安全部分，详细介绍如何在企业网络中安全部署IPv6网络。
[CYMRU] Team CYMRU Community Services, "THE BOGON REFERENCE", Version 7, April 2012, <http://www.team-cymru.org/Services/Bogons/>.
[CYMRU]CYMRU社区服务团队，“BOGON参考”，第7版，2012年4月<http://www.team-cymru.org/Services/Bogons/>.
[DHCPv6-SLAAC-PROBLEM] Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", Work in Progress, draft-liu-bonica-dhcpv6-slaac-problem-02, September 2013.
[DHCPv6 SLAAC问题]Liu，B.和R.Bonica，“DHCPv6/SLAAC地址配置交互问题声明”，正在进行的工作，草稿-Liu-Bonica-DHCPv6-SLAAC-PROBLEM-022013年9月。
[DIVI] Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-Stateless IPv4/IPv6 Translation", Work in Progress, draft-xli-behave-divi-06, January 2014.
[DIVI]Bao，C.，Li，X.，翟，Y.，和W.Shang，“DIVI：双无状态IPv4/IPv6转换”，正在进行的工作，草稿-xli-behave-DIVI-062014年1月。
[EDUROAM] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam architecture for network roaming", Work in Progress, draft-wierenga-ietf-eduroam-04, August 2014.
[EDUROAM]Wierenga，K.，Winter，S.，和T.Wolniewicz，“网络漫游的EDUROAM架构”，正在进行的工作，草稿-Wierenga-ietf-EDUROAM-042014年8月。
[HOST-SCANNING] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, draft-ietf-opsec-ipv6-host-scanning-04, June 2014.
[主机扫描]Gont，F.和T.Chown，“IPv6网络中的网络侦察”，正在进行的工作，草稿-ietf-opsec-IPv6-HOST-SCANNING-042014年6月。
[IPv6-DC] Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin, "IPv6 Operational Guidelines for Datacenters", Work in Progress, draft-ietf-v6ops-dc-ipv6-01, February 2014.
[IPv6 DC]Lopez，D.，Chen，Z.，Tsou，T.，Zhou，C.，和A.Servin，“数据中心的IPv6操作指南”，正在进行的工作，草稿-ietf-v6ops-DC-IPv6-01，2014年2月。
[IPv6-DESIGN] Matthews, P. and V. Kuarsingh, "Design Choices for IPv6 Networks", Work in Progress, draft-ietf-v6ops-design-choices-02, September 2014.
[IPv6设计]Matthews，P.和V.Kuarsingh，“IPv6网络的设计选择”，正在进行的工作，草稿-ietf-v6ops-DESIGN-Choices-022014年9月。
[IPv6-SECURITY] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", Work in Progress, draft-ietf-opsec-v6-04, October 2013.
[IPv6安全性]Chittimaneni，K.，Kaeo，M.，和E.Vyncke，“IPv6网络的运营安全考虑”，正在进行的工作，草案-ietf-opsec-v6-042013年10月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC0826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月<http://www.rfc-editor.org/info/rfc826>.
[RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", RFC 1687, August 1994, <http://www.rfc-editor.org/info/rfc1687>.
[RFC1687]Fleischman，E.，“大型企业用户对IPng的看法”，RFC1687，1994年8月<http://www.rfc-editor.org/info/rfc1687>.
[RFC1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, August 1995, <http://www.rfc-editor.org/info/rfc1817>.
[RFC1817]Rekhter，Y.，“CIDR和分级路由”，RFC18171995年8月<http://www.rfc-editor.org/info/rfc1817>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996, <http://www.rfc-editor.org/info/rfc2011>.
[RFC2011]McCloghrie，K.，“使用SMIv2的互联网协议SNMPv2管理信息库”，RFC 2011，1996年11月<http://www.rfc-editor.org/info/rfc2011>.
[RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997, <http://www.rfc-editor.org/info/rfc2096>.
[RFC2096]Baker，F.，“IP转发表MIB”，RFC 2096，1997年1月<http://www.rfc-editor.org/info/rfc2096>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月<http://www.rfc-editor.org/info/rfc2827>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 33151003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004, <http://www.rfc-editor.org/info/rfc3956>.
[RFC3956]Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，RFC 39562004年11月<http://www.rfc-editor.org/info/rfc3956>.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月<http://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月<http://www.rfc-editor.org/info/rfc3972>.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005, <http://www.rfc-editor.org/info/rfc4038>.
[RFC4038]Shin，M-K.，Hong，Y-G.，Hagino，J.，Savola，P.，和E.Castro，“IPv6过渡的应用方面”，RFC 4038，2005年3月<http://www.rfc-editor.org/info/rfc4038>.
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005, <http://www.rfc-editor.org/info/rfc4057>.
[RFC4057]Bound，J.，“IPv6企业网络场景”，RFC 4057，2005年6月<http://www.rfc-editor.org/info/rfc4057>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月<http://www.rfc-editor.org/info/rfc4193>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月<http://www.rfc-editor.org/info/rfc4213>.
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006, <http://www.rfc-editor.org/info/rfc4292>.
[RFC4292]Haberman，B.，“IP转发表MIB”，RFC 42922006年4月<http://www.rfc-editor.org/info/rfc4292>.
[RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006, <http://www.rfc-editor.org/info/rfc4293>.
[RFC4293]Routhier，S.，“互联网协议（IP）的管理信息库”，RFC 4293，2006年4月<http://www.rfc-editor.org/info/rfc4293>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月<http://www.rfc-editor.org/info/rfc4364>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月<http://www.rfc-editor.org/info/rfc4443>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006, <http://www.rfc-editor.org/info/rfc4659>.
[RFC4659]De Clercq，J.，Ooms，D.，Carugi，M.，和F.Le Faucheur，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 46592006年9月<http://www.rfc-editor.org/info/rfc4659>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007, <http://www.rfc-editor.org/info/rfc4890>.
[RFC4890]Davies，E.和J.Mohacsi，“防火墙中过滤ICMPv6消息的建议”，RFC 48902007年5月<http://www.rfc-editor.org/info/rfc4890>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月<http://www.rfc-editor.org/info/rfc4941>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007, <http://www.rfc-editor.org/info/rfc5095>.
[RFC5095]Abley，J.，Savola，P.，和G.Neville Neil，“IPv6中0型路由头的弃用”，RFC 5095，2007年12月<http://www.rfc-editor.org/info/rfc5095>.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008, <http://www.rfc-editor.org/info/rfc5157>.
[RFC5157]Chown，T.，“IPv6对网络扫描的影响”，RFC 5157，2008年3月<http://www.rfc-editor.org/info/rfc5157>.
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008, <http://www.rfc-editor.org/info/rfc5211>.
[RFC5211]Curran，J.，“互联网转型计划”，RFC 52112008年7月<http://www.rfc-editor.org/info/rfc5211>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008, <http://www.rfc-editor.org/info/rfc5214>.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月<http://www.rfc-editor.org/info/rfc5214>.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment Considerations", RFC 5375, December 2008, <http://www.rfc-editor.org/info/rfc5375>.
[RFC5375]Van de Velde，G.，Popoviciu，C.，Chown，T.，Bonness，O.，和C.Hahn，“IPv6单播地址分配注意事项”，RFC 53752008年12月<http://www.rfc-editor.org/info/rfc5375>.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009, <http://www.rfc-editor.org/info/rfc5722>.
[RFC5722]Krishnan，S.，“重叠IPv6片段的处理”，RFC 5722，2009年12月<http://www.rfc-editor.org/info/rfc5722>.
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010, <http://www.rfc-editor.org/info/rfc5798>.
[RFC5798]Nadas，S.，“IPv4和IPv6的虚拟路由器冗余协议（VRRP）第3版”，RFC 5798，2010年3月<http://www.rfc-editor.org/info/rfc5798>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月<http://www.rfc-editor.org/info/rfc5952>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月<http://www.rfc-editor.org/info/rfc6052>.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011, <http://www.rfc-editor.org/info/rfc6104>.
[RFC6104]Chown，T.和S.Venaas，“流氓IPv6路由器广告问题声明”，RFC 61042011年2月<http://www.rfc-editor.org/info/rfc6104>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011, <http://www.rfc-editor.org/info/rfc6105>.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 61052011年2月<http://www.rfc-editor.org/info/rfc6105>.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010, <http://www.rfc-editor.org/info/rfc6106>.
[RFC6106]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 61062010年11月<http://www.rfc-editor.org/info/rfc6106>.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011, <http://www.rfc-editor.org/info/rfc6144>.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC 61442011年4月<http://www.rfc-editor.org/info/rfc6144>.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP转换算法”，RFC61452011年4月<http://www.rfc-editor.org/info/rfc6145>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月<http://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011, <http://www.rfc-editor.org/info/rfc6147>.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月<http://www.rfc-editor.org/info/rfc6147>.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, April 2011, <http://www.rfc-editor.org/info/rfc6164>.
[RFC6164]Kohno，M.，Nitzan，B.，Bush，R.，Matsuzaki，Y.，Colitti，L.，和T.Narten，“在路由器间链路上使用127位IPv6前缀”，RFC 61642011年4月<http://www.rfc-editor.org/info/rfc6164>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, March 2011, <http://www.rfc-editor.org/info/rfc6177>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, March 2011, <http://www.rfc-editor.org/info/rfc6177>.translate error, please retry
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011, <http://www.rfc-editor.org/info/rfc6192>.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011, <http://www.rfc-editor.org/info/rfc6192>.translate error, please retry
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 62962011年6月<http://www.rfc-editor.org/info/rfc6296>.
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011, <http://www.rfc-editor.org/info/rfc6302>.
[RFC6302]Durand，A.，Gashinsky，I.，Lee，D.，和S.Sheppard，“面向互联网服务器的日志记录建议”，BCP 162，RFC 6302，2011年6月<http://www.rfc-editor.org/info/rfc6302>.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011, <http://www.rfc-editor.org/info/rfc6434>.
[RFC6434]Jankiewicz，E.，Loughney，J.和T.Narten，“IPv6节点要求”，RFC 64342011年12月<http://www.rfc-editor.org/info/rfc6434>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 65552012年4月<http://www.rfc-editor.org/info/rfc6555>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012, <http://www.rfc-editor.org/info/rfc6583>.
[RFC6583]Gashinsky，I.，Jaeggli，J.，和W.Kumari，“操作邻居发现问题”，RFC 65832012年3月<http://www.rfc-editor.org/info/rfc6583>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月<http://www.rfc-editor.org/info/rfc6724>.
[RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", RFC 6866, February 2013, <http://www.rfc-editor.org/info/rfc6866>.
[RFC6866]Carpenter，B.和S.Jiang，“企业网络中使用静态地址重新编号IPv6主机的问题声明”，RFC 6866，2013年2月<http://www.rfc-editor.org/info/rfc6866>.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013, <http://www.rfc-editor.org/info/rfc6879>.
[RFC6879]Jiang，S.，Liu，B.和B.Carpenter，“IPv6企业网络重新编号方案、注意事项和方法”，RFC 6879，2013年2月<http://www.rfc-editor.org/info/rfc6879>.
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content Providers and Application Service Providers", RFC 6883, March 2013, <http://www.rfc-editor.org/info/rfc6883>.
[RFC6883]Carpenter，B.和S.Jiang，“互联网内容提供商和应用服务提供商的IPv6指南”，RFC 68832013年3月<http://www.rfc-editor.org/info/rfc6883>.
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address Validation Improvement (SAVI) Threat Scope", RFC 6959, May 2013, <http://www.rfc-editor.org/info/rfc6959>.
[RFC6959]McPherson，D.，Baker，F.，和J.Halpern，“源地址验证改进（SAVI）威胁范围”，RFC 69592013年5月<http://www.rfc-editor.org/info/rfc6959>.
[RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 6964, May 2013, <http://www.rfc-editor.org/rfc/rfc6964.txt>.
[RFC6964]Templin，F.“使用站点内自动隧道寻址协议（ISATAP）在IPv4站点中部署IPv6的操作指南”，RFC 6964，2013年5月<http://www.rfc-editor.org/rfc/rfc6964.txt>.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7011]Claise，B.，Trammell，B.，和P.Aitken，“流量信息交换的IP流量信息导出（IPFIX）协议规范”，STD 77，RFC 7011，2013年9月<http://www.rfc-editor.org/info/rfc7011>.
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013, <http://www.rfc-editor.org/info/rfc7012>.
[RFC7012]Claise，B.和B.Trammell，“IP流信息导出（IPFIX）的信息模型”，RFC 7012，2013年9月<http://www.rfc-editor.org/info/rfc7012>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, December 2013, <http://www.rfc-editor.org/info/rfc7045>.
[RFC7045]Carpenter，B.和S.Jiang，“IPv6扩展头的传输和处理”，RFC 70452013年12月<http://www.rfc-editor.org/info/rfc7045>.
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, February 2014, <http://www.rfc-editor.org/info/rfc7113>.
[RFC7113]Gont，F.“IPv6路由器广告防护（RA防护）的实施建议”，RFC 7113，2014年2月<http://www.rfc-editor.org/info/rfc7113>.
[RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on IPv4 Networks", RFC 7123, February 2014, <http://www.rfc-editor.org/info/rfc7123>.
[RFC7123]Gont，F.和W.Liu，“IPv6对IPv4网络的安全影响”，RFC 7123，2014年2月<http://www.rfc-editor.org/info/rfc7123>.
[RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, August 2014, <http://www.rfc-editor.org/info/rfc7359>.
[RFC7359]Gont，F.，“双堆栈主机/网络中的第3层虚拟专用网络（VPN）隧道流量泄漏”，RFC 7359，2014年8月<http://www.rfc-editor.org/info/rfc7359>.
[SMURF] The Cert Division of the Software Engineering Institute, "Smurf IP Denial-of-Service Attacks", CERT Advisory CA-1998-01, March 2000, <http://www.cert.org/advisories/CA-1998-01.html>.
[SMURF]软件工程研究所的Cert部门，“SMURF IP拒绝服务攻击”，Cert咨询CA-1998-01，2000年3月<http://www.cert.org/advisories/CA-1998-01.html>.
[ULA-USAGE] Liu, B. and S. Jiang, "Considerations of Using Unique Local Addresses", Work in Progress, draft-ietf-v6ops-ula-usage-recommendations-03, July 2014.
[ULA-USAGE]Liu，B.和S.Jiang，“使用唯一本地地址的考虑”，正在进行的工作，草稿-ietf-v6ops-ULA-USAGE-Recommensions-032014年7月。
Acknowledgements
致谢
The authors would like to thank Robert Sparks, Steve Hanna, Tom Taylor, Brian Haberman, Stephen Farrell, Chris Grundemann, Ray Hunter, Kathleen Moriarty, Benoit Claise, Brian Carpenter, Tina Tsou, Christian Jacquenet, and Fred Templin for their substantial comments and contributions.
作者要感谢Robert Sparks、Steve Hanna、Tom Taylor、Brian Haberman、Stephen Farrell、Chris Grundemann、Ray Hunter、Kathleen Moriarty、Benoit Claise、Brian Carpenter、Tina Tsou、Christian Jacquenet和Fred Templin的大量评论和贡献。
Authors' Addresses
作者地址
Kiran K. Chittimaneni Dropbox, Inc. 185 Berry Street, Suite 400 San Francisco, CA 94107 United States EMail: kk@dropbox.com
Kiran K. Chittimaneni Dropbox，公司185浆果街，套房400旧金山，CA 94107美国电子邮件：kk@dropbox.com
Tim Chown University of Southampton Highfield Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk
南安普顿南安普敦大学汉菲尔德郡SO17 17BJ提姆tjc@ecs.soton.ac.uk
Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 United States Phone: +1 703 345 3513 EMail: lee.howard@twcable.com
Lee Howard Time Warner有线电视13820美国弗吉尼亚州赫恩登日出谷大道20171电话：+1 703 345 3513电子邮件：Lee。howard@twcable.com
Victor Kuarsingh Dyn, Inc. 150 Dow Street Manchester, NH United States EMail: victor@jvknet.com
Victor Kuarsingh Dyn，Inc.美国新罕布什尔州曼彻斯特道街150号电子邮件：victor@jvknet.com
Yanick Pouffary Hewlett Packard 950 Route Des Colles Sophia-Antipolis 06901 France EMail: Yanick.Pouffary@hp.com
Yanick Pouffary Hewlett-Packard 950 Route Des Colles Sophia Antipolis 06901 France电子邮件：Yanick。Pouffary@hp.com
Eric Vyncke Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2 778 4677 EMail: evyncke@cisco.com
Eric Vyncke Cisco Systems De Kleetlaan 6a Diegem 1831比利时电话：+32 2 778 4677电子邮件：evyncke@cisco.com