Internet Engineering Task Force (IETF) V. Kuarsingh, Ed.
Request for Comments: 6782 Rogers Communications
Category: Informational L. Howard
ISSN: 2070-1721 Time Warner Cable
November 2012
Internet Engineering Task Force (IETF) V. Kuarsingh, Ed.
Request for Comments: 6782 Rogers Communications
Category: Informational L. Howard
ISSN: 2070-1721 Time Warner Cable
November 2012
Wireline Incremental IPv6
有线增量IPv6
Abstract
摘要
Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies.
全球运营商正处于准备或在其网络中部署IPv6的不同阶段。这些运营商经常面临与IPv6引入相关的困难挑战，以及与IPv4耗尽相关的挑战。运营商需要同时满足IPv6连接的需求，并继续支持IPv4地址供应停滞的旧式设备的IPv4连接。IPv6过渡将使大多数网络从仅IPv4环境过渡到IPv6主导环境，过渡期因运营商而异。本文档有助于为有线电视提供商提供一个框架，这些提供商面临着引入IPv6的挑战，同时利用定义明确且商用的IPv6过渡技术满足IPv4连接的传统需求。
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/rfc6782.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6782.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
2. Operator Assumptions ............................................4
3. Reasons and Considerations for a Phased Approach ................5
3.1. Relevance of IPv6 and IPv4 .................................6
3.2. IPv4 Resource Challenges ...................................6
3.3. IPv6 Introduction and Operational Maturity .................7
3.4. Service Management .........................................8
3.5. Suboptimal Operation of Transition Technologies ............8
3.6. Future IPv6 Network ........................................9
4. IPv6 Transition Technology Analysis .............................9
4.1. Automatic Tunneling Using 6to4 and Teredo .................10
4.2. Carrier-Grade NAT (NAT444) ................................10
4.3. 6rd .......................................................11
4.4. Native Dual Stack .........................................11
4.5. DS-Lite ...................................................12
4.6. NAT64 .....................................................12
5. IPv6 Transition Phases .........................................13
5.1. Phase 0 - Foundation ......................................13
5.1.1. Phase 0 - Foundation: Training .....................13
5.1.2. Phase 0 - Foundation: System Capabilities ..........14
5.1.3. Phase 0 - Foundation: Routing ......................14
5.1.4. Phase 0 - Foundation: Network Policy and Security ..15
5.1.5. Phase 0 - Foundation: Transition Architecture ......15
5.1.6. Phase 0 - Foundation: Tools and Management .........16
5.2. Phase 1 - Tunneled IPv6 ...................................16
5.2.1. 6rd Deployment Considerations ......................17
5.3. Phase 2 - Native Dual Stack ...............................19
5.3.1. Native Dual Stack Deployment Considerations ........20
5.4. Intermediate Phase for CGN ................................20
5.4.1. CGN Deployment Considerations ......................22
5.5. Phase 3 - IPv6-Only .......................................23
5.5.1. DS-Lite ............................................23
5.5.2. DS-Lite Deployment Considerations ..................24
5.5.3. NAT64 Deployment Considerations ....................25
6. Security Considerations ........................................26
7. Acknowledgements ...............................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................26
1. Introduction ....................................................4
2. Operator Assumptions ............................................4
3. Reasons and Considerations for a Phased Approach ................5
3.1. Relevance of IPv6 and IPv4 .................................6
3.2. IPv4 Resource Challenges ...................................6
3.3. IPv6 Introduction and Operational Maturity .................7
3.4. Service Management .........................................8
3.5. Suboptimal Operation of Transition Technologies ............8
3.6. Future IPv6 Network ........................................9
4. IPv6 Transition Technology Analysis .............................9
4.1. Automatic Tunneling Using 6to4 and Teredo .................10
4.2. Carrier-Grade NAT (NAT444) ................................10
4.3. 6rd .......................................................11
4.4. Native Dual Stack .........................................11
4.5. DS-Lite ...................................................12
4.6. NAT64 .....................................................12
5. IPv6 Transition Phases .........................................13
5.1. Phase 0 - Foundation ......................................13
5.1.1. Phase 0 - Foundation: Training .....................13
5.1.2. Phase 0 - Foundation: System Capabilities ..........14
5.1.3. Phase 0 - Foundation: Routing ......................14
5.1.4. Phase 0 - Foundation: Network Policy and Security ..15
5.1.5. Phase 0 - Foundation: Transition Architecture ......15
5.1.6. Phase 0 - Foundation: Tools and Management .........16
5.2. Phase 1 - Tunneled IPv6 ...................................16
5.2.1. 6rd Deployment Considerations ......................17
5.3. Phase 2 - Native Dual Stack ...............................19
5.3.1. Native Dual Stack Deployment Considerations ........20
5.4. Intermediate Phase for CGN ................................20
5.4.1. CGN Deployment Considerations ......................22
5.5. Phase 3 - IPv6-Only .......................................23
5.5.1. DS-Lite ............................................23
5.5.2. DS-Lite Deployment Considerations ..................24
5.5.3. NAT64 Deployment Considerations ....................25
6. Security Considerations ........................................26
7. Acknowledgements ...............................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................26
This document sets out to help wireline operators in planning their IPv6 deployments while ensuring continued support for IPv6-incapable consumer devices and applications. This document identifies which technologies can be used incrementally to transition from IPv4-only to an IPv6-dominant environment with support for Dual Stack operation. The end state or goal for most operators will be IPv6-only, but the path to this final state will depend heavily on the amount of legacy equipment resident in end networks and management of long-tail IPv4-only content. Although no single plan will work for all operators, options listed herein provide a baseline that can be included in many plans.
本文档旨在帮助有线运营商规划其IPv6部署，同时确保继续支持无法使用IPv6的消费设备和应用程序。本文档确定了可以增量使用哪些技术从仅IPv4过渡到支持双堆栈操作的IPv6主导环境。大多数运营商的最终状态或目标将仅为IPv6，但达到这一最终状态的路径将在很大程度上取决于驻留在终端网络中的遗留设备数量以及对长尾IPv4内容的管理。虽然没有一个单一的计划适用于所有运营商，但本文列出的选项提供了一个基线，可以包含在许多计划中。
This document is intended for wireline environments that include cable, DSL, and/or fiber as the access method to the end consumer. This document attempts to follow the principles laid out in [RFC6180], which provides guidance on using IPv6 transition mechanisms. This document will focus on technologies that enable and mature IPv6 within the operator's network, but it will also include a cursory view of IPv4 connectivity continuance. This document will focus on transition technologies that are readily available in off-the-shelf Customer Premises Equipment (CPE) devices and commercially available network equipment.
本文档适用于有线环境，包括电缆、DSL和/或光纤作为终端消费者的访问方法。本文档试图遵循[RFC6180]中列出的原则，其中提供了使用IPv6转换机制的指导。本文档将重点介绍在运营商网络中启用和成熟IPv6的技术，但也将简要介绍IPv4连接的连续性。本文件将重点介绍现成的客户场所设备（CPE）设备和商用网络设备中的过渡技术。
For the purposes of this document, the authors assume the following:
就本文件而言，作者假设如下：
- The operator is considering deploying IPv6 or is in the process of deploying IPv6.
- 运营商正在考虑部署IPv6或正在部署IPv6。
- The operator has a legacy IPv4 subscriber base that will continue to exist for a period of time.
- 运营商的传统IPv4用户群将在一段时间内继续存在。
- The operator will want to minimize the level of disruption to the existing and new subscribers.
- 运营商将希望将对现有和新用户的中断程度降至最低。
- The operator may also want to minimize the number of technologies and functions that are needed to mediate any given set of subscribers' flows (overall preference for native IP flows).
- 运营商还可能希望尽量减少调解任何给定用户流集所需的技术和功能的数量（总体上优先考虑本机IP流）。
- The operator is able to run Dual Stack in its own core network and is able to transition its own services to support IPv6.
- 运营商能够在自己的核心网络中运行双栈，并能够转换自己的服务以支持IPv6。
Based on these assumptions, an operator will want to utilize technologies that minimize the need to tunnel, translate, or mediate flows to help optimize traffic flow and lower the cost impacts of transition technologies. Transition technology selections should be made to mediate the non-dominant IP family flows and allow native routing (IPv4 and/or IPv6) to forward the dominant traffic whenever possible. This allows the operator to minimize the cost of IPv6 transition technologies by minimizing the transition technology deployment size.
基于这些假设，运营商将希望利用将隧道、转换或调解流量需求降至最低的技术，以帮助优化交通流并降低过渡技术的成本影响。应选择过渡技术来调解非主导IP系列流，并允许本机路由（IPv4和/或IPv6）尽可能转发主导流量。这使得运营商能够通过最小化过渡技术部署规模来最小化IPv6过渡技术的成本。
An operator may also choose to prefer more IPv6-focused models where the use of transition technologies is based on an effort to enable IPv6 at the base layer as soon as possible. Some operators may want to promote IPv6 early on in the deployment and have IPv6 traffic perform optimally from the outset. This desire would need to be weighed against the cost and support impacts of such a choice and the quality of experience offered to subscribers.
运营商也可以选择更侧重于IPv6的模式，其中过渡技术的使用基于尽快在基础层启用IPv6的努力。一些运营商可能希望在部署初期推广IPv6，并从一开始就让IPv6流量发挥最佳性能。这一愿望需要与此类选择的成本和支持影响以及向用户提供的体验质量进行权衡。
When faced with the challenges described in the introduction, operators may want to consider a phased approach when adding IPv6 to an existing subscriber base. A phased approach allows the operator to add in IPv6 while not ignoring legacy IPv4 connection requirements. Some of the main challenges the operator will face include the following:
当面对介绍中所描述的挑战时，运营商可能希望在向现有的用户基础添加IPv6时考虑分阶段的方法。分阶段的方法允许运营商在不忽略传统IPv4连接要求的情况下添加IPv6。运营商将面临的一些主要挑战包括：
- IPv4 exhaustion may occur long before all traffic is able to be delivered over IPv6, necessitating IPv4 address sharing.
- IPv4耗尽可能发生在所有流量能够通过IPv6传输之前很久，这就需要IPv4地址共享。
- IPv6 will pose operational challenges, since some of the software is quite new and has had short run time in large production environments and organizations are also not acclimatized to supporting IPv6 as a service.
- IPv6将带来运营挑战，因为一些软件是全新的，在大型生产环境中运行时间很短，而且企业也不适应支持IPv6即服务。
- Connectivity modes will move from IPv4-only to Dual Stack in the home, changing functional behaviors in the consumer network and increasing support requirements for the operator.
- 连接模式将从仅IPv4移动到家庭中的双堆栈，从而改变消费者网络中的功能行为，并增加对运营商的支持要求。
- Although IPv6 support on CPEs is a newer phenomenon, there is a strong push by operators and the industry as a whole to enable IPv6 on devices. As demand grows, IPv6 enablement will no longer be optional but will be necessary on CPEs. Documents like [RFC6540] provide useful tools in the short term to help vendors and implementors understand what "IPv6 support" means.
- 虽然CPE上的IPv6支持是一个较新的现象，但运营商和整个行业都在大力推动在设备上启用IPv6。随着需求的增长，IPv6启用将不再是可选的，而是CPE所必需的。像[RFC6540]这样的文档在短期内提供了有用的工具，帮助供应商和实施者理解“IPv6支持”的含义。
These challenges will occur over a period of time, which means that the operator's plans need to address the ever-changing requirements of the network and subscriber demand. Although phases will be presented in this document, not all operators may need to enable each discrete phase. It is possible that characteristics in individual networks may allow certain operators to skip or jump to various phases.
这些挑战将在一段时间内出现，这意味着运营商的计划需要满足不断变化的网络需求和用户需求。虽然本文件将介绍阶段，但并非所有操作员都需要启用每个离散阶段。个别网络的特性可能允许某些运营商跳过或跳转到不同的阶段。
The delivery of high-quality unencumbered Internet service should be the primary goal for operators. With the imminent exhaustion of IPv4, IPv6 will offer the highest quality of experience in the long term. Even though the operator may be focused on IPv6 delivery, it should be aware that both IPv4 and IPv6 will play a role in the Internet experience during transition. The Internet is made of many interconnecting systems, networks, hardware, software, and content sources -- all of which will support IPv6 at different rates.
运营商的首要目标应该是提供高质量的无障碍互联网服务。随着IPv4即将耗尽，IPv6将在长期内提供最高质量的体验。尽管运营商可能专注于IPv6交付，但应意识到IPv4和IPv6都将在过渡期间的互联网体验中发挥作用。互联网由许多互连系统、网络、硬件、软件和内容源组成，所有这些都将以不同的速率支持IPv6。
Many subscribers use older operating systems and hardware that support IPv4-only operation. Internet subscribers don't buy IPv4 or IPv6 connections; they buy Internet connections, which demand the need to support both IPv4 and IPv6 for as long as the subscriber's home network demands such support. The operator may be able to leverage one or the other protocol to help bridge connectivity on the operator's network, but the home network will likely demand both IPv4 and IPv6 for some time.
许多订户使用旧的操作系统和硬件，它们只支持IPv4操作。互联网用户不购买IPv4或IPv6连接；他们购买互联网连接，只要用户的家庭网络需要支持IPv4和IPv6，就需要支持IPv4和IPv6。运营商可能能够利用一种或另一种协议来帮助桥接运营商网络上的连接，但家庭网络可能会在一段时间内同时需要IPv4和IPv6。
Since connectivity to IPv4-only endpoints and/or content will remain common, IPv4 resource challenges are of key concern to operators. The lack of new IPv4 addresses for additional devices means that meeting the growth in demand of IPv4 connections in some networks will require address sharing.
由于到仅IPv4端点和/或内容的连接仍然很常见，IPv4资源挑战是运营商关注的关键问题。其他设备缺少新的IPv4地址，这意味着满足某些网络中IPv4连接需求的增长将需要地址共享。
Networks are growing at different rates, including those in emerging markets and established networks based on the proliferation of Internet-based services and devices. IPv4 address constraints will likely affect many, if not most, operators at some point, increasing the benefits of IPv6. IPv4 address exhaustion is a consideration when selecting technologies that rely on IPv4 to supply IPv6 services, such as 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures) [RFC5969]. Additionally, if native Dual Stack is considered by the operator, challenges related to IPv4 address exhaustion remain a concern.
网络正在以不同的速度增长，包括新兴市场和基于互联网的服务和设备激增的现有网络。IPv4地址限制可能会在某个时候影响许多（如果不是大多数的话）运营商，从而增加IPv6的好处。在选择依赖IPv4提供IPv6服务的技术时，IPv4地址耗尽是一个考虑因素，例如6rd（IPv4基础设施上的IPv6快速部署）[RFC5969]。此外，如果运营商考虑本机双堆栈，则与IPv4地址耗尽相关的挑战仍然是一个问题。
Some operators may be able to reclaim small amounts of IPv4 addresses through addressing efficiencies in the network, although this will have few lasting benefits to the network and will not meet longer-term connectivity needs. Secondary markets for IPv4 addresses have also begun to arise, but it's not well understood how this will complement overall demand for Internet growth. Address transfers will also be subject to market prices and transfer rules governed by the Regional Registries.
一些运营商可能能够通过网络中的寻址效率回收少量IPv4地址，尽管这对网络没有什么持久的好处，也无法满足长期的连接需求。IPv4地址的二级市场也开始兴起，但这将如何补充互联网增长的总体需求尚不清楚。地址转让也将受市场价格和区域注册管理的转让规则的约束。
The lack of new global IPv4 address allocations will therefore force operators to support some form of IPv4 address sharing and may impact technological options for transition once the operator runs out of new IPv4 addresses for assignment.
因此，缺乏新的全局IPv4地址分配将迫使运营商支持某种形式的IPv4地址共享，并且一旦运营商没有新的IPv4地址可供分配，可能会影响过渡的技术选项。
The introduction of IPv6 will require new operational practices. The IPv4 environment we have today was built over many years and matured by experience. Although many of these experiences are transferable from IPv4 to IPv6, new experience and practices specific to IPv6 will be needed.
IPv6的引入将需要新的操作实践。我们今天拥有的IPv4环境是经过多年构建的，并经过经验成熟。尽管这些经验中有许多可以从IPv4转移到IPv6，但仍需要IPv6特有的新经验和实践。
Engineering and operational staff will need to develop experience with IPv6. Inexperience may lead to early IPv6 deployment instability, and operators should consider this when selecting technologies for initial transition. Operators may not want to subject their mature IPv4 service to a "new IPv6" path initially while it may be going through growing pains. Dual Stack Lite (DS-Lite) [RFC6333] and NAT64 [RFC6146] are both technologies that require IPv6 to support connectivity to IPv4 endpoints or content over an IPv6-only access network.
工程和运营人员需要积累IPv6方面的经验。缺乏经验可能导致早期IPv6部署不稳定，运营商在选择初始过渡技术时应考虑这一点。运营商最初可能不想让其成熟的IPv4服务受制于“新的IPv6”路径，而它可能正在经历成长的痛苦。双栈Lite（DS Lite）[RFC6333]和NAT64[RFC6146]都是需要IPv6支持通过仅IPv6的访问网络连接到IPv4端点或内容的技术。
Further, some of these transition technologies are new and require refinement within running code. Deployment experience is required to expose bugs and stabilize software in production environments. Many supporting systems are also under development and have newly developed IPv6 functionality, including vendor implementations of DHCPv6, management tools, monitoring systems, diagnostic systems, and logging, along with other elements.
此外，其中一些转换技术是新的，需要在运行的代码中进行优化。在生产环境中暴露bug和稳定软件需要有部署经验。许多支持系统也在开发中，并具有新开发的IPv6功能，包括DHCPv6的供应商实现、管理工具、监控系统、诊断系统和日志以及其他元素。
Although the base technological capabilities exist to enable and run IPv6 in most environments, organizational experience is low. Until such time as each key technical member of an operator's organization can identify IPv6 and can understand its relevance to the IP service offering, how it operates, and how to troubleshoot it, the deployment needs to mature and may be subject to events that impact subscribers. This fact should not incline operators to delay their IPv6 deployment
尽管存在在大多数环境中启用和运行IPv6的基本技术能力，但组织经验不足。在运营商组织的每个关键技术成员能够识别IPv6并了解其与IP服务产品的相关性、其运行方式以及故障排除方法之前，部署需要成熟，并且可能会受到影响订户的事件的影响。这一事实不应使运营商推迟其IPv6部署
but should drive them to deploy IPv6 sooner, to gain much-needed experience before IPv6 is the only viable way to connect new hosts to the network.
但应该促使他们更快地部署IPv6，以便在IPv6成为将新主机连接到网络的唯一可行方式之前获得急需的经验。
It should also be noted that although many transition technologies may be new, and some code related to access environments may be new, there is a large segment of the networking fabric that has had IPv6 available for a long period of time and has had extended exposure in production. Operators may use this to their advantage by first enabling IPv6 in the core network and then working outward towards the subscriber edge.
还应注意的是，尽管许多过渡技术可能是新的，一些与访问环境相关的代码可能是新的，但网络结构中有很大一部分已经使用IPv6很长一段时间了，并且在生产中已经有了较长的曝光时间。运营商可以利用这一优势，首先在核心网络中启用IPv6，然后向订户边缘扩展。
Services are managed within most networks and are often based on the gleaning and monitoring of IPv4 addresses assigned to endpoints. Operators will need to address such management tools, troubleshooting methods, and storage facilities (such as databases) to deal with not only new address types containing 128-bit IPv6 addresses [RFC2460] but often both IPv4 and IPv6 at the same time. Examination of address types, and recording delegated prefixes along with single address assignments, will likely require additional development.
服务在大多数网络中进行管理，通常基于对分配给端点的IPv4地址的收集和监视。运营商需要解决此类管理工具、故障排除方法和存储设施（如数据库）问题，以便不仅处理包含128位IPv6地址[RFC2460]的新地址类型，而且通常同时处理IPv4和IPv6。检查地址类型，记录委托前缀以及单个地址分配，可能需要额外的开发。
With any Dual Stack service -- whether native, 6rd-based, DS-Lite, NAT64, or some other service -- two address families may need to be managed simultaneously to help provide the full Internet experience. This would indicate that IPv6 management is not just a simple add-in but needs to be well integrated into the service management infrastructure. In the early transition phases, it's quite likely that many systems will be missed, and that IPv6 services will go unmonitored and impairments will go undetected.
对于任何双栈服务（无论是本机、基于第6条的、DS Lite、NAT64还是其他服务），可能需要同时管理两个地址系列，以帮助提供完整的Internet体验。这将表明IPv6管理不仅仅是一个简单的插件，还需要很好地集成到服务管理基础架构中。在早期过渡阶段，很可能会错过许多系统，IPv6服务将不受监控，损害将不被发现。
These issues may be worthy of consideration when selecting technologies that require IPv6 as the base protocol to deliver IPv4 connectivity. Instability of the IPv6 service in such a case would impact IPv4 services.
在选择需要IPv6作为基本协议以提供IPv4连接的技术时，这些问题可能值得考虑。在这种情况下，IPv6服务的不稳定性会影响IPv4服务。
Native delivery of IPv4 and IPv6 provides a solid foundation for delivery of Internet services to subscribers, since native IP paths are well understood and networks are often optimized to send such traffic efficiently. Transition technologies, however, may alter the normal path of traffic or reduce the path MTU, removing many network efficiencies built for native IP flows. Tunneling and translation devices may not be located on the most optimal path in line with the
IPv4和IPv6的本地交付为因特网服务提供给订户提供了坚实的基础，因为本地IP路径被很好地理解，并且网络经常被优化以有效地发送这样的业务。然而，过渡技术可能会改变正常的流量路径或减少路径MTU，从而降低为本机IP流构建的许多网络效率。隧道和平移设备可能不位于符合以下要求的最佳路径上：
natural traffic flow (based on route computation) and therefore may increase latency. These paths may also introduce additional points of failure.
自然交通流（基于路线计算），因此可能会增加延迟。这些路径还可能引入其他故障点。
Generally, the operator will want to deliver native IPv6 as soon as possible and utilize transition technologies only when required. Transition technologies may be used to provide continued access to IPv4 via tunneling and/or translation or may be used to deliver IPv6 connectivity. The delivery of Internet or internal services should be considered by the operator, since supplying connections using a transition technology will reduce overall performance for the subscriber.
通常，运营商希望尽快交付本机IPv6，并仅在需要时使用过渡技术。过渡技术可用于通过隧道和/或转换提供对IPv4的持续访问，或可用于提供IPv6连接。运营商应考虑提供互联网或内部服务，因为使用过渡技术提供连接将降低用户的总体性能。
When choosing between various transition technologies, operators should consider the benefits and drawbacks of each option. Some technologies, like Carrier-Grade NAT (CGN)/NAT444, utilize many existing addressing and management practices. Other options, such as DS-Lite and NAT64, remove the IPv4 addressing requirement to the subscriber premises device but require IPv6 to be operational and well supported.
当在各种过渡技术之间进行选择时，运营商应该考虑每个选项的优点和缺点。一些技术，如载波级NAT（CGN）/NAT444，利用了许多现有的寻址和管理实践。其他选项（如DS Lite和NAT64）取消了对订户前提设备的IPv4寻址要求，但要求IPv6能够运行并得到良好的支持。
An operator should also be aware that longer-term plans may include IPv6-only operation in all or much of the network. The IPv6-only operation may be complemented by technologies such as NAT64 for long-tail IPv4 content reach. This longer-term view may be distant to some but should be considered when planning out networks, addressing, and services. The needs and costs of maintaining two IP stacks will eventually become burdensome, and simplification will be desirable. Operators should plan for this state and not make IPv6 inherently dependent on IPv4, as this would unnecessarily constrain the network.
运营商还应意识到，长期计划可能包括在整个或大部分网络中只运行IPv6。仅限IPv6的操作可以通过NAT64等技术进行补充，以实现长尾IPv4内容覆盖。这一长期观点可能与某些人的观点相去甚远，但在规划网络、寻址和服务时应予以考虑。维护两个IP协议栈的需求和成本最终将变得繁重，简化将是可取的。运营商应针对这种状态进行规划，而不是让IPv6固有地依赖于IPv4，因为这将不必要地限制网络。
Other design considerations and guidelines for running an IPv6 network should also be considered by the operator. Guidance on designing an IPv6 network can be found in [IPv6-DESIGN] and [IPv6-ICP-ASP-GUIDANCE].
运营商还应考虑运行IPv6网络的其他设计注意事项和指南。有关设计IPv6网络的指南，请参见[IPv6设计]和[IPv6 ICP ASP指南]。
Operators should understand the main transition technologies for IPv6 deployment and IPv4 run-out. This document provides a brief description of some of the mainstream and commercially available options. This analysis is focused on the applicability of technologies to deliver residential services and less focused on commercial access, wireless, or infrastructure support.
运营商应了解IPv6部署和IPv4耗尽的主要过渡技术。本文档简要介绍了一些主流和商用选项。该分析侧重于提供住宅服务的技术的适用性，而较少关注商业接入、无线或基础设施支持。
This document focuses on those technologies that are commercially available and in deployment.
本文档重点介绍了商用和正在部署的技术。
Even when operators may not be actively deploying IPv6, automatic mechanisms exist on subscriber operating systems and CPE hardware. Such technologies include 6to4 [RFC3056], which is most commonly used with anycast relays [RFC3068]. Teredo [RFC4380] is also used widely by many Internet hosts.
即使运营商可能没有积极部署IPv6，订户操作系统和CPE硬件上也存在自动机制。此类技术包括6to4[RFC3056]，它最常用于选播继电器[RFC3068]。Teredo[RFC4380]也被许多互联网主机广泛使用。
Documents such as [RFC6343] have been written to help operators understand observed problems with 6to4 deployments and provide guidelines on how to improve their performance. An operator may want to provide local relays for 6to4 and/or Teredo to help improve the protocol's performance for ambient traffic utilizing these IPv6 connectivity methods. Experiences such as those described in [COMCAST-IPv6-EXPERIENCES] show that local relays have proved beneficial to 6to4 protocol performance.
编写了[RFC6343]等文档，以帮助运营商了解6to4部署中观察到的问题，并提供如何改进其性能的指南。运营商可能希望为6to4和/或Teredo提供本地中继，以帮助利用这些IPv6连接方法提高协议对环境流量的性能。[COMCAST-IPv6-Experiences]中所述的经验表明，本地中继已被证明有利于6to4协议的性能。
Operators should also be aware of breakage cases for 6to4 if non-[RFC1918] addresses are used within CGN/NAT444 zones. Many off-the-shelf CPEs and operating systems may turn on 6to4 without a valid return path to the originating (local) host. This particular use case can occur if any space other than [RFC1918] is used, including Shared Address Space [RFC6598] or space registered to another organization (squat space). The operator can use 6to4 Provider Managed Tunnels (6to4-PMT) [RFC6732] or attempt to block 6to4 operation entirely by blocking the anycast ranges associated with [RFC3068].
如果在CGN/NAT444区域内使用非[RFC1918]地址，操作员还应注意6to4的破损情况。许多现成的CPE和操作系统可能会在没有到原始（本地）主机的有效返回路径的情况下打开6to4。如果使用[RFC1918]以外的任何空间，包括共享地址空间[RFC6598]或注册到另一个组织的空间（深蹲空间），则可能会出现此特定用例。操作员可以使用6to4提供商管理的隧道（6to4 PMT）[RFC6732]或尝试通过阻止与[RFC3068]关联的选播范围来完全阻止6to4操作。
Carrier-Grade NAT (CGN), specifically as deployed in a NAT444 scenario [CGN-REQS], may prove beneficial for those operators who offer Dual Stack services to subscriber endpoints once they exhaust their pools of IPv4 addresses. CGNs, and address sharing overall, are known to cause certain challenges for the IPv4 service [RFC6269] [NAT444-IMPACTS] but may be necessary, depending on how an operator has chosen to deal with IPv6 transition and legacy IPv4 connectivity requirements.
运营商级NAT（CGN），特别是在NAT444方案[CGN-REQS]中部署的，可能对那些在耗尽IPv4地址池后向订户端点提供双堆栈服务的运营商有利。众所周知，CGN和地址共享会对IPv4服务[RFC6269][NAT444-IMPACTS]造成某些挑战，但可能是必要的，这取决于运营商选择如何处理IPv6过渡和传统IPv4连接要求。
In a network where IPv4 address availability is low, CGN/NAT444 may provide continued access to IPv4 endpoints. Some of the advantages of using CGN/NAT444 include similarities in provisioning and
在IPv4地址可用性较低的网络中，CGN/NAT444可以提供对IPv4端点的持续访问。使用CGN/NAT444的一些优点包括在资源调配和配置方面的相似性
activation models. IPv4 hosts in a CGN/NAT444 deployment will likely inherit the same addressing and management procedures as legacy IPv4 globally addressed hosts (i.e., DHCPv4, DNS (v4), TFTP, TR-069, etc.).
激活模型。CGN/NAT444部署中的IPv4主机可能会继承与传统IPv4全局寻址主机（即DHCPv4、DNS（v4）、TFTP、TR-069等）相同的寻址和管理过程。
6rd [RFC5969] provides a way of offering IPv6 connectivity to subscriber endpoints when native IPv6 addressing on the access network is not yet possible. 6rd provides tunneled connectivity for IPv6 over the existing IPv4 path. As the access edge is upgraded and subscriber premises equipment is replaced, 6rd can be replaced by native IPv6 connectivity. 6rd can be delivered on top of a CGN/ NAT444 deployment, but this would cause all traffic to be subject to some type of transition technology.
第6rd[RFC5969]提供了一种在接入网络上无法进行本机IPv6寻址时向订户端点提供IPv6连接的方法。6rd通过现有IPv4路径为IPv6提供隧道连接。随着接入边缘的升级和用户场所设备的更换，6rd可以被本机IPv6连接取代。6rd可以在CGN/NAT444部署的基础上交付，但这会导致所有流量都受到某种类型的转换技术的影响。
6rd may also be advantageous during the early transition period while IPv6 traffic volumes are low. During this period, the operator can gain experience with IPv6 in the core network and improve the operator's peering framework to match those of the IPv4 service. 6rd scales by adding relays to the operator's network. Another advantage of 6rd is that the operator does not need a DHCPv6 address assignment infrastructure and does not need to support IPv6 routing to the CPE to support a delegated prefix (as it's derived from the IPv4 address and other configuration parameters).
在IPv6通信量较低的早期过渡期，第6rd也可能是有利的。在此期间，运营商可以获得在核心网络中使用IPv6的经验，并改进运营商的对等框架以匹配IPv4服务。第6条通过向运营商网络添加继电器来实现规模。6rd的另一个优点是，运营商不需要DHCPv6地址分配基础设施，也不需要支持到CPE的IPv6路由以支持委派前缀（因为它源自IPv4地址和其他配置参数）。
Client support is required for 6rd operation and may not be available on deployed hardware. 6rd deployments may require the subscriber or operator to replace the CPE. 6rd will also require parameter configuration that can be powered by the operator through DHCPv4, manually provisioned on the CPE, or automatically provisioned through some other means. Manual provisioning would likely limit deployment scale.
第6次操作需要客户端支持，在部署的硬件上可能不可用。第六次部署可能需要用户或运营商更换CPE。6rd还需要参数配置，该参数配置可由操作员通过DHCPv4供电、在CPE上手动设置或通过某些其他方式自动设置。手动资源调配可能会限制部署规模。
Native Dual Stack is often referred to as the "gold standard" of IPv6 and IPv4 delivery. It is a method of service delivery that is already used in many existing IPv6 deployments. Native Dual Stack does, however, require that native IPv6 be delivered through the access network to the subscriber premises. This technology option is desirable in many cases and can be used immediately if the access network and subscriber premises equipment support native IPv6.
本机双栈通常被称为IPv6和IPv4交付的“黄金标准”。它是一种服务交付方法，已在许多现有IPv6部署中使用。然而，本机双栈确实要求本机IPv6通过接入网络传送到订户的场所。此技术选项在许多情况下都是可取的，并且如果接入网络和用户场所设备支持本机IPv6，则可以立即使用。
An operator who runs out of IPv4 addresses to assign to subscribers will not be able to provide traditional native Dual Stack connectivity for new subscribers. In Dual Stack deployments where sufficient IPv4 addresses are not available, CGN/NAT444 can be used on the IPv4 path.
没有IPv4地址分配给订阅者的运营商将无法为新订阅者提供传统的本机双堆栈连接。在没有足够IPv4地址的双堆栈部署中，可以在IPv4路径上使用CGN/NAT444。
Delivering native Dual Stack would require the operator's core and access networks to support IPv6. Other systems, like DHCP, DNS, and diagnostic/management facilities, need to be upgraded to support IPv6 as well. The upgrade of such systems may often be non-trivial and costly.
提供本机双栈需要运营商的核心和接入网络支持IPv6。其他系统，如DHCP、DNS和诊断/管理设施，也需要升级以支持IPv6。此类系统的升级通常可能非常繁琐且成本高昂。
DS-Lite [RFC6333] is based on a native IPv6 connection model where IPv4 services are supported. DS-Lite provides tunneled connectivity for IPv4 over the IPv6 path between the subscriber's network device and a provider-managed gateway (Address Family Transition Router (AFTR)).
DS Lite[RFC6333]基于支持IPv4服务的本机IPv6连接模型。DS Lite通过IPv6路径在订户的网络设备和提供商管理的网关（地址系列转换路由器（AFTR））之间为IPv4提供隧道连接。
DS-Lite can only be used where there is a native IPv6 connection between the AFTR and the CPE. This may mean that the technology's use may not be viable during early transition if the core or access network lacks IPv6 support. During the early transition period, a significant amount of content and services may by IPv4-only. Operators may be sensitive to this and may not want the newer IPv6 path to be the only bridge to IPv4 at that time, given the potential impact. The operator may also want to make sure that most of its internal services and a significant amount of external content are available over IPv6 before deploying DS-Lite. The availability of services on IPv6 would help lower the demand on the AFTRs.
DS Lite只能在AFTR和CPE之间存在本机IPv6连接的情况下使用。这可能意味着，如果核心网络或接入网络缺少IPv6支持，那么在早期过渡期间，该技术的使用可能不可行。在早期过渡期间，大量内容和服务可能仅通过IPv4提供。考虑到潜在影响，运营商可能对此很敏感，可能不希望较新的IPv6路径成为当时连接IPv4的唯一桥梁。在部署DS-Lite之前，运营商可能还希望确保其大部分内部服务和大量外部内容通过IPv6可用。IPv6上服务的可用性将有助于降低对AFTR的需求。
By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444, DS-Lite can facilitate continued support of legacy IPv4 services even after IPv4 address run-out. There are some functional considerations to take into account with DS-Lite, such as those described in [NAT444-IMPACTS] and in [DSLITE-DEPLOYMENT].
通过在多个端点（如CGN/NAT444）之间共享IPv4地址，DS-Lite可以帮助在IPv4地址用完后继续支持传统IPv4服务。DS Lite需要考虑一些功能方面的考虑，如[NAT444-IMPACTS]和[DSLITE-DEPLOYMENT]中所述。
DS-Lite requires client support on the CPE to function. The ability to utilize DS-Lite will be dependent on the operator providing DS-Lite-capable CPEs or retail availability of the supported client for subscriber-acquired endpoints.
DS Lite需要CPE上的客户端支持才能正常工作。利用DS-Lite的能力将取决于运营商是否提供支持DS-Lite的CPE，或受支持客户端对用户获取的端点的零售可用性。
NAT64 [RFC6146] provides the ability to connect IPv6-only connected clients and hosts to IPv4 servers without any tunneling. NAT64 requires that the host and home network support IPv6-only modes of
NAT64[RFC6146]提供了将仅IPv6连接的客户端和主机连接到IPv4服务器的能力，而无需任何隧道。NAT64要求主机和家庭网络仅支持IPv6模式
operation. Home networks do not commonly contain equipment that is 100% IPv6-capable. It is also not anticipated that common home networks will be ready for IPv6-only operation for a number of years. However, IPv6-only networking can be deployed by early adopters or highly controlled networks [RFC6586].
活动家庭网络通常不包含100%支持IPv6的设备。预计公共家庭网络在未来几年内也不会准备好只使用IPv6。但是，早期采用者或高度控制的网络可以部署仅限IPv6的网络[RFC6586]。
Viability of NAT64 will increase in wireline networks as consumer equipment is replaced by IPv6-capable versions. There are incentives for operators to move to IPv6-only operation, when feasible; these include the simplicity of a single-stack access network.
随着消费者设备被支持IPv6的版本所取代，NAT64在有线网络中的生存能力将提高。在可行的情况下，运营商有动机转向只使用IPv6的运营；其中包括单堆栈访问网络的简单性。
The phases described in this document are not provided as a rigid set of steps but are considered a guideline that should be analyzed by operators planning their IPv6 transition. Operators may choose to skip steps based on technological capabilities within their specific networks (residential/corporate, fixed/mobile), their business development perspectives (which may affect the pace of migration towards full IPv6), or a combination thereof.
本文档中描述的阶段不是作为一组严格的步骤提供的，而是作为指导方针，应由计划其IPv6过渡的运营商进行分析。运营商可根据其特定网络（住宅/公司、固定/移动）内的技术能力、其业务发展前景（可能影响向完整IPv6迁移的速度）或其组合选择跳过步骤。
The phases are based on the expectation that IPv6 traffic volume may initially be low, and operator staff will gain experience with IPv6 over time. As traffic volumes of IPv6 increase, IPv4 traffic volumes will decline (in percentage relative to IPv6), until IPv6 is the dominant address family used. Operators may want to keep the traffic flow for the dominant traffic class (IPv4 vs. IPv6) native to help manage costs related to transition technologies. The cost of using multiple technologies in succession to optimize each stage of the transition should also be compared against the cost of changing and upgrading subscriber connections.
这些阶段基于IPv6通信量最初可能较低的预期，运营商员工将随着时间的推移获得IPv6的经验。随着IPv6通信量的增加，IPv4通信量将下降（相对于IPv6的百分比），直到IPv6成为使用的主要地址系列。运营商可能希望将主要流量类别（IPv4与IPv6）的流量保持为本机流量，以帮助管理与过渡技术相关的成本。还应将连续使用多种技术优化每个过渡阶段的成本与更改和升级用户连接的成本进行比较。
Additional guidance and information on utilizing IPv6 transition mechanisms can be found in [RFC6180]. Also, guidance on incremental CGN for IPv6 transition can be found in [RFC6264].
有关利用IPv6转换机制的更多指导和信息，请参见[RFC6180]。此外，有关IPv6过渡的增量CGN的指导，请参见[RFC6264]。
Training is one of the most important steps in preparing an organization to support IPv6. Most people have little experience with IPv6, and many do not even have a solid grounding in IPv4. The implementation of IPv6 will likely produce many challenges due to immature code on hardware, and the evolution of many applications and systems to support IPv6. To properly deal with these impending or current challenges, organizations must train their staff on IPv6.
培训是组织准备支持IPv6的最重要步骤之一。大多数人对IPv6几乎没有经验，许多人甚至在IPv4方面没有坚实的基础。由于硬件上的代码不成熟，以及许多支持IPv6的应用程序和系统的发展，IPv6的实施可能会产生许多挑战。为了正确应对这些迫在眉睫或当前的挑战，企业必须对员工进行IPv6培训。
Training should also be provided within reasonable timelines from the actual IPv6 deployment. This means the operator needs to plan in advance as it trains the various parts of its organization. New technology and engineering staff often receive little training because of their depth of knowledge but must at least be provided opportunities to read documentation, architectural white papers, and RFCs. Operations personnel who support the network and other systems need to be trained closer to the deployment timeframes so that they immediately use their newfound knowledge before forgetting.
还应在实际部署IPv6后的合理时间内提供培训。这意味着运营商需要在培训其组织的各个部分时提前计划。由于知识的深度，新技术和工程人员通常很少接受培训，但至少必须有机会阅读文档、架构白皮书和RFC。支持网络和其他系统的操作人员需要在更接近部署时间的情况下接受培训，以便他们在忘记之前立即使用新发现的知识。
Subscriber support staff would require much more basic but large-scale training, since many organizations have massive call centers to support the subscriber base. Tailored training will also be required for marketing and sales staff to help them understand IPv6 and build it into the product development and sales process.
用户支持人员将需要更多基础但大规模的培训，因为许多组织都有大型呼叫中心来支持用户群。还需要为营销和销售人员提供量身定制的培训，以帮助他们了解IPv6并将其纳入产品开发和销售流程。
An important component with any IPv6 network architecture and implementation is the assessment of the hardware and operating capabilities of the deployed equipment (and software). The assessment needs to be conducted irrespective of how the operator plans to transition its network. The capabilities of the install base will, however, impact what technologies and modes of operation may be supported and therefore what technologies can be considered for the transition. If some systems do not meet the needs of the operator's IPv6 deployment and/or transition plan, the operator may need to plan for replacement and/or upgrade of those systems.
任何IPv6网络体系结构和实施的一个重要组成部分是对已部署设备（和软件）的硬件和操作能力的评估。无论运营商计划如何转换其网络，都需要进行评估。然而，install base的功能将影响可能支持的技术和操作模式，从而影响过渡可以考虑的技术。如果某些系统不能满足运营商IPv6部署和/或过渡计划的需要，运营商可能需要计划更换和/或升级这些系统。
The network infrastructure will need to be in place to support IPv6. This includes the routed infrastructure, along with addressing principles, routing principles, peering policy, and related network functions. Since IPv6 is quite different from IPv4 in several ways, including the number of addresses that are made available, careful attention to a scalable and manageable architecture is needed. One such change is the notion of a delegated prefix, which deviates from the common single-address phenomenon in IPv4-only deployments. Deploying prefixes per CPE can load the routing tables and require a routing protocol or route gleaning to manage connectivity to the subscriber's network. Delegating prefixes can be of specific importance in access network environments where downstream subscribers often move between access nodes, raising the concern of frequent renumbering and/or managing movement of routed prefixes within the network (common in cable-based networks).
网络基础设施需要到位以支持IPv6。这包括路由基础设施，以及寻址原则、路由原则、对等策略和相关网络功能。由于IPv6在几个方面与IPv4有很大的不同，包括可用的地址数量，因此需要仔细注意可扩展和可管理的体系结构。其中一个变化是委派前缀的概念，这与仅IPv4部署中常见的单地址现象不同。每个CPE部署前缀可以加载路由表，并需要路由协议或路由收集来管理与订户网络的连接。在下游用户经常在接入节点之间移动的接入网络环境中，授权前缀可能具有特殊重要性，这引起了对网络内路由前缀频繁重新编号和/或管理移动的关注（在基于电缆的网络中常见）。
Many, but not all, security policies will map easily from IPv4 to IPv6. Some new policies may be required for issues specific to IPv6 operation. This document does not highlight these specific issues but raises the awareness that they are to be taken into consideration and should be addressed when delivering IPv6 services. Other IETF documents, such as [RFC4942], [RFC6092], and [RFC6169], are excellent resources.
许多（但不是全部）安全策略可以轻松地从IPv4映射到IPv6。针对特定于IPv6操作的问题，可能需要一些新策略。本文档并未强调这些具体问题，但提高了人们的认识，即在提供IPv6服务时，应考虑并解决这些问题。其他IETF文档，如[RFC4942]、[RFC6092]和[RFC6169]都是优秀的资源。
Operators should plan out their transition architecture in advance (with room for flexibility) to help optimize how they will build out and scale their networks. Should operators consider multiple technologies, like CGN/NAT444, DS-Lite, NAT64, and 6rd, they may want to plan out where network resident equipment may be located and potentially choose locations that can be used for all functional roles (i.e., placement of a NAT44 translator, AFTR, NAT64 gateway, and 6rd relays). Although these functions are not inherently connected, additional management, diagnostic, and monitoring functions can be deployed alongside the transition hardware without the need to distribute these functions to an excessive or divergent number of locations.
运营商应提前规划其过渡架构（具有灵活性），以帮助优化其构建和扩展网络的方式。如果运营商考虑多种技术，如CGN/NAT44、DS-Lite、NAT64和第六，他们可能想规划出网络驻留设备可能位于何处，并潜在地选择可用于所有功能角色的位置（即，放置NAT44翻译器、AFTR、NAT64网关和第六个中继）。尽管这些功能没有固有的连接，但附加的管理、诊断和监控功能可以与过渡硬件一起部署，而无需将这些功能分配到过多或不同的位置。
This approach may also prove beneficial if traffic patterns change rapidly in the future, as operators may need to evolve their transition infrastructure faster than originally anticipated. One such example may be the movement from a CGN/NAT44 model (Dual Stack) to DS-Lite. Since both traffic sets require a translation function (NAT44), synchronized pool management, routing, and management system positioning can allow rapid movement (the technological means to re-provision the subscriber notwithstanding).
如果交通模式在未来快速变化，这种方法也可能被证明是有益的，因为运营商可能需要比最初预期更快地发展其过渡基础设施。一个这样的示例可能是从CGN/NAT44模型（双堆栈）到DS Lite的移动。由于这两个流量集都需要转换功能（NAT44），因此同步池管理、路由和管理系统定位可以允许快速移动（尽管有重新提供订户的技术手段）。
Operators should inform their vendors of what technologies they plan to support over the course of the transition to make sure the equipment is suited to support those modes of operation. This is important for both network gear and subscriber premises equipment.
运营商应告知其供应商他们计划在过渡过程中支持哪些技术，以确保设备适合支持这些操作模式。这对于网络设备和用户场所设备都很重要。
Operators should also plan their overall strategy to meet the target needs of an IPv6-only deployment. As traffic moves to IPv6, the benefits of only a single stack on the access network may eventually justify the removal of IPv4 for simplicity. Planning for this eventual model, no matter how far off this may be, will help operators embrace this end state when needed.
运营商还应规划其总体战略，以满足仅IPv6部署的目标需求。随着流量转移到IPv6，接入网络上只有一个堆栈的好处可能最终会证明为了简单起见删除IPv4是合理的。为这一最终模式进行规划，无论这可能有多远，都将有助于运营商在需要时接受这一最终状态。
The operator should thoroughly analyze all provisioning and management systems to develop requirements for each phase. This will include concepts related to the 128-bit IPv6 address, the notation of an assigned IPv6 prefix (Prefix Delegation), and the ability to detect either or both address families when determining if a subscriber has full Internet service.
运营商应彻底分析所有供应和管理系统，以制定每个阶段的需求。这将包括与128位IPv6地址相关的概念、指定IPv6前缀（前缀委派）的表示法，以及在确定订户是否拥有完整的Internet服务时检测其中一个或两个地址族的能力。
If an operator stores usage information, this would need to be aggregated to include both IPv4 and IPv6 information as both address families are assigned to the same subscriber. Tools that verify connectivity may need to query the IPv4 and IPv6 addresses.
如果运营商存储使用信息，则需要将其聚合以包括IPv4和IPv6信息，因为这两个地址族都分配给同一个订户。验证连接的工具可能需要查询IPv4和IPv6地址。
Tunneled access to IPv6 can be regarded as an early-stage transition option by operators. Many network operators can deploy native IPv6 from the access edge to the peering edge fairly quickly but may not be able to offer IPv6 natively to the subscriber edge device. During this period of time, tunneled access to IPv6 is a viable alternative to native IPv6. It is also possible that operators may be rolling out IPv6 natively to the subscriber edge, but the time involved may be long, due to logistics and other factors. Even while carefully rolling out native IPv6, operators can deploy relays for automatic tunneling technologies like 6to4 and Teredo. Where native IPv6 to the access edge is a longer-term project, operators can consider 6rd [RFC5969] as an option to offer in-home IPv6 access. Note that 6to4 and Teredo have different address selection [RFC6724] behaviors than 6rd. Additional guidelines on deploying and supporting 6to4 can be found in [RFC6343].
通过隧道接入IPv6可以被视为运营商的早期过渡选项。许多网络运营商可以相当快地将本机IPv6从接入边缘部署到对等边缘，但可能无法以本机方式向订户边缘设备提供IPv6。在此期间，对IPv6的隧道访问是本机IPv6的可行替代方案。运营商也有可能在订户边缘本地推出IPv6，但由于物流和其他因素，所涉及的时间可能很长。即使在谨慎推出本机IPv6的同时，运营商也可以为自动隧道技术（如6to4和Teredo）部署中继。如果本地IPv6对接入边缘是一个长期项目，运营商可以考虑将第六[RCF5969]作为在家庭IPv6接入中提供的选项。请注意，6to4和Teredo的地址选择[RFC6724]行为与6rd不同。有关部署和支持6to4的其他指南，请参见[RFC6343]。
The operator can deploy 6rd relays into the network and scale them as needed to meet the early subscriber needs of IPv6. Since 6rd requires the upgrade or replacement of CPE devices, the operator may want to ensure that the CPE devices support not just 6rd but native Dual Stack and other tunneling technologies, such as DS-Lite, if possible [IPv6-CE-RTR-REQS]. 6rd clients are becoming available in some retail channel products and within the original equipment manufacturer (OEM) market. Retail availability of 6rd is important, since not all operators control or have influence over what equipment is deployed in the consumer home network. The operator can support 6rd access with unmanaged devices using DHCPv4 Option 212 (OPTION_6RD) [RFC5969].
运营商可以在网络中部署第6个中继，并根据需要扩展它们，以满足IPv6的早期用户需求。由于6rd需要升级或更换CPE设备，运营商可能希望确保CPE设备不仅支持6rd，还支持本机双栈和其他隧道技术，如DS Lite，如果可能[IPv6 CE RTR要求]。在一些零售渠道产品和原始设备制造商（OEM）市场中，第六大客户正在变得可用。6rd的零售可用性很重要，因为并非所有运营商都控制或影响消费者家庭网络中部署的设备。操作员可以使用DHCPv4选项212（选项6rd）[RFC5969]支持非托管设备的第六次访问。
+--------+ -----
| | / \
Encap IPv6 Flow | 6rd | | IPv6 |
- - -> | Relay | <- > | Net |
+---------+ / | | \ /
| | / +--------+ -----
| 6rd + <----- -----
| | / \
| Client | IPv4 Flow | IPv4 |
| + < - - - - - - - - - - - - - - -> | Net |
| | \ /
+---------+ -----
+--------+ -----
| | / \
Encap IPv6 Flow | 6rd | | IPv6 |
- - -> | Relay | <- > | Net |
+---------+ / | | \ /
| | / +--------+ -----
| 6rd + <----- -----
| | / \
| Client | IPv4 Flow | IPv4 |
| + < - - - - - - - - - - - - - - -> | Net |
| | \ /
+---------+ -----
Figure 1: 6rd Basic Model
图1:6rd基本模型
6rd used as an initial transition technology also provides the added benefit of a deterministic IPv6 prefix based on the IPv4 assigned address. Many operational tools are available or have been built to identify what IPv4 (often dynamic) address was assigned to a subscriber CPE. So, a simple tool and/or method can be built to help identify the IPv6 prefix using the knowledge of the assigned IPv4 address.
用作初始转换技术的第6rd还提供了基于IPv4分配地址的确定性IPv6前缀的额外好处。许多操作工具可用于或已构建用于识别分配给订户CPE的IPv4（通常是动态）地址。因此，可以构建一个简单的工具和/或方法来帮助使用指定IPv4地址的知识识别IPv6前缀。
An operator may choose to not offer internal services over IPv6 if tunneled access to IPv6 is used, since some services generate a large amount of traffic. Such traffic may include video content, like IPTV. By limiting how much traffic is delivered over the 6rd connection (if possible), the operator can avoid costly and complex scaling of the relay infrastructure.
如果使用对IPv6的隧道访问，运营商可能会选择不通过IPv6提供内部服务，因为某些服务会产生大量流量。这种流量可以包括视频内容，如IPTV。通过限制通过第6次连接传输的流量（如果可能），运营商可以避免中继基础设施的成本高昂且复杂的扩展。
Deploying 6rd can greatly speed up an operator's ability to support IPv6 to the subscriber network if native IPv6 connectivity cannot be supplied. The speed at which 6rd can be deployed is highlighted in [RFC5569].
如果无法提供本机IPv6连接，部署6rd可以大大加快运营商支持IPv6到用户网络的能力。[RFC5569]中突出显示了6rd的部署速度。
The first core consideration is deployment models. 6rd requires the CPE (6rd client) to send traffic to a 6rd relay. These relays can share a common anycast address or can use unique addresses. Using an anycast model, the operator can deploy all the 6rd relays using the same IPv4 interior service address. As the load increases on the deployed relays, the operator can deploy more relays into the network. The one drawback is that it may be difficult to manage the traffic volume among additional relays, since all 6rd traffic will find the nearest (in terms of IGP cost) relay. The use of multiple relay addresses can help provide more control but has the disadvantage of being more complex to provision. Subsets of CPEs
第一个核心考虑是部署模型。第6rd要求CPE（第6rd客户端）向第6rd中继发送通信量。这些继电器可以共享公共选播地址，也可以使用唯一地址。通过使用选播模型，运营商可以使用相同的IPv4内部服务地址部署所有第6个中继。随着已部署继电器的负载增加，操作员可以将更多继电器部署到网络中。一个缺点是，可能很难管理额外中继之间的通信量，因为所有第6次通信都会找到最近的（就IGP成本而言）中继。使用多个中继地址有助于提供更多控制，但缺点是提供更复杂。CPE的子集
across the network will require and contain different relay information. An alternative approach is to use a hybrid model using multiple anycast service IP addresses for clusters of 6rd relays, should the operator anticipate massive scaling of the environment. Thus, the operator has multiple vectors by which to scale the service.
整个网络需要并包含不同的中继信息。另一种方法是，如果运营商预期环境会大规模扩展，则使用混合模型，为第6个中继集群使用多个选播服务IP地址。因此，运营商有多个向量来扩展服务。
+--------+
| |
IPv4 Addr.X | 6rd |
- - - > | Relay |
+-----------+ / | |
| Client A | <- - - +--------+
+-----------+
Separate IPv4 Service Addresses
+-----------+
| Client B | < - - +--------+
+-----------+ \ | |
- - - > | 6rd |
IPv4 Addr.Y | Relay |
| |
+--------+
+--------+
| |
IPv4 Addr.X | 6rd |
- - - > | Relay |
+-----------+ / | |
| Client A | <- - - +--------+
+-----------+
Separate IPv4 Service Addresses
+-----------+
| Client B | < - - +--------+
+-----------+ \ | |
- - - > | 6rd |
IPv4 Addr.Y | Relay |
| |
+--------+
Figure 2: 6rd Multiple IPv4 Service Address Model
图2:6rd多IPv4服务地址模型
+--------+
| |
IPv4 Addr.X | 6rd |
- - - > | Relay |
+-----------+ / | |
| Client A |- - - - +--------+
+-----------+
Common (Anycast) IPv4 Service Addresses
+-----------+
| Client B | - - - +--------+
+-----------+ \ | |
- - - > | 6rd |
IPv4 Addr.X | Relay |
| |
+--------+
+--------+
| |
IPv4 Addr.X | 6rd |
- - - > | Relay |
+-----------+ / | |
| Client A |- - - - +--------+
+-----------+
Common (Anycast) IPv4 Service Addresses
+-----------+
| Client B | - - - +--------+
+-----------+ \ | |
- - - > | 6rd |
IPv4 Addr.X | Relay |
| |
+--------+
Figure 3: 6rd Anycast IPv4 Service Address Model
图3:6rd选播IPv4服务地址模型
Provisioning of the 6rd endpoints is affected by the deployment model chosen (i.e., anycast vs. specific service IP addresses). Using multiple IP addresses may require more planning and management, as subscriber equipment will have different sets of data to be
第六个端点的配置受所选部署模型（即，选播与特定服务IP地址）的影响。使用多个IP地址可能需要更多的规划和管理，因为用户设备将有不同的数据集要处理
provisioned into the devices. The operator may use DHCPv4, manual provisioning, or other mechanisms to provide parameters to subscriber equipment.
配置到设备中。操作员可以使用DHCPv4、手动设置或其他机制向订户设备提供参数。
If the operator manages the CPE, support personnel will need tools able to report the status of the 6rd tunnel. Usage information can be collected on the operator edge, but if source/destination flow details are required, data must be collected after the 6rd relay (the IPv6 side of the connection).
如果操作员管理CPE，支持人员将需要能够报告第六隧道状态的工具。可以在运营商边缘收集使用信息，但如果需要源/目标流详细信息，则必须在第6次中继（连接的IPv6端）之后收集数据。
6rd [RFC5969], like any tunneling option, is subject to a reduced MTU, so operators need to plan to manage this type of environment.
第6rd[RFC5969]与任何隧道方案一样，MTU减少，因此运营商需要计划管理此类环境。
+---------+ IPv4 Encapsulation +------------+
| +- - - - - - - - - - - + |
| 6rd +----------------------+ 6rd +------------
| | IPv6 Packet | Relay | IPv6 Packet
| Client +----------------------+ +------------
| +- - - - - - - - - - - + | ^
+---------+ ^ +------------+ |
| |
| |
IPv4 (Tools/Mgmt) IPv6 Flow Analysis
+---------+ IPv4 Encapsulation +------------+
| +- - - - - - - - - - - + |
| 6rd +----------------------+ 6rd +------------
| | IPv6 Packet | Relay | IPv6 Packet
| Client +----------------------+ +------------
| +- - - - - - - - - - - + | ^
+---------+ ^ +------------+ |
| |
| |
IPv4 (Tools/Mgmt) IPv6 Flow Analysis
Figure 4: 6rd Tools and Flow Management
图4:6rd工具和流程管理
Either as a follow-up phase to "tunneled IPv6" or as an initial step, the operator may deploy native IPv6 down to the CPEs. This phase would then allow both IPv6 and IPv4 to be natively accessed by the subscriber home network without translation or tunneling. The native Dual Stack phase can be rolled out across the network while the tunneled IPv6 service remains operational, if used. As areas begin to support native IPv6, subscriber home equipment will generally prefer using the IPv6 addresses derived from the delegated IPv6 prefix versus tunneling options as defined in [RFC6724], such as 6to4 and Teredo. Specific care is needed when moving to native Dual Stack from 6rd, as documented in [6rd-SUNSETTING].
作为“隧道式IPv6”的后续阶段或作为初始步骤，运营商可以将本机IPv6部署到CPE。然后，该阶段将允许用户家庭网络以本机方式访问IPv6和IPv4，而无需转换或隧道。本机双栈阶段可以在整个网络中展开，而隧道式IPv6服务（如果使用）仍然可以运行。随着地区开始支持本机IPv6，订户家庭设备通常更喜欢使用从委派IPv6前缀派生的IPv6地址，而不是[RFC6724]中定义的隧道选项，如6to4和Teredo。如[6rd SUNSETTING]中所述，从第6rd移动到本机双堆栈时需要特别小心。
Native Dual Stack is the best option at this point in the transition and should be sought as soon as possible. During this phase, the operator can confidently move both internal and external services to IPv6. Since there are no translation devices needed for this mode of operation, it transports both protocols (IPv6 and IPv4) efficiently within the network.
本机双堆栈是过渡过程中此时的最佳选择，应尽快寻求。在此阶段，运营商可以放心地将内部和外部服务移动到IPv6。由于这种操作模式不需要翻译设备，因此它可以在网络中高效地传输两种协议（IPv6和IPv4）。
Native Dual Stack is a very desirable option for the IPv6 transition, if feasible. The operator must enable IPv6 on the network core and peering edge before attempting to turn on native IPv6 services. Additionally, provisioning and support systems such as DHCPv6, DNS, and other functions that support the subscriber's IPv6 Internet connection need to be in place.
如果可行的话，本机双栈是IPv6过渡的理想选择。在尝试打开本机IPv6服务之前，运营商必须在网络核心和对等边缘上启用IPv6。此外，还需要准备和支持系统，如DHCPv6、DNS和其他支持订阅者IPv6 Internet连接的功能。
The operator must treat IPv6 connectivity with the same operational importance as IPv4. A poor IPv6 service may be worse than not offering an IPv6 service at all, as it will negatively impact the subscriber's Internet experience. This may cause users or support personnel to disable IPv6, limiting the subscriber from the benefits of IPv6 connectivity as network performance improves. New code and IPv6 functionality may cause instability at first. The operator will need to monitor, troubleshoot, and resolve issues promptly.
运营商必须以与IPv4相同的操作重要性对待IPv6连接。糟糕的IPv6服务可能比根本不提供IPv6服务更糟糕，因为这将对用户的互联网体验产生负面影响。这可能会导致用户或支持人员禁用IPv6，随着网络性能的提高，订户将无法享受IPv6连接带来的好处。新代码和IPv6功能最初可能会导致不稳定。操作员需要及时监控、排除故障并解决问题。
Prefix assignment and routing are new for common residential services. Prefix assignment is straightforward (DHCPv6 using Identity Associations for Prefix Delegation (IA_PDs)), but installation and propagation of routing information for the prefix, especially during access layer instability, are often poorly understood. The operator should develop processes for renumbering subscribers who move to new access nodes.
前缀分配和路由是常见住宅服务的新功能。前缀分配很简单（DHCPv6使用标识关联进行前缀委派（IA_PDs）），但前缀路由信息的安装和传播，特别是在访问层不稳定期间，通常了解得很少。运营商应制定流程，对移动到新接入节点的订户重新编号。
Operators need to keep track of the dynamically assigned IPv4 address along with the IPv6 address and prefix. Any additional dynamic elements, such as auto-generated host names, need to be considered and planned for.
运营商需要跟踪动态分配的IPv4地址以及IPv6地址和前缀。需要考虑和规划任何其他动态元素，例如自动生成的主机名。
Acquiring more IPv4 addresses is already challenging, if not impossible; therefore, address sharing may be required on the IPv4 path of a Dual Stack deployment. The operator may have a preference to move directly to a transition technology such as DS-Lite [RFC6333] or may use Dual Stack with CGN/NAT444 to facilitate IPv4 connections.
获取更多的IPv4地址即使不是不可能，也是一项挑战；因此，在双堆栈部署的IPv4路径上可能需要地址共享。运营商可能倾向于直接转移到过渡技术，如DS Lite[RFC6333]，或者可以使用带有CGN/NAT444的双栈来促进IPv4连接。
CGN/NAT444 requires IPv4 addressing between the subscriber premises equipment and the operator's translator; this may be facilitated by shared addresses [RFC6598], private addresses [RFC1918], or another address space. CGN/NAT444 is only recommended to be used alongside
CGN/NAT444需要在订阅者楼宇设备和运营商的转换器之间进行IPv4寻址；共享地址[RFC6598]、专用地址[RFC1918]或其他地址空间可能有助于实现这一点。CGN/NAT444仅建议与
IPv6 in a Dual Stack deployment and not on its own. Figure 5 provides a comparative view of a traditional IPv4 path versus one that uses CGN/NAT444.
IPv6在双堆栈部署中，而不是单独部署。图5提供了传统IPv4路径与使用CGN/NAT444的IPv4路径的比较视图。
+--------+ -----
| | / \
IPv4 Flow | CGN | | |
- - -> + + < -> | |
+---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 |
|---------+ | Net |
| |
+---------+ IPv4 Flow | |
| CPE | <- - - - - - - - - - - - - - - > | |
|---------+ \ /
-----
+--------+ -----
| | / \
IPv4 Flow | CGN | | |
- - -> + + < -> | |
+---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 |
|---------+ | Net |
| |
+---------+ IPv4 Flow | |
| CPE | <- - - - - - - - - - - - - - - > | |
|---------+ \ /
-----
Figure 5: Overlay CGN Deployment
图5：覆盖CGN部署
In the case of native Dual Stack, CGN/NAT444 can be used to assist in extending connectivity for the IPv4 path while the IPv6 path remains native. For endpoints operating in an IPv6+CGN/NAT444 model, the native IPv6 path is available for higher-quality connectivity, helping host operation over the network. At the same time, the CGN path may offer less than optimal performance. These points are also true for DS-Lite.
在本机双堆栈的情况下，CGN/NAT444可用于帮助扩展IPv4路径的连接，同时IPv6路径保持本机。对于在IPv6+CGN/NAT444模式下运行的端点，本机IPv6路径可用于更高质量的连接，有助于主机在网络上运行。同时，CGN路径可能提供不太理想的性能。这几点对于DS Lite也是如此。
+--------+ -----
| | / \
IPv4 Flow | CGN | | IPv4 |
- - -> + + < -> | Net |
+---------+ / | | \ /
| | <- - - / +--------+ -------
| Dual |
| Stack | -----
| CPE | IPv6 Flow / IPv6 \
| | <- - - - - - - - - - - - - - - > | Net |
|---------+ \ /
-----
+--------+ -----
| | / \
IPv4 Flow | CGN | | IPv4 |
- - -> + + < -> | Net |
+---------+ / | | \ /
| | <- - - / +--------+ -------
| Dual |
| Stack | -----
| CPE | IPv6 Flow / IPv6 \
| | <- - - - - - - - - - - - - - - > | Net |
|---------+ \ /
-----
Figure 6: Dual Stack with CGN
图6：带有CGN的双堆栈
CGN/NAT444 deployments may make use of a number of address options, which include [RFC1918] or Shared Address Space [RFC6598]. It is also possible that operators may use part of their own Regional Internet Registry (RIR) assigned address space for CGN zone addressing if [RFC1918] addresses pose technical challenges in their
CGN/NAT444部署可以使用许多地址选项，包括[RFC1918]或共享地址空间[RFC6598]。如果[RFC1918]地址在运营过程中造成技术挑战，运营商也可能使用其自己的区域互联网注册（RIR）分配的部分地址空间进行CGN区域寻址
networks. It is not recommended that operators use 'squat space', as it may pose additional challenges with filtering and policy control [RFC6598].
网络。不建议操作员使用“蹲式空间”，因为这可能会对过滤和策略控制带来额外的挑战[RFC6598]。
CGN is often considered undesirable by operators but is required in many cases. An operator who needs to deploy CGN capabilities should consider the impacts of the function on the network. CGN is often deployed in addition to running IPv4 services and should not negatively impact the already working native IPv4 service. CGNs will be needed on a small scale at first and will grow to meet the demands based on traffic and connection dynamics of the subscriber, content, and network peers.
操作员通常认为CGN不可取，但在许多情况下需要CGN。一个需要部署CGN能力的操作员应该考虑函数对网络的影响。CGN通常是在运行IPv4服务的基础上部署的，不应该对已经工作的本机IPv4服务产生负面影响。CGN最初需要小规模的，并将根据订户、内容和网络对等方的流量和连接动态来满足需求。
The operator may want to deploy CGNs more centrally at first and then scale the system as needed. This approach can help conserve the costs of the system, limiting the deployed base and scaling it based on actual traffic demand. The operator should use a deployment model and architecture that allow the system to scale as needed.
运营商可能希望首先更集中地部署CGN，然后根据需要扩展系统。这种方法有助于节约系统成本，限制部署的基础，并根据实际流量需求进行扩展。操作员应使用允许系统根据需要扩展的部署模型和体系结构。
+--------+ -----
| | / \
| CGN | | |
- - -> + + < -> | |
+---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 |
| | ^ | |
|---------+ | | Net |
+--------+ Centralized | |
+---------+ | | CGN | |
| | | CGN | | |
| CPE | <- > + + <- - - - - - - > | |
|---------+ | | \ /
+--------+ -----
^
|
Distributed CGN
+--------+ -----
| | / \
| CGN | | |
- - -> + + < -> | |
+---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 |
| | ^ | |
|---------+ | | Net |
+--------+ Centralized | |
+---------+ | | CGN | |
| | | CGN | | |
| CPE | <- > + + <- - - - - - - > | |
|---------+ | | \ /
+--------+ -----
^
|
Distributed CGN
Figure 7: CGN Deployment: Centralized vs. Distributed
图7:CGN部署：集中式与分布式
The operator may be required to log translation information [CGN-REQS]. This logging may require significant investment in external systems that ingest, aggregate, and report such information [DETERMINISTIC-CGN].
操作员可能需要记录翻译信息[CGN-REQS]。此日志记录可能需要对接收、聚合和报告此类信息的外部系统进行大量投资[DETERMINISTIC-CGN]。
Since CGN has noticeable impacts on certain applications [NAT444-IMPACTS], operators may deploy CGN only for those subscribers who may be less affected by CGN (if possible).
由于CGN对某些应用程序有显著影响[NAT444-impacts]，运营商只能为受CGN影响较小的用户部署CGN（如果可能）。
Once native IPv6 is widely deployed in the network and well supported by tools, staff, and processes, an operator may consider supporting only IPv6 to all or some subscriber endpoints. During this final phase, IPv4 connectivity may or may not need to be supported, depending on the conditions of the network, subscriber demand, and legacy device requirements. If legacy IPv4 connectivity is still demanded (e.g., for older nodes), DS-Lite [RFC6333] may be used to tunnel the traffic. If IPv4 connectivity is not required but access to legacy IPv4 content is, then NAT64 [RFC6144] [RFC6146] can be used.
一旦本地IPv6广泛地部署在网络中，并被工具、人员和进程充分支持，运营商可以考虑仅支持IPv6到所有或某些用户端点。在此最后阶段，IPv4连接可能需要支持，也可能不需要支持，具体取决于网络条件、用户需求和传统设备要求。如果仍然需要传统IPv4连接（例如，对于较旧的节点），则可以使用DS Lite[RFC6333]来隧道流量。如果不需要IPv4连接，但需要访问传统IPv4内容，则可以使用NAT64[RFC6144][RFC6146]。
DS-Lite allows continued access for the IPv4 subscriber base using address sharing for IPv4 Internet connectivity but with only a single layer of translation, as compared to CGN/NAT444. This mode of operation also removes the need to directly supply subscriber endpoints with an IPv4 address, potentially simplifying the connectivity to the customer (single address family) and supporting IPv6-only addressing to the CPE.
与CGN/NAT444相比，DS Lite允许使用IPv4 Internet连接的地址共享对IPv4用户群进行持续访问，但只需要一层转换。这种操作模式还消除了直接向订户端点提供IPv4地址的需要，从而有可能简化与客户的连接（单地址系列），并支持仅对CPE进行IPv6寻址。
The operator can also move Dual Stack endpoints to DS-Lite
retroactively to help optimize the IPv4 address-sharing deployment by
removing the IPv4 address assignment and routing component. To
minimize traffic needing translation, the operator should have
already moved most content to IPv6 before the IPv6-only phase is
implemented.
+--------+ -----
| | / \
Encap IPv4 Flow | AFTR | | IPv4 |
-------+ +---+ Net |
+---------+ / | | \ /
| | / +--------+ -----
| DS-Lite +------- -----
| | / \
| Client | IPv6 Flow | IPv6 |
| +-------------------------------| Net |
| | \ /
+---------+ -----
The operator can also move Dual Stack endpoints to DS-Lite
retroactively to help optimize the IPv4 address-sharing deployment by
removing the IPv4 address assignment and routing component. To
minimize traffic needing translation, the operator should have
already moved most content to IPv6 before the IPv6-only phase is
implemented.
+--------+ -----
| | / \
Encap IPv4 Flow | AFTR | | IPv4 |
-------+ +---+ Net |
+---------+ / | | \ /
| | / +--------+ -----
| DS-Lite +------- -----
| | / \
| Client | IPv6 Flow | IPv6 |
| +-------------------------------| Net |
| | \ /
+---------+ -----
Figure 8: DS-Lite Basic Model
图8:DS Lite基本模型
If the operator had previously decided to enable a CGN/NAT444 deployment, it may be able to co-locate the AFTR and CGN/NAT444 processing functions within a common network location to simplify capacity management and the engineering of flows. This case may be evident in a later transition stage, when an operator chooses to optimize its network and IPv6-only operation is feasible.
如果运营商之前决定启用CGN/NAT444部署，则可能能够将AFTR和CGN/NAT444处理功能共同定位在一个公共网络位置，以简化容量管理和流量工程。这种情况在稍后的过渡阶段可能很明显，此时运营商选择优化其网络，并且仅限IPv6的操作是可行的。
The same deployment considerations associated with native IPv6 deployments apply to DS-Lite and NAT64. IPv4 will now be dependent on IPv6 service quality, so the IPv6 network and services must be running well to ensure a quality experience for the end subscriber. Tools and processes will be needed to manage the encapsulated IPv4 service. If flow analysis is required for IPv4 traffic, this may be enabled at a point beyond the AFTR (after decapsulation) or where DS-Lite-aware equipment is used to process traffic midstream.
与本机IPv6部署相关的部署注意事项同样适用于DS Lite和NAT64。IPv4现在将依赖于IPv6服务质量，因此IPv6网络和服务必须运行良好，以确保最终订户的质量体验。管理封装的IPv4服务需要工具和流程。如果需要对IPv4流量进行流量分析，则可以在AFTR之外的点（解除封装后）或使用DS Lite感知设备处理中游流量的点启用流量分析。
+---------+ IPv6 Encapsulation +------------+
| + - - - - - - - - - - -+ |
| AFTR +----------------------+ AFTR +------------
| | IPv4 Packet | | IPv4 Packet
| Client +----------------------+ +------------
| + - - - - - - - - - - -+ | ^
+---------+ ^ ^ +------------+ |
| | |
| | |
IPv6 (Tools/Mgmt) | IPv4 Packet Flow Analysis
|
Midstream IPv4 Packet Flow Analysis (Encapsulation Aware)
+---------+ IPv6 Encapsulation +------------+
| + - - - - - - - - - - -+ |
| AFTR +----------------------+ AFTR +------------
| | IPv4 Packet | | IPv4 Packet
| Client +----------------------+ +------------
| + - - - - - - - - - - -+ | ^
+---------+ ^ ^ +------------+ |
| | |
| | |
IPv6 (Tools/Mgmt) | IPv4 Packet Flow Analysis
|
Midstream IPv4 Packet Flow Analysis (Encapsulation Aware)
Figure 9: DS-Lite Tools and Flow Analysis
图9:DS Lite工具和流分析
DS-Lite [RFC6333] also requires client support on the subscriber premises device. The operator must clearly articulate to vendors which technologies will be used at which points, how they interact with each other at the CPE, and how they will be provisioned. As an example, an operator may use 6rd in the outset of the transition, then move to native Dual Stack followed by DS-Lite.
DS Lite[RFC6333]还需要订户设备上的客户端支持。运营商必须向供应商明确说明哪些技术将在哪些点使用，它们在CPE中如何相互作用，以及如何供应。例如，操作员可以在转换开始时使用6rd，然后移动到本机双堆栈，然后再移动到DS Lite。
DS-Lite [RFC6333], like any tunneling option, is subject to a reduced MTU, so operators need to plan to manage this type of environment. Additional considerations for DS-Lite deployments can be found in [DSLITE-DEPLOYMENT].
DS Lite[RFC6333]与任何隧道选项一样，需要减少MTU，因此运营商需要计划管理此类环境。有关DS Lite部署的其他注意事项，请参见[DSLITE-DEPLOYMENT]。
The deployment of NAT64 assumes that the network assigns an IPv6 address to a network endpoint that is translated to an IPv4 address to provide connectivity to IPv4 Internet services and content. Experiments such as the one described in [RFC6586] highlight issues related to IPv6-only deployments due to legacy IPv4 APIs and IPv4 literals. Many of these issues will be resolved by the eventual removal of this undesirable legacy behavior. Operational deployment models, considerations, and experiences related to NAT64 have been documented in [NAT64-EXPERIENCE].
NAT64的部署假定网络将IPv6地址分配给网络端点，该端点被转换为IPv4地址，以提供到IPv4 Internet服务和内容的连接。[RFC6586]中所述的实验突出了与传统IPv4 API和IPv4文本导致的仅IPv6部署相关的问题。这些问题中的许多将通过最终消除这种不受欢迎的遗留行为来解决。与NAT64相关的操作部署模型、注意事项和经验已记录在[NAT64-EXPERIENCE]中。
+--------+ -----
| | / \
IPv6 Flow | NAT64 | | IPv4 |
-------+ DNS64 +---+ Net |
+---------+ / | | \ /
| | / +--------+ -----
| IPv6 +------- -----
| | / \
| Only | IPv6 Flow | IPv6 |
| +-------------------------------| Net |
| | \ /
+---------+ -----
+--------+ -----
| | / \
IPv6 Flow | NAT64 | | IPv4 |
-------+ DNS64 +---+ Net |
+---------+ / | | \ /
| | / +--------+ -----
| IPv6 +------- -----
| | / \
| Only | IPv6 Flow | IPv6 |
| +-------------------------------| Net |
| | \ /
+---------+ -----
Figure 10: NAT64/DNS64 Basic Model
图10:NAT64/DNS64基本模型
To navigate some of the limitations of NAT64 when dealing with legacy IPv4 applications, the operator may choose to implement 464XLAT [464XLAT] if possible. As support for IPv6 on subscriber equipment and content increases, the efficiency of NAT64 increases by reducing the need to translate traffic. NAT64 deployments would see an overall decline in translator usage as more traffic is promoted to IPv6-to-IPv6 native communication. NAT64 may play an important part in an operator's late-stage transition, as it removes the need to support IPv4 on the access network and provides a solid go-forward networking model.
在处理旧式IPv4应用程序时，为了克服NAT64的一些限制，运营商可能会选择实施464XLAT[464XLAT]。随着订户设备和内容对IPv6的支持的增加，NAT64的效率通过减少传输流量的需要而提高。NAT64部署将看到转换器使用率的总体下降，因为更多的流量被提升到IPv6到IPv6本机通信。NAT64可能在运营商的后期过渡中扮演重要角色，因为它消除了在接入网络上支持IPv4的需要，并提供了可靠的前向网络模型。
It should be noted, as with any technology that utilizes address sharing, that the IPv4 public pool sizes (IPv4 transport addresses per [RFC6146]) can pose limits to IPv4 server connectivity for the subscriber base. Operators should be aware that some IPv4 growth in the near term is possible, so IPv4 translation pools need to be monitored.
应该注意的是，与任何利用地址共享的技术一样，IPv4公共池大小（每个[RFC6146]的IPv4传输地址）可能会限制用户群的IPv4服务器连接。运营商应该意识到，短期内IPv4可能会有所增长，因此需要监控IPv4转换池。
Operators should review the documentation related to the technologies selected for IPv6 transition. In those reviews, operators should understand what security considerations are applicable to the chosen technologies. As an example, [RFC6169] should be reviewed to understand security considerations related to tunneling technologies.
运营商应审查与选择用于IPv6过渡的技术相关的文档。在这些审查中，运营商应了解适用于所选技术的安全注意事项。例如，应审查[RFC6169]，以了解与隧道技术相关的安全注意事项。
Special thanks to Wes George, Chris Donley, Christian Jacquenet, and John Brzozowski for their extensive review and comments.
特别感谢韦斯·乔治、克里斯·唐利、克里斯蒂安·雅克内特和约翰·布佐夫斯基的广泛评论和评论。
Thanks to the following people for their textual contributions, guidance, and comments: Jason Weil, Gang Chen, Nik Lavorato, John Cianfarani, Chris Donley, Tina TSOU, Fred Baker, and Randy Bush.
感谢以下人士的文字贡献、指导和评论：杰森·威尔、陈刚、尼克·拉沃拉托、约翰·齐纳法拉尼、克里斯·唐利、蒂娜·祖、弗雷德·贝克和兰迪·布什。
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011.
[RFC6180]Arkko，J.和F.Baker，“IPv6部署期间使用IPv6转换机制的指南”，RFC 6180，2011年5月。
[464XLAT] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", Work in Progress, September 2012.
[464XLAT]Mawatari，M.，Kawashima，M.，和C.Byrne，“464XLAT：有状态和无状态翻译的结合”，正在进行的工作，2012年9月。
[6rd-SUNSETTING] Townsley, W. and A. Cassen, "6rd Sunsetting", Work in Progress, November 2011.
[6次日落]汤斯利，W.和A.卡森，“第6次日落”，正在进行的工作，2011年11月。
[CGN-REQS] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NATs (CGNs)", Work in Progress, August 2012.
[CGN-REQS]Perreault，S.，Ed.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，在建工程，2012年8月。
[COMCAST-IPv6-EXPERIENCES] Brzozowski, J. and C. Griffiths, "Comcast IPv6 Trial/ Deployment Experiences", Work in Progress, October 2011.
[COMCAST-IPv6-EXPERIENCES]Brzowski，J.和C.Griffiths，“COMCAST IPv6试用/部署经验”，正在进行的工作，2011年10月。
[DETERMINISTIC-CGN] Donley, C., Grundemann, C., Sarawat, V., and K. Sundaresan, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Work in Progress, July 2012.
[DETERMINISTIC-CGN]Donley，C.，Grundemann，C.，Sarawat，V.，和K.Sundaresan，“减少运营商级NAT部署中日志记录的确定性地址映射”，正在进行的工作，2012年7月。
[DSLITE-DEPLOYMENT] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. Boucadair, "Deployment Considerations for Dual-Stack Lite", Work in Progress, August 2012.
[DSLITE-DEPLOYMENT]Lee，Y.，Maglione，R.，Williams，C.，Jacquenet，C.，和M.Boucadair，“双堆栈Lite的部署考虑”，正在进行的工作，2012年8月。
[IPv6-CE-RTR-REQS] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", Work in Progress, October 2012.
[IPv6 CE RTR要求]Singh，H.，Beebee，W.，Donley，C.，和B.Stark，“IPv6客户边缘路由器的基本要求”，正在进行的工作，2012年10月。
[IPv6-DESIGN] Matthews, P., "Design Guidelines for IPv6 Networks", Work in Progress, October 2012.
[IPv6设计]Matthews，P.，“IPv6网络的设计指南”，正在进行的工作，2012年10月。
[IPv6-ICP-ASP-GUIDANCE] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content and Application Service Providers", Work in Progress, September 2012.
[IPv6 ICP ASP指南]Carpenter，B.和S.Jiang，“互联网内容和应用程序服务提供商的IPv6指南”，正在进行的工作，2012年9月。
[NAT444-IMPACTS] Donley, C., Ed., Howard, L., Kuarsingh, V., Berg, J., and J. Doshi, "Assessing the Impact of Carrier-Grade NAT on Network Applications", Work in Progress, October 2012.
[NAT444-IMPACTS]Donley，C.，Ed.，Howard，L.，Kuarsingh，V.，Berg，J.，和J.Doshi，“评估运营商级NAT对网络应用的影响”，正在进行的工作，2012年10月。
[NAT64-EXPERIENCE] Chen, G., Cao, Z., Byrne, C., Xie, C., and D. Binet, "NAT64 Operational Experiences", Work in Progress, August 2012.
[NAT64-EXPERIENCE]Chen，G.，Cao，Z.，Byrne，C.，Xie，C.，和D.Binet，“NAT64运行经验”，正在进行的工作，2012年8月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，2001年6月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, September 2007.
[RFC4942]Davies，E.，Krishnan，S.，和P.Savola，“IPv6过渡/共存安全考虑”，RFC 49422007年9月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569]Despres，R.，“IPv4基础设施上的IPv6快速部署（第6次）”，RFC 5569，2010年1月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，2010年8月。
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.
[RFC6092]Woodyatt，J.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，2011年1月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC 61442011年4月。
[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.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]Krishnan，S.，Thaler，D.，和J.Hoagland，“IP隧道的安全问题”，RFC 61692011年4月。
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011.
[RFC6264]Jiang，S.，Guo，D.，和B.Carpenter，“IPv6过渡的增量载波级NAT（CGN）”，RFC 62642011年6月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，RFC 6269，2011年6月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]Carpenter，B.，“6to4部署咨询指南”，RFC 63432011年8月。
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, April 2012.
[RFC6540]George，W.，Donley，C.，Liljenstolpe，C.，和L.Howard，“所有具有IP能力的节点都需要IPv6支持”，BCP 177，RFC 65402012年4月。
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April 2012.
[RFC6586]Arkko，J.和A.Keranen，“纯IPv6网络的体验”，RFC 6586，2012年4月。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
[RFC6598]Weil，J.，Kuarsingh，V.，Donley，C.，Liljenstolpe，C.，和M.Azinger，“IANA为共享地址空间保留IPv4前缀”，BCP 153，RFC 6598，2012年4月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724]Thaler，D.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月。
[RFC6732] Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider Managed Tunnels", RFC 6732, September 2012.
[RFC6732]Kuarsingh，V.，Lee，Y.，和O.Vautrin，“6to4提供商管理的隧道”，RFC 6732，2012年9月。
Authors' Addresses
作者地址
Victor Kuarsingh (editor) Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada
Victor Kuarsingh（编辑）加拿大安大略省布兰顿市迪克西路8200号罗杰斯通讯有限公司L6T 0C1
EMail: victor.kuarsingh@gmail.com
URI: http://www.rogers.com
EMail: victor.kuarsingh@gmail.com
URI: http://www.rogers.com
Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 US
美国弗吉尼亚州赫恩登日出谷大道13820号李霍华德时代华纳有线电视公司，邮编20171
EMail: lee.howard@twcable.com
URI: http://www.timewarnercable.com
EMail: lee.howard@twcable.com
URI: http://www.timewarnercable.com