Network Working Group M. Crawford
Request for Comments: 2874 Fermilab
Category: Standards Track C. Huitema
Microsoft Corporation
July 2000
Network Working Group M. Crawford
Request for Comments: 2874 Fermilab
Category: Standards Track C. Huitema
Microsoft Corporation
July 2000
DNS Extensions to Support IPv6 Address Aggregation and Renumbering
支持IPv6地址聚合和重新编号的DNS扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing.
本文档定义了对域名系统的更改，以支持可重新编号和可聚合的IPv6寻址。这些更改包括一种新的资源记录类型，用于以加快网络重新编号和更新现有查询类型定义的方式存储IPv6地址，这些查询类型返回Internet地址作为附加节处理的一部分。
For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events.
对于键入IPv6地址的查找（通常称为反向查找），本文档定义了一种新的区域结构，该结构允许在不修改地址空间的并行副本（如多址提供程序或站点）和跨网络重新编号事件的情况下使用区域。
Table of Contents
目录
1. Introduction ............................................... 2
2. Overview ................................................... 3
2.1. Name-to-Address Lookup ............................... 4
2.2. Underlying Mechanisms for Reverse Lookups ............ 4
2.2.1. Delegation on Arbitrary Boundaries ............. 4
2.2.2. Reusable Zones ................................. 5
3. Specifications ............................................. 5
3.1. The A6 Record Type ................................... 5
3.1.1. Format ......................................... 6
3.1.2. Processing ..................................... 6
3.1.3. Textual Representation ......................... 7
3.1.4. Name Resolution Procedure ...................... 7
3.2. Zone Structure for Reverse Lookups ................... 7
4. Modifications to Existing Query Types ...................... 8
5. Usage Illustrations ........................................ 8
5.1. A6 Record Chains ..................................... 9
5.1.1. Authoritative Data ............................. 9
5.1.2. Glue ........................................... 10
5.1.3. Variations ..................................... 12
5.2. Reverse Mapping Zones ................................ 13
5.2.1. The TLA level .................................. 13
5.2.2. The ISP level .................................. 13
5.2.3. The Site Level ................................. 13
5.3. Lookups .............................................. 14
5.4. Operational Note ..................................... 15
6. Transition from RFC 1886 and Deployment Notes .............. 15
6.1. Transition from AAAA and Coexistence with A Records .. 16
6.2. Transition from Nibble Labels to Binary Labels ....... 17
7. Security Considerations .................................... 17
8. IANA Considerations ........................................ 17
9. Acknowledgments ............................................ 18
10. References ................................................ 18
11. Authors' Addresses ........................................ 19
12. Full Copyright Statement .................................. 20
1. Introduction ............................................... 2
2. Overview ................................................... 3
2.1. Name-to-Address Lookup ............................... 4
2.2. Underlying Mechanisms for Reverse Lookups ............ 4
2.2.1. Delegation on Arbitrary Boundaries ............. 4
2.2.2. Reusable Zones ................................. 5
3. Specifications ............................................. 5
3.1. The A6 Record Type ................................... 5
3.1.1. Format ......................................... 6
3.1.2. Processing ..................................... 6
3.1.3. Textual Representation ......................... 7
3.1.4. Name Resolution Procedure ...................... 7
3.2. Zone Structure for Reverse Lookups ................... 7
4. Modifications to Existing Query Types ...................... 8
5. Usage Illustrations ........................................ 8
5.1. A6 Record Chains ..................................... 9
5.1.1. Authoritative Data ............................. 9
5.1.2. Glue ........................................... 10
5.1.3. Variations ..................................... 12
5.2. Reverse Mapping Zones ................................ 13
5.2.1. The TLA level .................................. 13
5.2.2. The ISP level .................................. 13
5.2.3. The Site Level ................................. 13
5.3. Lookups .............................................. 14
5.4. Operational Note ..................................... 15
6. Transition from RFC 1886 and Deployment Notes .............. 15
6.1. Transition from AAAA and Coexistence with A Records .. 16
6.2. Transition from Nibble Labels to Binary Labels ....... 17
7. Security Considerations .................................... 17
8. IANA Considerations ........................................ 17
9. Acknowledgments ............................................ 18
10. References ................................................ 18
11. Authors' Addresses ........................................ 19
12. Full Copyright Statement .................................. 20
Maintenance of address information in the DNS is one of several obstacles which have prevented site and provider renumbering from being feasible in IP version 4. Arguments about the importance of network renumbering for the preservation of a stable routing system and for other purposes may be read in [RENUM1, RENUM2, RENUM3]. To support the storage of IPv6 addresses without impeding renumbering we define the following extensions.
DNS中地址信息的维护是阻止站点和提供商在IP版本4中重新编号的几个障碍之一。关于网络重新编号对于维护稳定的路由系统和用于其他目的的重要性的论点可在[RENUM1，RENUM2，RENUM3]中阅读。为了在不妨碍重新编号的情况下支持IPv6地址的存储，我们定义了以下扩展。
o A new resource record type, "A6", is defined to map a domain name to an IPv6 address, with a provision for indirection for leading "prefix" bits.
o 定义了一种新的资源记录类型“A6”，将域名映射到IPv6地址，并提供了前导“前缀”位的间接寻址。
o Existing queries that perform additional section processing to locate IPv4 addresses are redefined to do that processing for both IPv4 and IPv6 addresses.
o 执行附加节处理以定位IPv4地址的现有查询将被重新定义，以便对IPv4和IPv6地址执行该处理。
o A new domain, IP6.ARPA, is defined to support lookups based on IPv6 address.
o 定义了一个新域IP6.ARPA，以支持基于IPv6地址的查找。
o A new prefix-delegation method is defined, relying on new DNS features [BITLBL, DNAME].
o 根据新的DNS功能[BITLBL，DNAME]，定义了一种新的前缀委派方法。
The changes are designed to be compatible with existing application programming interfaces. The existing support for IPv4 addresses is retained. Transition issues related to the coexistence of both IPv4 and IPv6 addresses in DNS are discussed in [TRANS].
这些更改旨在与现有的应用程序编程接口兼容。保留对IPv4地址的现有支持。[TRANS]中讨论了与DNS中IPv4和IPv6地址共存相关的转换问题。
This memo proposes a replacement for the specification in RFC 1886 [AAAA] and a departure from current implementation practices. The changes are designed to facilitate network renumbering and multihoming. Domains employing the A6 record for IPv6 addresses can insert automatically-generated AAAA records in zone files to ease transition. It is expected that after a reasonable period, RFC 1886 will become Historic.
本备忘录建议替换RFC 1886[AAAA]中的规范，并偏离当前的实施实践。这些更改旨在促进网络重新编号和多址。使用IPv6地址A6记录的域可以在区域文件中插入自动生成的AAAA记录，以简化转换。预计经过一段合理的时间后，RFC1886将成为历史。
The next three major sections of this document are an overview of the facilities defined or employed by this specification, the specification itself, and examples of use.
本文件接下来的三个主要部分概述了本规范定义或使用的设施、规范本身以及使用示例。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KWORD]. The key word "SUGGESTED" signifies a strength between MAY and SHOULD: it is believed that compliance with the suggestion has tangible benefits in most instances.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[KWORD]中所述进行解释。关键词“建议”意味着五月和应该之间的力量：人们相信，在大多数情况下，遵守建议会带来切实的好处。
This section provides an overview of the DNS facilities for storage of IPv6 addresses and for lookups based on IPv6 address, including those defined here and elsewhere.
本节概述了用于存储IPv6地址和基于IPv6地址进行查找的DNS设施，包括此处和其他地方定义的DNS设施。
IPv6 addresses are stored in one or more A6 resource records. A single A6 record may include a complete IPv6 address, or a contiguous portion of an address and information leading to one or more prefixes. Prefix information comprises a prefix length and a DNS name which is in turn the owner of one or more A6 records defining the prefix or prefixes which are needed to form one or more complete IPv6 addresses. When the prefix length is zero, no DNS name is present and all the leading bits of the address are significant. There may be multiple levels of indirection and the existence of multiple A6 records at any level multiplies the number of IPv6 addresses which are formed.
IPv6地址存储在一个或多个A6资源记录中。单个A6记录可能包括完整的IPv6地址，或地址的连续部分以及导致一个或多个前缀的信息。前缀信息包括前缀长度和DNS名称，DNS名称又是一个或多个A6记录的所有者，这些记录定义了形成一个或多个完整IPv6地址所需的前缀。当前缀长度为零时，不存在DNS名称，并且地址的所有前导位都是有效的。可能存在多个级别的间接寻址，任何级别上多个A6记录的存在都会增加所形成的IPv6地址的数量。
An application looking up an IPv6 address will generally cause the DNS resolver to access several A6 records, and multiple IPv6 addresses may be returned even if the queried name was the owner of only one A6 record. The authenticity of the returned address(es) cannot be directly verified by DNS Security [DNSSEC]. The A6 records which contributed to the address(es) may of course be verified if signed.
查找IPv6地址的应用程序通常会导致DNS解析程序访问多个A6记录，即使查询的名称仅为一个A6记录的所有者，也可能返回多个IPv6地址。DNS安全[DNSSEC]无法直接验证返回地址的真实性。提供地址的A6记录当然可以在签名后进行验证。
Implementers are reminded of the necessity to limit the amount of work a resolver will perform in response to a client request. This principle MUST be extended to also limit the generation of DNS requests in response to one name-to-address (or address-to-name) lookup request.
提醒实现者有必要限制解析器响应客户端请求将执行的工作量。必须扩展此原则，以限制响应一个名称到地址（或地址到名称）查找请求的DNS请求的生成。
This section describes the new DNS features which this document exploits. This section is an overview, not a specification of those features. The reader is directed to the referenced documents for more details on each.
本节介绍本文档利用的新DNS功能。本节是对这些功能的概述，而不是说明。读者可直接查阅参考文件，以了解有关每种方法的更多详细信息。
This new scheme for reverse lookups relies on a new type of DNS label called the "bit-string label" [BITLBL]. This label compactly represents an arbitrary string of bits which is treated as a hierarchical sequence of one-bit domain labels. Resource records can thereby be stored at arbitrary bit-boundaries.
这种新的反向查找方案依赖于一种称为“位字符串标签”[BITLBL]的新型DNS标签。该标签紧凑地表示任意比特串，该比特串被视为一比特域标签的分层序列。因此，资源记录可以存储在任意位边界上。
Examples in section 5 will employ the following textual representation for bit-string labels, which is a subset of the syntax defined in [BITLBL]. A base indicator "x" for hexadecimal and a sequence of hexadecimal digits is enclosed between "\[" and "]". The bits denoted by the digits represent a sequence of one-bit domain
第5节中的示例将使用以下位字符串标签的文本表示，这是[BITLBL]中定义的语法的子集。十六进制和十六进制数字序列的基本指示符“x”位于“\[”和“]”之间。由数字表示的位表示一个位域的序列
labels ordered from most to least significant. (This is the opposite of the order they would appear if listed one bit at a time, but it appears to be a convenient notation.) The digit string may be followed by a slash ("/") and a decimal count. If omitted, the implicit count is equal to four times the number of hexadecimal digits.
从最重要到最不重要的标签。（这与一次列出一位的顺序相反，但似乎是一种方便的表示法。）数字字符串后面可能跟一个斜杠（“/”）和一个十进制计数。如果省略，隐式计数等于十六进制数字的四倍。
Consecutive bit-string labels are equivalent (up to the limit imposed by the size of the bit count field) to a single bit-string label containing all the bits of the consecutive labels in the proper order. As an example, either of the following domain names could be used in a QCLASS=IN, QTYPE=PTR query to find the name of the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
连续位字符串标签等同于（不超过位计数字段大小施加的限制）单个位字符串标签，该标签按正确顺序包含连续标签的所有位。例如，可以在QCLASS=in，QTYPE=PTR查询中使用以下任一域名，以查找IPv6地址为3ffe:7c0:40:9:a00:20ff:fe81:2b32的节点的名称。
\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA。
\[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
\[x0A0020FFFE812B32/64]。\[x0009/16]。\[x3FFE07C00040/48]。IP6.ARPA。
DNS address space delegation is implemented not by zone cuts and NS records, but by a new analogue to the CNAME record, called the DNAME resource record [DNAME]. The DNAME record provides alternate naming to an entire subtree of the domain name space, rather than to a single node. It causes some suffix of a queried name to be substituted with a name from the DNAME record's RDATA.
DNS地址空间委派不是通过区域切割和NS记录实现的，而是通过一种新的类似于CNAME记录的方式实现的，称为DNAME资源记录[DNAME]。DNAME记录为域名空间的整个子树（而不是单个节点）提供备用命名。它导致查询名称的某些后缀被DNAME记录的RDATA中的名称替换。
For example, a resolver or server providing recursion, while looking up a QNAME a.b.c.d.e.f may encounter a DNAME record
例如，提供递归的解析器或服务器在查找QNAME a.b.c.d.e.f时可能会遇到DNAME记录
d.e.f. DNAME w.xy.
d、 e.f.名称w.xy。
which will cause it to look for a.b.c.w.xy.
这将导致它寻找a.b.c.w.xy。
The A6 record type is specific to the IN (Internet) class and has type number 38 (decimal).
A6记录类型特定于IN（互联网）类，类型编号为38（十进制）。
The RDATA portion of the A6 record contains two or three fields.
A6记录的RDATA部分包含两个或三个字段。
+-----------+------------------+-------------------+
|Prefix len.| Address suffix | Prefix name |
| (1 octet) | (0..16 octets) | (0..255 octets) |
+-----------+------------------+-------------------+
+-----------+------------------+-------------------+
|Prefix len.| Address suffix | Prefix name |
| (1 octet) | (0..16 octets) | (0..255 octets) |
+-----------+------------------+-------------------+
o A prefix length, encoded as an eight-bit unsigned integer with value between 0 and 128 inclusive.
o 前缀长度，编码为8位无符号整数，值介于0和128之间（含0和128）。
o An IPv6 address suffix, encoded in network order (high-order octet first). There MUST be exactly enough octets in this field to contain a number of bits equal to 128 minus prefix length, with 0 to 7 leading pad bits to make this field an integral number of octets. Pad bits, if present, MUST be set to zero when loading a zone file and ignored (other than for SIG [DNSSEC] verification) on reception.
o IPv6地址后缀，按网络顺序编码（高阶八位组优先）。此字段中必须有足够的八位字节，以包含等于128减去前缀长度的位数，0到7个前导焊盘位使此字段成为整数个八位字节。加载区域文件时，如果存在焊盘位，则必须将其设置为零，并在接收时忽略（SIG[DNSSEC]验证除外）。
o The name of the prefix, encoded as a domain name. By the rules of [DNSIS], this name MUST NOT be compressed.
o 前缀的名称，编码为域名。根据[DNSIS]的规则，此名称不得压缩。
The domain name component SHALL NOT be present if the prefix length is zero. The address suffix component SHALL NOT be present if the prefix length is 128.
如果前缀长度为零，则不应存在域名组件。如果前缀长度为128，则不应出现地址后缀组件。
It is SUGGESTED that an A6 record intended for use as a prefix for other A6 records have all the insignificant trailing bits in its address suffix field set to zero.
建议将打算用作其他A6记录前缀的A6记录的地址后缀字段中的所有不重要尾随位设置为零。
A query with QTYPE=A6 causes type A6 and type NS additional section processing for the prefix names, if any, in the RDATA field of the A6 records in the answer section. This processing SHOULD be recursively applied to the prefix names of A6 records included as additional data. When space in the reply packet is a limit, inclusion of additional A6 records takes priority over NS records.
QTYPE=A6的查询会在应答部分A6记录的RDATA字段中对前缀名称（如果有）进行A6类型和NS类型的额外部分处理。此处理应递归地应用于作为附加数据包含的A6记录的前缀名称。当应答数据包中的空间有限时，额外A6记录的包含优先于NS记录。
It is an error for an A6 record with prefix length L1 > 0 to refer to a domain name which owns an A6 record with a prefix length L2 > L1. If such a situation is encountered by a resolver, the A6 record with the offending (larger) prefix length MUST be ignored. Robustness precludes signaling an error if addresses can still be formed from valid A6 records, but it is SUGGESTED that zone maintainers from time to time check all the A6 records their zones reference.
前缀长度为L1>0的A6记录引用拥有前缀长度为L2>L1的A6记录的域名是错误的。如果冲突解决程序遇到这种情况，则必须忽略前缀长度有问题（较大）的A6记录。如果仍然可以从有效的A6记录中形成地址，则健壮性可以防止发出错误信号，但建议区域维护人员不时检查其区域参考的所有A6记录。
The textual representation of the RDATA portion of the A6 resource record in a zone file comprises two or three fields separated by whitespace.
区域文件中A6资源记录的RDATA部分的文本表示包含两个或三个由空格分隔的字段。
o A prefix length, represented as a decimal number between 0 and 128 inclusive,
o 前缀长度，表示为0到128（含0到128）之间的十进制数，
o the textual representation of an IPv6 address as defined in [AARCH] (although some leading and/or trailing bits may not be significant),
o [AARCH]中定义的IPv6地址的文本表示（尽管某些前导和/或尾随位可能不重要），
o a domain name, if the prefix length is not zero.
o 如果前缀长度不为零，则为域名。
The domain name MUST be absent if the prefix length is zero. The IPv6 address MAY be be absent if the prefix length is 128. A number of leading address bits equal to the prefix length SHOULD be zero, either implicitly (through the :: notation) or explicitly, as specified in section 3.1.1.
如果前缀长度为零，则必须缺少域名。如果前缀长度为128，则IPv6地址可能不存在。根据第3.1.1节的规定，等于前缀长度的前导地址位的数量应为零，可以是隐式的（通过：：表示法），也可以是显式的。
To obtain the IPv6 address or addresses which belong to a given name, a DNS client MUST obtain one or more complete chains of A6 records, each chain beginning with a record owned by the given name and including a record owned by the prefix name in that record, and so on recursively, ending with an A6 record with a prefix length of zero. One IPv6 address is formed from one such chain by taking the value of each bit position from the earliest A6 record in the chain which validly covers that position, as indicated by the prefix length. The set of all IPv6 addresses for the given name comprises the addresses formed from all complete chains of A6 records beginning at that name, discarding records which have invalid prefix lengths as defined in section 3.1.2.
要获取属于给定名称的一个或多个IPv6地址，DNS客户端必须获取一个或多个完整的A6记录链，每个链以给定名称拥有的记录开始，并在该记录中包含前缀名称拥有的记录，以此类推，以前缀长度为零的A6记录结束。一个IPv6地址由一个这样的链形成，其方法是从链中有效覆盖该位置的最早A6记录中获取每个位位置的值，如前缀长度所示。给定名称的所有IPv6地址集包括从该名称开始的所有完整A6记录链形成的地址，丢弃具有第3.1.2节中定义的无效前缀长度的记录。
If some A6 queries fail and others succeed, a client might obtain a non-empty but incomplete set of IPv6 addresses for a host. In many situations this may be acceptable. The completeness of a set of A6 records may always be determined by inspection.
如果某些A6查询失败，而其他查询成功，则客户端可能会为主机获取一组非空但不完整的IPv6地址。在许多情况下，这是可以接受的。一组A6记录的完整性始终可以通过检查来确定。
Very little of the new scheme's data actually appears under IP6.ARPA; only the first level of delegation needs to be under that domain. More levels of delegation could be placed under IP6.ARPA if some top-level delegations were done via NS records instead of DNAME records, but this would incur some cost in renumbering ease at the
新方案的数据实际上很少出现在IP6.ARPA下；只有第一级授权需要在该域下。如果一些顶级授权是通过NS记录而不是DNAME记录完成的，则可以将更多级别的授权置于IP6.ARPA之下，但这将在重新编号时产生一些成本
level of TLAs [AGGR]. Therefore, it is declared here that all address space delegations SHOULD be done by the DNAME mechanism rather than NS.
TLA水平[AGGR]。因此，在此声明，所有地址空间授权都应由DNAME机制而不是NS完成。
In addition, since uniformity in deployment will simplify maintenance of address delegations, it is SUGGESTED that address and prefix information be stored immediately below a DNS label "IP6". Stated another way, conformance with this suggestion would mean that "IP6" is the first label in the RDATA field of DNAME records which support IPv6 reverse lookups.
此外，由于部署的统一性将简化地址委派的维护，因此建议将地址和前缀信息存储在DNS标签“IP6”的正下方。换句话说，符合此建议意味着“IP6”是支持IPv6反向查找的DNAME记录的RDATA字段中的第一个标签。
When any "reserved" or "must be zero" bits are adjacent to a delegation boundary, the higher-level entity MUST retain those bits in its own control and delegate only the bits over which the lower-level entity has authority.
当任何“保留”或“必须为零”位与委派边界相邻时，上级实体必须将这些位保留在自己的控制中，并仅委派下级实体拥有权限的位。
To find the name of a node given its IPv6 address, a DNS client MUST perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the 128 bit address as one or more bit-string labels [BITLBL], followed by the two standard labels "IP6.ARPA". If recursive service was not obtained from a server and the desired PTR record was not returned, the resolver MUST handle returned DNAME records as specified in [DNAME], and NS records as specified in [DNSCF], and iterate.
要查找给定IPv6地址的节点的名称，DNS客户端必须使用QCLASS=IN，QTYPE=PTR对128位地址形成的名称执行查询，该名称作为一个或多个位字符串标签[BITLBL]，后跟两个标准标签“IP6.ARPA”。如果未从服务器获取递归服务，并且未返回所需的PTR记录，则解析程序必须按照[DNAME]中的规定处理返回的DNAME记录，并按照[DNSCF]中的规定处理NS记录，然后进行迭代。
All existing query types that perform type A additional section processing, i.e. the name server (NS), mail exchange (MX), and mailbox (MB) query types, and the experimental AFS data base (AFSDB) and route through (RT) types, must be redefined to perform type A, A6 and AAAA additional section processing, with type A having the highest priority for inclusion and type AAAA the lowest. This redefinition means that a name server may add any relevant IPv4 and IPv6 address information available locally to the additional section of a response when processing any one of the above queries. The recursive inclusion of A6 records referenced by A6 records already included in the additional section is OPTIONAL.
必须重新定义所有执行类型A附加节处理的现有查询类型，即名称服务器（NS）、邮件交换（MX）和邮箱（MB）查询类型，以及实验性AFS数据库（AFSDB）和路由通过（RT）类型，以执行类型A、A6和AAAA附加节处理，A型具有最高的纳入优先级，AAAA型最低。这种重新定义意味着，在处理上述任何一个查询时，名称服务器可以将本地可用的任何相关IPv4和IPv6地址信息添加到响应的附加部分。已包含在附加部分中的A6记录引用的A6记录的递归包含是可选的。
This section provides examples of use of the mechanisms defined in the previous section. All addresses and domains mentioned here are intended to be fictitious and for illustrative purposes only. Example delegations will be on 4-bit boundaries solely for readability; this specification is indifferent to bit alignment.
本节提供了前一节中定义的机制的使用示例。这里提到的所有地址和域都是虚构的，仅供说明。示例代表团将位于4位边界上，仅用于可读性；本规范与钻头对准无关。
Use of the IPv6 aggregatable address format [AGGR] is assumed in the examples.
示例中假设使用IPv6可聚合地址格式[AGGR]。
Let's take the example of a site X that is multi-homed to two "intermediate" providers A and B. The provider A is itself multi-homed to two "transit" providers, C and D. The provider B gets its transit service from a single provider, E. For simplicity suppose that C, D and E all belong to the same top-level aggregate (TLA) with identifier (including format prefix) '2345', and the TLA authority at ALPHA-TLA.ORG assigns to C, D and E respectively the next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and 2345:000E::/32.
让我们以一个站点X为例，它是两个“中间”提供商a和B的多宿站点。提供商a本身是两个“传输”提供商C和D的多宿站点。提供商B从单个提供商获得传输服务，E。为简单起见，假设C、D和E都属于具有标识符的同一顶级聚合（TLA）（包括格式前缀“2345”，ALPHA-TLA.ORG上的TLA机构分别为C、D和E分配下一级聚合（NLA）前缀2345:00C0:：/28、2345:00D0:：/28和2345:000E:：/32。
C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to B.
C将NLA前缀2345:00C1:CA00:：/40分配给A，D将前缀2345:00D2:DA00:：/40分配给A，E将2345:000E:EB00:：/40分配给B。
A assigns to X the subscriber identification '11' and B assigns the subscriber identification '22'. As a result, the site X inherits three address prefixes:
A为X分配用户标识“11”，B为X分配用户标识“22”。因此，站点X继承了三个地址前缀：
o 2345:00C1:CA11::/48 from A, for routes through C. o 2345:00D2:DA11::/48 from A, for routes through D. o 2345:000E:EB22::/48 from B, for routes through E.
o 2345:00C1:CA11:：/48来自A，对于通过C.o 2345:00D2的路线：DA11:：/48来自A，对于通过D.o 2345:000E的路线：EB22:：/48来自B，对于通过E的路线。
Let us suppose that N is a node in the site X, that it is assigned to subnet number 1 in this site, and that it uses the interface identifier '1234:5678:9ABC:DEF0'. In our configuration, this node will have three addresses:
假设N是站点X中的一个节点，它被分配给该站点中的子网编号1，并且它使用接口标识符“1234:5678:9ABC:DEF0”。在我们的配置中，此节点将有三个地址：
o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
We will assume that the site X is represented in the DNS by the domain name X.EXAMPLE, while A, B, C, D and E are represented by A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we assume a subdomain "IP6" that will hold the corresponding prefixes. The node N is identified by the domain name N.X.EXAMPLE. The following records would then appear in X's DNS.
我们将假设站点X在DNS中由域名X表示。例如，A、B、C、D和E由A.NET、B.NET、C.NET、D.NET和E.NET表示。在每个域中，我们假设一个子域“IP6”将包含相应的前缀。节点N由域名N.X.EXAMPLE标识。以下记录将出现在X的DNS中。
$ORIGIN X.EXAMPLE. N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
$ORIGIN X.EXAMPLE。N A6 64:：1234:5678:9ABC:DEF0子网-1.IP6子网-1.IP6 A6 48 0:0:0:：IP6 IP6 A6 48 0:：0订户-X.IP6.A.NET。IP6 A6 48 0:：0订户-X.IP6.B.NET。
And elsewhere there would appear
其他地方也会出现
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
订户-X.IP6.A.NET。A6 40 0:0:0011:：A.NET.IP6.C.NET。订户-X.IP6.A.NET。A6 40 0:0:0011:：A.NET.IP6.D.NET。
SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
订户-X.IP6.B.NET。A6 40 0:0:0022:：B-NET.IP6.E.NET。
A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
A.NET.IP6.C.NET。A6 28 0:0001:CA00:：C.NET.ALPHA-TLA.ORG。
A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
A.NET.IP6.D.NET。A6 28 0:0002:DA00:：D.NET.ALPHA-TLA.ORG。
B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
B-NET.IP6.E.NET。A6 32 0:0:EB00:：E.NET.ALPHA-TLA.ORG。
C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
C.NET.ALPHA-TLA.ORG。A6 0 2345:00C0:：D.NET.ALPHA-TLA.ORG。A6 0 2345:00D0:：E.NET.ALPHA-TLA.ORG。A6 0 2345:000E:：
When, as is common, some or all DNS servers for X.EXAMPLE are within the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry enough "glue" information to enable DNS clients to reach those nameservers. This is true in IPv6 just as in IPv4. However, the A6 record affords the DNS administrator some choices. The glue could be any of
通常，当X.EXAMPLE的某些或所有DNS服务器位于X.EXAMPLE区域内时，顶级区域示例必须携带足够的“粘合”信息，以使DNS客户端能够访问这些名称服务器。与IPv4一样，IPv6也是如此。但是，A6记录为DNS管理员提供了一些选择。胶水可以是任何一种
o a minimal set of A6 records duplicated from the X.EXAMPLE zone,
o 从X.EXAMPLE区域复制的最小A6记录集，
o a (possibly smaller) set of records which collapse the structure of that minimal set,
o 一组（可能更小）的记录，这些记录折叠了最小集合的结构，
o or a set of A6 records with prefix length zero, giving the entire global addresses of the servers.
o 或者一组前缀长度为零的A6记录，给出服务器的整个全局地址。
The trade-off is ease of maintenance against robustness. The best and worst of both may be had together by implementing either the first or second option together with the third. To illustrate the glue options, suppose that X.EXAMPLE is served by two nameservers NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively. Then the top-level zone EXAMPLE would include one (or more) of the following sets of A6 records as glue.
折衷是易于维护和健壮性。通过将第一个或第二个选项与第三个选项一起实施，这两个选项中最好的和最坏的可以结合在一起。为了说明粘合选项，假设X.EXAMPLE由两个名称服务器NS1.X.EXAMPLE和NS2.X.EXAMPLE提供服务，分别在子网1和2上具有接口标识符：：1:11:111:1111和：：2:22:222:2222。然后顶级区域示例将包括以下一组（或多组）A6记录作为粘合剂。
$ORIGIN EXAMPLE. ; first option X NS NS1.X NS NS2.X NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
$ORIGIN示例；第一个选项X NS NS1.X NS NS2.X NS1.X A6 64:：1:11:111:1111子网-1.IP6.X NS2.X A6 64:：2:22:222:2222子网-2.IP6.X子网-1.IP6.X A6 48 0:0:1:：IP6.X子网-2.IP6.X A6 48 0:0:2:：IP6.X A6 48 0:：0订户-X.IP6.A.NET。IP6.X A6 48 0:：0订户-X.IP6.B.NET。
$ORIGIN EXAMPLE. ; second option X NS NS1.X NS NS2.X NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET. A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET. NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET. A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
$ORIGIN示例；第二个选项X NS NS1.X NS NS2.X NS1.X A6 48:：1:1:11:111:1111订户-X.IP6.A.NET。A6 48:：1:1:11:111:1111订户-X.IP6.B.NET。NS2.X A6 48:：2:2:22:222:2222订户-X.IP6.A.NET。A6 48:：2:2:22:222:2222订户-X.IP6.B.NET。
$ORIGIN EXAMPLE. ; third option
X NS NS1.X
NS NS2.X
NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111
A6 0 2345:00D2:DA11:1:1:11:111:1111
A6 0 2345:000E:EB22:1:1:11:111:1111
NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222
A6 0 2345:00D2:DA11:2:2:22:222:2222
A6 0 2345:000E:EB22:2:2:22:222:2222
$ORIGIN EXAMPLE. ; third option
X NS NS1.X
NS NS2.X
NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111
A6 0 2345:00D2:DA11:1:1:11:111:1111
A6 0 2345:000E:EB22:1:1:11:111:1111
NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222
A6 0 2345:00D2:DA11:2:2:22:222:2222
A6 0 2345:000E:EB22:2:2:22:222:2222
The first and second glue options are robust against renumbering of X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if those providers' own DNS is unreachable. The glue records of the third option are robust against DNS failures elsewhere than the zones EXAMPLE and X.EXAMPLE themselves, but must be updated when X's address space is renumbered.
第一个和第二个粘合选项对于提供商A.NET和B.NET对X.EXAMPLE的前缀进行重新编号非常有效，但如果无法访问这些提供商自己的DNS，则会失败。第三个选项的粘合记录对于除区域示例和X.EXAMPLE本身以外的其他地方的DNS故障具有鲁棒性，但必须在对X的地址空间重新编号时进行更新。
If the EXAMPLE zone includes redundant glue, for instance the union of the A6 records of the first and third options, then under normal circumstances duplicate IPv6 addresses will be derived by DNS clients. But if provider DNS fails, addresses will still be obtained from the zero-prefix-length records, while if the EXAMPLE zone lags behind a renumbering of X.EXAMPLE, half of the addresses obtained by DNS clients will still be up-to-date.
如果示例区域包括冗余粘合，例如第一个和第三个选项的A6记录的并集，则在正常情况下，DNS客户端将派生重复的IPv6地址。但如果提供商DNS失败，地址仍将从零前缀长度记录中获取，而如果示例区域落后于X的重新编号。例如，DNS客户端获取的地址中有一半仍然是最新的。
The zero-prefix-length glue records can of course be automatically generated and/or checked in practice.
零前缀长度胶水记录当然可以在实践中自动生成和/或检查。
Several more-or-less arbitrary assumptions are reflected in the above structure. All of the following choices could have been made differently, according to someone's notion of convenience or an agreement between two parties.
上述结构中反映了一些或多或少的任意假设。根据某人对便利的看法或双方达成的协议，以下所有选择都可以做出不同的选择。
First, that site X has chosen to put subnet information in a separate A6 record rather than incorporate it into each node's A6 records.
首先，站点X选择将子网信息放在单独的A6记录中，而不是将其合并到每个节点的A6记录中。
Second, that site X is referred to as "SUBSCRIBER-X" by both of its providers A and B.
其次，该站点X被其提供商A和B称为“订户X”。
Third, that site X chose to indirect its provider information through A6 records at IP6.X.EXAMPLE containing no significant bits. An alternative would have been to replicate each subnet record for each provider.
第三，该站点X选择通过IP6.X的A6记录间接提供其提供商信息。例如，不包含有效位。另一种方法是为每个提供者复制每个子网记录。
Fourth, B and E used a slightly different prefix naming convention between themselves than did A, C and D. Each hierarchical pair of network entities must arrange this naming between themselves.
第四，B和E之间使用的前缀命名约定与a、C和D之间使用的前缀命名约定略有不同。网络实体的每个层次结构对必须在它们之间安排此命名。
Fifth, that the upward prefix referral chain topped out at ALPHA-TLA.ORG. There could have been another level which assigned the TLA values and holds A6 records containing those bits.
第五，在ALPHA-TLA.ORG上，向上前缀推荐链达到了顶峰。可能还有另一个级别分配TLA值并保存包含这些位的A6记录。
Finally, the above structure reflects an assumption that address fields assigned by a given entity are recorded only in A6 records held by that entity. Those bits could be entered into A6 records in the lower-level entity's zone instead, thus:
最后，上述结构反映了一种假设，即给定实体分配的地址字段仅记录在该实体持有的A6记录中。这些位可以输入较低级别实体区域中的A6记录，因此：
IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET. IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
IP6.X.示例。A6 40 0:0:11:：IP6.A.NET。IP6.X.示例。A6 40 0:0:22:：IP6.B.NET。
IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET. and so on.
IP6.A.NET。A6 28 0:1:CA00:：IP6.C.NET。等等
Or the higher-level entities could hold both sorts of A6 records (with different DNS owner names) and allow the lower-level entities to choose either mode of A6 chaining. But the general principle of avoiding data duplication suggests that the proper place to store assigned values is with the entity that assigned them.
或者，较高级别的实体可以同时持有两种A6记录（具有不同的DNS所有者名称），并允许较低级别的实体选择A6链接的任一模式。但避免数据重复的一般原则表明，存储指定值的适当位置是分配值的实体。
It is possible, but not necessarily recommended, for a zone maintainer to forego the renumbering support afforded by the chaining of A6 records and to record entire IPv6 addresses within one zone file.
区域维护人员可以（但不一定建议）放弃A6记录链接提供的重新编号支持，并在一个区域文件中记录整个IPv6地址。
Supposing that address space assignments in the TLAs with Format Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then the IP6.ARPA zone would include
假设在名为ALPHA-TLA.ORG、BRAVO-TLA.ORG和CHARLIE-TLA.XY的区域中维护具有格式前缀（001）二进制和ID 0345、0678和09AB的TLA中的地址空间分配，则IP6.ARPA区域将包括
$ORIGIN IP6.ARPA. \[x234500/24] DNAME IP6.ALPHA-TLA.ORG. \[x267800/24] DNAME IP6.BRAVO-TLA.ORG. \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
$ORIGIN IP6.ARPA\[x234500/24]DNAME IP6.ALPHA-TLA.ORG\[x267800/24]DNAME IP6.BRAVO-TLA.ORG\[x29AB00/24]DNAME IP6.CHARLIE-TLA.XY。
Eight trailing zero bits have been included in each TLA ID to reflect the eight reserved bits in the current aggregatable global unicast addresses format [AGGR].
每个TLA ID中包含八个尾随零位，以反映当前可聚合全局单播地址格式[AGGR]中的八个保留位。
ALPHA-TLA's assignments to network providers C, D and E are reflected in the reverse data as follows.
ALPHA-TLA对网络提供商C、D和E的分配反映在反向数据中，如下所示。
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET. \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET.
\[xC/4].IP6.ALPHA-TLA.ORG。DNAME IP6.C.NET\[xD/4].IP6.ALPHA-TLA.ORG。DNAME IP6.D.NET\[x0E/8].IP6.ALPHA-TLA.ORG。DNAME IP6.E.NET。
The providers A through E carry the following delegation information in their zone files.
提供者A到E在其区域文件中携带以下委托信息。
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET. \[xEB/8].IP6.E.NET. DNAME IP6.B.NET. \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
\[x1CA/12].IP6.C.NET。DNAME IP6.A.NET\[x2DA/12].IP6.D.NET。DNAME IP6.A.NET\[xEB/8].IP6.E.NET。DNAME IP6.B.NET\[x11/8].IP6.A.NET。DNAME IP6.X.EXAMPLE\[x22/8].IP6.B.NET。DNAME IP6.X.EXAMPLE。
Note that some domain names appear in the RDATA of more than one DNAME record. In those cases, one zone is being used to map multiple prefixes.
请注意，一些域名出现在多个DNAME记录的RDATA中。在这些情况下，一个区域用于映射多个前缀。
Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-name translations. This domain is now referenced by two different DNAME records held by two different providers.
考虑客户X.示例，使用IP6x.示例进行地址到名称转换。该域现在由两个不同的提供者持有的两个不同的DNAME记录引用。
$ORIGIN IP6.X.EXAMPLE. \[x0001/16] DNAME SUBNET-1 \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. and so on.
$ORIGIN IP6.X.示例\[x0001/16]DNAME SUBNET-1\[x123456789ABCDEF0]。SUBNET-1 PTR N.X.示例。等等
SUBNET-1 need not have been named in a DNAME record; the subnet bits could have been joined with the interface identifier. But if subnets are treated alike in both the A6 records and in the reverse zone, it will always be possible to keep the forward and reverse definition data for each prefix in one zone.
子网1不需要在DNAME记录中命名；子网位可能已与接口标识符连接。但是，如果在A6记录和反向区域中对子网的处理都相同，则始终可以在一个区域中保留每个前缀的正向和反向定义数据。
A DNS resolver looking for a hostname for the address 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the DNAME records shown above and would form new queries. Assuming that it began the process knowing servers for IP6.ARPA, but that no server it consulted provided recursion and none had other useful additional information cached, the sequence of queried names and responses would be (all with QCLASS=IN, QTYPE=PTR):
寻找地址2345:00C1:CA11:0001:1234:5678:9ABC:DEF0的主机名的DNS解析程序将获取上面显示的某些DNAME记录，并形成新的查询。假设它开始处理IP6.ARPA的服务器，但它咨询的服务器没有提供递归，也没有缓存其他有用的附加信息，那么查询的名称和响应的顺序将是（所有的QCLASS=IN，QTYPE=PTR）：
To a server for IP6.ARPA: QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
到IP6.ARPA的服务器：QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA。
Answer: \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
回答：\[x234500/24].IP6.ARPA。DNAME IP6.ALPHA-TLA.ORG。
To a server for IP6.ALPHA-TLA.ORG: QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
到IP6.ALPHA-TLA.ORG的服务器：QNAME=\[xc1ca10001123456789abcdef0/104].IP6.ALPHA-TLA.ORG。
Answer: \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
回答：\[xC/4].IP6.ALPHA-TLA.ORG。DNAME IP6.C.NET。
To a server for IP6.C.NET.: QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
到IP6.C.NET的服务器：QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET。
Answer: \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
回答：\[x1CA/12].IP6.C.NET。DNAME IP6.A.NET。
To a server for IP6.A.NET.: QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
到IP6.a.NET的服务器：QNAME=\[x110001123456789ABCDEF0/88].IP6.a.NET。
Answer: \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
回答：\[x11/8].IP6.A.NET。DNAME IP6.X.EXAMPLE。
To a server for IP6.X.EXAMPLE.: QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
到IP6.X.EXAMPLE的服务器：QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE。
Answer: \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
回答：\[x0001/16].IP6.X.EXAMPLE。DNAME SUBNET-1.IP6.X.示例\[x123456789ABCDEF0/64]。子网-1.X.EXAMPLE。PTR N.X.示例。
All the DNAME (and NS) records acquired along the way can be cached to expedite resolution of addresses topologically near to this address. And if another global address of N.X.EXAMPLE were resolved within the TTL of the final PTR record, that record would not have to be fetched again.
可以缓存沿途获取的所有DNAME（和NS）记录，以加速解析拓扑上靠近此地址的地址。如果在最终PTR记录的TTL中解析了另一个全局地址N.X.EXAMPLE，则不必再次获取该记录。
In the illustrations in section 5.1, hierarchically adjacent entities, such as a network provider and a customer, must agree on a DNS name which will own the definition of the delegated prefix(es). One simple convention would be to use a bit-string label representing exactly the bits which are assigned to the lower-level entity by the higher. For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]". This would place the A6 record(s) defining the delegated prefix at exactly the same point in the DNS tree as the DNAME record associated with that delegation. The cost of this simplification is that the lower-level zone must update its upward-pointing A6 records when it is renumbered. This cost may be found quite acceptable in practice.
在第5.1节的说明中，层级相邻实体（如网络提供商和客户）必须就DNS名称达成一致，该名称将拥有委托前缀的定义。一个简单的约定是使用一个位字符串标签，精确地表示由较高级别实体分配给较低级别实体的位。例如，“SUBSCRIBER-X”可以替换为“\[x11/8]”。这会将定义委派前缀的A6记录放置在DNS树中与与该委派关联的DNAME记录完全相同的点上。这种简化的代价是，较低级别区域在重新编号时必须更新其向上的A6记录。这一成本在实践中是可以接受的。
When prefixes have been "delegated upward" with A6 records, the number of DNS resource records required to establish a single IPv6 address increases by some non-trivial factor. Those records will typically, but not necessarily, come from different DNS zones (which can independently suffer failures for all the usual reasons). When obtaining multiple IPv6 addresses together, this increase in RR count will be proportionally less -- and the total size of a DNS reply might even decrease -- if the addresses are topologically clustered. But the records could still easily exceed the space available in a UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or SRV query, for example. The possibilities for overall degradation of performance and reliability of DNS lookups are numerous, and increase with the number of prefix delegations involved, especially when those delegations point to records in other zones.
当使用A6记录“向上委派”前缀时，建立单个IPv6地址所需的DNS资源记录的数量会增加一些非常重要的因素。这些记录通常（但不一定）来自不同的DNS区域（由于所有常见原因，这些区域可能会独立出现故障）。当同时获得多个IPv6地址时，如果这些地址是拓扑群集的，则RR计数的增加将按比例减少——DNS应答的总大小甚至可能减少。但是，这些记录仍然很容易超出UDP响应中的可用空间，例如，UDP响应会向MX、NS或SRV查询返回一个大的RRset[DNSCLAR]。DNS查找的性能和可靠性整体降低的可能性很多，并且随着涉及的前缀委派数量的增加而增加，特别是当这些委派指向其他区域中的记录时。
DNS Security [DNSSEC] addresses the trustworthiness of cached data, which is a problem intrinsic to DNS, but the cost of applying this to an IPv6 address is multiplied by a factor which may be greater than the number of prefix delegations involved if different signature chains must be verified for different A6 records. If a trusted centralized caching server (as in [TSIG], for example) is used, this cost might be amortized to acceptable levels. One new phenomenon is
DNS安全[DNSSEC]解决了缓存数据的可信度问题，这是DNS固有的问题，但如果必须为不同的A6记录验证不同的签名链，则将此应用于IPv6地址的成本乘以一个系数，该系数可能大于所涉及的前缀委派数。如果使用受信任的集中式缓存服务器（例如[TSIG]），则此成本可能会分摊到可接受的水平。一个新现象是
the possibility that IPv6 addresses may be formed from a A6 records from a combination of secure and unsecured zones.
IPv6地址可能由来自安全和非安全区域组合的A6记录形成。
Until more deployment experience is gained with the A6 record, it is recommended that prefix delegations be limited to one or two levels. A reasonable phasing-in mechanism would be to start with no prefix delegations (all A6 records having prefix length 0) and then to move to the use of a single level of delegation within a single zone. (If the TTL of the "prefix" A6 records is kept to an appropriate duration the capability for rapid renumbering is not lost.) More aggressively flexible delegation could be introduced for a subset of hosts for experimentation.
在A6记录获得更多的部署经验之前，建议将部署限制在一个或两个级别。一个合理的分阶段机制是从没有前缀的委托开始（所有A6记录的前缀长度为0），然后在单个区域内使用单个级别的委托。（如果将“前缀”A6记录的TTL保持在适当的持续时间内，则不会丢失快速重新编号的功能。）可以为试验主机子集引入更灵活的授权。
Administrators of zones which contain A6 records can easily accommodate deployed resolvers which understand AAAA records but not A6 records. Such administrators can do automatic generation of AAAA records for all of a zone's names which own A6 records by a process which mimics the resolution of a hostname to an IPv6 address (see section 3.1.4). Attention must be paid to the TTL assigned to a generated AAAA record, which MUST be no more than the minimum of the TTLs of the A6 records that were used to form the IPv6 address in that record. For full robustness, those A6 records which were in different zones should be monitored for changes (in TTL or RDATA) even when there are no changes to zone for which AAAA records are being generated. If the zone is secure [DNSSEC], the generated AAAA records MUST be signed along with the rest of the zone data.
包含A6记录的区域的管理员可以轻松容纳已部署的解析程序，这些解析程序理解AAAA记录，但不理解A6记录。此类管理员可以通过模拟主机名解析为IPv6地址的过程，为拥有A6记录的所有区域名称自动生成AAAA记录（见第3.1.4节）。必须注意分配给生成的AAAA记录的TTL，该TTL不得超过用于在该记录中形成IPv6地址的A6记录的最小TTL。为了充分稳健性，应监控不同区域中的A6记录的变化（TTL或RDATA），即使生成AAAA记录的区域没有变化。如果区域是安全的[DNSSEC]，则生成的AAAA记录必须与其余区域数据一起签名。
A zone-specific heuristic MAY be used to avoid generation of AAAA records for A6 records which record prefixes, although such superfluous records would be relatively few in number and harmless. Examples of such heuristics include omitting A6 records with a prefix length less than the largest value found in the zone file, or records with an address suffix field with a certain number of trailing zero bits.
可以使用特定于区域的启发式方法来避免为记录前缀的A6记录生成AAAA记录，尽管此类多余记录的数量相对较少且无害。这种启发式方法的示例包括省略前缀长度小于区域文件中最大值的A6记录，或省略带有地址后缀字段且具有一定数量尾随零位的记录。
On the client side, when looking up and IPv6 address, the order of A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA; AAAA, then A6; A6 only; or both in parallel. The default order (or only order, if not configurable) MUST be to try A6 first, then AAAA. If and when the AAAA becomes deprecated a new document will change the default.
在客户端，当查找IPv6地址和IPv6地址时，A6和AAAA查询的顺序可以配置为：A6，然后AAAA；AAAA，然后是A6；仅A6；或者两者并行。默认订单（或仅订单，如果不可配置）必须先尝试A6，然后尝试AAAA。如果AAAA被弃用，新文档将更改默认值。
The guidelines and options for precedence between IPv4 and IPv6 addresses are specified in [TRANS]. All mentions of AAAA records in that document are henceforth to be interpreted as meaning A6 and/or AAAA records in the order specified in the previous paragraph.
[TRANS]中规定了IPv4和IPv6地址之间优先级的准则和选项。此后，该文件中提及的所有AAAA记录均应按照上一段规定的顺序解释为A6和/或AAAA记录。
Implementations conforming to RFC 1886 [AAAA] perform reverse lookups as follows:
符合RFC 1886[AAAA]的实现执行如下反向查找：
An IPv6 address is represented as a name in the IP6.INT domain by a sequence of nibbles separated by dots with the suffix ".IP6.INT". The sequence of nibbles is encoded in reverse order, i.e. the low-order nibble is encoded first, followed by the next low-order nibble and so on. Each nibble is represented by a hexadecimal digit. For example, a name for the address 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section 5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.- 8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
IPv6地址在IP6.INT域中表示为一个名称，由一系列由后缀为“.IP6.INT”的点分隔的半字节组成。半字节序列按相反顺序编码，即先对低阶半字节进行编码，然后对下一个低阶半字节进行编码，依此类推。每个半字节由一个十六进制数字表示。例如，第5.3节中示例的地址2345:00C1:CA11:0001:1234:5678:9ABC:DEF0的名称将在DNS名称“0.f.e.d.c.b.a.9.-8.7.6.5.4.3.2.1.1.0.0.1.a.c.1.c.0.0.5.4.2.ip6.int”处查找
Implementations conforming to this specification will perform a lookup of a binary label in IP6.ARPA as specified in Section 3.2. It is RECOMMENDED that for a transition period implementations first lookup the binary label in IP6.ARPA and if this fails try to lookup the 'nibble' label in IP6.INT.
符合本规范的实施将按照第3.2节的规定，在IP6.ARPA中查找二进制标签。建议在过渡期实施中，首先在IP6.ARPA中查找二进制标签，如果此操作失败，则尝试在IP6.INT中查找“半字节”标签。
The signing authority [DNSSEC] for the A6 records which determine an IPv6 address is distributed among several entities, reflecting the delegation path of the address space which that address occupies. DNS Security is fully applicable to bit-string labels and DNAME records. And just as in IPv4, verification of name-to-address mappings is logically independent of verification of address-to-name mappings.
用于确定IPv6地址的A6记录的签名机构[DNSSEC]分布在多个实体之间，反映该地址占用的地址空间的委托路径。DNS安全性完全适用于位字符串标签和DNAME记录。正如在IPv4中一样，名称到地址映射的验证在逻辑上独立于地址到名称映射的验证。
With or without DNSSEC, the incomplete but non-empty address set scenario of section 3.1.4 could be caused by selective interference with DNS lookups. If in some situation this would be more harmful than complete DNS failure, it might be mitigated on the client side by refusing to act on an incomplete set, or on the server side by listing all addresses in A6 records with prefix length 0.
无论是否使用DNSSEC，第3.1.4节中不完整但非空的地址集场景都可能是由对DNS查找的选择性干扰造成的。如果在某些情况下，这比完全DNS故障更有害，则可以在客户端通过拒绝对不完整的集合采取行动来缓解，或者在服务器端通过在前缀长度为0的A6记录中列出所有地址来缓解。
The A6 resource record has been assigned a Type value of 38.
A6资源记录已分配类型值38。
The authors would like to thank the following persons for valuable discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont, Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden, Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
作者感谢以下人士的宝贵讨论和评论：马克·安德鲁斯、罗伯·奥斯汀、吉姆·邦德、兰迪·布什、布赖恩·卡彭特、大卫·康拉德、史蒂夫·迪林、弗朗西斯·杜邦、罗伯特·埃尔兹、鲍勃·芬克、奥拉弗尔·古德蒙德森、鲍勃·哈雷、鲍勃·辛登、爱德华·刘易斯、比尔·曼宁、基思·摩尔、托马斯·纳顿、埃里克·诺德马克、，迈克·奥戴尔、迈克尔·巴顿和肯·鲍威尔。
[AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6, RFC 1886, December 1995.
[AAAA]Thomson，S.和C.Huitema，“支持IP版本6的DNS扩展，RFC 1886，1995年12月。
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[AARCH]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[AGGR]Hinden，R.，O'Dell，M.和S.Deering，“一种IPv6可聚合全球单播地址格式”，RFC 2374，1998年7月。
[BITLBL] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[BITLBL]Crawford，M.，“域名系统中的二进制标签”，RFC 26731999年8月。
[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[DNAME]Crawford，M.，“非终端DNS名称重定向”，RFC 2672，1999年8月。
[DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[DNSCLAR]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[DNSIS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNSIS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System Security Extensions", RFC 2535, March 1999.
[DNSSEC]Eastlake，D.3rd和C.Kaufman，“域名系统安全扩展”，RFC 25351999年3月。
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KWORD]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[Reum1]Carpenter，B.和Y.Rekhter，“重新编号需要工作”，RFC 1900，1996年2月。
[RENUM2] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[RENUM2]Ferguson，P.和H.Berkowitz，“网络重新编号概述：我为什么想要它以及它到底是什么？”，RFC 2071，1997年1月。
[RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RENUM3]Carpenter，B.，Crowcroft，J.和Y.Rekhter，“今天的IPv4地址行为”，RFC 21011997年2月。
[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[TRANS]Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 1933，1996年4月。
[TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[TSIG]Vixie，P.，Gudmundsson，O.，Eastlake，D.3rd和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA
Matt Crawford Fermilab MS 368美国伊利诺伊州巴达维亚500号邮政信箱60510
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Christian Huitema微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: huitema@microsoft.com
EMail: huitema@microsoft.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。