RFC 3363 (rfc3363) - Page 3 of 6

Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)

RFC 3363        Representation of IPv6 Addresses in DNS      August 2002


   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.

   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.

2.2 Recommended Standard Action

   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.

3.  Bitlabels in the Reverse DNS Tree

   RFC 2673 defines a new DNS label type.  This was the first new type
   defined since RFC 1035 [RFC 1035].  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.

3.1 Rationale

   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.

3.2 Recommended Standard Action

   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.










Bush, et. al.                Informational