Internet Engineering Task Force (IETF) S. Jiang
Request for Comments: 6563 Huawei Technologies Co., Ltd
Category: Informational D. Conrad
ISSN: 2070-1721 Cloudflare, Inc.
B. Carpenter
Univ. of Auckland
March 2012
Internet Engineering Task Force (IETF) S. Jiang
Request for Comments: 6563 Huawei Technologies Co., Ltd
Category: Informational D. Conrad
ISSN: 2070-1721 Cloudflare, Inc.
B. Carpenter
Univ. of Auckland
March 2012
Moving A6 to Historic Status
将A6移至历史地位
Abstract
摘要
This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators.
本文件概述了与A6记录使用相关的问题，讨论了当前状态，并将RFC 2874移至历史状态，为实施者和操作员提供了清晰的信息。
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/rfc6563.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6563.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 and Background .....................................2
1.1. Standards Action Taken .....................................3
2. A6 Issues .......................................................3
2.1. Resolution Latency .........................................3
2.2. Resolution Failure .........................................3
2.3. Cross Administrative Domains ...............................4
2.4. Difficult Maintenance ......................................4
2.5. Existence of Multiple RR Types for One Purpose is Harmful ..4
2.6. Higher Security Risks ......................................4
3. Current Usage of A6 .............................................5
3.1. Reasons for Current A6 Usage ...............................5
4. Moving A6 to Historic Status ....................................6
4.1. Impact on Current A6 Usage .................................6
4.2. Transition Phase for Current A6 Usage ......................6
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Acknowledgments .................................................6
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................7
1. Introduction and Background .....................................2
1.1. Standards Action Taken .....................................3
2. A6 Issues .......................................................3
2.1. Resolution Latency .........................................3
2.2. Resolution Failure .........................................3
2.3. Cross Administrative Domains ...............................4
2.4. Difficult Maintenance ......................................4
2.5. Existence of Multiple RR Types for One Purpose is Harmful ..4
2.6. Higher Security Risks ......................................4
3. Current Usage of A6 .............................................5
3.1. Reasons for Current A6 Usage ...............................5
4. Moving A6 to Historic Status ....................................6
4.1. Impact on Current A6 Usage .................................6
4.2. Transition Phase for Current A6 Usage ......................6
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Acknowledgments .................................................6
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................7
The IETF began standardizing two different DNS protocol enhancements for IPv6 addresses in DNS records: AAAA was specified in 1995 as a Proposed Standard [RFC1886] and later in 2003 as a Draft Standard [RFC3596], and A6 appeared in 2000 as a Proposed Standard [RFC2874].
IETF开始为DNS记录中的IPv6地址标准化两种不同的DNS协议增强：AAAA于1995年被指定为提议的标准[RFC1886]，后来于2003年被指定为标准草案[RFC3596]，A6于2000年作为提议的标准[RFC2874]出现。
The existence of multiple ways to represent an IPv6 address in the DNS has led to confusion and conflicts about which of these protocol enhancements should be implemented and/or deployed. Having more than one choice of how IPv6 addresses are to be represented within the DNS can be argued to have led to delays in the deployment of IPv6. In 2002, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)" [RFC3363] moved A6 to Experimental status, with an aim of clearing up any confusion in this area. [RFC3363] and [RFC3364] compared AAAA and A6, and examined many of the issues in the A6 standard; these issues are summarized in this document.
DNS中存在多种表示IPv6地址的方法，这导致了关于应实施和/或部署哪些协议增强的混淆和冲突。对于如何在DNS中表示IPv6地址有多个选择可能会导致IPv6部署延迟。2002年，“在域名系统（DNS）中代表互联网协议版本6（IPv6）地址”[RFC3363]将A6移至实验状态，目的是消除这方面的任何混乱。[RFC3363]和[RFC3364]比较了AAAA和A6，并研究了A6标准中的许多问题；本文件概述了这些问题。
After ten years, the Experimental status of A6 continues to result in confusion and parallel deployment of both A6 and AAAA, albeit AAAA predominates by a large degree. In recent IPv6 transition tests and deployments, some providers informally mentioned A6 support as a possible future choice.
十年后，A6的实验状态继续导致A6和AAAA的混乱和并行部署，尽管AAAA在很大程度上占主导地位。在最近的IPv6过渡测试和部署中，一些提供商非正式地提到A6支持是未来可能的选择。
This document provides a brief summary of the issues related to the use of A6 records and discusses the current usage status of A6. Given the implications of A6 on the DNS architecture and the state of A6 deployment, this document moves RFC 2874 [RFC2874] to Historic status, thereby clarifying that implementers and operators should represent IPv6 addresses in the DNS by using AAAA records only.
本文档简要概述了与A6记录使用相关的问题，并讨论了A6的当前使用状态。考虑到A6对DNS体系结构和A6部署状态的影响，本文档将RFC 2874[RFC2874]移至历史状态，从而澄清了实施者和运营商应仅通过使用AAAA记录在DNS中表示IPv6地址。
Per this document, the status of RFC 2874 has been changed from Experimental to Historic.
根据本文件，RFC 2874的状态已从实验性更改为历史性。
This section summarizes the known issues associated with the use of A6 resource records (RRs), including the analyses explored in [RFC3363]. The reader is encouraged to review that document to fully understand the issues relating to A6.
本节总结了与A6资源记录（RRs）使用相关的已知问题，包括[RFC3363]中探讨的分析。鼓励读者阅读该文件，以充分了解与A6相关的问题。
Resolving an A6 record chain can involve resolving a series of subqueries that are likely to be independent of each other. Each of these subqueries takes a non-negligible amount of time unless the answer already happens to be in the resolver's cache. In the worst-case scenario, the time spent resolving an N-link chain A6 record would be the sum of the latency resulting from each of the N resolutions. As a result, long A6 chains would likely increase user frustration due to an excessive wait time for domain names to resolve.
解析A6记录链可能涉及解析一系列可能相互独立的子查询。每个子查询都会花费不可忽略的时间，除非答案恰好已经在解析器的缓存中。在最坏的情况下，解析N-link chain A6记录所花费的时间将是N个解析中的每一个所导致的延迟的总和。因此，由于域名解析的等待时间过长，长A6链可能会增加用户的挫败感。
In practice, it is very hard to derive a reasonable timeout-handling strategy for the reassembly of all the results from A6 subqueries. It has proved difficult to decide multiple timeout parameters, including: (1) the communication timeout for a single A6 fragment, (2) the communication timeout for the IPv6 address itself (total time needed for reassembly), and (3) the Time to Live (TTL) timeout for A6 fragment records.
在实践中，很难为重新组合A6子查询的所有结果推导出合理的超时处理策略。事实证明，很难确定多个超时参数，包括：（1）单个A6片段的通信超时，（2）IPv6地址本身的通信超时（重新组装所需的总时间），以及（3）A6片段记录的生存时间（TTL）超时。
The probability of A6 resolution failure during the process of resolving an N-link A6 chain is the sum of the probabilities of failure of each subquery, since each of the queries involved in resolving an A6 chain has a nonzero probability of failure, and an A6 resolution cannot complete until all subqueries have succeeded.
在解析N-link A6链的过程中，A6解析失败的概率是每个子查询的失败概率之和，因为解析A6链所涉及的每个查询的失败概率都不是零，并且A6解析在所有子查询成功之前无法完成。
Furthermore, the failure may happen at any link among 1~N of an N-Link A6 chain. Therefore, it would take an indeterminate time to return a failure result.
此外，故障可能发生在N-链节A6链的1~N个链节之间的任何链节上。因此，返回故障结果需要一段不确定的时间。
One of the primary motivations for the A6 RR is to facilitate renumbering and multihoming, where the prefix name field in the A6 RR points to a target that is not only outside the DNS zone containing the A6 RR, but is administered by a different organization entirely.
A6 RR的主要动机之一是促进重新编号和多归属，其中A6 RR中的前缀名称字段指向的目标不仅位于包含A6 RR的DNS区域之外，而且完全由不同的组织管理。
While pointers out-of-zone are not a problem per se, experience both with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that pointers to other organizations are often not maintained properly, perhaps because they're less amenable to automation than pointers within a single organization would be.
虽然分区外的指针本身不是问题，但在in-ADDR.ARPA树中使用glue RRs和PTR RRs的经验表明，指向其他组织的指针通常没有得到正确维护，可能是因为它们不像单个组织内的指针那样易于自动化。
In A6, changes to components of an RR are not isolated from the use of the composite IPv6 address. Any change to a non-128-bit component of an A6 RR may cause change to a large number of IPv6 addresses. The relationship dependency actually makes the maintenance of addresses much more complicated and difficult. Without understanding these complicated relationships, any arbitrary change for a non-128-bit A6 RR component may result in undesired consequences.
在A6中，对RR组件的更改不会与复合IPv6地址的使用隔离开来。A6 RR的非128位组件的任何更改都可能导致大量IPv6地址的更改。关系依赖实际上使地址的维护更加复杂和困难。在不了解这些复杂关系的情况下，非128位A6 RR组件的任何任意更改都可能导致不期望的结果。
Multiple correlative subcomponents of A6 records may have different TTLs, which can make cache maintenance very complicated.
A6记录的多个相关子组件可能具有不同的TTL，这会使缓存维护非常复杂。
If both AAAA and A6 records were widely deployed in the global DNS, it would impose more query delays to the client resolvers. DNS clients have insufficient knowledge to choose between AAAA and A6 queries, requiring local policy to determine which record type to query. If local policy dictates parallel queries for both AAAA and A6 records, and if those queries returned different results for any reason, the clients would have no knowledge about which address to choose.
如果AAAA和A6记录都广泛部署在全局DNS中，则会给客户端解析程序带来更多的查询延迟。DNS客户端没有足够的知识在AAAA和A6查询之间进行选择，需要本地策略来确定要查询的记录类型。如果本地策略要求对AAAA和A6记录进行并行查询，并且如果这些查询出于任何原因返回不同的结果，那么客户端将不知道选择哪个地址。
The dependency relationships inherent in A6 chains increase security risks. An attacker may successfully attack a single subcomponent of an A6 record, which would then influence many query results, and possibly every host on a large site. There is also the danger of unintentionally or maliciously creating a resolution loop -- an A6
A6链中固有的依赖关系增加了安全风险。攻击者可以成功攻击A6记录的单个子组件，这将影响许多查询结果，并可能影响大型站点上的每台主机。此外，还存在无意或恶意创建分辨率循环（A6）的危险
chain may create an infinite loop because an out of zone pointer may point back to another component farther down the A6 chain.
链可能会创建一个无限循环，因为区外指针可能会指向A6链下游的另一个组件。
Full support for IPv6 in the global DNS can be argued to have started when the first IPv6 records were associated with root servers in early 2008.
全球DNS中对IPv6的完全支持可以说是在2008年初第一个IPv6记录与根服务器关联时开始的。
One of the major DNS server software packages, BIND9 [BIND], supports both A6 and AAAA, and is unique among the major DNS resolvers in that certain versions of the BIND9 resolver will attempt to query for A6 records and follow A6 chains.
主要DNS服务器软件包之一BIND9[BIND]支持A6和AAAA，并且在主要DNS解析程序中是唯一的，因为BIND9解析程序的某些版本将尝试查询A6记录并遵循A6链。
According to published statistics for two root DNS servers (the "K" root server [KROOT] and the "L" root server [LROOT]), there are between 9,000 and 14,000 DNS queries per second on the "K" root server and between 13,000 to 19,000 queries per second on the "L" root server. The distributions of those queries by RR type are similar: roughly 60% A queries, 20~25% AAAA queries, and less than 1% A6 queries.
根据两个根DNS服务器（“K”根服务器[KROOT]和“L”根服务器[LROOT]）的已发布统计数据，“K”根服务器每秒有9000到14000个DNS查询，“L”根服务器每秒有13000到19000个查询。这些查询按RR类型的分布是相似的：大约60%的A查询、20~25%的AAAA查询和少于1%的A6查询。
That there is A6 query traffic does not mean that A6 is actually in use; it is likely the result of some recursive servers that issue internally generated A6 queries when looking up missing name server addresses, in addition to issuing A and AAAA queries.
存在A6查询流量并不意味着A6实际正在使用中；这可能是一些递归服务器在查找缺少的名称服务器地址时发出内部生成的A6查询，以及发出A和AAAA查询的结果。
BIND versions 9.0 through 9.2 could be configured to make A6 queries, and it is possible that some active name servers running those versions have not yet been upgraded.
BIND版本9.0到9.2可以配置为进行A6查询，并且运行这些版本的某些活动名称服务器可能尚未升级。
In the late 1990s, A6 was considered to be the future in preference to AAAA [RFC2874]. As a result, A6 queries were tried by default in BINDv9 versions. When it was pointed out that A6 had some fundamental issues (discussed in [A6DISC] with the deprecation codified in RFC 3363), A6 was abandoned in favor of AAAA and BINDv9 no longer tried A6 records by default. A6 was removed from the query order in the BIND distribution in 2004 or 2005.
在20世纪90年代末，A6被认为是优先于AAAA的未来[RFC2874]。结果，默认情况下，在BINDv9版本中尝试了A6查询。当有人指出A6存在一些基本问题时（在[A6DISC]中讨论，RFC 3363中对其进行了编目），A6被放弃，取而代之的是AAAA，BINDv9默认情况下不再尝试A6记录。A6在2004年或2005年从BIND发行版的查询顺序中删除。
Some Linux/glibc versions may have had A6 query implementations in gethostbyname() 8-10 years ago. These operating systems/libraries may not have been replaced or upgraded everywhere yet.
8-10年前，某些Linux/glibc版本可能在gethostbyname（）中有6个查询实现。这些操作系统/库可能尚未在任何地方被替换或升级。
This document moves the A6 specification to Historic status. This move provides a clear signal to implementers and/or operators that A6 should NOT be implemented or deployed.
本文件将A6规范移至历史状态。这一举措向实施者和/或运营商提供了一个明确的信号，即不应实施或部署A6。
If A6 were in use and it were to be treated as an 'unknown record' (RFC3597) as discussed below, it might lead to some interoperability issues since resolvers that support A6 are required to do additional section processing for these records on the wire. However, as there are no known production uses of A6, the impact is considered negligible.
如果A6正在使用中，并且如下文所述将其视为“未知记录”（RFC3597），则可能会导致一些互操作性问题，因为支持A6的解析器需要对导线上的这些记录执行额外的节处理。然而，由于A6没有已知的生产用途，因此其影响可以忽略不计。
Since there is no known A6-only client in production use, the transition phase may not be strictly necessary. However, clients that attempt to resolve A6 before AAAA will suffer a performance penalty. Therefore, we recommend that:
由于在生产使用中没有已知的A6专用客户，因此过渡阶段可能并非绝对必要。但是，试图在AAAA之前解决A6的客户端将受到性能惩罚。因此，我们建议：
* A6 handling from all new or updated host stacks be removed;
* A6移除所有新的或更新的主机堆栈的处理；
* All existing A6 records be removed; and,
* 删除所有现有A6记录；和
* All resolver and server implementations to return the same response as for any unknown or deprecated RR type for all A6 queries. If a AAAA record exists for the name being resolved, a suitable response would be 'no answers/no error', i.e., the response packet has an answer count of 0 but no error is indicated.
* 所有解析程序和服务器实现返回与所有A6查询的任何未知或不推荐的RR类型相同的响应。如果要解析的名称存在AAAA记录，则合适的响应将为“无应答/无错误”，即响应数据包的应答计数为0，但未指示错误。
Removing A6 records will eliminate any security exposure related to that RR type, and should introduce no new vulnerabilities.
删除A6记录将消除与该RR类型相关的任何安全暴露，并且不会引入新的漏洞。
IANA has updated the annotation of the A6 RR type (code 38) from "Experimental" to "Obsolete" in the DNS Parameters registry.
IANA已将DNS参数注册表中A6 RR类型（代码38）的注释从“实验性”更新为“过时”。
The authors would like to thank Ralph Droms, Roy Arends, Edward Lewis, Andreas Gustafsson, Mark Andrews, Jun-ichiro "itojun" Hagino, and other members of DNS WGs for valuable contributions.
作者要感谢拉尔夫·德罗姆斯、罗伊·阿伦兹、爱德华·刘易斯、安德烈亚斯·古斯塔夫松、马克·安德鲁斯、Jun ichiro“itojun”Hagino以及DNS工作组的其他成员所作的宝贵贡献。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874]Crawford，M.和C.Huitema，“支持IPv6地址聚合和重新编号的DNS扩展”，RFC 28742000年7月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.
[RFC1886]Thomson，S.和C.Huitema，“支持IP版本6的DNS扩展”，RFC 18861995年12月。
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC3363]Bush，R.，Durand，A.，Fink，B.，Gudmundsson，O.，和T.Hain，“代表域名系统（DNS）中的互联网协议版本6（IPv6）地址”，RFC 33632002年8月。
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002.
[RFC3364]Austein，R.，“互联网协议版本6（IPv6）的域名系统（DNS）支持权衡”，RFC 3364，2002年8月。
[A6DISC] Hagino, J., "Comparison of AAAA and A6 (do we really need A6?)", (Work In Progress), July 2001.
[A6DISC]Hagino，J.，“AAAA和A6的比较（我们真的需要A6吗？），（正在进行的工作），2001年7月。
[BIND] "Internet Systems Consortium", http://www.isc.org/software/bind.
[BIND]“互联网系统联盟”，http://www.isc.org/software/bind.
[KROOT] "RIPE Network Coordination Centre", http://k.root-servers.org/.
[KROOT]“成熟的网络协调中心”，http://k.root-servers.org/.
[LROOT] "ICANN DNS Operations", http://dns.icann.org/lroot/
[LROOT] "ICANN DNS Operations", http://dns.icann.org/lroot/
Author's Addresses
作者地址
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China EMail: jiangsheng@huawei.com
中国北京海淀区北青路156号华为校园盛江华为技术有限公司Q14邮编：100095电子邮件：jiangsheng@huawei.com
David Conrad Cloudflare, Inc. 665 3rd Street, Suite 207 San Francisco CA 94107 USA EMail: drc@cloudflare.com
David Conrad Cloudflare，公司665第三街，套房207旧金山CA 94107美国电子邮件：drc@cloudflare.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand EMail: brian.e.carpenter@gmail.com
Brian Carpenter奥克兰大学计算机系PB 92019奥克兰，1142新西兰电子邮件：布瑞恩。E。carpenter@gmail.com