Internet Engineering Task Force (IETF) R. Despres
Request for Comments: 7600 RD-IPtech
Category: Experimental S. Jiang, Ed.
ISSN: 2070-1721 Huawei Technologies Co., Ltd
R. Penno
Cisco Systems, Inc.
Y. Lee
Comcast
G. Chen
China Mobile
M. Chen
BBIX, Inc.
July 2015
Internet Engineering Task Force (IETF) R. Despres
Request for Comments: 7600 RD-IPtech
Category: Experimental S. Jiang, Ed.
ISSN: 2070-1721 Huawei Technologies Co., Ltd
R. Penno
Cisco Systems, Inc.
Y. Lee
Comcast
G. Chen
China Mobile
M. Chen
BBIX, Inc.
July 2015
IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
通过IPv6的IPv4剩余部署-无状态解决方案（第4条）
Abstract
摘要
This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers. The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end. Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set.
本文档指定了一种无状态解决方案，供服务提供商逐步部署仅限IPv6的网络域，同时仍向客户提供IPv4服务。该解决方案的独特属性是，在域遍历期间，TCP/UDP IPv4数据包是有效的TCP/UDP IPv6数据包，并且IPv4分段规则完全保留为端到端。可以为每个客户分配一个公共IPv4地址、多个公共IPv4地址或具有受限端口集的共享地址。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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/rfc7600.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7600.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................5
3. The 4rd Model ...................................................7
4. Protocol Specifications .........................................9
4.1. NAT44 on CE ................................................9
4.2. Mapping Rules and Other Domain Parameters .................10
4.3. Reversible Packet Translations at Domain Entries
and Exits .................................................11
4.4. Address Mapping from CE IPv6 Prefixes to 4rd IPv4
Prefixes ..................................................17
4.5. Address Mapping from 4rd IPv4 Addresses to 4rd
IPv6 Addresses ............................................19
4.6. Fragmentation Processing ..................................23
4.6.1. Fragmentation at Domain Entry ......................23
4.6.2. Ports of Fragments Addressed to
Shared-Address CEs .................................24
4.6.3. Packet Identifications from Shared-Address CEs .....26
4.7. TOS and Traffic Class Processing ..........................26
4.8. Tunnel-Generated ICMPv6 Error Messages ....................27
4.9. Provisioning 4rd Parameters to CEs ........................27
5. Security Considerations ........................................30
6. IANA Considerations ............................................31
7. Relationship with Previous Works ...............................31
8. References .....................................................33
8.1. Normative References ......................................33
8.2. Informative References ....................................34
Appendix A. Textual Representation of Mapping Rules ...............37
Appendix B. Configuring Multiple Mapping Rules ....................37
Appendix C. Adding Shared IPv4 Addresses to an IPv6 Network .......39
C.1. With CEs within CPEs .......................................39
C.2. With Some CEs behind Third-Party Router CPEs ..............41
Appendix D. Replacing Dual-Stack Routing with IPv6-Only Routing ...42
Appendix E. Adding IPv6 and 4rd Service to a Net-10 Network .......43
Acknowledgements ..................................................44
Authors' Addresses ................................................44
1. Introduction ....................................................4
2. Terminology .....................................................5
3. The 4rd Model ...................................................7
4. Protocol Specifications .........................................9
4.1. NAT44 on CE ................................................9
4.2. Mapping Rules and Other Domain Parameters .................10
4.3. Reversible Packet Translations at Domain Entries
and Exits .................................................11
4.4. Address Mapping from CE IPv6 Prefixes to 4rd IPv4
Prefixes ..................................................17
4.5. Address Mapping from 4rd IPv4 Addresses to 4rd
IPv6 Addresses ............................................19
4.6. Fragmentation Processing ..................................23
4.6.1. Fragmentation at Domain Entry ......................23
4.6.2. Ports of Fragments Addressed to
Shared-Address CEs .................................24
4.6.3. Packet Identifications from Shared-Address CEs .....26
4.7. TOS and Traffic Class Processing ..........................26
4.8. Tunnel-Generated ICMPv6 Error Messages ....................27
4.9. Provisioning 4rd Parameters to CEs ........................27
5. Security Considerations ........................................30
6. IANA Considerations ............................................31
7. Relationship with Previous Works ...............................31
8. References .....................................................33
8.1. Normative References ......................................33
8.2. Informative References ....................................34
Appendix A. Textual Representation of Mapping Rules ...............37
Appendix B. Configuring Multiple Mapping Rules ....................37
Appendix C. Adding Shared IPv4 Addresses to an IPv6 Network .......39
C.1. With CEs within CPEs .......................................39
C.2. With Some CEs behind Third-Party Router CPEs ..............41
Appendix D. Replacing Dual-Stack Routing with IPv6-Only Routing ...42
Appendix E. Adding IPv6 and 4rd Service to a Net-10 Network .......43
Acknowledgements ..................................................44
Authors' Addresses ................................................44
For service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers, the need for a stateless solution, i.e., one where no per-customer state is needed in IPv4-IPv6 gateway nodes of the provider, has been discussed in [Solutions-4v6]. This document specifies one such solution, named "4rd" for IPv4 Residual Deployment. Its distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end.
对于服务提供商在继续向客户提供IPv4服务的同时逐步部署仅限IPv6的网络域，需要无状态解决方案，即在提供商的IPv4-IPv6网关节点中不需要每个客户的状态，已在[Solutions-4v6]中讨论过。本文档为IPv4剩余部署指定了一个名为“4rd”的解决方案。其独特的特性是，TCP/UDP IPv4数据包在域遍历期间是有效的TCP/UDP IPv6数据包，并且IPv4分段规则完全保留端到端。
Using this solution, IPv4 packets are transparently tunneled across IPv6 networks (the reverse of IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969], in which IPv6 packets are statelessly tunneled across IPv4 networks).
使用此解决方案，IPv4数据包通过IPv6网络透明地隧道传输（与IPv4基础设施上的IPv6快速部署（6rd）[RFC5969]相反，其中IPv6数据包通过IPv4网络无状态隧道传输）。
While IPv6 headers are too long to be mapped into IPv4 headers (which is why 6rd requires encapsulation of full IPv6 packets in IPv4 packets), IPv4 headers can be reversibly translated into IPv6 headers in such a way that, during IPv6 domain traversal, UDP packets having checksums and TCP packets are valid IPv6 packets. IPv6-only middleboxes that perform deep packet inspection can operate on them, in particular for port inspection and web caches.
虽然IPv6报头太长，无法映射到IPv4报头（这就是为什么6rd需要在IPv4数据包中封装完整的IPv6数据包），但IPv4报头可以可逆地转换为IPv6报头，从而在IPv6域遍历期间，具有校验和的UDP数据包和TCP数据包都是有效的IPv6数据包。只有执行深度数据包检查的IPv6中间盒才能在其上运行，特别是用于端口检查和web缓存。
In order to deal with the IPv4 address shortage, customers can be assigned shared public IPv4 addresses with statically assigned restricted port sets. As such, it is a particular application of the Address plus Port (A+P) approach [RFC6346].
为了解决IPv4地址不足的问题，可以使用静态分配的受限端口集为客户分配共享公共IPv4地址。因此，它是地址加端口（a+P）方法[RFC6346]的一个特殊应用。
Deploying 4rd in networks that have enough public IPv4 addresses, customer sites can also be assigned full public IPv4 addresses. 4rd also supports scenarios where a set of public IPv4 addresses are assigned to customer sites.
在具有足够公共IPv4地址的网络中部署第4rd时，还可以为客户站点分配完整的公共IPv4地址。4rd还支持将一组公共IPv4地址分配给客户站点的场景。
The design of 4rd builds on a number of previous proposals made for IPv4-via-IPv6 transition technologies (Section 7).
4rd的设计建立在先前针对IPv4-via-IPv6过渡技术提出的许多建议的基础上（第7节）。
In some use cases, IPv4-only applications of 4rd-capable customer nodes can also work with stateful NAT64s [RFC6146], provided these are upgraded to support 4rd tunnels in addition to their IP/ICMP translation [RFC6145]. The advantage is then a more complete IPv4 transparency than with double translation.
在某些用例中，支持第4条的客户节点的仅IPv4应用程序也可以与有状态NAT64[RFC6146]一起工作，前提是这些应用程序除了支持IP/ICMP转换[RFC6145]外，还可以升级为支持第4条隧道。这样做的好处是IPv4的透明度比双重转换更全面。
How the 4rd model fits in the Internet architecture is summarized in Section 3. The protocol specifications are detailed in Section 4. Sections 5 and 6 deal with security considerations and IANA considerations, respectively. Previous proposals that influenced
第3节总结了第4个模型如何适应互联网体系结构。协议规范详见第4节。第5节和第6节分别涉及安全考虑和IANA考虑。以前的提案影响了
this specification are listed in Section 7. A few typical 4rd use cases are presented in Appendices A, B, C, D, and E.
本规范在第7节中列出。附录A、B、C、D和E中介绍了一些典型的第四次使用案例。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
ISP: Internet Service Provider. In this document, the service it offers can be DSL, fiber-optics, cable, or mobile. The ISP can also be a private-network operator.
ISP：互联网服务提供商。在本文档中，它提供的服务可以是DSL、光纤、电缆或移动设备。ISP也可以是专用网络运营商。
4rd (IPv4 Residual Deployment): An extension of the IPv4 service where public IPv4 addresses can be statically shared among several customer sites, each one being assigned an exclusive port set. This service is supported across IPv6-routing domains.
第4rd（IPv4剩余部署）：IPv4服务的扩展，在该服务中，公共IPv4地址可以在多个客户站点之间静态共享，每个站点分配一个专用端口集。跨IPv6路由域支持此服务。
4rd domain (or Domain): An ISP-operated IPv6 network across which 4rd is supported according to the present specification.
4rd域（或域）：ISP操作的IPv6网络，根据当前规范，支持通过该网络进行4rd。
Tunnel packet: An IPv6 packet that transparently conveys an IPv4 packet across a 4rd domain. Its header has enough information to reconstitute the IPv4 header at Domain exit. Its payload is the original IPv4 payload.
隧道数据包：在第4个域中透明传输IPv4数据包的IPv6数据包。其标头具有足够的信息，可以在域出口处重新构造IPv4标头。其有效负载是原始IPv4有效负载。
CE (Customer Edge): A customer-side tunnel endpoint. It can be in a node that is a host, a router, or both.
CE（客户边缘）：客户端隧道端点。它可以位于作为主机、路由器或两者的节点中。
BR (Border Relay): An ISP-side tunnel endpoint. Because its operation is stateless (neither per CE nor per session state), it can be replicated in as many nodes as needed for scalability.
BR（边界中继）：ISP侧隧道端点。因为它的操作是无状态的（既不是每个CE也不是每个会话状态），所以可以根据需要在任意多的节点中复制它，以实现可伸缩性。
4rd IPv6 address: IPv6 address used as the destination of a Tunnel packet sent to a CE or a BR.
第4条IPv6地址：用作发送到CE或BR的隧道数据包的目标的IPv6地址。
NAT64+: An ISP NAT64 [RFC6146] that is upgraded to support 4rd tunneling when IPv6 addresses it deals with are 4rd IPv6 addresses.
NAT64+：一个ISP NAT64[RFC6146]，当它处理的IPv6地址是第四个IPv6地址时，它被升级以支持第四个隧道。
4rd IPv4 address: A public IPv4 address or, in the case of a shared public IPv4 address, a public transport address (public IPv4 address plus port number).
第4个IPv4地址：公共IPv4地址，如果是共享公共IPv4地址，则为公共传输地址（公共IPv4地址加端口号）。
PSID (Port-Set Identifier): A flexible-length field that algorithmically identifies a port set.
PSID（端口集标识符）：一个灵活的长度字段，通过算法标识端口集。
4rd IPv4 prefix: A flexible-length prefix that may be a public IPv4 prefix, a public IPv4 address, or a public IPv4 address followed by a PSID.
第4rd IPv4前缀：灵活长度前缀，可以是公共IPv4前缀、公共IPv4地址或公共IPv4地址，后跟PSID。
Mapping rule: A set of parameters that are used by BRs and CEs to derive 4rd IPv6 addresses from 4rd IPv4 addresses. Mapping rules are also used by each CE to derive a 4rd IPv4 prefix from an IPv6 prefix that has been delegated to it.
映射规则：BRs和CEs用于从第4个IPv4地址派生第4个IPv6地址的一组参数。每个CE还使用映射规则从已委派给它的IPv6前缀派生第4个IPv4前缀。
EA bits (Embedded Address bits): Bits that are the same in a 4rd IPv4 address and in the 4rd IPv6 address derived from it.
EA位（嵌入式地址位）：在第4个IPv4地址和从其派生的第4个IPv6地址中相同的位。
BR Mapping rule: The Mapping rule that is applicable to off-domain IPv4 addresses (addresses reachable via BRs). It can also apply to some or all CE-assigned IPv4 addresses.
BR映射规则：适用于域外IPv4地址（可通过BRs访问的地址）的映射规则。它还可以应用于某些或所有CE分配的IPv4地址。
CE Mapping rule: A Mapping rule that is applicable only to CE-assigned IPv4 addresses (shared or not).
CE映射规则：仅适用于CE分配的IPv4地址（共享或非共享）的映射规则。
NAT64+ Mapping rule: The Mapping rule that is applicable to IPv4 addresses reachable via a NAT64+.
NAT64+映射规则：适用于可通过NAT64+访问的IPv4地址的映射规则。
CNP (Checksum Neutrality Preserver): A field of 4rd IPv6 addresses that ensures that TCP-like checksums do not change when IPv4 addresses are replaced with 4rd IPv6 addresses.
CNP（校验和中立性保护器）：第4个IPv6地址的字段，确保当IPv4地址替换为第4个IPv6地址时，类TCP校验和不会更改。
4rd Tag: A 16-bit tag whose value allows 4rd CEs, BRs, and NAT64+s to distinguish 4rd IPv6 addresses from other IPv6 addresses.
4rd标记：一个16位标记，其值允许4rd CEs、BRs和NAT64+s将4rd IPv6地址与其他IPv6地址区分开来。
4rd Domain
+-----------------------------+
| IPv6 routing |
| Enforced ingress filtering | +----------
... | | |
| +------+
Customer site | |BR(s) | IPv4
+------------+ | BR IPv6 prefix --> |and/or| Internet
| dual-stack | | |N4T64+|
| +--+ | +------+
| |CE+-+ <-- a CE IPv6 prefix | |
| +--+ | | +----------
| | | |
+------------+ | <--IPv4 tunnels--> +------------
=> Derived | (Mesh or hub-and-spoke |
4rd IPv4 prefix| topologies) | IPv6
| | Internet
... | |
| +------------
+-----------------------------+
<== one or several Mapping rules
(e.g., announced to CEs in stateless DHCPv6)
4rd Domain
+-----------------------------+
| IPv6 routing |
| Enforced ingress filtering | +----------
... | | |
| +------+
Customer site | |BR(s) | IPv4
+------------+ | BR IPv6 prefix --> |and/or| Internet
| dual-stack | | |N4T64+|
| +--+ | +------+
| |CE+-+ <-- a CE IPv6 prefix | |
| +--+ | | +----------
| | | |
+------------+ | <--IPv4 tunnels--> +------------
=> Derived | (Mesh or hub-and-spoke |
4rd IPv4 prefix| topologies) | IPv6
| | Internet
... | |
| +------------
+-----------------------------+
<== one or several Mapping rules
(e.g., announced to CEs in stateless DHCPv6)
Figure 1: The 4rd Model in the Internet Architecture
图1:Internet体系结构中的第四个模型
How the 4rd model fits in the Internet architecture is represented in Figure 1.
图1显示了第4个模型如何适应Internet体系结构。
A 4rd domain is an IPv6 network that includes one or several 4rd BRs or NAT64+s at its border with the public IPv4 Internet and that can advertise its IPv4-IPv6 Mapping rule(s) to CEs according to Section 4.9.
第4个域是一个IPv6网络，在其与公共IPv4 Internet的边界处包含一个或多个第4个BRs或NAT64+s，并且可以根据第4.9节将其IPv4-IPv6映射规则公布到CEs。
BRs of a 4rd Domain are all identical as far as 4rd is concerned. In a 4rd CE, the IPv4 packets that need to reach a BR will be transformed (as detailed in Section 4.3) into IPv6 packets that have the same anycast IPv6 prefix, which is the 80-bit BR prefix, in their destination addresses. They are then routed to any of the BRs. The 80-bit BR IPv6 prefix is an arbitrarily chosen /64 prefix from the IPv6 address space of the network operator and appended with 0x0300 (16-bit 4rd Tag; see R-9 in Section 4.5).
就第四个域而言，第四个域的BR都是相同的。在第4rd CE中，需要到达BR的IPv4数据包将被转换（如第4.3节所述）为在其目标地址中具有相同选播IPv6前缀（即80位BR前缀）的IPv6数据包。然后，它们被路由到任何BRs。80位BR IPv6前缀是从网络运营商的IPv6地址空间中任意选择的/64前缀，并附加0x0300（16位4rd标记；参见第4.5节中的R-9）。
Using the Mapping rule that applies, each CE derives its 4rd IPv4 prefix from its delegated IPv6 prefix, or one of them if it has several; see Section 4.4 for details. If the obtained IPv4 prefix has more than 32 bits, the assigned IPv4 address is shared among several CEs. Bits beyond the first 32 specify a set of ports whose use is reserved for the CE.
使用适用的映射规则，每个CE从其委派的IPv6前缀或其中一个（如果有多个）派生其第4个IPv4前缀；详见第4.4节。如果获得的IPv4前缀超过32位，则分配的IPv4地址将在多个CE之间共享。超过前32位的位指定一组端口，这些端口的使用保留给CE。
IPv4 traffic is automatically tunneled across the Domain, in either mesh topology or hub-and-spoke topology [RFC4925]. By default, IPv4 traffic between two CEs follows a direct IPv6 route between them (mesh topology). If the ISP configures the hub-and-spoke option, each IPv4 packet from one CE to another is routed via a BR.
IPv4流量在网状拓扑或中心辐射拓扑[RFC4925]中跨域自动隧道传输。默认情况下，两个CE之间的IPv4通信遵循它们之间的直接IPv6路由（网状拓扑）。如果ISP配置了集线器和分支选项，则每个IPv4数据包从一个CE路由到另一个CE，通过BR路由。
During Domain traversal, each tunneled TCP/UDP IPv4 packet looks like a valid TCP/UDP IPv6 packet. Thus, TCP/UDP access control lists that apply to IPv6, and possibly some other functions using deep packet inspection, also apply to IPv4.
在域遍历期间，每个隧道TCP/UDP IPv4数据包看起来都像一个有效的TCP/UDP IPv6数据包。因此，适用于IPv6的TCP/UDP访问控制列表，以及可能使用深度数据包检查的其他一些功能，也适用于IPv4。
In order for IPv4 anti-spoofing protection in CEs and BRs to remain effective when combined with 4rd tunneling, ingress filtering [RFC3704] has to be in effect in IPv6 (see R-12 and Section 5).
为了使CEs和BRs中的IPv4反欺骗保护在与第4条隧道相结合时保持有效，必须在IPv6中实施入口过滤[RFC3704]（见R-12和第5节）。
If an ISP wishes to support dynamic IPv4 address sharing in addition to or in place of 4rd stateless address sharing, it can do so by means of a stateful NAT64. By upgrading this NAT to add support for 4rd tunnels, which makes it a NAT64+, CEs that are assigned no static IPv4 space can benefit from complete IPv4 transparency between the CE and the NAT64. (Without this NAT64 upgrade, IPv4 traffic is translated to IPv6 and back to IPv4, during which time the DF = MF = 1 combination for IPv4, as recommended for host fragmentation in Section 8 of [RFC4821], is lost.)
如果ISP希望在第4个无状态地址共享的基础上或替代第4个无状态地址共享来支持动态IPv4地址共享，则可以通过有状态NAT64来实现。通过升级此NAT以添加对第4条隧道的支持（使其成为NAT64+），未分配任何静态IPv4空间的CE可以从CE和NAT64之间的IPv4完全透明中获益。（如果没有此NAT64升级，IPv4流量将转换为IPv6并返回IPv4，在此期间，[RFC4821]第8节中建议的IPv4的DF=MF=1组合将丢失。）
IPv4 packets are kept unchanged by Domain traversal, except that:
IPv4数据包通过域遍历保持不变，但以下情况除外：
o The IPv4 Time To Live (TTL), unless it is 1 or 255 at Domain entry, decreases during Domain traversal by the number of traversed routers. This is acceptable because it is undetectable end to end and also because TTL values that can be used with some protocols to test the adjacency of communicating routers are preserved [RFC4271] [RFC5082]. The effect on the traceroute utility, which uses TTL expiry to discover routers of end-to-end paths, is noted in Section 4.3.
o IPv4生存时间（TTL），除非在域进入时为1或255，否则在域遍历过程中会减少被遍历路由器的数量。这是可以接受的，因为它是无法检测到的端到端，也因为可以与某些协议一起使用以测试通信路由器的邻接性的TTL值被保留[RFC4271][RFC5082]。跟踪路由实用程序使用TTL到期来发现端到端路径的路由器，其影响在第4.3节中有所说明。
o IPv4 packets whose lengths are <= 68 octets always have their "Don't Fragment" (DF) flags set to 1 at Domain exit even if they had DF = 0 at Domain entry. This is acceptable because these packets are too short to be fragmented [RFC791] and so their DF bits have no meaning. Besides, both [RFC1191] and [RFC4821] recommend that sources always set DF to 1.
o 长度小于等于68个八位字节的IPv4数据包始终在域出口处将其“不分段”（DF）标志设置为1，即使它们在域入口处的DF=0。这是可以接受的，因为这些数据包太短，无法分段[RFC791]，因此它们的DF位没有意义。此外，[RFC1191]和[RFC4821]都建议震源始终将DF设置为1。
o Unless the Tunnel Traffic Class option applies to a Domain (Section 4.2), IPv4 packets may have their Type of Service (TOS) fields modified after Domain traversal (Section 4.7).
o 除非Tunnel Traffic Class选项适用于域（第4.2节），否则IPv4数据包在域遍历后可能会修改其服务类型（TOS）字段（第4.7节）。
This section describes detailed 4rd protocol specifications. They are mainly organized by functions. As a brief summary:
本节介绍详细的4rd协议规范。它们主要是按职能组织的。作为简要总结：
o A 4rd CE MUST follow R-1, R-2, R-3, R-4, R-6, R-7, R-8, R-9, R-10, R-11, R-12, R-13, R-14, R-16, R-17, R-18, R-19, R-20, R-21, R-22, R-23, R-24, R-25, R-26, and R-27.
o 第四个CE必须遵循R-1、R-2、R-3、R-4、R-6、R-7、R-8、R-9、R-10、R-11、R-12、R-13、R-14、R-16、R-17、R-18、R-19、R-20、R-21、R-22、R-23、R-24、R-25、R-26和R-27。
o A 4rd BR MUST follow R-2, R-3, R-4, R-5, R-6, R-9, R-12, R-13, R-14, R-15, R-19, R-20, R-21, R-22, and R-24.
o 第四个BR必须在R-2、R-3、R-4、R-5、R-6、R-9、R-12、R-13、R-14、R-15、R-19、R-20、R-21、R-22和R-24之后。
R-1: A CE node that is assigned a shared public IPv4 address MUST include a NAT44 [RFC3022]. This NAT44 MUST only use external ports that are in the CE-assigned port set.
R-1:分配了共享公共IPv4地址的CE节点必须包含NAT44[RFC3022]。此NAT44必须仅使用CE分配端口集中的外部端口。
NOTE: This specification only concerns IPv4 communication between IPv4-capable endpoints. For communication between IPv4-only endpoints and IPv6-only remote endpoints, the "Bump-in-the-Host" (BIH) specification [RFC6535] can be used. It can coexist in a node with the CE function, including scenarios where the IPv4-only function is a NAT44 [RFC3022].
注意：此规范仅涉及支持IPv4的端点之间的IPv4通信。对于仅IPv4端点和仅IPv6远程端点之间的通信，可以使用“主机通气”（BIH）规范[RFC6535]。它可以与CE功能共存于节点中，包括仅IPv4功能为NAT44[RFC3022]的场景。
R-2: CEs and BRs MUST be configured with the following Domain parameters:
R-2:CEs和BRs必须配置以下域参数：
A. One or several Mapping rules, each one comprising the following:
A.一个或多个映射规则，每个规则包括以下内容：
1. Rule IPv4 prefix
1. 规则IPv4前缀
2. EA-bits length
2. EA位长度
3. Rule IPv6 prefix
3. 规则IPv6前缀
4. Well-Known Ports (WKPs) authorized (OPTIONAL)
4. 知名端口（WKP）授权（可选）
B. Domain Path MTU (PMTU)
B.域路径MTU（PMTU）
C. Hub-and-spoke topology (Yes or No)
C.轮辐式拓扑（是或否）
D. Tunnel Traffic Class (OPTIONAL)
D.隧道交通等级（可选）
"Rule IPv4 prefix" is used to find, by a longest match, which Mapping rule applies to a 4rd IPv4 address (Section 4.5). A Mapping rule whose Rule IPv4 prefix is longer than /0 is a CE Mapping rule. BR and NAT64+ Mapping rules, which must apply to all off-domain IPv4 addresses, have /0 as their Rule IPv4 prefixes.
“规则IPv4前缀”用于通过最长匹配查找应用于第四个IPv4地址的映射规则（第4.5节）。规则IPv4前缀长于/0的映射规则是CE映射规则。BR和NAT64+映射规则必须应用于所有域外IPv4地址，它们的规则IPv4前缀为/0。
"EA-bits length" is the number of bits that are common to 4rd IPv4 addresses and 4rd IPv6 addresses derived from them. In a CE Mapping rule, it is also the number of bits that are common to a CE-delegated IPv6 prefix and the 4rd IPv4 prefix derived from it. BR and NAT64+ Mapping rules have EA-bits lengths equal to 32.
“EA bits length”是第4个IPv4地址和从中派生的第4个IPv6地址共有的位数。在CE映射规则中，它也是CE委派的IPv6前缀和从其派生的第4个IPv4前缀共有的位数。BR和NAT64+映射规则的EA位长度等于32。
"Rule IPv6 prefix" is the prefix that is used as a substitute for the Rule IPv4 prefix when a 4rd IPv6 address is derived from a 4rd IPv4 address (Section 4.5). In a BR Mapping rule or a NAT64+ Mapping rule, it MUST be a /80 prefix whose bits 64-79 are the 4rd Tag.
“规则IPv6前缀”是当第4条IPv6地址从第4条IPv4地址派生时用作规则IPv4前缀替代物的前缀（第4.5节）。在BR映射规则或NAT64+映射规则中，它必须是位64-79为第4位标记的/80前缀。
"WKPs authorized" may be set for Mapping rules that assign shared IPv4 addresses to CEs. (These rules are those whose length of the Rule IPv4 prefix plus the EA-bits length exceeds 32.) If set, well-known ports may be assigned to some CEs having particular IPv6 prefixes. If not set, fairness is privileged: all IPv6 prefixes concerned with the Mapping rule have port sets having identical values (no port set includes any of the well-known ports).
可以为将共享IPv4地址分配给CE的映射规则设置“WKPs授权”。（这些规则是指规则IPv4前缀加上EA位长度的长度超过32的规则。）如果设置，则可以将已知端口分配给具有特定IPv6前缀的某些CE。如果未设置公平性，则具有特权：与映射规则相关的所有IPv6前缀都具有具有相同值的端口集（没有任何端口集包括任何已知端口）。
"Domain PMTU" is the IPv6 Path MTU that the ISP can guarantee for all of its IPv6 paths between CEs and between BRs and CEs. It MUST be at least 1280 octets [RFC2460].
“域PMTU”是ISP可以为CEs之间以及BRs和CEs之间的所有IPv6路径保证的IPv6路径MTU。它必须至少为1280个八位字节[RFC2460]。
"Hub-and-spoke topology", if set to Yes, requires CEs to tunnel all IPv4 packets via BRs. If set to No, CE-to-CE packets take the same routes as native IPv6 packets between the same CEs (mesh topology).
如果设置为“是”，则“集线器和分支拓扑”要求CEs通过BRs对所有IPv4数据包进行隧道传输。如果设置为否，CE到CE数据包在相同CE（网状拓扑）之间采用与本机IPv6数据包相同的路由。
"Tunnel Traffic Class", if provided, is the IPv6 traffic class that BRs and CEs MUST set in Tunnel packets. In this case, evolutions of the IPv6 traffic class that may occur during Domain traversal are not reflected in TOS fields of IPv4 packets at Domain exit (Section 4.7).
“隧道流量类别”（如果提供）是BRs和CEs必须在隧道数据包中设置的IPv6流量类别。在这种情况下，域遍历期间可能发生的IPv6通信量类别的演变不会反映在域出口处IPv4数据包的TOS字段中（第4.7节）。
R-3: Domain-entry nodes that receive IPv4 packets with IPv4 options MUST discard these packets and return ICMPv4 error messages to signal IPv4-option incompatibility (Type = 12, Code = 0, Pointer = 20) [RFC792]. This limitation is acceptable because there are a lot of firewalls in the current IPv4 Internet that also filter IPv4 packets with IPv4 options.
R-3：接收具有IPv4选项的IPv4数据包的域入口节点必须丢弃这些数据包并返回ICMPv4错误消息，以表示IPv4选项不兼容（类型=12，代码=0，指针=20）[RFC792]。此限制是可以接受的，因为当前IPv4 Internet中有许多防火墙也使用IPv4选项过滤IPv4数据包。
R-4: Domain-entry nodes that receive IPv4 packets without IPv4 options MUST convert them to Tunnel packets, with or without IPv6 fragment headers, depending on what is needed to ensure IPv4 transparency (Figure 2). Domain-exit nodes MUST convert them back to IPv4 packets.
R-4：接收不带IPv4选项的IPv4数据包的域入口节点必须将其转换为隧道数据包（带或不带IPv6片段头），具体取决于确保IPv4透明性所需的内容（图2）。域出口节点必须将它们转换回IPv4数据包。
An IPv6 fragmentation header MUST be included at tunnel entry (Figure 2) if and only if one or several of the following conditions hold:
当且仅当以下一个或多个条件成立时，IPv6分段标头必须包含在隧道入口（图2）：
* The Tunnel Traffic Class option applies to the Domain.
* 隧道流量类别选项适用于域。
* TTL = 1 OR TTL = 255.
* TTL=1或TTL=255。
* The IPv4 packet is already fragmented, or may be fragmented later on, i.e., if MF = 1 OR offset > 0 OR (total length > 68 AND DF = 0).
* IPv4数据包已经被分段，或者稍后可能被分段，即，如果MF=1或偏移量>0或（总长度>68且DF=0）。
In order to optimize cases where fragmentation headers are unnecessary, the NAT44 of a CE that has one SHOULD send packets with TTL = 254.
为了优化不需要分段头的情况，具有分段头的CE的NAT44应发送TTL=254的数据包。
R-5: In Domains whose chosen topology is hub-and-spoke, BRs that receive 4rd IPv6 packets whose embedded destination IPv4 addresses match a CE Mapping rule MUST do the equivalent of reversibly translating their headers to IPv4 and then reversibly translate them back to IPv6 as though packets would be entering the Domain.
R-5：在所选拓扑为中心辐射的域中，接收第四个IPv6数据包（其嵌入的目标IPv4地址与CE映射规则匹配）的BR必须执行等效操作，将其头可逆地转换为IPv4，然后可逆地将其转换回IPv6，就好像数据包将进入域一样。
(A) Without IPv6 fragment header
IPv4 packet Tunnel packet
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : | IPv6 Header | 40
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+
(A) Without IPv6 fragment header
IPv4 packet Tunnel packet
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : | IPv6 Header | 40
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+
(B) With IPv6 fragment header
Tunnel packet
: +--------------------+
IPv4 packet : | IPv6 Header | 40
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : |IPv6 Fragment Header| 8
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+
(B) With IPv6 fragment header
Tunnel packet
: +--------------------+
IPv4 packet : | IPv6 Header | 40
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : |IPv6 Fragment Header| 8
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+
Figure 2: Reversible Packet Translation
图2：可逆数据包转换
R-6: Values to be set in IPv6 header fields at Domain entry are detailed in Table 1 (no fragment header) and Table 2 (with fragment header). Those to be set in IPv4 header fields at Domain exit are detailed in Table 3 (no fragment header) and Table 4 (with fragment header).
R-6：要在域入口的IPv6头字段中设置的值在表1（无片段头）和表2（带片段头）中有详细说明。表3（无片段头）和表4（带片段头）详细说明了在域出口的IPv4头字段中要设置的内容。
To convey IPv4 header information that has no equivalent in IPv6, some ad hoc fields are placed in IPv6 flow labels and in Identification fields of IPv6 fragment headers, as detailed in Figure 3.
为了传递在IPv6中没有等价物的IPv4报头信息，一些特殊字段被放置在IPv6流标签和IPv6片段报头的标识字段中，如图3所示。
|0 |4 19|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Addr_Prot_Cksm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Flow Label
|0 |4 19|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Addr_Prot_Cksm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Flow Label
0 1 2 |8 |16 31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|.|.|.| 0 | IPv4_TOS | IPv4_ID |
/-+-\-\-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \ TTL_255 IPv6 Identification Field
IPv4_DF TTL_1 (in fragment header if needed)
0 1 2 |8 |16 31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|.|.|.| 0 | IPv4_TOS | IPv4_ID |
/-+-\-\-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \ TTL_255 IPv6 Identification Field
IPv4_DF TTL_1 (in fragment header if needed)
Figure 3: 4rd Identification Fields of IPv6 Fragment Headers
图3:IPv6片段头的第4个标识字段
+---------------------+----------------------------------------+
| IPv6 Field | Value (fields from IPv4 header) |
+---------------------+----------------------------------------+
| Version | 6 |
| Traffic Class | TOS |
| Addr_Prot_Cksm | Sum of addresses and Protocol (Note 1) |
| Payload length | Total length - 20 |
| Next header | Protocol |
| Hop limit | Time to Live |
| Source address | See Section 4.5 |
| Destination address | See Section 4.5 |
+---------------------+----------------------------------------+
+---------------------+----------------------------------------+
| IPv6 Field | Value (fields from IPv4 header) |
+---------------------+----------------------------------------+
| Version | 6 |
| Traffic Class | TOS |
| Addr_Prot_Cksm | Sum of addresses and Protocol (Note 1) |
| Payload length | Total length - 20 |
| Next header | Protocol |
| Hop limit | Time to Live |
| Source address | See Section 4.5 |
| Destination address | See Section 4.5 |
+---------------------+----------------------------------------+
Table 1: IPv4-to-IPv6 Reversible Header Translation (without Fragment Header)
表1:IPv4到IPv6可逆头转换（无片段头）
+-----------------+----------------------------------------------+
| IPv6 Field | Value (fields from IPv4 header) |
+-----------------+----------------------------------------------+
| Version | 6 |
| Traffic Class | TOS OR Tunnel Traffic Class (Section 4.7) |
| Addr_Prot_Cksm | Sum of addresses and Protocol (Note 1) |
| Payload length | Total length - 12 |
| Next header | 44 (fragment header) |
| Hop limit | IF Time to Live = 1 or 255 THEN 254 |
| | ELSE Time to Live (Note 2) |
| Source address | See Section 4.5 |
| Dest. address | See Section 4.5 |
| 2nd next header | Protocol |
| Fragment offset | IPv4 fragment offset |
| M | More Fragments flag (MF) |
| IPv4_DF | Don't Fragment flag (DF) |
| TTL_1 | IF Time to Live = 1 THEN 1 ELSE 0 (Note 2) |
| TTL_255 | IF Time to Live = 255 THEN 1 ELSE 0 (Note 2) |
| IPv4_TOS | Type of Service (TOS) |
| IPv4_ID | Identification |
+-----------------+----------------------------------------------+
+-----------------+----------------------------------------------+
| IPv6 Field | Value (fields from IPv4 header) |
+-----------------+----------------------------------------------+
| Version | 6 |
| Traffic Class | TOS OR Tunnel Traffic Class (Section 4.7) |
| Addr_Prot_Cksm | Sum of addresses and Protocol (Note 1) |
| Payload length | Total length - 12 |
| Next header | 44 (fragment header) |
| Hop limit | IF Time to Live = 1 or 255 THEN 254 |
| | ELSE Time to Live (Note 2) |
| Source address | See Section 4.5 |
| Dest. address | See Section 4.5 |
| 2nd next header | Protocol |
| Fragment offset | IPv4 fragment offset |
| M | More Fragments flag (MF) |
| IPv4_DF | Don't Fragment flag (DF) |
| TTL_1 | IF Time to Live = 1 THEN 1 ELSE 0 (Note 2) |
| TTL_255 | IF Time to Live = 255 THEN 1 ELSE 0 (Note 2) |
| IPv4_TOS | Type of Service (TOS) |
| IPv4_ID | Identification |
+-----------------+----------------------------------------------+
Table 2: IPv4-to-IPv6 Reversible Header Translation (with Fragment Header)
表2:IPv4到IPv6可逆头转换（带片段头）
+-----------------+------------------------------------+
| IPv4 Field | Value (fields from IPv6 header) |
+-----------------+------------------------------------+
| Version | 4 |
| Header length | 5 |
| TOS | Traffic Class |
| Total length | Payload length + 20 |
| Identification | 0 |
| DF | 1 |
| MF | 0 |
| Fragment offset | 0 |
| Time to Live | Hop count |
| Protocol | Next header |
| Header checksum | Computed as per [RFC791] (Note 3) |
| Source address | Bits 80-111 of source address |
| Dest. address | Bits 80-111 of destination address |
+-----------------+------------------------------------+
+-----------------+------------------------------------+
| IPv4 Field | Value (fields from IPv6 header) |
+-----------------+------------------------------------+
| Version | 4 |
| Header length | 5 |
| TOS | Traffic Class |
| Total length | Payload length + 20 |
| Identification | 0 |
| DF | 1 |
| MF | 0 |
| Fragment offset | 0 |
| Time to Live | Hop count |
| Protocol | Next header |
| Header checksum | Computed as per [RFC791] (Note 3) |
| Source address | Bits 80-111 of source address |
| Dest. address | Bits 80-111 of destination address |
+-----------------+------------------------------------+
Table 3: IPv6-to-IPv4 Reversible Header Translation (without Fragment Header)
表3:IPv6到IPv4可逆头转换（无片段头）
+-----------------------+-----------------------------------------+
| IPv4 Field | Value (fields from IPv6 header) |
+-----------------------+-----------------------------------------+
| Version | 4 |
| Header length | 5 |
| TOS | Traffic Class OR IPv4_TOS (Section 4.7) |
| Total length | Payload length + 12 |
| Identification | IPv4_ID |
| DF | IPv4_DF |
| MF | M |
| Fragment offset | Fragment offset |
| Time to Live (Note 2) | IF TTL_255 = 1 THEN 255 |
| | ELSEIF TTL_1 = 1 THEN 1 |
| | ELSE hop count |
| Protocol | 2nd next header |
| Header checksum | Computed as per [RFC791] (Note 3) |
| Source address | Bits 80-111 of source address |
| Destination address | Bits 80-111 of destination address |
+-----------------------+-----------------------------------------+
+-----------------------+-----------------------------------------+
| IPv4 Field | Value (fields from IPv6 header) |
+-----------------------+-----------------------------------------+
| Version | 4 |
| Header length | 5 |
| TOS | Traffic Class OR IPv4_TOS (Section 4.7) |
| Total length | Payload length + 12 |
| Identification | IPv4_ID |
| DF | IPv4_DF |
| MF | M |
| Fragment offset | Fragment offset |
| Time to Live (Note 2) | IF TTL_255 = 1 THEN 255 |
| | ELSEIF TTL_1 = 1 THEN 1 |
| | ELSE hop count |
| Protocol | 2nd next header |
| Header checksum | Computed as per [RFC791] (Note 3) |
| Source address | Bits 80-111 of source address |
| Destination address | Bits 80-111 of destination address |
+-----------------------+-----------------------------------------+
Table 4: IPv6-to-IPv4 Reversible Header Translation (with Fragment Header)
表4:IPv6到IPv4可逆头转换（带片段头）
NOTE 1: The need to save in the IPv6 header a checksum of both IPv4 addresses and the IPv4 protocol field results from the following facts: (1) header checksums, present in IPv4 but not in IPv6, protect addresses or protocol integrity; (2) in IPv4, ICMP messages and null-checksum UDP datagrams depend on this protection because, unlike other datagrams, they have no other address-and-protocol integrity protection. The sum MUST be performed in ordinary two's complement arithmetic.
注1：需要在IPv6报头中保存IPv4地址和IPv4协议字段的校验和，这是由于以下事实造成的：（1）报头校验和，存在于IPv4中，但不存在于IPv6中，用于保护地址或协议完整性；（2） 在IPv4中，ICMP消息和空校验和UDP数据报依赖于此保护，因为与其他数据报不同，它们没有其他地址和协议完整性保护。求和必须用普通二的补码运算。
IP-layer Packet length is another field covered by the IPv4 header checksum. It is not included in the saved checksum because (1) doing so would have conflicted with [RFC6437] (flow labels must be the same in all packets of each flow); (2) ICMPv4 messages have good enough protection with their own checksums; (3) the UDP length field provides to null-checksum UDP datagrams the same level of protection after Domain traversal as without Domain traversal (consistency between IP-layer and UDP-layer lengths can be checked).
IP层数据包长度是IPv4报头校验和覆盖的另一个字段。它不包括在保存的校验和中，因为（1）这样做会与[RFC6437]冲突（每个流的所有数据包中的流标签必须相同）；（2） ICMPv4消息具有足够好的保护，具有自己的校验和；（3） UDP长度字段在域遍历后为空校验和UDP数据报提供与不进行域遍历时相同的保护级别（可以检查IP层和UDP层长度之间的一致性）。
NOTE 2: TTL treatment has been chosen to permit adjacency tests between two IPv4 nodes situated at both ends of a 4rd tunnel. TTL values to be preserved for this are TTL = 255 and TTL = 1. For other values, TTL decreases between two IPv4 nodes as though the traversed IPv6 routers were IPv4 routers.
注2：选择TTL处理是为了允许位于第四隧道两端的两个IPv4节点之间进行邻接测试。为此保留的TTL值为TTL=255和TTL=1。对于其他值，两个IPv4节点之间的TTL减小，就好像经过的IPv6路由器是IPv4路由器一样。
The effect of this TTL treatment on IPv4 traceroute is specific: (1) the number of routers of the end-to-end path includes traversed IPv6 routers; (2) IPv6 routers of a Domain are listed after IPv4 routers of Domain entry and exit; (3) the IPv4 address shown for an IPv6 router is the IPv6-only dummy IPv4 address (Section 4.8); (4) the response time indicated for an IPv6 router is that of the next router.
这种TTL处理对IPv4跟踪路由的影响是具体的：（1）端到端路径的路由器数量包括经过的IPv6路由器；（2） 域的IPv6路由器列在域入口和出口的IPv4路由器之后；（3） 为IPv6路由器显示的IPv4地址是唯一的IPv6虚拟IPv4地址（第4.8节）；（4） 为IPv6路由器指示的响应时间是下一个路由器的响应时间。
NOTE 3: Provided the sum of obtained IPv4 addresses and protocol matches Addr_Prot_Cksm. If not, the packet MUST be silently discarded.
注3：如果获得的IPv4地址和协议的总和与Addr_Prot_Cksm匹配。如果不是，则必须以静默方式丢弃数据包。
+--------------------------------------+
| CE IPv6 prefix |
+--------------------------+-----------+
: Longest match : :
: with a Rule IPv6 prefix : :
: || : EA-bits :
: \/ : length :
+--------------------------+ | :
| Rule IPv6 prefix |<----'---->:
+--------------------------+ :
|| : :
\/ : :
+-----------------+-----------+
|Rule IPv4 prefix | EA bits |
+-----------------+-----------+
: :
+-----------------------------+
| CE 4rd IPv4 prefix |
+-----------------------------+
________/ \_________ :
/ \ :
: ____:________________/ \__
: / : \
: <= 32 : : > 32 :
+----------------+ +-----------------+----+
|IPv4 prfx or add| OR | IPv4 address |PSID|
+----------------+ +-----------------+----+
: 32 : || :
\/
(by default) (If WKPs authorized)
: : : :
+---+----+---------+ +----+-------------+
Ports in |> 0|PSID|any value| OR |PSID| any value |
the CE port set +---+----+---------+ +----+-------------+
: 4 : 12 : : 16 :
+--------------------------------------+
| CE IPv6 prefix |
+--------------------------+-----------+
: Longest match : :
: with a Rule IPv6 prefix : :
: || : EA-bits :
: \/ : length :
+--------------------------+ | :
| Rule IPv6 prefix |<----'---->:
+--------------------------+ :
|| : :
\/ : :
+-----------------+-----------+
|Rule IPv4 prefix | EA bits |
+-----------------+-----------+
: :
+-----------------------------+
| CE 4rd IPv4 prefix |
+-----------------------------+
________/ \_________ :
/ \ :
: ____:________________/ \__
: / : \
: <= 32 : : > 32 :
+----------------+ +-----------------+----+
|IPv4 prfx or add| OR | IPv4 address |PSID|
+----------------+ +-----------------+----+
: 32 : || :
\/
(by default) (If WKPs authorized)
: : : :
+---+----+---------+ +----+-------------+
Ports in |> 0|PSID|any value| OR |PSID| any value |
the CE port set +---+----+---------+ +----+-------------+
: 4 : 12 : : 16 :
Figure 4: From CE IPv6 Prefix to 4rd IPv4 Address and Port Set
图4：从CE IPv6前缀到第4个IPv4地址和端口集
R-7: A CE whose delegated IPv6 prefix matches the Rule IPv6 prefix of one or several Mapping rules MUST select the CE Mapping rule for which the match is the longest. It then derives its 4rd IPv4 prefix as shown in Figure 4: (1) The CE replaces the Rule IPv6 prefix with the Rule IPv4 prefix. The result is the CE 4rd IPv4 prefix. (2) If this CE 4rd IPv4 prefix has less than 32 bits, the CE takes it as its assigned IPv4 prefix. If it has exactly 32 bits, the CE takes it as its IPv4 address. If
R-7:其委派IPv6前缀与一个或多个映射规则的规则IPv6前缀匹配的CE必须选择匹配最长的CE映射规则。然后，它派生其第4个IPv4前缀，如图4所示：（1）CE将规则IPv6前缀替换为规则IPv4前缀。结果是CE4rdIPv4前缀。（2） 如果此CE 4rd IPv4前缀少于32位，则CE将其作为其分配的IPv4前缀。如果它正好有32位，则CE将其作为其IPv4地址。如果
it has more than 32 bits, the CE MUST take the first 32 bits as its shared public IPv4 address and bits beyond the first 32 as its Port-Set identifier (PSID). Ports of its restricted port set are by default those that have any non-zero value in their first 4 bits (the PSID offset), followed by the PSID, and followed by any values in remaining bits. If the WKP authorized option applies to the Mapping rule, there is no 4-bit offset before the PSID so that all ports can be assigned.
它有超过32位，CE必须将前32位作为其共享公共IPv4地址，并将前32位以外的位作为其端口集标识符（PSID）。默认情况下，其受限端口集的端口是在其前4位（PSID偏移量）中具有任何非零值的端口，后跟PSID，后跟剩余位中的任何值。如果WKP授权选项适用于映射规则，则PSID之前没有4位偏移，因此可以分配所有端口。
NOTE: The choice of the default PSID position in port fields has been guided by the following objectives: (1) for fairness, avoid having any of the well-known ports 0-1023 in the port set specified by any PSID value; (2) for compatibility with RTP/ RTCP [RFC4961], include in each port set pairs of consecutive ports; (3) in order to facilitate operation and training, have the PSID at a fixed position in port fields; (4) in order to facilitate documentation in hexadecimal notation, and to facilitate maintenance, have this position nibble-aligned. Ports that are excluded from assignment to CEs are 0-4095, instead of just 0-1023, in a trade-off to favor nibble alignment of PSIDs and overall simplicity.
注意：端口字段中默认PSID位置的选择遵循以下目标：（1）为了公平起见，避免任何PSID值指定端口集中的任何已知端口0-1023；（2） 为了与RTP/RTCP[RFC4961]兼容，在每个端口集中包括一对连续端口；（3） 为了便于操作和培训，将PSID放置在港口区域的固定位置；（4） 为了便于以十六进制表示法编制文档，并便于维护，请对齐此位置的半字节。被排除在CEs分配之外的端口是0-4095，而不是0-1023，这是一种折衷，有利于PSID的半字节对齐和整体简单性。
R-8: A CE whose delegated IPv6 prefix has its longest match with the Rule IPv6 prefix of the BR Mapping rule MUST take as its IPv4 address the 32 bits that, in the delegated IPv6 prefix, follow this Rule IPv6 prefix. If this is the case while the hub-and-spoke option applies to the Domain, or if the Rule IPv6 prefix is not a /80, there is a configuration error in the Domain. An implementation-dependent administrative action MAY be taken.
R-8:其委派IPv6前缀与BR映射规则的规则IPv6前缀最长匹配的CE必须将委派IPv6前缀中遵循此规则IPv6前缀的32位作为其IPv4地址。如果集线器和分支选项应用于域时出现这种情况，或者如果规则IPv6前缀不是a/80，则域中存在配置错误。可以采取依赖于实施的行政行动。
A CE whose delegated IPv6 prefix does not match the Rule IPv6 prefix of either any CE Mapping rule or the BR Mapping rule, and is in a Domain that has a NAT64+ Mapping rule, MUST be noted as having the unspecified IPv4 address.
如果CE的委派IPv6前缀与任何CE映射规则或BR映射规则的规则IPv6前缀不匹配，并且位于具有NAT64+映射规则的域中，则必须将其标记为具有未指定的IPv4地址。
: 32 : : 16 : \
+----------------------------+ +---------------+ |
| IPv4 address | |Port_or_ICMP_ID| | Shared-address
+----------------------------+ +---+------+----+ | case
: Longest match : : 4 : PSID : | (PSID length
: with a Rule IPv4 prefix : :length: | of the rule > 0)
: || : : : | with WKPs
: \/ : : : | not authorized
+----------------+-----------+ +------+ | (PSID offset = 4)
|Rule IPv4 prefix|IPv4 suffix| | PSID | |
+----------------+-----------+ +------+ |
: || \_______ \____ | | |
: \/ \ \| / |
+--------------------------+--------+-----+ /
| Rule IPv6 prefix | EA bits |
+--------------------------+--------------+
: :
+-----------------------------------------+
| IPv6 prefix |
+-----------------------------------------+
:\_______________________________ / \
: ___________________\______/ \_______________
: / \ \
: / (CE Mapping rule) \ (BR Mapping rule) \
: <= 64 : : 112 :
+----------+---+---+------+---+ +--------------+---+------+---+
|CE v6 prfx| 0 |tag|v4 add|CNP| |BR IPv6 prefix|tag|v4 add|CNP|
+----------+-|-+---+------+---+ +--------------+---+------+---+
: <= 64 : | :16 : 32 :16 : : 64 :16 : 32 :16 :
|
Padding to /64
: 32 : : 16 : \
+----------------------------+ +---------------+ |
| IPv4 address | |Port_or_ICMP_ID| | Shared-address
+----------------------------+ +---+------+----+ | case
: Longest match : : 4 : PSID : | (PSID length
: with a Rule IPv4 prefix : :length: | of the rule > 0)
: || : : : | with WKPs
: \/ : : : | not authorized
+----------------+-----------+ +------+ | (PSID offset = 4)
|Rule IPv4 prefix|IPv4 suffix| | PSID | |
+----------------+-----------+ +------+ |
: || \_______ \____ | | |
: \/ \ \| / |
+--------------------------+--------+-----+ /
| Rule IPv6 prefix | EA bits |
+--------------------------+--------------+
: :
+-----------------------------------------+
| IPv6 prefix |
+-----------------------------------------+
:\_______________________________ / \
: ___________________\______/ \_______________
: / \ \
: / (CE Mapping rule) \ (BR Mapping rule) \
: <= 64 : : 112 :
+----------+---+---+------+---+ +--------------+---+------+---+
|CE v6 prfx| 0 |tag|v4 add|CNP| |BR IPv6 prefix|tag|v4 add|CNP|
+----------+-|-+---+------+---+ +--------------+---+------+---+
: <= 64 : | :16 : 32 :16 : : 64 :16 : 32 :16 :
|
Padding to /64
Figure 5: From 4rd IPv4 Address to 4rd IPv6 Address
图5：从第4个IPv4地址到第4个IPv6地址
R-9: BRs, and CEs that are assigned public IPv4 addresses, shared or not, MUST derive 4rd IPv6 addresses from 4rd IPv4 addresses via the steps below or their functional equivalent (Figure 5 details the shared public IPv4 address case):
R-9：被分配公共IPv4地址（共享或非共享）的BRs和CE必须通过以下步骤或其等效功能从第4个IPv4地址派生第4个IPv6地址（图5详细说明了共享公共IPv4地址的情况）：
NOTE: The rules for forming 4rd-specific Interface Identifiers (IIDs) are to obey [RFC7136]:
注：形成第四个特定接口标识符（IID）的规则应遵守[RFC7136]：
"Specifications of other forms of 64-bit IIDs MUST specify how all 64 bits are set."
“其他形式的64位IID的规范必须指定如何设置所有64位。”
and
和
"the whole IID value MUST be viewed as an opaque bit string by third parties, except possibly in the local context."
第三方必须将整个IID值视为不透明的位字符串，本地上下文除外
(1) If hub-and-spoke topology does not apply to the Domain, or if it applies but the IPv6 address to be derived is a source address from a CE or a destination address from a BR, find the CE Mapping rule whose Rule IPv4 prefix has the longest match with the IPv4 address.
(1) 如果集线器和分支拓扑不适用于域，或者如果它适用但要派生的IPv6地址是来自CE的源地址或来自BR的目标地址，请查找其规则IPv4前缀与IPv4地址最长匹配的CE映射规则。
If no Mapping rule is thus obtained, take the BR Mapping rule.
如果没有因此获得映射规则，则采用BR映射规则。
If the obtained Mapping rule assigns IPv4 prefixes to CEs, i.e., if the length of the Rule IPv4 prefix plus EA-bits length is 32 - k, with k >= 0, delete the last k bits of the IPv4 address.
如果获得的映射规则将IPv4前缀分配给CE，即，如果规则IPv4前缀的长度加上EA位长度为32-k，且k>=0，则删除IPv4地址的最后k位。
Otherwise, if the length of the Rule IPv4 prefix plus the EA-bits length is 32 + k, with k > 0, take k as the PSID length and append to the IPv4 address the PSID copied from bits p to p+3 of the Port_or_ICMP_ID field where (1) p, the PSID offset, is 4 by default and 0 if the WKPs authorized option applies to the rule; (2) the Port_or_ICMP_ID field is in bits of the IP payload that depend on whether the address is source or destination, on whether the packet is ICMP or not, and, if it is ICMP, whether it is an error message or an Echo message. This field is:
否则，如果规则IPv4前缀的长度加上EA位长度为32+k，且k>0，则将k作为PSID长度，并将从端口或ICMP ID字段的p位复制到p+3的PSID附加到IPv4地址，其中（1）p（PSID偏移量）默认为4，如果WKPs授权选项适用于规则，则为0；（2） Port_或_ICMP_ID字段以IP有效负载的位为单位，这取决于地址是源还是目标，取决于数据包是否为ICMP，如果是ICMP，则取决于它是错误消息还是回显消息。该字段为：
a. If the packet Protocol is not ICMP, the port field associated with the address (bits 0-15 for a source address and bits 16-31 for a destination address).
a. 如果数据包协议不是ICMP，则为与地址相关联的端口字段（源地址为0-15位，目的地址为16-31位）。
b. If the packet is an ICMPv4 Echo or Echo reply message, the ICMPv4 Identification field (bits 32-47).
b. 如果数据包是ICMPv4回显或回显回复消息，则ICMPv4标识字段（位32-47）。
c. If the packet is an ICMPv4 error message, the port field associated with the address in the returned packet header (bits 240-255 for a source address and bits 224-239 for a destination address).
c. 如果数据包是ICMPv4错误消息，则与返回的数据包头中的地址相关联的端口字段（源地址为240-255位，目的地址为224-239位）。
NOTE 1: Using Identification fields of ICMP messages as port fields permits the exchange of Echo requests and Echo replies between shared-address CEs and IPv4 hosts having exclusive IPv4 addresses. Echo exchanges between two shared-address CEs remain impossible, but this is a limitation inherent in address sharing (one reason among many to use IPv6).
注1：使用ICMP消息的标识字段作为端口字段允许在共享地址CE和具有专用IPv4地址的IPv4主机之间交换回显请求和回显回复。两个共享地址CE之间的回显交换仍然是不可能的，但这是地址共享固有的一个限制（使用IPv6的众多原因之一）。
NOTE 2: When the PSID is taken in the port fields of the IPv4 payload, implementation is kept independent from any particular Layer 4 protocol having such port fields by not checking that the protocol is indeed one that has such port fields. A packet may consequently go, in the case of a source mistake, from a BR to a shared-address CE with a protocol that is not supported by this CE. In this case, the CE NAT44 returns an ICMPv4 "protocol unreachable" error message. The IPv4 source is thus appropriately informed of its mistake.
注2：当在IPv4有效负载的端口字段中获取PSID时，通过不检查协议是否确实具有此类端口字段，实现独立于具有此类端口字段的任何特定第4层协议。因此，在源错误的情况下，数据包可能以该CE不支持的协议从BR转到共享地址CE。在这种情况下，CE NAT44返回ICMPv4“协议不可访问”错误消息。因此，IPv4源会被适当地告知其错误。
(2) In the result, replace the Rule IPv4 prefix with the Rule IPv6 prefix.
(2) 在结果中，将规则IPv4前缀替换为规则IPv6前缀。
(3) If the result is shorter than a /64, append to the result a null padding up to 64 bits, followed by the 4rd Tag (0x0300), and followed by the IPv4 address.
(3) 如果结果短于a/64，则在结果后面附加一个高达64位的空填充，后跟第4个标记（0x0300），后跟IPv4地址。
NOTE: The 4rd Tag is a 4rd-specific mark. Its function is to ensure that 4rd IPv6 addresses are recognizable by CEs without any interference with the choice of subnet prefixes in CE sites. (These choices may have been done before 4rd is enabled.)
注：第4个标签是第4个特定标记。其功能是确保CEs能够识别第4个IPv6地址，而不会干扰CE站点中子网前缀的选择。（这些选择可能在启用4rd之前完成。）
For this, the 4rd Tag has its "u" and "g" bits [RFC4291] both set to 1, so that they maximally differ from these existing IPv6 address schemas. So far, u = g = 1 has not been used in any IPv6 addressing architecture.
为此，第4个标记的“u”和“g”位[RFC4291]都设置为1，因此它们与这些现有IPv6地址模式最大程度不同。到目前为止，u=g=1还没有在任何IPv6寻址体系结构中使用。
With the 4rd Tag, IPv6 packets can be routed to the 4rd function within a CE node based on a /80 prefix that no native IPv6 address can contain.
使用4rd标记，IPv6数据包可以基于本机IPv6地址不能包含的/80前缀路由到CE节点内的4rd功能。
(4) Add to the result a Checksum Neutrality Preserver (CNP). Its value, in one's complement arithmetic, is the opposite of the sum of 16-bit fields of the IPv6 address other than the IPv4 address and the CNP themselves (i.e., five consecutive fields in address bits 0-79).
(4) 向结果中添加一个校验和中立性保持器（CNP）。在补码算法中，其值与IPv6地址（IPv4地址和CNP本身除外）的16位字段之和（即地址位0-79中的五个连续字段）相反。
NOTE: The CNP guarantees that Tunnel packets are valid IPv6 packets for all Layer 4 protocols that use the same checksum algorithm as TCP. This guarantee does not depend on where the checksum fields of these protocols are placed in IP payloads. (Today, such protocols are UDP [RFC768], TCP [RFC793], UDP-Lite [RFC3828], and the Datagram Congestion Control Protocol (DCCP) [RFC5595]. Should new ones be specified, BRs will support them without needing an update.)
注意：CNP保证隧道数据包对于使用与TCP相同校验和算法的所有第4层协议都是有效的IPv6数据包。这种保证不依赖于这些协议的校验和字段在IP有效负载中的位置。（目前，此类协议有UDP[RFC768]、TCP[RFC793]、UDP Lite[RFC3828]和数据报拥塞控制协议（DCCP）[RFC5595]。如果指定了新的协议，BRs将支持它们，而无需更新。）
R-10: A 4rd-capable CE SHOULD, and a 4rd-enabled CE MUST, always prohibit all addresses that use its advertised prefix and have an IID starting with 0x0300 (4rd Tag), by using Duplicate Address Detection [RFC4862].
R-10：通过使用重复地址检测[RFC4862]，支持第4条的CE应该，且支持第4条的CE必须始终禁止所有使用其播发前缀且IID以0x0300（第4条标记）开头的地址。
R-11: A CE that is assigned the unspecified IPv4 address (see Section 4.4) MUST use, for packets tunneled between itself and the Domain NAT64+, addresses as detailed in Figure 6: part (a) for its IPv6 source, and part (b) as IPv6 destinations that depend on IPv4 destinations. A NAT64+, being NAT64 conforming [RFC6146], MUST accept IPv6 packets whose destination conforms to Figure 6(b) (4rd Tag instead of "u" and 0x00 octets). In its Binding Information Base, it MUST remember whether a mapping was created with a "u" or 4rd-tag destination. In the IPv4-to-IPv6 direction, it MUST use 4rd tunneling, with source address conforming to Figure 6(b), when using a mapping that was created with a 4rd-tag destination.
R-11：分配了未指定IPv4地址（参见第4.4节）的CE必须使用图6（A）部分中详细说明的地址作为其IPv6源，以及（b）部分作为依赖于IPv4目的地的IPv6目的地，用于在其自身和域NAT64+之间隧道传输的数据包。NAT64+，即符合NAT64的[RFC6146]，必须接受其目的地符合图6（b）的IPv6数据包（第4个标签，而不是“u”和0x00八位字节）。在其绑定信息库中，它必须记住映射是使用“u”还是第4个标记目标创建的。在IPv4到IPv6的方向上，当使用由第4个标记目标创建的映射时，它必须使用第4个隧道，源地址符合图6（b）。
+---------------------+---------+-------+-------------+------+
(a) | CE IPv6 prefix | 0 |4rd Tag| 0 | CNP |
+---------------------+---------+-------+-------------+------+
: <= 64 : >= 0 : 16 : 32 : 16 :
4rd IPv6 address of a CE having no public IPv4 address
+---------------------+---------+-------+-------------+------+
(a) | CE IPv6 prefix | 0 |4rd Tag| 0 | CNP |
+---------------------+---------+-------+-------------+------+
: <= 64 : >= 0 : 16 : 32 : 16 :
4rd IPv6 address of a CE having no public IPv4 address
<----------- Rule IPv6 prefix --------->:
+-------------------------------+-------+-------------+------+
(b) | NAT64+ IPv6 prefix |4rd Tag|IPv4 address | CNP |
+-------------------------------+-------+-------------+------+
: 64 : 16 : 32 : 16 :
4rd IPv6 address of a host reachable via a NAT64+
<----------- Rule IPv6 prefix --------->:
+-------------------------------+-------+-------------+------+
(b) | NAT64+ IPv6 prefix |4rd Tag|IPv4 address | CNP |
+-------------------------------+-------+-------------+------+
: 64 : 16 : 32 : 16 :
4rd IPv6 address of a host reachable via a NAT64+
Figure 6: Rules for CE and NAT64+
图6:CE和NAT64的规则+
R-12: For anti-spoofing protection, CEs and BRs MUST check that the IPv6 source address of each received Tunnel packet is that which, according to R-9, is derived from the source 4rd IPv4 address. For this, the IPv4 address used to obtain the source 4rd IPv4 address is that embedded in the IPv6 source address (in its bits 80-111). (This verification is needed because IPv6 ingress filtering [RFC3704] applies only to IPv6 prefixes, without any guarantee that Tunnel packets are built as specified in R-9.)
R-12：对于反欺骗保护，CEs和BRs必须检查每个接收到的隧道数据包的IPv6源地址是否是根据R-9从源第4条IPv4地址派生的地址。为此，用于获取源第4个IPv4地址的IPv4地址是嵌入在IPv6源地址中的地址（在其位80-111中）。（需要进行此验证，因为IPv6入口过滤[RFC3704]仅适用于IPv6前缀，不保证按照R-9中的规定构建隧道数据包。）
R-13: For additional protection against packet corruption at a link layer that might be undetected at this layer during Domain traversal, CEs and BRs SHOULD verify that source and destination IPv6 addresses have not been modified. This can be done by checking that they remain checksum neutral (see the Note above regarding the CNP).
R-13：为了防止链路层的数据包损坏（在域遍历过程中可能在此层未被检测到），CEs和BRs应验证源和目标IPv6地址是否未被修改。这可以通过检查它们是否保持校验和中性来实现（参见上面关于CNP的注释）。
R-14: If an IPv4 packet enters a CE or BR with a size such that the derived Tunnel packet would be longer than the Domain PMTU, the packet has to be either discarded or fragmented. The Domain-entry node MUST discard it if the packet has DF = 1, with an ICMP error message returned to the source. It MUST fragment it otherwise, with the payload of each fragment not exceeding PMTU - 48. The first fragment has its offset equal to the received offset. Subsequent fragments have offsets increased by the lengths of the payloads of previous fragments. Functionally, fragmentation is supposed to be done in IPv4 before applying reversible header translation to each fragment; see Section 4.3.
R-14：如果IPv4数据包进入CE或BR，其大小使得派生的隧道数据包比域PMTU长，则该数据包必须被丢弃或分段。如果数据包的DF=1，域入口节点必须丢弃它，并将ICMP错误消息返回到源。否则，它必须对其进行碎片分割，每个碎片的有效载荷不超过PMTU-48。第一个片段的偏移量等于接收到的偏移量。后续碎片的偏移量随着先前碎片有效载荷的长度而增加。从功能上讲，在对每个片段应用可逆头转换之前，应该在IPv4中完成分段；见第4.3节。
Because ports are available only in the first fragments of IPv4 fragmented packets, a BR needs a mechanism to send to the right shared-address CEs all fragments of fragmented packets.
由于端口仅在IPv4碎片数据包的第一个片段中可用，BR需要一种机制将碎片数据包的所有片段发送到正确的共享地址。
For this, a BR MAY systematically reassemble fragmented IPv4 packets before tunneling them. But this consumes large memory space, creates opportunities for denial-of-service-attacks, and can significantly increase forwarding delays. This is the reason for the following requirement:
为此，BR可以在隧道传输之前系统地重新组装分段的IPv4数据包。但这会消耗大量内存空间，造成拒绝服务攻击的机会，并会显著增加转发延迟。这就是以下要求的原因：
R-15: BRs SHOULD support an algorithm whereby received IPv4 packets can be forwarded on the fly. The following is an example of such an algorithm:
R-15:BRs应该支持一种算法，通过该算法可以动态转发接收到的IPv4数据包。以下是此类算法的示例：
(1) At BR initialization, if at least one CE Mapping rule deals with one or more shared public IPv4 addresses (i.e., length of Rule IPv4 prefix + EA-bits length > 32), the BR initializes an empty "IPv4 packet table" whose entries have the following items:
(1) 在BR初始化时，如果至少有一个CE映射规则处理一个或多个共享公共IPv4地址（即，规则IPv4前缀的长度+EA位长度>32），BR初始化一个空的“IPv4数据包表”，其条目包含以下项：
- IPv4 source
- IPv4源
- IPv4 destination
- IPv4目的地
- IPv4 identification
- IPv4标识
- Destination port
- 目的港
(2) When the BR receives an IPv4 packet whose matching Mapping rule deals with one or more shared public IPv4 addresses (i.e., length of Rule IPv4 prefix + EA-bits length > 32), the BR searches the table for an entry whose IPv4 source, IPv4 destination, and IPv4 identification are those of the received packet. The BR then performs actions as detailed in Table 5, depending on which conditions hold.
(2) 当BR接收到其匹配映射规则处理一个或多个共享公共IPv4地址的IPv4数据包（即，规则IPv4前缀的长度+EA位长度>32）时，BR在表中搜索IPv4源、IPv4目标和IPv4标识与接收数据包相同的条目。BR然后执行表5中详细说明的操作，具体取决于条件。
+-----------------------------+---+---+---+---+---+---+---+---+
| - CONDITIONS - | | | | | | | | |
| First Fragment (offset = 0) | Y | Y | Y | Y | N | N | N | N |
| Last fragment (MF = 0) | Y | Y | N | N | Y | Y | N | N |
| An entry has been found | Y | N | Y | N | Y | N | Y | N |
| ------------------------- | | | | | | | | |
| - RESULTING ACTIONS - | | | | | | | | |
| Create a new entry | - | - | - | X | - | - | - | - |
| Use port of the entry | - | - | - | - | X | - | X | - |
| Update port of the entry | - | - | X | - | - | - | - | - |
| Delete the entry | X | - | - | - | X | - | - | - |
| Forward the packet | X | X | X | X | X | - | X | - |
+-----------------------------+---+---+---+---+---+---+---+---+
+-----------------------------+---+---+---+---+---+---+---+---+
| - CONDITIONS - | | | | | | | | |
| First Fragment (offset = 0) | Y | Y | Y | Y | N | N | N | N |
| Last fragment (MF = 0) | Y | Y | N | N | Y | Y | N | N |
| An entry has been found | Y | N | Y | N | Y | N | Y | N |
| ------------------------- | | | | | | | | |
| - RESULTING ACTIONS - | | | | | | | | |
| Create a new entry | - | - | - | X | - | - | - | - |
| Use port of the entry | - | - | - | - | X | - | X | - |
| Update port of the entry | - | - | X | - | - | - | - | - |
| Delete the entry | X | - | - | - | X | - | - | - |
| Forward the packet | X | X | X | X | X | - | X | - |
+-----------------------------+---+---+---+---+---+---+---+---+
Table 5: BR Actions
表5:BR行动
(3) The BR performs garbage collection for table entries that remain unchanged for longer than some limit. This limit, which is normally longer than the maximum time normally needed to reassemble a packet, is not critical. It should not, however, be longer than 15 seconds [RFC791].
(3) BR对超过某个限制时间内保持不变的表项执行垃圾收集。该限制通常比重新组装数据包所需的最大时间长，并不重要。但是，它不应超过15秒[RFC791]。
R-16: For the above algorithm to be effective, CEs that are assigned shared public IPv4 addresses MUST NOT interleave fragments of several fragmented packets.
R-16：为了使上述算法有效，分配了共享公共IPv4地址的CE不能交织多个碎片数据包的碎片。
R-17: CEs that are assigned IPv4 prefixes and are in nodes that route public IPv4 addresses rather than only using NAT44s MUST have the same behavior as that described just above for BRs.
R-17：分配了IPv4前缀且位于路由公共IPv4地址（而非仅使用NAT44）的节点中的CE必须具有与上面针对BRs描述的相同的行为。
When packets go from CEs that share the same IPv4 address to a common destination, a precaution is needed to guarantee that packet identifications set by sources are different. Otherwise, packet reassembly at the destination could be confused because it is based only on source IPv4 address and Identification. The probability of such confusing situations may in theory be very low, but a safe solution is needed in order to avoid creating new attack opportunities.
当数据包从共享相同IPv4地址的CE发送到公共目的地时，需要采取预防措施以确保源设置的数据包标识不同。否则，在目的地重新组装数据包可能会混淆，因为它仅基于源IPv4地址和标识。理论上，此类混乱情况的概率可能非常低，但需要一个安全的解决方案，以避免创造新的攻击机会。
R-18: A CE that is assigned a shared public IPv4 address MUST only use packet identifications that have the CE PSID in their bits 0 to PSID length - 1.
R-18：分配了共享公共IPv4地址的CE必须仅使用在其位0到PSID长度-1中具有CE PSID的数据包标识。
R-19: A BR or a CE that receives a packet from a shared-address CE MUST check that bits 0 to PSID length - 1 of their packet identifications are equal to the PSID found in the source 4rd IPv4 address.
R-19：从共享地址CE接收数据包的BR或CE必须检查其数据包标识的位0到PSID长度-1是否等于源第4个IPv4地址中的PSID。
IPv4 TOS and IPv6 traffic class have the same semantic, that of the differentiated services field, or DS field, specified in [RFC2474] and [RFC6040]. Their first 6 bits contain a differentiated services codepoint (DSCP), and their last 2 bits can convey explicit congestion notifications (ECNs), which both may evolve during Domain traversal. [RFC2983] discusses how the DSCP can be handled by tunnel endpoints. The Tunnel Traffic Class option provides permission to ignore DS-field evolutions occurring during Domain traversal, if the desired behavior is that of generic tunnels conforming to [RFC2473].
IPv4 TOS和IPv6流量类别具有相同的语义，[RFC2474]和[RFC6040]中指定的区分服务字段或DS字段的语义相同。它们的前6位包含一个区分服务代码点（DSCP），最后2位可以传递显式拥塞通知（ECN），这两个通知都可能在域遍历过程中演变。[RFC2983]讨论了隧道端点如何处理DSCP。如果所需行为是符合[RFC2473]的通用隧道的行为，则Tunnel Traffic Class选项允许忽略域遍历期间发生的DS场演变。
R-20: Unless the Tunnel Traffic Class option is configured for the Domain, BRs and CEs MUST copy the IPv4 TOS into the IPv6 traffic class at Domain entry and copy back the IPv6 traffic class into the IPv4 TOS at Domain exit.
R-20：除非为域配置了隧道流量类选项，否则BRs和CEs必须在域入口将IPv4 TOS复制到IPv6流量类，并在域出口将IPv6流量类复制回IPv4 TOS。
R-21: If the Tunnel Traffic Class option is configured for a Domain, BRs and CEs MUST at Domain entry take the configured Tunnel Traffic Class as the IPv6 traffic class and copy the received IPv4 TOS into the IPv4_TOS of the fragment header (Figure 3). At Domain exit, they MUST copy back the IPv4_TOS of the fragment header into the IPv4 TOS.
R-21：如果为域配置了Tunnel Traffic Class选项，则BRs和CEs必须在域入口将配置的Tunnel Traffic Class作为IPv6 Traffic Class，并将收到的IPv4 TOS复制到片段头的IPv4_TOS中（图3）。在域退出时，他们必须将片段头的IPv4_TOS复制回IPv4 TOS。
If a Tunnel packet is discarded on its way across a 4rd domain because of an unreachable destination, an ICMPv6 error message is returned to the IPv6 source. For the IPv4 source of the discarded packet to be informed of packet loss, the ICMPv6 message has to be converted into an ICMPv4 message.
如果由于无法到达目的地，隧道数据包在穿越第4个域的途中被丢弃，则会向IPv6源返回ICMPv6错误消息。要使丢弃数据包的IPv4源得知数据包丢失，必须将ICMPv6消息转换为ICMPv4消息。
R-22: If a CE or BR receives an ICMPv6 error message [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC792]. This packet MUST contain the first 8 octets of the discarded packet's IP payload. The reserved IPv4 dummy address (192.0.0.8/32; see Section 6) MUST be used as its source address.
R-22：如果CE或BR收到ICMPv6错误消息[RFC4443]，则必须合成ICMPv4错误包[RFC792]。此数据包必须包含丢弃数据包IP有效负载的前8个八位字节。保留的IPv4虚拟地址（192.0.0.8/32；请参见第6节）必须用作其源地址。
As described in [RFC6145], ICMPv6 Type = 1 and Code = 0 (Destination Unreachable, No route to destination) MUST be translated into ICMPv4 Type = 3 and Code = 0 (Destination Unreachable, Net unreachable), and ICMPv6 Type = 3 and Code = 0 (Time Exceeded, Hop limit exceeded in transit) MUST be translated into ICMPv4 Type = 11 and Code = 0 (Time Exceeded, time to live exceeded in transit).
如[RFC6145]中所述，ICMPv6 Type=1和Code=0（无法到达目的地，没有到目的地的路由）必须转换为ICMPv4 Type=3和Code=0（无法到达目的地，无法到达网络），ICMPv6 Type=3和Code=0（超过时间，在传输过程中超过跃点限制）必须转换为ICMPv4 Type=11和Code=0（超过时间，在运输过程中超过生存时间）。
Domain parameters listed in Section 4.2 are subject to the following constraints:
第4.2节中列出的域参数受以下约束：
R-23: Each Domain MUST have a BR Mapping rule and/or a NAT64+ Mapping rule. The BR Mapping rule is only used by CEs that are assigned public IPv4 addresses, shared or not. The NAT64+ Mapping rule is only used by CEs that are assigned the unspecified IPv4 address (Section 4.4) and therefore need an ISP NAT64 to reach IPv4 destinations.
R-23:每个域都必须有BR映射规则和/或NAT64+映射规则。BR映射规则仅由分配了公共IPv4地址（无论是否共享）的CE使用。NAT64+映射规则仅由分配了未指定IPv4地址（第4.4节）的CE使用，因此需要ISP NAT64才能到达IPv4目的地。
R-24: Each CE and each BR MUST support up to 32 Mapping rules.
R-24：每个CE和每个BR必须支持多达32个映射规则。
Support for up to 32 Mapping rules ensures that independently acquired CEs and BR nodes can always interwork.
支持多达32条映射规则，确保独立获取的CEs和BR节点始终可以互通。
ISPs that need Mapping rules for more IPv4 prefixes than this number SHOULD split their networks into multiple Domains. Communication between these domains can be done in IPv4 or by some other implementation-dependent, but equivalent, means.
如果ISP需要更多IPv4前缀的映射规则，则应将其网络拆分为多个域。这些域之间的通信可以在IPv4中完成，也可以通过其他一些依赖于实现但等效的方式完成。
R-25: For mesh topologies, where CE-CE paths don't go via BRs, all Mapping rules of the Domain MUST be sent to all CEs. For hub-and-spoke topologies, where all CE-CE paths go via BRs, each CE MAY be sent only the BR Mapping rule of the Domain plus, if different, the CE Mapping rule that applies to its CE IPv6 prefix.
R-25：对于网状拓扑，CE-CE路径不通过BRs，域的所有映射规则必须发送到所有CE。对于中心辐射式拓扑，所有CE-CE路径都通过BRs，每个CE只能发送域的BR映射规则以及应用于其CE IPv6前缀的CE映射规则（如果不同）。
R-26: In a Domain where the chosen topology is hub-and-spoke, all CEs MUST have IPv6 prefixes that match a CE Mapping rule. (Otherwise, packets sent to CEs whose IPv6 prefixes would match only the BR Mapping rule would, with longest-match selected routes, be routed directly to these CEs. This would be contrary to the hub-and-spoke requirement.)
R-26：在所选拓扑为中心辐射的域中，所有CE必须具有与CE映射规则匹配的IPv6前缀。（否则，发送到其IPv6前缀仅与BR映射规则匹配的CEs的数据包将直接路由到这些CEs。这将违反集线器辐射要求。）
R-27: CEs MUST be able to acquire parameters of 4rd domains (Section 4.2) in DHCPv6 [RFC3315]. Formats of DHCPv6 options to be used are detailed in Figures 7, 8, and 9, with field values specified after each figure.
R-27:CEs必须能够获取DHCPv6[RFC3315]中第四个域（第4.2节）的参数。图7、8和9详细说明了要使用的DHCPv6选项的格式，每个图后面都指定了字段值。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option = OPTION_4RD | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encapsulated 4rd rule options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option = OPTION_4RD | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encapsulated 4rd rule options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DHCPv6 Option for 4rd
图7:4rd的DHCPv6选项
o option code: 97, OPTION_4RD (see Section 6)
o 选项代码：97，选项4RD（见第6节）
o option-length: the length of encapsulated options, in octets
o 选项长度：封装选项的长度，以八位字节为单位
o encapsulated 4rd rule options: The OPTION_4RD DHCPv6 option contains at least one encapsulated OPTION_4RD_MAP_RULE option and a maximum of one encapsulated OPTION_4RD_NON_MAP_RULE option. Since DHCP servers normally send whatever options the operator configures, operators are advised to configure these options appropriately. DHCP servers MAY check to see that the configuration follows these rules and notify the operator in an implementation-dependent manner if the settings for these options aren't valid. The length of encapsulated options is in octets.
o 封装的4rd规则选项：选项\u 4rd DHCPv6至少包含一个封装选项\u 4rd\u映射\u规则选项，最多包含一个封装选项\u 4rd\u非映射\u规则选项。由于DHCP服务器通常发送操作员配置的任何选项，因此建议操作员适当配置这些选项。DHCP服务器可能会检查配置是否遵循这些规则，如果这些选项的设置无效，则会以依赖于实现的方式通知操作员。封装选项的长度以八位字节为单位。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option = OPTION_4RD_MAP_RULE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix4-len | prefix6-len | ea-len |W| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule-ipv4-prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| rule-ipv6-prefix |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option = OPTION_4RD_MAP_RULE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix4-len | prefix6-len | ea-len |W| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule-ipv4-prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| rule-ipv6-prefix |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Encapsulated Option for Mapping-Rule Parameters
图8：映射规则参数的封装选项
o option code: 98, encapsulated OPTION_4RD_MAP_RULE option (see Section 6)
o 选项代码：98，封装选项\u 4RD\u地图\u规则选项（见第6节）
o option-length: 20
o 选件长度：20
o prefix4-len: number of bits of the Rule IPv4 prefix
o prefix4 len：规则IPv4前缀的位数
o prefix6-len: number of bits of the Rule IPv6 prefix
o prefix6 len：规则IPv6前缀的位数
o ea-len: EA-bits length
o ea len:ea位长度
o W: WKP authorized, = 1 if set
o W:WKP授权，如果设置，则=1
o rule-ipv4-prefix: Rule IPv4 prefix, left-aligned
o rule-ipv4-prefix：规则ipv4前缀，左对齐
o rule-ipv6-prefix: Rule IPv6 prefix, left-aligned
o rule-ipv6-prefix：规则ipv6前缀，左对齐
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|option =OPTION_4RD_NON_MAP_RULE| option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| 0 |T| traffic-class | domain-pmtu |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|option =OPTION_4RD_NON_MAP_RULE| option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| 0 |T| traffic-class | domain-pmtu |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Encapsulated Option for Non-Mapping-Rule Parameters of 4rd Domains
图9:4rd域的非映射规则参数的封装选项
o option code: 99, encapsulated OPTION_4RD_NON_MAP_RULE option (see Section 6)
o 选项代码：99，封装选项\u 4RD\u非\u映射\u规则选项（见第6节）
o option-length: 4
o 选项长度：4
o H: Hub-and-spoke topology (= 1 if Yes)
o H：轮毂和轮辐拓扑（=1，如果是）
o T: Traffic Class flag (= 1 if a Tunnel Traffic Class is provided)
o T：交通等级标志（=1，如果提供了隧道交通等级）
o traffic-class: Tunnel Traffic Class
o 交通等级：隧道交通等级
o domain-pmtu: Domain PMTU (at least 1280 octets)
o 域pmtu：域pmtu（至少1280个八位字节）
Means other than DHCPv6 that may prove useful to provide 4rd parameters to CEs are off-scope for this document. The same or similar parameter formats would, however, be recommended to facilitate training and operation.
除DHCPv6外，向CEs提供第四个参数可能有用的方法不在本文件范围内。但是，建议采用相同或类似的参数格式，以便于培训和操作。
Spoofing attacks
欺骗攻击
With IPv6 ingress filtering in effect in the Domain [RFC3704], as required in Section 3 (Figure 1 in particular), and with consistency checks between 4rd IPv4 and IPv6 addresses (Section 4.5), no spoofing opportunity in IPv4 is introduced by 4rd: being able to use as source IPv6 address only one that has been allocated to him, a customer can only provide as source 4rd IPv4 address that which derives this IPv6 address according to Section 4.5, i.e., one that his ISP has allocated to him.
根据第3节（特别是图1）的要求，在域[RFC3704]中实施IPv6入口过滤，并在第4条IPv4和IPv6地址之间进行一致性检查（第4.5节）的情况下，第4条不会在IPv4中引入欺骗机会：只能将分配给他的一个地址用作源IPv6地址，客户只能提供根据第4.5节派生此IPv6地址的源第4条IPv4地址，即其ISP分配给他的地址。
Routing loop attacks
路由循环攻击
Routing loop attacks that may exist in some "automatic tunneling" scenarios are documented in [RFC6324]. No opportunities for routing loop attacks have been identified with 4rd.
[RFC6324]中记录了某些“自动隧道”场景中可能存在的路由循环攻击。4rd没有发现路由循环攻击的机会。
Fragmentation-related attacks
碎片相关攻击
As discussed in Section 4.6, each BR of a Domain that assigns shared public IPv4 addresses should maintain a dynamic table of fragmented packets that go to these shared-address CEs.
如第4.6节所述，分配共享公共IPv4地址的域的每个BR都应该维护一个动态表，其中包含指向这些共享地址的碎片数据包。
This leaves BRs vulnerable to denial-of-service attacks from hosts that would send very large numbers of first fragments and would never send last fragments having the same packet identifications. This vulnerability is inherent in IPv4 address sharing, be it static or dynamic. Compared to what it is with algorithms that reassemble IPv4 packets in BRs, it is, however, significantly mitigated by the algorithm provided in Section 4.6.2, as that algorithm uses much less memory space.
这使得BRs容易受到来自主机的拒绝服务攻击，这些主机将发送大量的第一个片段，并且永远不会发送具有相同数据包标识的最后一个片段。此漏洞是IPv4地址共享中固有的，无论是静态还是动态。然而，与在BRs中重新组装IPv4数据包的算法相比，第4.6.2节中提供的算法大大减轻了这一问题，因为该算法使用的内存空间要少得多。
IANA has allocated the following:
IANA已分配以下各项：
o Encapsulated options OPTION_4RD (97), OPTION_4RD_MAP_RULE (98), and OPTION_4RD_NON_MAP_RULE (99). These options have been recorded in the option code space of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry. See Section 4.9 of this document and Section 24.3 of [RFC3315]).
o 封装的选项选项RD（97）、选项RD映射规则（98）和选项RD非映射规则（99）。这些选项已记录在“IPv6动态主机配置协议（DHCPv6）”注册表的选项代码空间中。参见本文件第4.9节和[RFC3315]第24.3节。
Value | Description | Reference
-----------+-------------------------+---------------
97 | OPTION_4RD | this document
98 | OPTION_4RD_MAP_RULE | this document
99 | OPTION_4RD_NON_MAP_RULE | this document
Value | Description | Reference
-----------+-------------------------+---------------
97 | OPTION_4RD | this document
98 | OPTION_4RD_MAP_RULE | this document
99 | OPTION_4RD_NON_MAP_RULE | this document
o Reserved IPv4 address 192.0.0.8/32 to be used as the "IPv4 dummy address" (Section 4.8).
o 保留的IPv4地址192.0.0.8/32用作“IPv4虚拟地址”（第4.8节）。
The present specification has been influenced by many previous IETF drafts, in particular those accessible at <http://tools.ietf.org/html/draft-xxxx>, where "xxxx" refers to the following (listed in order, by date of their first versions):
本规范受到许多以前的IETF草案的影响，特别是那些可在<http://tools.ietf.org/html/draft-xxxx>，其中“xxxx”指以下内容（按顺序列出，按其第一个版本的日期排列）：
o bagnulo-behave-nat64 (2008-06-10)
o bagnulo-behave-nat64（2008-06-10）
o xli-behave-ivi (2008-07-06)
o xli-ivi（2008-07-06）
o despres-sam-scenarios (2008-09-28)
o 解除sam场景（2008-09-28）
o boucadair-port-range (2008-10-23)
o 布卡达尔港口范围（2008-10-23）
o ymbk-aplusp (2008-10-27)
o ymbk aplusp（2008-10-27）
o xli-behave-divi (2009-10-19)
o xli行为分部（2009-10-19）
o thaler-port-restricted-ip-issues (2010-02-28)
o 泰勒端口受限ip问题（2010-02-28）
o cui-softwire-host-4over6 (2010-07-06)
o cui-softwire-host-4over6（2010-07-06）
o dec-stateless-4v6 (2011-03-05)
o dec-stateless-4v6（2011-03-05）
o matsushima-v6ops-transition-experience (2011-03-07)
o 松岛-v6ops-transition-experience（2011-03-07）
o despres-intarea-4rd (2011-03-07)
o despres-intarea-4rd（2011-03-07）
o deng-aplusp-experiment-results (2011-03-07)
o 邓亚普实验结果（2011-03-07）
o operators-softwire-stateless-4v6-motivation (2011-05-05)
o 运营商-软线-无状态-4v6-动机（2011-05-05）
o xli-behave-divi-pd (2011-07-04)
o xli行为分部pd（2011-07-04）
o murakami-softwire-4rd (2011-07-04)
o 村上软线4rd（2011-07-04）
o murakami-softwire-4v6-translation (2011-07-04)
o murakami-softwire-4v6-translation（2011-07-04）
o despres-softwire-4rd-addmapping (2011-08-19)
o despres-softwire-4rd-addmapping（2011-08-19）
o boucadair-softwire-stateless-requirements (2011-09-08)
o boucadair软线无状态要求（2011-09-08）
o chen-softwire-4v6-add-format (2011-10-12)
o chen-softwire-4v6-add-format（2011-10-12）
o mawatari-softwire-464xlat (2011-10-16)
o mawatari-softwire-464xlat（2011-10-16）
o mdt-softwire-map-dhcp-option (2011-10-24)
o mdt软线映射dhcp选项（2011-10-24）
o mdt-softwire-mapping-address-and-port (2011-10-24)
o mdt软线映射地址和端口（2011-10-24）
o mdt-softwire-map-translation (2012-01-10)
o mdt软线地图翻译（2012-01-10）
o mdt-softwire-map-encapsulation (2012-01-27)
o mdt软线地图封装（2012-01-27）
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<http://www.rfc-editor.org/info/rfc791>.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，DOI 10.17487/RFC0792，1981年9月<http://www.rfc-editor.org/info/rfc792>.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[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, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<http://www.rfc-editor.org/info/rfc2474>.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <http://www.rfc-editor.org/info/rfc2983>.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 2983，DOI 10.17487/RFC2983，2000年10月<http://www.rfc-editor.org/info/rfc2983>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，DOI 10.17487/RFC4443，2006年3月<http://www.rfc-editor.org/info/rfc4443>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. Durand, Ed., "Softwire Problem Statement", RFC 4925, DOI 10.17487/RFC4925, July 2007, <http://www.rfc-editor.org/info/rfc4925>.
[RFC4925]Li，X.，Ed.，Dawkins，S.，Ed.，Ward，D.，Ed.，和A.Durand，Ed.，“软线问题声明”，RFC 4925，DOI 10.17487/RFC4925，2007年7月<http://www.rfc-editor.org/info/rfc4925>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，Ed.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，DOI 10.17487/RFC5082，2007年10月<http://www.rfc-editor.org/info/rfc5082>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6040]Briscoe，B.，“明确拥塞通知的隧道挖掘”，RFC 6040，DOI 10.17487/RFC6040，2010年11月<http://www.rfc-editor.org/info/rfc6040>.
[NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", Work in Progress, draft-shirasaki-nat444-06, July 2012.
[NAT444]山形，I.，白崎，Y.，中川，A.，山口，J.，和H.Ashida，“NAT444”，正在进行的工作，草稿-Shirasaki-NAT444-062012年7月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC 1191，DOI 10.17487/RFC1191，1990年11月<http://www.rfc-editor.org/info/rfc1191>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，DOI 10.17487/RFC2473，1998年12月<http://www.rfc-editor.org/info/rfc2473>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，DOI 10.17487/RFC3022，2001年1月<http://www.rfc-editor.org/info/rfc3022>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 3704，DOI 10.17487/RFC3704，2004年3月<http://www.rfc-editor.org/info/rfc3704>.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, <http://www.rfc-editor.org/info/rfc3828>.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，Ed.，和G.Fairhurst，Ed.，“轻量级用户数据报协议（UDP Lite）”，RFC 3828，DOI 10.17487/RFC3828，2004年7月<http://www.rfc-editor.org/info/rfc3828>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<http://www.rfc-editor.org/info/rfc4271>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 4821，DOI 10.17487/RFC4821，2007年3月<http://www.rfc-editor.org/info/rfc4821>.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, <http://www.rfc-editor.org/info/rfc4961>.
[RFC4961]Wing，D，“对称RTP/RTP控制协议（RTCP）”，BCP 131，RFC 4961，DOI 10.17487/RFC49611907年7月<http://www.rfc-editor.org/info/rfc4961>.
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, September 2009, <http://www.rfc-editor.org/info/rfc5595>.
[RFC5595]Fairhurst，G.“数据报拥塞控制协议（DCCP）服务代码”，RFC 5595，DOI 10.17487/RFC5595，2009年9月<http://www.rfc-editor.org/info/rfc5595>.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, DOI 10.17487/RFC5969, August 2010, <http://www.rfc-editor.org/info/rfc5969>.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，DOI 10.17487/RFC5969，2010年8月<http://www.rfc-editor.org/info/rfc5969>.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 6145DOI 10.17487/RFC6145，2011年4月<http://www.rfc-editor.org/info/rfc6145>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 6146，DOI 10.17487/RFC6146，2011年4月<http://www.rfc-editor.org/info/rfc6146>.
[RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, <http://www.rfc-editor.org/info/rfc6324>.
[RFC6324]Nakbly，G.和F.Templin，“使用IPv6自动隧道的路由循环攻击：问题陈述和建议的缓解措施”，RFC 6324DOI 10.17487/RFC6324，2011年8月<http://www.rfc-editor.org/info/rfc6324>.
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/ RFC6346, August 2011, <http://www.rfc-editor.org/info/rfc6346>.
[RFC6346]Bush，R.，Ed.，“IPv4地址短缺的地址加端口（A+P）方法”，RFC 6346，DOI 10.17487/RFC6346，2011年8月<http://www.rfc-editor.org/info/rfc6346>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>.
[RFC6437]Amante，S.，Carpenter，B.，Jiang，S.，和J.Rajahalme，“IPv6流标签规范”，RFC 6437，DOI 10.17487/RFC6437，2011年11月<http://www.rfc-editor.org/info/rfc6437>.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/RFC6535, February 2012, <http://www.rfc-editor.org/info/rfc6535>.
[RFC6535]Huang，B.，Deng，H.，和T.Savolainen，“使用“主机中的凹凸”（BIH）的双堆栈主机”，RFC 6535，DOI 10.17487/RFC65352012年2月<http://www.rfc-editor.org/info/rfc6535>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.
[RFC6887]Wing，D.，Ed.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，DOI 10.17487/RFC6887，2013年4月<http://www.rfc-editor.org/info/rfc6887>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7136]Carpenter，B.和S.Jiang，“IPv6接口标识符的重要性”，RFC 7136，DOI 10.17487/RFC7136，2014年2月<http://www.rfc-editor.org/info/rfc7136>.
[Solutions-4v6] Boucadair, M., Ed., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions", Work in Progress, draft-ietf-softwire-stateless-4v6-motivation-05, November 2012.
[Solutions-4v6]Boucadair，M.，Ed.，Matsushima，S.，Lee，Y.，Bonness，O.，Borges，I.，和G.Chen，“基于IPv6的载波端无状态IPv4迁移解决方案的动机”，正在进行中的工作，草稿-ietf-softwire-Stateless-4v6-motive-052012年11月。
In the sections that follow, each Mapping rule will be represented as follows, using 0bXXX to represent binary number XXX; square brackets ("[ ]") indicate optional items:
在接下来的部分中，每个映射规则将表示为如下所示，使用0bXXX表示二进制数XXX；方括号（“[]”）表示可选项目：
{Rule IPv4 prefix, EA-bits length, Rule IPv6 prefix [, WKPs authorized]}
{规则IPv4前缀，EA位长度，规则IPv6前缀[，WKPs授权]}
EXAMPLES:
{0.0.0.0/0, 32, 2001:db8:0:1:300::/80}
a BR Mapping rule
{198.16.0.0/14, 22, 2001:db8:4000::/34}
a CE Mapping rule
{0.0.0.0/0, 32, 2001:db8:0:1::/80}
a NAT64+ Mapping rule
{198.16.0.0/14, 22, 2001:db8:4000::/34, Yes}
a CE Mapping rule
and hub-and-spoke topology
EXAMPLES:
{0.0.0.0/0, 32, 2001:db8:0:1:300::/80}
a BR Mapping rule
{198.16.0.0/14, 22, 2001:db8:4000::/34}
a CE Mapping rule
{0.0.0.0/0, 32, 2001:db8:0:1::/80}
a NAT64+ Mapping rule
{198.16.0.0/14, 22, 2001:db8:4000::/34, Yes}
a CE Mapping rule
and hub-and-spoke topology
As far as Mapping rules are concerned, the simplest deployment model is that in which the Domain has only one rule (the BR Mapping rule). To assign an IPv4 address to a CE in this model, an IPv6 /112 is assigned to it, comprising the BR /64 prefix, the 4rd Tag, and the IPv4 address. However, this model has the following limitations: (1) shared IPv4 addresses are not supported; (2) IPv6 prefixes used for 4rd are too long to also be used for native IPv6 addresses; (3) if the IPv4 address space of the ISP is split with many disjoint IPv4 prefixes, the IPv6 routing plan must be as complex as an IPv4 routing plan based on these prefixes.
就映射规则而言，最简单的部署模型是域只有一个规则（BR映射规则）的部署模型。在此模型中，要将IPv4地址分配给CE，需要为其分配IPv6/112，包括BR/64前缀、第4个标记和IPv4地址。但是，该模型有以下限制：（1）不支持共享IPv4地址；（2） 用于第4rd的IPv6前缀太长，无法同时用于本机IPv6地址；（3） 如果ISP的IPv4地址空间被许多不相交的IPv4前缀分割，则IPv6路由计划必须与基于这些前缀的IPv4路由计划一样复杂。
With more Mapping rules, CE prefixes used for 4rd can be those used for native IPv6. How to choose CE Mapping rules for a particular deployment does not need to be standardized.
有了更多的映射规则，用于4rd的CE前缀可以是用于本机IPv6的CE前缀。如何为特定部署选择CE映射规则不需要标准化。
The following is only a particular pragmatic approach that can be used for various deployment scenarios. It is applied in some of the use cases that follow.
以下只是一种特殊的实用方法，可用于各种部署场景。它应用于下面的一些用例中。
(1) Select a "Common_IPv6_prefix" that will appear at the beginning of all 4rd CE IPv6 prefixes.
(1) 选择将出现在所有4rd CE IPv6前缀开头的“公共_IPv6_前缀”。
(2) Choose all IPv4 prefixes to be used, and assign one of them to each CE Mapping rule i.
(2) 选择要使用的所有IPv4前缀，并将其中一个分配给每个CE映射规则i。
(3) For each CE Mapping rule i, do the following:
(3) 对于每个CE映射规则i，请执行以下操作：
A. Choose the length of its Rule IPv6 prefix (possibly the same for all CE Mapping rules).
A.选择其规则IPv6前缀的长度（对于所有CE映射规则可能相同）。
B. Determine its PSID_length(i). A CE Mapping rule that assigns shared addresses with a sharing ratio of 2^Ki has PSID_length = Ki. A CE Mapping rule that assigns IPv4 prefixes of length L < 32 is considered to have a negative PSID_length (PSID_length = L - 32).
B.确定其PSID_长度（i）。分配共享比率为2^Ki的共享地址的CE映射规则具有PSID_length=Ki。分配长度为L<32的IPv4前缀的CE映射规则被认为具有负PSID_长度（PSID_长度=L-32）。
C. Derive EA-bits length(i) = 32 - L(Rule IPv4 prefix(i)) + PSID_length(i).
C.导出EA位长度（i）=32-L（规则IPv4前缀（i））+PSID_长度（i）。
D. Derive the length of Rule_code(i), the prefix to be appended to the common prefix to get the Rule IPv6 prefix of rule i:
D.推导规则_代码（i）的长度，将前缀附加到公共前缀以获得规则i的规则IPv6前缀：
L(Rule_code(i)) = L(CE IPv6 prefix(i))
- L(Common_IPv6_prefix)
- (32 - L(Rule IPv4 prefix(i)))
- PSID_length(i)
L(Rule_code(i)) = L(CE IPv6 prefix(i))
- L(Common_IPv6_prefix)
- (32 - L(Rule IPv4 prefix(i)))
- PSID_length(i)
E. Derive Rule_code(i) with the following constraints: (1) its length is L(Rule_code(i)); (2) it does not overlap with any of the previously obtained Rule_codes (for instance, 010 and 01011 do overlap, while 00, 011, and 010 do not); (3) it has the lowest possible value as a fractional binary number (for instance, 0100 < 10 < 11011 < 111). Thus, rules whose Rule_code lengths are 4, 3, 5, and 2 give Rule_codes 0000, 001, 00010, and 01.
E.使用以下约束条件导出规则_代码（i）：（1）其长度为L（规则_代码（i））；（2） 它不与先前获得的任何规则_代码重叠（例如，010和01011确实重叠，而00、011和010不重叠）；（3） 它具有尽可能低的分数二进制数值（例如，0100<10<11011<111）。因此，规则代码长度为4、3、5和2的规则给出了规则代码0000、001、00010和01。
F. Take Rule IPv6 prefix(i) = the Common_IPv6_prefix followed by Rule_code(i).
F.采用规则IPv6前缀（i）=公共的规则IPv6前缀，后跟规则代码（i）。
:<--------------------- L(CE IPv6 prefix(i)) --------------------->:
: :
: 32 - L(Rule IPv4 prefix(i)) PSID_length(i):
: \ | :
: :<---------'--------><--'-->:
: : || :
: : \/ :
: :<------->:<--- EA-bits length(i) --->:
: L(Rule_code(i))
: : :
+----------------------------+---------+
| Common_IPv6_prefix |Rule_code|
| | (i) |
+----------------------------+---------+
:<------ L(Rule IPv6 prefix(i)) ------>:
:<--------------------- L(CE IPv6 prefix(i)) --------------------->:
: :
: 32 - L(Rule IPv4 prefix(i)) PSID_length(i):
: \ | :
: :<---------'--------><--'-->:
: : || :
: : \/ :
: :<------->:<--- EA-bits length(i) --->:
: L(Rule_code(i))
: : :
+----------------------------+---------+
| Common_IPv6_prefix |Rule_code|
| | (i) |
+----------------------------+---------+
:<------ L(Rule IPv6 prefix(i)) ------>:
Figure 10: Diagram of One Pragmatic Approach
图10：一种实用方法的示意图
Here, we consider an ISP that offers IPv6-only service to up to 2^20 customers. Each customer is delegated a /56, starting with common prefix 2001:db8:0::/36. The ISP wants to add public IPv4 service for customers that are 4rd capable. It prefers to do so with stateless operation in its nodes but has significantly fewer IPv4 addresses than IPv6 addresses, so a sharing ratio is necessary.
在这里，我们考虑一个ISP只提供IPv6服务多达2 ^ 20客户。每个客户都被委派a/56，从公共前缀2001:db8:0:：/36开始。ISP希望为支持第4条的客户添加公共IPv4服务。它更喜欢在节点中使用无状态操作，但IPv4地址明显少于IPv6地址，因此需要一个共享比率。
The only IPv4 prefixes it can use are 192.8.0.0/15, 192.4.0.0/16, 192.2.0.0/16, and 192.1.0.0/16 (neither overlapping nor aggregatable). This gives 2^(32 - 15) + 3 * 2^(32 - 16) IPv4 addresses, i.e., 2^18 + 2^16. For the 2^20 customers to have the same sharing ratio, the number of IPv4 addresses to be shared has to be a power of 2. The ISP can therefore give up using one of its /16s, say the last one. (Whether or not it could be motivated to return it to its Internet Registry is off-scope for this document.) The sharing ratio to apply is then 2^20 / 2^18 = 2^2 = 4, giving a PSID length of 2.
它可以使用的唯一IPv4前缀是192.8.0.0/15、192.4.0.0/16、192.2.0.0/16和192.1.0.0/16（既不重叠也不可聚合）。这就给出了2^（32-15）+3*2^（32-16）个IPv4地址，即2^18+2^16。要使2^20个客户具有相同的共享比率，要共享的IPv4地址数必须是2的幂。因此，ISP可以放弃使用它的/16之一，比如最后一个。（是否有动机将其返回到其Internet注册表不在本文档范围内。）然后应用的共享比率为2^20/2^18=2^2=4，PSID长度为2。
Applying the principles of Appendix B with L(Common_IPv6_prefix) = 36, L(PSID) = 2 for all rules, and L(CE IPv6 prefix(i)) = 56 for all rules, Rule_codes and Rule IPv6 prefixes are as follows:
应用附录B中L（公共_IPv6_前缀）=36、L（PSID）=2（适用于所有规则）和L（CE IPv6前缀（i））=56（适用于所有规则）的原则，规则_代码和规则IPv6前缀如下：
+--------------+--------+-----------+-----------+-------------------+
| CE Rule IPv4 | EA | Rule-Code | Code | CE Rule IPv6 |
| prefix | bits | length | (binary) | prefix |
| | length | | | |
+--------------+--------+-----------+-----------+-------------------+
| 192.8.0.0/15 | 19 | 1 | 0 | 2001:db8:0::/37 |
| 192.4.0.0/16 | 18 | 2 | 10 | 2001:db8:800::/38 |
| 192.2.0.0/16 | 18 | 2 | 11 | 2001:db8:c00::/38 |
+--------------+--------+-----------+-----------+-------------------+
+--------------+--------+-----------+-----------+-------------------+
| CE Rule IPv4 | EA | Rule-Code | Code | CE Rule IPv6 |
| prefix | bits | length | (binary) | prefix |
| | length | | | |
+--------------+--------+-----------+-----------+-------------------+
| 192.8.0.0/15 | 19 | 1 | 0 | 2001:db8:0::/37 |
| 192.4.0.0/16 | 18 | 2 | 10 | 2001:db8:800::/38 |
| 192.2.0.0/16 | 18 | 2 | 11 | 2001:db8:c00::/38 |
+--------------+--------+-----------+-----------+-------------------+
Mapping rules are then the following:
映射规则如下所示：
{192.8.0.0/15, 19, 2001:0db8:0000::/37}
{192.4.0.0/16, 18, 2001:0db8:0800::/38}
{192.2.0.0/16, 18, 2001:0db8:0c00::/38}
{0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80}
{192.8.0.0/15, 19, 2001:0db8:0000::/37}
{192.4.0.0/16, 18, 2001:0db8:0800::/38}
{192.2.0.0/16, 18, 2001:0db8:0c00::/38}
{0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80}
The CE whose IPv6 prefix is, for example, 2001:db8:0bbb:bb00::/56 derives its IPv4 address and its port set as follows (Section 4.4):
例如，IPv6前缀为2001:db8:0bbb:bb00:：/56的CE派生其IPv4地址和端口集，如下所示（第4.4节）：
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56
Rule IPv6 prefix(i): 2001:0db8:0800::/38 (longest match)
EA-bits length(i) : 18
EA bits : 0b11 1011 1011 1011 1011
Rule IPv4 prefix(i): 0b1100 0000 0000 0100 (192.4.0.0/16)
IPv4 address : 0b1100 0000 0000 0100 1110 1110 1110 1110
: 192.4.238.238
PSID : 0b11
Ports : 0bYYYY 11XX XXXX XXXX
with YYYY > 0, and X...X any value
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56
Rule IPv6 prefix(i): 2001:0db8:0800::/38 (longest match)
EA-bits length(i) : 18
EA bits : 0b11 1011 1011 1011 1011
Rule IPv4 prefix(i): 0b1100 0000 0000 0100 (192.4.0.0/16)
IPv4 address : 0b1100 0000 0000 0100 1110 1110 1110 1110
: 192.4.238.238
PSID : 0b11
Ports : 0bYYYY 11XX XXXX XXXX
with YYYY > 0, and X...X any value
An IPv4 packet sent to address 192.4.238.238 and port 7777 is tunneled to the IPv6 address obtained as follows (Section 4.5):
发送到地址192.4.238.238和端口7777的IPv4数据包通过隧道传输到IPv6地址，如下所示（第4.5节）：
IPv4 address : 192.4.238.238 (0xc004 eeee)
: 0b1100 0000 0000 0100 1110 1110 1110 1110
Rule IPv4 prefix(i): 192.4.0.0/16 (longest match)
: 0b1100 0000 0000 0100
IPv4 suffix(i) : 0b1110 1110 1110 1110
EA-bits length(i) : 18
PSID length(i) : 2 (= 16 + 18 - 32)
Port field : 0b 0001 1110 0110 0001 (7777)
PSID : 0b11
Rule IPv6 prefix(i): 2001:0db8:0800::/38
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56
IPv6 address : 2001:0db8:0bbb:bb00:300:c004:eeee:YYYY
with YYYY = the computed CNP
IPv4 address : 192.4.238.238 (0xc004 eeee)
: 0b1100 0000 0000 0100 1110 1110 1110 1110
Rule IPv4 prefix(i): 192.4.0.0/16 (longest match)
: 0b1100 0000 0000 0100
IPv4 suffix(i) : 0b1110 1110 1110 1110
EA-bits length(i) : 18
PSID length(i) : 2 (= 16 + 18 - 32)
Port field : 0b 0001 1110 0110 0001 (7777)
PSID : 0b11
Rule IPv6 prefix(i): 2001:0db8:0800::/38
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56
IPv6 address : 2001:0db8:0bbb:bb00:300:c004:eeee:YYYY
with YYYY = the computed CNP
We now consider an ISP that has the same need as the ISP described in the previous section, except that (1) instead of using only its own IPv6 infrastructure, it uses that of a third-party provider and (2) some of its customers use this provider's Customer Premises Equipment (CPEs) so that they can use specific services offered by the provider. In these CPEs, a non-zero index is used to route IPv6 packets to the physical port to which CEs are attached, say 0x2. Each such CPE delegates to the CE nodes the customer-site IPv6 prefix followed by this index.
我们现在考虑的ISP与前一部分描述的ISP有相同的需求，除了（1），而不是只使用它自己的IPv6基础设施，它使用第三方提供商的和（2）它的一些客户使用该提供商的客户驻地设备（CPE），以便它们可以使用提供商提供的特定服务。在这些CPE中，使用非零索引将IPv6数据包路由到连接CE的物理端口，例如0x2。每个这样的CPE将客户站点IPv6前缀（后跟此索引）委托给CE节点。
The ISP is supposed to have the same IPv4 prefixes as those in the previous use case -- 192.8.0.0/15, 192.4.0.0/16, and 192.2.0.0/16 -- and to use the same Common_IPv6_prefix, 2001:db8:0::/36.
ISP应该具有与前一个用例中相同的IPv4前缀——192.8.0.0/15、192.4.0.0/16和192.2.0.0/16——并使用相同的公共_IPv6_前缀，2001:db8:0:：/36。
We also assume that only a minority of customers use third-party CPEs, so that it is sufficient to use only one of the two /16s for them.
我们还假设只有少数客户使用第三方CPE，因此仅为他们使用两个/16中的一个就足够了。
Mapping rules are then (see Appendix C.1):
映射规则如下（见附录C.1）：
{192.8.0.0/15, 19, 2001:0db8:0000::/37}
{192.4.0.0/16, 18, 2001:0db8:0800::/38}
{192.2.0.0/16, 18, 2001:0db8:0c00::/38}
{0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80}
{192.8.0.0/15, 19, 2001:0db8:0000::/37}
{192.4.0.0/16, 18, 2001:0db8:0800::/38}
{192.2.0.0/16, 18, 2001:0db8:0c00::/38}
{0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80}
CEs that are behind third-party CPEs derive their own IPv4 addresses and port sets as described in Appendix C.1.
位于第三方CPE后面的CE派生其自己的IPv4地址和端口集，如附录C.1所述。
In a BR, and also in a CE if the topology is mesh, the IPv6 address that is derived from IPv4 address 192.4.238.238 and port 7777 is obtained as described in the previous section, except for the last two steps, which are modified as follows:
在BR中，以及在CE中（如果拓扑为mesh），从IPv4地址192.4.238.238和端口7777派生的IPv6地址如前一节所述获得，但最后两个步骤除外，其修改如下：
IPv4 address : 192.4.238.238 (0xc004 eeee)
: 0b1100 0000 0000 0100 1110 1110 1110 1110
Rule IPv4 prefix(i): 192.4.0.0/16 (longest match)
: 0b1100 0000 0000 0100
IPv4 suffix(i) : 0b1110 1110 1110 1110
EA-bits length(i) : 18
PSID length(i) : 2 (= 16 + 18 - 32)
Port field : 0b 0001 1110 0110 0001 (7777)
PSID : 0b11
Rule IPv6 prefix(i): 2001:0db8:0800::/38
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/60
IPv6 address : 2001:0db8:0bbb:bb00:300:192.4.238.238:YYYY
with YYYY = the computed CNP
IPv4 address : 192.4.238.238 (0xc004 eeee)
: 0b1100 0000 0000 0100 1110 1110 1110 1110
Rule IPv4 prefix(i): 192.4.0.0/16 (longest match)
: 0b1100 0000 0000 0100
IPv4 suffix(i) : 0b1110 1110 1110 1110
EA-bits length(i) : 18
PSID length(i) : 2 (= 16 + 18 - 32)
Port field : 0b 0001 1110 0110 0001 (7777)
PSID : 0b11
Rule IPv6 prefix(i): 2001:0db8:0800::/38
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/60
IPv6 address : 2001:0db8:0bbb:bb00:300:192.4.238.238:YYYY
with YYYY = the computed CNP
In this use case, we consider an ISP that offers IPv4 service with public addresses individually assigned to its customers. It also offers IPv6 service, as it has deployed dual-stack routing. Because it provides its own CPEs to customers, it can upgrade all of its CPEs to support 4rd. It wishes to take advantage of this capability to replace dual-stack routing with IPv6-only routing, without changing any IPv4 address or IPv6 prefix.
在这个用例中，我们考虑了一个ISP，它提供了IPv4服务，其公共地址单独分配给它的客户。它还提供IPv6服务，因为它部署了双栈路由。因为它向客户提供自己的CPE，所以它可以升级所有CPE以支持第四代。它希望利用这一功能，在不更改任何IPv4地址或IPv6前缀的情况下，将双栈路由替换为仅限IPv6的路由。
For this, the ISP can use the single-rule model described at the beginning of Appendix B. If the prefix routed to BRs is chosen to start with 2001:db8:0:1::/64, this rule is:
为此，ISP可以使用附录B开头所述的单一规则模型。如果选择路由到BRs的前缀以2001:db8:0:1:：/64开头，则此规则为：
{0.0.0.0/0, 32, 2001:db8:0:1:300::/80}
{0.0.0.0/0, 32, 2001:db8:0:1:300::/80}
All that is needed in the network before disabling IPv4 routing is the following:
禁用IPv4路由之前，网络中所需的全部内容如下：
o In all routers, where there is an IPv4 route toward x.x.x.x/n, add a parallel route toward 2001:db8:0:1:300:x.x.x.x::/(80+n).
o 在所有路由器中，如果存在指向x.x.x.x/n的IPv4路由，则添加指向2001:db8:0:1:300:x.x.x:：/（80+n）的并行路由。
o Where IPv4 address x.x.x.x was assigned to a CPE, now delegate IPv6 prefix 2001:db8:0:1:300:x.x.x.x::/112.
o 如果IPv4地址x.x.x.x已分配给CPE，则现在委派IPv6前缀2001:db8:0:1:300:x.x.x:：/112。
NOTE: In parallel with this deployment, or after it, shared IPv4 addresses can be assigned to IPv6 customers. It is sufficient that IPv4 prefixes used for this be different from those used for exclusive-address assignments. Under this constraint, Mapping rules can be set up according to the same principles as those described in Appendix C.
注意：与此部署并行或在此部署之后，可以将共享IPv4地址分配给IPv6客户。用于此目的的IPv4前缀与用于独占地址分配的IPv4前缀不同就足够了。在此约束下，可以根据附录C中描述的相同原则设置映射规则。
In this use case, we consider an ISP that has only deployed IPv4, possibly because some of its network devices are not yet IPv6 capable. Because it did not have enough IPv4 addresses, it has assigned private IPv4 addresses [RFC1918] to customers, say 10.x.x.x. It thus supports up to 2^24 customers (a "Net-10" network, using the NAT444 model [NAT444]).
在这个用例中，我们考虑了一个只有部署IPv4的ISP，可能是因为它的一些网络设备还没有IPv6的能力。因为它没有足够的IPv4地址，所以它为客户分配了专用IPv4地址[RFC1918]，比如10.x.x.x。因此，它最多支持2^24个客户（使用NAT444模型[NAT444]）。
Now, it wishes to offer IPv6 service without further delay, using 6rd [RFC5969]. It also wishes to offer incoming IPv4 connectivity to its customers with a simpler solution than that provided by the Port Control Protocol (PCP) [RFC6887].
现在，它希望使用第6条[RFC5969]不再延迟地提供IPv6服务。它还希望通过比端口控制协议（PCP）[RFC6887]提供的解决方案更简单的解决方案向其客户提供传入IPv4连接。
This appendix describes an example that adds IPv6 (using 6rd) and 4rd services to the "Net-10" private IPv4 network.
本附录描述了将IPv6（使用第6rd）和第4rd服务添加到“Net-10”专用IPv4网络的示例。
The IPv6 prefix to be used for 6rd is supposed to be 2001:db8::/32, and the public IPv4 prefix to be used for shared addresses is supposed to be 198.16.0.0/16 (0xc610). The resulting sharing ratio is 2^24 / 2^(32 - 16) = 256, giving a PSID length of 8.
用于第6rd的IPv6前缀应为2001:db8:：/32，用于共享地址的公共IPv4前缀应为198.16.0.0/16（0xc610）。结果共享比为2^24/2^（32-16）=256，PSID长度为8。
The ISP installs one or several BRs at its border to the public IPv4 Internet. They support 6rd, and 4rd above it. The BR prefix /64 is supposed to be that which is derived from IPv4 address 10.0.0.1 (i.e., 2001:db8:0:100:/64).
ISP在其与公共IPv4 Internet的边界处安装一个或多个BRs。他们支持第六条和第四条。BR前缀/64应该是从IPv4地址10.0.0.1（即2001:db8:0:100:/64）派生的前缀。
In accordance with [RFC5969], 6rd BRs are configured with the following parameters: IPv4MaskLen = 8; 6rdPrefix = 2001:db8::/32; 6rdBRIPv4Address = 192.168.0.1 (0xc0a80001).
根据[RFC5969]，第6rd BRs配置有以下参数：IPv4MaskLen=8；6rdPrefix=2001:db8:：/32；6rdBRIPv4Address=192.168.0.1（0xc0a80001）。
4rd Mapping rules are then the following:
第四映射规则如下所示：
{198.16.0.0/16, 24, 2001:db8:0:0:300::/80}
{0.0.0.0/0, 32, 2001:db8:0:100:300:/80,}
{198.16.0.0/16, 24, 2001:db8:0:0:300::/80}
{0.0.0.0/0, 32, 2001:db8:0:100:300:/80,}
Any customer device that supports 4rd in addition to 6rd can then use its assigned shared IPv4 address with 240 assigned ports.
然后，除第6rd之外，任何支持第4rd的客户设备都可以使用其分配的共享IPv4地址和240个分配的端口。
If its NAT44 supports port forwarding to provide incoming IPv4 connectivity (statically, or dynamically with Universal Plug and Play (UPnP) and/or the NAT Port Mapping Protocol (NAT-PMP)), it can use it with ports of the assigned port set (a possibility that does not exist in Net-10 networks without 4rd/6rd).
如果其NAT44支持端口转发以提供传入的IPv4连接（静态或动态使用通用即插即用（UPnP）和/或NAT端口映射协议（NAT-PMP）），则可以将其用于指定端口集的端口（在没有4rd/6rd的Net-10网络中不存在这种可能性）。
Acknowledgements
致谢
This specification has benefited over several years from independent proposals, questions, comments, constructive suggestions, and useful criticisms from numerous IETF contributors. The authors would like to express recognition of all of these contributors, and especially the following, in alphabetical order by their first names: Behcet Sarikaya, Bing Liu, Brian Carpenter, Cameron Byrne, Congxiao Bao, Dan Wing, Derek Atkins, Erik Kline, Francis Dupont, Gabor Bajko, Hui Deng, Jacni Quin (who was an active coauthor of some earlier versions of this specification), James Huang, Jan Zorz, Jari Arkko, Kathleen Moriarty, Laurent Toutain, Leaf Yeh, Lorenzo Colitti, Marcello Bagnulo, Mark Townsley, Mohamed Boucadair, Nejc Skoberne, Olaf Maennel, Ole Troan, Olivier Vautrin, Peng Wu, Qiong Sun, Rajiv Asati, Ralph Droms, Randy Bush, Satoru Matsushima, Simon Perreault, Stuart Cheshire, Suresh Krishnan, Ted Lemon, Teemu Savolainen, Tetsuya Murakami, Tina Tsou, Tomek Mrugalski, Washam Fan, Wojciech Dec, Xiaohong Deng, Xing Li, and Yu Fu.
多年来，本规范从众多IETF贡献者的独立提案、问题、评论、建设性建议和有用的批评中受益匪浅。作者希望对所有这些贡献者表示感谢，特别是以下贡献者，按姓名字母顺序排列：白塞特·萨里卡亚、刘冰、布赖恩·卡彭特、卡梅隆·伯恩、聪晓宝、丹荣、德里克·阿特金斯、埃里克·克莱恩、弗朗西斯·杜邦、加博·巴伊科、惠登、杰克尼·奎因（他是本规范早期版本的积极合著者），詹姆斯·黄，简·佐尔兹，贾里·阿尔科，凯瑟琳·莫里亚蒂，劳伦特·图坦，叶·叶，洛伦佐·科利蒂，马塞洛·巴格鲁，马克·汤斯利，穆罕默德·布卡达尔，奈杰克·斯科伯恩，奥拉夫·马内尔，奥勒·特隆，奥利维尔·沃特林，吴鹏，琼孙，拉吉夫·阿萨蒂，拉尔夫·德罗斯，兰迪·布什，萨托鲁·松岛，西蒙·佩雷尔特，斯图尔特·契尔，苏雷什·克里希南，泰德·莱蒙，T伊木·萨沃莱宁、村上铁树、邹天娜、托梅克·穆鲁加尔斯基、范华生、沃切克·德克、邓晓红、邢莉和余福。
Authors' Addresses
作者地址
Remi Despres RD-IPtech 3 rue du President Wilson Levallois France
法国总统威尔逊·莱瓦洛伊街3号雷米·德斯普雷斯路IPtech
Email: despres.remi@laposte.net
Email: despres.remi@laposte.net
Sheng Jiang (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus, No. 156 BeiQing Road Hai-Dian District, Beijing 100095 China
盛江（编辑）华为技术有限公司中国北京市海淀区北青路156号华为校区Q14 100095
Email: jiangsheng@huawei.com
Email: jiangsheng@huawei.com
Reinaldo Penno Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞西塔斯曼大道170号雷纳尔多·佩诺思科系统公司，邮编95134
Email: repenno@cisco.com
Email: repenno@cisco.com
Yiu Lee Comcast One Comcast Center Philadelphia, PA 19103 United States
美国宾夕法尼亚州费城康卡斯特中心一号耀利康卡斯特19103
Email: yiu_lee@cable.comcast.com
Email: yiu_lee@cable.comcast.com
Gang Chen China Mobile 29, Jinrong Avenue Xicheng District, Beijing 100033 China
中国移动北京市西城区锦荣大道29号陈刚100033
Email: phdgang@gmail.com, chengang@chinamobile.com
Email: phdgang@gmail.com, chengang@chinamobile.com
Maoke Chen (a.k.a. Noriyuki Arai) BBIX, Inc. Tokyo Shiodome Building, Higashi-Shimbashi 1-9-1 Minato-ku, Tokyo 105-7310 Japan
陈茂科（又名荒井法之）BBIX有限公司东京Shiodome大厦，东新桥1-9-1 Minato ku，东京105-7310
Email: maoke@bbix.net
Email: maoke@bbix.net