Internet Engineering Task Force (IETF) A. Durand
Request for Comments: 6333 Juniper Networks
Category: Standards Track R. Droms
ISSN: 2070-1721 Cisco
J. Woodyatt
Apple
Y. Lee
Comcast
August 2011
Internet Engineering Task Force (IETF) A. Durand
Request for Comments: 6333 Juniper Networks
Category: Standards Track R. Droms
ISSN: 2070-1721 Cisco
J. Woodyatt
Apple
Y. Lee
Comcast
August 2011
Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
IPv4耗尽后的双栈Lite宽带部署
Abstract
摘要
This document revisits the dual-stack model and introduces the Dual-Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT).
本文档重新讨论了双栈模型，并介绍了双栈Lite技术，旨在更好地调整在服务提供商网络中部署IPv6的成本和好处。双栈Lite通过结合两种众所周知的技术，使宽带服务提供商能够在客户之间共享IPv4地址：IP-in-IP（IPv4-in-IPv6）和网络地址转换（NAT）。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6333.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6333.
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. Requirements Language ...........................................4
3. Terminology .....................................................4
4. Deployment Scenarios ............................................4
4.1. Access Model ...............................................4
4.2. CPE ........................................................5
4.3. Directly Connected Device ..................................6
5. B4 Element ......................................................7
5.1. Definition .................................................7
5.2. Encapsulation ..............................................7
5.3. Fragmentation and Reassembly ...............................7
5.4. AFTR Discovery .............................................7
5.5. DNS ........................................................8
5.6. Interface Initialization ...................................8
5.7. Well-Known IPv4 Address ....................................8
6. AFTR Element ....................................................9
6.1. Definition .................................................9
6.2. Encapsulation ..............................................9
6.3. Fragmentation and Reassembly ...............................9
6.4. DNS .......................................................10
6.5. Well-Known IPv4 Address ...................................10
6.6. Extended Binding Table ....................................10
7. Network Considerations .........................................10
7.1. Tunneling .................................................10
7.2. Multicast Considerations ..................................10
8. NAT Considerations .............................................11
8.1. NAT Pool ..................................................11
8.2. NAT Conformance ...........................................11
8.3. Application Level Gateways (ALGs) .........................11
8.4. Sharing Global IPv4 Addresses .............................11
8.5. Port Forwarding / Keep Alive ..............................11
1. Introduction ....................................................3
2. Requirements Language ...........................................4
3. Terminology .....................................................4
4. Deployment Scenarios ............................................4
4.1. Access Model ...............................................4
4.2. CPE ........................................................5
4.3. Directly Connected Device ..................................6
5. B4 Element ......................................................7
5.1. Definition .................................................7
5.2. Encapsulation ..............................................7
5.3. Fragmentation and Reassembly ...............................7
5.4. AFTR Discovery .............................................7
5.5. DNS ........................................................8
5.6. Interface Initialization ...................................8
5.7. Well-Known IPv4 Address ....................................8
6. AFTR Element ....................................................9
6.1. Definition .................................................9
6.2. Encapsulation ..............................................9
6.3. Fragmentation and Reassembly ...............................9
6.4. DNS .......................................................10
6.5. Well-Known IPv4 Address ...................................10
6.6. Extended Binding Table ....................................10
7. Network Considerations .........................................10
7.1. Tunneling .................................................10
7.2. Multicast Considerations ..................................10
8. NAT Considerations .............................................11
8.1. NAT Pool ..................................................11
8.2. NAT Conformance ...........................................11
8.3. Application Level Gateways (ALGs) .........................11
8.4. Sharing Global IPv4 Addresses .............................11
8.5. Port Forwarding / Keep Alive ..............................11
9. Acknowledgements ...............................................12
10. IANA Considerations ...........................................12
11. Security Considerations .......................................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................14
Appendix A. Deployment Considerations .............................16
A.1. AFTR Service Distribution and Horizontal Scaling ...........16
A.2. Horizontal Scaling .........................................16
A.3. High Availability ..........................................16
A.4. Logging ....................................................16
Appendix B. Examples ..............................................17
B.1. Gateway-Based Architecture .................................17
B.1.1. Example Message Flow ...................................19
B.1.2. Translation Details ....................................23
B.2. Host-Based Architecture ....................................24
B.2.1. Example Message Flow ...................................27
B.2.2. Translation Details ....................................31
9. Acknowledgements ...............................................12
10. IANA Considerations ...........................................12
11. Security Considerations .......................................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................14
Appendix A. Deployment Considerations .............................16
A.1. AFTR Service Distribution and Horizontal Scaling ...........16
A.2. Horizontal Scaling .........................................16
A.3. High Availability ..........................................16
A.4. Logging ....................................................16
Appendix B. Examples ..............................................17
B.1. Gateway-Based Architecture .................................17
B.1.1. Example Message Flow ...................................19
B.1.2. Translation Details ....................................23
B.2. Host-Based Architecture ....................................24
B.2.1. Example Message Flow ...................................27
B.2.2. Translation Details ....................................31
The common thinking for more than 10 years has been that the transition to IPv6 will be based solely on the dual-stack model and that most things would be converted this way before we ran out of IPv4. However, this has not happened. The IANA free pool of IPv4 addresses has now been depleted, well before sufficient IPv6 deployment had taken place. As a result, many IPv4 services have to continue to be provided even under severely limited address space.
十多年来，人们普遍认为，向IPv6的过渡将完全基于双栈模型，而且在IPv4耗尽之前，大多数东西都会以这种方式进行转换。然而，这并没有发生。在充分部署IPv6之前，IPv4地址的IANA空闲池已经耗尽。因此，即使在地址空间非常有限的情况下，也必须继续提供许多IPv4服务。
This document specifies the Dual-Stack Lite technology, which is aimed at better aligning the costs and benefits in service provider networks. Dual-Stack Lite will enable both continued support for IPv4 services and incentives for the deployment of IPv6. It also de-couples IPv6 deployment in the service provider network from the rest of the Internet, making incremental deployment easier.
本文档指定了双栈Lite技术，其目的是更好地调整服务提供商网络中的成本和收益。双栈Lite将继续支持IPv4服务，并鼓励部署IPv6。它还将服务提供商网络中的IPv6部署与Internet的其余部分分离，从而使增量部署更容易。
Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT).
双栈Lite通过结合两种众所周知的技术：IP-in-IP（IPv4-in-IPv6）和网络地址转换（NAT），使宽带服务提供商能够在客户之间共享IPv4地址。
This document makes a distinction between a dual-stack-capable and a dual-stack-provisioned device. The former is a device that has code that implements both IPv4 and IPv6, from the network layer to the applications. The latter is a similar device that has been provisioned with both an IPv4 and an IPv6 address on its interface(s). This document will also further refine this notion by distinguishing between interfaces provisioned directly by the service provider from those provisioned by the customer.
本文档对双堆栈设备和双堆栈设备进行了区分。前者是一种设备，其代码实现了IPv4和IPv6，从网络层到应用程序。后者是一种类似的设备，在其接口上提供了IPv4和IPv6地址。本文档还将通过区分服务提供商直接提供的接口和客户提供的接口，进一步完善这一概念。
Pure IPv6-only devices (i.e., devices that do not include an IPv4 stack) are outside of the scope of this document.
纯IPv6设备（即不包括IPv4堆栈的设备）不在本文档的范围内。
This document will first present some deployment scenarios and then define the behavior of the two elements of the Dual-Stack Lite technology: the Basic Bridging BroadBand (B4) element and the Address Family Transition Router (AFTR) element. It will then go into networking and NAT-ing considerations.
本文档将首先介绍一些部署场景，然后定义双栈Lite技术的两个元素的行为：基本桥接宽带（B4）元素和地址族转换路由器（AFTR）元素。然后将讨论网络和NAT方面的考虑。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The technology described in this document is known as Dual-Stack Lite. The abbreviation "DS-Lite" will be used throughout this text.
本文档中描述的技术称为双堆栈Lite。本文将使用缩写“DS Lite”。
This document also introduces two new terms: the DS-Lite Basic Bridging BroadBand (B4) element and the DS-Lite Address Family Transition Router (AFTR) element.
本文档还介绍了两个新术语：DS Lite基本桥接宽带（B4）元素和DS Lite地址族转换路由器（AFTR）元素。
Dual-stack is defined in [RFC4213].
双堆栈在[RFC4213]中定义。
NAT-related terminology is defined in [RFC4787].
[RFC4787]中定义了NAT相关术语。
CPE stands for Customer Premise Equipment. This is the layer 3 device in the customer premise that is connected to the service provider network. That device is often a home gateway. However, sometimes computers are directly attached to the service provider network. In such cases, such computers can be viewed as CPEs as well.
CPE代表客户场所设备。这是连接到服务提供商网络的客户场所中的第3层设备。该设备通常是家庭网关。然而，有时计算机直接连接到服务提供商网络。在这种情况下，此类计算机也可以被视为CPE。
Instead of relying on a cascade of NATs, the Dual-Stack Lite model is built on IPv4-in-IPv6 tunnels to cross the network to reach a carrier-grade IPv4-IPv4 NAT (the AFTR), where customers will share IPv4 addresses. There are a number of benefits to this approach:
双栈Lite模型构建在IPv4-in-IPv6隧道上，以跨网络到达运营商级IPv4-IPv4 NAT（AFTR），而不是依赖于NAT的级联，在该NAT中，客户将共享IPv4地址。这种方法有许多好处：
o This technology decouples the deployment of IPv6 in the service provider network (up to the customer premise equipment or CPE) from the deployment of IPv6 in the global Internet and in customer applications and devices.
o 该技术将IPv6在服务提供商网络（直至客户端设备或CPE）中的部署与IPv6在全球互联网以及客户应用程序和设备中的部署分离开来。
o The management of the service provider access networks is simplified by leveraging the large IPv6 address space. Overlapping private IPv4 address spaces are not required to support very large customer bases.
o 通过利用巨大的IPv6地址空间，简化了服务提供商接入网络的管理。为了支持非常大的客户群，不需要重叠的专用IPv4地址空间。
o As tunnels can terminate anywhere in the service provider network, this architecture lends itself to horizontal scaling and provides some flexibility to adapt to changing traffic load. More discussion of horizontal scaling can be found in Appendix A.
o 由于隧道可以在服务提供商网络中的任何位置终止，该体系结构有助于水平扩展，并提供一定的灵活性以适应不断变化的流量负载。关于水平缩放的更多讨论见附录A。
o Tunnels provide a direct connection between B4 and the AFTR. This can be leveraged to enable customers and their applications to control how the NAT function of the AFTR is performed.
o 隧道在B4和AFTR之间提供直接连接。这可以用来让客户及其应用程序控制AFTR的NAT功能的执行方式。
A key characteristic of this approach is that communications between end-nodes stay within their address family. IPv6 sources only communicate with IPv6 destinations, and IPv4 sources only communicate with IPv4 destinations. There is no protocol family translation involved in this approach. This simplifies greatly the task of applications that may carry literal IP addresses in their payloads.
这种方法的一个关键特征是，终端节点之间的通信保持在其地址族中。IPv6源仅与IPv6目标通信，IPv4源仅与IPv4目标通信。该方法不涉及协议族转换。这大大简化了应用程序的任务，这些应用程序的有效负载中可能包含文字IP地址。
This section describes home Local Area networks characterized by the presence of a home gateway, or CPE, provisioned only with IPv6 by the service provider.
本节描述了家庭局域网，其特征是存在仅由服务提供商通过IPv6提供的家庭网关或CPE。
A DS-Lite CPE is an IPv6-aware CPE with a B4 interface implemented in the WAN interface.
DS Lite CPE是支持IPv6的CPE，其B4接口在WAN接口中实现。
A DS-Lite CPE SHOULD NOT operate a NAT function between an internal interface and a B4 interface, as the NAT function will be performed by the AFTR in the service provider's network. This will avoid accidentally operating in a double-NAT environment.
DS Lite CPE不应在内部接口和B4接口之间操作NAT功能，因为NAT功能将由服务提供商网络中的AFTR执行。这将避免在双NAT环境中意外操作。
However, it SHOULD operate its own DHCP(v4) server handing out [RFC1918] address space (e.g., 192.168.0.0/16) to hosts in the home. It SHOULD advertise itself as the default IPv4 router to those home hosts. It SHOULD also advertise itself as a DNS server in the DHCP Option 6 (DNS Server). Additionally, it SHOULD operate a DNS proxy to accept DNS IPv4 requests from home hosts and send them using IPv6 to the service provider DNS servers, as described in Section 5.5.
但是，它应该运行自己的DHCP（v4）服务器，将[RFC1918]地址空间（例如192.168.0.0/16）分配给家庭中的主机。它应该将自己作为默认的IPv4路由器通告给这些主机。它还应该在DHCP选项6（DNS服务器）中作为DNS服务器进行广告。此外，如第5.5节所述，它应该操作DNS代理来接受来自主主机的DNS IPv4请求，并使用IPv6将它们发送到服务提供商DNS服务器。
Note: If an IPv4 home host decides to use another IPv4 DNS server, the DS-Lite CPE will forward those DNS requests via the B4 interface, the same way it forwards any regular IPv4 packets. However, each DNS request will create a binding in the AFTR. A large number of DNS requests may have a direct impact on the AFTR's NAT table utilization.
注意：如果IPv4主主机决定使用另一个IPv4 DNS服务器，DS Lite CPE将通过B4接口转发这些DNS请求，与转发任何常规IPv4数据包的方式相同。但是，每个DNS请求将在AFTR中创建一个绑定。大量DNS请求可能会直接影响AFTR的NAT表利用率。
IPv6-capable devices directly reach the IPv6 Internet. Packets simply follow IPv6 routing, they do not go through the tunnel, and they are not subject to any translation. It is expected that most IPv6-capable devices will also be IPv4 capable and will simply be configured with an IPv4 [RFC1918]-style address within the home network and access the IPv4 Internet the same way as the legacy IPv4- only devices within the home.
支持IPv6的设备直接到达IPv6 Internet。数据包只需遵循IPv6路由，它们不通过隧道，也不需要进行任何转换。预计大多数支持IPv6的设备也将支持IPv4，并且只需在家庭网络中配置IPv4[RFC1918]类型的地址，并以与家庭中传统的仅IPv4设备相同的方式访问IPv4 Internet。
Pure IPv6-only devices (i.e., devices that do not include an IPv4 stack) are outside of the scope of this document.
纯IPv6设备（即不包括IPv4堆栈的设备）不在本文档的范围内。
In broadband home networks, some devices are directly connected to the broadband service provider. They are connected straight to a modem, without a home gateway. Those devices are, in fact, acting as CPEs.
在宽带家庭网络中，一些设备直接连接到宽带服务提供商。它们直接连接到调制解调器，没有家庭网关。事实上，这些设备起着CPE的作用。
Under this scenario, the customer device is a dual-stack-capable host that is provisioned by the service provider with IPv6 only. The device itself acts as a B4 element, and the IPv4 service is provided by an IPv4-in-IPv6 tunnel, just as in the home gateway/CPE case. That device can run any combinations of IPv4 and/or IPv6 applications.
在这种情况下，客户设备是一个支持双堆栈的主机，由服务提供商仅使用IPv6提供。设备本身充当B4元素，IPv4服务由IPv4-in-IPv6隧道提供，就像家庭网关/CPE的情况一样。该设备可以运行IPv4和/或IPv6应用程序的任意组合。
A directly connected DS-Lite device SHOULD send its DNS requests over IPv6 to the IPv6 DNS server it has been configured to use.
直接连接的DS Lite设备应通过IPv6将其DNS请求发送到已配置为使用的IPv6 DNS服务器。
Similarly to the previous sections, IPv6 packets follow IPv6 routing, they do not go through the tunnel, and they are not subject to any translation.
与前面的章节类似，IPv6数据包遵循IPv6路由，它们不通过隧道，也不需要进行任何转换。
The support of IPv4-only devices and IPv6-only devices in this scenario is out of scope for this document.
此方案中仅支持IPv4设备和仅支持IPv6设备不在本文档的范围内。
The B4 element is a function implemented on a dual-stack-capable node, either a directly connected device or a CPE, that creates a tunnel to an AFTR.
B4元素是在双栈功能节点（直接连接的设备或CPE）上实现的功能，该节点创建到AFTR的隧道。
The tunnel is a multipoint-to-point IPv4-in-IPv6 tunnel ending on a service provider AFTR.
该隧道是一个多点对点IPv4-in-IPv6隧道，在服务提供商AFTR上结束。
See Section 7.1 for additional tunneling considerations.
其他隧道注意事项见第7.1节。
Note: At this point, DS-Lite only defines IPv4-in-IPv6 tunnels; however, other types of encapsulation could be defined in the future.
注意：此时，DS Lite仅定义IPv4-in-IPv6隧道；但是，将来可以定义其他类型的封装。
Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4 traffic over IPv6 will reduce the effective MTU of the datagram. Unfortunately, path MTU discovery [RFC1191] is not a reliable method to deal with this problem.
使用封装（IPv4-in-IPv6或其他任何东西）通过IPv6承载IPv4流量将减少数据报的有效MTU。不幸的是，路径MTU发现[RFC1191]不是处理此问题的可靠方法。
A solution to deal with this problem is for the service provider to increase the MTU size of all the links between the B4 element and the AFTR elements by at least 40 bytes to accommodate both the IPv6 encapsulation header and the IPv4 datagram without fragmenting the IPv6 packet.
处理此问题的解决方案是，服务提供商将B4元素和AFTR元素之间的所有链路的MTU大小增加至少40个字节，以容纳IPv6封装报头和IPv4数据报，而不分割IPv6数据包。
However, as not all service providers will be able to increase their link MTU, the B4 element MUST perform fragmentation and reassembly if the outgoing link MTU cannot accommodate the extra IPv6 header. The original IPv4 packet is not oversized. The packet is oversized after the IPv6 encapsulation. The inner IPv4 packet MUST NOT be fragmented. Fragmentation MUST happen after the encapsulation of the IPv6 packet. Reassembly MUST happen before the decapsulation of the IPv4 packet. A detailed procedure has been specified in [RFC2473] Section 7.2.
然而，由于并非所有服务提供商都能够增加其链路MTU，如果传出链路MTU不能容纳额外的IPv6报头，B4元素必须执行分段和重新组装。原始IPv4数据包没有过大。IPv6封装后，数据包过大。内部IPv4数据包不得分段。碎片必须在IPv6数据包封装之后发生。重新组装必须在IPv4数据包解除封装之前进行。[RFC2473]第7.2节规定了详细程序。
In order to configure the IPv4-in-IPv6 tunnel, the B4 element needs the IPv6 address of the AFTR element. This IPv6 address can be configured using a variety of methods, ranging from an out-of-band mechanism, manual configuration, or a variety of DHCPv6 options.
为了配置IPv6隧道中的IPv4，B4元素需要AFTR元素的IPv6地址。可以使用多种方法配置此IPv6地址，包括带外机制、手动配置或各种DHCPv6选项。
In order to guarantee interoperability, a B4 element SHOULD implement the DHCPv6 option defined in [RFC6334].
为了保证互操作性，B4元素应实现[RFC6334]中定义的DHCPv6选项。
A B4 element is only configured from the service provider with IPv6. As such, it can only learn the address of a DNS recursive server through DHCPv6 (or other similar method over IPv6). As DHCPv6 only defines an option to get the IPv6 address of such a DNS recursive server, the B4 element cannot easily discover the IPv4 address of such a recursive DNS server, and as such will have to perform all DNS resolution over IPv6.
B4元素仅从具有IPv6的服务提供商配置。因此，它只能通过DHCPv6（或IPv6上的其他类似方法）了解DNS递归服务器的地址。由于DHCPv6仅定义了获取此类DNS递归服务器的IPv6地址的选项，因此B4元素无法轻松发现此类递归DNS服务器的IPv4地址，因此必须通过IPv6执行所有DNS解析。
The B4 element can pass this IPv6 address to downstream IPv6 nodes, but not to downstream IPv4 nodes. As such, the B4 element SHOULD implement a DNS proxy, following the recommendations of [RFC5625].
B4元素可以将此IPv6地址传递给下游IPv6节点，但不能传递给下游IPv4节点。因此，B4元素应按照[RFC5625]的建议实现DNS代理。
To support a security-aware resolver behind the B4 element, the DNS proxy in the B4 element must also be security aware. Details can be found in [RFC4033] Section 6.
为了支持B4元素后面的安全感知解析器，B4元素中的DNS代理也必须是安全感知的。有关详细信息，请参见[RFC4033]第6节。
The B4 element can be implemented in a host and CPE in conjunction with other technologies such as native dual-stack. The host and the CPE SHOULD select to start only one technology during initialization. For example, if the CPE selects to start in native dual-stack mode, it SHOULD NOT initialize the B4 element. This selection process is out of scope for this document.
B4元素可以在主机和CPE中与其他技术（如本机双堆栈）一起实现。主机和CPE应选择在初始化期间仅启动一种技术。例如，如果CPE选择以本机双堆栈模式启动，则不应初始化B4元素。此选择过程超出了本文档的范围。
Any locally unique IPv4 address could be configured on the IPv4-in-IPv6 tunnel to represent the B4 element. Configuring such an address is often necessary when the B4 element is sourcing IPv4 datagrams directly over the tunnel. In order to avoid conflicts with any other address, IANA has defined a well-known range, 192.0.0.0/29.
可以在IPv4-in-IPv6隧道上配置任何本地唯一的IPv4地址，以表示B4元素。当B4元素通过隧道直接获取IPv4数据报时，通常需要配置这样的地址。为了避免与任何其他地址冲突，IANA定义了一个众所周知的范围192.0.0.0/29。
192.0.0.0 is the reserved subnet address. 192.0.0.1 is reserved for the AFTR element, and 192.0.0.2 is reserved for the B4 element. If a service provider has a special configuration that prevents the B4 element from using 192.0.0.2, the B4 element MAY use any other addresses within the 192.0.0.0/29 range.
192.0.0.0是保留子网地址。192.0.0.1预留给AFTR元件，192.0.0.2预留给B4元件。如果服务提供商具有防止B4元素使用192.0.0.2的特殊配置，则B4元素可以使用192.0.0.0/29范围内的任何其他地址。
Note: A range of addresses has been reserved for this purpose. The intent is to accommodate nodes implementing multiple B4 elements.
注：为此目的保留了一系列地址。目的是容纳实现多个B4元素的节点。
An AFTR element is the combination of an IPv4-in-IPv6 tunnel endpoint and an IPv4-IPv4 NAT implemented on the same node.
AFTR元素是IPv4-in-IPv6隧道端点和在同一节点上实现的IPv4-IPv4 NAT的组合。
The tunnel is a point-to-multipoint IPv4-in-IPv6 tunnel ending at the B4 elements.
该隧道是一个点对多点IPv4-in-IPv6隧道，终止于B4元素。
See Section 7.1 for additional tunneling considerations.
其他隧道注意事项见第7.1节。
Note: At this point, DS-Lite only defines IPv4-in-IPv6 tunnels; however, other types of encapsulation could be defined in the future.
注意：此时，DS Lite仅定义IPv4-in-IPv6隧道；但是，将来可以定义其他类型的封装。
As noted previously, fragmentation and reassembly need to be taken care of by the tunnel endpoints. As such, the AFTR MUST perform fragmentation and reassembly if the underlying link MTU cannot accommodate the encapsulation overhead. Fragmentation MUST happen after the encapsulation on the IPv6 packet. Reassembly MUST happen before the decapsulation of the IPv6 header. A detailed procedure has been specified in [RFC2473] Section 7.2.
如前所述，碎片和重新组装需要由隧道端点负责。因此，如果底层链路MTU不能容纳封装开销，AFTR必须执行分段和重新组装。在对IPv6数据包进行封装之后必须发生碎片。重新组装必须在IPv6标头解除封装之前进行。[RFC2473]第7.2节规定了详细程序。
Fragmentation at the Tunnel Entry-Point is a lightweight operation. In contrast, reassembly at the Tunnel Exit-Point can be expensive. When the Tunnel Exit-Point receives the first fragmented packet, it must wait for the second fragmented packet to arrive in order to reassemble the two fragmented IPv6 packets for decapsulation. This requires the Tunnel Exit-Point to buffer and keep track of fragmented packets. Consider that the AFTR is the Tunnel Exit-Point for many tunnels. If many devices simultaneously source a large number of fragmented packets through the AFTR to its managed B4 elements, this will require the AFTR to buffer and consume enormous resources to keep track of the flows. This reassembly process will significantly impact the AFTR's performance. However, this impact only happens when many clients simultaneously source large IPv4 packets. Since we believe that the majority of the clients will receive large IPv4 packets (such as watching video streams) instead of sourcing large IPv4 packets (such as sourcing video streams), reassembly is only a fraction of the overall AFTR's workload.
隧道入口点的碎片化是一种轻量级操作。相比之下，在隧道出口处重新组装可能会很昂贵。当隧道出口点接收到第一个分段数据包时，它必须等待第二个分段数据包到达，以便重新组装两个分段IPv6数据包以进行解封装。这需要隧道出口点缓冲并跟踪碎片数据包。考虑到AFTR是许多隧道的隧道出口点。如果许多设备同时通过AFTR向其受管B4元素发送大量碎片数据包，这将需要AFTR缓冲并消耗大量资源来跟踪流。此重新组装过程将对AFTR的性能产生重大影响。但是，只有当许多客户端同时发送大型IPv4数据包时，才会发生这种影响。由于我们相信大多数客户端将接收大型IPv4数据包（如观看视频流），而不是寻找大型IPv4数据包（如寻找视频流），因此重组仅占整个AFTR工作负载的一小部分。
When the AFTR's resources are running below a pre-defined threshold, the AFTR SHOULD generate a notification to the administrator before the resources are completely exhausted. The threshold and notification procedures are implementation dependent and are out of scope for this document.
当AFTR的资源运行低于预定义阈值时，AFTR应在资源完全耗尽之前向管理员发出通知。阈值和通知程序取决于实施，不在本文件的范围内。
Methods to avoid fragmentation, such as rewriting the TCP Maximum Segment Size (MSS) option or using technologies such as the Subnetwork Encapsulation and Adaptation Layer as defined in [RFC5320], are out of scope for this document.
避免碎片的方法，如重写TCP最大段大小（MSS）选项或使用[RFC5320]中定义的子网封装和适配层等技术，不在本文件范围内。
As noted previously, a DS-Lite node implementing a B4 element will perform DNS resolution over IPv6. As a result, DNS packets are not expected to go through the AFTR element.
如前所述，实现B4元素的DS Lite节点将通过IPv6执行DNS解析。因此，DNS数据包预计不会通过AFTR元素。
The AFTR SHOULD use the well-known IPv4 address 192.0.0.1 reserved by IANA to configure the IPv4-in-IPv6 tunnel. That address can then be used to report ICMP problems and will appear in traceroute outputs.
AFTR应使用IANA保留的众所周知的IPv4地址192.0.0.1来配置IPv4-in-IPv6隧道。然后，该地址可用于报告ICMP问题，并将出现在跟踪路由输出中。
The NAT binding table of the AFTR element is extended to include the source IPv6 address of the incoming packets. This IPv6 address is used to disambiguate between the overlapping IPv4 address space of the service provider customers.
AFTR元素的NAT绑定表被扩展以包括传入数据包的源IPv6地址。此IPv6地址用于消除服务提供商客户的重叠IPv4地址空间之间的歧义。
By doing a reverse lookup in the extended IPv4 NAT binding table, the AFTR knows how to reconstruct the IPv6 encapsulation when the packets come back from the Internet. That way, there is no need to keep a static configuration for each tunnel.
通过在扩展的IPv4 NAT绑定表中执行反向查找，AFTR知道当数据包从Internet返回时如何重构IPv6封装。这样，就不需要为每个隧道保持静态配置。
Tunneling MUST be done in accordance to [RFC2473] and [RFC4213]. Traffic classes ([RFC2474]) from the IPv4 headers MUST be carried over to the IPv6 headers and vice versa.
隧道开挖必须按照[RFC2473]和[RFC4213]进行。IPv4报头中的流量类（[RFC2474]）必须转移到IPv6报头，反之亦然。
Discussion of multicast is out of scope for this document.
关于多播的讨论超出了本文档的范围。
The AFTR MAY be provisioned with different NAT pools. The address ranges in the pools may be disjoint but MUST NOT be overlapped. Operators may implement policies in the AFTR to assign clients in different pools. For example, an AFTR can have two interfaces. Each interface will have a disjoint pool NAT assigned to it. In another case, a policy implemented on the AFTR may specify that one set of B4s will use NAT pool 1 and a different set of B4s will use NAT pool 2.
AFTR可以配置不同的NAT池。池中的地址范围可以是不相交的，但不能重叠。运营商可以在AFTR中实施策略，在不同池中分配客户端。例如，AFTR可以有两个接口。每个接口都将分配一个不相交的池NAT。在另一种情况下，在AFTR上实施的策略可以指定一组B4将使用NAT池1，而另一组B4将使用NAT池2。
A Dual-Stack Lite AFTR MUST implement behavior conforming to the best current practice, currently documented in [RFC4787], [RFC5508], and [RFC5382]. More discussions about carrier-grade NATs can be found in [LSN-REQS].
双栈Lite AFTR必须实现符合当前最佳实践的行为，当前记录在[RFC4787]、[RFC5508]和[RFC5382]中。有关载波级NAT的更多讨论，请参见[LSN-REQS]。
The AFTR performs NAT-44 and inherits the limitations of NAT. Some protocols require ALGs in the NAT device to traverse through the NAT. For example, Active FTP requires the ALG to work properly. ALGs consume resources, and there are many different types of ALGs. The AFTR is a shared network device that supports a large number of B4 elements. It is impossible for the AFTR to implement every current and future ALG.
AFTR执行NAT-44并继承NAT的限制。一些协议要求NAT设备中的ALG穿越NAT。例如，活动FTP要求ALG正常工作。ALG消耗资源，并且有许多不同类型的ALG。AFTR是支持大量B4元件的共享网络设备。AFTR不可能实现当前和未来的所有ALG。
The AFTR shares a single IP with multiple users. This helps to increase the IPv4 address utilization. However, it also brings some issues such as logging and lawful intercept. More considerations on sharing the port space of IPv4 addresses can be found in [RFC6269].
AFTR与多个用户共享一个IP。这有助于提高IPv4地址的利用率。然而，它也带来了一些问题，如日志记录和合法拦截。有关共享IPv4地址端口空间的更多注意事项，请参见[RFC6269]。
The PCP working group is standardizing a control plane to the carrier-grade NAT [LSN-REQS] in the IETF. The Port Control Protocol (PCP) enables applications to directly negotiate with the NAT to open ports and negotiate lifetime values to avoid keep-alive traffic. More on PCP can be found in [PCP-BASE].
PCP工作组正在将控制平面标准化为IETF中的载波级NAT[LSN-REQS]。端口控制协议（PCP）允许应用程序直接与NAT协商以打开端口，并协商生存期值以避免保持活动的流量。有关PCP的更多信息，请参见[PCP-BASE]。
The authors would like to acknowledge the role of Mark Townsley for his input on the overall architecture of this technology by pointing this work in the direction of [SNAT]. Note that this document results from a merging of [DURAND-DS-LITE] and [SNAT]. Also to be acknowledged are the many discussions with a number of people including Shin Miyakawa, Katsuyasu Toyama, Akihide Hiura, Takashi Uematsu, Tetsutaro Hara, Yasunori Matsubayashi, and Ichiro Mizukoshi. The authors would also like to thank David Ward, Jari Arkko, Thomas Narten, and Geoff Huston for their constructive feedback. Special thanks go to Dave Thaler and Dan Wing for their reviews and comments.
作者希望通过将这项工作指向[SNAT]的方向，感谢马克·汤斯利对这项技术的总体架构的贡献。请注意，本文档是[DURAND-DS-LITE]和[SNAT]合并的结果。还需要承认的是，与许多人进行了多次讨论，其中包括三川信孝、富山胜康、秋田昭彦、上松隆、原哲太郎、松下靖一和水口一郎。作者还要感谢David Ward、Jari Arkko、Thomas Narten和Geoff Huston的建设性反馈。特别感谢Dave Thaler和Dan Wing的评论和评论。
Per this document, IANA has allocated a well-known IPv4 192.0.0.0/29 network prefix. That range is used to number the Dual-Stack Lite interfaces. Reserving a /29 allows for 6 possible interfaces on a multi-home node. The IPv4 address 192.0.0.1 is reserved as the IPv4 address of the default router for such Dual-Stack Lite hosts.
根据本文档，IANA分配了一个众所周知的IPv4 192.0.0.0/29网络前缀。该范围用于对双堆栈Lite接口进行编号。保留a/29允许在多主节点上有6个可能的接口。IPv4地址192.0.0.1保留为此类双栈Lite主机的默认路由器的IPv4地址。
Security issues associated with NAT have long been documented. See [RFC2663] and [RFC2993].
与NAT相关的安全问题早就有了记录。参见[RFC2663]和[RFC2993]。
However, moving the NAT functionality from the CPE to the core of the service provider network and sharing IPv4 addresses among customers create additional requirements when logging data for abuse usage. With any architecture where an IPv4 address does not uniquely represent an end host, IPv4 addresses and timestamps are no longer sufficient to identify a particular broadband customer. The AFTR should have the capability to log the tunnel-id, protocol, ports/IP addresses, and the creation time of the NAT binding to uniquely identify the user sessions. Exact details of what is logged are implementation specific and out of scope for this document.
但是，将NAT功能从CPE移动到服务提供商网络的核心，并在客户之间共享IPv4地址，在记录滥用数据时会产生额外的要求。对于IPv4地址不唯一代表终端主机的任何体系结构，IPv4地址和时间戳不再足以识别特定的宽带客户。AFTR应该能够记录隧道id、协议、端口/IP地址和NAT绑定的创建时间，以唯一标识用户会话。记录内容的确切细节是特定于实现的，不在本文档的范围内。
The AFTR performs translation functions for interior IPv4 hosts using RFC 1918 addresses or the IANA reserved address range (192.0.0.0/29). In some circumstances, an ISP may provision policies in the AFTR and instruct the AFTR to bypass translation functions based on <IPv4 Address, port number, protocol>. When the AFTR receives a packet with matching information of the policy from the interior host, the AFTR can simply forward the packet without translation. The addresses, ports, and protocol information must be provisioned on the AFTR before receiving the packet. The provisioning mechanism is out of scope for this specification.
AFTR使用RFC1918地址或IANA保留地址范围（192.0.0.0/29）为内部IPv4主机执行转换功能。在某些情况下，ISP可能会在AFTR中提供策略，并指示AFTR基于<IPv4地址、端口号、协议>绕过转换功能。当AFTR从内部主机接收到具有匹配策略信息的数据包时，AFTR可以简单地转发该数据包而无需翻译。在接收数据包之前，必须在AFTR上提供地址、端口和协议信息。设置机制超出了本规范的范围。
When decapsulating packets, the AFTR MUST only forward packets sourced by RFC 1918 addresses, an IANA reserved address range, or any other out-of-band pre-authorized addresses. The AFTR MUST drop all other packets. This prevents rogue devices from launching denial-of-service attacks using unauthorized public IPv4 addresses in the IPv4 source header field or an unauthorized transport port range in the IPv4 transport header field. For example, rogue devices could bombard a public web server by launching a TCP SYN ACK attack [RFC4987]. The victim will receive TCP SYN from random IPv4 source addresses at a rapid rate and deny TCP services to legitimate users.
在解除数据包封装时，AFTR必须仅转发由RFC 1918地址、IANA保留地址范围或任何其他带外预授权地址来源的数据包。AFTR必须丢弃所有其他数据包。这可防止恶意设备使用IPv4源标头字段中未经授权的公共IPv4地址或IPv4传输标头字段中未经授权的传输端口范围发起拒绝服务攻击。例如，恶意设备可以通过发起TCP SYN ACK攻击来轰炸公共web服务器[RFC4987]。受害者将从随机IPv4源地址快速接收TCP SYN，并拒绝向合法用户提供TCP服务。
With IPv4 addresses shared by multiple users, ports become a critical resource. As such, some mechanisms need to be put in place by an AFTR to limit port usage, either by rate-limiting new connections or putting a hard limit on the maximum number of ports usable by a single user. If this number is high enough, it should not interfere with normal usage and still provide reasonable protection of the shared pool. More considerations on sharing IPv4 addresses can be found in [RFC6269]. Other considerations and recommendations on logging can be found in [RFC6302].
由于IPv4地址由多个用户共享，端口成为关键资源。因此，AFTR需要设置一些机制来限制端口使用，或者通过限制新连接的速率，或者对单个用户可用的最大端口数设置硬限制。如果此数字足够高，则不应干扰正常使用，并且仍应为共享池提供合理的保护。有关共享IPv4地址的更多注意事项，请参见[RFC6269]。有关日志记录的其他注意事项和建议，请参见[RFC6302]。
AFTRs should support ways to limit service only to registered customers. One simple option is to implement an IPv6 ingress filter on the AFTR's tunnel interface to accept only the IPv6 address range defined in the filter.
AFTR应支持将服务仅限于注册客户的方式。一个简单的选择是在AFTR的隧道接口上实现IPv6入口筛选器，以仅接受筛选器中定义的IPv6地址范围。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[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月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625]Bellis，R.，“DNS代理实施指南”，BCP 152，RFC 56252009年8月。
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011.
[RFC6334]Hankins，D.和T.Mrugalski，“双栈Lite的IPv6动态主机配置协议（DHCPv6）选项”，RFC 63342011年8月。
[DURAND-DS-LITE] Durand, A., "Dual-stack lite broadband deployments post IPv4 exhaustion", Work in Progress, July 2008.
[DURAND-DS-LITE]DURAND，A.，“IPv4耗尽后的双栈LITE宽带部署”，正在进行的工作，2008年7月。
[LSN-REQS] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NAT (CGN)", Work in Progress, July 2011.
[LSN-REQS]Perreault，S.，Ed.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，在建工程，2011年7月。
[PCP-BASE] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, July 2011.
[PCP-BASE]Wing，D.，Ed.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，正在进行的工作，2011年7月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[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月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.，Ed.，和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，2007年8月。
[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010.
[RFC5320]Templin，F.，Ed.“子网络封装和适配层（SEAL）”，RFC 5320，2010年2月。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]Guha，S.，Ed.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508]Srisuresh，P.，Ford，B.，Sivakumar，S.，和S.Guha，“ICMP的NAT行为要求”，BCP 148，RFC 5508，2009年4月。
[RFC5571] Storer, B., Pignataro, C., Ed., Dos Santos, M., Stevant, B., Ed., Toutain, L., and J. Tremblay, "Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)", RFC 5571, June 2009.
[RFC5571]Storer，B.，Pignataro，C.，Ed.，Dos Santos，M.，Stevant，B.，Ed.，Toutain，L.，和J.Tremblay，“具有第二层隧道协议版本2（L2TPv2）的软线中心辐射部署框架”，RFC 55712009年6月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，RFC 6269，2011年6月。
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.
[RFC6302]Durand，A.，Gashinsky，I.，Lee，D.，和S.Sheppard，“面向Internet服务器的日志记录建议”，BCP 162，RFC 6302，2011年6月。
[SNAT] Droms, R. and B. Haberman, "Softwires Network Address Translation (SNAT)", Work in Progress, July 2008.
[SNAT]Droms，R.和B.Haberman，“软线网络地址转换（SNAT）”，正在进行的工作，2008年7月。
One of the key benefits of the Dual-Stack Lite technology lies in the fact that it is a tunnel-based solution. As such, tunnel endpoints can be anywhere in the service provider network.
双栈Lite技术的关键优势之一在于它是一个基于隧道的解决方案。因此，隧道端点可以位于服务提供商网络中的任何位置。
Using the DHCPv6 tunnel endpoint option [RFC6334], service providers can create groups of users sharing the same AFTR. Those groups can be merged or divided at will. This leads to a horizontally scaled solution, where more capacity is added with more AFTRs. As those groups of users can evolve over time, it is best to make sure that AFTRs do not require per-user configuration in order to provide service.
使用DHCPv6隧道端点选项[RFC6334]，服务提供商可以创建共享相同AFTR的用户组。这些组可以随意合并或拆分。这导致了一个水平扩展的解决方案，即更多的AFTR增加了更多的容量。由于这些用户组可以随着时间的推移而演变，因此最好确保AFTR不需要每个用户配置来提供服务。
A service provider can start using just a few centralized AFTRs. Later, when more capacity is needed, more AFTRs can be added and pushed closer to the edges of the access network.
服务提供商可以开始使用几个集中的AFTR。稍后，当需要更多容量时，可以添加更多AFTR并将其推近接入网络的边缘。
An important element in the design of the Dual-Stack Lite technology is the simplicity of implementation on the customer side. An IP4-in-IPv6 tunnel and a default route over it in the B4 element are all that is needed to get IPv4 connectivity. It is assumed that high availability is the responsibility of the service provider, not the customer devices implementing Dual-Stack Lite. As such, a single IPv6 address of the tunnel endpoint is provided in the DHCPv6 option defined in [RFC6334]. Specific means to achieve high availability on the service provider side are outside the scope of this specification.
双栈Lite技术设计中的一个重要元素是在客户端实现的简单性。IPv6隧道中的IP4和B4元素中的默认路由是获得IPv4连接所需的全部。假定高可用性是服务提供商的责任，而不是实施双栈Lite的客户设备的责任。因此，在[RFC6334]中定义的DHCPv6选项中提供了隧道端点的单个IPv6地址。在服务提供商端实现高可用性的具体方法不在本规范的范围内。
DS-Lite AFTR implementation should offer the functionality to log NAT binding creations or other ways to keep track of the ports/IP addresses used by customers. This is both to support troubleshooting, which is very important to service providers trying to figure out why something may not be working, and to meet region-specific requirements for responding to legally binding requests for information from law enforcement authorities.
DS Lite AFTR实现应提供记录NAT绑定创建的功能，或以其他方式跟踪客户使用的端口/IP地址。这既是为了支持故障排除，这对于试图找出某些问题可能不起作用的原因的服务提供商来说非常重要，也是为了满足地区特定的要求，以响应执法机构提出的具有法律约束力的信息请求。
This architecture is targeted at residential broadband deployments but can be adapted easily to other types of deployment where the installed base of IPv4-only devices is important.
此体系结构针对住宅宽带部署，但可以轻松地适应其他类型的部署，其中仅IPv4设备的安装基数非常重要。
Consider a scenario where a Dual-Stack Lite CPE is provisioned only with IPv6 in the WAN port, not IPv4. The CPE acts as an IPv4 DHCP server for the LAN (wireline and wireless) handing out [RFC1918] addresses. In addition, the CPE may support IPv6 Auto-Configuration and/or a DHCPv6 server for the LAN. When an IPv4-only device connects to the CPE, that CPE will hand out a [RFC1918] address to the device. When a dual-stack-capable device connects to the CPE, that CPE will hand out a [RFC1918] address and a global IPv6 address to the device. Besides, the CPE will create an IPv4-in-IPv6 softwire tunnel [RFC5571] to an AFTR that resides in the service provider network.
考虑一个场景，在WAN端口，而不是IPv4，仅用IPv6提供双栈Lite CPE。CPE充当LAN（有线和无线）的IPv4 DHCP服务器，分发[RFC1918]地址。此外，CPE可支持用于LAN的IPv6自动配置和/或DHCPv6服务器。当仅IPv4设备连接到CPE时，该CPE将向该设备发送[RFC1918]地址。当支持双栈的设备连接到CPE时，该CPE将向该设备发送[RFC1918]地址和全局IPv6地址。此外，CPE将创建到驻留在服务提供商网络中的AFTR的IPv4-in-IPv6软线隧道[RFC5571]。
When the device accesses IPv6 service, it will send the IPv6 datagram to the CPE natively. The CPE will route the traffic upstream to the IPv6 default gateway.
当设备访问IPv6服务时，将IPv6数据报本机发送给CPE。CPE将把流量路由到IPv6默认网关的上游。
When the device accesses IPv4 service, it will source the IPv4 datagram with the [RFC1918] address and send the IPv4 datagram to the CPE. The CPE will encapsulate the IPv4 datagram inside the IPv4-in-IPv6 softwire tunnel and forward the IPv6 datagram to the AFTR. This is in contrast to what the CPE normally does today, which is to NAT the [RFC1918] address to the public IPv4 address and route the datagram upstream. When the AFTR receives the IPv6 datagram, it will decapsulate the IPv6 header and perform an IPv4-to-IPv4 NAT on the source address.
当设备访问IPv4服务时，它将使用[RFC1918]地址获取IPv4数据报，并将IPv4数据报发送给CPE。CPE将把IPv4数据报封装在IPv4-in-IPv6软线隧道内，并将IPv6数据报转发给AFTR。这与CPE目前通常的做法相反，即将[RFC1918]地址NAT到公共IPv4地址，并将数据报路由到上游。当AFTR收到IPv6数据报时，它将解除对IPv6标头的封装，并在源地址上执行IPv4到IPv4的NAT。
As illustrated in Figure 1, this Dual-Stack Lite deployment model consists of three components: the Dual-Stack Lite home router with a B4 element, the AFTR, and a softwire between the B4 element acting as softwire initiator (SI) [RFC5571] in the Dual-Stack Lite home router and the softwire concentrator (SC) [RFC5571] in the AFTR. The AFTR performs IPv4-IPv4 NAT translations to multiplex multiple subscribers through a pool of global IPv4 addresses. Overlapping address spaces used by subscribers are disambiguated through the identification of tunnel endpoints.
如图1所示，此双栈Lite部署模型由三个组件组成：具有B4元件的双栈Lite家庭路由器、AFTR，以及在双栈Lite家庭路由器中充当软线启动器（SI）[RFC5571]的B4元件和AFTR中的软线集中器（SC）[RFC5571]之间的软线。AFTR通过全局IPv4地址池执行IPv4-IPv4 NAT转换以多路复用多个订户。订阅者使用的重叠地址空间通过识别隧道端点来消除歧义。
+-----------+
| Host |
+-----+-----+
|10.0.0.1
|
|
|10.0.0.2
+---------|---------+
| | |
| Home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
|||2001:db8:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:db8:0:2::1
+--------|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|192.0.2.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
+-----------+
| Host |
+-----+-----+
|10.0.0.1
|
|
|10.0.0.2
+---------|---------+
| | |
| Home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
|||2001:db8:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:db8:0:2::1
+--------|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|192.0.2.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 1: Gateway-Based Architecture
图1：基于网关的体系结构
Notes:
笔记：
o The Dual-Stack Lite home router is not required to be on the same link as the host.
o 双栈Lite家庭路由器不需要与主机位于同一链路上。
o The Dual-Stack Lite home router could be replaced by a Dual-Stack Lite router in the service provider network.
o 服务提供商网络中的双栈Lite路由器可以取代双栈Lite家庭路由器。
The resulting solution accepts an IPv4 datagram that is translated into an IPv4-in-IPv6 softwire datagram for transmission across the softwire. At the corresponding endpoint, the IPv4 datagram is decapsulated, and the translated IPv4 address is inserted based on a translation from the softwire.
最终的解决方案接受一个IPv4数据报，该数据报被转换为IPv4-in-IPv6软线数据报，以便通过软线进行传输。在相应的端点，IPv4数据报被解除封装，并且基于来自软线的转换插入转换后的IPv4地址。
In the example shown in Figure 2, the translation tables in the AFTR are configured to forward between IP/TCP (10.0.0.1/10000) and IP/TCP (192.0.2.1/5000). That is, a datagram received by the Dual-Stack Lite home router from the host at address 10.0.0.1, using TCP DST port 10000, will be translated to a datagram with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000 in the Internet.
在图2所示的示例中，AFTR中的转换表配置为在IP/TCP（10.0.0.1/10000）和IP/TCP（192.0.2.1/5000）之间转发。也就是说，双栈Lite家庭路由器使用TCP DST端口10000从地址为10.0.0.1的主机接收的数据报将被转换为Internet上IPv4 SRC地址为192.0.2.1、TCP SRC端口为5000的数据报。
+-----------+
| Host |
+-----+-----+
| |10.0.0.1
IPv4 datagram 1 | |
| |
v |10.0.0.2
+---------|---------+
| | |
| home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
| |||2001:db8:0:1::1
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6 softwire
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| | AFTR |
| v ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |192.0.2.1
IPv4 datagram 3 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
+-----------+
| Host |
+-----+-----+
| |10.0.0.1
IPv4 datagram 1 | |
| |
v |10.0.0.2
+---------|---------+
| | |
| home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
| |||2001:db8:0:1::1
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6 softwire
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| | AFTR |
| v ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |192.0.2.1
IPv4 datagram 3 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 2: Outbound Datagram
图2：出站数据报
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:2::1 |
| | IPv6 Src | 2001:db8:0:1::1 |
| | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.2.1 |
| | TCP Dst | 80 |
| | TCP Src | 5000 |
+-----------------+--------------+-----------------+
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:2::1 |
| | IPv6 Src | 2001:db8:0:1::1 |
| | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.2.1 |
| | TCP Dst | 80 |
| | TCP Src | 5000 |
+-----------------+--------------+-----------------+
Datagram Header Contents
数据报头内容
When datagram 1 is received by the Dual-Stack Lite home router, the B4 element encapsulates the datagram in datagram 2 and forwards it to the Dual-Stack Lite carrier-grade NAT over the softwire.
当双栈Lite家庭路由器接收到数据报1时，B4元件将数据报封装在数据报2中，并通过软线将其转发给双栈Lite载波级NAT。
When the tunnel concentrator in the AFTR receives datagram 2, it forwards the IPv4 datagram to the NAT, which determines from its NAT table that the datagram received on the softwire with TCP SRC port 10000 should be translated to datagram 3 with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000.
当AFTR中的隧道集中器接收到数据报2时，它将IPv4数据报转发给NAT，NAT根据其NAT表确定，在具有TCP SRC端口10000的软线上接收的数据报应转换为具有IPv4 SRC地址192.0.2.1和TCP SRC端口5000的数据报3。
Figure 3 shows an inbound message received at the AFTR. When the NAT function in the AFTR receives datagram 1, it looks up the IP/TCP DST information in its translation table. In the example in Figure 3, the NAT changes the TCP DST port to 10000, sets the IP DST address to 10.0.0.1, and forwards the datagram to the softwire. The B4 in the home router decapsulates the IPv4 datagram from the inbound softwire datagram and forwards it to the host.
图3显示了在AFTR接收的入站消息。当AFTR中的NAT函数接收到数据报1时，它在其转换表中查找IP/TCP DST信息。在图3中的示例中，NAT将TCP DST端口更改为10000，将IP DST地址设置为10.0.0.1，并将数据报转发到软线。家庭路由器中的B4从入站软线数据报中解除IPv4数据报的封装，并将其转发到主机。
+-----------+
| Host |
+-----+-----+
^ |10.0.0.1
IPv4 datagram 3 | |
| |
| |10.0.0.2
+---------|---------+
| +-+-+ |
| home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
^ |||2001:db8:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |192.0.2.1
IPv4 datagram 1 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
+-----------+
| Host |
+-----+-----+
^ |10.0.0.1
IPv4 datagram 3 | |
| |
| |10.0.0.2
+---------|---------+
| +-+-+ |
| home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
^ |||2001:db8:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |192.0.2.1
IPv4 datagram 1 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 3: Inbound Datagram
图3：入站数据报
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 192.0.2.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 5000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:1::1 |
| | IPv6 Src | 2001:db8:0:2::1 |
| | IPv4 Dst | 10.0.0.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 10.0.0.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------+
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 192.0.2.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 5000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:1::1 |
| | IPv6 Src | 2001:db8:0:2::1 |
| | IPv4 Dst | 10.0.0.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 10.0.0.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------+
Datagram Header Contents
数据报头内容
The AFTR has a NAT that translates between softwire/port pairs and IPv4-address/port pairs. The same translation is applied to IPv4 datagrams received on the device's external interface and from the softwire endpoint in the device.
AFTR具有在软线/端口对和IPv4地址/端口对之间转换的NAT。相同的转换应用于在设备的外部接口上接收的IPv4数据报以及从设备中的软线端点接收的IPv4数据报。
In Figure 2, the translator network interface in the AFTR is on the Internet, and the softwire interface connects to the Dual-Stack Lite home router. The AFTR translator is configured as follows:
在图2中，AFTR中的转换器网络接口位于互联网上，软线接口连接到双栈Lite家庭路由器。AFTR转换器配置如下：
Network interface: Translate IPv4 destination address and TCP destination port to the softwire identifier and TCP destination port
网络接口：将IPv4目标地址和TCP目标端口转换为软线标识符和TCP目标端口
Softwire interface: Translate softwire identifier and TCP source port to IPv4 source address and TCP source port
软线接口：将软线标识符和TCP源端口转换为IPv4源地址和TCP源端口
Here is how the translation in Figure 3 works:
下面是图3中的翻译是如何工作的：
o Datagram 1 is received on the AFTR translator network interface. The translator looks up the IPv4-address/port pair in its translator table, rewrites the IPv4 destination address to 10.0.0.1 and the TCP source port to 10000, and forwards the datagram to the softwire.
o 数据报1通过AFTR转换器网络接口接收。转换器在其转换器表中查找IPv4地址/端口对，将IPv4目标地址重写为10.0.0.1，将TCP源端口重写为10000，并将数据报转发到软线。
o The IPv4 datagram is received on the Dual-Stack Lite home router B4. The B4 function extracts the IPv4 datagram, and the Dual-Stack Lite home router forwards datagram 3 to the host.
o IPv4数据报在双栈Lite家庭路由器B4上接收。B4函数提取IPv4数据报，双栈Lite家庭路由器将数据报3转发给主机。
+------------------------------------+--------------------+
| Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port |
+------------------------------------+--------------------+
| 2001:db8:0:1::1/10.0.0.1/TCP/10000 | 192.0.2.1/TCP/5000 |
+------------------------------------+--------------------+
+------------------------------------+--------------------+
| Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port |
+------------------------------------+--------------------+
| 2001:db8:0:1::1/10.0.0.1/TCP/10000 | 192.0.2.1/TCP/5000 |
+------------------------------------+--------------------+
Dual-Stack Lite Carrier-Grade NAT Translation Table
双栈Lite载波级NAT转换表
The Softwire-Id is the IPv6 address assigned to the Dual-Stack Lite CPE. Hosts behind the same Dual-Stack Lite home router have the same Softwire-Id. The source IPv4 address is the [RFC1918] address assigned by the Dual-Stack home router and is unique to each host behind the CPE. The AFTR would receive packets sourced from different IPv4 addresses in the same softwire tunnel. The AFTR combines the Softwire-Id and IPv4 address/port [Softwire-Id, IPv4+ Port] to uniquely identify the host behind the same Dual-Stack Lite home router.
Softwire Id是分配给双栈Lite CPE的IPv6地址。同一双栈Lite家庭路由器后面的主机具有相同的Softwire-Id。源IPv4地址是双栈家庭路由器分配的[RFC1918]地址，对于CPE后面的每个主机都是唯一的。AFTR将在同一软线隧道中接收来自不同IPv4地址的数据包。AFTR将软线Id和IPv4地址/端口[软线Id，IPv4+端口]结合起来，以唯一标识同一双栈Lite家庭路由器后面的主机。
This architecture is targeted at new, large-scale deployments of dual-stack-capable devices implementing a Dual-Stack Lite interface.
此体系结构的目标是实现双堆栈Lite接口的支持双堆栈的设备的新的大规模部署。
Consider a scenario where a Dual-Stack Lite host device is directly connected to the service provider network. The host device is dual-stack capable but only provisioned with an IPv6 global address. Besides, the host device will pre-configure a well-known IPv4 non-routable address; see Section 10 (IANA Considerations). This well-known IPv4 non-routable address is similar to the 127.0.0.1 loopback address. Every host device that implements Dual-Stack Lite will pre-configure the same address. This address will be used to source the IPv4 datagram when the device accesses IPv4 services. Besides, the host device will create an IPv4-in-IPv6 softwire tunnel to an AFTR. The carrier-grade NAT will reside in the service provider network.
考虑一个场景，其中双栈Lite主机设备直接连接到服务提供商网络。主机设备支持双堆栈，但仅配置了IPv6全局地址。此外，主机设备将预配置众所周知的IPv4不可路由地址；见第10节（IANA注意事项）。这个众所周知的IPv4不可路由地址类似于127.0.0.1环回地址。每个实现双栈Lite的主机设备都将预先配置相同的地址。当设备访问IPv4服务时，此地址将用于源IPv4数据报。此外，主机设备将创建到AFTR的IPv4-in-IPv6软线隧道。运营商级NAT将驻留在服务提供商网络中。
When the device accesses IPv6 service, the device will send the IPv6 datagram natively to the default gateway.
当设备访问IPv6服务时，设备将以本机方式将IPv6数据报发送到默认网关。
When the device accesses IPv4 service, it will source the IPv4 datagram with the well-known non-routable IPv4 address. Then, the host device will encapsulate the IPv4 datagram inside the IPv4-in-IPv6 softwire tunnel and send the IPv6 datagram to the AFTR. When the AFTR receives the IPv6 datagram, it will decapsulate the IPv6 header and perform IPv4-to-IPv4 NAT on the source address.
当设备访问IPv4服务时，它将使用已知的不可路由IPv4地址来源IPv4数据报。然后，主机设备将IPv4数据报封装在IPv4-in-IPv6软线隧道内，并将IPv6数据报发送到AFTR。当AFTR接收到IPv6数据报时，它将解除对IPv6标头的封装，并对源地址执行IPv4到IPv4的NAT。
This scenario works on both wireline and wireless networks. A typical wireless device will connect directly to the service provider without a CPE in between.
此方案适用于有线和无线网络。典型的无线设备将直接连接到服务提供商，中间没有CPE。
As illustrated in Figure 4, this Dual-Stack Lite deployment model consists of three components: the Dual-Stack Lite host, the AFTR, and a softwire between the softwire initiator B4 in the host and the softwire concentrator in the AFTR. The Dual-Stack Lite host is assumed to have IPv6 service and can exchange IPv6 traffic with the AFTR.
如图4所示，此双栈Lite部署模型由三个组件组成：双栈Lite主机、AFTR以及主机中的软线启动器B4和AFTR中的软线集中器之间的软线。假定双栈Lite主机具有IPv6服务，并且可以与AFTR交换IPv6流量。
The AFTR performs IPv4-IPv4 NAT translations to multiplex multiple subscribers through a pool of global IPv4 addresses. Overlapping IPv4 address spaces used by the Dual-Stack Lite hosts are disambiguated through the identification of tunnel endpoints.
AFTR通过全局IPv4地址池执行IPv4-IPv4 NAT转换以多路复用多个订户。双栈Lite主机使用的重叠IPv4地址空间通过识别隧道端点来消除歧义。
In this situation, the Dual-Stack Lite host configures the IPv4 address 192.0.0.2 out of the well-known range 192.0.0.0/29 (defined by IANA) on its B4 interface. It also configures the first non-reserved IPv4 address of the reserved range, 192.0.0.1, as the address of its default gateway.
在这种情况下，双栈Lite主机在其B4接口上配置IPv4地址192.0.0.2，超出了众所周知的192.0.0.0/29范围（由IANA定义）。它还将保留范围的第一个非保留IPv4地址192.0.0.1配置为其默认网关的地址。
+-------------------+
| |
| Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
|||2001:db8:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:db8:0:2::1
+--------|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|192.0.2.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
+-------------------+
| |
| Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
|||2001:db8:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:db8:0:2::1
+--------|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|192.0.2.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 4: Host-Based Architecture
图4：基于主机的体系结构
The resulting solution accepts an IPv4 datagram that is translated into an IPv4-in-IPv6 softwire datagram for transmission across the softwire. At the corresponding endpoint, the IPv4 datagram is decapsulated, and the translated IPv4 address is inserted based on a translation from the softwire.
最终的解决方案接受一个IPv4数据报，该数据报被转换为IPv4-in-IPv6软线数据报，以便通过软线进行传输。在相应的端点，IPv4数据报被解除封装，并且基于来自软线的转换插入转换后的IPv4地址。
In the example shown in Figure 5, the translation tables in the AFTR are configured to forward between IP/TCP (192.0.0.2/10000) and IP/TCP (192.0.2.1/5000). That is, a datagram received from the host at address 192.0.0.2, using TCP DST port 10000, will be translated to a datagram with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000 in the Internet.
在图5所示的示例中，AFTR中的转换表被配置为在IP/TCP（192.0.0.2/10000）和IP/TCP（192.0.2.1/5000）之间转发。也就是说，使用TCP DST端口10000从地址为192.0.0.2的主机接收的数据报将被转换为Internet中IPv4 SRC地址为192.0.2.1、TCP SRC端口为5000的数据报。
+-------------------+
| |
|Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
| |||2001:db8:0:1::1
IPv6 datagram 1| |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| | AFTR |
| v ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |192.0.2.1
IPv4 datagram 2 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
+-------------------+
| |
|Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
| |||2001:db8:0:1::1
IPv6 datagram 1| |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| | AFTR |
| v ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |192.0.2.1
IPv4 datagram 2 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 5: Outbound Datagram
图5：出站数据报
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv6 datagram 1 | IPv6 Dst | 2001:db8:0:2::1 |
| | IPv6 Src | 2001:db8:0:1::1 |
| | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.0.2 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 2 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.2.1 |
| | TCP Dst | 80 |
| | TCP Src | 5000 |
+-----------------+--------------+-----------------+
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv6 datagram 1 | IPv6 Dst | 2001:db8:0:2::1 |
| | IPv6 Src | 2001:db8:0:1::1 |
| | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.0.2 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 2 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.2.1 |
| | TCP Dst | 80 |
| | TCP Src | 5000 |
+-----------------+--------------+-----------------+
Datagram Header Contents
数据报头内容
When sending an IPv4 packet, the Dual-Stack Lite host encapsulates it in datagram 1 and forwards it to the AFTR over the softwire.
发送IPv4数据包时，双栈Lite主机将其封装在数据报1中，并通过软线将其转发给AFTR。
When it receives datagram 1, the concentrator in the AFTR hands the IPv4 datagram to the NAT, which determines from its translation table that the datagram received on the softwire with TCP SRC port 10000 should be translated to datagram 3 with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000.
当接收到数据报1时，AFTR中的集中器将IPv4数据报交给NAT，NAT根据其转换表确定，在具有TCP SRC端口10000的软线上接收的数据报应转换为具有IPv4 SRC地址192.0.2.1和TCP SRC端口5000的数据报3。
Figure 6 shows an inbound message received at the AFTR. When the NAT function in the AFTR receives datagram 1, it looks up the IP/TCP DST in its translation table. In the example in Figure 6, the NAT translates the TCP DST port to 10000, sets the IP DST address to 192.0.0.2, and forwards the datagram to the softwire. The B4 inside the host decapsulates the IPv4 datagram from the inbound softwire datagram, and forwards it to the host's application layer.
图6显示了在AFTR接收的入站消息。当AFTR中的NAT函数接收到数据报1时，它在其转换表中查找IP/TCP DST。在图6中的示例中，NAT将TCP DST端口转换为10000，将IP DST地址设置为192.0.0.2，并将数据报转发到软线。主机内的B4将IPv4数据报从入站软线数据报中解封，并将其转发到主机的应用层。
+-------------------+
| |
|Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
^ |||2001:db8:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| AFTR |
| | ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |192.0.2.1
IPv4 datagram 1 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
+-------------------+
| |
|Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
^ |||2001:db8:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| AFTR |
| | ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |192.0.2.1
IPv4 datagram 1 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 6: Inbound Datagram
图6：入站数据报
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 192.0.2.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 5000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:1::1 |
| | IPv6 Src | 2001:db8:0:2::1 |
| | IPv4 Dst | 192.0.0.2 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------+
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 192.0.2.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 5000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:1::1 |
| | IPv6 Src | 2001:db8:0:2::1 |
| | IPv4 Dst | 192.0.0.2 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------+
Datagram Header Contents
数据报头内容
The AFTR translation steps are the same as in Appendix B.1.2. One difference is that all the host-based B4s will use the same well-known IPv4 address 192.0.0.2. To uniquely identify the host-based B4, the AFTR will use the host-based B4's IPv6 address, which is unique for the host.
AFTR翻译步骤与附录B.1.2相同。一个区别是，所有基于主机的B4将使用相同的已知IPv4地址192.0.0.2。为了唯一标识基于主机的B4，AFTR将使用基于主机的B4的IPv6地址，该地址对于主机是唯一的。
+-------------------------------------+--------------------+
| Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port |
+-------------------------------------+--------------------+
| 2001:db8:0:1::1/192.0.0.2/TCP/10000 | 192.0.2.1/TCP/5000 |
+-------------------------------------+--------------------+
+-------------------------------------+--------------------+
| Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port |
+-------------------------------------+--------------------+
| 2001:db8:0:1::1/192.0.0.2/TCP/10000 | 192.0.2.1/TCP/5000 |
+-------------------------------------+--------------------+
Dual-Stack Lite Carrier-Grade NAT Translation Table
双栈Lite载波级NAT转换表
The Softwire-Id is the IPv6 address assigned to the Dual-Stack host. Each host has a unique Softwire-Id. The source IPv4 address is one of the well-known IPv4 addresses. The AFTR could receive packets from different hosts sourced from the same IPv4 well-known address from different softwire tunnels. Similar to the gateway architecture, the AFTR combines the Softwire-Id and IPv4 address/port [Softwire-Id, IPv4+Port] to uniquely identify the individual host.
Softwire Id是分配给双堆栈主机的IPv6地址。每个主机都有一个唯一的Softwire-Id。源IPv4地址是众所周知的IPv4地址之一。AFTR可以从不同的软线隧道接收来自相同IPv4已知地址的不同主机的数据包。与网关体系结构类似，AFTR将软线Id和IPv4地址/端口[软线Id，IPv4+端口]组合在一起，以唯一标识单个主机。
Authors' Addresses
作者地址
Alain Durand Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089-1206 USA
美国加利福尼亚州桑尼维尔北马蒂尔达大道1194号阿兰·杜兰德·朱尼珀网络公司，邮编94089-1206
EMail: adurand@juniper.net
EMail: adurand@juniper.net
Ralph Droms Cisco 1414 Massachusetts Avenue Boxborough, MA 01714 USA
美国马萨诸塞州博克斯伯勒马萨诸塞大道1414号，邮编01714
EMail: rdroms@cisco.com
EMail: rdroms@cisco.com
James Woodyatt Apple 1 Infinite Loop Cupertino, CA 95014 USA
James Woodyatt苹果1号无限环Cupertino，加利福尼亚州，美国95014
EMail: jhw@apple.com
EMail: jhw@apple.com
Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 USA
Yiu L.Lee Comcast美国宾夕法尼亚州费城Comcast中心1号，邮编：19103
EMail: yiu_lee@cable.comcast.com
EMail: yiu_lee@cable.comcast.com