rfc2874.txt

RFC规范的翻译稿

对IP6.C.NET.服务器：
QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
结果：
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.

对IP6.A.NET.服务器：
QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
结果：
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.

对IP6.X.EXAMPLE.服务器：
QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
结果：
\[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
\[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
所以这样得到的DNAME（和NS）记录都存入缓冲，以加快逻辑上接近该地址的地址解析速度。如果要在最末的PTR记录TTL中解析N.X.EXAMPLE的另一个全球地址，那个记录不能再次得到。
5.4 操作注意
在5.1节描述的层次相邻实体中，比如网络服务商和客户，必须就拥有授权前缀定义的DNS名字达成一致。一个简单的约定就是使用位串标记来准确表示那些有高级实体分配给低级实体的位。例如，用“[x11/8]”取代“订阅者-X”。这把定义授权前缀的A6记录放在DNS树中与授权有关的DNAME记录同样的位置。这些简化的代价就是低级区域重编号时，必须修改其上面指出的A6记录。实际上这些代价是可以接受的。
6. RFC1886的过渡和配置注意
如果前缀已经用A6记录“向上授权”，DNS资源记录数目要求有由于非细节因素产生单个IPv6地址增长。典型地，那些记录并不一定来自不同的DNS区域（会因为一般原因而单独失效）。当得到多个IPv6地址时，RR数的增加将按比例减少－并且DNS应答总数甚至会减少－如果地址逻辑上是聚合的。但是，记录仍能轻易超出DNS响应中的可用空间，例如，这些响应会返回很大的RR集[DNSCLAR]给MX、NS或SRV查询。特别地，当那些授权指向其它区域的记录时，性能和DNS查找可靠性全面下降的可能性很大，并且随着授权前缀数目的增多而增大。
DNS安全[DNSSEC]在于缓冲数据的可信赖性，这也是DNS本身固有的问题，但将其应用到IPv6地址的代价会以一个系数而线性增大。如果不同签名链必须由不同A6记录验证，这个系数可能会大于有关授权前缀的数目。如果使用了受信赖的集中式缓冲服务器（例如在[TSIG]）,代价可用分割为可接受的级别。有可能出现一种新的情况，IPv6地址可能由安全和不安全区域中的A6记录产生。
建议授权前缀限制在一个或两个级别，直到从A6记录得到更多的配置经验。一种可行的调整机制就是从没有授权前缀（所以A6记录前缀长度为0）开始，再到在单个区域使用单个级别的授权。（如果A6记录的前缀TTL能维持在一个适当的范围，快速重编号的能力不会失效。）实验中会为子网中的主机引入更多非常灵活的授权。
6.1 向AAAA过渡并与A记录共存
包括A6记录区域的管理员能容易地调整那些能处理AAAA记录但不能处理A记录的解析器。通过一个模拟主机名到IPv6地址解析的处理过程，管理员能给所有具有A6记录的区域名自动产生AAAA记录（参见3.1.4节）。必须注意到，分配给AAAA记录的TTL必须小于在那个记录中形成IPv6地址的A6记录TTLs的最小值。为了全面的健壮性，应该监控不同区域中的A6记录变化（TTL或RDATA中），即使那些产生AAAA记录的区域没有任何变化。如果区域是安全的[DNSSEC]，产生的AAAA记录必须与其余区域数据一起作标记。
特定启发式区域可以用于避免为记录前缀的A6记录产生AAAA记录，尽管过多的记录相当少见也没有害处。这些启发式实例包括删除前缀长度小于区域文件中最大值的A6记录，或者地址后缀末尾有一些位数为0的记录。
在客户端执行查找时，A6和AAAA查询可能设置成其中的一个次序：A6到AAAA；AAAA到A6；仅仅A6；或者两者并行。缺省的次序（如不可配置，则是唯一次序）必须首先是A6，然后是AAAA。如果AAAA不可用，新的配置将改变缺省配置。
[TRANS]描述了IPv4和IPv6地址间的优先级指南和选择。以后文档中所有涉及的AAAA记录都按上段描述次序的A6和/或AAAA记录处理。
6.2 从半位元标记向二进制标记过渡
遵照RFC 1886进行反向查找的实现如下：
通过一序列点分带“.IP6.INT”后缀的半位元，IPv6地址表示成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.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int.”查找。
遵照本规范的实现将在IP6.ARPA进行二进制标记查找,如3.2节所述。建议过渡期间首先在IP6.ARPA进行二进制标记查找，如果查找失败再在IP6.INT按“半位元”查找。
7. 安全性考虑
为那些确定IPv6地址的A6记录的签名认证[DNSSEC]分布在多个实体中，反映了地址占有地址空间的授权路径。DNS安全性完全可用于位串标记和DNAME记录。就象在IPv4中一样，名字到地址映射认证逻辑上独立于地址到名字映射的认证。
不管有没有DNSSEC，DNS查找的选择性干扰会产生3.1.4节所述的不完整但非空的地址。在某种情况下，如果它比DNS完全失效更有害，这种情况可以通过在客户端拒绝响应不完整的地址，或者通过在服务器端列出前缀长度为0的A6记录的所有地址得到缓解。
8. IANA考虑
A6资源记录被分配类型值38。

9. 鸣谢
   作者非常感谢下列人员的有价值的讨论和意见：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.
10. 参考
   [AAAA]   Thomson, S. and C. Huitema, "DNS Extensions to support IP
             version 6, RFC 1886, December 1995.

   [AARCH]  Hinden, R. and S. Deering, "IP Version 6 Addressing
             Architecture", RFC 2373, July 1998.

   [AGGR]   Hinden, R., O'Dell, M. and S. Deering, "An IPv6
             Aggregatable Global Unicast Address Format", RFC 2374, July
             1998.

   [BITLBL]  Crawford, M., "Binary Labels in the Domain Name System",
             RFC 2673, August 1999.

   [DNAME]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
             2672, August 1999.

   [DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [DNSIS]   Mockapetris, P., "Domain names - implementation and
             specification", STD 13, RFC 1035, November 1987.

   [DNSSEC]  Eastlake, D. 3rd and C. Kaufman, "Domain Name System
             Security Extensions", RFC 2535, March 1999.

   [KWORD]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RENUM1]  Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
             1900, February 1996.

   [RENUM2]  Ferguson, P. and H. Berkowitz, "Network Renumbering
             Overview:  Why would I want it and what is it anyway?", RFC
             2071, January 1997.

   [RENUM3]  Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
             Behaviour Today", RFC 2101, February 1997.

   [TRANS]   Gilligan, R. and E. Nordmark, "Transition Mechanisms for
             IPv6 Hosts and Routers", RFC 1933, April 1996.

   [TSIG]    Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
             Wellington, "Secret Key Transaction Authentication for DNS
             (TSIG)", RFC 2845, May 2000.
11. 作者地址
   Matt Crawford
   Fermilab
   MS 368
   PO Box 500
   Batavia, IL 60510
   USA

   Phone: [phone]
   EMail: [e-mail]

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399

   EMail: [e-mail]
12. 版权说明
Copyright (C) The Internet Society (2000).  All Rights Reserved.
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.
致谢
Funding for the RFC Editor function is currently provided by the Internet Society.

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




1
RFC文档中文翻译计划