rfc2874.txt

RFC规范的翻译稿

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：邱忠辉（happyhero [e-mail] ）
译文发布时间：2002-1-30
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
Network Working Group                                       M. Crawford
Request for Comments: 2874                                     Fermilab
Category: Standards Track                                    C. Huitema   
                                                  Microsoft Corporation
                                                              July 2000


支持IPv6地址聚合和重编号的DNS扩展 
（RFC2874 ——DNS Extensions to Support IPv6 Address Aggregation and Renumbering）


本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度和状态。本备忘录的发布不受任何限制。
版权声明
Copyright (C) The Internet Society (2000).

摘要
本文档定义了对域名系统的修改以支持可重编号和可聚合IPv6寻址。这些修改包括用一种加速网络重编号和修改已有查询类型定义的方式以一种新的资源记录类型来存储IPv6地址，这些已有的查询类型返回Internet地址作为部分附加开销。
对于侧重于IPv6地址的查找（常称为反向查找），本文档定义了一种新的区域结构，允许使用一种区域，它无需修改地址空间的相同拷贝（对多宿主供应商和站点而言）并能穿越网络重编号事件。

目录
1. 引言	2
2. 概述	3
2.1 域名到地址的查找	3
2.2 反向查找的根本机制	3
3. 特性	4
3.1 A6记录类型	4
3.1.1 格式	4
3.1.2 处理	5
3.1.3 语义表示	5
3.1.4 域名解析过程	5
3.2 反向查找的区域结构	5
4. 已有查询类型的修改	6
5. 使用说明	6
5.1 A6记录链	6
5.1.1 实验数据	7
5.1.2 粘合	7
5.1.3 变更	8
5.2 反向映射区域	9
5.2.2 ISP级别	9
5.2.3站点级别	10
5.3 查找	10
5.4 操作注意	11
6. RFC1886的过渡和配置注意	11
6.1 向AAAA过渡并与A记录共存	11
6.2 从半位元标记向二进制标记过渡	12
7. 安全性考虑	12
8. IANA考虑	12
9. 鸣谢	12
10. 参考	13
11. 作者地址	14
12. 版权说明	14
致谢	15

1. 引言
维护DNS地址信息是阻碍节点和供应商在IPv4中进行重编号的难题之一。基于保持稳定的路由系统或其它目的，关于网络重编号重要性的观点可以参阅[RENUM1, RENUM2, RENUM3]。为了支持对不能阻止重编号的IPv6地址的存储，我们定义了下面的扩展。
一种新的资源记录类型，“A6”，定义为域名到IPv6地址的映射，并规定了间接的最主要的前缀位。
执行定位IPv4地址额外处理功能的现有查询被重新定义为既处理IPv4地址，又处理IPv6地址。
一种新域，IP.ARPA，定义为支持基于IPv6地址的查找。
定义了一种新的前缀授权方法，它依赖于新的DNS特性[BITLBL, DNAME]。
这些变化都设计成与现有应用编程接口兼容，保留了对IPv4地址的支持。DNS中IPv4和IPv6地址共存相关的转换问题在[TRANS]中讨论。
本文档提出了一种与目前实现相违背的方案并取代RFC1886中的规范。这些变化使网络重编号和多宿主操作更加方便。与IPv6地址对应的A6记录配置的域将自动产生的AAAA记录插入到区域文件中，以简化转换。相信假以时日，RFC1886有望成为历史。
本文档将分为三个主要部分对本规范的定义与配置工具、规范内容和规范的应用案例进行描述。
本文档中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”，“建议”，“或许”，“可选的”在[KWORD]中解释。关键字“推荐”表示介于或许和应该之间，通常认为多数情况下遵从“推荐”会带来切实的好处。

2. 概述
本节简述了存储IPv6地址和基于IPv6地址查找的DNS工具，包括本文档或其它文档定义的工具。
2.1 域名到地址的查找
IPv6地址被保存为一条或多条A6资源记录。单个A6记录或许包括一个完整IPv6地址，或者一个地址的邻近部分和产生一个以上地址前缀的信息。前缀信息包括一个前缀长度和一个域名，这个域名反过来又是一条或多条定义地址前缀的A6记录的所有者，这些地址前缀需要形成一个或多个完整IPv6地址。若前缀长度为0，则没有域名并且所有主要的地址位都是有意义的。或许存在多级间接查找，任何一级存在多个A6记录都会增加其形成的IPv6地址数量。
查找一个IPv6地址的应用程序通常让DNS解析器访问多条A6记录，即使要查找的域名只对应一条A6记录，也可能返回多个IPv6地址。DNS安全[DNSSEC]并不直接认证返回地址的合法性。如果作了标记，自然可以认证返回地址的A6记录。
实现必须限制解析器对应一个客户请求所需的工作量。这个原则必须扩展到限制DNS请求的产生，这些DNS请求对应域名到地址（或地址到域名）查找。
2.2 反向查找的根本机制
本部分描述本文档使用的DNS新特性。本部分是概述，不是这些特性的详述。更详细的细节读者可以参考对应的参考文档。
2.2.1 专用边界的授权
这种反向查找新机制取决于一种被称为“位串标记”[BITLBL]的新DNS标记类型。这种标记简洁地表示一种专用位串，这些位被当作一种分层次有序的单个位域标记。因此，资源记录能存储为专用位边界。
第五部分的例子将配置后文描述的位串标记，它是[BITLBL]中定义的语法的子集。“\[“ and ”]”间包括了十六进制的基本表示“x”和有序的十六进制位。这些用数字表示的位对应了一个有序的重要性递减的单个位域标记。（如果一次只列出一位，这是它们出现的反序，但它似乎是更方便的符号。）这种位串后面有一个斜线“/”和一个十进制数。若省略十进制数部分，表明十进制位数是十六进制位数的四倍。
连续的位串标记和单个位串标记一样（就位数字段大小限制而言）都包含了一定次序的所有连续的标记位。例如，下面的域名可以用一个“QCLASS=IN, QTYPE=PT”的查询来查找IPv6地址为3ffe:7c0:40:9:a00:20ff:fe81:2b32节点的域名。
\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
\[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
2.2.2 可重用区域
DNS地址空间授权不是通过区域分割和NS记录来实现，而是通过一种类似于CNAME的记录，称为DNAME资源记录[DNAME]。DNAME记录为域名空间的整个子树而不是为单个节点提供替代命名。这导致用DNAME记录的RDATA中的名字来取代一些要查询域名的后缀。
例如，当一个提供递归查询的域名解析器或服务器查找一个a.b.c.d.e.f的QNAME时，可能会得到一条将其指向a.b.c.w.xy的DNAME记录：
d.e.f.     DNAME     w.xy.
3. 特性
3.1 A6记录类型
A6记录类型是指IN（互联网）类型和类型编号为38（十进制）的类型。
3.1.1 格式
A6记录的RDATA部分包括两个或三个字段。
    +-----------+------------------+-------------------+
    |  前缀长度 |     地址后缀     |      名字前缀     |
    | (1 octet) |  (0..16 octets)  |  (0..255 octets)  |
    +-----------+------------------+-------------------+
前缀长度，用取值范围为0-128的8位无符号整数编码。
IPv6地址后缀，按网络序号（前面的高位字节）编码。这个字段必须有足够的字节数可设置128位的前缀长度，包括0-7位填充位以使这个字段具有完整的字节数。如果出现填充位，当装载区域文件时必须置位为0，并且接收时不予处理（SIG[DNSSEC]认证除外）。
名字前缀，编码成域名。根据[DNSIS]规则，这个名字不能被压缩。
如果前缀长度为0，域名部分将不会出现。如果前缀长度为128，名字后缀部分将不会出现。
建议把要用作其它A6记录前缀的A6记录地址后缀中所有可以忽略的末位都设为0。
3.1.2 处理
一个QTYPE为A6的查询产生对名字前缀的A6类型和NS类型附加处理开销，如果产生的话，这些名字前缀在结果部分A6记录的RDATA字段中。这个处理过程应该将A6记录名字前缀作为附加数据进行递归处理。如果应答包的大小有限制，A6记录的附加部分具有比NS记录更高的优先级。
一个前缀长度L1>0的A6记录如果查找一个具有前缀长度L2>L1的A6记录的域名，会出现错误。如果解析器遇到这种情况，必须忽略这个具有不合法前缀长度的A6记录。如果还能从有效的A6记录得到地址，解析器的健壮性将不让这个错误出现，但建议区域维护经常检查其区域有关的所有A6记录。
3.1.3 语义表示
区域文件中A6资源记录RDATA部分的语义表示包括两个或三个由空格隔开的字段。
前缀长度，表示为一个范围在0-128的十进制数。
[AARCH]中定义的IPv6地址的语义表示（尽管一些首位和末位可能无关紧要）。
域名，如果前缀长度不为0。
如果前缀长度为0，域名必须为空。如果前缀长度为128，IPv6地址可能为空。就象3.1.1节描述的那样，地址前面部分等于前缀长度的位数应该隐式地（通过：：符号）或显式地设为0。
3.1.4 域名解析过程
为了得到IPv6地址或对应给定域名的地址，DNS客户端必须得到一个或多个完整的A6记录链，每个链以给定域名的记录开始，并包括那个记录中前缀名字对应的记录等，递归地以前缀长度为0的A6记录结束。
如果前缀长度为0，域名必须为空。如果前缀长度为128，IPv6地址可能为空。就象3.1.1节描述的那样，地址前面部分等于前缀长度的位数应该隐式地（通过：：符号）或显式地设为0。通过从链中最初的A6记录得到每个位的具体位置，一个链能形成一个IPv6地址，这个链就象前缀长度描述的那样包括位的有效位置。给定域名的所有IPv6地址包括该域名开头的所有完全A6记录得到的地址，丢弃在3.1.2节定义的有无效前缀长度的记录。
如果一些A6查询失败并且其它查询成功，客户端可以为一个主机得到一个非空但不完全的IPv6地址。很多情况下，这也是可以接受的。A6	记录集的完整性可以总是通过检查来确定。
3.2 反向查找的区域结构
事实上新方案的数据很少会在IP6.ARPA的情况下出现；仅仅第一级授权需要在那个域下出现。如果最高级授权是通过NS记录而不是DNAME记录实现，更多授权级别能够置于IP6.ARPA下，但将在TLAs[AGGR]级别重编号时产生一些开销。因此，这里认为所有地址空间授权应该通过DNAME机制而非NS机制来实现。
此外，由于统一配置将简化地址授权的维护，建议地址和前缀信息直接以DNS标记“IP6”保存。换而言之，遵从这个建议意味着“IP6”是支持IPv6反向查找的DNAME记录中RDATA字段中第一个标记。
当授权边界与任何保留或必须为0的位相邻时，高级别的实体必须将那些位由自己控制，并只授权给低级别实体能授权的那些位。
为了给已知IPv6地址的节点查找域名，DNS客户端必须按名字执行一个QCLASS=IN，QTYPE=PTR的查询，这个名字是由作为一个或多个位串标记[BITLBL]的128位地址形成的，在两个标准的“IP6.ARPA”标记后。如果不能从服务器得到递归式服务，并且不能返回要得到的PTR记录，解析器必须反复地处理返回的在[DNAME]中描述的DNAME记录和[DNSCF]中描述的NS记录。
4. 已有查询类型的修改
所有现有执行A类附加处理的查询类型如名字服务器（NS）、邮件交换（MX）、邮箱查询类型（MB）和实验性AFS数据库（AFSDB）以及路由直通类型，必须重新定义成能执行A、A6和AAAA类附加处理，并且A类包括最高优先级，AAAA类优先级别最低。这个重定义就是说，当处理任何上述查询时，名字服务器可以增加任何有关的附加响应部分本地可用的IPv4和IPv6地址信息。A6记录的递归式包括是可选的，这些记录被包含在附加处理部分中的A6记录所引用。