Internet Engineering Task Force (IETF) M. Mawatari
Request for Comments: 6877 Japan Internet Exchange
Category: Informational M. Kawashima
ISSN: 2070-1721 NEC AccessTechnica, Ltd.
C. Byrne
T-Mobile USA
April 2013
Internet Engineering Task Force (IETF) M. Mawatari
Request for Comments: 6877 Japan Internet Exchange
Category: Informational M. Kawashima
ISSN: 2070-1721 NEC AccessTechnica, Ltd.
C. Byrne
T-Mobile USA
April 2013
464XLAT: Combination of Stateful and Stateless Translation
464XLAT：有状态和无状态转换的组合
Abstract
摘要
This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.
本文档描述了一种体系结构（464XLAT），该体系结构通过将核心中现有的和众所周知的有状态协议转换（如RFC 6146所述）与边缘的无状态协议转换（如RFC 6145所述）相结合，在纯IPv6网络上提供有限的IPv4连接。464XLAT是一种简单且可扩展的技术，可以在不封装的情况下将有限的IPv4访问服务快速部署到仅限IPv6的边缘网络。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6877.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6877.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation and Uniqueness of 464XLAT . . . . . . . . . . . . . 4
4. Network Architecture . . . . . . . . . . . . . . . . . . . . . 4
4.1. Wireline Network Architecture . . . . . . . . . . . . . . 4
4.2. Wireless 3GPP Network Architecture . . . . . . . . . . . . 5
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Wireline Network Applicability . . . . . . . . . . . . . . 6
5.2. Wireless 3GPP Network Applicability . . . . . . . . . . . 7
6. Implementation Considerations . . . . . . . . . . . . . . . . 7
6.1. IPv6 Address Format . . . . . . . . . . . . . . . . . . . 7
6.2. IPv4/IPv6 Address Translation Chart . . . . . . . . . . . 7
6.3. IPv6 Prefix Handling . . . . . . . . . . . . . . . . . . . 9
6.4. DNS Proxy Implementation . . . . . . . . . . . . . . . . . 9
6.5. CLAT in a Gateway . . . . . . . . . . . . . . . . . . . . 9
6.6. CLAT-to-CLAT Communications . . . . . . . . . . . . . . . 10
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 10
7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 10
7.2. Traffic Treatment Scenarios . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Examples of IPv4/IPv6 Address Translation . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation and Uniqueness of 464XLAT . . . . . . . . . . . . . 4
4. Network Architecture . . . . . . . . . . . . . . . . . . . . . 4
4.1. Wireline Network Architecture . . . . . . . . . . . . . . 4
4.2. Wireless 3GPP Network Architecture . . . . . . . . . . . . 5
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Wireline Network Applicability . . . . . . . . . . . . . . 6
5.2. Wireless 3GPP Network Applicability . . . . . . . . . . . 7
6. Implementation Considerations . . . . . . . . . . . . . . . . 7
6.1. IPv6 Address Format . . . . . . . . . . . . . . . . . . . 7
6.2. IPv4/IPv6 Address Translation Chart . . . . . . . . . . . 7
6.3. IPv6 Prefix Handling . . . . . . . . . . . . . . . . . . . 9
6.4. DNS Proxy Implementation . . . . . . . . . . . . . . . . . 9
6.5. CLAT in a Gateway . . . . . . . . . . . . . . . . . . . . 9
6.6. CLAT-to-CLAT Communications . . . . . . . . . . . . . . . 10
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 10
7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 10
7.2. Traffic Treatment Scenarios . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Examples of IPv4/IPv6 Address Translation . . . . . . 13
With the exhaustion of the unallocated IPv4 address pools, it will be difficult for many networks to assign IPv4 addresses to end users.
随着未分配的IPv4地址池的耗尽，许多网络将难以将IPv4地址分配给最终用户。
This document describes an IPv4-over-IPv6 solution as one of the techniques for IPv4 service extension and encouragement of IPv6 deployment. 464XLAT is not a one-for-one replacement of full IPv4 functionality. The 464XLAT architecture only supports IPv4 in the client-server model, where the server has a global IPv4 address. This means it is not fit for IPv4 peer-to-peer communication or inbound IPv4 connections. 464XLAT builds on IPv6 transport and includes full any-to-any IPv6 communication.
本文档将IPv4-over-IPv6解决方案描述为IPv4服务扩展和鼓励IPv6部署的技术之一。464XLAT不是完整IPv4功能的一对一替代品。464XLAT体系结构仅支持客户机-服务器模式中的IPv4，其中服务器具有全局IPv4地址。这意味着它不适合IPv4对等通信或入站IPv4连接。464XLAT构建于IPv6传输之上，包括完整的任意对任意IPv6通信。
The 464XLAT architecture described in this document uses IPv4/IPv6 translation standardized in [RFC6145] and [RFC6146]. It does not require DNS64 [RFC6147] since an IPv4 host may simply send IPv4 packets, including packets to an IPv4 DNS server, that will be translated to IPv6 on the customer-side translator (CLAT) and back to IPv4 on the provider-side translator (PLAT). 464XLAT networks may use DNS64 [RFC6147] to enable single stateful translation [RFC6146] instead of 464XLAT double translation where possible. The 464XLAT architecture encourages the IPv6 transition by making IPv4 services reachable across IPv6-only networks and providing IPv6 and IPv4 connectivity to single-stack IPv4 or IPv6 servers and peers.
本文档中描述的464XLAT体系结构使用[RFC6145]和[RFC6146]中标准化的IPv4/IPv6转换。它不需要DNS64[RFC6147]，因为IPv4主机可以简单地发送IPv4数据包，包括发送到IPv4 DNS服务器的数据包，这些数据包将在客户端转换器（CLAT）上转换为IPv6，在提供商端转换器（PLAT）上转换回IPv4。464XLAT网络可能使用DNS64[RFC6147]来启用单状态转换[RFC6146]，而不是464XLAT双转换。464XLAT体系结构通过使IPv4服务可在仅限IPv6的网络上访问，并向单堆栈IPv4或IPv6服务器和对等方提供IPv6和IPv4连接，从而鼓励IPv6过渡。
PLAT: PLAT is provider-side translator (XLAT) that complies with [RFC6146]. It translates N:1 global IPv6 addresses to global IPv4 addresses, and vice versa.
PLAT:PLAT是符合[RFC6146]的提供者端转换器（XLAT）。它将N:1全局IPv6地址转换为全局IPv4地址，反之亦然。
CLAT: CLAT is customer-side translator (XLAT) that complies with [RFC6145]. It algorithmically translates 1:1 private IPv4 addresses to global IPv6 addresses, and vice versa. The CLAT function is applicable to a router or an end-node such as a mobile phone. The CLAT should perform IP routing and forwarding to facilitate packets forwarding through the stateless translation even if it is an end-node. The CLAT as a common home router or wireless Third Generation Partnership Project (3GPP) router is expected to perform gateway functions such as being a DHCP server and DNS proxy for local clients. The CLAT uses different IPv6 prefixes for CLAT-side and PLAT-side IPv4 addresses and therefore does not comply with the sentence "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix." in
CLAT:CLAT是符合[RFC6145]的客户端翻译器（XLAT）。它通过算法将1:1的专用IPv4地址转换为全局IPv6地址，反之亦然。CLAT功能适用于路由器或终端节点，如移动电话。CLAT应该执行IP路由和转发，以便于通过无状态转换进行数据包转发，即使它是一个终端节点。CLAT作为一个普通家庭路由器或无线第三代合作伙伴计划（3GPP）路由器，预计将执行网关功能，例如作为本地客户端的DHCP服务器和DNS代理。CLAT对CLAT端和平台端IPv4地址使用不同的IPv6前缀，因此不符合“IPv4可翻译IPv6地址和IPv4转换IPv6地址都应使用相同前缀”的规定
Section 3.3 of [RFC6052]. The CLAT does not facilitate communications between a local IPv4-only node and an IPv6- only node on the Internet.
[RFC6052]第3.3节。CLAT不促进本地仅IPv4节点和Internet上仅IPv6节点之间的通信。
The list below describes the motivation for 464XLAT and its unique characteristics.
下表描述了464XLAT的动机及其独特特性。
o 464XLAT has minimal IPv4 resource requirements and maximum IPv4 efficiency through statistical multiplexing.
o 通过统计多路复用，464XLAT具有最小的IPv4资源需求和最大的IPv4效率。
o No new protocols are required; there is quick deployment.
o 不需要新的协议；有快速部署。
o IPv6-only networks are simpler and therefore less expensive to operate than dual-stack networks.
o 仅IPv6网络比双栈网络更简单，因此运行成本更低。
o 464XLAT has consistent native IP-based monitoring and traffic engineering. Capacity-planning techniques can be applied without the indirection or obfuscation of a tunnel.
o 464XLAT具有一致的基于本机IP的监控和流量工程。容量规划技术的应用不需要对隧道进行间接或模糊处理。
Examples of 464XLAT architectures are shown in the figures in the following sections.
464XLAT体系结构的示例如以下各节中的图所示。
Wireline Network Architecture can be used in situations where there are clients behind the CLAT, regardless of the type of access service -- for example, fiber to the home (FTTH), Data Over Cable Service Interface Specification (DOCSIS), or WiFi.
有线网络体系结构可用于CLAT背后有客户端的情况，而不管接入服务的类型如何——例如，光纤到家（FTTH）、有线数据服务接口规范（DOCSIS）或WiFi。
Wireless 3GPP Network Architecture can be used in situations where a client terminates the wireless access network and possibly acts as a router with tethered clients.
无线3GPP网络架构可用于客户端终止无线接入网络并可能充当具有栓系客户端的路由器的情况。
The private IPv4 host in this diagram can reach global IPv4 hosts via translation on both the CLAT and PLAT. On the other hand, the IPv6 host can reach other IPv6 hosts on the Internet directly without translation. This means that the Customer Premises Equipment (CPE) / CLAT can not only have the function of a CLAT but also the function of an IPv6 native router for native IPv6 traffic. In this diagram, the v4p host behind the CLAT has [RFC1918] addresses.
此图中的专用IPv4主机可以通过CLAT和PLAT上的转换到达全局IPv4主机。另一方面，IPv6主机可以直接到达Internet上的其他IPv6主机，而无需翻译。这意味着客户场所设备（CPE）/CLAT不仅可以具有CLAT的功能，还可以具有用于本机IPv6流量的IPv6本机路由器的功能。在此图中，CLAT后面的v4p主机具有[RFC1918]地址。
+------+
| v6 |
| host |
+--+---+
|
.---+---.
/ \
/ IPv6 \
| Internet |
\ /
`----+----'
|
+------+ | .---+---. .------.
| v6 +---+ +------+ / \ +------+ / \
| host | | | | / IPv6 \ | | / IPv4 \
+------+ +---+ CLAT +---+ Network +---+ PLAT +---+ Internet |
+--------+ | | | \ / | | \ /
| v4p/v6 +-+ +------+ `---------' +------+ `----+----'
| host | | |
+--------+ | +--+---+
+------+ | | v4g |
| v4p +---+ | host |
| host | | +------+
+------+ |
+------+
| v6 |
| host |
+--+---+
|
.---+---.
/ \
/ IPv6 \
| Internet |
\ /
`----+----'
|
+------+ | .---+---. .------.
| v6 +---+ +------+ / \ +------+ / \
| host | | | | / IPv6 \ | | / IPv4 \
+------+ +---+ CLAT +---+ Network +---+ PLAT +---+ Internet |
+--------+ | | | \ / | | \ /
| v4p/v6 +-+ +------+ `---------' +------+ `----+----'
| host | | |
+--------+ | +--+---+
+------+ | | v4g |
| v4p +---+ | host |
| host | | +------+
+------+ |
<- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->
<- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->
v6 : Global IPv6 v4p : Private IPv4 v4g : Global IPv4
v6:全局IPv6 v4p:专用IPv4 v4g:全局IPv4
Figure 1: Wireline Network Topology
图1：有线网络拓扑
The CLAT function on the User Equipment (UE) provides an [RFC1918] address and IPv4 default route to the local node's network stack. The applications on the UE can use the private IPv4 address for reaching global IPv4 hosts via translation on both the CLAT and the PLAT. On the other hand, reaching IPv6 hosts (including hosts presented via DNS64 [RFC6147]) does not require the CLAT function on the UE.
用户设备（UE）上的CLAT功能提供[RFC1918]地址和到本地节点网络堆栈的IPv4默认路由。UE上的应用程序可以使用专用IPv4地址，通过CLAT和PLAT上的转换到达全局IPv4主机。另一方面，到达IPv6主机（包括通过DNS64[RFC6147]呈现的主机）不需要UE上的CLAT功能。
Presenting a private IPv4 network for tethering via NAT44 and stateless translation on the UE is also an application of the CLAT.
通过NAT44和UE上的无状态转换提供专用IPv4网络进行栓接也是CLAT的一个应用。
+------+
| v6 |
| host |
+--+---+
|
.---+---.
/ \
/ IPv6 \
| Internet |
\ /
UE / Mobile Phone `---------'
+----------------------+ |
| +----+ | | .---+---. .------.
| | v6 +----+ +------+ / \ +------+ / \
| +----+ | | | / IPv6 PDP \ | | / IPv4 \
| +---+ CLAT +---+ Mobile Core +---+ PLAT +--+ Internet |
| | | | \ GGSN / | | \ /
| | +------+ \ ' +------+ `----+---'
| +-----+ | | `-------' |
| | v4p +---+ | +--+---+
| +-----+ | | | v4g |
+----------------------+ | host |
+------+
+------+
| v6 |
| host |
+--+---+
|
.---+---.
/ \
/ IPv6 \
| Internet |
\ /
UE / Mobile Phone `---------'
+----------------------+ |
| +----+ | | .---+---. .------.
| | v6 +----+ +------+ / \ +------+ / \
| +----+ | | | / IPv6 PDP \ | | / IPv4 \
| +---+ CLAT +---+ Mobile Core +---+ PLAT +--+ Internet |
| | | | \ GGSN / | | \ /
| | +------+ \ ' +------+ `----+---'
| +-----+ | | `-------' |
| | v4p +---+ | +--+---+
| +-----+ | | | v4g |
+----------------------+ | host |
+------+
<- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->
<- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->
v6 : Global IPv6 v4p : Private IPv4 v4g : Global IPv4 PDP : Packet Data Protocol GGSN : Gateway GPRS Support Node
v6:全局IPv6 v4p:专用IPv4 v4g:全局IPv4 PDP:分组数据协议GGSN:网关GPRS支持节点
Figure 2: Wireless 3GPP Network Topology
图2：无线3GPP网络拓扑
When an Internet Service Provider (ISP) has IPv6 access service and provides 464XLAT, the ISP can provide outgoing IPv4 service to end users across an IPv6 access network. The result is that edge network growth is no longer tightly coupled to the availability of scarce IPv4 addresses.
当Internet服务提供商（ISP）具有IPv6访问服务并提供464XLAT时，ISP可以通过IPv6访问网络向最终用户提供传出IPv4服务。其结果是边缘网络的增长不再与稀缺IPv4地址的可用性紧密耦合。
If another ISP operates the PLAT, the edge ISP is only required to deploy an IPv6 access network. All ISPs do not need IPv4 access networks. They can migrate their access network to a simple and highly scalable IPv6-only environment.
如果其他ISP操作平台，则边缘ISP只需部署IPv6接入网络。所有ISP都不需要IPv4访问网络。他们可以将其接入网络迁移到一个简单且高度可扩展的纯IPv6环境。
At the time of writing, in April 2013, the vast majority of mobile networks are compliant to Pre-Release 9 3GPP standards. In Pre-Release 9 3GPP networks, Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) networks must signal and support both IPv4 and IPv6 Packet Data Protocol (PDP) attachments to access IPv4 and IPv6 network destinations [RFC6459]. Since there are two PDPs required to support two address families, this is double the number of PDPs required to support the status quo of one address family, which is IPv4.
在撰写本文时，2013年4月，绝大多数移动网络都符合预发布的第9版3GPP标准。在预发布的9 3GPP网络中，全球移动通信系统（GSM）和通用移动通信系统（UMTS）网络必须发送信号并支持IPv4和IPv6分组数据协议（PDP）附件，以访问IPv4和IPv6网络目的地[RFC6459]。由于需要两个PDP来支持两个地址系列，因此这是支持一个地址系列（IPv4）现状所需PDP数量的两倍。
For the cases of connecting to an IPv4 literal or IPv4 socket that require IPv4 connectivity, the CLAT function on the UE provides a private IPv4 address and IPv4 default route on the host for the applications to reference and bind to. Connections sourced from the IPv4 interface are immediately routed to the CLAT function and passed to the IPv6-only mobile network, destined for the PLAT. In summary, the UE performs the CLAT function that does a stateless translation [RFC6145], but only when required by an IPv4-only scenario such as IPv4 literals or IPv4-only sockets. The mobile network has a PLAT that does stateful translation [RFC6146].
对于连接到需要IPv4连接的IPv4文本或IPv4套接字的情况，UE上的CLAT函数在主机上提供专用IPv4地址和IPv4默认路由，供应用程序引用和绑定。来自IPv4接口的连接会立即路由到CLAT功能，并传递到仅限IPv6的移动网络，目的地为平台。总之，UE执行CLAT函数，该函数执行无状态转换[RFC6145]，但仅在仅IPv4的场景（如IPv4文本或仅IPv4的套接字）需要时执行。移动网络有一个执行状态转换的平台[RFC6146]。
464XLAT works with today's existing systems as much as possible. 464XLAT is compatible with existing solutions for network-based deep packet inspection like 3GPP standardized Policy and Charging Control (PCC) [TS.23203].
464XLAT尽可能与现有系统配合使用。464XLAT与现有的基于网络的深度数据包检查解决方案兼容，如3GPP标准化策略和计费控制（PCC）[TS.23203]。
The IPv6 address format in 464XLAT is defined in Section 2.2 of [RFC6052].
[RFC6052]第2.2节定义了464XLAT中的IPv6地址格式。
This chart offers an explanation about address translation architecture using a combination of stateful translation at the PLAT and stateless translation at the CLAT. The client on this chart is delegated an IPv6 prefix from a prefix delegation mechanism such as DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633]; therefore, it has a dedicated IPv6 prefix for translation.
此图表结合使用平台上的有状态转换和CLAT上的无状态转换，解释了地址转换体系结构。此图表上的客户端通过前缀委派机制（如DHCPv6前缀委派（DHCPv6 PD）[RFC3633]）委派IPv6前缀；因此，它有一个专用的IPv6前缀用于翻译。
Destination IPv4 address
+----------------------------+
| Global IPv4 address |
| assigned to IPv4 server |
+--------+ +----------------------------+
| IPv4 | Source IPv4 address
| server | +----------------------------+
+--------+ | Global IPv4 address |
^ | assigned to IPv4 PLAT pool |
| +----------------------------+
+--------+
| PLAT | Stateful XLATE(IPv4:IPv6=1:n)
+--------+
^
|
(IPv6 cloud)
Destination IPv6 address
+--------------------------------------------------------------+
| IPv4-embedded IPv6 address |
| defined in Section 2.2 of RFC 6052 |
+--------------------------------------------------------------+
Source IPv6 address
+--------------------------------------------------------------+
| IPv4-embedded IPv6 address |
| defined in Section 2.2 of RFC 6052 |
+--------------------------------------------------------------+
(IPv6 cloud)
^
|
+--------+
| CLAT | Stateless XLATE(IPv4:IPv6=1:1)
+--------+
^ Destination IPv4 address
| +----------------------------+
+--------+ | Global IPv4 address |
| IPv4 | | assigned to IPv4 server |
| client | +----------------------------+
+--------+ Source IPv4 address
+----------------------------+
| Private IPv4 address |
| assigned to IPv4 client |
+----------------------------+
Destination IPv4 address
+----------------------------+
| Global IPv4 address |
| assigned to IPv4 server |
+--------+ +----------------------------+
| IPv4 | Source IPv4 address
| server | +----------------------------+
+--------+ | Global IPv4 address |
^ | assigned to IPv4 PLAT pool |
| +----------------------------+
+--------+
| PLAT | Stateful XLATE(IPv4:IPv6=1:n)
+--------+
^
|
(IPv6 cloud)
Destination IPv6 address
+--------------------------------------------------------------+
| IPv4-embedded IPv6 address |
| defined in Section 2.2 of RFC 6052 |
+--------------------------------------------------------------+
Source IPv6 address
+--------------------------------------------------------------+
| IPv4-embedded IPv6 address |
| defined in Section 2.2 of RFC 6052 |
+--------------------------------------------------------------+
(IPv6 cloud)
^
|
+--------+
| CLAT | Stateless XLATE(IPv4:IPv6=1:1)
+--------+
^ Destination IPv4 address
| +----------------------------+
+--------+ | Global IPv4 address |
| IPv4 | | assigned to IPv4 server |
| client | +----------------------------+
+--------+ Source IPv4 address
+----------------------------+
| Private IPv4 address |
| assigned to IPv4 client |
+----------------------------+
Figure 3: Case of Enabling Only Stateless XLATE on CLAT
图3：在CLAT上仅启用无状态XLATE的情况
There are two relevant IPv6 prefixes that the CLAT must be aware of.
CLAT必须注意两个相关的IPv6前缀。
First, CLAT must know its own IPv6 prefixes. The CLAT should acquire a /64 for the uplink interface, a /64 for all downlink interfaces, and a dedicated /64 prefix for the purpose of sending and receiving statelessly translated packets. When a dedicated /64 prefix is not available for translation from DHCPv6-PD [RFC3633], the CLAT may perform NAT44 for all IPv4 LAN packets so that all the LAN-originated IPv4 packets appear from a single IPv4 address and are then statelessly translated to one interface IPv6 address that is claimed by the CLAT via the Neighbor Discovery Protocol (NDP) and defended with Duplicate Address Detection (DAD).
首先，CLAT必须知道自己的IPv6前缀。CLAT应为上行链路接口获取a/64，为所有下行链路接口获取a/64，并为发送和接收无状态转换的数据包获取专用的/64前缀。当专用/64前缀不可用于从DHCPv6 PD[RFC3633]进行转换时，CLAT可对所有IPv4 LAN数据包执行NAT44，以便所有源自LAN的IPv4数据包均来自单个IPv4地址，然后无状态地转换为CLAT通过邻居发现协议声明的一个接口IPv6地址（NDP）并使用重复地址检测（DAD）进行防护。
Second, the CLAT must discover the PLAT-side translation IPv6 prefix used as a destination of the PLAT. The CLAT will use this prefix as the destination of all translation packets that require stateful translation to the IPv4 Internet. It may discover the PLAT-side translation prefix using [Discovery-Heuristic]. In the future, some other mechanisms, such as a new DHCPv6 option, will possibly be defined to communicate the PLAT-side translation prefix.
其次，CLAT必须发现用作平台目标的平台端翻译IPv6前缀。CLAT将使用此前缀作为所有需要有状态转换到IPv4 Internet的转换数据包的目标。它可以使用[发现启发式]发现平台端翻译前缀。将来，可能会定义一些其他机制，例如新的DHCPv6选项，以传递平台端翻译前缀。
The CLAT should implement a DNS proxy as defined in [RFC5625]. The case of an IPv4-only node behind the CLAT querying an IPv4 DNS server is undesirable since it requires both stateful and stateless translation for each DNS lookup. The CLAT should set itself as the DNS server via DHCP or other means and should proxy DNS queries for IPv4 and IPv6 LAN clients. Using the CLAT-enabled home router or UE as a DNS proxy is a normal consumer gateway function and simplifies the traffic flow so that only IPv6 native queries are made across the access network. DNS queries from the client that are not sent to the DNS proxy on the CLAT must be allowed and are translated and forwarded just like any other IP traffic.
CLAT应实现[RFC5625]中定义的DNS代理。CLAT后面的仅IPv4节点查询IPv4 DNS服务器的情况是不可取的，因为它需要对每个DNS查找进行有状态和无状态转换。CLAT应通过DHCP或其他方式将自身设置为DNS服务器，并应代理IPv4和IPv6 LAN客户端的DNS查询。使用支持CLAT的家庭路由器或UE作为DNS代理是一种正常的消费者网关功能，它简化了通信流，因此只有IPv6本机查询通过接入网络进行。必须允许来自客户端的未发送到CLAT上DNS代理的DNS查询，并像任何其他IP流量一样进行转换和转发。
The CLAT feature can be implemented in a common home router or mobile phone that has a tethering feature. Routers with a CLAT feature should also provide common router services such as DHCP of [RFC1918] addresses, DHCPv6, NDP with Router Advertisement, and DNS service.
CLAT功能可以在具有栓系功能的普通家庭路由器或移动电话中实现。具有CLAT功能的路由器还应提供常见的路由器服务，如[RFC1918]地址的DHCP、DHCPv6、具有路由器广告的NDP和DNS服务。
464XLAT is a hub and spoke architecture focused on enabling IPv4-only services over IPv6-only networks. Interactive Connectivity Establishment (ICE) [RFC5245] may be used to support peer-to-peer communication within a 464XLAT network.
464XLAT是一种中心辐射式体系结构，专注于通过仅IPv6的网络实现仅IPv4的服务。交互式连接建立（ICE）[RFC5245]可用于支持464XLAT网络内的对等通信。
Even if the ISP for end users is different from the PLAT provider (e.g., another ISP), it can implement traffic engineering independently from the PLAT provider. Detailed reasons are below:
即使最终用户的ISP不同于平台提供商（例如，另一个ISP），它也可以独立于平台提供商实施流量工程。具体原因如下:
1. The ISP for end users can figure out the IPv4 destination address from the translated IPv6 packet header, so it can implement traffic engineering based on the IPv4 destination address (e.g., traffic monitoring for each IPv4 destination address, packet filtering for each IPv4 destination address, etc.). The tunneling methods do not have such an advantage, without any deep packet inspection for processing the inner IPv4 packet of the tunnel packet.
1. 最终用户的ISP可以从翻译的IPv6数据包头中找出IPv4目标地址，因此它可以基于IPv4目标地址实施流量工程（例如，每个IPv4目标地址的流量监控、每个IPv4目标地址的数据包过滤等）。隧道方法没有这样的优点，没有任何深度分组检查来处理隧道分组的内部IPv4分组。
2. If the ISP for end users can assign an IPv6 prefix greater than /64 to each subscriber, this 464XLAT architecture can separate the IPv6 prefix for native IPv6 packets and the XLAT prefixes for IPv4/IPv6 translation packets. Accordingly, it can identify the type of packets ("native IPv6 packets" and "IPv4/IPv6 translation packets") and implement traffic engineering based on the IPv6 prefix.
2. 如果最终用户的ISP可以为每个订户分配大于/64的IPv6前缀，则此464XLAT体系结构可以将本机IPv6数据包的IPv6前缀与IPv4/IPv6转换数据包的XLAT前缀分开。因此，它可以识别数据包的类型（“本机IPv6数据包”和“IPv4/IPv6转换数据包”），并基于IPv6前缀实施流量工程。
The below table outlines how different permutations of connectivity are treated in the 464XLAT architecture.
下表概述了464XLAT体系结构中如何处理不同的连接排列。
Note: 464XLAT double translation treatment will be stateless when a dedicated /64 is available for translation on the CLAT. Otherwise, the CLAT will have both stateful and stateless since it requires NAT44 from the LAN to a single IPv4 address and then stateless translation to a single IPv6 address.
注：当专用/64可用于CLAT上的翻译时，464XLAT双翻译处理将是无状态的。否则，CLAT将同时具有有状态和无状态，因为它需要NAT44从LAN到单个IPv4地址，然后无状态转换到单个IPv6地址。
+--------+-------------+-----------------------+-------------+
| Server | Application | Traffic Treatment | Location of |
| | and Host | | Translation |
+--------+-------------+-----------------------+-------------+
| IPv6 | IPv6 | End-to-End IPv6 | None |
+--------+-------------+-----------------------+-------------+
| IPv4 | IPv6 | Stateful Translation | PLAT |
+--------+-------------+-----------------------+-------------+
| IPv4 | IPv4 | 464XLAT | PLAT/CLAT |
+--------+-------------+-----------------------+-------------+
+--------+-------------+-----------------------+-------------+
| Server | Application | Traffic Treatment | Location of |
| | and Host | | Translation |
+--------+-------------+-----------------------+-------------+
| IPv6 | IPv6 | End-to-End IPv6 | None |
+--------+-------------+-----------------------+-------------+
| IPv4 | IPv6 | Stateful Translation | PLAT |
+--------+-------------+-----------------------+-------------+
| IPv4 | IPv4 | 464XLAT | PLAT/CLAT |
+--------+-------------+-----------------------+-------------+
Traffic Treatment Scenarios
交通处理方案
To implement a PLAT, see the security considerations presented in Section 5 of [RFC6146].
要实现平台，请参阅[RFC6146]第5节中介绍的安全注意事项。
To implement a CLAT, see the security considerations presented in Section 7 of [RFC6145]. The CLAT may comply with [RFC6092].
要实现CLAT，请参阅[RFC6145]第7节中介绍的安全注意事项。CLAT可能符合[RFC6092]。
The authors would like to thank JPIX NOC members, JPIX 464XLAT trial service members, Seiichi Kawamura, Dan Drown, Brian Carpenter, Rajiv Asati, Washam Fan, Behcet Sarikaya, Jan Zorz, Tatsuya Oishi, Lorenzo Colitti, Erik Kline, Ole Troan, Maoke Chen, Gang Chen, Tom Petch, Jouni Korhonen, Bjoern A. Zeeb, Hemant Singh, Vizdal Ales, Mark ZZZ Smith, Mikael Abrahamsson, Tore Anderson, Teemu Savolainen, Alexandru Petrescu, Gert Doering, Victor Kuarsingh, Ray Hunter, James Woodyatt, Tom Taylor, and Remi Despres for their helpful comments. We also would like to thank Fred Baker and Joel Jaeggli for their support.
作者要感谢JPIX NOC成员、JPIX 464XLAT审判服务团成员、川村成一、丹·斯多德、布赖恩·卡彭特、拉吉夫·阿萨蒂、瓦沙姆·范、白塞特·萨里卡亚、扬·佐尔兹、塔苏亚·大石、洛伦佐·科利蒂、埃里克·克莱恩、奥特罗安、陈茂科、陈刚、汤姆·佩奇、朱尼·科霍宁、比约恩·泽布、赫曼·辛格、维兹达尔·艾尔斯、马克·兹兹·史密斯、，米凯尔·阿布拉罕松、托尔·安德森、蒂姆·萨沃莱宁、亚历山大·彼得雷斯库、格特·多林、维克多·夸辛格、雷·亨特、詹姆斯·伍迪亚特、汤姆·泰勒和雷米·德斯普雷斯，感谢他们的有益评论。我们还要感谢Fred Baker和Joel Jaeggli的支持。
[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月。
[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月。
[Discovery-Heuristic] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", Work in Progress, March 2013.
[发现启发式]Savolainen，T.，Korhonen，J.，和D.Wing，“用于IPv6地址合成的IPv6前缀的发现”，正在进行的工作，2013年3月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625]Bellis，R.，“DNS代理实施指南”，BCP 152，RFC 56252009年8月。
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.
[RFC6092]Woodyatt，J.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，2011年1月。
[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月。
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012.
[RFC6459]Korhonen，J.，Soininen，J.，Patil，B.，Savolainen，T.，Bajko，G.，和K.Iisakkila，“第三代合作伙伴关系项目（3GPP）中的IPv6演进包系统（EPS）”，RFC 6459，2012年1月。
[TS.23203] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 10.7.0, June 2012.
[TS.23203]3GPP，“政策和收费控制体系结构”，3GPP TS 23.203 10.7.0，2012年6月。
Appendix A. Examples of IPv4/IPv6 Address Translation
附录A.IPv4/IPv6地址转换示例
The following is an example of IPv4/IPv6 address translation on the 464XLAT architecture.
以下是464XLAT体系结构上IPv4/IPv6地址转换的示例。
In the case that an IPv6 prefix greater than /64 is assigned to an end user by such as DHCPv6-PD [RFC3633], the CLAT can use a dedicated /64 from the assigned IPv6 prefix.
在诸如DHCPv6 PD[RFC3633]将大于/64的IPv6前缀分配给最终用户的情况下，CLAT可以使用分配的IPv6前缀中的专用/64。
Host & configuration value
+------------------------------+
| IPv4 server |
| [198.51.100.1] | IP packet header
+------------------------------+ +--------------------------------+
^ | Destination IP address |
| | [198.51.100.1] |
| | Source IP address |
| | [192.0.2.1] |
+------------------------------+ +--------------------------------+
| PLAT | ^
| IPv4 pool address | |
| [192.0.2.1 - 192.0.2.100] | |
| PLAT-side XLATE IPv6 prefix | |
| [2001:db8:1234::/96] | |
+------------------------------+ +--------------------------------+
^ | Destination IP address |
| | [2001:db8:1234::198.51.100.1] |
| | Source IP address |
| | [2001:db8:aaaa::192.168.1.2] |
+------------------------------+ +--------------------------------+
| CLAT | ^
| PLAT-side XLATE IPv6 prefix | |
| [2001:db8:1234::/96] | |
| CLAT-side XLATE IPv6 prefix | |
| [2001:db8:aaaa::/96] | |
+------------------------------+ +--------------------------------+
^ | Destination IP address |
| | [198.51.100.1] |
| | Source IP address |
| | [192.168.1.2] |
+------------------------------+ +--------------------------------+
| IPv4 client |
| [192.168.1.2/24] |
+------------------------------+
Delegated IPv6 prefix for client: 2001:db8:aaaa::/56
Host & configuration value
+------------------------------+
| IPv4 server |
| [198.51.100.1] | IP packet header
+------------------------------+ +--------------------------------+
^ | Destination IP address |
| | [198.51.100.1] |
| | Source IP address |
| | [192.0.2.1] |
+------------------------------+ +--------------------------------+
| PLAT | ^
| IPv4 pool address | |
| [192.0.2.1 - 192.0.2.100] | |
| PLAT-side XLATE IPv6 prefix | |
| [2001:db8:1234::/96] | |
+------------------------------+ +--------------------------------+
^ | Destination IP address |
| | [2001:db8:1234::198.51.100.1] |
| | Source IP address |
| | [2001:db8:aaaa::192.168.1.2] |
+------------------------------+ +--------------------------------+
| CLAT | ^
| PLAT-side XLATE IPv6 prefix | |
| [2001:db8:1234::/96] | |
| CLAT-side XLATE IPv6 prefix | |
| [2001:db8:aaaa::/96] | |
+------------------------------+ +--------------------------------+
^ | Destination IP address |
| | [198.51.100.1] |
| | Source IP address |
| | [192.168.1.2] |
+------------------------------+ +--------------------------------+
| IPv4 client |
| [192.168.1.2/24] |
+------------------------------+
Delegated IPv6 prefix for client: 2001:db8:aaaa::/56
Authors' Addresses
作者地址
Masataka Mawatari Japan Internet Exchange Co., Ltd. KDDI Otemachi Building 19F, 1-8-1 Otemachi, Chiyoda-ku, Tokyo 100-0004 JAPAN
Masataka Mawatari日本互联网交换有限公司日本东京千代田区大町1-8-1号大町KDDI大厦19楼100-0004
Phone: +81 3 3243 9579
EMail: mawatari@jpix.ad.jp
Phone: +81 3 3243 9579
EMail: mawatari@jpix.ad.jp
Masanobu Kawashima NEC AccessTechnica, Ltd. 800, Shimomata Kakegawa-shi, Shizuoka 436-8501 JAPAN
日本静冈岛下田角川市川岛正步NEC配件技术有限公司800号，邮编436-8501
Phone: +81 537 22 8274
EMail: kawashimam@vx.jp.nec.com
Phone: +81 537 22 8274
EMail: kawashimam@vx.jp.nec.com
Cameron Byrne T-Mobile USA Bellevue, Washington 98006 USA
Cameron Byrne T-Mobile美国华盛顿贝尔维尤，邮编：98006
EMail: cameron.byrne@t-mobile.com
EMail: cameron.byrne@t-mobile.com