Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 6127 Ericsson
Category: Informational M. Townsley
ISSN: 2070-1721 Cisco
May 2011
Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 6127 Ericsson
Category: Informational M. Townsley
ISSN: 2070-1721 Cisco
May 2011
IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios
IPv4耗尽和IPv4-IPv6共存场景
Abstract
摘要
When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition.
在设计IPv6时，预计从IPv4到IPv6的过渡将比经验所揭示的更加顺利和迅速。IPv4互联网的增长以及IPv4地址块的可用池在可预见的范围内将耗尽的预测突出表明迫切需要重新审视IPv6部署模型。本文档概述了部署场景，旨在帮助了解业界需要哪些类型的其他工具来帮助IPv4和IPv6共存和过渡。
This document was originally created as input to the Montreal co-existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition.
本文件最初是作为2008年10月蒙特利尔共存临时会议的投入而创建的，该会议导致Behave和Softwire工作组重新组建，以承担新的IPv4和IPv6共存工作。本文件作为当时思想的历史记录出版，但希望也能帮助读者理解当前IETF共存和过渡工具背后的基本原理。
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/rfc6127.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6127.
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 ....................................................2
2. Scenarios .......................................................4
2.1. Reaching the IPv4 Internet .................................4
2.1.1. NAT444 ..............................................5
2.1.2. Distributed NAT .....................................6
2.1.3. Recommendation ......................................8
2.2. Running Out of IPv4 Private Address Space ..................9
2.3. Enterprise IPv6-Only Networks .............................11
2.4. Reaching Private IPv4-Only Servers ........................13
2.5. Reaching IPv6-Only Servers ................................14
3. Security Considerations ........................................16
4. Conclusions ....................................................16
5. References .....................................................17
5.1. Normative References ......................................17
5.2. Informative References ....................................17
Appendix A. Acknowledgments .......................................20
1. Introduction ....................................................2
2. Scenarios .......................................................4
2.1. Reaching the IPv4 Internet .................................4
2.1.1. NAT444 ..............................................5
2.1.2. Distributed NAT .....................................6
2.1.3. Recommendation ......................................8
2.2. Running Out of IPv4 Private Address Space ..................9
2.3. Enterprise IPv6-Only Networks .............................11
2.4. Reaching Private IPv4-Only Servers ........................13
2.5. Reaching IPv6-Only Servers ................................14
3. Security Considerations ........................................16
4. Conclusions ....................................................16
5. References .....................................................17
5.1. Normative References ......................................17
5.2. Informative References ....................................17
Appendix A. Acknowledgments .......................................20
This document was originally created as input to the Montreal co-existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition.
本文件最初是作为2008年10月蒙特利尔共存临时会议的投入而创建的，该会议导致Behave和Softwire工作组重新组建，以承担新的IPv4和IPv6共存工作。本文件作为当时思想的历史记录出版，但希望也能帮助读者理解当前IETF共存和过渡工具背后的基本原理。
When IPv6 was designed, it was expected that IPv6 would be enabled, in part or in whole, while continuing to run IPv4 side-by-side on the same network nodes and hosts. This method of transition is referred to as "dual-stack" [RFC4213] and has been the prevailing method driving the specifications and available tools for IPv6 to date.
在设计IPv6时，预期IPv6将部分或全部启用，同时继续在相同的网络节点和主机上并排运行IPv4。这种转换方法被称为“双栈”[RFC4213]，是迄今为止推动IPv6规范和可用工具的主流方法。
Experience has shown that large-scale deployment of IPv6 takes time, effort, and significant investment. With IPv4 address pool depletion on the foreseeable horizon [HUSTON-IPv4], network operators and Internet Service Providers are being forced to consider network designs that no longer assume the same level of access to unique global IPv4 addresses. IPv6 alone does not alleviate this concern given the basic assumption that all hosts and nodes will be dual-stack until the eventual sunsetting of IPv4-only equipment. In short, the time-frames for the growth of the IPv4 Internet, the universal deployment of dual-stack IPv4 and IPv6, and the final transition to an IPv6-dominant Internet are not in alignment with what was originally expected.
经验表明，大规模部署IPv6需要时间、精力和大量投资。在可预见的地平线上的IPv4地址池耗尽[HuSTON-IPv4]，网络运营商和互联网服务提供商被迫考虑不再具有相同的对唯一的全球IPv4地址的访问级别的网络设计。考虑到所有主机和节点都将是双栈的基本假设，直到只有IPv4的设备最终消亡，IPv6本身并不能缓解这一担忧。简言之，IPv4互联网的发展、双栈IPv4和IPv6的普遍部署以及最终过渡到IPv6主导互联网的时间框架与最初的预期不一致。
While dual-stack remains the most well-understood approach to deploying IPv6 today, current realities dictate a re-assessment of the tools available for other deployment models that are likely to emerge. In particular, the implications of deploying multiple layers of IPv4 address translation need to be considered, as well as those associated with translation between IPv4 and IPv6, which led to the deprecation of [RFC2766] as detailed in [RFC4966]. This document outlines some of the scenarios where these address and protocol translation mechanisms could be useful, in addition to methods where carrying IPv4 over IPv6 may be used to assist in transition to IPv6 and co-existence with IPv4. We purposefully avoid a description of classic dual-stack methods, as well as IPv6-over-IPv4 tunneling. Instead, this document focuses on scenarios that are driving tools we have historically not been developing standard solutions around.
虽然双栈仍然是当今部署IPv6最为人熟知的方法，但当前的现实要求重新评估可能出现的其他部署模型可用的工具。特别是，需要考虑部署多层IPv4地址转换的影响，以及与IPv4和IPv6之间的转换相关的影响，这导致[RFC2766]被弃用，详见[RFC4966]。本文档概述了这些地址和协议转换机制可能有用的一些场景，以及在IPv6上承载IPv4可用于帮助过渡到IPv6并与IPv4共存的方法。我们有意避免描述经典的双栈方法，以及IPv6-over-IPv4隧道。相反，本文档将重点放在驱动工具的场景上，这些工具是我们过去没有开发过的标准解决方案。
It should be understood that the scenarios in this document represent new deployment models and are intended to complement, and not replace, existing ones. For instance, dual-stack continues to be the most recommended deployment model. Note that dual-stack is not limited to situations where all hosts can acquire public IPv4 addresses. A common deployment scenario is running dual-stack on the IPv6 side with public addresses, and on the IPv4 side with just one public address and a traditional IPv4 NAT. Generally speaking, offering native connectivity with both IP versions is preferred over the use of translation or tunneling mechanisms when sufficient address space is available.
应该理解，本文档中的场景代表新的部署模型，旨在补充而不是取代现有的部署模型。例如，双堆栈仍然是最推荐的部署模型。请注意，双堆栈并不限于所有主机都可以获取公共IPv4地址的情况。一种常见的部署方案是在IPv6端使用公共地址运行双堆栈，在IPv4端仅使用一个公共地址和传统的IPv4 NAT运行双堆栈。一般来说，当有足够的地址空间可用时，提供两个IP版本的本机连接优于使用转换或隧道机制。
This section identifies five deployment scenarios that we believe have a significant level of near-to-medium-term demand somewhere on the globe. We will discuss these in the following sections, while walking through a bit of the design space to get an understanding of the types of tools that could be developed to solve each. In particular, we want the reader to consider for each scenario what type of new equipment must be introduced in the network, and where; which nodes must be changed in some way; and which nodes must work together in an interoperable manner via a new or existing protocol.
本节确定了五种部署方案，我们认为这些方案在全球某个地方具有相当大的近中期需求。我们将在以下部分中讨论这些问题，同时浏览一些设计空间，以了解可以开发哪些类型的工具来解决每个问题。特别是，我们希望读者考虑每种情况下，必须在网络中引入什么类型的新设备，以及在哪里；哪些节点必须以某种方式更改；以及哪些节点必须通过新的或现有的协议以可互操作的方式协同工作。
The five scenarios are:
这五种情况是：
o Reaching the IPv4 Internet with less than one global IPv4 address per subscriber or subscriber household available (Section 2.1).
o 以每个用户或用户家庭少于一个全局IPv4地址访问IPv4 Internet（第2.1节）。
o Running a large network needing more addresses than those available in private RFC 1918 address space (Section 2.2).
o 运行需要比专用RFC 1918地址空间中可用地址更多地址的大型网络（第2.2节）。
o Running an IPv6-only network for operational simplicity as compared to dual-stack, while still needing access to the global IPv4 Internet for some, but not all, connectivity (Section 2.3).
o 与双协议栈相比，运行仅限IPv6的网络以简化操作，同时仍需要访问全球IPv4互联网以实现部分（但不是全部）连接（第2.3节）。
o Reaching one or more privately addressed IPv4-only servers via IPv6 (Section 2.4).
o 通过IPv6（第2.4节）到达一个或多个专用寻址IPv4服务器。
o Accessing IPv6-only servers from IPv4-only clients (Section 2.5).
o 从仅IPv4客户端访问仅IPv6服务器（第2.5节）。
+----+ +---------------+
IPv4 host(s)-----+ GW +------IPv4-------------| IPv4 Internet |
+----+ +---------------+
+----+ +---------------+
IPv4 host(s)-----+ GW +------IPv4-------------| IPv4 Internet |
+----+ +---------------+
<---private v4--->NAT<--------------public v4----------------->
<---private v4--->NAT<--------------public v4----------------->
Figure 1: Accessing the IPv4 Internet Today
图1：今天访问IPv4 Internet
Figure 1 shows a typical model for accessing the IPv4 Internet today, with the gateway device implementing a Network Address and Port Translation (NAPT, or more simply referred to in this document as NAT). The NAT function serves a number of purposes, one of which is to allow more hosts behind the gateway (GW) than there are IPv4 addresses presented to the Internet. This multiplexing of IP addresses comes at great cost to the original end-to-end model of the Internet, but nonetheless is the dominant method of access today, particularly to residential subscribers.
图1显示了当前访问IPv4 Internet的典型模型，网关设备实现了网络地址和端口转换（NAPT，或者在本文中简称为NAT）。NAT功能有许多用途，其中之一是允许网关（GW）后面的主机数量超过提供给Internet的IPv4地址。这种IP地址的多路复用对最初的端到端互联网模式来说代价高昂，但仍然是当今主要的接入方式，特别是对住宅用户。
Taking the typical residential subscriber as an example, each subscriber line is allocated one global IPv4 address for it to use with as many devices as the NAT GW and local network 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.
以典型的住宅用户为例，每个用户线路分配一个全局IPv4地址，以便与NAT GW和本地网络可以处理的尽可能多的设备一起使用。随着IPv4地址空间变得更加受限，并且没有大量移动到IPv6，预计服务提供商将被迫将单个全局IPv4地址分配给多个订户。事实上，在某些部署中，情况已经如此。
When there is less than one address per subscriber at a given time, address multiplexing must be performed at a location where visibility to more than one subscriber can be realized. The most obvious place for this is within the service provider network itself, requiring the service provider to acquire and operate NAT equipment to allow sharing of addresses across multiple subscribers. For deployments where the GW is owned and operated by the customer, however, this becomes operational overhead for the Internet Service Provider (ISP), for which the ISP will no longer be able to rely on the customer and the seller of the GW device.
当在给定时间每个订户少于一个地址时，必须在能够实现对多个订户的可见性的位置执行地址多路复用。最明显的地方是服务提供商网络本身，要求服务提供商获取并操作NAT设备，以允许跨多个订户共享地址。但是，对于由客户拥有和运营GW的部署，这将成为互联网服务提供商（ISP）的运营开销，ISP将不再能够依赖客户和GW设备的卖方。
This new address translation node has been termed a "Carrier Grade NAT", or CGN [NISHITANI-CGN]. The CGN's insertion into the ISP network is shown in Figure 2.
这个新的地址转换节点被称为“载波级NAT”，或CGN[NISHITANI-CGN]。CGN插入ISP网络如图2所示。
+----+ +---+ +-------------+
IPv4 host(s)-----+ GW +------IPv4---------+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
+----+ +---+ +-------------+
IPv4 host(s)-----+ GW +------IPv4---------+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
<---private v4--->NAT<----private v4------>NAT<----public v4--->
<---private v4--->NAT<----private v4------>NAT<----public v4--->
Figure 2: Employing Two NAT Devices: NAT444
图2：使用两个NAT设备：NAT444
This approach is known as "NAT444" or "Double-NAT" and is discussed further in [NAT-PT].
这种方法被称为“NAT444”或“双NAT”，并在[NAT-PT]中进一步讨论。
It is important to note that while multiplexing of IPv4 addresses is occurring here at multiple levels, there is no aggregation of NAT state between the GW and the CGN. Every flow that is originated in the subscriber home is represented as duplicate state in the GW and the CGN. For example, if there are 4 PCs in a subscriber home, each with 25 open TCP sessions, both the GW and the CGN must track 100 sessions each for that subscriber line.
需要注意的是，虽然IPv4地址的多路复用在多个级别上发生，但GW和CGN之间没有NAT状态的聚合。在GW和CGN中，起源于用户家庭的每个流都表示为重复状态。例如，如果一个用户家庭中有4台PC，每台都有25个开放的TCP会话，那么GW和CGN必须为该用户线路跟踪100个会话。
NAT444 has the enticing property that it seems, at first glance, that the CGN can be deployed without any change to the GW device or other node in the network. While it is true that a GW that can accept a lease for a global IPv4 address would very likely accept a translated
NAT444具有诱人的特性，乍一看，CGN可以在不改变GW设备或网络中其他节点的情况下部署。诚然，能够接受全局IPv4地址租约的GW很可能会接受转换后的IPv4地址
IPv4 address as well, the CGN is neither transparent to the GW nor to the subscriber. In short, it is a very different service model to offer a translated IPv4 address versus a global IPv4 address to a customer. While many things may continue to work in both environments, some end-host applications may break, and GW port-mapping functionality will likely cease to work reliably. Further, if addresses between the subscriber network and service provider network overlap [ISP-SHARED-ADDR], ambiguous routes in the GW could lead to misdirected or black-holed traffic. Resolving this overlap through allocation of new private address space is difficult, as many existing devices rely on knowing what address ranges represent private addresses [IPv4-SPACE-ISSUES].
IPv4地址，CGN对GW和订户都不是透明的。简而言之，向客户提供转换后的IPv4地址与提供全局IPv4地址是截然不同的服务模式。虽然在这两种环境中许多事情可能会继续工作，但一些终端主机应用程序可能会中断，而GW端口映射功能可能会停止可靠工作。此外，如果用户网络和服务提供商网络之间的地址重叠[ISP-SHARED-ADDR]，则GW中的不明确路由可能会导致错误定向或黑洞流量。通过分配新的专用地址空间来解决这种重叠是困难的，因为许多现有设备依赖于知道哪些地址范围代表专用地址[IPv4空间问题]。
Network operations that had previously been tied to a single IPv4 address for a subscriber would need to be considered when deploying NAT444 as well. These may include troubleshooting, operations, accounting, logging and legal intercept, Quality of Service (QoS) functions, anti-spoofing and security, backoffice systems, etc. Ironically, some of these considerations overlap with the kinds of considerations one needs to perform when deploying IPv6.
在部署NAT444时，还需要考虑以前绑定到订户的单个IPv4地址的网络操作。这些可能包括故障排除、操作、记帐、日志记录和合法拦截、服务质量（QoS）功能、反欺骗和安全、后台系统等。具有讽刺意味的是，其中一些注意事项与部署IPv6时需要执行的各种注意事项重叠。
Consequences aside, NAT444 service is already being deployed in some networks for residential broadband service. It is safe to assume that this trend will likely continue in the face of tightening IPv4 address availability. The operational considerations of NAT444 need to be well-documented.
撇开后果不谈，NAT444服务已经在一些网络中部署，用于住宅宽带服务。可以安全地假设，在IPv4地址可用性日益紧张的情况下，这种趋势很可能会继续下去。NAT444的操作注意事项需要详细记录。
NAT444 assumes that the global IPv4 address offered to a residential subscriber today will simply be replaced with a single translated address. In order to try and circumvent performing NAT twice, and since the address being offered is no longer a global address, a service provider could begin offering a subnet of translated IPv4 addresses in hopes that the subscriber would route IPv4 in the GW rather than NAT. The same would be true if the GW was known to be an IP-unaware bridge. This makes assumptions on whether the ISP can enforce policies, or even identify specific capabilities, of the GW. Once we start opening the door to making changes at the GW, we have increased the potential design space considerably. The next section covers the same problem scenario of reaching the IPv4 Internet in the face of IPv4 address depletion, but with the added wrinkle that the GW can be updated or replaced along with the deployment of a CGN (or CGN-like) node.
NAT444假设今天提供给住宅用户的全局IPv4地址将被一个转换后的地址所取代。为了尝试和避免两次执行NAT，并且由于提供的地址不再是全局地址，服务提供商可以开始提供转换后的IPv4地址的子网，希望订户在GW而不是NAT中路由IPv4。如果已知GW是一个IP网桥，则情况也是如此。这就对ISP是否能够执行GW的策略，甚至识别GW的特定功能做出了假设。一旦我们开始打开大门，对GW进行更改，我们就大大增加了潜在的设计空间。下一节将讨论在IPv4地址耗尽的情况下到达IPv4 Internet的相同问题场景，但增加了一个问题，即GW可以随着CGN（或类似CGN）节点的部署而更新或替换。
Increasingly, service providers offering "triple-play" services own and manage a highly functional GW in the subscriber home. These managed GWs generally have rather tight integration with the service
提供“三网融合”服务的服务提供商越来越多地拥有并管理用户家庭中功能强大的GW。这些受管理的GWs通常与服务紧密集成
provider network and applications. In these types of deployments, we can begin to consider what other possibilities exist besides NAT444 by assuming cooperative functionality between the CGN and the GW.
提供商网络和应用程序。在这些类型的部署中，我们可以通过考虑CGN和GW之间的协作功能来开始考虑除了NAT44之外还存在什么其他的可能性。
If the connection between the GW and the CGN is a point-to-point link (a common configuration between the GW and the "IP edge" in a number of access architectures), NAT-like functionality may be "split" between the GW and the CGN rather than performing NAT444 as described in the previous section.
如果GW和CGN之间的连接是点对点链路（在许多接入架构中GW和“IP边缘”之间的公共配置），则类似NAT的功能可以在GW和CGN之间“分割”，而不是如前一节所述执行NAT444。
one frac addr one public addr
+----+ +---+ +-------------+
IPv4 host(s)-----+ GW +-----p2p link------+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
one frac addr one public addr
+----+ +---+ +-------------+
IPv4 host(s)-----+ GW +-----p2p link------+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
<---private v4---> NAT <----public v4--->
(distributed,
over a p2p link)
<---private v4---> NAT <----public v4--->
(distributed,
over a p2p link)
Figure 3: Distributed-NAT Service
图3：分布式NAT服务
In this approach, multiple GWs share a common public IPv4 address, but with separate, non-overlapping port ranges. Each such address/ port range pair is defined as a "fractional address". Each home gateway can use the address as if it were its own public address, except that only a limited port range is available to the gateway. The CGN is aware of the port ranges, which may be assigned in different ways, for instance during DHCP lease acquisition or dynamically when ports are needed [v6OPS-APBP]. The CGN directs traffic to the fractional address towards that subscriber's GW device. This method has the advantage that the more complicated aspects of the NAT function (Application Level Gateways (ALGs), port mapping, etc.) remain in the GW, augmented only by the restricted port range allocated to the fractional address for that GW. The CGN is then free to operate in a fairly stateless manner, forwarding traffic based on IP address and port ranges and not tracking any individual flows from within the subscriber network. There are obvious scaling benefits to this approach within the CGN node, with the tradeoff of complexity in terms of the number of nodes and protocols that must work together in an interoperable manner. Further, the GW is still receiving a global IPv4 address, albeit only a "portion" of one in terms of available port usage. There are still outstanding questions in terms of how to handle protocols that run directly over IP and cannot use the divided port number ranges, and how to handle fragmented packets, but the benefit is that we are no longer burdened by two layers of NAT as in NAT444.
在这种方法中，多个GWs共享一个公共IPv4地址，但具有独立的、不重叠的端口范围。每个这样的地址/端口范围对被定义为“分数地址”。每个家庭网关都可以像使用自己的公共地址一样使用该地址，但网关只能使用有限的端口范围。CGN知道端口范围，可以以不同的方式分配，例如在DHCP租约获取期间或需要端口时动态分配[v6OPS APBP]。CGN将流量定向到该用户的GW设备的分数地址。这种方法的优点是，NAT功能的更复杂方面（应用级网关（ALG）、端口映射等）仍保留在GW中，仅通过分配给该GW的分数地址的受限端口范围进行扩展。然后，CGN可以自由地以相当无状态的方式运行，根据IP地址和端口范围转发流量，而不跟踪来自订户网络内的任何单个流量。这种方法在CGN节点内具有明显的扩展优势，在节点数量和协议数量方面，必须以互操作的方式协同工作，以权衡复杂性。此外，GW仍在接收一个全局IPv4地址，尽管就可用端口使用而言，它只是其中的一个“部分”。在如何处理直接在IP上运行且不能使用分割端口号范围的协议，以及如何处理分段数据包方面，仍然存在一些悬而未决的问题，但好处是我们不再像NAT444那样被两层NAT所困扰。
Not all access architectures provide a natural point-to-point link between the GW and the CGN to tie into. Further, the CGN may not be incorporated into the IP edge device in networks that do have point-to-point links. For these cases, we can build our own point-to-point link using a tunnel. A tunnel is essentially a point-to-point link that we create when needed [INTAREA-TUNNELS]. This is illustrated in Figure 4.
并非所有接入架构都能在GW和CGN之间提供自然的点对点连接。此外，在具有点到点链路的网络中，CGN可以不被合并到IP边缘设备中。对于这些情况，我们可以使用隧道构建自己的点对点链路。隧道本质上是我们在需要时创建的点对点链接[Intrea-TUNNELS]。这如图4所示。
one frac addr one public addr
+----+ +---+ +-------------+
IPv4 host(s)-----+ GW +======tunnel=======+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
one frac addr one public addr
+----+ +---+ +-------------+
IPv4 host(s)-----+ GW +======tunnel=======+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
<---private v4---> NAT <----public v4--->
(distributed,
over a tunnel)
<---private v4---> NAT <----public v4--->
(distributed,
over a tunnel)
Figure 4: Point-to-Point Link Created through a Tunnel
图4：通过隧道创建的点对点链接
Figure 4 is essentially the same as Figure 3, except the data link is created with a tunnel. The tunnel could be created in any number of ways, depending on the underlying network.
图4基本上与图3相同，只是数据链路是通过隧道创建的。根据底层网络的不同，可以通过多种方式创建隧道。
At this point, we have used a tunnel or point-to-point link with coordinated operation between the GW and the CGN in order to keep most of the NAT functionality in the GW.
在这一点上，我们在GW和CGN之间使用了具有协调运行的隧道或点对点链路，以保持GW中的大部分NAT功能。
Given the assumption of a point-to-point link between the GW and the CGN, the CGN could perform the NAT function, allowing private, overlapping space to all subscribers. For example, each subscriber GW may be assigned the same 10.0.0.0/8 address space (or all RFC 1918 [RFC1918] space for that matter). The GW then becomes a simple "tunneling router", and the CGN takes on the full NAT role. One can think of this design as effectively a layer-3 VPN, but with Virtual-NAT tables rather than Virtual-Routing tables.
假设GW和CGN之间存在点对点链路，CGN可以执行NAT功能，允许所有用户使用私有重叠空间。例如，每个订户GW可被分配相同的10.0.0.0/8地址空间（或就此而言的所有RFC 1918[RFC1918]空间）。然后，GW成为一个简单的“隧道路由器”，CGN承担全部NAT角色。人们可以将这种设计视为一种有效的第3层VPN，但是使用虚拟NAT表而不是虚拟路由表。
This section deals strictly with the problem of reaching the IPv4 Internet with limited public address space for each device in a network. We explored combining NAT functions and tunnels between the GW and the CGN to obtain similar results with different design tradeoffs. The methods presented can be summarized as:
本节严格处理在网络中每个设备的公共地址空间有限的情况下访问IPv4 Internet的问题。我们探索了在GW和CGN之间结合NAT功能和隧道，以获得不同设计权衡的类似结果。提出的方法可概括为：
a. Double-NAT (NAT444)
a. 双NAT（NAT444）
b. Single-NAT at CGN with a subnet and routing at the GW
b. CGN处的单个NAT，在GW处具有子网和路由
c. Tunnel/link + fractional IP (NAT at GW, port-routing at CGN)
c. 隧道/链路+部分IP（GW处的NAT，CGN处的端口路由）
d. Tunnel/link + Single-NAT with overlapping RFC 1918 ("Virtual NAT" tables and routing at the GW)
d. 隧道/链路+具有重叠RFC 1918的单个NAT（“虚拟NAT”表和GW处的路由）
In all of the methods above, the GW could be logically moved into a single host, potentially eliminating one level of NAT by that action alone. As long as the hosts themselves need only a single IPv4 address, methods b and d obviously are of little interest. This leaves methods a and c as the more interesting methods in cases where there is no analogous GW device (such as a campus network).
在上述所有方法中，GW可以逻辑地移动到单个主机中，仅通过该操作就可能消除一级NAT。只要主机本身只需要一个IPv4地址，方法b和d显然就没有什么意义。在没有类似的GW设备（如校园网）的情况下，方法a和c是更有趣的方法。
This document recommends the development of new guidelines and specifications to address the above methods. Cases where the home gateway both can and cannot be modified should be addressed.
本文件建议制定新的指南和规范，以解决上述方法。应解决家庭网关既可以修改也不能修改的情况。
In addition to public address space depletion, very large privately addressed networks are reaching exhaustion of RFC 1918 space on local networks as well. Very large service provider networks are prime candidates for this. Private address space is used locally in ISPs for a variety of things, including:
除了公共广播空间耗尽之外，非常大的私有寻址网络也在耗尽本地网络上的RFC1918空间。非常大的服务提供商网络是这方面的首选。专用地址空间在ISP中本地用于各种用途，包括：
o Control and management of service provider devices in subscriber premises (cable modems, set-top boxes, and so on).
o 控制和管理用户场所中的服务提供商设备（电缆调制解调器、机顶盒等）。
o Addressing the subscriber's NAT devices in a Double-NAT arrangement.
o 以双NAT安排寻址订户的NAT设备。
o "Walled garden" data, voice, or video services.
o “围墙花园”数据、语音或视频服务。
Some providers deal with this problem by dividing their network into parts, each on its own copy of the private space. However, this limits the way services can be deployed and what management systems can reach what devices. It is also operationally complicated in the sense that the network operators have to understand which private scope they are in.
一些提供商通过将他们的网络分成几个部分来解决这个问题，每个部分都有自己的私有空间副本。但是，这限制了服务的部署方式以及管理系统可以访问哪些设备。网络运营商必须了解其所处的私有范围，这在操作上也是复杂的。
Tunnels were used in the previous section to facilitate distribution of a single global IPv4 address across multiple endpoints without using NAT, or to allow overlapping address space to GWs or hosts connected to a CGN. The kind of tunnel or link was not specified. If the tunnel used carries IPv4 over IPv6, the portion of the IPv6 network traversed naturally need not be IPv4-capable, and need not utilize IPv4 addresses, private or public, for the tunnel traffic to traverse the network. This is shown in Figure 5.
在上一节中使用了隧道，以便于在不使用NAT的情况下跨多个端点分发单个全局IPv4地址，或者允许GWs或连接到CGN的主机具有重叠的地址空间。未指定隧道或连接的类型。如果所使用的隧道通过IPv6承载IPv4，则自然穿越的IPv6网络部分不需要具备IPv4能力，也不需要利用IPv4地址（专用或公用），以便隧道流量穿越网络。这如图5所示。
IPv6-only network
+----+ +---+ +-------------+
IPv4 host--------+ GW +=======tunnel========+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
IPv6-only network
+----+ +---+ +-------------+
IPv4 host--------+ GW +=======tunnel========+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
<---private v4----> <----- v4 over v6 -----> <---public v4---->
<---private v4----> <----- v4 over v6 -----> <---public v4---->
Figure 5: Running IPv4 over an IPv6-Only Network
图5：在仅限IPv6的网络上运行IPv4
Each of the four approaches (a, b, c, and d) from the Section 2.1 scenario could be applied here, and for brevity each iteration is not specified in full here. The models are essentially the same, just that the tunnel is over an IPv6 network and carries IPv4 traffic. Note that while there are numerous solutions for carrying IPv6 over IPv4, this reverse mode is somewhat of an exception (one notable exception being the Softwire working group, as seen in [RFC4925]).
第2.1节场景中的四种方法（a、b、c和d）中的每一种都可以在这里应用，为了简洁起见，这里没有详细说明每个迭代。这些模型本质上是相同的，只是隧道通过IPv6网络，承载IPv4流量。请注意，虽然有许多通过IPv4承载IPv6的解决方案，但这种反向模式在某种程度上是个例外（一个值得注意的例外是Softwire工作组，如[RFC4925]所示）。
Once we have IPv6 to the GW (or host, if we consider the GW embedded in the host), enabling IPv6 and IPv4 over the IPv6 tunnel allows for dual-stack operation at the host or network behind the GW device. This is depicted in Figure 6:
一旦我们有了IPv6到GW（或者主机，如果我们考虑在主机中嵌入GW），在IPv6隧道上启用IPv6和IPv4允许在GW设备后面的主机或网络上进行双栈操作。如图6所示：
+----+ +-------------+
IPv6 host-----+ | +------------------+IPv6 Internet|
| +---IPv6-----+ +-------------+
dual-stack host-+ GW |
| | +---+ +-------------+
IPv4 host-----+ +===v4-over-v6 tunnel====+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
+----+ +-------------+
IPv6 host-----+ | +------------------+IPv6 Internet|
| +---IPv6-----+ +-------------+
dual-stack host-+ GW |
| | +---+ +-------------+
IPv4 host-----+ +===v4-over-v6 tunnel====+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
<-----------private v4 (partially in tunnel)-->NAT<---public v4---->
<-----------------------------public v6---------------------------->
<-----------private v4 (partially in tunnel)-->NAT<---public v4---->
<-----------------------------public v6---------------------------->
Figure 6: "Dual-Stack Lite" Operation over an IPv6-Only Network
图6：仅IPv6网络上的“双栈Lite”操作
In [DUAL-STACK-LITE], this is referred to as "dual-stack lite", bowing to the fact that it is dual-stack at the gateway, but not at the network. As introduced in Section 2.1, if the CGN here is a full functioning NAT, hosts behind a dual-stack lite gateway can support IPv4-only and IPv6-enabled applications across an IPv6-only network without provisioning a unique IPv4 address to each gateway. In fact, every gateway may have the same address.
在[DUAL-STACK-LITE]中，这被称为“DUAL-STACK-LITE”，因为它在网关上是双堆栈，但在网络上不是。如第2.1节所述，如果此处的CGN是一个功能完整的NAT，则双栈lite网关后面的主机可以跨仅IPv6网络支持仅IPv4和启用IPv6的应用程序，而无需为每个网关提供唯一的IPv4地址。事实上，每个网关可能都有相同的地址。
While the high-level problem space in this scenario is how to alleviate local usage of IPv4 addresses within a service provider network, the solution direction identified with IPv6 has interesting operational properties that should be pointed out. By tunneling IPv4 over IPv6 across the service provider network, the separate problems
虽然此场景中的高级问题空间是如何减轻服务提供商网络中IPv4地址的本地使用，但IPv6确定的解决方案方向具有值得指出的有趣的操作特性。通过在服务提供商网络上通过IPv6隧道传输IPv4，可以解决不同的问题
of transitioning the service provider network to IPv6, deploying IPv6 to subscribers, and continuing to provide IPv4 service can all be decoupled. The service provider could deploy IPv6 internally, turn off IPv4 internally, and still carry IPv4 traffic across the IPv6 core for end users. In the extreme case, all of that IPv4 traffic need not be provisioned with different IPv4 addresses for each endpoint, as there is not IPv4 routing or forwarding within the network. Thus, there are no issues with IPv4 renumbering, address space allocation, etc. within the network itself.
将服务提供商网络过渡到IPv6、向订户部署IPv6以及继续提供IPv4服务的过程都可以解耦。服务提供商可以在内部部署IPv6，在内部关闭IPv4，并且仍然为最终用户跨IPv6核心承载IPv4流量。在极端情况下，由于网络中不存在IPv4路由或转发，因此不需要为每个端点为所有IPv4流量提供不同的IPv4地址。因此，在网络本身内IPv4重新编号、地址空间分配等方面没有问题。
It is recommended that the IETF develop tools to address this scenario for both a host and the GW. It is assumed that both endpoints of the tunnel can be modified to support these new tools.
建议IETF开发工具来解决主机和GW的这种情况。假设可以修改隧道的两个端点以支持这些新工具。
This scenario is about allowing an IPv6-only host or a host that has no interfaces connected to an IPv4 network to reach servers on the IPv4 Internet. This is an important scenario for what we sometimes call "greenfield" deployments. One example is an enterprise network that wishes to operate only IPv6 for operational simplicity, but still wishes to reach the content in the IPv4 Internet. For instance, a new office building may be provisioned with IPv6 only. This is shown in Figure 7.
此场景是关于允许仅IPv6主机或没有连接到IPv4网络的接口的主机访问IPv4 Internet上的服务器。这是我们有时称之为“绿地”部署的一个重要场景。一个例子是一个企业网络，它希望只运行IPv6以简化操作，但仍然希望访问IPv4 Internet中的内容。例如，新的办公楼可能仅配备IPv6。如图7所示。
+----+ +-------------+
| +------------------+IPv6 Internet+
| | +-------------+
IPv6 host-----------------+ GW |
| | +-------------+
| +------------------+IPv4 Internet+
+----+ +-------------+
+----+ +-------------+
| +------------------+IPv6 Internet+
| | +-------------+
IPv6 host-----------------+ GW |
| | +-------------+
| +------------------+IPv4 Internet+
+----+ +-------------+
<-------------------------public v6----------------------------->
<-------public v6--------->NAT<----------public v4-------------->
<-------------------------public v6----------------------------->
<-------public v6--------->NAT<----------public v4-------------->
Figure 7: Enterprise IPv6-Only Network
图7：仅限企业IPv6的网络
Other cases that have been mentioned include "greenfield" wireless service provider networks and sensor networks. This enterprise IPv6- only scenario bears a striking resemblance to the Section 2.2 scenario as well, if one considers a particularly large enterprise network that begins to resemble a service provider network.
提到的其他案例包括“绿地”无线服务提供商网络和传感器网络。如果考虑一个开始类似于服务提供商网络的特别大的企业网络，那么这个仅限企业IPv6的场景也与第2.2节的场景非常相似。
In the Section 2.2 scenario, we dipped into design space enough to illustrate that the service provider was able to implement an IPv6- only network to ease their addressing problems via tunneling. This came at the cost of touching two devices on the edges of this
在第2.2节场景中，我们深入设计了足够多的空间，以说明服务提供商能够实现一个仅限IPv6的网络，从而通过隧道来缓解其寻址问题。这样做的代价是，在这张纸的边缘触摸两台设备
network; both the GW and the CGN have to support IPv6 and the tunneling mechanism over IPv6. The greenfield enterprise scenario is different from that one in the sense that there is only one place that the enterprise can easily modify: the border between its network and the IPv4 Internet. Obviously, the IPv4 Internet operates the way it already does. But in addition, the hosts in the enterprise network are commercially available devices, personal computers with existing operating systems. While we consider in this scenario that all of the devices on the network are "modern" dual-stack-capable devices, we do not want to have to rely upon kernel-level modifications to these operating systems. This restriction drives us to a "one box" type of solution, where IPv6 can be translated into IPv4 to reach the public Internet. This is one situation where new or improved IETF specifications could have an effect on the user experience in these networks. In fairness, it should be noted that even a network-based solution will take time and effort to deploy. This is essentially, again, a tradeoff between one new piece of equipment in the network, or a cooperation between two.
网络GW和CGN都必须支持IPv6和IPv6上的隧道机制。绿地企业场景与该场景不同，因为只有一个地方企业可以轻松修改：其网络和IPv4互联网之间的边界。显然，IPv4互联网的运行方式与以往相同。但除此之外，企业网络中的主机是商用设备，即具有现有操作系统的个人计算机。虽然我们认为，在这种情况下，网络上的所有设备都是“现代”的双栈能力设备，但我们不希望依赖于对这些操作系统的内核级修改。这一限制促使我们采用“一箱式”解决方案，在这种解决方案中，IPv6可以转换为IPv4以到达公共互联网。在这种情况下，新的或改进的IETF规范可能会对这些网络中的用户体验产生影响。公平地说，应该注意，即使是基于网络的解决方案也需要时间和精力来部署。这本质上也是网络中一个新设备之间的折衷，或者是两个设备之间的合作。
One approach to deal with this environment is to provide an application-level proxy at the edge of the network (GW). For instance, if the only application that needs to reach the IPv4 Internet is the web, then an HTTP/HTTPS proxy can easily convert traffic from IPv6 into IPv4 on the outside.
处理这种环境的一种方法是在网络边缘（GW）提供应用程序级代理。例如，如果需要访问IPv4 Internet的唯一应用程序是web，那么HTTP/HTTPS代理可以在外部轻松地将IPv6的流量转换为IPv4。
Another more generic approach is to employ an IPv6-to-IPv4 translator device. Different types of translation schemes are discussed in [NAT-PT], [RFC6144], [RFC6145], and [RFC6052]. NAT64 is one example of a translation scheme falling under this category [RFC6147] [RFC6146].
另一种更通用的方法是使用IPv6到IPv4转换器设备。[NAT-PT]、[RFC6144]、[RFC6145]和[RFC6052]中讨论了不同类型的翻译方案。NAT64是属于该类别的翻译方案的一个示例[RFC6147][RFC6146]。
Translation will in most cases have some negative consequences for the end-to-end operation of Internet protocols. For instance, the issues with Network Address Translation - Protocol Translation (NAT-PT) [RFC2766] have been described in [RFC4966]. It is important to note that the choice of translation solution, and the assumptions about the network in which it is used, impact the consequences. A translator for the general case has a number of issues that a translator for a more specific situation may not have at all.
在大多数情况下，翻译会对互联网协议的端到端操作产生一些负面影响。例如，网络地址转换-协议转换（NAT-PT）[RFC2766]的问题已在[RFC4966]中描述。需要注意的是，翻译解决方案的选择以及对使用该解决方案的网络的假设会影响结果。一般情况下的翻译人员有许多问题，而更具体情况下的翻译人员可能根本没有这些问题。
It is recommended that the IETF develop tools to address this scenario. These tools need to allow existing IPv6 hosts to operate unchanged.
建议IETF开发工具来解决该场景。这些工具需要允许现有IPv6主机保持不变地运行。
This section discusses the specific problem of IPv4-only-capable server farms that no longer can be allocated a sufficient number of public addresses. It is expected that for individual servers, addresses are going to be available for a long time in a reasonably easy manner. However, a large server farm may require a large enough block of addresses that it is either not feasible to allocate one or it becomes economically desirable to use the addresses for other purposes.
本节讨论仅支持IPv4的服务器场的特定问题，这些服务器场不再能够分配足够数量的公共地址。预计对于单个服务器，地址将以一种相当简单的方式长期可用。但是，大型服务器场可能需要足够大的地址块，因此分配一个地址是不可行的，或者出于其他目的使用这些地址在经济上是可取的。
Another use case for this scenario involves a service provider that is capable of acquiring a sufficient number of IPv4 addresses, and has already done so. However, the service provider also simply wishes to start to offer an IPv6 service but without yet touching the server farm (that is, without upgrading the server farm to IPv6).
此场景的另一个用例涉及能够获取足够数量的IPv4地址的服务提供商，并且已经这样做了。但是，服务提供商也只是希望开始提供IPv6服务，但不涉及服务器场（即，不将服务器场升级到IPv6）。
One option available in such a situation is to move those servers and their clients to IPv6. However, moving to IPv6 involves not just the cost of the IPv6 connectivity, but the cost of moving the application itself from IPv4 to IPv6. So, in this case, the server farm is IPv4- only, there is an increasing cost for IPv4 connectivity, and there is an expensive bill for moving server infrastructure to IPv6. What can be done?
在这种情况下可用的一个选项是将这些服务器及其客户端移动到IPv6。然而，迁移到IPv6不仅涉及IPv6连接的成本，还涉及将应用程序本身从IPv4迁移到IPv6的成本。因此，在本例中，服务器场仅限于IPv4，IPv4连接的成本不断增加，将服务器基础结构移动到IPv6的费用也很昂贵。可以做些什么？
If the clients are IPv4-only as well, the problem is a hard one. This issue is dealt with in more depth in Section 2.5. However, there are important cases where large sets of clients are IPv6- capable. In these cases, it is possible to place the server farm in private IPv4 space and arrange some of the gateway service from IPv6 to IPv4 to reach the servers. This is shown in Figure 8.
如果客户端也是IPv4，那么问题就很难解决。第2.5节将更深入地讨论这个问题。但是，在一些重要的情况下，大型客户端集支持IPv6。在这些情况下，可以将服务器场放置在专用IPv4空间中，并将一些从IPv6到IPv4的网关服务安排到服务器。如图8所示。
+----+
IPv6 host(s)-------(Internet)-----+ GW +------Private IPv4 servers
+----+
+----+
IPv6 host(s)-------(Internet)-----+ GW +------Private IPv4 servers
+----+
<---------public v6--------------->NAT<------private v4---------->
<---------public v6--------------->NAT<------private v4---------->
Figure 8: Reaching Servers in Private IPv4 Space
图8：到达专用IPv4空间中的服务器
One approach to implement this is to use NAT64 to translate IPv6 into private IPv4 addresses. The private IPv4 addresses are mapped into IPv6 addresses within one or more known prefixes. The GW at the edge of the server farm is aware of the mapping, as is the Domain Name
实现这一点的一种方法是使用NAT64将IPv6转换为专用IPv4地址。专用IPv4地址映射到一个或多个已知前缀内的IPv6地址。服务器场边缘的GW和域名都知道映射
System (DNS). AAAA records for each server name are given an IPv6 address that corresponds to the mapped private IPv4 address. Thus, each privately addressed IPv4 server is given a public IPv6 presentation. No Application Level Gateway for DNS (DNS-ALG) is needed in this case, contrary to what NAT-PT would require, for instance.
系统（DNS）。为每个服务器名称的AAAA记录提供一个与映射的专用IPv4地址相对应的IPv6地址。因此，每个私有寻址的IPv4服务器都有一个公共IPv6表示。在这种情况下，不需要DNS的应用程序级网关（DNS-ALG），例如，与NAT-PT的要求相反。
This is very similar to the Section 2.3 scenario where we typically think of a small site with IPv6 needing to reach the public IPv4 Internet. The difference here is that we assume not a small IPv6 site, but the whole of the IPv6 Internet needing to reach a small IPv4 site. This example was driven by the enterprise network with IPv4 servers, but could be scaled down to the individual subscriber home level as well. Here, the same technique could be used to, say, access an IPv4 webcam in the home from the IPv6 Internet. All that is needed is the ability to update AAAA records appropriately, an IPv6 client (which could use Teredo [RFC4380] or some other method to obtain IPv6 reachability), and the NAT64 mechanism. In this sense, this method looks much like a "NAT/firewall bypass" function.
这与第2.3节的场景非常相似，我们通常认为一个带有IPv6的小型站点需要连接到公共IPv4互联网。这里的区别在于，我们假设不是一个小的IPv6站点，而是整个IPv6 Internet需要到达一个小的IPv4站点。这个示例是由具有IPv4服务器的企业网络驱动的，但也可以缩小到单个订户家庭级别。在这里，同样的技术也可以用于从IPv6 Internet访问家中的IPv4网络摄像头。所需要的只是能够适当地更新AAAA记录、IPv6客户端（可以使用Teredo[RFC4380]或其他方法来获得IPv6可达性）和NAT64机制。从这个意义上讲，这个方法看起来很像一个“NAT/防火墙旁路”函数。
An argument could be made that since the host is likely dual-stack, existing port-mapping services or NAT traversal techniques could be used to reach the private space instead of IPv6. This would have to be done anyway if the hosts are not all IPv6-capable or connected. However, in cases where the hosts are all IPv6-capable, the alternative techniques force additional limitations on the use of port numbers. In the case of IPv6-to-IPv4 translation, the full port space would be available for each server, even in the private space.
有人认为，由于主机可能是双栈的，因此可以使用现有的端口映射服务或NAT遍历技术来访问私有空间，而不是IPv6。如果主机不是全部支持IPv6或已连接，则无论如何都必须执行此操作。但是，在主机都支持IPv6的情况下，替代技术会对端口号的使用施加额外的限制。在IPv6到IPv4转换的情况下，每个服务器都可以使用完整的端口空间，即使在专用空间中也是如此。
It is recommended that the IETF develop tools to address this scenario. These tools need to allow existing IPv4 servers to operate unchanged.
建议IETF开发工具来解决该场景。这些工具需要允许现有IPv4服务器保持不变地运行。
This scenario is predicted to become increasingly important as IPv4 global connectivity sufficient for supporting server-oriented content becomes significantly more difficult to obtain than global IPv6 connectivity. Historically, the expectation has been that for connectivity to IPv6-only devices, devices would either need to be IPv6-connected, or dual-stack with the ability to set up an IPv6- over-IPv4 tunnel in order to access the IPv6 Internet. Many "modern" device stacks have this capability, and for them this scenario does not present a problem as long as a suitable gateway to terminate the tunnel and route the IPv6 packets is available. But, for the server operator, it may be a difficult proposition to leave all IPv4-only devices without reachability. Thus, if a solution for IPv4-only devices to reach IPv6-only servers were realizable, the benefits
随着足以支持面向服务器的内容的IPv4全局连接变得比全局IPv6连接更难获得，预计这种情况将变得越来越重要。从历史上看，人们的期望是，要连接到仅限IPv6的设备，设备要么需要连接IPv6，要么需要能够设置IPv6-over-IPv4隧道的双栈，以便访问IPv6 Internet。许多“现代”设备堆栈都具有此功能，对于它们来说，只要有合适的网关来终止隧道并路由IPv6数据包，这种情况就不会出现问题。但是，对于服务器运营商来说，让所有只使用IPv4的设备都无法访问可能是一件困难的事情。因此，如果可以实现一个只用于IPv4的设备到达只用于IPv6的服务器的解决方案，那么好处就显而易见了
would be clear. Not only could servers move directly to IPv6 without trudging through a difficult dual-stack period, but they could do so without risk of losing connectivity with the IPv4-only Internet.
那就很清楚了。服务器不仅可以直接移动到IPv6，而无需艰难地度过双栈期，而且还可以在不失去与仅IPv4的Internet连接的风险的情况下移动到IPv6。
Unfortunately, realizing this goal is complicated by the fact that IPv4 to IPv6 is considered "hard" since of course IPv6 has a much larger address space than IPv4. Thus, representing 128 bits in 32 bits is not possible, barring the use of techniques similar to NAT64, which uses IPv6 addresses to represent IPv4 addresses as well.
不幸的是，IPv4到IPv6被认为是“硬”的，这一事实使实现这一目标变得复杂，因为IPv6当然比IPv4有更大的地址空间。因此，在32位中表示128位是不可能的，除非使用与NAT64类似的技术，NAT64也使用IPv6地址表示IPv4地址。
The main questions regarding this scenario are about timing and priority. While the expectation that this scenario may be of importance one day is readily acceptable, at the time of this writing, there are few or no IPv6-only servers of importance (beyond some contrived cases) that the authors are aware of. The difficulty of making a decision about this case is that, quite possibly, when there is sufficient pressure on IPv4 such that we see IPv6-only servers, the vast majority of hosts will either have IPv6 connectivity or the ability to tunnel IPv6 over IPv4 in one way or another.
关于这个场景的主要问题是时间和优先级。虽然这种情况有一天可能会很重要的预期是可以接受的，但在撰写本文时，作者知道的仅IPv6服务器很少或根本没有重要的服务器（除了一些人为的情况）。对这种情况作出决定的困难在于，很可能，当IPv4受到足够的压力时，我们会看到只使用IPv6的服务器，绝大多数主机将要么具有IPv6连接，要么能够以某种方式通过IPv4通过IPv6进行隧道传输。
This discussion makes assumptions about what a "server" is as well. For the majority of applications seen on the IPv4 Internet to date, this distinction has been more or less clear. This clarity is perhaps in no small part due to the overhead today in creating a truly end-to-end application in the face of the fragmented addressing and reachability brought on by the various NATs and firewalls employed today. However, current notions of a "server" are beginning to shift, as we see more and more pressure to connect people to one another in an end-to-end fashion -- with peer-to-peer techniques, for instance -- rather than simply content server to client. Thus, if we consider an "IPv6-only server" as what we classically consider an "IPv4 server" today, there may not be a lot of demand for this in the near future. However, with a more distributed model of the Internet in mind, there may be more opportunities to employ IPv6-only "servers" that we would normally extrapolate from based on past experience with applications.
本讨论还假设了“服务器”是什么。对于迄今为止在IPv4互联网上看到的大多数应用程序来说，这种区别或多或少是明确的。这种清晰性可能在很大程度上是由于今天在创建真正的端到端应用程序时，面对当今使用的各种NAT和防火墙所带来的碎片化寻址和可访问性，所带来的开销。然而，当前对“服务器”的概念正在开始转变，因为我们看到越来越多的压力要求人们以端到端的方式（例如，使用点对点技术）而不是简单地从内容服务器到客户端连接彼此。因此，如果我们把“IPv6唯一服务器”看作是我们今天经典的“IPv4服务器”，那么在不久的将来可能不会有太多的需求。然而，考虑到互联网的更分布式模型，可能会有更多机会使用仅限IPv6的“服务器”，我们通常会根据过去的应用经验推断这些服务器。
It is recommended that the IETF address this scenario, though perhaps with a slightly lower priority than the others. In any case, when new tools are developed to support this, it should be obvious that we cannot assume any support for updating legacy IPv4 hosts in order to reach the IPv6-only servers.
建议IETF解决该场景，尽管优先级可能略低于其他场景。在任何情况下，当开发新的工具来支持这一点时，很明显，我们不能假设任何对更新旧式IPv4主机的支持，以便访问仅限IPv6的服务器。
Security aspects of the individual solutions are discussed in more depth elsewhere, for instance in [DUAL-STACK-LITE], [RFC6144], [RFC6147], [RFC6145], [RFC6146], [NAT-PT], and [RFC4966]. This document highlights just three issues:
个别解决方案的安全方面在其他地方进行了更深入的讨论，例如在[DUAL-STACK-LITE]、[RFC6144]、[RFC6147]、[RFC6145]、[RFC6146]、[NAT-PT]和[RFC4966]中。本文件仅强调三个问题：
o Any type of translation may have an impact on how certain protocols can pass through. For example, IPsec needs support for NAT traversal, and the proliferation of NATs implies an even higher reliance on these mechanisms. It may also require additional support for new types of translation.
o 任何类型的翻译都可能对某些协议的通过方式产生影响。例如，IPsec需要对NAT遍历的支持，而NAT的激增意味着对这些机制的依赖程度更高。它还可能需要对新类型翻译的额外支持。
o Some solutions have a need to modify results obtained from DNS. This may have an impact on DNS security, as discussed in [RFC4966]. Minimization or even elimination of such problems is essential, as discussed in [RFC6147].
o 某些解决方案需要修改从DNS获得的结果。这可能会对DNS安全性产生影响，如[RFC4966]中所述。如[RFC6147]中所述，最小化甚至消除此类问题至关重要。
o Tunneling solutions have their own security issues, for instance the need to secure tunnel endpoint discovery or to avoid opening up denial-of-service or reflection vulnerabilities [RFC6169].
o 隧道解决方案有其自身的安全问题，例如需要保护隧道端点发现或避免打开拒绝服务或反射漏洞[RFC6169]。
The authors believe that the scenarios outlined in this document are among the top of the list of those that should be addressed by the IETF community in short order. For each scenario, there are clearly different solution approaches with implementation, operations, and deployment tradeoffs. Further, some approaches rely on existing or well-understood technology, while some require new protocols and changes to established network architecture. It is essential that these tradeoffs be considered, understood by the community at large, and in the end well-documented as part of the solution design.
作者认为，本文件中概述的场景是IETF社区应在短时间内解决的场景列表中最重要的场景之一。对于每个场景，都有明显不同的解决方案方法，包括实现、操作和部署权衡。此外，一些方法依赖于现有的或众所周知的技术，而一些方法需要新的协议和对已建立的网络架构的更改。重要的是要考虑这些权衡，让整个社区都能理解，并最终作为解决方案设计的一部分进行详细记录。
After writing the initial version of this document, the Softwire working group was rechartered to address the Section 2.2 scenario with a combination of existing tools (tunneling, IPv4 NATs) and some minor new ones (DHCP options) [DUAL-STACK-LITE]. Similarly, the Behave working group was rechartered to address scenarios from Sections 2.3, 2.4, and 2.5. At the time this document is being published, proposals to address scenarios from Section 2.1 are still under consideration for new IETF work items.
在编写本文档的初始版本后，重新组建了Softwire工作组，使用现有工具（隧道、IPv4 NAT）和一些小型新工具（DHCP选项）[双栈精简版]的组合来解决第2.2节场景。类似地，对工作组进行了重组，以处理第2.3、2.4和2.5节中的场景。在本文件发布时，第2.1节提出的解决方案仍在考虑新的IETF工作项。
This document set out to list scenarios that are important for the Internet community. While it introduces some design elements in order to understand and discuss tradeoffs, it does not list detailed requirements. In large part, the authors believe that exhaustive and detailed requirements would not be helpful at the expense of
本文档列出了对互联网社区非常重要的场景。虽然它介绍了一些设计元素以便理解和讨论权衡，但它没有列出详细的需求。在很大程度上，作者认为，以牺牲客户的利益为代价，详尽无遗的需求是没有帮助的
embarking on solutions, given our current state of affairs. We do not expect any of the solutions to be perfect when measured from all vantage points. When looking for opportunities to deploy IPv6, reaching too far for perfection could result in losing these opportunities if we are not attentive. Our goal with this document is to support the development of tools to help minimize the tangible problems that we are experiencing now, as well as those problems that we can best anticipate down the road, in hopes of steering the Internet on its best course from here.
考虑到我们目前的状况，着手解决问题。我们并不期望从所有有利的角度衡量，任何解决方案都是完美的。在寻找部署IPv6的机会时，如果我们不注意，过分追求完美可能会导致失去这些机会。本文件的目标是支持开发工具，以帮助最大限度地减少我们目前遇到的实际问题，以及我们能够最好地预测未来的问题，以期从现在开始引导互联网走上最佳道路。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年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月。
[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月。
[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月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925]Li，X.，Dawkins，S.，Ward，D.，和A.Durand，“软线问题声明”，RFC 49252007年7月。
[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月。
[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月。
[NAT-PT] Wing, D., Ward, D., and A. Durand, "A Comparison of Proposals to Replace NAT-PT", Work in Progress, September 2008.
[NAT-PT]Wing，D.，Ward，D.，和A.Durand，“替代NAT-PT方案的比较”，正在进行的工作，2008年9月。
[DUAL-STACK-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, May 2011.
[DUAL-STACK-LITE]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈LITE宽带部署”，正在进行的工作，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. 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月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月。
[INTAREA-TUNNELS] Touch, J. and M. Townsley, "Tunnels in the Internet Architecture", Work in Progress, March 2010.
[Intrea-TUNNELS]Touch，J.和M.Townsley，“互联网架构中的隧道”，正在进行的工作，2010年3月。
[v6OPS-APBP] Despres, R., "A Scalable IPv4-IPv6 Transition Architecture Need for an Address-Port-Borrowing-Protocol (APBP)", Work in Progress, July 2008.
[v6OPS APBP]Despres，R.，“一个可扩展的IPv4-IPv6转换架构需要一个地址端口借用协议（APBP）”，正在进行的工作，2008年7月。
[HUSTON-IPv4] Huston, G., "IPv4 Address Report", available at http://www.potaroo.net, December 2010.
[HUSTON-IPv4]休斯顿，G.，“IPv4地址报告”，可在http://www.potaroo.net，2010年12月。
[NISHITANI-CGN] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for IP Address Sharing Schemes", Work in Progress, March 2011.
[NISHITANI-CGN]Perreault，S.，Ed.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“IP地址共享方案的通用要求”，正在进行的工作，2011年3月。
[ISP-SHARED-ADDR] Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "ISP Shared Address", Work in Progress, September 2010.
[ISP-SHARED-ADDR]山形，I.，宫川，S.，中川，A.，山口，J.，和H.Ashida，“ISP共享地址”，正在进行的工作，2010年9月。
[IPv4-SPACE-ISSUES] Azinger, M. and L. Vegoda, "Issues Associated with Designating Additional Private IPv4 Address Space", Work in Progress, January 2011.
[IPv4空间问题]Azinger，M.和L.Vegoda，“与指定额外专用IPv4地址空间相关的问题”，正在进行的工作，2011年1月。
[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月。
Discussions with a number of people including Dave Thaler, Thomas Narten, Marcelo Bagnulo, Fred Baker, Remi Despres, Lorenzo Colitti, Dan Wing, and Brian Carpenter, and feedback during the Internet Area open meeting at IETF 72, were essential to the creation of the content in this document.
与Dave Thaler、Thomas Narten、Marcelo Bagnulo、Fred Baker、Remi Despres、Lorenzo Coletti、Dan Wing和Brian Carpenter等多人的讨论，以及IETF 72互联网区域公开会议期间的反馈，对于本文档内容的创建至关重要。
Authors' Addresses
作者地址
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@piuha.net
EMail: jari.arkko@piuha.net
Mark Townsley Cisco Paris 75006 France
马克汤斯利思科巴黎75006法国
EMail: townsley@cisco.com
EMail: townsley@cisco.com