Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 7051 Broadcom
Category: Informational T. Savolainen, Ed.
ISSN: 2070-1721 Nokia
November 2013
Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 7051 Broadcom
Category: Informational T. Savolainen, Ed.
ISSN: 2070-1721 Nokia
November 2013
Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix
主机学习NAT64前缀的解决方案分析
Abstract
摘要
Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network. This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by the NAT64 and DNS64. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending the standardization of the approach based on heuristic discovery.
主机和应用程序可能会受益于了解是否合成了IPv6地址以及网络中是否存在NAT64和DNS64。本文档分析了所有建议的解决方案（在撰写本文时已知），用于通信是否正在进行合成、使用了什么地址格式以及NAT64和DNS64使用了什么IPv6前缀。这些解决方案支持NAT64避免和本地IPv6地址合成。本文最后建议基于启发式发现的方法标准化。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7051.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7051.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Issues ..........................................................5
4. Background ......................................................6
5. Proposed Solutions to Learn about Synthesis and
Network-Specific Prefix .........................................7
5.1. DNS Query for a Well-Known Name ............................7
5.1.1. Solution Description ................................7
5.1.2. Analysis and Discussion .............................7
5.1.3. Summary .............................................8
5.2. EDNS0 Option Indicating AAAA Record Synthesis and Format ...8
5.2.1. Solution Description ................................8
5.2.2. Analysis and Discussion .............................9
5.2.3. Summary ............................................10
5.3. EDNS0 Flags Indicating AAAA Record Synthesis and Format ...10
5.3.1. Solution Description ...............................10
5.3.2. Analysis and Discussion ............................10
5.3.3. Summary ............................................11
5.4. DNS Resource Record for IPv4-Embedded IPv6 Address ........11
5.4.1. Solution Description ...............................11
5.4.2. Analysis and Discussion ............................12
5.4.3. Summary ............................................12
5.5. Learning the IPv6 Prefix of a Network's NAT64 Using DNS ...13
5.5.1. Solution Description ...............................13
5.5.2. Analysis and Discussion ............................13
5.5.3. Summary ............................................14
5.6. Learning the IPv6 Prefix of a Network's NAT64
Using DHCPv6 ..............................................14
5.6.1. Solution Description ...............................14
5.6.2. Analysis and Discussion ............................15
5.6.3. Summary ............................................15
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Issues ..........................................................5
4. Background ......................................................6
5. Proposed Solutions to Learn about Synthesis and
Network-Specific Prefix .........................................7
5.1. DNS Query for a Well-Known Name ............................7
5.1.1. Solution Description ................................7
5.1.2. Analysis and Discussion .............................7
5.1.3. Summary .............................................8
5.2. EDNS0 Option Indicating AAAA Record Synthesis and Format ...8
5.2.1. Solution Description ................................8
5.2.2. Analysis and Discussion .............................9
5.2.3. Summary ............................................10
5.3. EDNS0 Flags Indicating AAAA Record Synthesis and Format ...10
5.3.1. Solution Description ...............................10
5.3.2. Analysis and Discussion ............................10
5.3.3. Summary ............................................11
5.4. DNS Resource Record for IPv4-Embedded IPv6 Address ........11
5.4.1. Solution Description ...............................11
5.4.2. Analysis and Discussion ............................12
5.4.3. Summary ............................................12
5.5. Learning the IPv6 Prefix of a Network's NAT64 Using DNS ...13
5.5.1. Solution Description ...............................13
5.5.2. Analysis and Discussion ............................13
5.5.3. Summary ............................................14
5.6. Learning the IPv6 Prefix of a Network's NAT64
Using DHCPv6 ..............................................14
5.6.1. Solution Description ...............................14
5.6.2. Analysis and Discussion ............................15
5.6.3. Summary ............................................15
5.7. Learning the IPv6 Prefix of a Network's NAT64
Using Router ..............................................16
5.7.1. Solution Description ...............................16
5.7.2. Analysis and Discussion ............................16
5.7.3. Summary ............................................17
5.8. Using Application-Layer Protocols such as STUN ............17
5.8.1. Solution Description ...............................17
5.8.2. Analysis and Discussion ............................17
5.8.3. Summary ............................................19
5.9. Learning the IPv6 Prefix of a Network's NAT64
Using Access-Technology-Specific Methods ..................19
5.9.1. Solution Description ...............................19
5.9.2. Analysis and Discussion ............................19
5.9.3. Summary ............................................20
6. Conclusion .....................................................20
7. Security Considerations ........................................21
8. Contributors ...................................................22
9. Acknowledgements ...............................................22
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................23
5.7. Learning the IPv6 Prefix of a Network's NAT64
Using Router ..............................................16
5.7.1. Solution Description ...............................16
5.7.2. Analysis and Discussion ............................16
5.7.3. Summary ............................................17
5.8. Using Application-Layer Protocols such as STUN ............17
5.8.1. Solution Description ...............................17
5.8.2. Analysis and Discussion ............................17
5.8.3. Summary ............................................19
5.9. Learning the IPv6 Prefix of a Network's NAT64
Using Access-Technology-Specific Methods ..................19
5.9.1. Solution Description ...............................19
5.9.2. Analysis and Discussion ............................19
5.9.3. Summary ............................................20
6. Conclusion .....................................................20
7. Security Considerations ........................................21
8. Contributors ...................................................22
9. Acknowledgements ...............................................22
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................23
Hosts and applications may benefit from learning if an IPv6 address is synthesized, which would mean that a NAT64 is used to reach the IPv4 network or Internet. There are two issues that can be addressed with solutions that allow hosts and applications to learn the Network-Specific Prefix (NSP) [RFC6052] used by the NAT64 [RFC6146] and the DNS64 [RFC6147] devices.
如果合成IPv6地址，主机和应用程序可能会从中受益，这意味着NAT64用于连接IPv4网络或Internet。有两个问题可以通过允许主机和应用程序了解NAT64[RFC6146]和DNS64[RFC6147]设备使用的网络特定前缀（NSP）[RFC6052]的解决方案来解决。
The first issue is finding out whether a particular address is synthetic and therefore learning the presence of a NAT64. For example, a dual-stack host with IPv4 connectivity could use this information to bypass NAT64 and use native IPv4 transport for destinations that are reachable through IPv4. We will refer this as 'Issue #1' throughout the document.
第一个问题是找出特定地址是否为合成地址，从而了解NAT64的存在。例如，具有IPv4连接的双栈主机可以使用此信息绕过NAT64，并对可通过IPv4访问的目标使用本机IPv4传输。我们将在整个文件中将其称为“问题1”。
The second issue is finding out how to construct from an IPv4 address an IPv6 address that will be routable to/by the NAT64. This is useful when IPv4 literals can be found in the payload of some protocol or applications do not use DNS to resolve names to addresses but know the IPv4 address of the destination by some other means. We will refer this as 'Issue #2' throughout the document.
第二个问题是了解如何从IPv4地址构造可路由到NAT64或由NAT64路由的IPv6地址。当可以在某些协议的有效负载中找到IPv4文本，或者应用程序不使用DNS将名称解析为地址，而是通过其他方式知道目标的IPv4地址时，这非常有用。我们将在整个文件中将其称为“问题2”。
Additionally, three other issues have to be considered by a solution addressing the first two issues: whether DNS is required ('Issue #3'), whether a solution supports changing NSP ('Issue #4'), and whether multiple NSPs are supported (either of the same or different length) for load-balancing purposes ('Issue #5').
此外，解决前两个问题的解决方案还必须考虑三个其他问题：是否需要DNS（“问题3”）、解决方案是否支持更改NSP（“问题4”），以及是否支持多个NSP（长度相同或不同）以实现负载平衡（“问题5”）。
This document analyzes all proposed solutions known at the time of writing for communicating if the synthesis is taking place, used address format, and the IPv6 prefix used by the NAT64 and DNS64. Based on the analysis we conclude whether the issue of learning the Network-Specific Prefix is worth solving and what would be the recommended solution(s) in that case.
本文档分析了在撰写本文时已知的所有拟议通信解决方案（如果正在进行合成）、使用的地址格式以及NAT64和DNS64使用的IPv6前缀。根据分析，我们得出结论，学习网络特定前缀的问题是否值得解决，在这种情况下，建议的解决方案是什么。
Address Synthesis
地址合成
Address synthesis is a mechanism, in the context of this document, where an IPv4 address is represented as an IPv6 address understood by a NAT64 device. The synthesized IPv6 address is formed by embedding an IPv4 address as-is into an IPv6 address prefixed with an NSP/WKP. It is assumed that the 'unused' suffix bits of the synthesized address are set to zero as described in Section 2.2 of [RFC6052].
在本文的上下文中，地址合成是一种机制，其中IPv4地址表示为NAT64设备理解的IPv6地址。合成的IPv6地址是通过将IPv4地址原样嵌入以NSP/WKP为前缀的IPv6地址而形成的。假设合成地址的“未使用”后缀位设置为零，如[RFC6052]第2.2节所述。
DNS64
DNS64
DNS extensions for network address translation from IPv6 clients to IPv4 servers: A network entity that synthesizes IPv6 addresses and AAAA records out of IPv4 addresses and A records, hence making IPv4 namespaces visible in the IPv6 namespace. DNS64 uses NSP and/or WKP in the synthesis process.
用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展：从IPv4地址和A记录中合成IPv6地址和AAAA记录的网络实体，从而使IPv4名称空间在IPv6名称空间中可见。DNS64在合成过程中使用NSP和/或WKP。
NAT64
NAT64
Network Address and protocol Translation mechanism for translating IPv6 packets to IPv4 packets and vice versa: A network entity that a host or an application may want to either avoid or utilize. IPv6 packets that hosts sent to addresses in the NSP and/or WKP are routed to NAT64.
用于将IPv6数据包转换为IPv4数据包或将IPv4数据包转换为IPv6数据包的网络地址和协议转换机制：主机或应用程序可能希望避免或利用的网络实体。主机发送到NSP和/或WKP中地址的IPv6数据包被路由到NAT64。
NSP
NSP
Network-Specific Prefix: A prefix chosen by a network administrator for NAT64/DNS64 to present IPv4 addresses in the IPv6 namespace.
网络特定前缀：网络管理员为NAT64/DNS64选择的前缀，用于在IPv6命名空间中显示IPv4地址。
WKP
WKP
Well-Known Prefix: A prefix (64:ff9b::/96) chosen by IETF and configured by a network administrator for NAT64/DNS64 to present IPv4 addresses in the IPv6 namespace.
众所周知的前缀：由IETF选择并由网络管理员为NAT64/DNS64配置的前缀（64:ff9b:：/96），用于在IPv6命名空间中显示IPv4地址。
This document analyzes different solutions with a focus on the following five issues:
本文档分析了不同的解决方案，重点关注以下五个问题：
Issue #1
问题1
The problem of distinguishing between synthesized and real IPv6 addresses, which allows a host to learn the presence of a NAT64 in the network.
区分合成和真实IPv6地址的问题，这允许主机了解网络中是否存在NAT64。
Issue #2
问题2
The problem of learning the NSP used by the access network and needed for local IPv6 address synthesis.
学习接入网络使用的NSP以及本地IPv6地址合成所需的NSP的问题。
Issue #3
第3期
The problem of learning the NSP or WKP used by the access network by a host not implementing DNS (hence, applications are unable to use DNS to learn the prefix).
未实现DNS的主机学习接入网络使用的NSP或WKP的问题（因此，应用程序无法使用DNS学习前缀）。
Issue #4
问题4
The problem of supporting changing NSP. The NSP learned by the host may become stale for multiple reasons. For example, the host might move to a new network that uses a different NSP, thus making the previously learned NSP stale. Also, the NSP used in the network may be changed due administrative reasons, thus again making the previously learned NSP stale.
支持更改NSP的问题。主机读入的NSP可能由于多种原因而过时。例如，主机可能会移动到使用不同NSP的新网络，从而使以前学习到的NSP过时。此外，由于管理原因，网络中使用的NSP可能会发生更改，从而再次使先前学习的NSP过时。
Issue #5
第5期
The problem of supporting multiple NSPs. A network may be configured with multiple NSPs for address synthesis. For example, for load-balancing purposes, each NAT64 device in the same network could be assigned their own NSP. It should be noted that learning a single NSP is enough for an end host to successfully perform local IPv6 address synthesis, but to avoid NAT64, the end host needs to learn all NSPs used by the access network.
支持多个NSP的问题。一个网络可以配置多个NSP用于地址合成。例如，出于负载平衡的目的，可以为同一网络中的每个NAT64设备分配自己的NSP。需要注意的是，学习单个NSP足以让终端主机成功执行本地IPv6地址合成，但为了避免NAT64，终端主机需要学习接入网络使用的所有NSP。
Certain applications, operating in protocol translation scenarios, can benefit from knowing the IPv6 prefix used by a local NAT64 of the attached access network. This applies to Scenario 1 ("IPv6 network to IPv4 Internet"), Scenario 5 ("An IPv6 network to an IPv4 network"), and Scenario 7 ("The IPv6 Internet to the IPv4 Internet") in the IPv4/IPv6 translation framework document [RFC6144]. Scenario 3 ("The IPv6 Internet to an IPv4 network") is not considered applicable herein as in that case, a NAT64 is located at the front of a remote IPv4 network, and a host in IPv6 Internet can benefit very little from learning the NSP IPv6 prefix used by the remote NAT64. The NAT64 prefix can be either a Network-Specific Prefix (NSP) or the Well-Known Prefix (WKP). Below is (an incomplete) list of various use cases where it is beneficial for a host or an application to know the presence of a NAT64 and the NSP/WKP:
在协议转换场景中运行的某些应用程序可以从了解连接的接入网络的本地NAT64使用的IPv6前缀中获益。这适用于IPv4/IPv6转换框架文档[RFC6144]中的场景1（“IPv6网络到IPv4互联网”）、场景5（“IPv6网络到IPv4网络”）和场景7（“IPv6互联网到IPv4互联网”）。场景3（“IPv6互联网到IPv4网络”）在此不适用，因为在这种情况下，NAT64位于远程IPv4网络的前端，IPv6互联网中的主机从学习远程NAT64使用的NSP IPv6前缀中获益甚微。NAT64前缀可以是网络特定前缀（NSP）或众所周知的前缀（WKP）。以下是各种用例的（不完整）列表，其中主机或应用程序了解NAT64和NSP/WKP的存在是有益的：
o Host-based DNSSEC validation. As is documented in DNS64 [RFC6147], Section 5.5, Point 3, synthetic AAAA records cannot be successfully validated in a host. In order to utilize NAT64, a security-aware and validating host has to perform the DNS64 function locally, and hence, it has to be able to learn WKP or proper NSP.
o 基于主机的DNSSEC验证。正如DNS64[RFC6147]第5.5节第3点所述，合成AAAA记录无法在主机中成功验证。为了利用NAT64，安全感知和验证主机必须在本地执行DNS64功能，因此，它必须能够学习WKP或适当的NSP。
o Protocols that use IPv4 literals. In IPv6-only access, native IPv4 connections cannot be created. If a network has NAT64, it is possible to synthesize an IPv6 address by combining the IPv4 literal and the IPv6 prefix used by NAT64. The synthesized IPv6 address can then be used to create an IPv6 connection.
o 使用IPv4文本的协议。在仅IPv6访问中，无法创建本机IPv4连接。如果网络具有NAT64，则可以通过组合IPv4文本和NAT64使用的IPv6前缀来合成IPv6地址。然后，可以使用合成的IPv6地址创建IPv6连接。
o Multicast translation [MCAST-TRANSLATOR] [V4V6MC-FRAMEWORK].
o 多播翻译[MCAST-TRANSLATOR][V4V6MC-FRAMEWORK]。
o URI schemes with host IPv4 address literals rather than domain names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1, ipp://192.0.2.1). A host can synthesize an IPv6 address out of the literal in the URI and use IPv6 to create a connection through NAT64.
o 具有主机IPv4地址文字而非域名的URI方案（例如。，http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1, ipp://192.0.2.1). 主机可以从URI中的文本合成IPv6地址，并使用IPv6通过NAT64创建连接。
o Updating the host's [RFC6724] preference table to prefer native prefixes over translated prefixes. This is useful as applications are more likely able to traverse through NAT44 than NAT64.
o 更新主机的[RFC6724]首选项表，使其首选本机前缀而不是翻译后的前缀。这是非常有用的，因为应用程序更有可能遍历NAT44而不是NAT64。
DNS64 cannot serve applications that are not using DNS or that obtain referral as an IPv4 literal address. One example application is the Session Description Protocol (SDP) [RFC4566], as used by the Real Time Streaming Protocol (RTSP) [RFC2326] and the Session Initiation Protocol (SIP) [RFC3261]. Other example applications include web browsers, as IPv4 address literals are still encountered in web pages
DNS64无法为未使用DNS或作为IPv4文本地址获得引用的应用程序提供服务。一个示例应用是由实时流协议（RTSP）[RFC2326]和会话发起协议（SIP）[RFC3261]使用的会话描述协议（SDP）[RFC4566]。其他示例应用程序包括web浏览器，因为网页中仍然会遇到IPv4地址文本
and URLs. Some of these applications could still work through NAT64, provided they were able to create locally valid IPv6 presentations of peers' IPv4 addresses.
和网址。其中一些应用程序仍然可以通过NAT64工作，前提是它们能够创建对等方IPv4地址的本地有效IPv6表示。
It is a known issue that passing IP address referrals often fails in today's Internet [REFERRAL-PS]. Synthesizing IPv6 addresses does not necessarily make the situation any better as the synthesized addresses utilizing NSP are not distinguishable from public IPv6 addresses for the referral receiver. However, the situation is not really any different from the current Internet as using public addresses does not really guarantee reachability (for example, due to firewalls). A node 'A' behind NAT64 may detect it is talking to a node 'B' through NAT64, in which case the node 'A' may want to avoid passing its IPv6 address as a referral to the node 'B'. The node 'B' on the IPv4 side of the NAT64 should not see the IPv6 address of a node 'A' from the IPv6 side of NAT64, and hence the node 'B' should not be able to pass IPv6 address referral to a node 'C'. Passing IPv4 presentation of the IPv6 address of the host 'A' to the node 'C' is bound to similar problems as passing a public IPv4 address of a host behind NAT44 as a referral. This analysis focuses on detecting NAT64 presence from the IPv6 side of NAT64.
众所周知，在今天的互联网上，传递IP地址转介通常会失败[REFERRAL-PS]。合成IPv6地址并不一定会使情况变得更好，因为使用NSP的合成地址与转介接收器的公共IPv6地址不可区分。然而，这种情况实际上与当前的互联网没有任何不同，因为使用公共地址并不能真正保证可达性（例如，由于防火墙）。NAT64后面的节点“A”可能检测到它正在通过NAT64与节点“B”通话，在这种情况下，节点“A”可能希望避免将其IPv6地址传递给节点“B”。NAT64的IPv4端的节点“B”不应从NAT64的IPv6端看到节点“a”的IPv6地址，因此节点“B”不应能够将IPv6地址引用传递给节点“C”。将主机“A”的IPv6地址的IPv4表示形式传递给节点“C”必然会遇到与将NAT44后面的主机的公共IPv4地址作为引用传递类似的问题。此分析侧重于从NAT64的IPv6端检测NAT64的存在。
5. Proposed Solutions to Learn about Synthesis and Network-Specific Prefix
5. 学习合成和网络特定前缀的建议解决方案
Section 3 of [RFC7050] describes a host behavior for discovering the presence of a DNS64 server and a NAT64 device, and heuristics for discovering the used NSP. A host requiring information for local IPv6 address synthesis or for NAT64 avoidance sends a DNS query for a AAAA record of a Well-Known IPv4-only Fully Qualified Domain Name (FQDN). If a host receives a negative reply, it knows that no DNS64 and NAT64 are in the network.
[RFC7050]的第3节描述了发现DNS64服务器和NAT64设备存在的主机行为，以及发现所用NSP的启发式方法。需要本地IPv6地址合成或NAT64避免信息的主机发送DNS查询，以查找已知的仅IPv4完全限定域名（FQDN）的AAAA记录。如果主机收到否定回复，则它知道网络中没有DNS64和NAT64。
If a host receives a AAAA reply, it knows the network must be utilizing IPv6 address synthesis. After receiving a synthesized AAAA resource record, the host may examine the received IPv6 address and use heuristics, such as "subtracting" the known IPv4 address out of synthesized IPv6 address, to find out the NSP.
如果主机收到AAAA回复，它知道网络必须使用IPv6地址合成。在接收到合成的AAAA资源记录后，主机可以检查接收到的IPv6地址，并使用试探法，例如从合成的IPv6地址中“减去”已知的IPv4地址，以找出NSP。
The PROs of the proposal are listed below:
该提案的优点如下：
+ Can be used to solve Issues #1 and #2.
+ 可用于解决问题1和问题2。
+ Solves Issue #4 via the lifetime of the DNS record.
+ 通过DNS记录的生存期解决问题4。
+ Can partially solve Issue #5 if multiple synthetic AAAA records are included in the response. Can find multiple address formats.
+ 如果响应中包含多个合成AAAA记录，则可以部分解决问题5。可以找到多种地址格式。
+ Does not necessarily require any standards effort.
+ 不一定需要任何标准工作。
+ Does not require host stack or resolver changes. All required logic and heuristics can be implemented in applications that are interested in learning about address synthesis taking place.
+ 不需要更改主机堆栈或解析程序。所有需要的逻辑和启发式都可以在对学习地址合成感兴趣的应用程序中实现。
+ The solution is backward compatible from the point of view of 'legacy' hosts and servers.
+ 从“遗留”主机和服务器的角度来看，该解决方案是向后兼容的。
+ Hosts or applications interested in learning about synthesis and the used NSP can do the "discovery" proactively at any time, for example, every time the host attaches to a new network.
+ 有兴趣了解合成和使用的NSP的主机或应用程序可以在任何时候（例如，每次主机连接到新网络时）主动进行“发现”。
+ Does not require explicit support from the network using NAT64.
+ 不需要使用NAT64的网络的明确支持。
The CONs of the proposal are listed below:
该提案的缺点如下：
- Requires hosting of a DNS resource record for the Well-Known Name.
- 需要为已知名称托管DNS资源记录。
- Does not provide a solution for Issue #3.
- 未提供问题3的解决方案。
- This method is only able to find one NSP even if a network is utilizing multiple NSPs (Issue #5) (unless DNS64 includes multiple synthetic AAAA records in response).
- 即使网络正在使用多个NSP，此方法也只能找到一个NSP（问题5）（除非DNS64包含多个合成AAAA记录作为响应）。
This is the only approach that can be deployed without explicit support from the network or the host. This approach could also complement explicit methods and be used as a fallback approach when explicit methods are not supported by an access network.
这是唯一可以在没有网络或主机明确支持的情况下部署的方法。该方法还可以补充显式方法，并在接入网络不支持显式方法时用作回退方法。
[SYNTH-FLAG-2011] defined a new Extension Mechanisms for DNS (EDNS0) option [RFC2671] that contained 3 flag bits (called SY-bits). The EDNS0 option served as an implicit indication of the presence of a DNS64 server and NAT64 device. The EDNS0 option SY-bit values other than '000' and '111' explicitly told the NSP prefix length. Only the DNS64 server could insert the EDNS0 option and the required SY-bits combination into the synthesized AAAA resource record.
[SYNTH-FLAG-2011]为包含3个标志位（称为SY位）的DNS（EDNS0）选项[RFC2671]定义了一个新的扩展机制。EDNS0选项用作存在DNS64服务器和NAT64设备的隐式指示。“000”和“111”以外的EDNS0选项SY位值明确告知NSP前缀长度。只有DNS64服务器才能将EDNS0选项和所需的SY位组合插入到合成的AAAA资源记录中。
The PROs of the proposal are listed below:
该提案的优点如下：
+ Can be used to solve Issue #1 and is designed to explicitly solve Issue #2.
+ 可用于解决问题1，设计用于明确解决问题2。
+ Solves Issue #4 via the lifetime of the DNS record.
+ 通过DNS记录的生存期解决问题4。
+ Can partially solve Issue #5 if multiple synthetic AAAA records are included in the response and all use same format.
+ 如果响应中包含多个合成AAAA记录，并且所有记录都使用相同的格式，则可以部分解决问题5。
+ The solution is backward compatible from the point of view of 'legacy' hosts and servers.
+ 从“遗留”主机和服务器的角度来看，该解决方案是向后兼容的。
+ Even if the solution is bundled with DNS queries and responses, a standardization of a new DNS record type is not required; rather, just defining a new EDNS0 option is needed.
+ 即使解决方案与DNS查询和响应捆绑在一起，也不需要新DNS记录类型的标准化；相反，只需要定义一个新的EDNS0选项。
+ EDNS0 option implementation requires changes only to DNS64 servers.
+ EDNS0选项实施仅需要更改DNS64服务器。
+ Does not require additional provisioning or management as the EDNS0 option is added automatically by the DNS64 server to the responses.
+ 不需要额外的资源调配或管理，因为DNS64服务器会自动将EDNS0选项添加到响应中。
+ Does not involve additional queries towards the global DNS infrastructure as EDNS0 logic can be handled within the DNS64 server.
+ 不涉及对全局DNS基础架构的其他查询，因为EDNS0逻辑可以在DNS64服务器内处理。
The CONs of the proposal are listed below:
该提案的缺点如下：
- Requires end hosts to support EDNS0 extension mechanisms [RFC6891].
- 要求终端主机支持EDNS0扩展机制[RFC6891]。
- Requires host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length.
- 需要对主机解析程序API（或标志、提示等）进行主机解析程序更改和机制/添加，以便向查询应用程序发送一条注释，说明已合成地址以及NSP前缀长度。
- Requires a modification to DNS64 servers to include the EDNS0 option to the synthesized responses.
- 需要修改DNS64服务器，以将EDNS0选项包含到合成响应中。
- Does not provide a solution for Issue #3.
- 未提供问题3的解决方案。
- EDNS0 flags and options are typically hop-by-hop only, severely limiting the applicability of these approaches, unless the EDNS0- capable DNS64 is the first DNS server the end host talks to, as it
- EDNS0标志和选项通常是逐跳的，严重限制了这些方法的适用性，除非支持EDNS0的DNS64是终端主机与之对话的第一个DNS服务器，因为它是
is otherwise not possible to guarantee that the EDNS0 option survives through all DNS proxies and servers in between.
否则，无法保证EDNS0选项通过这两者之间的所有DNS代理和服务器存活。
The solution based on the EDNS0 option works by extending the existing EDNS0 resource record. Although the solution has host resolver and DNS64 server impacts, the changes are limited to those entities (end host, applications) that are interested in learning the presence of NAT64 and the used NAT64 prefix. The provisioning and management overhead is minimal, if not non-existent, as the EDNS0 options are synthesized in a DNS64 server in a same manner as the synthesized AAAA resource records. Moreover, EDNS0 does not induce any load to DNS servers because no new RRType query is defined.
基于EDNS0选项的解决方案通过扩展现有EDNS0资源记录来工作。尽管该解决方案具有主机解析程序和DNS64服务器影响，但更改仅限于对了解NAT64的存在和使用的NAT64前缀感兴趣的实体（终端主机、应用程序）。由于EDNS0选项是以与合成AAAA资源记录相同的方式在DNS64服务器中合成的，因此即使不存在，供应和管理开销也是最小的。此外，EDNS0不会给DNS服务器带来任何负载，因为没有定义新的RRType查询。
[SYNTH-FLAG-2010] defined 3 new flag bits (called SY-bits) in the EDNS0 OPT [RFC2671] header that served as an implicit indication of the presence of a DNS64 server and NAT64 device. SY-bit values other than '000' or '111' explicitly told the NSP prefix length. Only the DNS64 server could insert the EDNS0 option and the required SY-bits combination into the synthesized AAAA resource record.
[SYNTH-FLAG-2010]在EDNS0 OPT[RFC2671]头中定义了3个新的标志位（称为SY位），作为DNS64服务器和NAT64设备存在的隐式指示。“000”或“111”以外的SY位值明确告知NSP前缀长度。只有DNS64服务器才能将EDNS0选项和所需的SY位组合插入到合成的AAAA资源记录中。
The PROs of the proposal are listed below:
该提案的优点如下：
+ Can be used to solve Issue #1 and is designed to explicitly solve Issue #2.
+ 可用于解决问题1，设计用于明确解决问题2。
+ Solves Issue #4 via the lifetime of the DNS record.
+ 通过DNS记录的生存期解决问题4。
+ Can partially solve Issue #5 if multiple synthetic AAAA records are included in the response and all use same format.
+ 如果响应中包含多个合成AAAA记录，并且所有记录都使用相同的格式，则可以部分解决问题5。
+ The solution is backward compatible from the point of view of 'legacy' hosts and servers.
+ 从“遗留”主机和服务器的角度来看，该解决方案是向后兼容的。
+ EDNS0 option implementation requires changes only to DNS64 servers.
+ EDNS0选项实施仅需要更改DNS64服务器。
+ Does not require additional provisioning or management as the EDNS0 option is added automatically by the DNS64 server to the responses.
+ 不需要额外的资源调配或管理，因为DNS64服务器会自动将EDNS0选项添加到响应中。
+ Does not involve additional queries towards the global DNS infrastructure as EDNS0 logic can be handled within the DNS64 server.
+ 不涉及对全局DNS基础架构的其他查询，因为EDNS0逻辑可以在DNS64服务器内处理。
The CONs of the proposal are listed below:
该提案的缺点如下：
- Requires end hosts to support EDNS0 extension mechanisms [RFC6891].
- 要求终端主机支持EDNS0扩展机制[RFC6891]。
- Consumes scarce flag bits from the EDNS0 OPT header.
- 使用EDNS0 OPT标头中的稀缺标志位。
- Requires a host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length.
- 需要主机冲突解决程序对主机冲突解决程序API（或标志、提示等）进行更改和机制/添加，以便向查询应用程序发送一条注释，说明已合成地址以及NSP前缀长度。
- Requires a modification to DNS64 servers to include the EDNS0 option to the synthesized responses.
- 需要修改DNS64服务器，以将EDNS0选项包含到合成响应中。
- Does not provide a solution for Issue #3.
- 未提供问题3的解决方案。
- EDNS0 flags and options are typically hop-by-hop only, severely limiting the applicability of these approaches, unless the EDNS0- capable DNS64 is the first DNS server the end host talks to, as it is otherwise not possible to guarantee that the EDNS0 option survives through all DNS proxies and servers in between.
- EDNS0标志和选项通常是逐跳的，严重限制了这些方法的适用性，除非支持EDNS0的DNS64是终端主机与之对话的第一个DNS服务器，否则无法保证EDNS0选项通过所有DNS代理和服务器存活。
This option is included here for the sake of completeness. The consumption of three bits of the limited EDNS0 OPT space can be considered unfavorable and hence is unlikely to be accepted.
为了完整起见，此处包含此选项。有限EDNS0 OPT空间的三位消耗可能被认为是不利的，因此不太可能被接受。
[DNS-A64] proposed a new DNS resource record (A64) that would be a record dedicated to storing a single IPv4-embedded IPv6 address [RFC6052]. Use of a dedicated resource record would allow a host to distinguish between real IPv6 addresses and synthesized IPv6 addresses. The solution requires the host to send a query for an A64 record. A positive answer with an A64 record informs the requesting host that the resolved address is not a native address but an IPv4- embedded IPv6 address. This would ease the local policies to prefer direct communications (i.e., avoid using IPv4-embedded IPv6 addresses when a native IPv6 address or a native IPv4 address is available). Applications may be notified via new or modified API.
[DNS-A64]提出了一个新的DNS资源记录（A64），该记录将专用于存储单个IPv4嵌入式IPv6地址[RFC6052]。使用专用资源记录将允许主机区分真实IPv6地址和合成IPv6地址。该解决方案要求主机发送A64记录的查询。带有A64记录的肯定回答会通知请求主机，解析的地址不是本机地址，而是嵌入IPv4的IPv6地址。这将使本地策略更倾向于直接通信（即，当本机IPv6地址或本机IPv4地址可用时，避免使用IPv4嵌入的IPv6地址）。可通过新的或修改的API通知应用程序。
The PROs of the proposal are listed below:
该提案的优点如下：
+ Can be used to solve Issues #1 and #5.
+ 可用于解决问题1和问题5。
+ Solves Issue #4 via the lifetime of the DNS record.
+ 通过DNS记录的生存期解决问题4。
+ The solution is backward compatible from the point of view of 'legacy' hosts and servers.
+ 从“遗留”主机和服务器的角度来看，该解决方案是向后兼容的。
+ Synthesized addresses can be used in authoritative DNS servers.
+ 合成地址可用于权威DNS服务器。
+ Maintains the reliability of the DNS model (i.e., a synthesized IPv6 address is presented as such and not as a native IPv6 address).
+ 保持DNS模型的可靠性（即，合成的IPv6地址是这样表示的，而不是本机IPv6地址）。
+ When both IPv4-converted and native IPv6 addresses are configured for the same QNAME, native addresses are preferred.
+ 当IPv4转换地址和本机IPv6地址都为同一QNAME配置时，本机地址是首选地址。
The CONs of the proposal are listed below:
该提案的缺点如下：
- Does not address Issues #2 or #3 in any way.
- 不以任何方式解决问题2或问题3。
- Requires a host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized.
- 需要对主机解析程序API（或标志、提示等）进行主机解析程序更改和机制/添加，以向查询应用程序发送地址已合成的注释。
- Requires standardization of a new DNS resource record type (A64) and the implementation of it in both resolvers and servers.
- 需要标准化新的DNS资源记录类型（A64）并在解析程序和服务器中实现它。
- Requires a coordinated deployment between different flavors of DNS servers within the provider to work deterministically.
- 需要在提供程序内不同风格的DNS服务器之间进行协调部署，才能确定地工作。
- Additional load on the DNS servers (3 queries -- A64, AAAA, and A -- may be issued by a dual-stack host).
- DNS服务器上的额外负载（3个查询——A64、AAAA和A——可能由双堆栈主机发出）。
- Does not help to identify synthesized IPv6 addresses if the session does not involve any DNS queries.
- 如果会话不涉及任何DNS查询，则无法帮助识别合成的IPv6地址。
While the proposed solution delivers explicit information about address synthesis taking place, solving the Issue #1, standardization of a new DNS record type might turn out to be too overwhelming a task as a solution for a temporary transition phase. Defining a new record type increases the load towards the DNS server as the host issues parallel A64, AAAA, and A queries.
虽然建议的解决方案提供了关于地址合成的明确信息，解决了问题#1，但作为临时过渡阶段的解决方案，新DNS记录类型的标准化可能过于艰巨。当主机发出并行A64、AAAA和a查询时，定义新记录类型会增加DNS服务器的负载。
[LEARN-PREFIX] proposed two DNS-based methods for discovering the presence of a DNS64 server and a NAT64 device. It also proposed a mechanism for discovering the used NSP.
[LEARN-PREFIX]提出了两种基于DNS的方法来发现DNS64服务器和NAT64设备的存在。它还提出了一种发现所用NSP的机制。
First, the document proposed that a host may learn the presence of a DNS64 server and a NAT64 device by receiving a TXT resource record with a well-known string (which the document proposes to be reserved by IANA) followed by the NAT64 unicast IPv6 address and the prefix length. The DNS64 server would add the TXT resource record into the DNS response.
首先，文件建议主机可通过接收TXT资源记录来了解DNS64服务器和NAT64设备的存在，该TXT资源记录具有众所周知的字符串（文件建议由IANA保留），后跟NAT64单播IPv6地址和前缀长度。DNS64服务器将把TXT资源记录添加到DNS响应中。
Second, the document proposed specifying a new URI-Enabled NAPTR (U-NAPTR) [RFC4848] application to discover the NAT64's IPv6 prefix and length. The input domain name is exactly the same as would be used for a reverse DNS lookup, derived from the host's IPv6 in the ".ip6.arpa." tree. The host doing the U-NAPTR queries may need multiple queries until the host finds the provisioned domain name with the correct prefix length. The response to a successful U-NAPTR query contains the unicast IPv6 address and the prefix length of the NAT64 device.
其次，该文件建议指定一个新的启用URI的NAPTR（U-NAPTR）[RFC4848]应用程序来发现NAT64的IPv6前缀和长度。输入域名与用于反向DNS查找的域名完全相同，该域名源自“.ip6.arpa.”树中主机的IPv6。执行U-NAPTR查询的主机可能需要多次查询，直到主机找到具有正确前缀长度的配置域名。对成功的U-NAPTR查询的响应包含单播IPv6地址和NAT64设备的前缀长度。
The PROs of the proposal are listed below:
该提案的优点如下：
+ Can be used to solve Issues #1 and #2.
+ 可用于解决问题1和问题2。
+ Solves Issue #4 via the lifetime of the DNS record.
+ 通过DNS记录的生存期解决问题4。
+ Does not require host stack or resolver changes if the required logic and heuristics are implemented in applications that are interested in learning about address synthesis taking place.
+ 如果所需的逻辑和启发式算法是在有兴趣了解正在发生的地址合成的应用程序中实现的，则不需要更改主机堆栈或解析器。
The CONs of the proposal are listed below:
该提案的缺点如下：
- Requires standardization of a Well-Known Name by IANA for the TXT resource record and/or standardization of a new U-NAPTR application.
- 需要IANA对TXT资源记录的知名名称进行标准化和/或对新的U-NAPTR应用程序进行标准化。
- Requires a host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length. However, it is possible that the U-NAPTR
- 需要主机冲突解决程序对主机冲突解决程序API（或标志、提示等）进行更改和机制/添加，以便向查询应用程序发送一条注释，说明已合成地址以及NSP前缀长度。然而，U-NAPTR可能
application logic is completely implemented by the application itself as noted in the PROs list.
应用程序逻辑完全由应用程序本身实现，如PROs列表中所述。
- The U-NAPTR prefix-learning method may entail multiple queries.
- U-NAPTR前缀学习方法可能需要多个查询。
- The U-NAPTR prefix-learning method requires provisioning of NSPs in the ".ip6.arpa." tree.
- U-NAPTR前缀学习方法要求在“.ip6.arpa.”树中提供NSP。
- RFC5507 [RFC5507] specifically recommends against reusing TXT resource records to expand DNS.
- RFC5507[RFC5507]特别建议不要重用TXT资源记录来扩展DNS。
- Requires configuration on the access network's DNS servers.
- 需要在访问网络的DNS服务器上进行配置。
- Does not provide a solution for Issue #3.
- 未提供问题3的解决方案。
Note: If the TXT record includes multiple NSPs, Issue #5 could be solved as well, but only if nodes as a group would select different NSPs, hence supporting load balancing. As this is not clear, this item is not yet listed under PROs or CONs.
注意：如果TXT记录包含多个NSP，则问题5也可以解决，但前提是作为一个组的节点将选择不同的NSP，从而支持负载平衡。由于这一点尚不清楚，该项目尚未列在赞成或反对项下。
The implementation of this solution requires some changes to the applications and resolvers in a similar fashion as in solutions in Sections 5.2, 5.3, and 5.4. Unlike the other DNS-based approaches, the U-NAPTR-based solution also requires provisioning information into the ".ip6.arpa." tree, which is no longer entirely internal to the provider hosting the NAT64/DNS64 service.
此解决方案的实施需要以与第5.2、5.3和5.4节中的解决方案类似的方式对应用程序和解析器进行一些更改。与其他基于DNS的方法不同，基于U-NAPTR的解决方案还需要在“.ip6.arpa.”树中提供信息，该树不再完全位于承载NAT64/DNS64服务的提供商内部。
The iterative approach of learning the NAT64 prefix in an U-NAPTR-based solution may result in multiple DNS queries, which can be considered more complex and inefficient compared to other DNS-based solutions.
在基于U-NAPTR的解决方案中学习NAT64前缀的迭代方法可能会导致多个DNS查询，与其他基于DNS的解决方案相比，这可能被认为更复杂、效率更低。
Two individual IETF documents specified DHCPv6-based approaches.
两份独立的IETF文件规定了基于DHCPv6的方法。
[LEARN-PREFIX] described a new DHCPv6 [RFC3315] option (OPTION_AFT_PREFIX_DHCP) that would contain the IPv6 unicast prefix, IPv6 Any-Source Multicast (ASM) prefix, and IPv6 Source-Specific Multicast (SSM) prefix (and their lengths) for the NAT64.
[LEARN-PREFIX]描述了一个新的DHCPv6[RFC3315]选项（选项_AFT_PREFIX_DHCP），该选项将包含NAT64的IPv6单播前缀、IPv6任意源多播（ASM）前缀和IPv6源特定多播（SSM）前缀（及其长度）。
[DHCPV6-SHARED-ADDRESS] proposed a DHCPv6 option that could be used to communicate to a requesting host the prefix used for building IPv4-converted IPv6 addresses together with the format type and
[DHCPV6-SHARED-ADDRESS]提出了一个DHCPV6选项，可用于与请求主机通信用于构建IPv4转换IPv6地址的前缀以及格式类型和地址
therefore also the used address synthesis algorithm. Provisioning the format type is required so as to be correctly handled by the NAT64-enabled devices deployed in a given domain.
因此也采用了地址合成算法。需要设置格式类型，以便由部署在给定域中的启用NAT64的设备正确处理。
The PROs of the proposal are listed below:
该提案的优点如下：
+ Can be used to solve Issues #1, #2, #3, and #4 via the lifetime of the DHCPv6 information.
+ 可以通过DHCPv6信息的生命周期来解决问题1、2、3和4。
+ Does not involve the DNS system. Therefore, applications that would not normally initiate any DNS queries can still learn the NAT64 prefix.
+ 不涉及DNS系统。因此，通常不会启动任何DNS查询的应用程序仍然可以学习NAT64前缀。
+ DHCPv6 is designed to provide various kinds of configuration information in a centrally managed fashion.
+ DHCPv6旨在以集中管理的方式提供各种配置信息。
The CONs of the proposal are listed below:
该提案的缺点如下：
- Change of NSP requires change to the DHCPv6 configuration.
- 更改NSP需要更改DHCPv6配置。
- Requires at least stateless DHCPv6 client on hosts.
- 主机上至少需要无状态DHCPv6客户端。
- Requires support on DHCPv6 clients, which is not trivial in all operating systems.
- 需要DHCPv6客户机上的支持，这在所有操作系统中都很重要。
- The DHCPv6-based solution involves changes and management on network-side nodes that are not really part of the NAT64/DNS64 deployment or aware of issues caused by NAT64/DNS64.
- 基于DHCPv6的解决方案涉及对网络端节点的更改和管理，这些节点实际上不是NAT64/DNS64部署的一部分，也不知道NAT64/DNS64引起的问题。
- A new DHCPv6 option is required along with the corresponding changes to both DHCPv6 clients and servers.
- 需要一个新的DHCPv6选项以及对DHCPv6客户端和服务器的相应更改。
Note: If DHCPv6 would include multiple NSPs, Issue #5 could be solved as well, but only if nodes as a group would select different NSPs, hence supporting load balancing. As this is not clear, this item is not yet listed under PROs or CONs.
注意：如果DHCPv6将包括多个NSP，那么问题5也可以解决，但前提是作为一个组的节点将选择不同的NSP，从而支持负载平衡。由于这一点尚不清楚，该项目尚未列在赞成或反对项下。
The DHCPv6-based solution would be a good solution as it hooks into the general IP configuration phase, allows easy updates when configuration information changes, and does not involve DNS in general. Use of DHCPv6 requires configuration changes on DHCPv6 clients and servers and, in some cases, may also require implementation changes. Furthermore, it is not obvious that all devices that need translation services would implement stateless
基于DHCPv6的解决方案将是一个很好的解决方案，因为它连接到通用IP配置阶段，允许在配置信息更改时轻松更新，并且通常不涉及DNS。使用DHCPv6需要更改DHCPv6客户端和服务器上的配置，在某些情况下，还可能需要更改实现。此外，并非所有需要翻译服务的设备都会实现无状态翻译
DHCPv6. For example, cellular Third Generation Partnership Project (3GPP) networks do not mandate hosts or networks to implement or deploy DHCPv6.
DHCPv6。例如，蜂窝式第三代合作伙伴计划（3GPP）网络不要求主机或网络实施或部署DHCPv6。
5.7. Learning the IPv6 Prefix of a Network's NAT64 Using Router Advertisements
5.7. 使用路由器广告学习网络NAT64的IPv6前缀
Revision three of [LEARN-PREFIX] described a new Router Advertisement (RA) [RFC4861] option (OPTION_AFT_PREFIX_RA) that would contain the IPv6 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix (and their lengths) for the NAT64. The RA option is essentially the same as for DHCPv6, discussed in Section 5.6.
[LEARN-PREFIX]的第三版描述了一个新的路由器公告（RA）[RFC4861]选项（选项_AFT_PREFIX_RA），该选项将包含NAT64的IPv6单播前缀、IPv6 ASM前缀和IPv6 SSM前缀（及其长度）。RA选项基本上与第5.6节中讨论的DHCPv6相同。
The PROs of the proposal are listed below:
该提案的优点如下：
+ Can be used to solve Issues #1, #2, and #3.
+ 可用于解决问题1、2和3。
+ Can solve Issue #4 if lifetime information can be communicated.
+ 如果可以沟通生命周期信息，则可以解决问题4。
The CONs of the proposal are listed below:
该提案的缺点如下：
- Requires configuration and management of all access routers to emit correct information in the RA. This could, for example, be accomplished somehow by piggybacking on top of routing protocols (which would then require enhancements to routing protocols).
- 需要配置和管理所有访问路由器，以在RA中发出正确的信息。例如，这可以通过在路由协议的基础上（这将需要对路由协议进行增强）以某种方式实现。
- In some operating systems, it may not be trivial to transfer information obtained in the RA to upper layers.
- 在某些操作系统中，将在RA中获得的信息传输到上层可能不是件小事。
- Requires changes to the host operating system's IP stack.
- 需要更改主机操作系统的IP堆栈。
- An NSP change requires changes to the access router configuration.
- NSP更改需要更改访问路由器配置。
- Requires standardization of a new option to the Router Advertisement, which is generally an unfavored approach.
- 需要标准化路由器广告的新选项，这通常是一种不利的方法。
- The RA-based solution involves changes and management on network-side nodes that are not really part of the NAT64/DNS64 deployment or aware of issues caused by NAT64/DNS64.
- 基于RA的解决方案涉及对网络端节点的更改和管理，这些节点实际上不是NAT64/DNS64部署的一部分，也不知道NAT64/DNS64引起的问题。
Note: If the RA would include multiple NSPs, Issue #5 could be solved as well, but only if nodes as a group would select different NSPs, hence supporting load balancing. As this is not clear, this item is not yet listed under PROs or CONs.
注意：如果RA将包括多个NSP，问题5也可以解决，但前提是作为一个组的节点将选择不同的NSP，从而支持负载平衡。由于这一点尚不清楚，该项目尚未列在赞成或反对项下。
The RA-based solution would be a good solution as it hooks into the general IP configuration phase, allows easy updates when configuration information changes, and does not involve DNS in general. However, generally introducing any changes to the Neighbor Discovery Protocol that are not absolutely necessary are unfavored due to the impact on both the network-side node and end host IP stack implementations.
基于RA的解决方案将是一个很好的解决方案，因为它连接到通用IP配置阶段，允许在配置信息更改时轻松更新，并且通常不涉及DNS。然而，由于对网络侧节点和终端主机IP堆栈实现的影响，通常不希望对邻居发现协议引入任何并非绝对必要的更改。
Compared to the DHCPv6 equivalent solution in Section 5.6, the management overhead is greater with the RA-based solution. With the DHCPv6-based solution, the management can be centralized to a few DHCPv6 servers compared to the RA-based solution where each access router is supposed to be configured with the same information.
与第5.6节中的DHCPv6等效解决方案相比，基于RA的解决方案的管理开销更大。使用基于DHCPv6的解决方案，与基于RA的解决方案相比，管理可以集中到几个DHCPv6服务器上，在该解决方案中，每个接入路由器都应该配置相同的信息。
Application-layer protocols, such as Session Traversal Utilities for NAT (STUN) [RFC5389], that define methods for endpoints to learn their external IP addresses could be used for NAT64 and NSP discovery. This document focuses on STUN, but the protocol could be something else as well.
应用层协议，例如NAT（STUN）[RFC5389]的会话遍历实用程序，为端点定义了解其外部IP地址的方法，可用于NAT64和NSP发现。本文档主要关注STUN，但协议也可能是其他内容。
A host must first use DNS to discover IPv6 representations of STUN servers' IPv4 addresses, because the host has no way to directly use IPv4 addresses to contact STUN servers.
主机必须首先使用DNS来发现STUN服务器IPv4地址的IPv6表示形式，因为主机无法直接使用IPv4地址联系STUN服务器。
After learning the IPv6 address of a STUN server, the STUN client sends a request to the STUN server containing a new 'SENDING-TO' attribute that tells the server the IPv6 address to which the client sent the request. In a reply, the server includes another new attribute called 'RECEIVED-AS', which contains the server's IP address on which the request arrived. After receiving the reply, the client compares the 'SENDING-TO' and 'RECEIVED-AS' attributes to find out an NSP candidate.
了解STUN服务器的IPv6地址后，STUN客户端向STUN服务器发送一个请求，其中包含一个新的“发送到”属性，该属性告诉服务器客户端向其发送请求的IPv6地址。在回复中，服务器包含另一个名为“RECEIVED-AS”的新属性，该属性包含请求到达的服务器的IP地址。收到回复后，客户端将比较“发送到”和“接收到”属性以找出NSP候选。
This solution is relatively similar to the one described in Section 5.1, but instead of using DNS, it uses STUN to get input for heuristic algorithms.
此解决方案与第5.1节中描述的解决方案相对类似，但它不使用DNS，而是使用STUN获取启发式算法的输入。
The PROs of the proposal are listed below:
该提案的优点如下：
+ Can be used to solve Issues #1 and #2.
+ 可用于解决问题1和问题2。
+ Does not require host changes or supportive protocols such as DNS or DHCPv6. All required logic and heuristics can be implemented in applications that are interested in learning about address synthesis taking place.
+ 不需要更改主机或支持DNS或DHCPv6等协议。所有需要的逻辑和启发式都可以在对学习地址合成感兴趣的应用程序中实现。
+ The solution is backward compatible from the point of view of 'legacy' hosts and servers.
+ 从“遗留”主机和服务器的角度来看，该解决方案是向后兼容的。
+ Hosts or applications interested in learning about synthesis and the used NSP can do the "discovery" proactively at any time, for example, every time the host attaches to a new network.
+ 有兴趣了解合成和使用的NSP的主机或应用程序可以在任何时候（例如，每次主机连接到新网络时）主动进行“发现”。
+ Does not require explicit support from the network using NAT64.
+ 不需要使用NAT64的网络的明确支持。
+ Can possibly be bundled to existing STUN message exchanges as new attributes, and hence, a client can learn its external IPv4 address and an NSP/WKP with the same exchange.
+ 可以作为新属性绑定到现有的STUN消息交换，因此，客户端可以通过同一交换了解其外部IPv4地址和NSP/WKP。
+ Can be used to confirm the heuristics by synthesizing the IPv6 address of another STUN server or by synthesizing the IPv6 address of first STUN server after the host has heuristically determined NSP using the method in Section 5.1, i.e., the connectivity test could be done with STUN.
+ 可通过合成另一个STUN服务器的IPv6地址或在主机使用第5.1节中的方法以启发式方式确定NSP后合成第一个STUN服务器的IPv6地址来确认启发式，即，可使用STUN进行连接性测试。
+ The true IPv4 destination address is used in NSP determination instead of the IPv4 address received from DNS. This may increase reliability.
+ NSP确定中使用的是真实的IPv4目标地址，而不是从DNS接收的IPv4地址。这可能会提高可靠性。
+ The same STUN improvement could also be used to reveal NAT66 on the data path, if the 'RECEIVED-AS' would contain a different IPv6 address from 'SENDING-TO'.
+ 如果“RECEIVED-AS”包含与“SENDING-to”不同的IPv6地址，那么同样的STUN改进也可以用于在数据路径上显示NAT66。
The CONs of the proposal are listed below:
该提案的缺点如下：
- Requires a server on the network to respond to the queries.
- 需要网络上的服务器响应查询。
- Requires standardization if done as an extension to STUN.
- 如果作为眩晕的扩展，则需要标准化。
- The solution involves changes and management on network side nodes that are not really part of the NAT64/DNS64 deployment or aware of issues caused by NAT64/DNS64.
- 该解决方案涉及对网络端节点的更改和管理，这些节点实际上不属于NAT64/DNS64部署的一部分，也不知道NAT64/DNS64引起的问题。
- Does not solve Issue #3 if the STUN server's synthetic IPv6 address is provisioned via DNS.
- 如果通过DNS提供STUN服务器的合成IPv6地址，则无法解决问题3。
- Does not solve Issue #4 as the STUN server would not be aware of the learned NSP's validity time.
- 无法解决问题#4，因为STUN服务器不知道学习到的NSP的有效时间。
- Does not solve Issue #5 as the STUN server would not be aware of multiple NSP prefixes.
- 无法解决问题5，因为STUN服务器不知道多个NSP前缀。
- Heavyweight solution especially if an application does not otherwise support STUN.
- 重量级解决方案，尤其是在应用程序不支持STUN的情况下。
An approach based on STUN or a similar protocol is a second way to solve the problem without explicit access-network support. The heuristics for NSP discovery would still be in the client; however, the result may be more reliable as an actual IPv4 destination address is compared to the IPv6 address used in sending. The additional benefit of STUN is that the client learns its public IPv4 address with the same message exchange. STUN could also be used as the connectivity test tool if the client would first heuristically determine NSP out of DNS as described in Section 5.1, synthesize the IPv6 representation of the STUN server's IPv4 address, and then test connectivity to the STUN server.
基于STUN或类似协议的方法是解决问题的第二种方法，无需明确的接入网络支持。NSP发现的启发式方法仍在客户端中；但是，与发送中使用的IPv6地址相比，实际IPv4目标地址可能更可靠。STUN的另一个好处是，客户端通过相同的消息交换学习其公共IPv4地址。如果客户机首先按照第5.1节所述试探性地从DNS中确定NSP，综合STUN服务器IPv4地址的IPv6表示，然后测试与STUN服务器的连接，则STUN也可以用作连接测试工具。
As an additional benefit, the STUN improvement could be used for NAT66 discovery.
作为另一个好处，STUN改进可用于NAT66发现。
5.9. Learning the IPv6 Prefix of a Network's NAT64 Using Access-Technology-Specific Methods
5.9. 使用特定于访问技术的方法学习网络NAT64的IPv6前缀
Several link layers on different access systems have attachment time signaling protocols for negotiating various parameters that are used later on with the established link-layer connection. Examples of such include the 3GPP Non-Access-Stratum (NAS) signaling protocol [NAS.24.301] among other link layers and tunneling solutions. There, using NAS signaling it could be possible to list all NSPs with their respective prefix lengths in generic protocol configuration option containers during the network access establishment. The lack of NSPs in protocol configuration option containers would be an implicit indication that there is no NAT64 present in the network.
不同接入系统上的多个链路层具有附件时间信令协议，用于协商稍后与已建立的链路层连接一起使用的各种参数。此类示例包括3GPP非接入层（NAS）信令协议[NAS.24.301]以及其他链路层和隧道解决方案。在这里，使用NAS信令，可以在网络接入建立期间在通用协议配置选项容器中列出所有NSP及其各自的前缀长度。协议配置选项容器中缺少NSP将暗示网络中不存在NAT64。
The PROs of the proposal are listed below:
该提案的优点如下：
+ Can be used to solve Issues #1, #2, #3, and #5.
+ 可用于解决问题1、2、3和5。
+ Can solve Issue #4 if lifetime information is also communicated.
+ 如果还传达了生命周期信息，则可以解决问题4。
The CONs of the proposal are listed below:
该提案的缺点如下：
- Requires configuration and management of all access routers/ gateways to emit correct information in "link/lower-layer" signaling. If NAT64 functionality is implemented into the access router/gateway that terminates the generic protocol configuration exchange, then the configuration management can be automated.
- 需要配置和管理所有接入路由器/网关，以在“链路/较低层”信令中发出正确的信息。如果NAT64功能在终止通用协议配置交换的访问路由器/网关中实现，则配置管理可以自动化。
- In some operating systems, it may not be trivial to transfer information obtained in "link/lower layers" to upper layers.
- 在某些操作系统中，将在“链接/较低层”中获得的信息传输到较高层可能并不简单。
- An NSP change may require changes to the access router/gateway configuration.
- NSP更改可能需要更改访问路由器/网关配置。
- Requires standardization of a new configuration parameter exchange/container for each access system of interest. The proposed solution is indeed specific to each access technology.
- 需要为每个感兴趣的访问系统标准化新的配置参数交换/容器。建议的解决方案确实针对每种接入技术。
The solution based on access technology would be a good solution as it hooks into general network access establishment phase, allows easy updates when configuration information changes, and does not involve DNS in general. However, generally introducing any changes to the link/lower layers is a long and slow process, and changes would need to be done for all access technologies/systems that are used with NAT64.
基于访问技术的解决方案将是一个很好的解决方案，因为它连接到一般的网络访问建立阶段，允许在配置信息更改时轻松更新，并且通常不涉及DNS。然而，通常对链路/较低层进行任何更改都是一个漫长而缓慢的过程，需要对NAT64使用的所有接入技术/系统进行更改。
Compared to the RA-equivalent solution in Section 5.7, the management overhead is equivalent or even less than the RA-based solution.
与第5.7节中的RA等效解决方案相比，管理开销与基于RA的解决方案相当，甚至更低。
Our conclusion is to recommend publishing the Well-Known DNS Name heuristic discovery-based method as a Standards Track IETF document for applications and host implementors to implement as-is.
我们的结论是建议将众所周知的基于DNS名称的启发式发现方法作为标准跟踪IETF文档发布，以供应用程序和主机实现人员按原样实现。
As a general principle, we prefer to have as minimal a solution as possible, avoid impacts to entities not otherwise involved in the protocol translation scheme, minimize host impact, and require minimal to no operational effort on the network side.
作为一般原则，我们希望尽可能少地使用解决方案，避免对协议转换方案中未涉及的实体造成影响，最大限度地减少主机影响，并且在网络端不需要任何操作工作。
Of the different issues, we give the most weight to Issues #1 and #2. We do not give much weight to Issue #3, as cases where hosts need to synthesize IPv6 addresses but do not have DNS available seem rare to us. Even if an application does not otherwise utilize DNS, it ought to be able to trigger a simple DNS query to find out WKP/NSP. Issue #4 is handled by the majority of solutions, and Issue #5 is
在不同的问题中，我们最重视问题1和问题2。我们不太重视第3个问题，因为主机需要合成IPv6地址但没有可用DNS的情况对我们来说似乎很少见。即使应用程序没有使用DNS，它也应该能够触发一个简单的DNS查询来查找WKP/NSP。问题4由大多数解决方案处理，问题5由
considered to be mostly insignificant as even if individual hosts would use only one NSP at a time, different hosts would be using different NSPs, hence supporting load-balancing targets. Only one of the discussed solutions, see Section 5.6, supports learning of possible new or indicating support for multiple algorithms for address synthesis other than the one described in [RFC6052].
这被认为是无关紧要的，因为即使单个主机一次只使用一个NSP，不同的主机也会使用不同的NSP，因此支持负载平衡目标。所讨论的解决方案中，只有一种（见第5.6节）支持学习可能的新算法或指示支持多种地址合成算法，而不是[RFC6052]中所述的算法。
The DNS64 entity has to be configured with WKP/NSP in order for it to do synthesis; hence, using DNS also for delivering the synthesis information sounds logical. The fact that the synthesis information fate-shares the information received in the DNS response is a valuable attribute and reduces the possible distribution of stale prefix information. However, having all DNS64 servers support explicit WKP/NSP discovery (ENDS0, A64, and DNS SRV record approaches) is difficult to arrange. The U-NAPTR-based approach would require provisioning information into the ".ip6.arpa." tree, which would not be entirely internal for the provider. Use of DHCPv6 would involve additional trouble configuring DHCPv6 servers and ensuring DHCPv6 clients are in place; it would also involve ensuring that the NAT64 and DHCPv6 (and possibly even some DNS64 servers) are all in sync. RA-based mechanisms are operationally expensive as configuration would have to be placed and maintained in the access routers. Furthermore, both DHCPv6 and RA-based mechanisms involve entities that do not otherwise need to be aware of protocol translation (they only need to know DNS server addresses). Finally, regarding the use of STUN, a host does not need to implement STUN whereas DNS is, in practice, required anyway. Also, the STUN protocol would need to be changed on both the host and network side to support the discovery of NAT64 and WKP/NSP.
DNS64实体必须配置WKP/NSP才能进行合成；因此，使用DNS来传递合成信息听起来是合乎逻辑的。合成信息共享在DNS响应中接收的信息这一事实是一个有价值的属性，并减少了过时前缀信息的可能分布。但是，让所有DNS64服务器支持显式WKP/NSP发现（ENDS0、A64和DNS SRV记录方法）很难安排。基于U-NAPTR的方法将需要在“.ip6.arpa.”树中提供信息，而该树对于提供者来说并不完全是内部的。使用DHCPv6将涉及配置DHCPv6服务器和确保DHCPv6客户端就位的额外问题；它还包括确保NAT64和DHCPv6（甚至可能是一些DNS64服务器）都是同步的。基于RA的机制在操作上非常昂贵，因为必须在接入路由器中放置和维护配置。此外，基于DHCPv6和RA的机制都涉及实体，这些实体不需要知道协议转换（它们只需要知道DNS服务器地址）。最后，关于STUN的使用，主机不需要实现STUN，而实际上无论如何都需要DNS。此外，需要在主机和网络端更改STUN协议，以支持NAT64和WKP/NSP的发现。
The security considerations are essentially similar to those described in DNS64 [RFC6147]. The document also talks about man-in-the-middle and denial-of-service attacks caused by forging of information required for IPv6 synthesis from corresponding IPv4 addresses. Forgery of information required for IPv6 address synthesis may allow an attacker to insert itself as a middle man or to perform a denial-of-service attack. The DHCPv6 and RA-based approaches are vulnerable to forgery as the attacker may send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6 authentication [RFC3315] or Secure Neighbor Discovery (SEND) [RFC3971] are used). If the attacker is already able to modify and forge DNS responses (flags, addresses of known IPv4-only servers, records, etc.), ability to influence local address synthesis is likely of low additional value. Also, a DNS-based mechanism is only as secure as the method used to configure the DNS server's IP addresses on the host. Therefore, if, for example, the host cannot trust DHCPv6, it cannot
安全注意事项基本上类似于DNS64[RFC6147]中所述的注意事项。该文件还讨论了中间人攻击和拒绝服务攻击，这些攻击是由伪造相应IPv4地址合成IPv6所需的信息引起的。伪造IPv6地址合成所需的信息可能会使攻击者以中间人身份插入或执行拒绝服务攻击。基于DHCPv6和RA的方法容易被伪造，因为攻击者可能发送伪造的RAs或充当恶意DHCPv6服务器（除非使用DHCPv6身份验证[RFC3315]或安全邻居发现（send）[RFC3971]）。如果攻击者已经能够修改和伪造DNS响应（标志、已知仅IPv4服务器的地址、记录等），则影响本地地址合成的能力可能附加值较低。此外，基于DNS的机制仅与用于在主机上配置DNS服务器IP地址的方法一样安全。因此，例如，如果主机不能信任DHCPv6，则它不能
trust the DNS server learned via DHCPv6 either, unless the host has a way to authenticate all DNS responses (e.g., via DNSSEC [RFC4033]).
也可以信任通过DHCPv6学习的DNS服务器，除非主机能够验证所有DNS响应（例如，通过DNSSEC[RFC4033]）。
The following individual contributed text to this document.
以下个人为本文件提供了文本。
Mohamed Boucadair France Telecom Rennes, 35000 France
Mohamed Boucadair法国电信雷恩，35000法国
EMail: mohamed.boucadair@orange-ftgroup.com
EMail: mohamed.boucadair@orange-ftgroup.com
The authors would like to thank Dan Wing and Christian Huitema, especially for the STUN idea and for their valuable comments and discussions.
作者要感谢Dan Wing和Christian Huitema，特别是他们提出的STUN想法以及宝贵的评论和讨论。
Jouni Korhonen would like to specifically thank Nokia Siemens Networks as he completed the majority of this document while employed there.
Jouni Korhonen特别感谢诺基亚西门子网络公司，因为他在该公司工作期间完成了本文件的大部分内容。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[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月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[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月。
[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007.
[RFC4848]Daigle，L.，“使用URI和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 48482007年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[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月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724]Thaler，D.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月。
[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月。
[DHCPV6-SHARED-ADDRESS] Boucadair, M., Levis, P., Grimault, J., Savolainen, T., and G. Bajko, "Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP Addresses Solutions", Work in Progress, December 2009.
[DHCPV6-SHARED-ADDRESS]Boucadair，M.，Levis，P.，Grimault，J.，Savolainen，T.，和G.Bajko，“共享IP地址解决方案的动态主机配置协议（DHCPV6）选项”，正在进行的工作，2009年12月。
[DNS-A64] Boucadair, M. and E. Burgey, "A64: DNS Resource Record for IPv4-Embedded IPv6 Address", Work in Progress, September 2010.
[DNS-A64]Boucadair，M.和E.Burgey，“A64:IPv4嵌入式IPv6地址的DNS资源记录”，正在进行的工作，2010年9月。
[LEARN-PREFIX] Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/ IPv4 Translator", Work in Progress, October 2009.
[LEARN-PREFIX]Wing，D.，“学习网络IPv6/IPv4转换器的IPv6前缀”，正在进行的工作，2009年10月。
[MCAST-TRANSLATOR] Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An IPv4 - IPv6 multicast translator", Work in Progress, December 2010.
[MCAST-TRANSLATOR]Venaas，S.，Asaeda，H.，SUZUKI，S.，和T.Fujisaki，“IPv4-IPv6多播转换器”，正在进行的工作，2010年12月。
[NAS.24.301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010, <http://www.3gpp.org/ftp/Specs/html-info/24301.htm>.
[NAS.24.301]3GPP，“演进分组系统（EPS）的非接入层（NAS）协议”，3GPP TS 24.301 8.8.02010年12月<http://www.3gpp.org/ftp/Specs/html-info/24301.htm>.
[REFERRAL-PS] Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement for Referral", Work in Progress, February 2011.
[REFERRAL-PS]Carpenter，B.，Jiang，S.，和Z.Cao，“转诊问题陈述”，在建工程，2011年2月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[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月。
[RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design Choices When Expanding the DNS", RFC 5507, April 2009.
[RFC5507]IAB，Faltstrom，P.，Austein，R.，和P.Koch，“扩展DNS时的设计选择”，RFC 5507，2009年4月。
[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月。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[RFC6891]Damas，J.，Graff，M.，和P.Vixie，“DNS（EDNS（0））的扩展机制”，STD 75，RFC 6891，2013年4月。
[SYNTH-FLAG-2010] Korhonen, J. and T. Savolainen, "EDNS0 Option for Indicating AAAA Record Synthesis and Format", Work in Progress, July 2010.
[SYNTH-FLAG-2010]Korhonen，J.和T.Savolainen，“用于指示AAAA记录合成和格式的EDNS0选项”，正在进行的工作，2010年7月。
[SYNTH-FLAG-2011] Korhonen, J. and T. Savolainen, "EDNS0 Option for Indicating AAAA Record Synthesis and Format", Work in Progress, February 2011.
[SYNTH-FLAG-2011]Korhonen，J.和T.Savolainen，“用于指示AAAA记录合成和格式的EDNS0选项”，正在进行的工作，2011年2月。
[V4V6MC-FRAMEWORK] Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 Multicast Translation", Work in Progress, June 2011.
[V4V6MC-FRAMEWORK]Venaas，S.，Li，X.，和C.Bao，“IPv4/IPv6多播转换框架”，正在进行的工作，2011年6月。
Authors' Addresses
作者地址
Jouni Korhonen (editor) Broadcom Porkkalankatu 24 FIN-00180 Helsinki Finland
Jouni Korhonen（编辑）Broadcom Porkkalankatu 24 FIN-00180芬兰赫尔辛基
EMail: jouni.nospam@gmail.com
EMail: jouni.nospam@gmail.com
Teemu Savolainen (editor) 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