rfc2874.txt

RFC 的详细文档！

   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):

   To a server for IP6.ARPA:
   QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.

        Answer:
        \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.

   To a server for IP6.ALPHA-TLA.ORG:
   QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.

        Answer:
        \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.

   To a server for IP6.C.NET.:
   QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.

        Answer:
        \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.

   To a server for IP6.A.NET.:
   QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.

        Answer:
        \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.

   To a server for IP6.X.EXAMPLE.:
   QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.




Crawford, et al.            Standards Track                    [Page 14]

RFC 2874                        IPv6 DNS                       July 2000


        Answer:
        \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
        \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.

   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.

5.4.  Operational Note

   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.

6.  Transition from RFC 1886 and Deployment Notes

   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.

   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



Crawford, et al.            Standards Track                    [Page 15]

RFC 2874                        IPv6 DNS                       July 2000


   the possibility that IPv6 addresses may be formed from a A6 records
   from a combination of secure and unsecured zones.

   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.

6.1.  Transition from AAAA and Coexistence with A Records

   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.

   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.

   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.

   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.



Crawford, et al.            Standards Track                    [Page 16]

RFC 2874                        IPv6 DNS                       July 2000


6.2.  Transition from Nibble Labels to Binary Labels

   Implementations conforming to RFC 1886 [AAAA] perform reverse lookups
   as follows:

      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."

   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.

7.  Security Considerations

   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.

   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.

8.  IANA Considerations

   The A6 resource record has been assigned a Type value of 38.










Crawford, et al.            Standards Track                    [Page 17]

RFC 2874                        IPv6 DNS                       July 2000


9.  Acknowledgments

   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.

10.  References

   [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.



Crawford, et al.            Standards Track                    [Page 18]

RFC 2874                        IPv6 DNS                       July 2000


   [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.  Authors' Addresses

   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]

























Crawford, et al.            Standards Track                    [Page 19]

RFC 2874                        IPv6 DNS                       July 2000


12.  Full Copyright Statement

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Crawford, et al.            Standards Track                    [Page 20]