Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 7225 France Telecom
Category: Standards Track May 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 7225 France Telecom
Category: Standards Track May 2014
ISSN: 2070-1721
Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)
使用端口控制协议（PCP）发现NAT64 IPv6前缀
Abstract
摘要
This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This option is needed for successful communications when IPv4 addresses are used in referrals.
本文档定义了一个新的端口控制协议（PCP）选项，以了解PCP控制的NAT64设备用于构建IPv4转换的IPv6地址的IPv6前缀。在转介中使用IPv4地址时，成功通信需要此选项。
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/rfc7225.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7225.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.1. AAAA Synthesis by the DNS Stub-resolver . . . . . . . 4
3.2.2. Application Referrals . . . . . . . . . . . . . . . . 4
4. PREFIX64 Option . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Server's Behavior . . . . . . . . . . . . . . . . . . . . 7
4.3. Client's Behavior . . . . . . . . . . . . . . . . . . . . 9
5. Flow Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. TCP Session Initiated from an IPv6-only Host . . . . . . 10
5.2. SIP Flow Example . . . . . . . . . . . . . . . . . . . . 11
5.3. Mapping of IPv4 Address Ranges to IPv6 Prefixes . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.1. AAAA Synthesis by the DNS Stub-resolver . . . . . . . 4
3.2.2. Application Referrals . . . . . . . . . . . . . . . . 4
4. PREFIX64 Option . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Server's Behavior . . . . . . . . . . . . . . . . . . . . 7
4.3. Client's Behavior . . . . . . . . . . . . . . . . . . . . 9
5. Flow Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. TCP Session Initiated from an IPv6-only Host . . . . . . 10
5.2. SIP Flow Example . . . . . . . . . . . . . . . . . . . . 11
5.3. Mapping of IPv4 Address Ranges to IPv6 Prefixes . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
According to [RFC6146], NAT64 uses Pref64::/n to construct IPv4-converted IPv6 addresses as defined in [RFC6052].
根据[RFC6146]，NAT64使用Pref64:：/n构造[RFC6052]中定义的IPv4转换IPv6地址。
This document defines a new Port Control Protocol (PCP) option [RFC6887] to inform PCP clients about the Pref64::/n and suffix [RFC6052] used by a PCP-controlled NAT64 device [RFC6146]. It does so by defining a new PREFIX64 option.
本文档定义了一个新的端口控制协议（PCP）选项[RFC6887]，用于通知PCP客户端PCP控制的NAT64设备[RFC6146]使用的Pref64:：/n和后缀[RFC6052]。它通过定义一个新的PREFIX64选项来实现。
This PCP option is a deterministic solution to help establish communications between IPv6-only hosts and remote IPv4-only hosts. Unlike [RFC7050], this option solves all the issues identified in [RFC7051].
此PCP选项是一个确定性解决方案，可帮助在仅IPv6主机和仅远程IPv4主机之间建立通信。与[RFC7050]不同，此选项解决了[RFC7051]中确定的所有问题。
Some illustrative examples are provided in Section 5. Detailed experiments conducted to assess the applicability of the PREFIX64 option for services (e.g., accessing a video server, establishing SIP-based sessions, etc.) in NAT64 environments are available in [EXPERIMENTS].
第5节提供了一些示例。为评估PREFIX64选项对NAT64环境中的服务（例如，访问视频服务器、建立基于SIP的会话等）的适用性而进行的详细实验可在[实验]中找到。
The use of this PCP option for NAT64 load-balancing purposes is out of scope.
将此PCP选项用于NAT64负载平衡超出范围。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This document proposes a deterministic solution to solve the following issues:
本文件提出了解决以下问题的确定性解决方案：
o Learn the Pref64::/n used by an upstream NAT64 function. This is needed to help: * distinguish between IPv4-converted IPv6 addresses [RFC6052] and native IPv6 addresses. * implement IPv6 address synthesis for applications not relying on DNS (where DNS64 [RFC6147] would provide the synthesis).
o 了解上游NAT64函数使用的Pref64:：/n。这有助于：*区分IPv4转换的IPv6地址[RFC6052]和本机IPv6地址。*为不依赖DNS的应用程序实现IPv6地址合成（其中DNS64[RFC6147]将提供合成）。
o Avoid stale Pref64::/n values.
o 避免过时的Pref64:：/n值。
o Discover multiple Pref64::/n values when multiple prefixes exist in a network.
o 当网络中存在多个前缀时，查找多个Pref64:：/n值。
o Use DNSSEC ([RFC4033], [RFC4034], [RFC4035]) in the presence of NAT64.
o 在NAT64在场的情况下使用DNSSEC（[RFC4033]、[RFC4034]、[RFC4035]）。
o Discover the suffix used by a NAT64 function when non-null suffixes are in use (e.g., checksum neutral suffix).
o 发现NAT64函数在使用非空后缀时使用的后缀（例如，校验和中性后缀）。
o Support destination-based Pref64::/n (e.g., Section 5.1 of [RFC7050]).
o 支持基于目的地的Pref64:：/n（例如，[RFC7050]的第5.1节）。
o Associate a Pref64::/n with a given NAT64 when distinct prefixes are configured for each NAT64 enabled in a network.
o 为网络中启用的每个NAT64配置不同前缀时，将Pref64:：/n与给定NAT64关联。
A more extensive discussion can be found at [RFC7051].
更广泛的讨论见[RFC7051]。
This section provides some use cases to illustrate the problem space. More details can be found at Section 4 of [RFC7051].
本节提供一些用例来说明问题空间。更多详情见[RFC7051]第4节。
The option defined in this document can be used for hosts with DNS64 capability [RFC6147] added to the host's stub-resolver.
本文档中定义的选项可用于主机的存根解析器中添加了DNS64功能[RFC6147]的主机。
The stub resolver on the host will try to obtain (native) AAAA records, and if they are not found, the DNS64 function on the host will query for A records and then synthesize AAAA records. Using the PREFIX64 PCP extension, the host's stub-resolver can learn the prefix used for IPv6/IPv4 translation and synthesize AAAA records accordingly.
主机上的存根解析程序将尝试获取（本机）AAAA记录，如果未找到这些记录，主机上的DNS64函数将查询A记录，然后合成AAAA记录。使用PREFIX64 PCP扩展，主机的存根解析器可以学习用于IPv6/IPv4转换的前缀，并相应地合成AAAA记录。
Because synthetic AAAA records cannot be successfully validated in a host, learning the Pref64::/n used to construct IPv4-converted IPv6 addresses allows the use of DNSSEC. As discussed in Section 5.5 of [RFC6147], a security-aware and validating host has to perform the DNS64 function locally.
由于无法在主机中成功验证合成AAAA记录，因此学习用于构造IPv4转换IPv6地址的Pref64:：/n允许使用DNSSEC。如[RFC6147]第5.5节所述，安全感知和验证主机必须在本地执行DNS64功能。
As discussed in [REF-OBJECT], a frequently occurring situation is that one entity A connected to a network needs to inform another entity B how to reach either A itself or some third-party entity C. This is known as address referral.
如[REF-OBJECT]中所述，经常发生的情况是，连接到网络的一个实体a需要通知另一个实体B如何到达a本身或某个第三方实体C。这称为地址参考。
In the particular context of NAT64 [RFC6146], applications relying on address referral will fail because an IPv6-only client won't be able to make use of an IPv4 address received in a referral. A non-exhaustive list of such applications is provided below:
在NAT64[RFC6146]的特定上下文中，依赖地址引用的应用程序将失败，因为仅限IPv6的客户端将无法使用在引用中接收到的IPv4地址。下文提供了此类申请的非详尽清单：
o In SIP environments [RFC3261], the SDP part ([RFC4566]) of exchanged SIP messages includes information required for establishing RTP sessions (namely, IP address and port number). When a NAT64 is involved in the path, an IPv6-only SIP User Agent (UA) that receives an SDP offer/answer containing an IPv4 address cannot send media streams to the remote endpoint.
o 在SIP环境[RFC3261]中，交换的SIP消息的SDP部分（[RFC4566]）包括建立RTP会话所需的信息（即IP地址和端口号）。当路径中涉及NAT64时，接收包含IPv4地址的SDP提供/应答的仅限IPv6的SIP用户代理（UA）无法向远程端点发送媒体流。
o An IPv6-only WebRTC (Web Real-Time Communication [WebRTC]) agent cannot make use of an IPv4 address received in referrals to establish a successful session with a remote IPv4-only WebRTC agent.
o 仅限IPv6的WebRTC（Web实时通信[WebRTC]）代理无法使用在引用中接收到的IPv4地址与仅限IPv4的远程WebRTC代理建立成功的会话。
o BitTorrent is a distributed file-sharing infrastructure that is based on peer-to-peer (P2P) techniques for exchanging files between connected users. To download a given file, a BitTorrent client needs to obtain the corresponding torrent file. Then, it connects to a tracker to retrieve a list of "leechers" (clients that are currently downloading the file but do not yet possess all
o BitTorrent是一种分布式文件共享基础设施，它基于对等（P2P）技术，用于在连接的用户之间交换文件。要下载给定文件，BitTorrent客户端需要获得相应的torrent文件。然后，它连接到一个跟踪器来检索“leechers”列表（当前正在下载文件但尚未拥有所有文件的客户端）
portions of the file) and "seeders" (clients that possess all portions of the file and are uploading them to other requesting clients). The client connects to those machines and downloads the available portions of the requested file. In the presence of an address-sharing function (see Appendix A of [RFC6269]), some encountered issues are solved if PCP is enabled (see [PCP-BITTORRENT]). Nevertheless, an IPv6-only client cannot connect to a remote IPv4-only machine even if the base PCP protocol is used.
部分文件）和“播种器”（拥有文件所有部分并正在将其上载到其他请求客户端的客户端）。客户端连接到这些机器并下载请求文件的可用部分。在存在地址共享功能的情况下（参见[RFC6269]的附录A），如果启用了PCP（参见[PCP-BITTORRENT]），则会解决一些遇到的问题。但是，即使使用基本PCP协议，仅IPv6客户端也无法连接到仅IPv4的远程计算机。
Learning the Pref64::/n solves the issues listed above.
学习Pref64:：/n可以解决上面列出的问题。
The format of the PREFIX64 option is depicted in Figure 1. This option follows the guidelines specified in Section 7.3 of [RFC6887].
PREFIX64选项的格式如图1所示。该选项遵循[RFC6887]第7.3节规定的指南。
This option allows the mapping of specific IPv4 address ranges (contained in the IPv4 Prefix List) to separate Pref64::/n prefixes as discussed in [RFC6147].
此选项允许将特定IPv4地址范围（包含在IPv4前缀列表中）映射到单独的Pref64:：/n前缀，如[RFC6147]中所述。
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 Code=129| Reserved | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix64 Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: Prefix64 (Variable) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Suffix (Variable) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) |
: IPv4 Prefix List (Variable) :
| (See Figure 2) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Code=129| Reserved | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix64 Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: Prefix64 (Variable) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Suffix (Variable) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) |
: IPv4 Prefix List (Variable) :
| (See Figure 2) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Prefix64 PCP Option
图1:Prefix64 PCP选项
The description of the fields is as follows:
这些字段的说明如下所示：
o Option Code: 129
o 选择代码：129
o Reserved: This field is initialized as specified in Section 7.3 of [RFC6887].
o 保留：按照[RFC6887]第7.3节的规定初始化此字段。
o Option Length: Indicates in octets the length of the enclosed data.
o 选项长度：以八位字节表示封闭数据的长度。
o Prefix64 Length: Indicates in octets the length of the Pref64::/n. The allowed values are specified in [RFC6052] (i.e., 4, 5, 6, 7, 8, or 12).
o Prefix64长度：以八位字节表示Pref64:：/n的长度。[RFC6052]中规定了允许值（即4、5、6、7、8或12）。
o Prefix64: This field identifies the IPv6 unicast prefix to be used for constructing an IPv4-converted IPv6 address from an IPv4 address as specified in Section 2.2 of [RFC6052]. This prefix can be the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network-Specific Prefix. The address synthesis MUST follow the guidelines documented in [RFC6052].
o Prefix64：此字段标识用于根据[RFC6052]第2.2节中指定的IPv4地址构造IPv4转换IPv6地址的IPv6单播前缀。该前缀可以是众所周知的前缀（即64:ff9b:：/96）或特定于网络的前缀。地址合成必须遵循[RFC6052]中记录的指南。
o Suffix: The length of this field is (12 - Prefix64 Length) octets. This field identifies the suffix to be used for constructing an IPv4-converted IPv6 address from an IPv4 address as specified in Section 2.2 of [RFC6052]. No suffix is included if a /96 Prefix64 is conveyed in the option.
o 后缀：此字段的长度为（12-前缀64长度）八位字节。此字段标识用于根据[RFC6052]第2.2节中指定的IPv4地址构造IPv4转换IPv6地址的后缀。如果选项中传输了a/96 Prefix64，则不包括后缀。
o IPv4 Prefix List: This is an optional field. The format of the IPv4 Prefix List field is shown in Figure 2. This field may be included by a PCP server to solve the destination-dependent Pref64::/n discovery problem discussed in Section 5.1 of [RFC7050]. * IPv4 Prefix Count: indicates the number of IPv4 prefixes included in the option. "IPv4 Prefix Count" field MUST be set to 0 in a request and MUST be set to the number of included IPv4 subnets in a response. * An IPv4 prefix is represented as "IPv4 Address/IPv4 Prefix Length" [RFC4632]. For example, to encode 192.0.2.0/24, "IPv4 Prefix Length" field is set to 24 and "IPv4 Address" field is set to 192.0.2.0. If a Pref64::/n is configured for all IPv4 addresses, a wildcard IPv4 prefix (i.e., 0.0.0.0/0) may be returned in the response together with the configured Pref64::/n. If no IPv4 Prefix List is returned in a PREFIX64 option, the PCP client assumes the prefix is valid for any destination IPv4 address. Valid IPv4 prefixes are listed in Section 3.1 of [RFC4632].
o IPv4前缀列表：这是一个可选字段。IPv4前缀列表字段的格式如图2所示。PCP服务器可以包含此字段，以解决与目标相关的Pref64:：/n[RFC7050]第5.1节中讨论的发现问题。*IPv4前缀计数：指示选项中包含的IPv4前缀数。“IPv4前缀计数”字段在请求中必须设置为0，并且必须设置为响应中包含的IPv4子网的数量。*IPv4前缀表示为“IPv4地址/IPv4前缀长度”[RFC4632]。例如，要编码192.0.2.0/24，“IPv4前缀长度”字段设置为24，“IPv4地址”字段设置为192.0.2.0。如果为所有IPv4地址配置了Pref64:：/n，则响应中可能会返回通配符IPv4前缀（即0.0.0.0/0）以及配置的Pref64:：/n。如果PREFIX64选项中未返回IPv4前缀列表，则PCP客户端将假定该前缀对任何目标IPv4地址有效。[RFC4632]的第3.1节列出了有效的IPv4前缀。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix Count | IPv4 Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix Length | IPv4 Address (32 bits)... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv4 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix Count | IPv4 Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix Length | IPv4 Address (32 bits)... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv4 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of IPv4 Prefix List field
图2:IPv4前缀列表字段的格式
Option Name: PREFIX64
选项名称：PREFIX64
Value: 129
价值：129
Purpose: Learn the prefix used by the NAT64 to build IPv4-converted IPv6 addresses. This is used by a host for local address synthesis (e.g., when an IPv4 address is present in referrals).
目的：了解NAT64用于构建IPv4转换的IPv6地址的前缀。主机将其用于本地地址合成（例如，当引用中存在IPv4地址时）。
Valid for Opcodes: MAP, ANNOUNCE
对操作码有效：映射、公告
Length: Variable
长度：可变
May appear in: request, response.
可能出现在：请求、响应。
Maximum occurrences: 1 for a request. As many as fit within the maximum PCP message size for a response.
最大发生次数：一个请求1次。在响应的最大PCP消息大小内尽可能多地匹配。
The PCP server controlling a NAT64 SHOULD be configured to return to requesting PCP clients the value of the Pref64::/n and suffix used to build IPv4-converted IPv6 addresses. When enabled, the PREFIX64 option conveys the value of the Pref64::/n and configured suffix. If no suffix is explicitly configured to the PCP server, the null suffix is used as the default value (see Section 2.2 of [RFC6052]).
控制NAT64的PCP服务器应配置为向请求PCP客户端返回用于生成IPv4转换的IPv6地址的Pref64:：/n和后缀的值。启用时，PREFIX64选项会传递Pref64:：/n和配置后缀的值。如果没有为PCP服务器明确配置后缀，则使用空后缀作为默认值（参见[RFC6052]第2.2节）。
If the PCP server is configured to honor the PREFIX64 option but no Pref64::/n is explicitly configured, the PCP server MUST NOT include any PREFIX64 option in its PCP messages.
如果PCP服务器配置为支持PREFIX64选项，但未明确配置Pref64:：/n，则PCP服务器的PCP消息中不得包含任何PREFIX64选项。
The PCP server controlling a NAT64 MAY be configured to include a PREFIX64 option in all MAP responses even if the PREFIX64 option is not listed in the associated request. The PCP server controlling a NAT64 MAY be configured to include a PREFIX64 option in its ANNOUNCE messages.
控制NAT64的PCP服务器可配置为在所有映射响应中包括PREFIX64选项，即使相关请求中未列出PREFIX64选项。控制NAT64的PCP服务器可以配置为在其公告消息中包括PREFIX64选项。
The PCP server MAY be configured with a list of destination IPv4 prefixes associated with a Pref64::/n. This list is then included by the PCP server in a PREFIX64 option sent to PCP clients.
PCP服务器可以配置与Pref64:：/n关联的目标IPv4前缀列表。然后，PCP服务器将此列表包含在发送到PCP客户端的PREFIX64选项中。
The PCP server MAY be configured to return multiple PREFIX64 options in the same message to the PCP client. In such case, the server does the following:
PCP服务器可配置为在同一消息中向PCP客户端返回多个PREFIX64选项。在这种情况下，服务器将执行以下操作：
o If no destination IPv4 prefix list is configured, the PCP server includes in the first PREFIX64 option, which appears in the PCP message it sends to the PCP client, the prefix and suffix to perform local IPv6 address synthesis [RFC6052]. Additional PREFIX64 options convey any other Pref64::/n values configured. Returning these prefixes allows an end host to identify all synthesized IPv6 addresses in a network; the host can prefer IPv4 or another network interface instead in order to avoid any NAT64 deployed in the network. The PCP server is required to disambiguate prefixes used for IPv6 address synthesis and other prefixes used to avoid any NAT64 deployed in the network. The PCP server can be configured with a customized IPv6 prefix list (i.e., specific to a PCP client or a group of PCP clients) or system-wide IPv6 prefix list (i.e., the same list is returned for any PCP client). Note, it is NOT RECOMMENDED to include PREFIX64 options in ANNOUNCE messages if a customized IPv6 prefix list is configured to the PCP server.
o 如果未配置目标IPv4前缀列表，PCP服务器将在其发送给PCP客户端的PCP消息中显示的第一个PREFIX64选项中包含用于执行本地IPv6地址合成的前缀和后缀[RFC6052]。其他PREFIX64选项传递任何其他配置的Pref64:：/n值。返回这些前缀允许终端主机识别网络中的所有合成IPv6地址；主机可以选择IPv4或其他网络接口，以避免在网络中部署任何NAT64。PCP服务器需要消除用于IPv6地址合成的前缀和用于避免网络中部署任何NAT64的其他前缀之间的歧义。PCP服务器可以配置自定义的IPv6前缀列表（即，特定于PCP客户端或一组PCP客户端）或系统范围的IPv6前缀列表（即，为任何PCP客户端返回相同的列表）。注意，如果为PCP服务器配置了自定义IPv6前缀列表，则不建议在公告消息中包含PREFIX64选项。
o If IPv4 prefix lists are configured, the PCP server includes in the first PREFIX64 options the Pref64::/n and suffix that are associated with an IPv4 prefix list (i.e., each of these PREFIX64 options conveys a distinct Pref64::/n together with an IPv4 prefix list). Additional PREFIX64 options convey any other Pref64::/n values configured (i.e., the remaining Pref64::/n values not mapped to any IPv4 prefix list).
o 如果配置了IPv4前缀列表，则PCP服务器在第一个PREFIX64选项中包括与IPv4前缀列表相关联的Pref64:：/n和后缀（即，这些PREFIX64选项中的每个选项都与IPv4前缀列表一起传递不同的Pref64:：/n）。其他PREFIX64选项传递配置的任何其他Pref64:：/n值（即，未映射到任何IPv4前缀列表的剩余Pref64:：/n值）。
If a distinct Pref64::/n or suffix is configured to the PCP-controlled NAT64 device, the PCP server SHOULD issue an unsolicited PCP ANNOUNCE message to inform the PCP client about the new Pref64::/n and/or suffix.
如果为PCP控制的NAT64设备配置了不同的Pref64:：/n或后缀，PCP服务器应发出未经请求的PCP公告消息，通知PCP客户端新的Pref64:：/n和/或后缀。
The PCP client includes a PREFIX64 option in a MAP or ANNOUNCE request to learn the IPv6 prefix and suffix used by an upstream PCP-controlled NAT64 device. When enclosed in a PCP request, the Prefix64 MUST be set to ::/96. The PREFIX64 option can be inserted in a MAP request used to learn the external IP address as detailed in Section 11.6 of [RFC6887].
PCP客户端在映射或通告请求中包含PREFIX64选项，以了解由上游PCP控制的NAT64设备使用的IPv6前缀和后缀。当包含在PCP请求中时，前缀x64必须设置为：：/96。PREFIX64选项可插入到用于学习外部IP地址的映射请求中，详见[RFC6887]第11.6节。
The PCP client MUST be prepared to receive multiple prefixes (e.g., if several PCP servers are deployed and each of them is configured with a distinct Pref64::/n). The PCP client MUST associate each received Pref64::/n and suffix with the PCP server from which the Pref64::/n and suffix information was retrieved.
PCP客户端必须准备好接收多个前缀（例如，如果部署了多个PCP服务器，并且每个服务器都配置了不同的Pref64:：/n）。PCP客户端必须将每个收到的Pref64:：/n和后缀与从中检索Pref64:：/n和后缀信息的PCP服务器相关联。
If the PCP client fails to contact a given PCP server, the PCP client SHOULD clear the prefix(es) and suffix(es) it learned from that PCP server. For example, a PCP client may fail to contact a PCP server if the host embedding the PCP client moves to a new network or if that PCP server is out of service. The use of these stale prefixes is not recommended to build an IPv4-converted IPv6 address because failures are likely to be encountered (see [RFC7051], Section 3, Issue #4).
如果PCP客户端未能联系给定的PCP服务器，则PCP客户端应清除从该PCP服务器上获悉的前缀和后缀。例如，如果嵌入PCP客户端的主机移动到新网络或PCP服务器停止服务，则PCP客户端可能无法联系PCP服务器。不建议使用这些过时的前缀来构建IPv4转换的IPv6地址，因为可能会遇到故障（请参阅[RFC7051]，第3节，问题4）。
If the PCP client receives a PREFIX64 option that includes an invalid IPv4 prefix, the PCP client ignores that IPv4 prefix. If one or more valid IPv4 prefixes and/or IPv6 prefixes and suffixes are present, the PCP client uses them.
如果PCP客户端接收到包含无效IPv4前缀的PREFIX64选项，则PCP客户端将忽略该IPv4前缀。如果存在一个或多个有效的IPv4前缀和/或IPv6前缀和后缀，PCP客户端将使用它们。
Upon receipt of the message from the PCP server, the PCP client replaces any old prefix(es)/suffix(es) received from the same PCP server with the new one(s) included in the PREFIX64 option(s). If no PREFIX64 option includes a destination IPv4 prefix list, the host embedding the PCP client uses the prefix/suffix included in the first PREFIX64 option for local address synthesis. Other prefixes learned can be used by the host to avoid any NAT64 deployed in the network. If one or multiple received PREFIX64 options contain a destination IPv4 prefix list, the PCP client MUST associate the included IPv4 prefixes with the Pref64::/n and the suffix indicated in the same PREFIX64 option. In such case, the host embedding the PCP client MUST enforce a destination-based prefix Pref64::/n selection for local address synthesis purposes. How the content of the PREFIX64 option(s) is passed to the OS is implementation specific.
收到来自PCP服务器的消息后，PCP客户端将从同一PCP服务器接收的任何旧前缀/后缀替换为PREFIX64选项中包含的新前缀/后缀。如果没有PREFIX64选项包含目标IPv4前缀列表，则嵌入PCP客户端的主机将使用第一个PREFIX64选项中包含的前缀/后缀进行本地地址合成。主机可以使用其他学到的前缀来避免在网络中部署任何NAT64。如果一个或多个收到的PREFIX64选项包含目标IPv4前缀列表，则PCP客户端必须将包含的IPv4前缀与Pref64:：/n和同一PREFIX64选项中指示的后缀相关联。在这种情况下，嵌入PCP客户端的主机必须强制执行基于目的地的前缀Pref64:：/n选择，以便进行本地地址合成。如何将PREFIX64选项的内容传递给操作系统取决于具体实现。
Upon receipt of an unsolicited PCP ANNOUNCE message, the PCP client replaces the old prefix/suffix received from the same PCP server with the new Pref64::/n and suffix included in the PREFIX64 option.
收到未经请求的PCP公告消息后，PCP客户端将从同一PCP服务器接收的旧前缀/后缀替换为Pref64:：/n和PREFIX64选项中包含的后缀。
This section provides a non-normative description of use cases relying on the PREFIX64 option.
本节提供了依赖PREFIX64选项的用例的非规范性描述。
The usage shown in Figure 3 depicts a typical usage of the PREFIX64 option when a DNS64 capability is embedded in the host.
图3所示的用法描述了主机中嵌入DNS64功能时PREFIX64选项的典型用法。
In the example shown in Figure 3, once the IPv6-only client discovers the IPv4 address of the remote IPv4-only server (e.g., using DNS), it retrieves the Pref64::/n (i.e., 2001:db8:122:300::/56) to be used to build an IPv4-converted IPv6 address for that server. This retrieval is achieved using the PREFIX64 option (Steps (a) and (b)). The client then uses 2001:db8:122:300::/56 to construct an IPv6 address and then initiates a TCP connection (Steps (1) to (4)).
在图3所示的示例中，一旦仅IPv6客户端发现远程仅IPv4服务器的IPv4地址（例如，使用DNS），它将检索Pref64:：/n（即，2001:db8:122:300:：/56），以用于为该服务器构建IPv4转换的IPv6地址。此检索是使用PREFIX64选项（步骤（a）和（b））实现的。然后，客户端使用2001:db8:122:300:：/56构建IPv6地址，然后启动TCP连接（步骤（1）到（4））。
+---------+ +-----+ +---------+
|IPv6-only| |NAT64| |IPv4-only|
| Client | | | | Server |
+---------+ +-----+ +---------+
| | |
| (a) PCP MAP Request | |
| PREFIX64 | |
|======================>| |
| (b) PCP MAP Response | |
| PREFIX64 = | |
| 2001:db8:122:300::/56 | |
|<======================| |
| (1) TCP SYN | (2) TCP SYN |
|======================>|====================>|
| (4) TCP SYN/ACK | (3) TCP SYN/ACK |
|<======================|<====================|
| (5) TCP ACK | (6) TCP ACK |
|======================>|====================>|
| | |
+---------+ +-----+ +---------+
|IPv6-only| |NAT64| |IPv4-only|
| Client | | | | Server |
+---------+ +-----+ +---------+
| | |
| (a) PCP MAP Request | |
| PREFIX64 | |
|======================>| |
| (b) PCP MAP Response | |
| PREFIX64 = | |
| 2001:db8:122:300::/56 | |
|<======================| |
| (1) TCP SYN | (2) TCP SYN |
|======================>|====================>|
| (4) TCP SYN/ACK | (3) TCP SYN/ACK |
|<======================|<====================|
| (5) TCP ACK | (6) TCP ACK |
|======================>|====================>|
| | |
Note: The DNS exchange to retrieve the IPv4 address of the IPv4-only Server is not shown in the figure.
注意：图中未显示用于检索仅IPv4服务器的IPv4地址的DNS交换。
Figure 3: Example of a TCP Session Initiated from an IPv6-Only Host
图3：仅从IPv6主机启动的TCP会话示例
Figure 4 shows an example of the use of the option defined in Section 4 in a SIP context. In order for RTP/RTCP flows to be exchanged between an IPv6-only SIP UA and an IPv4-only UA without requiring any ALG (Application Level Gateway) at the NAT64 or any particular function at the IPv4-only SIP Proxy Server (e.g., hosted NAT traversal [LATCHING]), the PORT_SET option [PORT-SET] is used in addition to the PREFIX64 option.
图4显示了在SIP上下文中使用第4节中定义的选项的示例。为了在仅IPv6的SIP UA和仅IPv4的UA之间交换RTP/RTCP流，而不需要NAT64上的任何ALG（应用程序级网关）或仅IPv4的SIP代理服务器上的任何特定功能（例如，托管NAT遍历[锁定]），除了PREFIX64选项外，还使用了PORT_SET选项[端口集]。
In steps (a) and (b), the IPv6-only SIP UA retrieves a pair of ports to be used for RTP/RTCP sessions, the external IPv4 address and the Pref64::/n to build IPv4-embedded IPv6 addresses. This is achieved by issuing a MAP request that includes a PREFIX64 option and a PORT_SET option. A pair of ports (i.e., port_X/port_X+1) and an external IPv4 address (together with a Pref64::/n, i.e., 2001:db8:122::/48) are then returned by the PCP server to the requesting PCP client.
在步骤（a）和（b）中，仅限IPv6的SIP UA检索一对用于RTP/RTCP会话的端口、外部IPv4地址和Pref64:：/n以构建IPv4嵌入IPv6地址。这是通过发出包含PREFIX64选项和PORT_SET选项的映射请求来实现的。然后，PCP服务器将一对端口（即端口X/端口X+1）和一个外部IPv4地址（连同一个Pref64:：/n，即2001:db8:122:：/48）返回给请求的PCP客户端。
The returned external IPv4 address and external port numbers are used by the IPv6-only SIP UA to build its SDP offer, which contains exclusively IPv4 addresses. (Especially in the "c=" line, the port indicated for the media port is the external port assigned by the PCP server.) The INVITE request including the SDP offer is then forwarded by the NAT64 to the Proxy Server, which will relay it to the called party, i.e., the IPv4-only SIP UA (Steps (1) to (3)).
仅限IPv6的SIP UA使用返回的外部IPv4地址和外部端口号构建其SDP产品，该产品仅包含IPv4地址。（特别是在“c=”行中，为媒体端口指示的端口是由PCP服务器分配的外部端口。）然后，NAT64将包括SDP提供的INVITE请求转发给代理服务器，代理服务器将其转发给被叫方，即仅IPv4的SIP UA（步骤（1）至（3））。
The remote IPv4-only SIP UA accepts the offer and sends back its SDP answer in a "200 OK" message that is relayed by the SIP Proxy Server and NAT64 until being delivered to the IPv6-only SIP UA (Steps (4) to (6)).
仅限IPv4的远程SIP UA接受该提议，并在“200 OK”消息中发回其SDP应答，该消息由SIP代理服务器和NAT64中继，直到被传递到仅限IPv6的SIP UA（步骤（4）至（6））。
The Pref64::/n (2001:db8:122::/48) is used by the IPv6-only SIP UA to construct a corresponding IPv6 address of the IPv4 address enclosed in the SDP answer made by the IPv4-only SIP UA (Step (6)).
Pref64:：/n（2001:db8:122:：/48）由仅限IPv6的SIP UA用于构造包含在仅限IPv4的SIP UA所做SDP应答中的IPv4地址的相应IPv6地址（步骤（6））。
The IPv6-only SIP UA and IPv4-only SIP UA are then able to exchange RTP/RTCP flows without requiring any ALG at the NAT64 or any special function at the IPv4-only SIP Proxy Server.
然后，仅限IPv6的SIP UA和仅限IPv4的SIP UA能够交换RTP/RTCP流，而无需NAT64上的任何ALG或仅限IPv4的SIP代理服务器上的任何特殊功能。
+---------+ +-----+ +------------+ +---------+
|IPv6-only| |NAT64| | IPv4 SIP | |IPv4-only|
| SIP UA | | | |Proxy Server| | SIP UA |
+---------+ +-----+ +------------+ +---------+
| (a) PCP MAP Request | | |
| PORT_SET | | |
| PREFIX64 | | |
|======================>| | |
| (b) PCP MAP Response | | |
| PORT_SET | | |
| PREFIX64: | | |
| 2001:db8:122::/48 | | |
|<======================| | |
| (1) SIP INVITE | (2) SIP INVITE | (3) SIP INVITE |
|======================>|===============>|================>|
| (6) SIP 200 OK | (5) SIP 200 OK | (4) SIP 200 OK |
|<======================|<===============|<================|
| (7) SIP ACK | (8) SIP ACK | (9) SIP ACK |
|======================>|===============>|================>|
| | | |
|src port: dst port:|src port: dst port:|
|port_A port_B|port_X port_B|
|<======IPv6 RTP=======>|<============IPv4 RTP============>|
|<===== IPv6 RTCP======>|<============IPv4 RTCP===========>|
|src port: dst port:|src port: dst port:|
|port_A+1 port_B+1|port_X+1 port_B+1|
| | |
+---------+ +-----+ +------------+ +---------+
|IPv6-only| |NAT64| | IPv4 SIP | |IPv4-only|
| SIP UA | | | |Proxy Server| | SIP UA |
+---------+ +-----+ +------------+ +---------+
| (a) PCP MAP Request | | |
| PORT_SET | | |
| PREFIX64 | | |
|======================>| | |
| (b) PCP MAP Response | | |
| PORT_SET | | |
| PREFIX64: | | |
| 2001:db8:122::/48 | | |
|<======================| | |
| (1) SIP INVITE | (2) SIP INVITE | (3) SIP INVITE |
|======================>|===============>|================>|
| (6) SIP 200 OK | (5) SIP 200 OK | (4) SIP 200 OK |
|<======================|<===============|<================|
| (7) SIP ACK | (8) SIP ACK | (9) SIP ACK |
|======================>|===============>|================>|
| | | |
|src port: dst port:|src port: dst port:|
|port_A port_B|port_X port_B|
|<======IPv6 RTP=======>|<============IPv4 RTP============>|
|<===== IPv6 RTCP======>|<============IPv4 RTCP===========>|
|src port: dst port:|src port: dst port:|
|port_A+1 port_B+1|port_X+1 port_B+1|
| | |
Figure 4: Example of IPv6 to IPv4 SIP-Initiated Session
图4:IPv6到IPv4 SIP启动会话的示例
When the session is initiated from the IPv4-only SIP UA (see Figure 5), the IPv6-only SIP UA retrieves a pair of ports to be used for the RTP/RTCP session, the external IPv4 address and the Pref64::/n to build IPv4-converted IPv6 addresses (Steps (a) and (b)). These two steps could instead be delayed until the INVITE message is received (Step (3)).
当会话从仅IPv4的SIP UA启动时（参见图5），仅IPv6的SIP UA检索一对用于RTP/RTCP会话的端口、外部IPv4地址和Pref64:：/n以构建IPv4转换的IPv6地址（步骤（a）和（b））。这两个步骤可以延迟，直到收到INVITE消息为止（步骤（3））。
The retrieved IPv4 address and port numbers are used to build the SDP answer in Step (4), while the Pref64::/n is used to construct an IPv6 address corresponding to the IPv4 address enclosed in the SDP offer made by the IPv4-only SIP UA (Step (3)). RTP/RTCP flows are then exchanged between the IPv6-only SIP UA and the IPv4-only UA without requiring any ALG at the NAT64 or any special function at the IPv4-only SIP Proxy Server.
在步骤（4）中，检索到的IPv4地址和端口号用于构建SDP应答，而Pref64:：/n用于构建与仅IPv4的SIP UA提供的SDP中包含的IPv4地址相对应的IPv6地址（步骤（3））。RTP/RTCP流随后在仅IPv6的SIP UA和仅IPv4的UA之间交换，而不需要NAT64上的任何ALG或仅IPv4的SIP代理服务器上的任何特殊功能。
+---------+ +-----+ +------------+ +---------+
|IPv6-only| |NAT64| | IPv4 SIP | |IPv4-only|
| SIP UA | | | |Proxy Server| | SIP UA |
+---------+ +-----+ +------------+ +---------+
| (a) PCP MAP Request | | |
| PORT_SET | | |
| PREFIX64 | | |
|======================>| | |
| (b) PCP MAP Response | | |
| PORT_SET | | |
| PREFIX64: | | |
| 2001:db8:122::/48 | | |
|<======================| | |
| (3) SIP INVITE | (2) SIP INVITE | (1) SIP INVITE |
|<======================|<===============|<================|
| (4) SIP 200 OK | (5) SIP 200 OK | (6) SIP 200 OK |
|======================>|===============>|================>|
| (9) SIP ACK | (8) SIP ACK | (7) SIP ACK |
|<======================|<===============|<================|
| | | |
|src port: dst port:|src port: dst port:|
|port_a port_b|port_Y port_b|
|<======IPv6 RTP=======>|<============IPv4 RTP============>|
|<===== IPv6 RTCP======>|<============IPv4 RTCP===========>|
|src port: dst port:|src port: dst port:|
|port_a+1 port_b+1|port_Y+1 port_b+1|
| | |
+---------+ +-----+ +------------+ +---------+
|IPv6-only| |NAT64| | IPv4 SIP | |IPv4-only|
| SIP UA | | | |Proxy Server| | SIP UA |
+---------+ +-----+ +------------+ +---------+
| (a) PCP MAP Request | | |
| PORT_SET | | |
| PREFIX64 | | |
|======================>| | |
| (b) PCP MAP Response | | |
| PORT_SET | | |
| PREFIX64: | | |
| 2001:db8:122::/48 | | |
|<======================| | |
| (3) SIP INVITE | (2) SIP INVITE | (1) SIP INVITE |
|<======================|<===============|<================|
| (4) SIP 200 OK | (5) SIP 200 OK | (6) SIP 200 OK |
|======================>|===============>|================>|
| (9) SIP ACK | (8) SIP ACK | (7) SIP ACK |
|<======================|<===============|<================|
| | | |
|src port: dst port:|src port: dst port:|
|port_a port_b|port_Y port_b|
|<======IPv6 RTP=======>|<============IPv4 RTP============>|
|<===== IPv6 RTCP======>|<============IPv4 RTCP===========>|
|src port: dst port:|src port: dst port:|
|port_a+1 port_b+1|port_Y+1 port_b+1|
| | |
Figure 5: Example of IPv4 to IPv6 SIP-Initiated Session
图5:IPv4到IPv6 SIP启动会话的示例
Figure 6 shows an example of a NAT64 configured with two Pref64::/n values; each of these Pref64::/n values is associated with a distinct IPv4 address range:
图6显示了配置有两个Pref64:：/n值的NAT64示例；这些Pref64:：/n值中的每一个都与不同的IPv4地址范围相关联：
o 192.0.2.0/24 is mapped to 2001:db8:122:300::/56.
o 192.0.2.0/24映射到2001:db8:122:300:：/56。
o 198.51.100.0/24 is mapped to 2001:db8:122::/48.
o 198.51.100.0/24映射到2001:db8:122:：/48。
Once the IPv6-only client discovers the IPv4 address of the remote IPv4-only server (i.e., 198.51.100.1), it retrieves two IPv6 prefixes to be used to build an IPv4-converted IPv6 addresses. This retrieval is achieved using two PREFIX64 options (Step (b)).
一旦仅IPv6客户端发现远程仅IPv4服务器（即198.51.100.1）的IPv4地址，它将检索两个IPv6前缀，以用于构建IPv4转换的IPv6地址。此检索使用两个PREFIX64选项（步骤（b））实现。
Because 198.51.100.1 matches the destination prefix 198.51.100.0/24, the client uses the associated Pref64::/n (i.e., 2001:db8:122::/48) to construct an IPv6 address for that IPv4-only server, and then it initiates a TCP connection (Steps (1) to (6)).
由于198.51.100.1与目标前缀198.51.100.0/24匹配，因此客户端使用关联的Pref64:：/n（即，2001:db8:122:：/48）为仅IPv4的服务器构造IPv6地址，然后启动TCP连接（步骤（1）至（6））。
+---------+ +-----+ +---------+
|IPv6-only| |NAT64| |IPv4-only|
| Client | | | | Server |
+---------+ +-----+ +---------+
| | 198.51.100.1
| (a) PCP MAP Request | |
| PREFIX64 | |
|=================================>| |
| (b) PCP MAP Response | |
|PREFIX64{ | |
| Pref64::/n =2001:db8:122:300::/56| |
| IPv4 Prefix=192.0.2.0/24} | |
|PREFIX64{ | |
| Pref64::/n =2001:db8:122::/48 | |
| IPv4 Prefix=198.51.100.0/24} | |
|<=================================| |
| (1) TCP SYN | (2) TCP SYN |
|=================================>|====================>|
| (4) TCP SYN/ACK | (3) TCP SYN/ACK |
|<=================================|<====================|
| (5) TCP ACK | (6) TCP ACK |
|=================================>|====================>|
| | |
+---------+ +-----+ +---------+
|IPv6-only| |NAT64| |IPv4-only|
| Client | | | | Server |
+---------+ +-----+ +---------+
| | 198.51.100.1
| (a) PCP MAP Request | |
| PREFIX64 | |
|=================================>| |
| (b) PCP MAP Response | |
|PREFIX64{ | |
| Pref64::/n =2001:db8:122:300::/56| |
| IPv4 Prefix=192.0.2.0/24} | |
|PREFIX64{ | |
| Pref64::/n =2001:db8:122::/48 | |
| IPv4 Prefix=198.51.100.0/24} | |
|<=================================| |
| (1) TCP SYN | (2) TCP SYN |
|=================================>|====================>|
| (4) TCP SYN/ACK | (3) TCP SYN/ACK |
|<=================================|<====================|
| (5) TCP ACK | (6) TCP ACK |
|=================================>|====================>|
| | |
Note: The DNS exchange to retrieve the IPv4 address of the IPv4-only Server is not shown in the figure.
注意：图中未显示用于检索仅IPv4服务器的IPv4地址的DNS交换。
Figure 6: Mapping of IPv4 Address Ranges to IPv6 Prefixes
图6:IPv4地址范围到IPv6前缀的映射
A similar behavior is to be experienced if these Pref64::/n values and associated IPv4 prefix lists are configured to distinct NAT64 devices.
如果将这些Pref64:：/n值和关联的IPv4前缀列表配置为不同的NAT64设备，则会出现类似的行为。
The following PCP Option Code has been allocated in the optional-to-process range (the registry is maintained in http://www.iana.org/assignments/pcp-parameters):
以下PCP选项代码已分配到可选的处理范围（注册表在http://www.iana.org/assignments/pcp-parameters):
PREFIX64 set to 129 (see Section 4.1)
PREFIX64设置为129（见第4.1节）
PCP-related security considerations are discussed in [RFC6887].
[RFC6887]中讨论了PCP相关的安全注意事项。
As discussed in [RFC6147], if an attacker can manage to change the Pref64::/n used by the DNS64 function, the traffic generated by the host that receives the synthetic reply will be delivered to the altered Pref64. This can result in either a denial-of-service (DoS) attack, a flooding attack, or a man-in-the-middle (MITM) attack. This attack could be achieved either by altering PCP messages issued by a legitimate PCP server or by using a fake PCP server.
如[RFC6147]中所述，如果攻击者能够设法更改DNS64函数使用的Pref64:：/n，则接收合成应答的主机生成的通信量将传送到更改后的Pref64。这可能导致拒绝服务（DoS）攻击、泛洪攻击或中间人（MITM）攻击。此攻击可以通过更改合法PCP服务器发出的PCP消息或使用假PCP服务器来实现。
Means to defend against attackers who can modify packets between the PCP server and the PCP client, or who can inject spoofed packets that appear to come from a legitimate PCP server, SHOULD be enabled. In some deployments, access control lists (ACLs) can be installed on the PCP client, PCP server, and the network between them, so those ACLs allow only communications from a trusted PCP server to the PCP client.
应启用防范攻击者的手段，这些攻击者可以修改PCP服务器和PCP客户端之间的数据包，或者可以注入看似来自合法PCP服务器的伪造数据包。在某些部署中，可以在PCP客户端、PCP服务器以及它们之间的网络上安装访问控制列表（ACL），因此这些ACL只允许从受信任的PCP服务器到PCP客户端的通信。
PCP server discovery is out of scope for this document. It is the responsibility of documents about PCP server discovery to elaborate on the security considerations to discover a legitimate PCP server.
PCP服务器发现超出了本文档的范围。有关PCP服务器发现的文档有责任详细说明发现合法PCP服务器的安全注意事项。
Learning a Pref64::/n via PCP allows using DNSSEC in the presence of NAT64. As such, NAT64 with DNSSEC and PCP is better than no DNSSEC at all, but it is less safe than DNSSEC without DNS64/NAT64 and PCP. The best mitigation action against Pref64::/n discovery attacks is thus to add IPv6 support in all endpoints and hence reduce the need to perform IPv6 address synthesis.
通过PCP学习Pref64:：/n允许在NAT64存在的情况下使用DNSSEC。因此，含有DNSSEC和PCP的NAT64比不含DNSSEC要好，但其安全性不如不含DNS64/NAT64和PCP的DNSSEC。因此，针对Pref64:：/n发现攻击的最佳缓解措施是在所有端点中添加IPv6支持，从而减少执行IPv6地址合成的需要。
Many thanks to S. Perreault, R. Tirumaleswar, T. Tsou, D. Wing, J. Zhao, R. Penno, I. van Beijnum, T. Savolainen, S. Savikumar, D. Thaler, T. Lemon, S. Hanna, P. Resnick, R. Sparks, S. Farrell, and W. Cui for their comments and suggestions.
非常感谢S.Perreault、R.Tirumaleswar、T.Tsou、D.Wing、J.Zhao、R.Penno、I.van Beijnum、T.Savolainen、S.Savikumar、D.Thaler、T.Lemon、S.Hanna、P.Resnick、R.Sparks、S.Farrell和W.Cui的评论和建议。
[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月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月。
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887]南柴郡Wing，D.，布卡达尔，M.，佩诺，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，2013年4月。
[PCP-BITTORRENT] Boucadair, M., Zheng, T., Deng, X., and J. Queiroz, "Behavior of BitTorrent service in PCP-enabled networks with Address Sharing", Work in Progress, May 2012.
[PCP-BITTORRENT]Boucadair，M.，Zheng，T.，Deng，X.，和J.Queiroz，“具有地址共享功能的PCP网络中BITTORRENT服务的行为”，正在进行的工作，2012年5月。
[EXPERIMENTS] Abdesselam, M., Boucadair, M., Hasnaoui, A., and J. Queiroz, "PCP NAT64 Experiments", Work in Progress, September 2012.
[实验]Abdesselam，M.，Boucadair，M.，Hasnaoui，A.，和J.Queiroz，“PCP NAT64实验”，正在进行的工作，2012年9月。
[REF-OBJECT] Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement for Referral", Work in Progress, February 2011.
[REF-OBJECT]Carpenter，B.，Jiang，S.，和Z.Cao，“转诊问题陈述”，在建工程，2011年2月。
[LATCHING] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", Work in Progress, May 2014.
[锁定]Ivov，E.，Kaplan，H.，和D.Wing，“锁定：实时通信媒体的托管NAT穿越（HNT）”，正在进行的工作，2014年5月。
[PORT-SET] Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., and S. Perreault, "Port Control Protocol (PCP) Extension for Port Set Allocation", Work in Progress, November 2013.
[端口集]琼，Q.，布卡达尔，M.，西瓦库马尔，S.，周，C.，邹，T.，和S.佩雷尔特，“端口集分配的端口控制协议（PCP）扩展”，正在进行的工作，2013年11月。
[WebRTC] Alvestrand, H., "Overview: Real Time Protocols for Brower-based Applications", Work in Progress, February 2014.
[WebRTC]Alvestrand，H.，“概述：基于浏览器的应用程序的实时协议”，进展中的工作，2014年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，RFC 6269，2011年6月。
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, November 2013.
[RFC7050]Savolainen，T.，Korhonen，J.，和D.Wing，“用于IPv6地址合成的IPv6前缀的发现”，RFC 70502013年11月。
[RFC7051] Korhonen, J. and T. Savolainen, "Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, November 2013.
[RFC7051]Korhonen，J.和T.Savolainen，“主机学习NAT64前缀的解决方案分析”，RFC 7051，2013年11月。
Author's Address
作者地址
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com