Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 6180 Ericsson
Category: Informational F. Baker
ISSN: 2070-1721 Cisco Systems
May 2011
Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 6180 Ericsson
Category: Informational F. Baker
ISSN: 2070-1721 Cisco Systems
May 2011
Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
IPv6部署期间使用IPv6转换机制的指南
Abstract
摘要
The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations.
互联网的发展继续超越IPv4的能力。显然需要扩展地址空间。随着子网中可用前缀和地址数量的增加，以及地址管理的改进，IPv6是唯一可行的选择。然而，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/rfc6180.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6180.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Choosing a Deployment Model . . . . . . . . . . . . . . . 6
4. Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . . 7
4.1. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8
4.2. Crossing IPv4 Islands . . . . . . . . . . . . . . . . . . 10
4.3. IPv6-Only Core Network . . . . . . . . . . . . . . . . . . 11
4.4. IPv6-Only Deployment . . . . . . . . . . . . . . . . . . . 11
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Choosing a Deployment Model . . . . . . . . . . . . . . . 6
4. Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . . 7
4.1. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8
4.2. Crossing IPv4 Islands . . . . . . . . . . . . . . . . . . 10
4.3. IPv6-Only Core Network . . . . . . . . . . . . . . . . . . 11
4.4. IPv6-Only Deployment . . . . . . . . . . . . . . . . . . . 11
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
The Internet continues to grow beyond the capabilities of IPv4. The tremendous success of the Internet has strained the IPv4 address space, which is no longer sufficient to fuel future growth. At the time of this writing, August 2010, the IANA "free pool" contains only 14 unallocated unicast IPv4 /8 prefixes. Credible estimates based on past behavior suggest that the Regional Internet Registries (RIRs) will exhaust their remaining address space by early 2012, apart from the development of a market in IPv4 address space. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table.
互联网的发展继续超越IPv4的能力。互联网的巨大成功使IPv4地址空间变得紧张，这已不足以推动未来的增长。在撰写本文时，即2010年8月，IANA“自由池”仅包含14个未分配的单播IPv4/8前缀。基于过去行为的可靠估计表明，除了IPv4地址空间市场的开发外，地区互联网注册中心（RIR）将在2012年初耗尽其剩余的地址空间。显然需要扩展地址空间。随着子网中可用前缀和地址数量的增加，以及地址管理的改进，IPv6是唯一可行的选择。
John Curran, in "An Internet Transition Plan" [RFC5211], gives estimated dates for significant points in the transition; while the tail of the process will likely be long, it is clear that deployment is a present reality and requirement.
约翰·科伦（John Curran）在《互联网转型计划》（RFC5211）中给出了转型重要阶段的预计日期；虽然这一过程的尾声可能很长，但很明显，部署是目前的现实和需要。
Accordingly, many organizations have employed or are planning to employ IPv6 in their networks. Yet, IPv6 deployment requires some effort, resources, and expertise. This is largely a natural part of maintaining and evolving a network: changing requirements are taken into account in normal planning, procurement, and update cycles. Very large networks have successfully adopted IPv6 alongside IPv4, with surprisingly little effort.
因此，许多组织已经或计划在其网络中采用IPv6。然而，IPv6部署需要一些努力、资源和专业知识。这在很大程度上是维护和发展网络的自然部分：在正常的规划、采购和更新周期中考虑不断变化的需求。非常大的网络已经成功地采用了IPv6和IPv4，但出人意料的是，几乎不费吹灰之力。
However, in order to successfully make this transition, some amount of new expertise is required. Different types of experience will be required: basic understanding of IPv6 mechanisms, debugging tools, product capabilities and caveats when used with IPv6, and so on. The availability of many different IPv6 deployment models and tools is an additional reason why expertise is required. These models and tools have been developed over the years at the IETF, some for specific circumstances and others for more general use. They differ greatly in their principles of operation. Over time, views about the best ways to employ the tools have evolved. Given the number of options, network managers are understandably confused. They need guidance on recommended approaches to IPv6 deployment.
然而，为了成功地完成这一过渡，需要一些新的专业知识。需要不同类型的经验：基本了解IPv6机制、调试工具、产品功能以及与IPv6一起使用时的注意事项等。许多不同IPv6部署模型和工具的可用性是需要专业知识的另一个原因。这些模型和工具是IETF多年来开发的，一些用于特定环境，另一些用于更广泛的用途。它们的操作原理差别很大。随着时间的推移，关于使用这些工具的最佳方式的观点也在不断演变。考虑到选项的数量，网络管理员感到困惑是可以理解的。他们需要关于IPv6部署推荐方法的指导。
The rest of this document is organized as follows. Section 2 introduces some terminology, Section 3 discusses some of the general principles behind choosing particular deployment models and tools, Section 4 goes through the recommended deployment models for common situations, and Section 5 provides some concluding remarks about the choice between these models.
本文件其余部分的组织如下。第2节介绍了一些术语，第3节讨论了选择特定部署模型和工具背后的一些一般原则，第4节介绍了常见情况下推荐的部署模型，第5节提供了关于这些模型之间选择的一些总结。
Many networks can follow one of the four scenarios described in this document. However, variations will certainly occur in the details, and there will be questions, such as the particular choice of tunneling solution, for which there is no "one size fits all" answer. Network managers must each take the responsibility of choosing the best solution for their own case. This document does not attempt to provide guidance for all possible networking situations. Also, a systematic operational plan for the transition is required, but the details depend entirely on the individual network.
许多网络可以遵循本文档中描述的四种场景之一。然而，细节肯定会发生变化，并且会出现一些问题，例如隧道解决方案的特定选择，对于这些问题没有“一刀切”的答案。网络经理必须各自负责为自己的情况选择最佳解决方案。本文件并不试图为所有可能的联网情况提供指导。此外，还需要一个系统的过渡操作计划，但细节完全取决于单个网络。
In this document, the following terms are used.
在本文件中，使用以下术语。
IPv4/IPv4 NAT: refers to any IPv4-to-IPv4 network address translation algorithm, both "Basic NAT" and "Network Address/Port Translator (NAPT)", as defined by [RFC2663].
IPv4/IPv4 NAT：指任何IPv4到IPv4的网络地址转换算法，包括[RFC2663]定义的“基本NAT”和“网络地址/端口转换器（NAPT）”。
Dual Stack: refers to a technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers [RFC4213].
双栈：指在主机和路由器中提供对互联网协议（IPv4和IPv6）的完全支持的技术[RFC4213]。
Dual Stack Lite: also called "DS-Lite", refers to a technique that employs tunneling and IPv4/IPv4 NAT to provide IPv4 connectivity over IPv6 networks [DS-lite].
双栈Lite：也称为“DS Lite”，是指一种利用隧道和IPv4/IPv4 NAT通过IPv6网络提供IPv4连接的技术[DS Lite]。
IPv4-only domain: as defined in [RFC6144], a routing domain in which applications can only use IPv4 to communicate, whether due to host limitations, application limitations, or network limitations.
仅IPv4域：如[RFC6144]中所定义，一个路由域，其中应用程序只能使用IPv4进行通信，无论是由于主机限制、应用程序限制还是网络限制。
IPv6-only domain: as defined in [RFC6144], a routing domain in which applications can only use IPv6 to communicate, whether due to host limitations, application limitations, or network limitations.
仅限IPv6域：如[RFC6144]中所定义，一个路由域，其中应用程序只能使用IPv6进行通信，无论是由于主机限制、应用程序限制还是网络限制。
NAT-PT: refers to a specific, old design of a Network Address Translator - Protocol Translator defined in [RFC2766] and deprecated due to the reasons stated in [RFC4966].
NAT-PT：是指[RFC2766]中定义的、由于[RFC4966]中所述原因而被弃用的网络地址转换器-协议转换器的一种特定的旧设计。
The primary goal is to facilitate the continued growth of the networking industry and deployment of Internet technology at relatively low capital and operational expense without destabilizing deployed services or degrading customer experience. This is at risk with IPv4 due to the address runout; economics teaches us that a finite resource, when stressed, becomes expensive, either in the actual cost of the resource or in the complexity of the technology and processes required to manage it. It is also at risk while both
其主要目标是以相对较低的资本和运营费用促进网络行业的持续增长和互联网技术的部署，而不会破坏部署的服务或降低客户体验。由于地址溢出，IPv4存在风险；经济学告诉我们，有限的资源在受到压力时会变得昂贵，无论是资源的实际成本还是管理资源所需的技术和过程的复杂性。当两者同时存在时，它也处于危险之中
IPv4 and IPv6 are deployed in parallel, as it costs more to run two technologies than one. To this end, since IPv4 clearly will not scale to meet our insatiable requirements, the primary technical goals are the global deployment of IPv6 both in the network, in its service infrastructure, and by applications, resulting in the end of the requirement to deploy two IP versions and the obsolescence of transitional mechanisms. Temporary goals in support of this focus on enabling parts of the Internet to employ IPv6 and disable IPv4 before the entire Internet has done so.
IPv4和IPv6是并行部署的，因为运行两种技术比运行一种技术成本更高。为此，由于IPv4显然无法扩展以满足我们永不满足的需求，主要技术目标是在网络、服务基础设施和应用程序中全面部署IPv6，从而结束部署两个IP版本的需求，并淘汰过渡机制。支持这一点的临时目标是，在整个互联网使用IPv6和禁用IPv4之前，使部分互联网能够使用IPv6和禁用IPv4。
The end goal is network-wide native IPv6 deployment, resulting in the obsolescence of transitional mechanisms based on encapsulation, tunnels, or translation, and also resulting in the obsolescence of IPv4. Transition mechanisms, taken as a class, are a means to an end, to simplify the process for the network administration.
最终目标是在网络范围内部署本机IPv6，导致基于封装、隧道或转换的过渡机制过时，也导致IPv4过时。转换机制，作为一个类，是达到目的的一种手段，用于简化网络管理过程。
However, the goals, constraints, and opportunities for IPv6 deployment differ from one case to another. There is no single right model for IPv6 deployment, just like there is no one and only model for IPv4 network design. Some guidelines can be given, however. Common deployment models that have been found to work well are discussed in Section 4, and the small set of standardized IETF migration tools support these models. But first it may be useful to discuss some general principles that guide our thinking about what is a good deployment model.
但是，部署IPv6的目标、限制和机会因情况而异。IPv6部署没有单一正确的模型，就像IPv4网络设计没有单一且唯一的模型一样。然而，可以给出一些指导方针。第4节讨论了运行良好的常见部署模型，一小部分标准化IETF迁移工具支持这些模型。但首先，讨论一些指导我们思考什么是好的部署模型的一般原则可能是有用的。
It is important to start the deployment process in a timely manner. Most of the effort is practical -- network audit, network component choices, network management, planning, implementation -- and at the time of this writing, reasonably easily achievable. There is no particular advantage to avoiding dealing with IPv6 as part of the normal network planning cycle. The migration tools already exist, and while additional features continue to be developed, it is not expected that they radically change what networks have to do. In other words, there is no point in waiting for an improved design.
及时启动部署过程非常重要。大部分工作都是实用的——网络审计、网络组件选择、网络管理、规划、实施——在撰写本文时，这些工作相当容易实现。避免将IPv6作为正常网络规划周期的一部分来处理没有什么特别的好处。迁移工具已经存在，虽然还将继续开发其他功能，但预计它们不会从根本上改变网络的功能。换句话说，等待改进的设计毫无意义。
There are only a few exceptional networks where coexistence with IPv4 is not a consideration at all. These networks are typically new deployments, strictly controlled by a central authority, and have no need to deal with legacy devices. For example, specialized machine-to-machine networks that communicate only to designated servers, such as Smart Grids, can easily be deployed as IPv6-only networks. Mobile telephone network operators, especially those using 3GPP (Third Generation Partnership Project), have seriously considered IPv6-only operation, and some have deployed it. Research networks that can be separated from the IPv4 Internet to find out what happens are also a
只有少数例外的网络根本不考虑与IPv4共存。这些网络通常是新部署的，由中央机构严格控制，不需要处理遗留设备。例如，仅与指定服务器通信的专用机器对机器网络（如智能电网）可以轻松部署为仅限IPv6的网络。移动电话网络运营商，特别是那些使用3GPP（第三代合作伙伴计划）的运营商，已经认真考虑只使用IPv6的运营，一些运营商已经部署了它。研究可以与IPv4互联网分离的网络，以了解发生了什么也是一个挑战
candidate. In most other networks, IPv4 has to be considered. A typical requirement is that older, IPv4-only applications, systems, or services must be accommodated. Most networks that cross administrative boundaries or allow end-user equipment have such requirements. Even in situations where the network consists of only new, IPv6-capable devices, it is typically required that the devices be able to communicate with the IPv4 Internet.
候选人在大多数其他网络中，必须考虑IPv4。一个典型的要求是必须适应较旧的、仅限IPv4的应用程序、系统或服务。大多数跨越管理边界或允许最终用户设备的网络都有这样的要求。即使在网络仅由支持IPv6的新设备组成的情况下，通常也要求这些设备能够与IPv4 Internet通信。
It is expected that after a period of supporting both IPv4 and IPv6, IPv4 can eventually be turned off. This should happen gradually. For instance, a service provider network might stop providing IPv4 service within its own network, while still allowing its IPv6 customers to access the rest of the IPv4 Internet through overlay, proxy, or translation services. Regardless of progress in supporting IPv6, it is widely expected that some legacy applications and some networks will continue to run only over IPv4 for many years. All deployment scenarios need to deal with this situation.
预计在同时支持IPv4和IPv6一段时间后，IPv4最终可以关闭。这应该逐渐发生。例如，服务提供商网络可能停止在其自己的网络中提供IPv4服务，同时仍允许其IPv6客户通过覆盖、代理或翻译服务访问IPv4 Internet的其余部分。尽管在支持IPv6方面取得了进展，但人们普遍预计，一些遗留应用程序和一些网络将在多年内继续只在IPv4上运行。所有部署场景都需要处理这种情况。
The first requirement is that the model or tool actually allow communications to flow and services to appropriately be delivered to customers without perceived degradation. While this sounds too obvious to even state, it is sometimes not easy to ensure that a proposed model does not have failure modes related to supporting older devices, for instance. A network that is not serving all of its users is not fulfilling its task.
第一个要求是，该模型或工具实际上允许通信流动，并适当地向客户提供服务，而不会造成明显的降级。虽然这听起来太明显了，甚至无法说明，但有时要确保提议的模型没有与支持旧设备相关的故障模式并不容易，例如。没有为所有用户提供服务的网络没有完成其任务。
The ability to communicate is far more important than fine-grained performance differences. In general, it is not productive to focus on the optimization of a design that is intended to be temporary, such as a migration solution necessarily is. Consequently, existing tools are often preferred over new ones, even if for some specific circumstance it would be possible to construct a slightly more efficient design.
通信能力远比细粒度性能差异重要。一般来说，将重点放在临时性设计的优化上是没有成效的，例如迁移解决方案必然是临时性的。因此，现有工具往往比新工具更受欢迎，即使在某些特定情况下，可能会构建一个稍微更高效的设计。
Similarly, migration tools that can be disposed after a period of co-existence are preferred over tools that require more permanent changes. Such permanent changes may incur costs even after the transition to IPv6 has been completed.
类似地，与需要更持久更改的工具相比，可以在共存一段时间后处理的迁移工具更受欢迎。即使在完成向IPv6的过渡之后，此类永久性更改也可能会产生成本。
Looking back on the deployment of Internet technology, some of the factors, as described in [RFC5218] and [Baker.Shanghai], that have been important for success include:
回顾互联网技术的应用，如[RFC5218]和[Baker.Shanghai]所述，对成功至关重要的一些因素包括：
o The ability to offer a valuable service. In the case of the Internet, connectivity has been this service.
o 提供有价值服务的能力。就互联网而言，连接一直是这项服务的核心。
o The ability to deploy the solution in an incremental fashion.
o 以增量方式部署解决方案的能力。
o Simplicity. This has been a key factor in making it possible for all types of devices to support the Internet protocols.
o 简单这是使所有类型的设备都能够支持Internet协议的一个关键因素。
o Openly available implementations. These make it easier for researchers, start-ups, and others to build on or improve existing components.
o 公开可用的实现。这使得研究人员、初创企业和其他人更容易建立或改进现有组件。
o The ability to scale. The IPv4 Internet grew far larger than its original designers had anticipated, and scaling limits only became apparent 20-30 years later.
o 扩展的能力。IPv4互联网的发展远远超出了其最初设计者的预期，而扩展限制在20-30年后才变得明显。
o The design supports robust interoperability rather than mere correctness. This is important in order to ensure that the solution works in different circumstances and in an imperfectly controlled world.
o 该设计支持健壮的互操作性，而不仅仅是正确性。这对于确保解决方案在不同环境和控制不完善的世界中发挥作用非常重要。
Similar factors are also important when choosing IPv6 migration tools. Success factors should be evaluated in the context of a migration solution. For instance, incremental deployability and lack of dependencies to components that are under someone else's control are key factors.
在选择IPv6迁移工具时，类似的因素也很重要。应在迁移解决方案的上下文中评估成功因素。例如，增量部署能力和对其他人控制下的组件缺乏依赖性是关键因素。
It is also essential that any chosen designs allow the network to be maintained, serviced, diagnosed, and measured. The ability of the network to operate under many different circumstances and surprising conditions is a key. Any large network that employs brittle components will incur significant support costs.
同样重要的是，任何选择的设计都允许对网络进行维护、服务、诊断和测量。网络在许多不同环境和意外条件下运行的能力是一个关键。任何使用易碎组件的大型网络都将产生巨大的支持成本。
Properly executed IPv6 deployment normally involves a step-wise approach where individual functions or parts of the network are updated at different times. For instance, IPv6 connectivity has to be established and tested before DNS entries with IPv6 addresses can be provisioned. Or, specific services can be moved to support IPv6 earlier than others. In general, most deployment models employ a very similar network architecture for both IPv4 and IPv6. The principle of changing only the minimum amount necessary is applied here. As a result, some features of IPv6, such as the ability to have an effectively unlimited number of hosts on a subnet, may not be available in the short term.
正确执行的IPv6部署通常包括一种分步方法，即在不同时间更新网络的各个功能或部分。例如，在提供具有IPv6地址的DNS条目之前，必须建立并测试IPv6连接。或者，可以将特定服务移动到比其他服务更早支持IPv6的位置。通常，大多数部署模型对IPv4和IPv6都采用非常相似的网络体系结构。这里应用的原则是只改变所需的最小数量。因此，IPv6的某些功能，例如在一个子网中有效地拥有无限数量主机的能力，可能在短期内不可用。
This section presents a number of common scenarios along with recommended deployment tools for them. We start from the most obvious deployment situation where native connectivity is available and both IP versions are used. Since native IPv6 connectivity is not
本节介绍了一些常见的场景以及推荐的部署工具。我们从最明显的部署情况开始，其中本机连接可用，并且使用两个IP版本。因为本机IPv6连接不可用
available in all networks, our second scenario looks at ways of arranging such connectivity over the IPv4 Internet. The third scenario is more advanced and looks at a service provider network that runs only on IPv6 but that is still capable of providing both IPv6 and IPv4 services. The fourth and most advanced scenario focuses on translation, at the application or the network layer.
在所有网络中都可用，我们的第二个场景着眼于通过IPv4 Internet安排此类连接的方法。第三个场景更高级，它着眼于仅在IPv6上运行但仍能够同时提供IPv6和IPv4服务的服务提供商网络。第四个也是最高级的场景侧重于应用程序或网络层的翻译。
Note that there are many other possible deployment models and existing specifications to support such models. These other models are not necessarily frowned upon. However, they are not expected to be the mainstream deployment models, and consequently, the associated specifications are typically not IETF Standards Track RFCs. Network managers should not adopt these non-mainstream models lightly, however, as there is little guarantee that they work well. There are also models that are believed to be problematic. An older model of IPv6-IPv4 translation (NAT-PT) [RFC2766] suffers from a number of drawbacks arising from, for example, its attempt to capture DNS queries on path [RFC4966]. Another example regarding the preference to employ tunneling instead of double translation will be discussed later in this document.
请注意，还有许多其他可能的部署模型和现有规范支持此类模型。这些其他模式不一定不受欢迎。然而，它们不应成为主流部署模型，因此，相关规范通常不是IETF标准跟踪RFC。然而，网络管理者不应该轻率地采用这些非主流模式，因为几乎不能保证它们工作良好。还有一些模型被认为是有问题的。较旧的IPv6-IPv4转换（NAT-PT）[RFC2766]模型存在许多缺陷，例如，它试图捕获路径[RFC4966]上的DNS查询。关于使用隧道而不是双重翻译的另一个例子将在本文件后面讨论。
The simplest deployment model is dual stack: one turns on IPv6 throughout one's existing IPv4 network and allows applications using the two protocols to operate as ships in the night. This model is applicable to most networks -- home, enterprise, service provider, or content provider network.
最简单的部署模型是双栈：一种是在现有IPv4网络中启用IPv6，并允许使用这两种协议的应用程序在夜间运行。此模型适用于大多数网络--家庭、企业、服务提供商或内容提供商网络。
The purpose of this model is to support any type of device and communication, and to make it an end-to-end choice which IP version is used between the peers. There are minimal assumptions about the capabilities and configuration of hosts in these networks. Native connectivity avoids problems associated with the configuration of tunnels and Maximum Transmission Unit (MTU) settings. As a result, these networks are robust and reliable. Accordingly, this is the recommended deployment model for most networks and is supported by IETF standards such as dual stack [RFC4213] and address selection [RFC3484]. Similarly, while there are some remaining challenges, this model is also preferred by many service providers and network managers [RFC6036] [IPv6-only-experience].
此模型的目的是支持任何类型的设备和通信，并使其成为对等方之间使用哪个IP版本的端到端选择。对于这些网络中的主机的功能和配置，存在着最低限度的假设。本机连接避免了与隧道配置和最大传输单元（MTU）设置相关的问题。因此，这些网络稳健可靠。因此，这是大多数网络的推荐部署模型，并受到IETF标准（如双栈[RFC4213]和地址选择[RFC3484]）的支持。类似地，尽管还有一些剩余的挑战，但许多服务提供商和网络经理也更喜欢这种模式[RFC6036][IPv6-only experience]。
The challenges associated with this model are twofold. First, while dual stack allows each individual network to deploy IPv6 on their own, actual use still requires participation from all parties between the peers. For instance, the peer must be reachable over IPv6, have an IPv6 address to itself, and advertise such an address in the relevant naming service (such as the DNS). This can create a
与此模型相关的挑战有两方面。首先，虽然双栈允许每个单独的网络单独部署IPv6，但实际使用仍然需要对等方之间所有各方的参与。例如，对等方必须可以通过IPv6访问，自身具有IPv6地址，并在相关命名服务（如DNS）中公布该地址。这可以创建一个
situation where IPv6 has been turned on in a network, but there is little actual traffic. One direct way to affect this situation is to ensure that major destinations of traffic are prepared to receive IPv6 traffic. Current Internet traffic is highly concentrated on selected content provider networks, and making a change in even a small number of these networks can have significant effects. This was recently observed when YouTube started supporting IPv6 [networkworld.youtube]. There are scenarios where these means are insufficient. The following sections discuss deployment models that enable parts of the network to deploy IPv6 faster than other parts.
在网络中已打开IPv6，但实际流量很少的情况。影响这种情况的一个直接方法是确保流量的主要目的地准备好接收IPv6流量。当前的互联网流量高度集中在选定的内容提供商网络上，即使对其中一小部分网络进行更改也会产生重大影响。最近，当YouTube开始支持IPv6[networkworld.YouTube]时，人们注意到了这一点。有些情况下，这些手段是不够的。以下各节讨论了一些部署模型，这些模型使部分网络能够比其他部分更快地部署IPv6。
The second challenge is that not all applications deal gracefully with situations where one of the alternative destination addresses works unreliably. For instance, if IPv6 connectivity is unreliable, it may take a long time for some applications to switch over to IPv4. As a result, many content providers are shying away from advertising IPv6 addresses in DNS. This in turn exacerbates the first challenge. Long term, the use of modern application toolkits and APIs solves this problem. In the short term, some content providers and user network managers have made a mutual agreement to resolve names to IPv6 addresses. Such agreements are similar to peering agreements and have been seen as necessary by many content providers. These "whitelisting" practices have some downsides as well, however. In particular, they create a dependency on an external party for moving traffic to IPv6. Nevertheless, there are many types of traffic in the Internet, and only some of it requires such careful coordination. Popular peer-to-peer systems can automatically and reliably employ IPv6 connectivity where it is available, for instance.
第二个挑战是，并非所有应用程序都能优雅地处理其中一个备用目标地址工作不可靠的情况。例如，如果IPv6连接不可靠，则某些应用程序可能需要很长时间才能切换到IPv4。因此，许多内容提供商都回避在DNS中公布IPv6地址。这反过来又加剧了第一个挑战。从长远来看，现代应用程序工具包和API的使用解决了这个问题。在短期内，一些内容提供商和用户网络经理已达成共识，将名称解析为IPv6地址。这类协议类似于对等协议，许多内容提供商认为这是必要的。然而，这些“白名单”做法也有一些缺点。特别是，它们创建了对外部方的依赖，以便将流量移动到IPv6。然而，互联网上有许多类型的流量，其中只有一部分需要如此仔细的协调。例如，流行的对等系统可以在可用的情况下自动可靠地使用IPv6连接。
Despite these challenges, the native dual-stack connectivity model remains the recommended approach. It is responsible for a large part of the progress on worldwide IPv6 deployment to date. The largest IPv6 networks -- notably, national research and education networks, Internet II, RENATER, and others -- employ this approach.
尽管存在这些挑战，本机双堆栈连接模型仍然是推荐的方法。迄今为止，它在全球IPv6部署方面取得了很大进展。最大的IPv6网络——尤其是国家研究和教育网络、Internet II、RENATER和其他网络——采用了这种方法。
The original intent of dual stack was to deploy both IP versions alongside each other before IPv4 addresses were to run out. As we know, this never happened and deployment now has to take place with limited IPv4 addresses. Employing dual stack together with a traditional IPv4 address translator (IPv4/IPv4 NAT) is a very common configuration. If the address translator is acceptable for the network from a pure IPv4 perspective, this model can be recommended from a dual-stack perspective as well. The advantage of IPv6 in this model is that it allows direct addressing of specific nodes in the network, creating a contrast to the translated IPv4 service, as noted in [RFC2993] and [shared-addressing-issues]. As a result, it allows the construction of IPv6-based applications that offer more functionality.
双栈的初衷是在IPv4地址用完之前将两个IP版本一起部署。正如我们所知，这种情况从未发生过，现在必须使用有限的IPv4地址进行部署。将双堆栈与传统的IPv4地址转换器（IPv4/IPv4 NAT）结合使用是一种非常常见的配置。如果从纯IPv4的角度来看，网络可以接受地址转换器，那么也可以从双堆栈的角度推荐此模型。此模型中IPv6的优势在于，它允许直接寻址网络中的特定节点，从而与[RFC2993]和[shared addressing issues]中提到的转换IPv4服务形成对比。因此，它允许构建提供更多功能的基于IPv6的应用程序。
There may also be situations where a traditional IPv4 address translator is no longer sufficient. For instance, in typical residential networks, each subscriber is given one global IPv4 address, and the subscriber's IPv4/IPv4 NAT device may use this address with as many devices as it can handle. As IPv4 address space becomes more constrained and without substantial movement to IPv6, it is expected that service providers will be pressured to assign a single global IPv4 address to multiple subscribers. Indeed, in some deployments this is already the case. The dual-stack model is still applicable even in these networks, but the IPv4/IPv4 Network Address Transition (NAT) functionality may need to be relocated and enhanced. On some networks it is possible to employ overlapping private address space [L2-NAT] [DS-extra-lite]. Other networks may require a combination of IPv4/IPv4 NAT enhancements and tunneling. These scenarios are discussed further in Section 4.3.
也可能存在传统IPv4地址转换器不再足够的情况。例如，在典型的住宅网络中，每个订阅者都有一个全局IPv4地址，订阅者的IPv4/IPv4 NAT设备可以将该地址与尽可能多的设备一起使用。随着IPv4地址空间变得更加受限，并且没有大量移动到IPv6，预计服务提供商将被迫将单个全局IPv4地址分配给多个订户。事实上，在某些部署中，情况已经如此。即使在这些网络中，双栈模型仍然适用，但IPv4/IPv4网络地址转换（NAT）功能可能需要重新定位和增强。在某些网络上，可以使用重叠的专用地址空间[L2-NAT][DS extra lite]。其他网络可能需要IPv4/IPv4 NAT增强和隧道的组合。第4.3节将进一步讨论这些场景。
Native IPv6 connectivity is not always available, but fortunately it can be established using tunnels. Tunneling introduces some additional complexity. It also increases the probability that the Path MTU algorithm will be used, as many implementations derive their default MTU from the Ethernet frame size; ICMP filtering interacts poorly with the Path MTU algorithm in [RFC1981]. However, its benefit is that it decouples addressing inside and outside the tunnel, making it easy to deploy IPv6 without having to modify routers along the path. Tunneling should be used when native connectivity cannot be established, such as when crossing another administrative domain or a router that cannot be easily reconfigured.
本机IPv6连接并不总是可用的，但幸运的是，可以使用隧道建立连接。隧道引入了一些额外的复杂性。它还增加了使用Path MTU算法的可能性，因为许多实现都从以太网帧大小导出其默认MTU；ICMP过滤与[RFC1981]中的Path MTU算法的交互作用很差。然而，它的好处是它将隧道内外的寻址解耦，使部署IPv6变得容易，而无需修改路径上的路由器。当无法建立本机连接时，例如当跨越另一个管理域或无法轻松重新配置的路由器时，应使用隧道。
There are several types of tunneling mechanisms, including manually configured IPv6-over-IPv4 tunnels [RFC4213], 6to4 [RFC3056], automatic host-based tunnels [RFC4380], tunnel brokers [RFC3053], running IPv6 over MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798], the use of Virtual Private Networks (VPNs) or mobility tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454] [RFC5555] [RFC5844], and many others. More advanced solutions provide a mesh-based framework of tunnels [RFC5565].
有几种类型的隧道机制，包括手动配置的IPv6-over-IPv4隧道[RFC4213]、6to4[RFC3056]、基于主机的自动隧道[RFC4380]、隧道代理[RFC3053]、使用IPv6提供商边缘路由器（6PE）[RFC4798]在MPLS上运行IPv6、使用虚拟专用网络（VPN）或移动隧道，以同时承载IPv4和IPv6[RFC4301][RFC5454][RFC5555][RFC5844]以及许多其他内容。更高级的解决方案提供了基于网格的隧道框架[RFC5565]。
On a managed network, there are no major challenges with tunneling beyond the possible configuration and MTU problems. Tunneling is very widely deployed both for IPv6 connectivity and other reasons, and is well understood. In general, the IETF recommends that tunneling be used if it is necessary to cross a segment of IP version X when communicating from IP version Y to Y. An alternative design would be to employ protocol translation twice. However, this design involves problems similar to those created by IPv4 address translation and is largely untried technology in any larger scale.
在受管网络上，除了可能的配置和MTU问题外，隧道传输不存在重大挑战。由于IPv6连接和其他原因，隧道技术得到了广泛的应用，人们对此非常了解。一般来说，IETF建议在从IP版本Y到Y进行通信时，如果有必要跨越IP版本X的一段，则应使用隧道。另一种设计是使用两次协议转换。然而，这种设计涉及的问题与IPv4地址转换产生的问题类似，而且在任何更大范围内都是未经试验的技术。
On an unmanaged network, however, there have been a number of problems. In general, solutions aimed at early adopters (such as 6to4) have at times caused IPv6 connectivity to appear to be available on a network when in fact there is no connectivity. In turn, this has lead to the content providers needing to serve IPv6 results for DNS queries only for trusted peers with known high-quality connectivity.
但是，在非托管网络上，出现了许多问题。一般来说，针对早期采用者（如6to4）的解决方案有时会导致IPv6连接看起来在网络上可用，而实际上没有连接。反过来，这导致内容提供商需要仅为具有已知高质量连接的可信对等方的DNS查询提供IPv6结果。
The IPv6 Rapid Deployment (6RD) [RFC5969] approach is a newer version of the 6to4 tunneling solution without the above drawbacks. It offers systematic IPv6 tunneling over IPv4 across an ISP, correspondence between IPv4 and IPv6 routing, and can be deployed within an ISP without the need to rely on other parties.
IPv6快速部署（6RD）[RFC5969]方法是6to4隧道解决方案的更新版本，没有上述缺点。它提供了跨ISP的IPv4系统IPv6隧道、IPv4和IPv6路由之间的通信，并且可以在ISP内部署，而无需依赖其他方。
An emerging deployment model uses IPv6 as the dominant protocol at a service provider network, and tunnels IPv4 through this network in a manner converse to the one described in the previous section. There are several motivations for choosing this deployment model:
一种新兴的部署模型使用IPv6作为服务提供商网络的主要协议，并以与上一节所述相反的方式通过该网络传输IPv4。选择此部署模型有几个动机：
o There may not be enough public or private IPv4 addresses to support network management functions in an end-to-end fashion, without segmenting the network into small parts with overlapping address space.
o 可能没有足够的公共或专用IPv4地址来支持端到端的网络管理功能，而不将网络分割为具有重叠地址空间的小部分。
o IPv4 address sharing among subscribers may involve new address translation nodes within the service provider's network. IPv6 can be used to reach these nodes. Normal IPv4 routing is insufficient for this purpose, as the same addresses would be used in several parts of the network.
o 订户之间的IPv4地址共享可能涉及服务提供商网络中的新地址转换节点。IPv6可用于到达这些节点。正常的IPv4路由不足以实现此目的，因为网络的多个部分将使用相同的地址。
o It may be simpler for the service provider to employ a single-version network.
o 服务提供商使用单一版本的网络可能更简单。
The recommended tool for this model is Dual Stack Lite [DS-lite]. Dual Stack Lite both provides relief for IPv4 address shortage and makes forward progress on IPv6 deployment, by moving service provider networks and IPv4 traffic over IPv6. Given the IPv6 connectivity that Dual Stack Lite runs over, it becomes easy to provide IPv6 connectivity all the way to the end users as well.
此模型的推荐工具是双堆栈Lite[DS Lite]。双栈Lite通过在IPv6上移动服务提供商网络和IPv4流量，既缓解了IPv4地址短缺，又在IPv6部署方面取得了进展。考虑到双栈Lite运行的IPv6连接，向最终用户提供IPv6连接也变得很容易。
Our final deployment model breaks the requirement that all parties must upgrade to IPv6 before any end-to-end communications use IPv6. This model makes sense when the following conditions are met:
我们的最终部署模型打破了所有各方必须在任何端到端通信使用IPv6之前升级到IPv6的要求。当满足以下条件时，此模型有意义：
o There is a fact or requirement that there be an IPv4-only domain and an IPv6-only domain.
o 存在一个事实或要求，即只有IPv4域和IPv6域。
o There is a requirement that hosts in the IPv4-only domain access servers or peers in the IPv6-only domain and vice versa.
o 要求仅IPv4域中的主机访问服务器或仅IPv6域中的对等方，反之亦然。
This deployment model would fit well, for instance, a corporate or mobile network that offers IPv6-only networking but where users still wish to access content from the IPv4 Internet.
例如，这种部署模式非常适合只提供IPv6网络但用户仍希望从IPv4 Internet访问内容的公司或移动网络。
When we say "IPv4-only" or "IPv6-only", we mean that the applications can communicate only using IPv4 or IPv6; this might be due to lack of capabilities in the applications, host stacks, or the network; the effect is the same. The reason to switch to an IPv6-only network may be a desire to test such a configuration or to simplify the network. It is expected that as IPv6 deployment progresses, the second reason will become more prevalent. One particular reason for considering an IPv6-only domain is the effect of overlapping private address space to applications. This is important in networks that have exhausted both public and private IPv4 address space and where arranging an IPv6-only network is easier than dealing with the overlapping address space in applications.
当我们说“仅IPv4”或“仅IPv6”时，我们的意思是应用程序只能使用IPv4或IPv6进行通信；这可能是由于应用程序、主机堆栈或网络中缺乏功能所致；效果是一样的。切换到仅IPv6网络的原因可能是希望测试这种配置或简化网络。预计随着IPv6部署的进展，第二个原因将变得更加普遍。考虑只使用IPv6的域的一个特殊原因是重叠的专用地址空间对应用程序的影响。这对于已耗尽公共和私有IPv4地址空间的网络非常重要，在这些网络中，仅安排IPv6网络比处理应用程序中的重叠地址空间更容易。
Note that the existence of an IPv6-only domain requires that all devices are indeed IPv6 capable. In today's mixed networking environments with legacy devices, this cannot always be guaranteed. But, it can be arranged in networks where all devices are controlled by a central authority. For instance, newly built corporate networks can ensure that the latest device versions are in use. Some networks can also be engineered to support different services over an underlying network and, as such, can support IPv6-only networking more easily. For instance, a cellular network may support IPv4-only connectivity for the installed base of existing devices and IPv6-only connectivity for incremental growth with newer IPv6-capable handsets. Similarly, a broadband ISP may support dual-stack connectivity for customers that require both IPv4 and IPv6, and offer IPv6-only and NAT64 service for others. In the case of 3GPP and DOCSIS 3.0 access networks, the underlying access network architecture allows the flexibility to run different services in parallel to suit the various needs of the customer and the network operator.
请注意，只有IPv6的域的存在要求所有设备都能够使用IPv6。在今天的混合网络环境中，传统设备无法始终保证这一点。但是，它可以安排在所有设备都由中央机构控制的网络中。例如，新建的公司网络可以确保使用最新的设备版本。一些网络还可以设计为通过底层网络支持不同的服务，因此可以更轻松地支持仅限IPv6的网络。例如，蜂窝网络可能支持现有设备安装群的仅IPv4连接，以及支持新的支持IPv6的手机增量增长的仅IPv6连接。类似地，宽带ISP可以为同时需要IPv4和IPv6的客户支持双栈连接，并为其他客户提供仅IPv6和NAT64服务。在3GPP和DOCSIS 3.0接入网络的情况下，底层接入网络架构允许灵活地并行运行不同的服务，以满足客户和网络运营商的各种需求。
It is also necessary for the network operator to have some level of understanding of what applications are used in the network, enabling him to ensure that any communication exchange is in fact predictable, capable of using IPv6, and translatable. In such a case, full interoperability can be expected. This has been demonstrated with
网络运营商还必须对网络中使用的应用程序有一定程度的了解，从而确保任何通信交换实际上都是可预测的、能够使用IPv6和可翻译的。在这种情况下，可以预期完全的互操作性。这一点已经用实例加以证明
some mobile devices, for instance. Note that the requirements on applications are similar to those in networks employing IPv4 NAT technology.
例如，一些移动设备。请注意，对应用程序的要求与采用IPv4 NAT技术的网络中的要求类似。
One obvious IPv6-only deployment approach applies to applications that include proxies or relays. One might position a web proxy, a mail server, or a SIP (Session Initiation Protocol) and media stream back-to-back user agent across the boundary between IPv4 and IPv6 domains, so that the application terminates IPv4 sessions on one side and IPv6 sessions on the other. Doing this preserves the end-to-end nature of communications from the gateway to the communicating peer. For obvious reasons, this solution is preferable to the implementation of Application Layer Gateways in network-layer translators.
一种明显的仅限IPv6的部署方法适用于包括代理或中继的应用程序。可以跨IPv4和IPv6域之间的边界定位web代理、邮件服务器或SIP（会话启动协议）和媒体流背对背用户代理，以便应用程序在一端终止IPv4会话，在另一端终止IPv6会话。这样做可以保留从网关到通信对等方的通信的端到端性质。出于明显的原因，此解决方案比在网络层转换器中实现应用层网关更可取。
The other approach is network-layer IPv4/IPv6 translation as described in "IPv4/IPv6 Translation" [RFC6144] [RFC6145] [RFC6146] [RFC6052] [RFC6147] [FTP64]. IPv4/IPv6 translation at the network layer is similar to IPv4/IPv4 translation in its advantages and disadvantages. It allows a network to provide two types of services to IPv6-only hosts:
另一种方法是网络层IPv4/IPv6转换，如“IPv4/IPv6转换”[RFC6144][RFC6145][RFC6146][RFC6052][RFC6147][FTP64]中所述。网络层的IPv4/IPv6转换与IPv4/IPv4转换的优缺点类似。它允许网络向仅IPv6的主机提供两种类型的服务：
o a relatively small set of systems may be configured with IPv4- mapped addresses, enabling stateless interoperation between IPv4- only and IPv6-only domains, each of which can use the other as peers or servers, and
o 一组相对较小的系统可以配置IPv4映射地址，从而实现仅IPv4和仅IPv6域之间的无状态互操作，其中每个域都可以将另一个域用作对等点或服务器，以及
o a larger set of systems with global IPv6 addresses, which can access IPv4 servers using stateful translation but which are inaccessible as peers or servers from the IPv4-only domain.
o 具有全局IPv6地址的一组更大的系统，可以使用有状态转换访问IPv4服务器，但作为仅IPv4域的对等方或服务器无法访问。
The former service is used today in some university networks, and the latter in some corporate and mobile networks. The stateless service is naturally better suited for servers, and the stateful service for large numbers of client devices. The latter case occurs typically in a public network access setting. The two services can of course also be used together. In this scenario, network-layer translation provides for straightforward services for most applications crossing the IPv4-only/IPv6-only boundary.
前一种服务现在在一些大学网络中使用，后一种服务在一些公司和移动网络中使用。无状态服务自然更适合于服务器，而有状态服务更适合于大量客户机设备。后一种情况通常发生在公共网络访问设置中。当然，这两项服务也可以一起使用。在这种情况下，网络层转换为大多数跨越仅IPv4/仅IPv6边界的应用程序提供了直接的服务。
One challenge in this model is that as long as IPv4 addresses are still shared, issues similar to those caused by IPv4 NATs will still appear [shared-addressing-issues]. Another challenge relates to communications involving IPv4 referrals. IPv4-literals within certain protocols and formats, such as HTML, will fail when passed to IPv6-only hosts since the host does not have an IPv4 address to source the IPv4 communications or an IPv4 route. Measurements on the public Internet show that literals appear in a tiny but measurable
该模型中的一个挑战是，只要IPv4地址仍然是共享的，就会出现类似于IPv4 NAT引起的问题[共享寻址问题]。另一个挑战涉及涉及IPv4转介的通信。某些协议和格式（如HTML）中的IPv4文本在传递到仅限IPv6的主机时将失败，因为主机没有IPv4地址来源IPv4通信或IPv4路由。公共互联网上的测量结果表明，文字以微小但可测量的形式出现
part of web pages [IPv6-only-experience], though whether this poses a practical problem is debatable. If this poses a particular problem for the types of applications in use, proxy configurations could be modified to use a proxy for the traffic in question, hosts could be modified to understand how they can map IPv4-literals to IPv6 addresses, or native dual stack could be employed instead.
部分网页[仅限IPv6体验]，但这是否会造成实际问题仍有争议。如果这对正在使用的应用程序类型造成了特殊问题，则可以修改代理配置以使用代理来处理相关流量，修改主机以了解如何将IPv4文本映射到IPv6地址，或者可以使用本机双堆栈。
The fundamental recommendation is to turn on IPv6. Section 4 described four deployment models to do that, presented in rough order of occurrence in the world at the time of this writing. The first two models are the most widely deployed today. All four models are recommended by the IETF, though, again, the first two models should take priority where they are applicable.
基本建议是启用IPv6。第4节描述了实现这一点的四种部署模型，在撰写本文时按大致的发生顺序进行了介绍。前两款机型是目前部署最广泛的机型。IETF推荐了所有四种型号，但前两种型号在适用时应优先考虑。
As noted in Section 1, variations occur in details, and network managers are ultimately in charge of choosing the best solution for their own case. Benefits and challenges discussed in the previous sections should be considered when weighing deployment alternatives. The transition mechanisms that operators have deployed have been a mixed blessing; native dual-stack deployments are not used to their full extent if peers have not upgraded, tunnel mechanisms that don't follow the routing of the underlying network have been problematic, and translation has its faults as well. Nevertheless, operators have successfully deployed very large networks with these models.
如第1节所述，变化会发生在细节上，网络经理最终负责为自己的情况选择最佳解决方案。在权衡部署备选方案时，应考虑前面章节讨论的好处和挑战。运营商部署的过渡机制好坏参半；如果对等方未升级，本机双堆栈部署将无法充分使用，不遵循底层网络路由的隧道机制存在问题，转换也有其缺陷。然而，运营商已经成功地使用这些模型部署了非常大的网络。
Some additional considerations are discussed below.
下面将讨论一些额外的注意事项。
o There is a tradeoff between ability to connect as many different types of devices as possible and the ability to move forward with deployment as independently as possible. As an example, native dual stack ensures the best connectivity but requires updates in peer systems before actual traffic flows over IPv6. Conversely, IPv6-only networks are very sensitive to what kind of devices they can support, but can be deployed without any expectation of updates on peer systems.
o 在连接尽可能多的不同类型的设备的能力和尽可能独立地推进部署的能力之间存在着权衡。例如，本机双堆栈可确保最佳连接性，但在实际流量通过IPv6之前，需要在对等系统中进行更新。相反，仅限IPv6的网络对其支持的设备类型非常敏感，但可以在对等系统上部署而不需要任何更新。
o "Greenfield" networks and networks with existing IPv4 devices and users need to be treated differently. In the latter case, turning on IPv6 in addition to IPv4 seems the rational choice. In the former case, an IPv6-only model may make sense.
o “绿地”网络和具有现有IPv4设备和用户的网络需要区别对待。在后一种情况下，除了IPv4之外还启用IPv6似乎是理性的选择。在前一种情况下，只使用IPv6的模式可能有意义。
o The right deployment model choices also vary as time goes by. For instance, a tunneling solution that makes sense today may become a native dual-stack solution as the network and devices in the network evolve. Or, an IPv6-only network becomes feasible when a sufficient fraction of client devices become IPv6-enabled.
o 随着时间的推移，正确的部署模型选择也会有所不同。例如，随着网络和网络中设备的发展，今天有意义的隧道解决方案可能会成为本机双堆栈解决方案。或者，当足够多的客户端设备启用IPv6时，只使用IPv6的网络变得可行。
No matter which deployment model is chosen, many of the important implications of IPv6 deployment are elsewhere within the network: IPv6 needs to be taken into account in network management systems and operations, address assignments, service agreements, firewalls, intrusion detection systems, and so on.
无论选择哪种部署模式，IPv6部署的许多重要影响都在网络中的其他地方：IPv6需要在网络管理系统和操作、地址分配、服务协议、防火墙、入侵检测系统等方面加以考虑。
Various aspects of IPv6 deployment have been covered in several documents. Of particular interest may be the basic dual-stack definition [RFC4213], application aspects [RFC4038], deployment in Internet service provider networks [RFC4029] [RFC6036], deployment in enterprise networks [RFC4057] [RFC4852], IPv6-only deployment [IPv6-only-experience], and considerations in specific access networks such as cellular networks [RFC3314] [RFC3574] [RFC4215] [v6-in-mobile] or 802.16 networks [RFC5181].
一些文档介绍了IPv6部署的各个方面。特别令人感兴趣的可能是基本的双栈定义[RFC4213]、应用方面[RFC4038]、在互联网服务提供商网络中的部署[RFC4029][RFC6036]、在企业网络中的部署[RFC4057][RFC4852]、仅IPv6的部署[IPv6的经验]，以及在特定接入网络（如蜂窝网络）中的注意事项[RFC3314][RFC3574][RFC4215][v6移动设备]或802.16网络[RFC5181]。
This document provides general guidance on IPv6 deployment models that have been found suitable for most organizations. The purpose of this document is not to enumerate all special circumstances that may warrant other types of deployment models or the details of the necessary transition tools. Many of the special cases and details have been discussed in the above documents.
本文档提供了适用于大多数组织的IPv6部署模型的一般指导。本文档的目的不是列举可能需要其他类型部署模型或必要转换工具细节的所有特殊情况。上述文件中讨论了许多特殊情况和细节。
While there are detailed differences between the security properties and vulnerabilities between IPv4 and IPv6, in general they provide a very similar level of security and are subject to the same threats. With both protocols, specific security issues are more likely to be found at the practical level than in the specifications. The practical issues include, for instance, bugs or available security mechanisms on a given product. When deploying IPv6, it is important to ensure that the necessary security capabilities exist on the network components even when dealing with IPv6 traffic. For instance, firewall capabilities have often been a challenge in IPv6 deployments.
虽然IPv4和IPv6之间的安全属性和漏洞存在着详细的差异，但总体而言，它们提供了非常相似的安全级别，并且受到相同的威胁。对于这两种协议，在实际层面上比在规范中更可能发现特定的安全问题。例如，实际问题包括给定产品上的bug或可用安全机制。部署IPv6时，即使在处理IPv6流量时，也必须确保网络组件上存在必要的安全功能。例如，在IPv6部署中，防火墙功能常常是一个挑战。
This document has no impact on the security properties of specific IPv6 transition tools. The security considerations relating to the transition tools are described in the relevant documents, for instance, [RFC4213], [RFC6147], [DS-lite], and [RFC6169].
本文档对特定IPv6转换工具的安全属性没有影响。相关文档中描述了与转换工具相关的安全注意事项，例如，[RFC4213]、[RFC6147]、[DS lite]和[RFC6169]。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[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月。
[RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile IPv4", RFC 5454, March 2009.
[RFC5454]Tsirtsis，G.，Park，V.和H.Soliman，“双栈移动IPv4”，RFC 54542009年3月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]Soliman，H.，“双栈主机和路由器的移动IPv6支持”，RFC 55552009年6月。
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.
[RFC5565]Wu，J.，Cui，Y.，Metz，C.和E.Rosen，“软线网格框架”，RFC 55652009年6月。
[Baker.Shanghai] Baker, F., "The view from IPv6 Operations WG (and we'll talk about translation)", Presentation in the China Mobile Workshop on IPv6 Deployment in Cellular Networks, Shanghai, China, November 2009, <http://ipv6ws.arkko.com/ presentations/3GPP-IETF-V6OPS-Discussion.pdf>.
[Baker.Shanghai]Baker，F.，“IPv6运营工作组的观点（我们将讨论翻译）”，在中国移动蜂窝网络IPv6部署研讨会上的演讲，中国上海，2009年11月<http://ipv6ws.arkko.com/ 演示文稿/3GPP-IETF-V6OPS-Discussion.pdf>。
[DS-extra-lite] Arkko, J., Eggert, L., and M. Townsley, "Scalable Operation of Address Translators with Per-Interface Bindings", Work in Progress, February 2011.
[DS extra lite]Arkko，J.，Eggert，L.，和M.Townsley，“地址转换器的可扩展操作，每个接口绑定”，正在进行的工作，2011年2月。
[DS-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, August 2010.
[DS lite]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈lite宽带部署”，正在进行的工作，2010年8月。
[FTP64] Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", Work in Progress, March 2011.
[FTP64]北京，I.，“用于IPv6到IPv4转换的FTP ALG”，正在进行的工作，2011年3月。
[IPv6-only-experience] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", Work in Progress, April 2011.
[仅限IPv6体验]Arkko，J.和A.Keranen，“仅限IPv6网络的体验”，正在进行的工作，2011年4月。
[L2-NAT] Miles, D. and M. Townsley, "Layer2-Aware NAT", Work in Progress, March 2009.
[L2-NAT]迈尔斯，D.和M.汤斯利，“第二层感知NAT”，正在进行的工作，2009年3月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]Durand，A.，Fasano，P.，Guardini，I.，和D.Lento，“IPv6隧道代理”，RFC 3053，2001年1月。
[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月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314]Wasserman，M.，“第三代合作伙伴项目（3GPP）标准中IPv6的建议”，RFC 3314，2002年9月。
[RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003.
[RFC3574]Soininen，J.，“3GPP网络的过渡场景”，RFC 3574，2003年8月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029]Lind，M.，Ksinant，V.，Park，S.，Baudot，A.，和P.Savola，“将IPv6引入ISP网络的场景和分析”，RFC 40292005年3月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038]Shin，M-K.，Hong，Y-G.，Hagino，J.，Savola，P.，和E.Castro，“IPv6过渡的应用方面”，RFC 4038，2005年3月。
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4057]Bound，J.，“IPv6企业网络场景”，RFC 4057，2005年6月。
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[RFC4215]Wiljakka，J.，“第三代合作伙伴计划（3GPP）网络中IPv6过渡的分析”，RFC 4215，2005年10月。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798]De Clercq，J.，Ooms，D.，Prevost，S.，和F.Le Faucheur，“使用IPv6提供商边缘路由器（6PE）通过IPv4 MPLS连接IPv6孤岛”，RFC 4798，2007年2月。
[RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. Green, "IPv6 Enterprise Network Analysis - IP Layer 3 Focus", RFC 4852, April 2007.
[RFC4852]Bound，J.，Pouffary，Y.，Klynsma，S.，Chown，T.，和D.Green，“IPv6企业网络分析-IP层3焦点”，RFC 48522007年4月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[RFC4966]Aoun，C.和E.Davies，“将网络地址转换器-协议转换器（NAT-PT）移至历史状态的原因”，RFC 4966，2007年7月。
[RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 Deployment Scenarios in 802.16 Networks", RFC 5181, May 2008.
[RFC5181]Shin，M-K.，Han，Y-H.，Kim，S-E.，和D.Premec，“802.16网络中的IPv6部署场景”，RFC 5181，2008年5月。
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008.
[RFC5211]Curran，J.，“互联网转型计划”，RFC 52112008年7月。
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008.
[RFC5218]Thaler，D.和B.Aboba，“什么是成功的方案？”RFC 5218，2008年7月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，2010年5月。
[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月。
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[RFC6036]Carpenter，B.和S.Jiang，“IPv6部署的新兴服务提供商场景”，RFC 6036，2010年10月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月。
[RFC6127] Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios", RFC 6127, May 2011.
[RFC6127]Arkko，J.和M.Townsley，“IPv4耗尽和IPv4-IPv6共存场景”，RFC 6127，2011年5月。
[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月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年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月。
[networkworld.youtube] Marsan, C., "YouTube support of IPv6 seen in dramatic traffic spike", Network World article, February 2010, <http://www.networkworld.com/news/2010/ 020110-youtube-ipv6.html>.
[networkworld.youtube]Marsan，C.，“youtube对IPv6的支持出现在急剧的流量激增中”，网络世界文章，2010年2月<http://www.networkworld.com/news/2010/ 020110-youtube-ipv6.html>。
[shared-addressing-issues] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", Work in Progress, March 2011.
[共享地址问题]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，正在进行的工作，2011年3月。
[v6-in-mobile] Koodli, R., "Mobile Networks Considerations for IPv6 Deployment", Work in Progress, May 2011.
[v6移动版]Koodli，R.，“IPv6部署的移动网络注意事项”，进展中的工作，2011年5月。
The authors would like to thank the many people who have engaged in discussions around this topic over the years. Some of the material in this document comes originally from Fred Baker's presentation in a workshop in Shanghai [Baker.Shanghai]. In addition, the authors would like to thank Mark Townsley with whom Jari Arkko wrote an earlier document [RFC6127]. Brian Carpenter submitted an in-depth review and provided significant new text. Cameron Byrne provided significant feedback on the key recommendations in this memo. The authors would also like thank Dave Thaler, Alain Durand, Randy Bush, and Dan Wing, who have always provided valuable guidance in this field. Finally, the authors would like to thank Suresh Krishnan, Fredrik Garneij, Mohamed Boucadair, Remi Despres, Kurtis Lindqvist, Shawn Emery, Dan Romascanu, Tim Polk, Ralph Droms, Sean Turner, Tina Tsou, Nevil Brownlee, and Joel Jaeggli, who have commented on early versions of this memo.
作者要感谢多年来围绕这一主题进行讨论的许多人。本文档中的一些材料最初来自Fred Baker在上海[Baker.Shanghai]一个研讨会上的演讲。此外，作者还要感谢马克·汤斯利（MarkTownsley），贾里·阿尔科（Jari Arkko）曾与他共同撰写了一份早期文件[RFC6127]。Brian Carpenter提交了一份深入的评论，并提供了重要的新文本。Cameron Byrne就本备忘录中的关键建议提供了重要反馈。作者还要感谢Dave Thaler、Alain Durand、Randy Bush和Dan Wing，他们一直在这一领域提供有价值的指导。最后，作者要感谢Suresh Krishnan、Fredrik Garneij、Mohamed Boucadair、Remi Despres、Kurtis Lindqvist、Shawn Emery、Dan Romascanu、Tim Polk、Ralph Droms、Sean Turner、Tina Tsou、Nevil Brownlee和Joel Jaeggli，他们对本备忘录的早期版本发表了评论。
Authors' Addresses
作者地址
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@piuha.net
EMail: jari.arkko@piuha.net
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
美国加利福尼亚州圣巴巴拉市弗雷德·贝克思科系统公司，邮编：93117
EMail: fred@cisco.com
EMail: fred@cisco.com