Internet Engineering Task Force (IETF) T. Savolainen
Request for Comments: 7050 Nokia
Category: Standards Track J. Korhonen
ISSN: 2070-1721 Broadcom
D. Wing
Cisco Systems
November 2013
Internet Engineering Task Force (IETF) T. Savolainen
Request for Comments: 7050 Nokia
Category: Standards Track J. Korhonen
ISSN: 2070-1721 Broadcom
D. Wing
Cisco Systems
November 2013
Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
发现用于IPv6地址合成的IPv6前缀
Abstract
摘要
This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments.
本文档描述了用于检测DNS64的存在和用于学习用于接入网络上协议转换的IPv6前缀的方法。该方法取决于已知的仅IPv4完全限定域名“ipv4only.arpa”的存在。所学到的信息使节点能够执行本地IPv6地址合成，并可能避免在双堆栈和多接口部署上部署NAT64。
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/rfc7050.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7050.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Notation and Terminology ...........................4
2.1. Requirements Notation ......................................4
2.2. Terminology ................................................4
3. Node Behavior ...................................................4
3.1. Validation of Discovered Pref64::/n ........................6
3.1.1. DNSSEC Requirements for the Network .................7
3.1.2. DNSSEC Requirements for the Node ....................7
3.2. Connectivity Check .........................................8
3.2.1. No Connectivity Checks against "ipv4only.arpa." .....9
3.3. Alternative Fully Qualified Domain Names ..................10
3.4. Message Flow Illustration .................................10
4. Operational Considerations for Hosting the IPv4-Only
Well-Known Name ................................................12
5. Operational Considerations for DNS64 Operator ..................12
5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes ...........13
6. Exit Strategy ..................................................14
7. Security Considerations ........................................14
8. IANA Considerations ............................................15
8.1. Domain Name Reservation Considerations ....................15
8.2. IPv4 Address Allocation Considerations ....................16
8.3. IAB Statement Regarding This .arpa Request ................17
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
Appendix A. Example of DNS Record Configuration ..................20
Appendix B. About the IPv4 Address for the Well-Known Name .......21
1. Introduction ....................................................3
2. Requirements Notation and Terminology ...........................4
2.1. Requirements Notation ......................................4
2.2. Terminology ................................................4
3. Node Behavior ...................................................4
3.1. Validation of Discovered Pref64::/n ........................6
3.1.1. DNSSEC Requirements for the Network .................7
3.1.2. DNSSEC Requirements for the Node ....................7
3.2. Connectivity Check .........................................8
3.2.1. No Connectivity Checks against "ipv4only.arpa." .....9
3.3. Alternative Fully Qualified Domain Names ..................10
3.4. Message Flow Illustration .................................10
4. Operational Considerations for Hosting the IPv4-Only
Well-Known Name ................................................12
5. Operational Considerations for DNS64 Operator ..................12
5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes ...........13
6. Exit Strategy ..................................................14
7. Security Considerations ........................................14
8. IANA Considerations ............................................15
8.1. Domain Name Reservation Considerations ....................15
8.2. IPv4 Address Allocation Considerations ....................16
8.3. IAB Statement Regarding This .arpa Request ................17
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
Appendix A. Example of DNS Record Configuration ..................20
Appendix B. About the IPv4 Address for the Well-Known Name .......21
As part of the transition to IPv6, NAT64 [RFC6146] and DNS64 [RFC6147] technologies will be utilized by some access networks to provide IPv4 connectivity for IPv6-only nodes [RFC6144]. DNS64 utilizes IPv6 address synthesis to create local IPv6 addresses for peers having only IPv4 addresses, hence allowing DNS-using IPv6-only nodes to communicate with IPv4-only peers.
作为向IPv6过渡的一部分，一些接入网络将利用NAT64[RFC6146]和DNS64[RFC6147]技术为仅IPv6的节点[RFC6144]提供IPv4连接。DNS64利用IPv6地址合成为仅具有IPv4地址的对等方创建本地IPv6地址，因此允许使用仅IPv6节点的DNS与仅IPv4对等方通信。
However, DNS64 cannot serve applications not using DNS, such as those receiving IPv4 address literals as referrals. Such applications could nevertheless be able to work through NAT64, provided they are able to create locally valid IPv6 addresses that would be translated to the peers' IPv4 addresses.
但是，DNS64不能服务于不使用DNS的应用程序，例如那些接收IPv4地址文本作为引用的应用程序。不过，这些应用程序可以通过NAT64工作，前提是它们能够创建本地有效的IPv6地址，并将其转换为对等方的IPv4地址。
Additionally, DNS64 is not able to do IPv6 address synthesis for nodes running validating DNS resolvers enabled by DNS Security (DNSSEC), but instead, the synthesis must be done by the nodes themselves. In order to perform IPv6 synthesis, nodes have to learn the IPv6 prefix(es) used on the access network for protocol translation. A prefix, which may be a Network-Specific Prefix (NSP) or a Well-Known Prefix (WKP) [RFC6052], is referred to in this document as Pref64::/n [RFC6146].
此外，DNS64无法为运行由DNS安全性（DNSSEC）启用的验证DNS解析程序的节点执行IPv6地址合成，而是必须由节点自己执行合成。为了执行IPv6合成，节点必须学习接入网络上用于协议转换的IPv6前缀。前缀可以是网络特定前缀（NSP）或众所周知的前缀（WKP）[RFC6052]，在本文档中称为Pref64:：/n[RFC6146]。
This document describes a best-effort method for applications and nodes to learn the information required to perform local IPv6 address synthesis. The IPv6 address synthesis procedure itself is out of the scope of this document. An example application is a browser encountering IPv4 address literals in an IPv6-only access network. Another example is a node running a validating security-aware DNS resolver in an IPv6-only access network.
本文档描述了应用程序和节点学习执行本地IPv6地址合成所需信息的最佳方法。IPv6地址合成过程本身不在本文档的范围内。一个示例应用程序是在仅IPv6的访问网络中遇到IPv4地址文本的浏览器。另一个示例是在仅IPv6访问网络中运行验证安全感知DNS解析器的节点。
The knowledge of IPv6 address synthesis taking place may also be useful if DNS64 and NAT64 are used in dual-stack-enabled access networks or if a node is multi-interfaced [RFC6418]. In such cases, nodes may choose to prefer IPv4 or an alternative network interface in order to avoid traversal through protocol translators.
如果DNS64和NAT64用于支持双栈的接入网络，或者如果节点是多接口的[RFC6418]，则发生IPv6地址合成的知识也可能有用。在这种情况下，节点可以选择首选IPv4或替代网络接口，以避免通过协议转换器进行遍历。
It is important to note that use of this approach will not result in a system that is as robust, secure, and well-behaved as an all-IPv6 system would be. Hence, it is highly recommended to upgrade nodes' destinations to IPv6 and utilize the described method only as a transition solution.
需要注意的是，使用这种方法不会产生一个像全IPv6系统一样健壮、安全和性能良好的系统。因此，强烈建议将节点的目的地升级到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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
NAT64 FQDN: a fully qualified domain name (FQDN) for a NAT64 protocol translator.
NAT64 FQDN：NAT64协议转换器的完全限定域名（FQDN）。
Pref64::/n: an IPv6 prefix used for IPv6 address synthesis [RFC6146].
Pref64:：/n：用于IPv6地址合成的IPv6前缀[RFC6146]。
Pref64::WKA: an IPv6 address consisting of Pref64::/n and WKA at any of the locations allowed by RFC 6052 [RFC6052].
Pref64:：WKA:一个IPv6地址，由RFC 6052[RFC6052]允许的任意位置的Pref64:：/n和WKA组成。
Secure Channel: a communication channel a node has between itself and a DNS64 server protecting DNS protocol-related messages from interception and tampering. The channel can be, for example, an IPsec-based virtual private network (VPN) tunnel or a link layer utilizing data encryption technologies.
安全通道：节点自身与DNS64服务器之间的通信通道，用于保护DNS协议相关消息免受拦截和篡改。例如，信道可以是基于IPsec的虚拟专用网络（VPN）隧道或利用数据加密技术的链路层。
Well-Known IPv4-only Name (WKN): the fully qualified domain name, "ipv4only.arpa.", well-known to have only A record(s).
众所周知的仅IPv4名称（WKN）：完全限定的域名，“ipv4only.arpa.”，众所周知只有一个记录。
Well-Known IPv4 Address (WKA): an IPv4 address that is well-known and present in an A record for the well-known name. Two well-known IPv4 addresses are defined for Pref64::/n discovery purposes: 192.0.0.170 and 192.0.0.171.
已知IPv4地址（WKA）：已知的IPv4地址，并出现在已知名称的A记录中。为Pref64:：/n查找目的定义了两个众所周知的IPv4地址：192.0.0.170和192.0.0.171。
A node requiring information about the presence (or absence) of NAT64, and one or more Pref64::/n used for protocol translation SHALL send a DNS query for AAAA resource records of the Well-Known IPv4-only Name (WKN) "ipv4only.arpa.". The node MAY perform the DNS query in both IPv6-only and dual-stack access networks.
需要有关NAT64存在（或不存在）的信息以及用于协议转换的一个或多个Pref64:：/n的节点应发送DNS查询，以查询已知的仅IPv4名称（WKN）“ipv4only.arpa.”的AAAA资源记录。该节点可在仅IPv6和双栈接入网络中执行DNS查询。
When sending a DNS AAAA resource record query for the WKN, a node MUST set the "Checking Disabled (CD)" bit to zero [RFC4035], as otherwise the DNS64 server will not perform IPv6 address synthesis (Section 3 of [RFC6147]) and hence would not reveal the Pref64::/n used for protocol translation.
当发送WKN的DNS AAAA资源记录查询时，节点必须将“检查禁用（CD）”位设置为零[RFC4035]，否则DNS64服务器将不会执行IPv6地址合成（第3节[RFC6147]），因此不会显示用于协议转换的Pref64:：/n。
A DNS reply with one or more AAAA resource records indicates that the access network is utilizing IPv6 address synthesis. In some scenarios, captive portals, or NXDOMAIN and NODATA hijacking, performed by the access network may result in a false positive. One method to detect such hijacking is to query a fully qualified domain name that is known to be invalid (and normally returns an empty response or an error response) and see if it returns a valid resource record. However, as long as the hijacked domain does not result in AAAA resource record responses that contain a well-known IPv4 address in any location defined by [RFC6052], the response will not disturb the Pref64::/n learning procedure.
具有一个或多个AAAA资源记录的DNS应答表示接入网络正在利用IPv6地址合成。在某些情况下，由接入网络执行的捕获门户或NXDOMAIN和Nodeata劫持可能会导致误报。检测此类劫持的一种方法是查询已知无效的完全限定域名（通常返回空响应或错误响应），并查看它是否返回有效的资源记录。但是，只要被劫持的域不会导致在[RFC6052]定义的任何位置包含已知IPv4地址的AAAA资源记录响应，该响应将不会干扰Pref64:：/n学习过程。
A node MUST look through all of the received AAAA resource records to collect one or more Pref64::/n. The Pref64::/n list might include the Well-Known Prefix 64:ff9b::/96 [RFC6052] or one or more Network-Specific Prefixes. In the case of NSPs, the node SHALL determine the used address format by searching the received IPv6 addresses for the WKN's well-known IPv4 addresses. The node SHALL assume the well-known IPv4 addresses might be found at the locations specified by [RFC6052], Section 2.2. The node MUST check on octet boundaries to ensure a 32-bit well-known IPv4 address value is present only once in an IPv6 address. In case another instance of the value is found inside the IPv6 address, the node SHALL repeat the search with the other well-known IPv4 address.
节点必须查看所有收到的AAAA资源记录，以收集一个或多个Pref64:：/n。Pref64:：/n列表可能包括众所周知的前缀64:ff9b:：/96[RFC6052]或一个或多个特定于网络的前缀。对于NSPs，节点应通过搜索接收到的IPv6地址以查找WKN的已知IPv4地址来确定使用的地址格式。节点应假定已知IPv4地址可能位于[RFC6052]第2.2节规定的位置。节点必须检查八位字节边界，以确保已知的32位IPv4地址值在IPv6地址中仅存在一次。如果在IPv6地址内找到该值的另一个实例，则节点应使用另一个已知IPv4地址重复搜索。
If only one Pref64::/n was present in the DNS response, a node SHALL use that Pref64::/n for both local synthesis and for detecting synthesis done by the DNS64 server on the network.
如果DNS响应中仅存在一个Pref64:：/n，则节点应将该Pref64:：/n用于本地合成和检测网络上DNS64服务器完成的合成。
If more than one Pref64::/n was present in the DNS response, a node SHOULD use all of them when determining whether other received IPv6 addresses are synthetic. The node MUST use all learned Pref64::/n when performing local IPv6 address synthesis and use the prefixes in the order received from the DNS64 server. That is, when the node is providing a list of locally synthesized IPv6 addresses to upper layers, IPv6 addresses MUST be synthesized by using all discovered Pref64::/n prefixes in the received order.
如果DNS响应中存在多个Pref64:：/n，则节点在确定其他接收到的IPv6地址是否为合成地址时应使用所有Pref64:：/n。执行本地IPv6地址合成时，节点必须使用所有读入的Pref64:：/n，并按照从DNS64服务器接收的顺序使用前缀。也就是说，当节点向上层提供本地合成的IPv6地址列表时，必须使用接收顺序中所有发现的Pref64:：/n前缀来合成IPv6地址。
If the well-known IPv4 addresses are not found within the standard locations, the DNS response indicates that the network is not using a standard address format or unexpected IPv4 addresses were used in the AAAA resource record synthesis. In either case, the Pref64::/n cannot be determined and the heuristic procedure has failed. Developers can, over time, learn of IPv6-translated address formats that are extensions or alternatives to the standard formats. At that point, developers MAY add additional steps to the described discovery procedure. The additional steps are outside the scope of the present document.
如果在标准位置中未找到已知的IPv4地址，则DNS响应表示网络未使用标准地址格式，或者AAAA资源记录合成中使用了意外的IPv4地址。在任何一种情况下，都无法确定Pref64:：/n，并且启发式过程失败。随着时间的推移，开发人员可以了解到IPv6转换地址格式是标准格式的扩展或替代。此时，开发人员可以向所描述的发现过程添加额外的步骤。其他步骤超出了本文件的范围。
In case a node does not receive a positive DNS reply to the AAAA resource record query, the node MAY perform a DNS A resource record query for the well-known name. Receiving a positive reply to the DNS A resource record query indicates that the recursive DNS server that is used is not a DNS64 server.
如果节点没有收到对AAAA资源记录查询的肯定DNS回复，则该节点可以对该已知名称执行DNS a资源记录查询。接收到对DNS a资源记录查询的肯定答复表明所使用的递归DNS服务器不是DNS64服务器。
In the case of a negative response (NXDOMAIN, NODATA) or a DNS query timeout, a DNS64 server is not available on the access network, the access network filtered out the well-known query, or something went wrong in the DNS resolution. All unsuccessful cases result in a node being unable to perform local IPv6 address synthesis. In the case of timeout, the node SHOULD retransmit the DNS query like any other DNS query the node makes [RFC1035]. In the case of a negative response (NXDOMAIN, NODATA), the node MUST obey the Time to Live (TTL) [RFC1035] of the response before resending the AAAA resource record query. The node MAY monitor for DNS replies with IPv6 addresses constructed from the WKP, in which case if any are observed, the node SHOULD use the WKP as if it were learned during the query for the well-known name.
如果出现否定响应（NXDOMAIN、NODATA）或DNS查询超时，则接入网络上的DNS64服务器不可用，接入网络过滤掉了已知的查询，或者DNS解析出现错误。所有不成功的情况都会导致节点无法执行本地IPv6地址合成。在超时的情况下，节点应该像节点进行的任何其他DNS查询一样重新传输DNS查询[RFC1035]。在否定响应（NXDOMAIN，NODATA）的情况下，节点必须在重新发送AAAA资源记录查询之前遵守响应的生存时间（TTL）[RFC1035]。该节点可以监视使用由WKP构造的IPv6地址的DNS应答，在这种情况下，如果观察到任何应答，则该节点应该使用WKP，就好像它是在查询已知名称的过程中获知的一样。
To save Internet resources if possible, a node should perform Pref64::/n discovery only when needed (e.g., when local synthesis is required, when a new network interface is connected to a new network, and so forth). The node SHALL cache the replies it receives during the Pref64::/n discovery procedure, and it SHOULD repeat the discovery process ten seconds before the TTL of the Well-Known Name's synthetic AAAA resource record expires.
为了尽可能节省Internet资源，节点应仅在需要时执行Pref64:：/n查找（例如，当需要本地合成时，当新网络接口连接到新网络时，等等）。节点应缓存在Pref64:：/n发现过程中收到的回复，并应在知名名称的合成AAAA资源记录的TTL过期前10秒重复发现过程。
If a node is using an insecure channel between itself and a DNS64 server or the DNS64 server is untrusted, it is possible for an attacker to influence the node's Pref64::/n discovery procedures. This may result in denial-of-service, redirection, man-in-the-middle, or other attacks.
如果节点在自身和DNS64服务器之间使用不安全的通道，或者DNS64服务器不受信任，则攻击者可能会影响节点的Pref64:：/n发现过程。这可能导致拒绝服务、重定向、中间人攻击或其他攻击。
To mitigate against attacks, the node SHOULD communicate with a trusted DNS64 server over a secure channel or use DNSSEC. NAT64 operators SHOULD provide facilities for validating discovery of Pref64::/n via a secure channel and/or DNSSEC protection.
为了抵御攻击，节点应通过安全通道与受信任的DNS64服务器通信或使用DNSSEC。NAT64操作员应提供通过安全通道和/或DNSSEC保护验证Pref64:：/n发现的设施。
It is important to understand that DNSSEC only validates that the discovered Pref64::/n is the one that belongs to a domain used by NAT64 FQDN. Importantly, the DNSSEC validation does not tell if the node is at the network where the Pref64::/n is intended to be used. Furthermore, DNSSEC validation cannot be utilized in the case of a WKP.
重要的是要了解，DNSSEC仅验证发现的Pref64:：/n是否属于NAT64 FQDN使用的域。重要的是，DNSSEC验证不会告诉节点是否位于要使用Pref64:：/n的网络上。此外，DNSSEC验证不能用于WKP。
If the operator has chosen to support nodes performing validation of discovered Pref64::/n with DNSSEC, the operator of the NAT64 device MUST perform the following configurations.
如果操作员选择支持使用DNSSEC对发现的Pref64:：/n执行验证的节点，则NAT64设备的操作员必须执行以下配置。
1. Have one or more fully qualified domain names for the NAT64 translator entities (later referred to as NAT64 FQDN). In the case of more than one Pref64::/n being used in a network, e.g., for load-balancing purposes, it is for network administrators to decide whether a single NAT64's fully qualified domain name maps to more than one Pref64::/n, or whether there will be a dedicated NAT64 FQDN per Pref64::/n.
1. 为NAT64转换器实体（稍后称为NAT64 FQDN）提供一个或多个完全限定的域名。在网络中使用多个Pref64:：/n的情况下，例如出于负载平衡的目的，由网络管理员决定单个NAT64的完全限定域名是否映射到多个Pref64:：/n，或者每个Pref64:：/n是否有一个专用NAT64 FQDN。
2. Each NAT64 FQDN MUST have one or more DNS AAAA resource records containing Pref64::WKA (Pref64::/n combined with WKA).
2. 每个NAT64 FQDN必须具有一个或多个包含Pref64:：WKA（Pref64:：/n与WKA组合）的DNS AAAA资源记录。
3. Each Pref64::WKA MUST have a PTR resource record that points to the corresponding NAT64 FQDN.
3. 每个Pref64:：WKA必须具有指向相应NAT64 FQDN的PTR资源记录。
4. Sign the NAT64 FQDNs' AAAA and A resource records with DNSSEC.
4. 使用DNSSEC对NAT64 FQDNs的AAAA和A资源记录进行签名。
A node SHOULD prefer a secure channel to talk to a DNS64 server whenever possible. In addition, a node that implements a DNSSEC validating resolver MAY use the following procedure to validate discovery of the Pref64::/n.
节点应尽可能使用安全通道与DNS64服务器通信。此外，实现DNSSEC验证解析程序的节点可以使用以下过程验证Pref64的发现：/n。
1. Heuristically find Pref64::/n candidates by making a AAAA resource record query for "ipv4only.arpa." by following the procedure in Section 3. This will result in IPv6 addresses consisting of Pref64::/n combined with WKA, i.e., Pref64::WKA. For each Pref64::/n that the node wishes to validate, the node performs the following steps.
1. 按照第3节中的过程，通过对“ipv4only.arpa.”进行AAAA资源记录查询，以启发式方式查找Pref64:：/n候选项。这将导致IPv6地址由Pref64:：/n和WKA组成，即Pref64:：WKA。对于节点希望验证的每个Pref64:：/n，节点将执行以下步骤。
2. Send a DNS PTR resource record query for the IPv6 address of the translator (for ".ip6.arpa." tree), using the Pref64::WKA learned in step 1. CNAME and DNAME results should be followed according to the rules in RFC 1034 [RFC1034], RFC 1035 [RFC1035], and RFC 6672 [RFC6672]. The ultimate response will include one or more NAT64 FQDNs.
2. 使用在步骤1中学习的Pref64:：WKA，发送转换器IPv6地址（用于“.ip6.arpa.”树）的DNS PTR资源记录查询。应根据RFC 1034[RFC1034]、RFC 1035[RFC1035]和RFC 6672[RFC6672]中的规则遵循CNAME和DNAME结果。最终响应将包括一个或多个NAT64 FQDN。
3. The node SHOULD compare the domains of learned NAT64 FQDNs to a list of the node's trusted domains and choose a NAT64 FQDN that matches. The means for a node to learn the trusted domains is
3. 节点应将学习的NAT64 FQDN的域与节点的受信任域列表进行比较，并选择匹配的NAT64 FQDN。节点学习受信任域的方法是
implementation specific. If the node has no trust for the domain, the discovery procedure is not secure, and the remaining steps described below MUST NOT be performed.
具体实施。如果节点对域不信任，则发现过程不安全，不得执行下面描述的其余步骤。
4. Send a DNS AAAA resource record query for the NAT64 FQDN.
4. 发送NAT64 FQDN的DNS AAAA资源记录查询。
5. Verify the DNS AAAA resource record contains Pref64::WKA addresses received at step 1. It is possible that the NAT64 FQDN has multiple AAAA records, in which case the node MUST check if any of the addresses match the ones obtained in step 1. The node MUST ignore other responses and not use them for local IPv6 address synthesis.
5. 验证DNS AAAA资源记录是否包含在步骤1接收到的Pref64:：WKA地址。NAT64 FQDN可能有多个AAAA记录，在这种情况下，节点必须检查是否有任何地址与步骤1中获得的地址匹配。节点必须忽略其他响应，而不能将其用于本地IPv6地址合成。
6. Perform DNSSEC validation of the DNS AAAA response.
6. 对DNS AAAA响应执行DNSSEC验证。
After the node has successfully performed the above five steps, the node can consider Pref64::/n validated.
节点成功执行上述五个步骤后，节点可以考虑PREF64：：/N验证。
After learning a Pref64::/n, the node SHOULD perform a connectivity check to ensure the learned Pref64::/n is functional. It could be non-functional for a variety of reasons -- the discovery failed to work as expected, the IPv6 path to the NAT64 is down, the NAT64 is down, or the IPv4 path beyond the NAT64 is down.
学习Pref64:：/n后，节点应执行连接检查，以确保学习的Pref64:：/n正常工作。由于各种原因，它可能无法正常工作--发现未能按预期工作，NAT64的IPv6路径已关闭，NAT64已关闭，或者NAT64之外的IPv4路径已关闭。
There are two main approaches to determine if the learned Pref64::/n is functional. The first approach is to perform a dedicated connectivity check. The second approach is to simply attempt to use the learned Pref64::/n. Each approach has some trade-offs (e.g., additional network traffic or possible user-noticeable delay), and implementations should carefully weigh which approach is appropriate for their application and the network.
有两种主要方法可确定读入的Pref64:：/n是否正常工作。第一种方法是执行专用连接检查。第二种方法是简单地尝试使用读入的Pref64:：/n。每种方法都有一些权衡（例如，额外的网络流量或可能的用户明显延迟），实现应仔细权衡哪种方法适合其应用程序和网络。
The node SHOULD use an implementation-specific connectivity check server and a protocol of the implementation's choice, but if that is not possible, a node MAY do a PTR resource record query of the Pref64::WKA to get a NAT64 FQDN. The node then does an A resource query of the NAT64 FQDN, which will return zero or more A resource records pointing to connectivity check servers used by the network operator. A negative response to the PTR or A resource query means there are no connectivity check servers available. A network operator that provides NAT64 services for a mix of nodes with and without implementation-specific connectivity check servers SHOULD assist nodes in their connectivity checks by mapping each NAT64 FQDN to one or more DNS A resource records with IPv4 address(es) pointing to connectivity check server(s). The connectivity check approach based on Pref64::/n works only with NSPs, as it is not possible to
节点应该使用特定于实现的连接检查服务器和实现选择的协议，但如果不可能，节点可以对Pref64:：WKA执行PTR资源记录查询，以获取NAT64 FQDN。然后，节点对NAT64 FQDN执行A资源查询，该查询将返回零条或多条指向网络运营商使用的连接检查服务器的A资源记录。对PTR或资源查询的否定响应意味着没有可用的连接检查服务器。为具有或不具有特定于实现的连接检查服务器的混合节点提供NAT64服务的网络运营商应通过将每个NAT64 FQDN映射到一个或多个IPv4地址指向连接检查服务器的DNS A资源记录来协助节点进行连接检查。基于Pref64:：/n的连接检查方法仅适用于NSPs，因为无法
register A records for each different domain using a WKP. The network operator MUST disable ICMPv6 rate limiting for connectivity check messages.
使用WKP为每个不同的域注册记录。网络运营商必须禁用连接检查消息的ICMPv6速率限制。
If multiple connectivity check servers are available for use, the node chooses the first one, preferring implementation-specific servers.
如果有多个连接检查服务器可供使用，则节点将选择第一个服务器，首选特定于实现的服务器。
The connectivity check protocol used with implementation-specific connectivity check servers is implementation specific.
与特定于实现的连接检查服务器一起使用的连接检查协议是特定于实现的。
The connectivity check protocol used with connectivity check servers pointed to by the NAT64 FQDN's A resource records is ICMPv6 [RFC4443]. The node performing a connectivity check against these servers SHALL send an ICMPv6 Echo Request to an IPv6 address synthesized by combining discovered Pref64::/n with an IPv4 address of the server as specified in [RFC6052]. This will test the IPv6 path to the NAT64, the NAT64's operation, and the IPv4 path all the way to the connectivity check server. If no response is received for the ICMPv6 Echo Request, the node SHALL send another ICMPv6 Echo Request a second later. If still no response is received, the node SHALL send a third ICMPv6 Echo Request two seconds later. If an ICMPv6 Echo Response is received, the node knows the IPv6 path to the connectivity check server is functioning normally. If no response is received after three transmissions and after three seconds have elapsed since the last ICMPv6 Echo Request, the node learns this Pref64::/n might not be functioning, and the node MAY choose a different Pref64::/n (if available), choose to alert the user, or proceed anyway assuming the failure is temporary or is caused by the connectivity check itself. After all, ICMPv6 is unreliable by design, and failure to receive ICMPv6 responses may not indicate anything other than network failure to transport ICMPv6 messages.
NAT64 FQDN的A资源记录指向的连接检查服务器使用的连接检查协议是ICMPv6[RFC4443]。对这些服务器执行连接检查的节点应向IPv6地址发送ICMPv6回显请求，该地址通过将发现的Pref64:：/n与[RFC6052]中指定的服务器IPv4地址组合而合成。这将测试NAT64的IPv6路径、NAT64的操作以及连接检查服务器的IPv4路径。如果没有收到ICMPv6回显请求的响应，则节点应在一秒钟后发送另一个ICMPv6回显请求。如果仍然没有收到响应，则节点应在两秒钟后发送第三个ICMPv6回显请求。如果接收到ICMPv6回显响应，则节点知道连接检查服务器的IPv6路径正常工作。如果在三次传输之后以及自上次ICMPv6回显请求以来的三秒钟之后未收到响应，则节点会了解到此Pref64:：/n可能不起作用，并且节点可能会选择不同的Pref64:：/n（如果可用），选择提醒用户，或者，假设故障是暂时的或是连接检查本身造成的，则继续。毕竟，ICMPv6在设计上是不可靠的，如果接收不到ICMPv6响应，则除了传输ICMPv6消息的网络故障外，可能并不表示其他任何情况。
If no separate connectivity check is performed before local IPv6 address synthesis, a node MAY monitor success of connection attempts performed with locally synthesized IPv6 addresses. Based on success of these connections, and based on possible ICMPv6 error messages received (such as Destination Unreachable messages), the node MAY cease to perform local address synthesis and MAY restart the Pref64::/n discovery procedures.
如果在本地IPv6地址合成之前未执行单独的连接检查，则节点可以监视使用本地合成的IPv6地址执行的连接尝试的成功。基于这些连接的成功以及接收到的可能ICMPv6错误消息（例如目标不可访问消息），节点可能停止执行本地地址合成，并可能重新启动Pref64:：/n发现过程。
Clients MUST NOT send a connectivity check to an address returned by the "ipv4only.arpa." query. This is because, by design, no server will be operated on the Internet at that address as such. Similarly, network operators MUST NOT operate a server on that address. The reason this address isn't used for connectivity checks is that
客户端不得向“ipv4only.arpa.”查询返回的地址发送连接检查。这是因为，按照设计，互联网上不会有服务器在该地址运行。同样，网络运营商不得在该地址上操作服务器。此地址不用于连接检查的原因是
operators who neglect to operate a connectivity check server will allow that traffic towards the Internet where it will be dropped and cause a false negative connectivity check with the client (that is, the NAT64 is working fine, but the connectivity check fails because a server is not operating at "ipv4only.arpa." on the Internet and a server is not operated by the NAT64 operator). Instead, for the connectivity check, an additional DNS resource record is looked up and used for the connectivity check. This ensures that packets don't unnecessarily leak to the Internet and reduces the chance of a false negative connectivity check.
忽略操作连接检查服务器的运营商将允许该流量流向Internet，并在Internet上丢弃该流量，并导致与客户端的连接检查为假阴性（即NAT64工作正常，但连接检查失败，因为服务器未在“ipv4only.arpa”下运行）在Internet上，服务器不由NAT64操作员操作）。相反，对于连接检查，将查找附加的DNS资源记录并用于连接检查。这样可以确保数据包不会不必要地泄漏到Internet，并减少连接检查出现假阴性的可能性。
Some applications, operating systems, devices, or networks may find it advantageous to operate their own DNS infrastructure to perform a function similar to "ipv4only.arpa." but use a different resource record. The primary advantage is to ensure availability of the DNS infrastructure and ensure the proper configuration of the DNS record itself. For example, a company named Example might have their application query "ipv4only.example.com". Other than the different DNS resource record being queried, the rest of the operations are anticipated to be identical to the steps described in this document.
一些应用程序、操作系统、设备或网络可能会发现，操作自己的DNS基础设施以执行类似于“ipv4only.arpa”的功能是有利的，但使用不同的资源记录。主要优点是确保DNS基础设施的可用性，并确保DNS记录本身的正确配置。例如，名为example的公司的应用程序查询可能为“ipv4only.example.com”。除了要查询的不同DNS资源记录外，其余操作预计与本文档中描述的步骤相同。
The figure below gives an example illustration of a message flow in the case of prefix discovery utilizing Pref64::/n validation. The figure also shows a step where the procedure ends if no Pref64::/n validation is performed.
下图给出了使用Pref64:：/n验证进行前缀发现时的消息流示例。该图还显示了一个步骤，如果未执行Pref64:：/n验证，则过程结束。
In this example, three Pref64::/n prefixes are provided by the DNS64 server. The first Pref64::/n is using an NSP, in this example, "2001:db8:42::/96". The second Pref64::/n is using an NSP, in this example, "2001:db8:43::/96". The third Pref64::/n is using the WKP. Hence, when the Pref64::/n prefixes are combined with the WKA to form Pref64::WKA, the synthetic IPv6 addresses returned by the DNS64 server are "2001:db8:42::192.0.0.170", "2001:db8:43::192.0.0.170", and "64:ff9b::192.0.0.170". The DNS64 server could also return synthetic addresses containing the IPv4 address 192.0.0.171.
在本例中，DNS64服务器提供了三个Pref64:：/n前缀。第一个Pref64:：/n使用NSP，在本例中为“2001:db8:42:：/96”。第二个Pref64:：/n使用NSP，在本例中为“2001:db8:43:：/96”。第三个Pref64:：/n正在使用WKP。因此，当Pref64:：/n前缀与WKA组合形成Pref64:：WKA时，DNS64服务器返回的合成IPv6地址为“2001:db8:42:：192.0.0.170”、“2001:db8:43:：192.0.0.170”和“64:ff9b:：192.0.0.170”。DNS64服务器还可以返回包含IPv4地址192.0.0.171的合成地址。
The validation is not done for the WKP; see Section 3.1.
未对WKP进行验证；见第3.1节。
Node DNS64 server
| |
| "AAAA" query for "ipv4only.arpa." |
|----------------------------------------------->|"A" query for
| |"ipv4only.arpa."
| |--------------->
| |
| | "A" response:
| | "192.0.0.170"
| | "192.0.0.171"
| |<---------------
| +----------------------------+
| | "AAAA" synthesis using |
| | three Pref64::/n. |
| +----------------------------+
| "AAAA" response with: |
| "2001:db8:42::192.0.0.170" |
| "2001:db8:43::192.0.0.170" |
| "64:ff9b::192.0.0.170" |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| If Pref64::/n validation is not performed, a | |
| node can fetch prefixes from AAAA responses | |
| at this point and skip the steps below. | |
+----------------------------------------------+ |
| |
| "PTR" query #1 for "2001:db8:42::192.0.0.170 |
|----------------------------------------------->|
| "PTR" query #2 for "2001:db8:43::192.0.0.170 |
|----------------------------------------------->|
| |
| "PTR" response #1 "nat64_1.example.com" |
|<-----------------------------------------------|
| "PTR" response #2 "nat64_2.example.com" |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| Compare received domains to a trusted domain | |
| list and if matches are found, continue. | |
+----------------------------------------------+ |
| |
| "AAAA" query #1 for "nat64_1.example.com" |
|----------------------------------------------->|
| "AAAA" query #2 for "nat64_2.example.com" |
|----------------------------------------------->|
Node DNS64 server
| |
| "AAAA" query for "ipv4only.arpa." |
|----------------------------------------------->|"A" query for
| |"ipv4only.arpa."
| |--------------->
| |
| | "A" response:
| | "192.0.0.170"
| | "192.0.0.171"
| |<---------------
| +----------------------------+
| | "AAAA" synthesis using |
| | three Pref64::/n. |
| +----------------------------+
| "AAAA" response with: |
| "2001:db8:42::192.0.0.170" |
| "2001:db8:43::192.0.0.170" |
| "64:ff9b::192.0.0.170" |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| If Pref64::/n validation is not performed, a | |
| node can fetch prefixes from AAAA responses | |
| at this point and skip the steps below. | |
+----------------------------------------------+ |
| |
| "PTR" query #1 for "2001:db8:42::192.0.0.170 |
|----------------------------------------------->|
| "PTR" query #2 for "2001:db8:43::192.0.0.170 |
|----------------------------------------------->|
| |
| "PTR" response #1 "nat64_1.example.com" |
|<-----------------------------------------------|
| "PTR" response #2 "nat64_2.example.com" |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| Compare received domains to a trusted domain | |
| list and if matches are found, continue. | |
+----------------------------------------------+ |
| |
| "AAAA" query #1 for "nat64_1.example.com" |
|----------------------------------------------->|
| "AAAA" query #2 for "nat64_2.example.com" |
|----------------------------------------------->|
| |
| "AAAA" resp. #1 with "2001:db8:42::192.0.0.170 |
|<-----------------------------------------------|
| "AAAA" resp. #2 with "2001:db8:43::192.0.0.170 |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| Validate AAAA responses and compare the IPv6 | |
| addresses to those previously learned. | |
+----------------------------------------------+ |
| |
+----------------------------------------------+ |
| Fetch the Pref64::/n from the validated | |
| responses and take into use. | |
+----------------------------------------------+ |
| |
| |
| "AAAA" resp. #1 with "2001:db8:42::192.0.0.170 |
|<-----------------------------------------------|
| "AAAA" resp. #2 with "2001:db8:43::192.0.0.170 |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| Validate AAAA responses and compare the IPv6 | |
| addresses to those previously learned. | |
+----------------------------------------------+ |
| |
+----------------------------------------------+ |
| Fetch the Pref64::/n from the validated | |
| responses and take into use. | |
+----------------------------------------------+ |
| |
Figure 1: Pref64::/n Discovery Procedure
Figure 1: Pref64::/n Discovery Procedure
The authoritative name server for the well-known name SHALL have DNS record TTL set to at least 60 minutes in order to improve effectiveness of DNS caching. The exact TTL value will be determined and tuned based on operational experiences.
知名名称的权威名称服务器应将DNS记录TTL设置为至少60分钟，以提高DNS缓存的有效性。准确的TTL值将根据运行经验确定和调整。
The domain serving the well-known name MUST be signed with DNSSEC. See also Section 7.
提供已知名称的域必须使用DNSSEC签名。另见第7节。
A network operator of a DNS64 server can guide nodes utilizing heuristic discovery procedures by managing the responses a DNS64 server provides.
DNS64服务器的网络运营商可以通过管理DNS64服务器提供的响应，利用启发式发现过程指导节点。
If the network operator would like nodes to utilize multiple Pref64::/n prefixes, the operator needs to configure DNS64 servers to respond with multiple synthetic AAAA records. As per Section 3, the nodes can then use them all.
如果网络运营商希望节点使用多个Pref64:：/n前缀，则运营商需要配置DNS64服务器以使用多个合成AAAA记录进行响应。根据第3节，节点可以全部使用它们。
There are no guarantees on which of the Pref64::/n prefixes nodes will end up using. If the operator wants nodes to specifically use a certain Pref64::/n or periodically change the Pref64::/n they use, for example, for load balancing reasons, the only guaranteed method is to make DNS64 servers return only a single synthetic AAAA resource record and have the TTL of that synthetic record such that the node repeats the Pref64::/n discovery when required.
无法保证Pref64:：/n前缀节点中的哪一个将最终使用。如果操作员希望节点专门使用某个Pref64:：/n或定期更改其使用的Pref64:：/n，例如，出于负载平衡的原因，唯一有保证的方法是使DNS64服务器仅返回单个合成AAAA资源记录，并具有该合成记录的TTL，以便节点在需要时重复Pref64:：/n发现。
Besides choosing how many Pref64::/n prefixes to respond and what TTL to use, DNS64 servers MUST NOT interfere with or perform other special procedures for the queries related to the well-known name.
除了选择要响应的Pref64:：/n前缀数量和要使用的TTL之外，DNS64服务器不得干扰或执行与已知名称相关的查询的其他特殊过程。
RFC 6147 [RFC6147] allows DNS64 implementations to be able to map specific IPv4 address ranges to separate Pref64::/n prefixes. That allows handling of special use IPv4 addresses [RFC6890]. The example setup where this might be used is illustrated in Figure 2. The NAT64 "A" is used when accessing IPv4-only servers in the data center, and the NAT64 "B" is used for Internet access.
RFC 6147[RFC6147]允许DNS64实现能够将特定IPv4地址范围映射到单独的Pref64:：/n前缀。允许处理特殊用途的IPv4地址[RFC6890]。图2显示了可能使用此功能的示例设置。NAT64“A”用于访问数据中心中仅IPv4的服务器，NAT64“B”用于访问Internet。
NAT64 "A" ----- IPv4-only servers in a data center
/
IPv6-only node---<
\
NAT64 "B" ----- IPv4 Internet
NAT64 "A" ----- IPv4-only servers in a data center
/
IPv6-only node---<
\
NAT64 "B" ----- IPv4 Internet
Figure 2: NAT64s with IPv4 Address Ranges
图2:IPv4地址范围的NAT64
The heuristic discovery method described herein does not support learning of the possible rules used by a DNS64 server for mapping specific IPv4 address ranges to separate Pref64::/n prefixes. Therefore, nodes will use the same discovered Pref64::/n to synthesize IPv6 addresses from any IPv4 address. This can cause issues for routing and connectivity establishment procedures. The operator of the NAT64 and the DNS64 ought to take this into account in the network design.
本文描述的启发式发现方法不支持学习DNS64服务器用于将特定IPv4地址范围映射到单独的Pref64:：/n前缀的可能规则。因此，节点将使用相同的已发现Pref64:：/n从任何IPv4地址合成IPv6地址。这可能会导致路由和连接建立过程出现问题。NAT64和DNS64的运营商应该在网络设计中考虑到这一点。
The network operators can help IPv6-only nodes by ensuring the nodes do not have to work with IPv4 address literals for which special mapping rules are used. That is, the IPv4-only servers addressed from the special IPv4 address ranges ought to have signed AAAA records, which allows IPv6-only nodes to avoid local address synthesis. If the IPv6-only nodes are not using DNSSEC, then it is enough if the network's DNS64 server returns synthetic AAAA resource records pointing to IPv4-only servers. Avoiding the need for IPv6-only nodes to perform address synthesis for IPv4 addresses belonging to special ranges is the best approach to assist nodes.
网络运营商可以通过确保节点不必使用使用特殊映射规则的IPv4地址文本来帮助仅IPv6的节点。也就是说，从特殊IPv4地址范围寻址的仅IPv4服务器应该具有签名AAAA记录，这允许仅IPv6节点避免本地地址合成。如果仅IPv6节点未使用DNSSEC，则如果网络的DNS64服务器返回指向仅IPv4服务器的合成AAAA资源记录就足够了。避免只使用IPv6的节点对属于特殊范围的IPv4地址执行地址合成是帮助节点的最佳方法。
If the IPv6-only nodes have no choice other than using IPv4-address literals belonging to special IPv4 address ranges and the IPv6-only node will perform local synthesis by using the discovered Pref64::/n, then the network ought to ensure with routing that the packets are delivered to the correct NAT64. For example, a router in the path from an IPv6-only host to NAT64s can forward the IPv6 packets to the correct NAT64 as illustrated in Figure 3. The routing could be based
如果仅限IPv6的节点除了使用属于特殊IPv4地址范围的IPv4地址文本之外别无选择，并且仅限IPv6的节点将通过使用发现的Pref64:：/n执行本地合成，则网络应通过路由确保数据包传送到正确的NAT64。例如，从纯IPv6主机到NAT64的路径中的路由器可以将IPv6数据包转发到正确的NAT64，如图3所示。路由可以基于
on the last 32 bits of the IPv6 address, but the network operator can also use some other IPv6 address format allowed by RFC 6052 [RFC6052] if it simplifies routing setup. This setup requires additional logic on the NAT64 providing connectivity to special IPv4 address ranges: it needs to be able to translate packets it receives that are using the Pref64::/n used with Internet connections.
在IPv6地址的最后32位，但如果简化路由设置，网络运营商也可以使用RFC 6052[RFC6052]允许的其他IPv6地址格式。此设置需要NAT64上的附加逻辑，以提供到特殊IPv4地址范围的连接：它需要能够转换使用Internet连接使用的Pref64:：/n接收的数据包。
NAT64 "A" ----- IPv4-only servers in a data center
/
IPv6-only host---router
\
NAT64 "B" ----- IPv4 Internet
NAT64 "A" ----- IPv4-only servers in a data center
/
IPv6-only host---router
\
NAT64 "B" ----- IPv4 Internet
Figure 3: NAT64s with Assisting Router
图3：带辅助路由器的NAT64s
A day will come when this tool is no longer needed. A node SHOULD implement a configuration knob for disabling the Pref64::/n discovery feature.
总有一天，这个工具将不再需要。节点应实现用于禁用Pref64:：/n查找功能的配置旋钮。
The security considerations follow closely those of RFC 6147 [RFC6147]. The possible attacks are very similar in the case where an attacker controls a DNS64 server and returns tampered IPv6 addresses to a node and in the case where an attacker causes the node to use tampered Pref64::/n for local address synthesis. DNSSEC cannot be used to validate responses created by a DNS64 server with which the node has no trust relationship. Hence, this document does not change the big picture for untrusted network scenarios. If an attacker alters the Pref64::/n used by a DNS64 server or a node, the traffic generated by the node will be delivered to an altered destination. This can result in either a denial-of-service (DoS) attack (if the resulting IPv6 addresses are not assigned to any device), a flooding attack (if the resulting IPv6 addresses are assigned to devices that do not wish to receive the traffic), or an eavesdropping attack (in case the altered NSP is routed through the attacker).
安全注意事项严格遵循RFC 6147[RFC6147]的规定。在攻击者控制DNS64服务器并向节点返回篡改的IPv6地址的情况下，以及在攻击者使节点使用篡改的Pref64:：/n进行本地地址合成的情况下，可能的攻击非常相似。DNSSEC不能用于验证与节点没有信任关系的DNS64服务器创建的响应。因此，本文档不会改变不可信网络场景的总体情况。如果攻击者更改DNS64服务器或节点使用的Pref64:：/n，则该节点生成的流量将传送到更改的目标。这可能导致拒绝服务（DoS）攻击（如果生成的IPv6地址未分配给任何设备）、泛洪攻击（如果生成的IPv6地址分配给不希望接收流量的设备）或窃听攻击（如果更改的NSP通过攻击者路由）。
Even though a well-known name's DNS A resource record would not necessarily need to be protected with DNSSEC as both the name and IPv4 addresses well-known, DNSSEC protection is required for DNS AAAA resource record queries. Without DNSSEC, fake positive AAAA responses could cause hosts to erroneously detect Pref64::/n, thus allowing an attacker to inject malicious Pref64::/n for hosts' synthesis procedures. A signed "ipv4only.arpa." allows validating
尽管众所周知的名称的DNS a资源记录不一定需要使用DNSSEC进行保护，因为名称和IPv4地址都是众所周知的，但DNS AAAA资源记录查询需要DNSSEC保护。如果没有DNSSEC，假阳性AAAA响应可能会导致主机错误地检测到Pref64:：/n，从而允许攻击者为主机的合成过程注入恶意的Pref64:：/n。签名的“ipv4only.arpa.”允许进行验证
DNS64 servers (see [RFC6147] Section 3, Case 5, for example) to detect malicious AAAA resource records. Therefore, the zone serving the well-known name has to be protected with DNSSEC.
用于检测恶意AAAA资源记录的DNS64服务器（例如，请参见[RFC6147]第3节案例5）。因此，使用知名名称的区域必须使用DNSSEC进行保护。
For Pref64::/n discovery validation, the access network SHOULD sign the NAT64 translator's fully qualified domain name. A node SHOULD use the algorithm described in Section 3.1 to validate each discovered Pref64::/n.
对于Pref64:：/n发现验证，访问网络应签署NAT64转换器的完全限定域名。节点应使用第3.1节中描述的算法验证每个发现的Pref64:：/n。
The procedure described in Section 3.1.2 requires a node using DNSSEC to validate discovery of Pref64::/n to have a list of trusted domains. If a matching domain is not found at Step 3 in Section 3.1.2, an implementation might be tempted to ask a user to temporarily or permanently add a received domain as trusted. History has shown that average users are unable to properly handle such queries and tend to answer positively without thinking in an attempt to move forward quickly. Therefore, unless the DNSSEC-using implementation has a way to dynamically and reliably add trusted domains, it is better to fail the Pref64::/n discovery procedure.
第3.1.2节中描述的过程要求使用DNSSEC的节点验证Pref64:：/n的发现，以获得受信任域的列表。如果在第3.1.2节的步骤3中找不到匹配的域，则实现可能会要求用户临时或永久地将收到的域添加为受信任域。历史表明，普通用户无法正确处理此类查询，往往会不假思索地积极回答，试图快速前进。因此，除非使用DNSSEC的实现能够动态、可靠地添加受信任域，否则最好使Pref64:：/n发现过程失败。
Lastly, the best mitigation action against Pref64::/n discovery attacks is to add IPv6 support for nodes' destinations and hence reduce the need to perform local IPv6 address synthesis.
最后，针对Pref64:：/n发现攻击的最佳缓解措施是为节点的目的地添加IPv6支持，从而减少执行本地IPv6地址合成的需要。
According to procedures described in [RFC3172] and [RFC6761], IANA has delegated a new second-level domain in the .ARPA zone for the well-known domain name "ipv4only.arpa.". The intention is that there will not be any further delegation of names below the "ipv4only.arpa." domain. The administrative and operational management of this zone is performed by IANA. The answers to the seven questions listed in [RFC6761] are as follows:
根据[RFC3172]和[RFC6761]中所述的程序，IANA已在.ARPA区域为知名域名“ipv4only.ARPA”指定了一个新的二级域名。其目的是在“ipv4only.arpa.”域下不再有任何名称的进一步授权。该区域的行政和运营管理由IANA执行。[RFC6761]中列出的七个问题的答案如下：
1. Are human users expected to recognize these names as special and use them differently? In what way?
1. 是否期望人类用户将这些名称识别为特殊名称并以不同方式使用它们？以什么方式？
No, although this is a domain delegated under the .arpa infrastructural identifier top level domain.
不，尽管这是在.arpa基础设施标识符顶级域下委托的域。
2. Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way?
2. 应用软件的作者是否期望他们的软件将这些名称识别为特殊名称，并以不同的方式对待它们？以什么方式？
Yes. Any application attempting to perform NAT64 discovery will query the name.
对任何试图执行NAT64发现的应用程序都将查询该名称。
3. Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?
3. 名称解析API和库的编写者是否希望他们的软件将这些名称识别为特殊名称并以不同的方式对待它们？如果是，怎么做？
Yes, to the extent the API or library is affected by NAT64.
是的，API或库受NAT64影响的程度。
4. Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?
4. 缓存域名服务器的开发人员是否希望他们的实现将这些名称识别为特殊名称，并以不同的方式对待它们？如果是，怎么做？
No.
不
5. Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?
5. 权威域名服务器的开发人员是否希望他们的实现将这些名称识别为特殊名称并以不同的方式对待它们？如果是，怎么做？
No.
不
6. Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware?
6. 此保留的专用域名是否对DNS服务器运营商有任何潜在影响？如果他们试图将其权威DNS服务器配置为此保留名称的权威，兼容名称服务器软件是否会将其视为无效而拒绝？DNS服务器运营商需要了解这一点并了解原因吗？即使名称服务器软件不阻止他们使用此保留名称，是否有其他方式可能无法按预期工作，DNS服务器运营商应了解这些情况？
This name has effects for operators of NAT64/DNS64, but otherwise is just another delegated .arpa domain.
此名称对NAT64/DNS64的运算符有效，但在其他情况下，它只是另一个委派的.arpa域。
7. How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially-designated entity?
7. DNS注册机构/注册机构应如何处理注册此保留域名的请求？这些要求是否应该被拒绝？是否应允许此类请求，但仅允许向特别指定的实体提出？
The registry for .arpa is held at IANA, and only IANA needs to take action here.
.arpa的注册表位于IANA，只有IANA需要在此处采取行动。
The well-known name needs to map to two different global IPv4 addresses, which have been allocated as described in [RFC6890]. The addresses have been taken from the IANA IPv4 Special Purpose Address Registry [RFC6890], and 192.0.0.170 and 192.0.0.171 have been assigned to this document with the parameters shown below:
众所周知的名称需要映射到两个不同的全局IPv4地址，这两个地址已按[RFC6890]中所述分配。地址取自IANA IPv4专用地址注册表[RFC6890]，192.0.0.170和192.0.0.171已分配给本文档，参数如下所示：
+----------------------+-------------------------------+
| Attribute | Value |
+----------------------+-------------------------------+
| Address Block | 192.0.0.170/32 |
| | 192.0.0.171/32 |
| Name | NAT64/DNS64 Discovery |
| RFC | RFC 7050, Section 2.2 |
| Allocation Date | February 2013 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-protocol | True |
+----------------------+-------------------------------+
+----------------------+-------------------------------+
| Attribute | Value |
+----------------------+-------------------------------+
| Address Block | 192.0.0.170/32 |
| | 192.0.0.171/32 |
| Name | NAT64/DNS64 Discovery |
| RFC | RFC 7050, Section 2.2 |
| Allocation Date | February 2013 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-protocol | True |
+----------------------+-------------------------------+
The Record for IPv4 Address Allocation for IPv4 Special Purpose Address Registry
IPv4专用地址注册表的IPv4地址分配记录
The zone "ipv4only.arpa." is delegated from the ARPA zone to appropriate name servers chosen by the IANA. An apex A RRSet has been inserted in the "ipv4only.arpa." zone as follows:
区域“ipv4only.arpa.”从arpa区域委托给IANA选择的适当名称服务器。apex A RRSet已插入“ipv4only.arpa.”区域，如下所示：
IPV4ONLY.ARPA. IN A 192.0.0.170
IPV4ONLY.ARPA。在192.0.0.170中
IPV4ONLY.ARPA. IN A 192.0.0.171
IPV4ONLY.ARPA。在192.0.0.171中
With the publication of this document, the IAB approves of the delegation of "ipv4only" in the .arpa domain. Under [RFC3172], the IAB has requested that IANA delegate and provision "ipv4only.arpa." as written in this specification. However, the IAB does not take any architectural or technical position about this specification.
随着本文件的发布，IAB批准在.arpa域中授予“ipv4only”。根据[RFC3172]，IAB已要求IANA授权并提供本规范中所述的“ipv4only.arpa.”。然而，IAB对本规范不采取任何架构或技术立场。
The authors would like to thank Dmitry Anipko, Cameron Byrne, Aaron Yi Ding, Christian Huitema, Washam Fan, Peter Koch, Stephan Lagerholm, Zhenqiang Li, Simon Perreault, Marc Petit-Huguenin, Andrew Sullivan, and Dave Thaler for significant improvement ideas and comments.
作者要感谢Dmitry Anipko、Cameron Byrne、Aaron Yi Ding、Christian Huitema、Washam Fan、Peter Koch、Stephan Lagerholm、Li振强、Simon Perreault、Marc Petit Huguein、Andrew Sullivan和Dave Thaler提出的重大改进意见和评论。
Jouni Korhonen would like to acknowledge his previous employer, Nokia Siemens Networks, where the majority of his work on this document was carried out.
Jouni Korhonen要感谢他的前雇主诺基亚西门子网络公司，他在该公司完成了本文件的大部分工作。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[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月。
[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月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[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月。
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, June 2012.
[RFC6672]Rose，S.和W.Wijngaards，“DNS中的DNAME重定向”，RFC 66722012年6月。
[RFC3172] Huston, G., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, September 2001.
[RFC3172]Huston，G.“地址和路由参数区域域（“arpa”）的管理指南和操作要求”，BCP 52，RFC 3172，2001年9月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", RFC 5735, January 2010.
[RFC5735]Cotton，M.和L.Vegoda，“特殊用途IPv4地址”，RFC 57352010年1月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC 61442011年4月。
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
[RFC6418]Blanchet，M.和P.Seite，“多接口和供应域问题声明”，RFC 6418，2011年11月。
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013.
[RFC6761]Cheshire，S.和M.Krochmal，“特殊用途域名”，RFC 67612013年2月。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, April 2013.
[RFC6890]Cotton，M.，Vegoda，L.，Bonica，R.，和B.Haberman，“特殊用途IP地址注册”，BCP 153，RFC 68902013年4月。
The following BIND-style examples illustrate how A and AAAA records could be configured by a NAT64 operator.
以下绑定样式示例说明了NAT64运算符如何配置A和AAAA记录。
The examples use Pref64::/n of 2001:db8::/96, both WKAs, and the example.com domain.
示例使用了WKAs和example.com域中的Pref64:：/n of 2001:db8:：/96。
The PTR record for reverse queries (Section 3.1.1, Bullet 3):
反向查询的PTR记录（第3.1.1节，项目符号3）：
$ORIGIN A.A.0.0.0.0.0.C\ .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA. @ IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 12h 15m 3w 2h) IN NS ns.example.com.
$ORIGIN A.A.0.0.0.0.0.C\.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.0.2.IP6.ARPA.@在SOA ns1.example.com中。hostmaster.example.com。（2003080800 12h 15m 3w 2h）在NS.example.com上。
IN PTR nat64.example.com.
在PTR nat64.example.com中。
$ORIGIN B.A.0.0.0.0.0.C\ .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA. @ IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 12h 15m 3w 2h) IN NS ns.example.com.
$ORIGIN B.A.0.0.0.0.0.C\.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.d.0.1.0.0.0.2.IP6.ARPA.@在SOA ns1.example.com中。hostmaster.example.com。（2003080800 12h 15m 3w 2h）在NS.example.com上。
IN PTR nat64.example.com.
在PTR nat64.example.com中。
If example.com does not use DNSSEC, the following configuration file could be used. Please note that nat64.example.com has both a AAAA record with the Pref64::/n and an A record for the connectivity check (Section 3.1.1, Bullet 2).
如果example.com不使用DNSSEC，则可以使用以下配置文件。请注意，nat64.example.com既有一条带Pref64:：/n的AAAA记录，也有一条连接检查的a记录（第3.1.1节，项目符号2）。
example.com. IN SOA ns.example.com. hostmaster.example.com. ( 2002050501 ; serial 100 ; refresh (1 minute 40 seconds) 200 ; retry (3 minutes 20 seconds) 604800 ; expire (1 week) 100 ; minimum (1 minute 40 seconds) )
example.com。在SOA ns.example.com中。hostmaster.example.com。（2002050501；串行100；刷新（1分40秒）200；重试（3分20秒）604800；过期（1周）100；最小值（1分40秒））
example.com. IN NS ns.example.com.
example.com。在NS.example.com中。
nat64.example.com.
IN AAAA 2001:db8:0:0:0:0:C000:00AA
IN AAAA 2001:db8:0:0:0:0:C000:00AB
IN A 192.0.2.1
nat64.example.com.
IN AAAA 2001:db8:0:0:0:0:C000:00AA
IN AAAA 2001:db8:0:0:0:0:C000:00AB
IN A 192.0.2.1
For DNSSEC to sign the records, the owner of the example.com zone would have RRSIG records for both the AAAA and A records for nat64.example.com. As a normal DNSSEC requirement, the zone and its parent also need to be signed.
为了让DNSSEC签署记录，example.com区域的所有者将拥有AAAA的RRSIG记录和nat64.example.com的A记录。作为DNSSEC的一项正常要求，还需要签署区域及其母公司。
The IPv4 addresses for the well-known name cannot be non-global IPv4 addresses as listed in the Section 3 of [RFC5735]. Otherwise, DNS64 servers might not perform AAAA record synthesis when the well-known prefix is used, as stated in Section 3.1 of [RFC6052]. However, the addresses do not have to be routable or allocated to any real node as no communications will be initiated to these IPv4 address.
已知名称的IPv4地址不能是[RFC5735]第3节中列出的非全局IPv4地址。否则，当使用众所周知的前缀时，DNS64服务器可能不会执行AAAA记录合成，如[RFC6052]第3.1节所述。但是，这些地址不必是可路由的或分配给任何实际节点，因为不会启动到这些IPv4地址的通信。
Allocation of at least two IPv4 addresses improves the heuristics in cases where the bit pattern of the primary IPv4 address appears more than once in the synthetic IPv6 address (i.e., the NSP prefix contains the same bit pattern as the IPv4 address).
如果主IPv4地址的位模式在合成IPv6地址中出现多次（即，NSP前缀包含与IPv4地址相同的位模式），则至少分配两个IPv4地址可以改进启发式。
If no well-known IPv4 addresses would be statically allocated for this method, the heuristic would require sending of an additional A query to learn the IPv4 addresses that would be then searched from inside of the received IPv6 address.
如果没有为该方法静态分配已知的IPv4地址，则启发式将需要发送额外的查询以了解IPv4地址，然后从接收到的IPv6地址内部搜索这些地址。
Authors' Addresses
作者地址
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland
Teemu Savolainen诺基亚Hermiankatu 12 D FI-33720坦佩雷芬兰
EMail: teemu.savolainen@nokia.com
EMail: teemu.savolainen@nokia.com
Jouni Korhonen Broadcom Linnoitustie 6 FI-02600 Espoo Finland
Jouni Korhonen Broadcom Linnoitustie 6 FI-02600芬兰埃斯波
EMail: jouni.nospam@gmail.com
EMail: jouni.nospam@gmail.com
Dan Wing Cisco Systems 170 West Tasman Drive San Jose, California 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com