Internet Engineering Task Force (IETF) C. Bao
Request for Comments: 6052 CERNET Center/Tsinghua University
Updates: 4291 C. Huitema
Category: Standards Track Microsoft Corporation
ISSN: 2070-1721 M. Bagnulo
UC3M
M. Boucadair
France Telecom
X. Li
CERNET Center/Tsinghua University
October 2010
Internet Engineering Task Force (IETF) C. Bao
Request for Comments: 6052 CERNET Center/Tsinghua University
Updates: 4291 C. Huitema
Category: Standards Track Microsoft Corporation
ISSN: 2070-1721 M. Bagnulo
UC3M
M. Boucadair
France Telecom
X. Li
CERNET Center/Tsinghua University
October 2010
IPv6 Addressing of IPv4/IPv6 Translators
IPv4/IPv6转换器的IPv6寻址
Abstract
摘要
This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
本文档仅使用静态配置信息讨论IPv6地址到相应IPv4地址的算法转换，反之亦然。它定义了一个用于算法翻译的众所周知的前缀，同时允许组织在适当的时候也使用特定于网络的前缀。算法转换用于IPv4/IPv6转换器，以及IPv4/IPv6场景中使用的其他类型的代理和网关（例如DNS）。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6052.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6052.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 5
2.1. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 5
2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 5
2.3. Address Translation Algorithms . . . . . . . . . . . . . . 7
2.4. Text Representation . . . . . . . . . . . . . . . . . . . 7
3. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 8
3.1. Restrictions on the Use of the Well-Known Prefix . . . . . 8
3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8
3.3. Choice of Prefix for Stateless Translation Deployments . . 9
3.4. Choice of Prefix for Stateful Translation Deployments . . 11
4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12
4.2. Choice of the Well-Known Prefix . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Protection against Spoofing . . . . . . . . . . . . . . . 14
5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 15
5.3. Firewall Configuration . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 5
2.1. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 5
2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 5
2.3. Address Translation Algorithms . . . . . . . . . . . . . . 7
2.4. Text Representation . . . . . . . . . . . . . . . . . . . 7
3. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 8
3.1. Restrictions on the Use of the Well-Known Prefix . . . . . 8
3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8
3.3. Choice of Prefix for Stateless Translation Deployments . . 9
3.4. Choice of Prefix for Stateful Translation Deployments . . 11
4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12
4.2. Choice of the Well-Known Prefix . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Protection against Spoofing . . . . . . . . . . . . . . . 14
5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 15
5.3. Firewall Configuration . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
This document is part of a series of IPv4/IPv6 translation documents. A framework for IPv4/IPv6 translation is discussed in [v4v6-FRAMEWORK], including a taxonomy of scenarios that will be used in this document. Other documents specify the behavior of various types of translators and gateways, including mechanisms for translating between IP headers and other types of messages that include IP addresses. This document specifies how an individual IPv6 address is translated to a corresponding IPv4 address, and vice versa, in cases where an algorithmic mapping is used. While specific types of devices are used herein as examples, it is the responsibility of the specification of such devices to reference this document for algorithmic mapping of the addresses themselves.
本文档是IPv4/IPv6翻译文档系列的一部分。[v4v6框架]中讨论了IPv4/IPv6转换框架，包括本文档中将使用的场景分类。其他文档指定了各种类型的转换器和网关的行为，包括在IP头和包括IP地址的其他类型的消息之间进行转换的机制。本文档指定在使用算法映射的情况下，如何将单个IPv6地址转换为相应的IPv4地址，反之亦然。虽然本文使用特定类型的设备作为示例，但此类设备的规范有责任参考本文件以进行地址本身的算法映射。
Section 2 describes the prefixes and the format of "IPv4-embedded IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an IPv4 address. This format is common to both "IPv4-converted" and "IPv4-translatable" IPv6 addresses. This section also defines the algorithms for translating addresses, and the text representation of IPv4-embedded IPv6 addresses.
第2节描述了“IPv4嵌入式IPv6地址”的前缀和格式，即32位包含IPv4地址的IPv6地址。此格式对于“IPv4转换”和“IPv4可转换”IPv6地址都是通用的。本节还定义了转换地址的算法，以及IPv4嵌入IPv6地址的文本表示。
Section 3 discusses the choice of prefixes, the conditions in which they can be used, and the use of IPv4-embedded IPv6 addresses with stateless and stateful translation.
第3节讨论了前缀的选择、使用前缀的条件以及IPv4嵌入IPv6地址的无状态和有状态转换的使用。
Section 4 provides a summary of the discussions behind two specific design decisions, the choice of a null suffix and the specific value of the selected prefix.
第4节总结了两个具体设计决策背后的讨论，即空后缀的选择和所选前缀的具体值。
Section 5 discusses security concerns.
第5节讨论了安全问题。
In some scenarios, a dual-stack host will unnecessarily send its traffic through an IPv6/IPv4 translator. This can be caused by the host's default address selection algorithm [RFC3484], referrals, or other reasons. Optimizing these scenarios for dual-stack hosts is for future study.
在某些情况下，双堆栈主机将不必要地通过IPv6/IPv4转换器发送其流量。这可能是由于主机的默认地址选择算法[RFC3484]、引用或其他原因造成的。为双栈主机优化这些场景是为了将来的研究。
This document is part of a series defining address translation services. We understand that the address format could also be used by other interconnection methods between IPv6 and IPv4, e.g., methods based on encapsulation. If encapsulation methods are developed by the IETF, we expect that their descriptions will document their specific use of IPv4-embedded IPv6 addresses.
本文档是定义地址转换服务系列的一部分。我们了解，地址格式也可用于IPv6和IPv4之间的其他互连方法，例如基于封装的方法。如果封装方法是由IETF开发的，我们希望它们的描述将记录它们对IPv4嵌入式IPv6地址的具体使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document makes use of the following terms:
本文件使用了以下术语：
Address translator: any entity that has to derive an IPv4 address from an IPv6 address or vice versa. This applies not only to devices that do IPv4/IPv6 packet translation, but also to other entities that manipulate addresses, such as name resolution proxies (e.g., DNS64 [DNS64]) and possibly other types of Application Layer Gateways (ALGs).
地址转换器：必须从IPv6地址派生IPv4地址或从IPv6地址派生IPv4地址的任何实体。这不仅适用于执行IPv4/IPv6数据包转换的设备，还适用于操纵地址的其他实体，例如名称解析代理（例如DNS64[DNS64]）和可能的其他类型的应用层网关（ALG）。
IPv4-converted IPv6 addresses: IPv6 addresses used to represent IPv4 nodes in an IPv6 network. They are a variant of IPv4-embedded IPv6 addresses and follow the format described in Section 2.2.
IPv4转换的IPv6地址：用于表示IPv6网络中IPv4节点的IPv6地址。它们是IPv4嵌入式IPv6地址的变体，并遵循第2.2节中描述的格式。
IPv4-embedded IPv6 addresses: IPv6 addresses in which 32 bits contain an IPv4 address. Their format is described in Section 2.2.
IPv4嵌入式IPv6地址：其中32位包含IPv4地址的IPv6地址。其格式见第2.2节。
IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6 packets, and vice versa. It may do "stateless" translation, meaning that there is no per-flow state required, or "stateful" translation, meaning that per-flow state is created when the first packet in a flow is received.
IPv4/IPv6转换器：将IPv4数据包转换为IPv6数据包的实体，反之亦然。它可以执行“无状态”转换，这意味着不需要每个流状态，或者“有状态”转换，这意味着在接收到流中的第一个数据包时创建每个流状态。
IPv4-translatable IPv6 addresses: IPv6 addresses assigned to IPv6 nodes for use with stateless translation. They are a variant of IPv4-embedded IPv6 addresses and follow the format described in Section 2.2.
IPv4可翻译IPv6地址：分配给IPv6节点用于无状态转换的IPv6地址。它们是IPv4嵌入式IPv6地址的变体，并遵循第2.2节中描述的格式。
Network-Specific Prefix: an IPv6 prefix assigned by an organization for use in algorithmic mapping. Options for the Network-Specific Prefix are discussed in Sections 3.3 and 3.4.
网络特定前缀：由组织分配用于算法映射的IPv6前缀。第3.3节和第3.4节讨论了网络特定前缀的选项。
Well-Known Prefix: the IPv6 prefix defined in this document for use in an algorithmic mapping.
众所周知的前缀：本文档中定义的用于算法映射的IPv6前缀。
This document reserves a "Well-Known Prefix" for use in an algorithmic mapping. The value of this IPv6 prefix is:
本文档保留了一个“众所周知的前缀”，用于算法映射。此IPv6前缀的值为：
64:ff9b::/96
64:ff9b::/96
IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses follow the same format, described here as the IPv4-embedded IPv6 address Format. IPv4-embedded IPv6 addresses are composed of a variable-length prefix, the embedded IPv4 address, and a variable-length suffix, as presented in the following diagram, in which PL designates the prefix length:
IPv4转换的IPv6地址和IPv4可转换的IPv6地址遵循相同的格式，此处描述为IPv4嵌入式IPv6地址格式。IPv4嵌入式IPv6地址由可变长度前缀、嵌入式IPv4地址和可变长度后缀组成，如下图所示，其中PL指定前缀长度：
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|32| prefix |v4(32) | u | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|40| prefix |v4(24) | u |(8)| suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|48| prefix |v4(16) | u | (16) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|56| prefix |(8)| u | v4(24) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64| prefix | u | v4(32) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|96| prefix | v4(32) |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|32| prefix |v4(32) | u | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|40| prefix |v4(24) | u |(8)| suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|48| prefix |v4(16) | u | (16) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|56| prefix |(8)| u | v4(24) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64| prefix | u | v4(32) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|96| prefix | v4(32) |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1
图1
In these addresses, the prefix shall be either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to the organization deploying the address translators. The prefixes can only have one of the following lengths: 32, 40, 48, 56, 64, or 96. (The Well-Known Prefix is 96 bits long, and can only be used in the last form of the table.)
在这些地址中，前缀应为“众所周知的前缀”或部署地址转换器的组织特有的“网络特定前缀”。前缀只能有以下长度之一：32、40、48、56、64或96。（众所周知的前缀长度为96位，只能在表的最后一种形式中使用。）
Various deployments justify different prefix lengths with Network-Specific Prefixes. The trade-off between different prefix lengths are discussed in Sections 3.3 and 3.4.
不同的部署使用特定于网络的前缀来证明不同的前缀长度。第3.3节和第3.4节讨论了不同前缀长度之间的权衡。
Bits 64 to 71 of the address are reserved for compatibility with the host identifier format defined in the IPv6 addressing architecture [RFC4291]. These bits MUST be set to zero. When using a /96 Network-Specific Prefix, the administrators MUST ensure that the bits 64 to 71 are set to zero. A simple way to achieve that is to construct the /96 Network-Specific Prefix by picking a /64 prefix, and then adding 4 octets set to zero.
地址的第64位到第71位保留为与IPv6寻址体系结构[RFC4291]中定义的主机标识符格式兼容。这些位必须设置为零。使用/96网络特定前缀时，管理员必须确保位64至71设置为零。实现这一点的一个简单方法是通过选取/64前缀，然后添加4个设置为零的八位字节来构造/96网络特定前缀。
The IPv4 address is encoded following the prefix, most significant bits first. Depending of the prefix length, the 4 octets of the address may be separated by the reserved octet "u", whose 8 bits MUST be set to zero. In particular:
IPv4地址在前缀之后编码，最高有效位在前。根据前缀长度，地址的4个八位字节可由保留八位字节“u”分隔，其8位必须设置为零。特别地：
o When the prefix is 32 bits long, the IPv4 address is encoded in positions 32 to 63.
o 当前缀长度为32位时，IPv4地址在位置32到63处编码。
o When the prefix is 40 bits long, 24 bits of the IPv4 address are encoded in positions 40 to 63, with the remaining 8 bits in position 72 to 79.
o 当前缀长度为40位时，IPv4地址的24位编码在位置40到63，其余8位编码在位置72到79。
o When the prefix is 48 bits long, 16 bits of the IPv4 address are encoded in positions 48 to 63, with the remaining 16 bits in position 72 to 87.
o 当前缀长度为48位时，IPv4地址的16位编码在位置48到63，其余16位编码在位置72到87。
o When the prefix is 56 bits long, 8 bits of the IPv4 address are encoded in positions 56 to 63, with the remaining 24 bits in position 72 to 95.
o 当前缀长度为56位时，IPv4地址的8位编码在位置56到63，其余24位编码在位置72到95。
o When the prefix is 64 bits long, the IPv4 address is encoded in positions 72 to 103.
o 当前缀长度为64位时，IPv4地址编码在位置72到103。
o When the prefix is 96 bits long, the IPv4 address is encoded in positions 96 to 127.
o 当前缀长度为96位时，IPv4地址编码在位置96到127。
There are no remaining bits, and thus no suffix, if the prefix is 96 bits long. In the other cases, the remaining bits of the address constitute the suffix. These bits are reserved for future extensions and SHOULD be set to zero. Address translators who receive IPv4- embedded IPv6 addresses where these bits are not zero SHOULD ignore the bits' value and proceed as if the bits' value were zero. (Future extensions may specify a different behavior.)
如果前缀长度为96位，则没有剩余位，因此也没有后缀。在其他情况下，地址的剩余位构成后缀。这些位是为将来的扩展保留的，应该设置为零。接收IPv4嵌入的IPv6地址（这些位不为零）的地址转换器应忽略位的值，并像位的值为零一样继续。（将来的扩展可能会指定不同的行为。）
IPv4-embedded IPv6 addresses are composed according to the following algorithm:
IPv4嵌入式IPv6地址根据以下算法组成：
o Concatenate the prefix, the 32 bits of the IPv4 address, and the suffix (if needed) to obtain a 128-bit address.
o 连接前缀、IPv4地址的32位和后缀（如果需要）以获得128位地址。
o If the prefix length is less than 96 bits, insert the null octet "u" at the appropriate position (bits 64 to 71), thus causing the least significant octet to be excluded, as documented in Figure 1.
o 如果前缀长度小于96位，则在适当的位置（位64到71）插入空八位组“u”，从而导致排除最低有效八位组，如图1所示。
The IPv4 addresses are extracted from the IPv4-embedded IPv6 addresses according to the following algorithm:
IPv4地址根据以下算法从IPv4嵌入式IPv6地址中提取：
o If the prefix is 96 bits long, extract the last 32 bits of the IPv6 address;
o 如果前缀长度为96位，则提取IPv6地址的最后32位；
o For the other prefix lengths, remove the "u" octet to obtain a 120-bit sequence (effectively shifting bits 72-127 to positions 64-119), then extract the 32 bits following the prefix.
o 对于其他前缀长度，移除“u”八位组以获得120位序列（有效地将位72-127移动到位置64-119），然后提取前缀后面的32位。
IPv4-embedded IPv6 addresses will be represented in text in conformity with Section 2.2 of [RFC4291]. IPv4-embedded IPv6 addresses constructed using the Well-Known Prefix or a /96 Network-Specific Prefix may be represented using the alternative form presented in Section 2.2 of [RFC4291], with the embedded IPv4 address represented in dotted decimal notation. Examples of such representations are presented in Tables 1 and 2.
IPv4嵌入式IPv6地址将按照[RFC4291]第2.2节以文本形式表示。使用众所周知的前缀或a/96网络特定前缀构建的IPv4嵌入式IPv6地址可使用[RFC4291]第2.2节中给出的替代形式表示，嵌入式IPv4地址以点十进制表示法表示。表1和表2中给出了此类表示的示例。
+-----------------------+------------+------------------------------+
| Network-Specific | IPv4 | IPv4-embedded IPv6 address |
| Prefix | address | |
+-----------------------+------------+------------------------------+
| 2001:db8::/32 | 192.0.2.33 | 2001:db8:c000:221:: |
| 2001:db8:100::/40 | 192.0.2.33 | 2001:db8:1c0:2:21:: |
| 2001:db8:122::/48 | 192.0.2.33 | 2001:db8:122:c000:2:2100:: |
| 2001:db8:122:300::/56 | 192.0.2.33 | 2001:db8:122:3c0:0:221:: |
| 2001:db8:122:344::/64 | 192.0.2.33 | 2001:db8:122:344:c0:2:2100:: |
| 2001:db8:122:344::/96 | 192.0.2.33 | 2001:db8:122:344::192.0.2.33 |
+-----------------------+------------+------------------------------+
+-----------------------+------------+------------------------------+
| Network-Specific | IPv4 | IPv4-embedded IPv6 address |
| Prefix | address | |
+-----------------------+------------+------------------------------+
| 2001:db8::/32 | 192.0.2.33 | 2001:db8:c000:221:: |
| 2001:db8:100::/40 | 192.0.2.33 | 2001:db8:1c0:2:21:: |
| 2001:db8:122::/48 | 192.0.2.33 | 2001:db8:122:c000:2:2100:: |
| 2001:db8:122:300::/56 | 192.0.2.33 | 2001:db8:122:3c0:0:221:: |
| 2001:db8:122:344::/64 | 192.0.2.33 | 2001:db8:122:344:c0:2:2100:: |
| 2001:db8:122:344::/96 | 192.0.2.33 | 2001:db8:122:344::192.0.2.33 |
+-----------------------+------------+------------------------------+
Table 1: Text Representation of IPv4-Embedded IPv6 Addresses Using Network-Specific Prefixes
表1：使用网络特定前缀的IPv4嵌入式IPv6地址的文本表示
+-------------------+--------------+----------------------------+
| Well-Known Prefix | IPv4 address | IPv4-Embedded IPv6 address |
+-------------------+--------------+----------------------------+
| 64:ff9b::/96 | 192.0.2.33 | 64:ff9b::192.0.2.33 |
+-------------------+--------------+----------------------------+
+-------------------+--------------+----------------------------+
| Well-Known Prefix | IPv4 address | IPv4-Embedded IPv6 address |
+-------------------+--------------+----------------------------+
| 64:ff9b::/96 | 192.0.2.33 | 64:ff9b::192.0.2.33 |
+-------------------+--------------+----------------------------+
Table 2: Text Representation of IPv4-Embedded IPv6 Addresses Using the Well-Known Prefix
表2：使用已知前缀的IPv4嵌入式IPv6地址的文本表示
The Network-Specific Prefix examples in Table 1 are derived from the IPv6 prefix reserved for documentation in [RFC3849]. The IPv4 address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for documentation in [RFC5735]. The representation of IPv6 addresses is compatible with [RFC5952].
表1中的网络特定前缀示例源自[RFC3849]中为文档保留的IPv6前缀。IPv4地址192.0.2.33是子网192.0.2.0/24的一部分，保留用于[RFC5735]中的文档。IPv6地址的表示形式与[RFC5952]兼容。
The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. Address translators MUST NOT translate packets in which an address is composed of the Well-Known Prefix and a non-global IPv4 address; they MUST drop these packets.
众所周知的前缀不得用于表示非全局IPv4地址，如[RFC1918]中定义的地址或[RFC5735]第3节中列出的地址。地址转换器不得翻译地址由已知前缀和非全局IPv4地址组成的数据包；他们必须扔掉这些包裹。
The Well-Known Prefix SHOULD NOT be used to construct IPv4- translatable IPv6 addresses. The nodes served by IPv4-translatable IPv6 addresses should be able to receive global IPv6 traffic bound to their IPv4-translatable IPv6 address without incurring intermediate protocol translation. This is only possible if the specific prefix used to build the IPv4-translatable IPv6 addresses is advertised in inter-domain routing, but the advertisement of more specific prefixes derived from the Well-Known Prefix is not supported, as explained in Section 3.2. Network-Specific Prefixes SHOULD be used in these scenarios, as explained in Section 3.3.
众所周知的前缀不应用于构造IPv4可翻译IPv6地址。由IPv4可翻译IPv6地址提供服务的节点应能够接收绑定到其IPv4可翻译IPv6地址的全局IPv6通信量，而无需进行中间协议转换。只有在域间路由中公布用于构建IPv4可翻译IPv6地址的特定前缀时，才可能出现这种情况，但如第3.2节所述，不支持公布从已知前缀派生的更特定前缀。如第3.3节所述，在这些场景中应使用特定于网络的前缀。
The Well-Known Prefix MAY be used by organizations deploying translation services, as explained in Section 3.4.
众所周知的前缀可由部署翻译服务的组织使用，如第3.4节所述。
The Well-Known Prefix MAY appear in inter-domain routing tables, if service providers decide to provide IPv6-IPv4 interconnection services to peers. Advertisement of the Well-Known Prefix SHOULD be controlled either by upstream and/or downstream service providers according to inter-domain routing policies, e.g., through
如果服务提供商决定向对等方提供IPv6-IPv4互连服务，则众所周知的前缀可能出现在域间路由表中。众所周知的前缀的广告应当由上游和/或下游服务提供商根据域间路由策略来控制，例如，通过
configuration of BGP [RFC4271]. Organizations that advertise the Well-Known Prefix in inter-domain routing MUST be able to provide IPv4/IPv6 translation service.
BGP的配置[RFC4271]。在域间路由中公布已知前缀的组织必须能够提供IPv4/IPv6转换服务。
When the IPv4/IPv6 translation relies on the Well-Known Prefix, IPv4- embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be advertised in BGP (especially External BGP) [RFC4271] because this leads to importing the IPv4 routing table into the IPv6 one and therefore introduces scalability issues to the global IPv6 routing table. Administrators of BGP nodes SHOULD configure filters that discard advertisements of embedded IPv6 prefixes longer than the Well-Known Prefix.
当IPv4/IPv6转换依赖于已知前缀时，比已知前缀长的IPv4嵌入IPv6前缀不得在BGP（特别是外部BGP）[RFC4271]中播发，因为这会导致将IPv4路由表导入IPv6路由表，从而给全局IPv6路由表带来可伸缩性问题。BGP节点的管理员应配置过滤器，以丢弃比已知前缀更长的嵌入IPv6前缀的播发。
When the IPv4/IPv6 translation service relies on Network-Specific Prefixes, the IPv4-translatable IPv6 prefixes used in stateless translation MUST be advertised with proper aggregation to the IPv6 Internet. Similarly, if translators are configured with multiple Network-Specific Prefixes, these prefixes MUST be advertised to the IPv6 Internet with proper aggregation.
当IPv4/IPv6转换服务依赖于特定于网络的前缀时，在无状态转换中使用的IPv4可翻译IPv6前缀必须通过适当的聚合发布到IPv6 Internet。类似地，如果转换器配置有多个特定于网络的前缀，则必须通过适当的聚合将这些前缀播发到IPv6 Internet。
Organizations may deploy translation services using stateless translation. In these deployments, internal IPv6 nodes are addressed using IPv4-translatable IPv6 addresses, which enable them to be accessed by IPv4 nodes. The addresses of these external IPv4 nodes are then represented in IPv4-converted IPv6 addresses.
组织可以使用无状态翻译部署翻译服务。在这些部署中，内部IPv6节点使用IPv4可翻译IPv6地址寻址，从而使IPv4节点能够访问这些节点。这些外部IPv4节点的地址随后以IPv4转换的IPv6地址表示。
Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix to their IPv4/IPv6 translation service. IPv4-translatable and IPv4-converted IPv6 addresses MUST be constructed as specified in Section 2.2. IPv4-translatable IPv6 addresses MUST use the selected Network-Specific Prefix. Both IPv4- translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix.
部署无状态IPv4/IPv6转换的组织应为其IPv4/IPv6转换服务分配特定于网络的前缀。IPv4可翻译和IPv4转换的IPv6地址必须按照第2.2节的规定构造。IPv4可翻译IPv6地址必须使用选定的网络特定前缀。IPv4可翻译IPv6地址和IPv4转换IPv6地址应使用相同的前缀。
Using the same prefix ensures that IPv6 nodes internal to the organization will use the most efficient paths to reach the nodes served by IPv4-translatable IPv6 addresses. Specifically, if a node learns the IPv4 address of a target internal node without knowing that this target is in fact located behind the same translator that the node also uses, translation rules will ensure that the IPv6 address constructed with the Network-Specific Prefix is the same as the IPv4-translatable IPv6 address assigned to the target. Standard routing preference (i.e., "most specific match wins") will then ensure that the IPv6 packets are delivered directly, without requiring that translators receive the packets and then return them in the direction from which they came.
使用相同的前缀可确保组织内部的IPv6节点将使用最有效的路径到达IPv4可翻译IPv6地址所服务的节点。具体地说，如果节点在不知道该目标实际上位于该节点也使用的同一转换器后面的情况下了解目标内部节点的IPv4地址，则转换规则将确保使用网络特定前缀构造的IPv6地址与分配给目标的IPv4可翻译IPv6地址相同。然后，标准路由首选项（即“最特定的匹配获胜”）将确保直接交付IPv6数据包，而无需翻译人员接收数据包，然后按照数据包发出的方向返回数据包。
The intra-domain routing protocol must be able to deliver packets to the nodes served by IPv4-translatable IPv6 addresses. This may require routing on some or all of the embedded IPv4 address bits. Security considerations detailed in Section 5 require that routers check the validity of the IPv4-translatable IPv6 source addresses, using some form of reverse path check.
域内路由协议必须能够将数据包传送到由IPv4可翻译IPv6地址服务的节点。这可能需要在部分或全部嵌入式IPv4地址位上进行路由。第5节详述的安全注意事项要求路由器使用某种形式的反向路径检查来检查IPv4可翻译IPv6源地址的有效性。
The management of stateless address translation can be illustrated with a small example:
无状态地址转换的管理可以用一个小例子来说明：
We will consider an IPv6 network with the prefix 2001:db8: 122::/48. The network administrator has selected the Network-Specific Prefix 2001:db8:122:344::/64 for managing stateless IPv4/ IPv6 translation. The IPv4-translatable address block for IPv4 subnet 192.0.2.0/24 is 2001:db8:122:344:c0:2::/96. In this network, the host A is assigned the IPv4-translatable IPv6 address 2001:db8:122:344:c0:2:2100::, which corresponds to the IPv4 address 192.0.2.33. Host A's address is configured either manually or through DHCPv6.
我们将考虑具有前缀2001：d8：122：：/ 48的IPv6网络。网络管理员已选择网络特定前缀2001:db8:122:344:：/64来管理无状态IPv4/IPv6转换。IPv4子网192.0.2.0/24的IPv4可翻译地址块为2001:db8:122:344:c0:2:：/96。在此网络中，向主机A分配IPv4可翻译IPv6地址2001:db8:122:344:c0:2:2100:：，该地址对应于IPv4地址192.0.2.33。主机A的地址可以手动配置，也可以通过DHCPv6配置。
In this example, host A is not directly connected to the translator, but instead to a link managed by a router R. The router R is configured to forward to A the packets bound to 2001: db8:122:344:c0:2:2100::. To receive these packets, R will advertise reachability of the prefix 2001:db8:122:344:c0:2:2100::/ 104 in the intra-domain routing protocol -- or perhaps a shorter prefix if many hosts on link have IPv4-translatable IPv6 addresses derived from the same IPv4 subnet. If a packet bound to 192.0.2.33 reaches the translator, the destination address will be translated to 2001:db8:122:344:c0:2:2100::, and the packet will be routed towards R and then to A.
在此示例中，主机A不直接连接到转换器，而是连接到由路由器R管理的链路。路由器R配置为将绑定到2001:db8:122:344:c0:2:2100:的数据包转发到转换器。为了接收这些数据包，R将公布域内路由协议中前缀2001:db8:122:344:c0:2:2100:：/104的可达性——或者，如果链路上的许多主机具有从同一IPv4子网派生的IPv4可翻译IPv6地址，则可能是更短的前缀。如果绑定到192.0.2.33的数据包到达转换器，则目标地址将转换为2001:db8:122:344:c0:2:2100:：，数据包将路由到R，然后路由到a。
Let's suppose now that a host B of the same domain learns the IPv4 address of A, maybe through an application-specific referral. If B has translation-aware software, B can compose a destination address by combining the Network-Specific Prefix 2001:db8:122: 344::/64 and the IPv4 address 192.0.2.33, resulting in the address 2001:db8:122:344:c0:2:2100::. The packet sent by B will be forwarded towards R, and then to A, avoiding protocol translation.
现在让我们假设同一域的主机B可能通过特定于应用程序的引用来学习a的IPv4地址。如果B有翻译感知软件，B可以通过组合特定于网络的前缀2001:db8:122:344:：/64和IPv4地址192.0.2.33组成目标地址，从而生成地址2001:db8:122:344:c0:2:2100:：。B发送的数据包将转发到R，然后转发到A，避免协议转换。
Forwarding, and reverse path checks, are more efficient when performed on the combination of the prefix and the IPv4 address. In theory, routers are able to route on prefixes of any length, but in practice there may be routers for which routing on prefixes larger than 64 bits is slower. However, routing efficiency is not the only consideration in the choice of a prefix length. Organizations also need to consider the availability of prefixes, and the potential impact of all-zero identifiers.
当对前缀和IPv4地址的组合执行转发和反向路径检查时，效率更高。理论上，路由器可以在任何长度的前缀上进行路由，但在实践中，可能有一些路由器在大于64位的前缀上的路由速度较慢。然而，在选择前缀长度时，路由效率并不是唯一的考虑因素。组织还需要考虑前缀的可用性以及所有零标识符的潜在影响。
If a /32 prefix is used, all the routing bits are contained in the top 64 bits of the IPv6 address, leading to excellent routing properties. These prefixes may however be hard to obtain, and allocation of a /32 to a small set of IPv4-translatable IPv6 addresses may be seen as wasteful. In addition, the /32 prefix and a zero suffix lead to an all-zero interface identifier, which is an issue that we discuss in Section 4.1.
如果使用/32前缀，则所有路由位都包含在IPv6地址的前64位中，从而产生出色的路由属性。然而，这些前缀可能很难获得，将a/32分配给一小部分IPv4可翻译IPv6地址可能会被视为浪费。此外，/32前缀和零后缀导致全零接口标识符，这是我们在第4.1节中讨论的问题。
Intermediate prefix lengths such as /40, /48, or /56 appear as compromises. Only some of the IPv4 bits are part of the /64 prefixes. Reverse path checks, in particular, may have a limited efficiency. Reverse path checks limited to the most significant bits of the IPv4 address will reduce the possibility of spoofing external IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4- translatable IPv6 addresses.
中间前缀长度（如/40、/48或/56）显示为折衷值。只有部分IPv4位是/64前缀的一部分。特别是反向路径检查的效率可能有限。限制在IPv4地址最高有效位的反向路径检查将减少欺骗外部IPv4地址的可能性，但将允许IPv6节点欺骗内部IPv4可翻译IPv6地址。
We propose a compromise, based on using no more than 1/256th of an organization's allocation of IPv6 addresses for the IPv4/IPv6 translation service. For example, if the organization is an Internet Service Provider with an allocated IPv6 prefix /32 or shorter, the ISP could dedicate a /40 prefix to the translation service. An end site with a /48 allocation could dedicate a /56 prefix to the translation service, or possibly a /96 prefix if all IPv4- translatable IPv6 addresses are located on the same link.
我们提出了一种折衷方案，即在IPv4/IPv6转换服务中使用不超过组织IPv6地址分配的1/256。例如，如果组织是具有分配的IPv6前缀/32或更短的Internet服务提供商，则ISP可以将/40前缀专用于翻译服务。具有/48分配的终端站点可以将/56前缀专用于翻译服务，或者如果所有IPv4可翻译IPv6地址都位于同一链路上，则可能使用/96前缀。
The recommended prefix length is also a function of the deployment scenario. The stateless translation can be used for Scenario 1, Scenario 2, Scenario 5, and Scenario 6 defined in [v4v6-FRAMEWORK]. For different scenarios, the prefix length recommendations are:
建议的前缀长度也是部署场景的一个函数。无状态转换可用于[v4v6框架]中定义的场景1、场景2、场景5和场景6。对于不同的场景，前缀长度建议如下：
o For Scenario 1 (an IPv6 network to the IPv4 Internet) and Scenario 2 (the IPv4 Internet to an IPv6 network), an ISP holding a /32 allocation SHOULD use a /40 prefix, and a site holding a /48 allocation SHOULD use a /56 prefix.
o 对于方案1（IPv6网络到IPv4互联网）和方案2（IPv4互联网到IPv6网络），持有/32分配的ISP应使用/40前缀，持有/48分配的站点应使用/56前缀。
o For Scenario 5 (an IPv6 network to an IPv4 network) and Scenario 6 (an IPv4 network to an IPv6 network), the deployment SHOULD use a /64 or a /96 prefix.
o 对于方案5（IPv6网络到IPv4网络）和方案6（IPv4网络到IPv6网络），部署应使用/64或/96前缀。
Organizations may deploy translation services based on stateful translation technology. An organization may decide to use either a Network-Specific Prefix or the Well-Known Prefix for its stateful IPv4/IPv6 translation service.
组织可以部署基于有状态翻译技术的翻译服务。组织可能决定为其有状态IPv4/IPv6转换服务使用网络特定前缀或众所周知的前缀。
When these services are used, IPv6 nodes are addressed through standard IPv6 addresses, while IPv4 nodes are represented by IPv4- converted IPv6 addresses, as specified in Section 2.2.
使用这些服务时，IPv6节点通过标准IPv6地址寻址，而IPv4节点由IPv4转换的IPv6地址表示，如第2.2节所述。
The stateful nature of the translation creates a potential stability issue when the organization deploys multiple translators. If several translators use the same prefix, there is a risk that packets belonging to the same connection may be routed to different translators as the internal routing state changes. This issue can be avoided either by assigning different prefixes to different translators or by ensuring that all translators using the same prefix coordinate their state.
当组织部署多个翻译人员时，翻译的状态性质会产生潜在的稳定性问题。如果多个转换器使用相同的前缀，则随着内部路由状态的更改，属于同一连接的数据包可能会被路由到不同的转换器。可以通过为不同的翻译人员分配不同的前缀或确保使用相同前缀的所有翻译人员协调其状态来避免此问题。
Stateful translation can be used in scenarios defined in [v4v6-FRAMEWORK]. The Well-Known Prefix SHOULD be used in these scenarios, with two exceptions:
有状态转换可用于[v4v6框架]中定义的场景。在这些场景中应使用众所周知的前缀，但有两个例外：
o In all scenarios, the translation MAY use a Network-Specific Prefix, if deemed appropriate for management reasons.
o 在所有情况下，如果出于管理原因认为合适，翻译可以使用特定于网络的前缀。
o The Well-Known Prefix MUST NOT be used for Scenario 3 (the IPv6 Internet to an IPv4 network), as this would lead to using the Well-Known Prefix with non-global IPv4 addresses. That means a Network-Specific Prefix (for example, a /96 prefix) MUST be used in that scenario.
o 众所周知的前缀不得用于场景3（IPv6 Internet到IPv4网络），因为这将导致将众所周知的前缀与非全局IPv4地址一起使用。这意味着在该场景中必须使用特定于网络的前缀（例如，a/96前缀）。
The prefix that we have chosen reflects two design choices, the null suffix and the specific value of the Well-Known Prefix. We provide here a summary of the discussions leading to those two choices.
我们选择的前缀反映了两种设计选择，空后缀和已知前缀的特定值。我们在此提供导致这两种选择的讨论摘要。
The address format described in Section 2.2 recommends a zero suffix. Before making this recommendation, we considered different options: checksum neutrality, the encoding of a port range, and a value different than 0.
第2.2节中描述的地址格式建议使用零后缀。在提出此建议之前，我们考虑了不同的选项：校验和中立性、端口范围的编码以及不同于0的值。
In the case of stateless translation, there would be no need for the translator to recompute a one's complement checksum if both the IPv4- translatable and the IPv4-converted IPv6 addresses were constructed in a "checksum-neutral" manner, that is, if the IPv6 addresses would have the same one's complement checksum as the embedded IPv4 address. In the case of stateful translation, checksum neutrality does not eliminate checksum computation during translation, as only one of the two addresses would be checksum neutral. We considered reserving 16 bits in the suffix to guarantee checksum neutrality, but declined
在无状态转换的情况下，如果IPv4可翻译和IPv4转换的IPv6地址都是以“校验和中性”的方式构造的，也就是说，如果IPv6地址与嵌入的IPv4地址具有相同的补码校验和，则转换器将不需要重新计算补码校验和。在有状态转换的情况下，校验和中性不会消除转换期间的校验和计算，因为两个地址中只有一个是校验和中性的。我们考虑在后缀中保留16位以保证校验和中立性，但拒绝了
because it would not help with stateful translation and because checksum neutrality can also be achieved by an appropriate choice of the Network-Specific Prefix, i.e., selecting a prefix whose one's complement checksum equals either 0 or 0xffff.
因为它对有状态转换没有帮助，而且校验和中立性也可以通过适当选择特定于网络的前缀来实现，即选择一个其补码校验和等于0或0xffff的前缀。
There have been proposals to complement stateless translation with a port-range feature. Instead of mapping an IPv4 address to exactly one IPv6 prefix, the options would allow several IPv6 nodes to share an IPv4 address, with each node managing a different range of ports. If a port range extension is needed, it could be defined later, using bits currently reserved as null in the suffix.
有人建议使用端口范围功能来补充无状态转换。这些选项将允许多个IPv6节点共享一个IPv4地址，而不是将IPv4地址映射到一个IPv6前缀，每个节点管理不同范围的端口。如果需要端口范围扩展，可以稍后使用后缀中当前保留为null的位来定义。
When a /32 prefix is used, an all-zero suffix results in an all-zero interface identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet-router anycast address. However, in our specification, there is only one node with an IPv4-translatable IPv6 address in the /64 subnet, so the anycast semantic does not create confusion. We thus decided to keep the null suffix for now. This issue does not exist for prefixes larger than 32 bits, such as the /40, /56, /64, and /96 prefixes that we recommend in Section 3.3.
使用/32前缀时，全零后缀将产生全零接口标识符。我们理解与RFC4291第2.6.1节的冲突，该节规定所有零用于子网路由器选播地址。但是，在我们的规范中，/64子网中只有一个节点具有IPv4可翻译IPv6地址，因此选播语义不会造成混淆。因此，我们决定暂时保留空后缀。对于大于32位的前缀，例如我们在第3.3节中推荐的/40、/56、/64和/96前缀，不存在此问题。
Before making our recommendation of the Well-Known Prefix, we were faced with three choices:
在推荐知名前缀之前，我们面临三个选择：
o reuse the IPv4-mapped prefix, ::ffff:0:0/96, as specified in RFC 2765, Section 2.1;
o 按照RFC 2765第2.1节的规定，重用IPv4映射前缀：ffff:0:0/96；
o request IANA to allocate a /32 prefix, or
o 请求IANA分配/32前缀，或
o request allocation of a new /96 prefix.
o 请求分配新的/96前缀。
We weighted the pros and cons of these choices before settling on the recommended /96 Well-Known Prefix.
在确定推荐的/96众所周知的前缀之前，我们权衡了这些选择的利弊。
The main advantage of the existing IPv4-mapped prefix is that it is already defined. Reusing that prefix would require minimal standardization efforts. However, being already defined is not just an advantage, as there may be side effects of current implementations. When presented with the IPv4-mapped prefix, current versions of Windows and Mac OS generate IPv4 packets, but will not send IPv6 packets. If we used the IPv4-mapped prefix, these nodes would not be able to support translation without modification. This will defeat the main purpose of the translation techniques. We thus eliminated the first choice, i.e., decided to not reuse the IPv4- mapped prefix, ::ffff:0:0/96.
现有IPv4映射前缀的主要优点是它已经定义。重用该前缀将需要最少的标准化工作。然而，已经定义并不仅仅是一个优势，因为当前实现可能会有副作用。当显示IPv4映射前缀时，当前版本的Windows和Mac OS会生成IPv4数据包，但不会发送IPv6数据包。如果我们使用IPv4映射前缀，这些节点将无法支持未经修改的转换。这将破坏翻译技巧的主要目的。因此，我们排除了第一种选择，即决定不重用IPv4映射的前缀：：ffff:0:0/96。
A /32 prefix would have allowed the embedded IPv4 address to fit within the top 64 bits of the IPv6 address. This would have facilitated routing and load balancing when an organization deploys several translators. However, such destination-address-based load balancing may not be desirable. It is not compatible with Session Traversal Utilities for NAT (STUN) [RFC5389] in the deployments involving multiple stateful translators, each one having a different pool of IPv4 addresses. STUN compatibility would only be achieved if the translators managed the same pool of IPv4 addresses and were able to coordinate their translation state, in which case there is no big advantage to using a /32 prefix rather than a /96 prefix.
32前缀将允许嵌入的IPv4地址位于IPv6地址的前64位。当一个组织部署多个翻译器时，这将有助于路由和负载平衡。然而，这种基于目的地地址的负载平衡可能并不可取。在涉及多个有状态转换器的部署中，它与NAT（STUN）[RFC5389]的会话遍历实用程序不兼容，每个转换器具有不同的IPv4地址池。只有当翻译人员管理相同的IPv4地址池并能够协调其翻译状态时，才能实现STUN兼容性，在这种情况下，使用/32前缀而不是/96前缀没有太大的优势。
According to Section 2.2 of [RFC4291], in the legal textual representations of IPv6 addresses, dotted decimal can only appear at the end. The /96 prefix is compatible with that requirement. It enables the dotted decimal notation without requiring an update to [RFC4291]. This representation makes the address format easier to use and the log files easier to read.
根据[RFC4291]第2.2节，在IPv6地址的合法文本表示中，点十进制只能出现在末尾。/96前缀与该要求兼容。它不需要更新[RFC4291]即可启用点十进制表示法。这种表示方式使地址格式更易于使用，日志文件更易于读取。
The prefix that we recommend has the particularity of being "checksum neutral". The sum of the hexadecimal numbers "0064" and "ff9b" is "ffff", i.e., a value equal to zero in one's complement arithmetic. An IPv4-embedded IPv6 address constructed with this prefix will have the same one's complement checksum as the embedded IPv4 address.
我们推荐的前缀具有“校验和中性”的特殊性。十六进制数“0064”和“ff9b”之和为“ffff”，即在补码运算中等于零的值。使用此前缀构造的IPv4嵌入式IPv6地址将具有与嵌入式IPv4地址相同的补码校验和。
IPv4/IPv6 translators can be modeled as special routers, are subject to the same risks, and can implement the same mitigations. (The discussion of generic threats to routers and their mitigations is beyond the scope of this document.) There is, however, a particular risk that directly derives from the practice of embedding IPv4 addresses in IPv6: address spoofing.
IPv4/IPv6转换器可以建模为特殊路由器，承受相同的风险，并且可以实施相同的缓解措施。（对路由器的一般威胁及其缓解措施的讨论超出了本文档的范围。）但是，在IPv6中嵌入IPv4地址的做法直接产生了一种特殊的风险：地址欺骗。
An attacker could use an IPv4-embedded IPv6 address as the source address of malicious packets. After translation, the packets will appear as IPv4 packets from the specified source, and the attacker may be hard to track. If left without mitigation, the attack would allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
攻击者可以使用IPv4嵌入式IPv6地址作为恶意数据包的源地址。转换后，数据包将显示为来自指定源的IPv4数据包，攻击者可能难以跟踪。如果不采取缓解措施，攻击将允许恶意IPv6节点欺骗任意IPv4地址。
The mitigation is to implement reverse path checks and to verify throughout the network that packets are coming from an authorized location.
缓解措施是实施反向路径检查，并在整个网络中验证数据包是否来自授权位置。
The prefixes used for address translation are used by IPv6 nodes to send packets to IPv6/IPv4 translators. Attackers could attempt to fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong values for these parameters, resulting in network disruption, denial of service, and possible information disclosure. To mitigate such attacks, network administrators need to ensure that prefixes are configured in a secure way.
IPv6节点使用用于地址转换的前缀向IPv6/IPv4转换器发送数据包。攻击者可能试图欺骗节点、DNS网关和IPv4/IPv6转换器为这些参数使用错误的值，从而导致网络中断、拒绝服务和可能的信息泄露。为了减轻此类攻击，网络管理员需要确保以安全的方式配置前缀。
The mechanisms for achieving secure configuration of prefixes are beyond the scope of this document.
实现前缀安全配置的机制超出了本文档的范围。
Many firewalls and other security devices filter traffic based on IPv4 addresses. Attackers could attempt to fool these firewalls by sending IPv6 packets to or from IPv6 addresses that translate to the filtered IPv4 addresses. If the attack is successful, traffic that was previously blocked might be able to pass through the firewalls disguised as IPv6 packets. In all such scenarios, administrators should assure that packets that send to or from IPv4-embedded IPv6 addresses are subject to the same filtering as those directly sent to or from the embedded IPv4 addresses.
许多防火墙和其他安全设备根据IPv4地址过滤流量。攻击者可以通过向IPv6地址发送IPv6数据包或从IPv6地址发送IPv6数据包，这些地址转换为过滤后的IPv4地址，从而试图愚弄这些防火墙。如果攻击成功，以前被阻止的流量可能会伪装成IPv6数据包通过防火墙。在所有此类场景中，管理员应确保发送到IPv4嵌入式IPv6地址或从IPv4嵌入式IPv6地址发送的数据包受到与直接发送到或从嵌入式IPv4地址发送的数据包相同的过滤。
The mechanisms for configuring firewalls and security devices to achieve this filtering are beyond the scope of this document.
配置防火墙和安全设备以实现此过滤的机制超出了本文档的范围。
IANA has made the following changes in the "Internet Protocol Version 6 Address Space" registry located at http://www.iana.org.
IANA在位于的“Internet协议版本6地址空间”注册表中进行了以下更改：http://www.iana.org.
OLD:
旧的：
IPv6 Prefix Allocation Reference Note
----------- ---------------- ------------ ----------------
0000::/8 Reserved by IETF [RFC4291] [1][5]
IPv6 Prefix Allocation Reference Note
----------- ---------------- ------------ ----------------
0000::/8 Reserved by IETF [RFC4291] [1][5]
NEW:
新的：
IPv6 Prefix Allocation Reference Note
----------- ---------------- ------------ ----------------
0000::/8 Reserved by IETF [RFC4291] [1][5][6]
IPv6 Prefix Allocation Reference Note
----------- ---------------- ------------ ----------------
0000::/8 Reserved by IETF [RFC4291] [1][5][6]
[6] The "Well-Known Prefix" 64:ff9b::/96 used in an algorithmic mapping between IPv4 to IPv6 addresses is defined out of the 0000::/8 address block, per RFC 6052.
[6] 根据RFC 6052，在IPv4到IPv6地址之间的算法映射中使用的“众所周知的前缀”64:ff9b:：/96在0000:：/8地址块中定义。
Many people in the BEHAVE WG have contributed to the discussion that led to this document, including Andrew Sullivan, Andrew Yourtchenko, Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler, David Harrington, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-Courmont, Remi Despres, and William Waites.
BEHAVE工作组中的许多人都参与了本文件的讨论，包括安德鲁·沙利文、安德鲁·尤琴科、阿里·凯拉宁、布赖恩·卡彭特、查理·考夫曼、丹·温、戴夫·泰勒、大卫·哈灵顿、埃德·扬基维茨、弗雷德·贝克、宫田广史、伊尔吉奇·凡·贝南姆、约翰·施尼兹林、基思·摩尔、凯文·尹、马格纳斯·韦斯特隆德、，Margaret Wasserman、Masahito Endo、Phil Roberts、Philip Matthews、Remi Denis Courmont、Remi Despres和William Waites。
Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
Marcelo Bagnulo的部分资金来自Trilogy，这是一个由欧盟委员会第七个框架计划支持的研究项目。
The following individuals co-authored documents from which text has been incorporated, and are listed in alphabetical order.
以下个人共同编写了文档，其中包含文本，并按字母顺序列出。
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond，WA 98052美国电话：+1 425 703 8835电子邮件：dthaler@microsoft.com
Fred Baker Cisco Systems Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com
Fred Baker Cisco Systems Santa Barbara，California 93117美国电话：+1-408-526-4257传真：+1-413-473-2403电子邮件：fred@cisco.com
Hiroshi Miyata Yokogawa Electric Corporation 2-9-32 Nakacho Musashino-shi, Tokyo 180-8750 JAPAN EMail: h.miyata@jp.yokogawa.com
Miyata Hiroshi Yokogawa Electric Corporation 2-9-32 Nakacho Musashino shi，东京180-8750日本电子邮件：h。miyata@jp.yokogawa.com
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[DNS64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", Work in Progress, October 2010.
[DNS64]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，正在进行的工作，2010年10月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
[RFC3849]Huston，G.，Lord，A.，和P.Smith，“为文档保留IPv6地址前缀”，RFC 3849，2004年7月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]Cotton，M.和L.Vegoda，“特殊用途IPv4地址”，BCP 153，RFC 57352010年1月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[v4v6-FRAMEWORK] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", Work in Progress, August 2010.
[v4v6框架]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，正在进行的工作，2010年8月。
Authors' Addresses
作者地址
Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China Phone: +86 10-62785983 EMail: congxiao@cernet.edu.cn
聪晓宝CERNET中心/清华大学主楼225室，北京，100084中国电话：+86 10-62785983电子邮件：congxiao@cernet.edu.cn
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 U.S.A. EMail: huitema@microsoft.com
Christian Huitema Microsoft Corporation One Microsoft Way Redmond，WA 98052-6399美国电子邮件：huitema@microsoft.com
Marcelo Bagnulo UC3M Av. Universidad 30 Leganes, Madrid 28911 Spain Phone: +34-91-6249500 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es/marcelo
马塞洛·巴格努洛UC3M Av。马德里勒加内斯30大学28911西班牙电话：+34-91-6249500电子邮件：marcelo@it.uc3m.esURI:http://www.it.uc3m.es/marcelo
Mohamed Boucadair France Telecom 3, Av Francois Chateaux Rennes 350000 France EMail: mohamed.boucadair@orange-ftgroup.com
Mohamed Boucadair法国电信3，Av Francois Chateaux Rennes 350000法国电子邮件：Mohamed。boucadair@orange-ftgroup.com
Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China Phone: +86 10-62785983 EMail: xing@cernet.edu.cn
兴利CERNET中心/清华大学主楼225室，北京，100084中国电话：+86 10-62785983电子邮件：xing@cernet.edu.cn