[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03                                                   
Internet Engineering Task Force                        Christian Huitema
INTERNET DRAFT                                             Susan Thomson
                                                                Bellcore
<draft-ietf-ipngwg-aaaa-00.txt>                         November 5, 1997

        DNS Extensions to support IP version 6


Status of this Memo

   This document is an Internet Draft. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress."

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet Drafts
   Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US  West  Coast), or munnari.oz.au (Pacific
   Rim).

   Distribution of this memo is unlimited.

Abstract

   This document defines the changes that need to be made to the Domain
   Name System to support hosts running IP version 6 (IPv6).  The
   changes include a new resource record type to store an IPv6 address,
   a new domain to support lookups based on an IPv6 address, and updated
   definitions of existing query types that return Internet addresses as
   part of additional section processing.



















Thomson & Huitema                                               [Page 1]


Internet draft             IPv6 DNS Extensions             November 1997

1.Introduction

   Current support for the storage of Internet addresses in the Domain
   Name System (DNS)[1,2] cannot easily be extended to support IPv6
   addresses[3] since applications assume that address queries return
   32-bit IPv4 addresses only.

   To support the storage of IPv6 addresses we define the following
   extensions:

      o A new resource record type is defined to map a domain name to an
        IPv6 address.

      o A new domain is defined to support lookups based on address.

      o Existing queries that perform additional section processing to
        locate IPv4 addresses are redefined to perform additional
        section processing on both IPv4 and IPv6 addresses.

   The changes are designed to be compatible with existing software. The
   existing support for IPv4 addresses is retained. Transition issues
   related to the co-existence of both IPv4 and IPv6 addresses in DNS
   are discussed in [4].

   This memo proposes an incompatible extension to the specification in
   RFC 1886, and a departure from current implementation practices. The
   changes are designed to facilitate network renumbering.

2. NEW RESOURCE RECORD DEFINITION AND DOMAIN

   A new record type is defined to store a system's IPv6 address, or
   addresses.  The new record contains the least significant bits of
   the host's IPv6 address. When the number of significant bits is lower
   than 128, the record also contains the domain name of another
   IPv6 system, which typically describes a complete subnet, or a
   complete site.  The most significant bits will be copied from the
   IPv6 address of that system.  If that system has several IPv6
   addresses, the low bits of the host address will be combined with
   each prefix of the several addresses, resulting in as many IPv6
   addresses for the host.

   A system may need several records if it is connected to several domains,
   as would be the case, for example, of a site connected to several
   providers, or of a host connected to different subnets.

2.1 AAAA record type

   The AAAA resource record type is a new record specific to the
   Internet class that stores the lower bits of a  single IPv6 address
   and the name of a domain where to fetch the higher bits.

   The value of the type is 28 (decimal).


Thomson & Huitema                                               [Page 2]


Internet draft             IPv6 DNS Extensions             November 1997


   (Note that we decide here to reuse the name and code specified in
   RFC 1886.  This is questionable, as the record formats are in fact
   incompatible.  An alternative would be to allocate a new code.
   Another alternative would be to adopt a compatible record format,
   composed of 128 bits of address as in RFC 1886, followed by the
   prefix and domain name.  Updated systems would be capable of
   reading the old records.  Old systems, however, would only be
   capable of using the new records if they decide to use the first
   128 bits and ignore the remainder.  In fact, they are more likely
   to complain of a wrong record length.)

2.2 AAAA data format

    +--------------+------------------+-----------------------+
    | Pre. length  | Address low bits | Domain name of subnet |
    |  (1 octet)   |  (0..16 octets)  | (variable, 0..256)    |
    +--------------+------------------+-----------------------+

   The data portion of the AAAA record contains three fields:

    o a prefix length, encoded as one single octet.

    o the lower bits of the address, encoded on a variable number
      of octets.

    o the domain name of the subnet, encoded as a domain name,
      possibly compressed as specified in [3]. (The compression of
      the domain name saves space, but may cause problems if servers
      that don't understand the AAAA type cache this record.)

   The number of octets used to encode the lower bits shall be exactly
   sufficient to encode the complement to 128 bits of the prefix length.
   The following table gives a set of examples:

        Prefix length           Number of octets of address
                0                       16
                16                      14
                27                      13
                48                      10
                64                      8

   When the number of low order bits is not a multiple of 8, the
   address should be padded to the left with binary zeroes.  The
   least significant address bit will always be encoded as the
   least significant bit of the rightmost address octet.

   The domain name component shall not be encoded if the length
   of the prefix is zero.





Thomson & Huitema                                               [Page 3]


Internet draft             IPv6 DNS Extensions             November 1997

2.3 AAAA query

   An AAAA query for a specified domain name in the Internet class
   returns all associated AAAA resource records in the answer section of
   a response.

   A type AAAA query does perform additional section processing, by
   returning the AAAA records associated to the domain names mentioned
   in the domain's AAAA records.

2.4 Textual format of AAAA records

   The textual representation of the data portion of the AAAA resource
   record used in a master database file is composed of three fields
   separated by white spaces:
      o a prefix length, represented as a decimal number,

      o the textual representation of the host's IPv6 address as
        defined in [3],

      o a domain name.

   The domain name may be absent if the prefix length is zero.

3. Inverse queries

   Inverse queries are performed by looking for a DBIT record in
   the IP6.INT domain.  The DBIT resource records contains a prefix
   length and a domain name.   When the prefix length is not equal
   to 128, the search should recurse by looking in the specified domain.

3.1 DBIT record type

   The DBIT resource record type is a new record specific to the
   Internet class that stores a single IPv6 address.

   The value of the type is TBD (decimal).

3.2 DBIT data format

    +--------------+--------------------+
    | Pre. length  |     Domain name    |
    |  (1 octet)   | (variable, 0..256) |
    +--------------+--------------------+

   The data portion of the DBIT record contains two fields:

    o a prefix length, encoded as one single octet.

    o the domain name of the subnet, encoded as a domain name,
      possibly compressed as specified in [3]. (The compression of
      the domain name saves space, but may cause problems if servers
      that don't understand the DBIT type cache this record.)

Thomson & Huitema                                               [Page 5]


Internet draft             IPv6 DNS Extensions             November 1997

   The prefix length is always relative to the start of the address, so
   that if a  prefix describes completely an address its length is always
   set to 128.

3.3 DBIT query

   An DBIT query for a specified domain name in the Internet class
   returns all associated DBIT resource records in the answer section of
   a response.

   A type DBIT query does not perform additional section processing.


3.4 Textual format of DBIT records

   The textual representation of the data portion of the DBIT resource
   record used in a master database file is composed of two fields
   separated by white spaces:

      o a prefix length, represented as a decimal number,

      o a domain name.

3.5 IP6.INT Domain

   A special domain is defined to look up a record given an address. The
   intent of this domain is to provide a way of mapping an IPv6 address
   to a host name, although it may be used for other purposes as well.
   The domain is rooted at IP6.INT.

   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,
   the inverse lookup domain name corresponding to the address

       4321:0:1:7:3:4:567:89ab

   would be

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.7.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.

3.6 Processing of inverse queries

   The DBIT request may result in one of the three following
   possibilities:

   * an error,

   * the return of a DBIT record indicating a prefix length of 128,



Thomson & Huitema                                               [Page 6]


Internet draft             IPv6 DNS Extensions             November 1997


   * the return of a DBIT record indicating a prefix length indicating
     a prefix length less than 128.

   The third case will occur if the request has been matched by a
   wildcard entry.  For example, if all the IPv6 addresses that
   start with the prefix  4321:0:1::/48 have been delegated to
   the domain "net.foo.bar", it is possible to enter the record

        DBIT    48 net.foo.bar.

   for the wildcard entry:

        *.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.

   The system that tried to find the name corresponding to the address

        4321:0:1:7:3:4:567:89ab

   will receive this record and will note that the prefix length is only
   equal to 48.  It will thus have to rewrite the inverse name.  The new
   name will be rooted by the specified prefix, and will only contain
   the nibbles that are not subsumed by the prefix.  In our example, that
   means:

        b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.7.0.0.0.net.foo.bar.

   The system will repeat the DBIT query for that new name.  If the
   prefix length in the resulting DBIT is still not equal to 128, it
   will have to repeat the operation.

   If the prefix does not fit on an even number of nibbles, the most
   significant hexadecimal digit will only include the bits that were
   not specified in the prefix.  The other bits will be set to zero.
   For example, if the address

        4321:0:1:7:3:4:567:89ab

   had been matched by the prefix 4321:0:1:6/63, for example by

        DBIT    63 subnet6.foo.bar.

   the name used for the recursion would be:

        b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.1.subnet6.foo.bar.

   Not that the use of wildcard entries is natural in this procedure,
   but is not mandatory.  Other solutions, such as enumeration of
   legal names and replication of the DBIT records, are also acceptable.




Thomson & Huitema                                               [Page 7]


Internet draft             IPv6 DNS Extensions             November 1997

4. MODIFICATIONS TO EXISTING QUERY TYPES

   All existing query types that perform type A additional section
   processing, i.e. name server (NS), mail exchange (MX) and mailbox
   (MB) query types, must be redefined to perform both type A and type
   AAAA additional section processing. These new definitions mean that a
   name server must add any relevant IPv4 addresses and any relevant
   IPv6 addresses available locally to the additional section of a
   response when processing any one of the above queries.

5. SECURITY CONSIDERATIONS

   The AAAA and DBIT records can be secured by using the DNS
   security procedures.  The signature of the AAAA record only proves
   that the record is genuine, i.e. has been inserted in the DNS by the
   manager of the specified domain.  The signature of the DBIT record
   can be used to check the validity of the address delegation.

6. ACKNOWLEDGEMENTS

   Many of the ideas here were developed during a discussion between the
   authors, Robert Elz, Olafur Gudmundsson, Jim Bound, Bill Manning,
   Bob Fink, Mike O'Dell, Matt Crawford, Bob Hinden and Steve Deering.
   The specific AAAA format presented here was proposed by Robert Elz.
   The idea of a DBIT record was proposed by Olafur Gudmundsson.

6. REFERENCES


   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
        13, RFC 1034, USC/Information Sciences Institute, November 1987.

   [2]  Mockapetris, P., "Domain Names - Implementation and Specifica-
        tion", STD 13, RFC 1035, USC/Information Sciences Institute,
        November 1987.

   [3]  Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
        Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
        1995.

   [4]  Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
        Hosts and Routers", Work in Progress.

   [5]  Huitema C., and S. Thomson, "DNS Extensions to support IP
        version 6." RFC 1886.








Thomson & Huitema                                               [Page 8]


Internet draft             IPv6 DNS Extensions             November 1997

Authors' Addresses

   Susan Thomson
   Bellcore
   MCC 1C259B
   445 South Street
   Morristown, NJ 07960
   U.S.A.

   Phone: +1 201-829-4514
   EMail: set@bellcore.com

   Christian Huitema
   Bellcore
   MCC 1J236B
   445 South Street
   Morristown, NJ 07960
   U.S.A.

   Phone: +1 201-829-4266
   EMail: huitema@bellcore.com

































Thomson & Huitema                                               [Page 9]