Network Working Group R. Bush
Request for Comments: 3363 A. Durand
Updates: 2673, 2874 B. Fink
Category: Informational O. Gudmundsson
T. Hain
Editors
August 2002
Network Working Group R. Bush
Request for Comments: 3363 A. Durand
Updates: 2673, 2874 B. Fink
Category: Informational O. Gudmundsson
T. Hain
Editors
August 2002
Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)
表示域名系统（DNS）中的Internet协议版本6（IPv6）地址
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status.
本文档澄清并更新了在DNS中定义IPv6地址直接映射和反向映射的RFC的标准状态。本文件将A6和Bit标签规范移至试验状态。
The IETF had begun the process of standardizing two different address formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both are at proposed standard. This had led to confusion and conflicts on which one to deploy. It is important for deployment that any confusion in this area be cleared up, as there is a feeling in the community that having more than one choice will lead to delays in the deployment of IPv6. The goal of this document is to clarify the situation.
IETF已经开始对IPv6地址AAAA[RFC1886]和A6[RFC2874]的两种不同地址格式进行标准化，这两种地址格式都符合拟议标准。这导致了在哪个平台上部署的混乱和冲突。对于部署来说，澄清这一领域的任何混乱都是很重要的，因为社区中有一种感觉，即有多个选择将导致IPv6部署的延迟。本文件的目的是澄清情况。
This document also discusses issues relating to the usage of Binary Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
本文档还讨论了使用二进制标签[RFC 2673]支持IPv6地址反向映射的相关问题。
This document is based on extensive technical discussion on various relevant working groups mailing lists and a joint DNSEXT and NGTRANS meeting at the 51st IETF in August 2001. This document attempts to capture the sense of the discussions and reflect them in this document to represent the consensus of the community.
本文件基于各种相关工作组邮件列表的广泛技术讨论，以及2001年8月第51届IETF上DNSEXT和NGTRANS的联合会议。本文件试图抓住讨论的意义，并将其反映在本文件中，以代表社区的共识。
The main arguments and the issues are covered in a separate document [RFC3364] that reflects the current understanding of the issues. This document summarizes the outcome of these discussions.
主要论点和问题包含在单独的文件[RFC3364]中，该文件反映了当前对这些问题的理解。本文件总结了这些讨论的结果。
The issue of the root of reverse IPv6 address map is outside the scope of this document and is covered in a different document [RFC3152].
反向IPv6根地址映射的问题不在本文档的范围内，在另一个文档[RFC3152]中介绍。
This document changes the status of RFCs 2673 and 2874 from Proposed Standard to Experimental.
本文件将RFCs 2673和2874的状态从拟定标准更改为试验性标准。
Working group consensus as perceived by the chairs of the DNSEXT and NGTRANS working groups is that:
DNSEXT和NGTRANS工作组主席认为，工作组的共识是：
a) AAAA records are preferable at the moment for production deployment of IPv6, and
a) 对于IPv6的生产部署，目前最好使用AAAA记录，以及
b) that A6 records have interesting properties that need to be better understood before deployment.
b) A6记录具有有趣的属性，需要在部署之前更好地理解这些属性。
c) It is not known if the benefits of A6 outweigh the costs and risks.
c) 目前还不知道A6的好处是否大于成本和风险。
There are several potential issues with A6 RRs that stem directly from the feature that makes them different from AAAA RRs: the ability to build up addresses via chaining.
A6 RRs存在几个潜在问题，这些问题直接源于使其不同于AAAA RRs的功能：通过链接建立地址的能力。
Resolving a chain of A6 RRs involves resolving a series of what are nearly-independent queries. Each of these sub-queries takes some non-zero amount of time, unless the answer happens to be in the resolver's local cache already. Other things being equal, we expect that the time it takes to resolve an N-link chain of A6 RRs will be roughly proportional to N. What data we have suggests that users are already impatient with the length of time it takes to resolve A RRs in the IPv4 Internet, which suggests that users are not likely to be patient with significantly longer delays in the IPv6 Internet, but terminating queries prematurely is both a waste of resources and another source of user frustration. Thus, we are forced to conclude that indiscriminate use of long A6 chains is likely to lead to increased user frustration.
解析A6 RRs链涉及解析一系列几乎独立的查询。每个子查询都需要一些非零的时间，除非答案恰好已经在解析器的本地缓存中。在其他条件相同的情况下，我们预计解决一个N-link链的A6 RRs所需的时间将大致与N成正比。我们所掌握的数据表明，用户已经对解决IPv4互联网上的RRs所需的时间感到不耐烦，这表明，用户不太可能对IPv6互联网中明显更长的延迟有耐心，但过早终止查询既浪费资源，又是用户沮丧的另一个原因。因此，我们不得不得出结论，不加选择地使用长A6链可能会增加用户的挫败感。
The probability of failure during the process of resolving an N-link A6 chain also appears to be roughly proportional to N, since each of the queries involved in resolving an A6 chain has roughly the same probability of failure as a single AAAA query.
解析N-link A6链过程中的失败概率似乎也大致与N成正比，因为解析A6链所涉及的每个查询的失败概率与单个AAAA查询的失败概率大致相同。
Last, several of the most interesting potential applications for A6 RRs involve situations 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. 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 susceptible to automation than pointers within a single organization would be.
最后，A6 RR的几个最有趣的潜在应用涉及A6 RR中的前缀名称字段指向一个目标的情况，该目标不仅位于包含A6 RR的DNS区域之外，而且完全由另一个组织管理。虽然分区外的指针本身不是问题，但在in-ADDR.ARPA树中使用glue RRs和PTR RRs的经验表明，指向其他组织的指针通常没有得到正确维护，可能是因为它们不像单个组织内的指针那样容易受到自动化的影响。
Based on the perceived consensus, this document recommends that RFC 1886 stay on standards track and be advanced, while moving RFC 2874 to Experimental status.
基于已达成的共识，本文件建议RFC 1886保持在标准轨道上并取得进展，同时将RFC 2874移至试验状态。
RFC 2673 defines a new DNS label type. This was the first new type defined since RFC 1035 [RFC1035]. Since the development of 2673 it has been learned that deployment of a new type is difficult since DNS servers that do not support bitlabels reject queries containing bit labels as being malformed. The community has also indicated that this new label type is not needed for mapping reverse addresses.
RFC 2673定义了一个新的DNS标签类型。这是自RFC1035[RFC1035]以来定义的第一个新类型。自2673的开发以来，人们了解到新类型的部署是困难的，因为不支持位标签的DNS服务器拒绝包含位标签的查询，认为其格式不正确。社区还指出，映射反向地址不需要这种新标签类型。
The hexadecimal text representation of IPv6 addresses appears to be capable of expressing all of the delegation schemes that we expect to be used in the DNS reverse tree.
IPv6地址的十六进制文本表示似乎能够表示我们期望在DNS反向树中使用的所有委派方案。
RFC 2673 standard status is to be changed from Proposed to Experimental. Future standardization of these documents is to be done by the DNSEXT working group or its successor.
RFC 2673标准状态将从建议状态更改为试验状态。这些文件的未来标准化将由DNSEXT工作组或其继任者完成。
The issues for DNAME in the reverse mapping tree appears to be closely tied to the need to use fragmented A6 in the main tree: if one is necessary, so is the other, and if one isn't necessary, the other isn't either. Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated.
反向映射树中的DNAME问题似乎与在主树中使用片段A6的需要密切相关：如果一个是必需的，那么另一个也是必需的，如果一个不是必需的，那么另一个也不是必需的。因此，在将RFC 2874移动到实验中时，本文的目的是反对在反向树中使用DNAME RRs。
This document is based on input from many members of the various IETF working groups involved in this issues. Special thanks go to the people that prepared reading material for the joint DNSEXT and NGTRANS working group meeting at the 51st IETF in London, Rob Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino, Christian Huitema. Number of other people have made number of comments on mailing lists about this issue including Andrew W. Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka Savola, Paul Vixie.
本文件基于涉及该问题的各个IETF工作组的许多成员的输入。特别感谢在伦敦第51届IETF上为DNSEXT和NGTRANS联合工作组会议准备阅读材料的人员，Rob Austein、Dan Bernstein、Matt Crawford、Jun ichiro itojun Hagino、Christian Huitema。很多其他人在邮件列表上对这个问题发表了很多评论，包括安德鲁·巴克利、罗伯特·埃尔兹、约翰·伊伦、爱德华·刘易斯、比尔·曼宁、佩卡·萨沃拉、保罗·维克西。
As this document specifies a course of action, there are no direct security considerations. There is an indirect security impact of the choice, in that the relationship between A6 and DNSSEC is not well understood throughout the community, while the choice of AAAA does leads to a model for use of DNSSEC in IPv6 networks which parallels current IPv4 practice.
由于本文件规定了行动方案，因此没有直接的安全考虑。这种选择会对安全产生间接影响，因为A6和DNSSEC之间的关系在整个社区中没有得到很好的理解，而AAAA的选择确实会导致在IPv6网络中使用DNSSEC的模型，该模型与当前的IPv4实践平行。
None.
没有一个
Normative References
规范性引用文件
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1886] Thompson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.
[RFC1886]Thompson，S.和C.Huitema，“支持IP版本6的DNS扩展”，RFC18861995年12月。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC2673]克劳福德，M.，“域名系统中的二进制标签”，RFC2673，1999年8月。
[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月。
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152 August 2001.
[RFC3152]Bush，R.，“IP6.ARPA的授权”，BCP 49，RFC 3152，2001年8月。
Informative References
资料性引用
[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月。
Editors' Addresses
编辑地址
Randy Bush EMail: randy@psg.com
兰迪·布什电子邮件：randy@psg.com
Alain Durand EMail: alain.durand@sun.com
阿兰·杜兰德电子邮件：阿兰。durand@sun.com
Bob Fink EMail: fink@es.net
Bob Fink电子邮件：fink@es.net
Olafur Gudmundsson EMail: ogud@ogud.com
Olafur Gudmundsson电子邮件：ogud@ogud.com
Tony Hain EMail: hain@tndh.net
Tony Hain电子邮件：hain@tndh.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。