draft-ietf-ipngwg-dns-lookups-08.txt

bind-3.2.

IPng Working Group                                         Matt Crawford
Internet Draft                                                  Fermilab
                                                       Christian Huitema
                                                           Susan Thomson
                                                               Telcordia
                                                            May 17, 2000

     DNS Extensions to Support IPv6 Address Aggregation and Renumbering
                   <draft-ietf-ipngwg-dns-lookups-08.txt>



Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC 2026.  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 and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet- Drafts as
    reference material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

1.  Abstract

    This document defines changes to the Domain Name System to support
    renumberable and aggregatable IPv6 addressing.  The changes include
    a new resource record type to store an IPv6 address in a manner
    which expedites network renumbering and updated definitions of
    existing query types that return Internet addresses as part of
    additional section processing.

    For lookups keyed on IPv6 addresses (often called reverse lookups),
    this document defines a new zone structure which allows a zone to be
    used without modification for parallel copies of an address space
    (as for a multihomed provider or site) and across network
    renumbering events.








Expires November 22, 2000   Crawford et al.                     [Page 1]

Internet Draft                  IPv6 DNS                    May 17, 2000


Status of this Memo ...............................................    1

1.  Abstract ......................................................    1

2.  Introduction ..................................................    3

3.  Overview ......................................................    4
    3.1.  Name-to-Address Lookup ..................................    4
    3.2.  Underlying Mechanisms for Reverse Lookups ...............    4
        3.2.1.  Delegation on Arbitrary Boundaries ................    4
        3.2.2.  Reusable Zones ....................................    5

4.  Specifications ................................................    6
    4.1.  The A6 Record Type ......................................    6
        4.1.1.  Format ............................................    6
        4.1.2.  Processing ........................................    6
        4.1.3.  Textual Representation ............................    7
        4.1.4.  Name Resolution Procedure .........................    7
    4.2.  Zone Structure for Reverse Lookups ......................    8

5.  Modifications to Existing Query Types .........................    8

6.  Usage Illustrations ...........................................    9
    6.1.  A6 Record Chains ........................................    9
        6.1.1.  Authoritative Data ................................   10
        6.1.2.  Glue ..............................................   10
        6.1.3.  Variations ........................................   12
    6.2.  Reverse Mapping Zones ...................................   13
        6.2.1.  The TLA level .....................................   13
        6.2.2.  The ISP level .....................................   14
        6.2.3.  The Site Level ....................................   14
    6.3.  Lookups .................................................   14
    6.4.  Operational Note ........................................   15

7.  Transition from RFC 1886 and Deployment Notes .................   16
    7.1.  Transition from AAAA and Coexistence with A Records .....   17
    7.2.  Transition from Nibble Labels to Binary Labels ..........   17

8.  Security Considerations .......................................   18

9.  IANA Considerations ...........................................   18

10.  Acknowledgments ..............................................   18

11.  References ...................................................   19

12.  Authors' Addresses ...........................................   20



Expires November 22, 2000   Crawford et al.                     [Page 2]

Internet Draft                  IPv6 DNS                    May 17, 2000


2.  Introduction

    Maintenance of address information in the DNS is one of several
    obstacles which have prevented site and provider renumbering from
    being feasible in IP version 4.  Arguments about the importance of
    network renumbering for the preservation of a stable routing system
    and for other purposes may be read in documents cited here as
    [RENUM].  To support the storage of IPv6 addresses without impeding
    renumbering we define the following extensions.

    o   A new resource record type, "A6", is defined to map a domain
        name to an IPv6 address, with a provision for indirection for
        leading "prefix" bits.

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

    o   A new domain, IP6.ARPA, is defined to support lookups based on
        IPv6 address.

    o   A new prefix-delegation method is defined, relying on new DNS
        features [BITLBL, DNAME].

    The changes are designed to be compatible with existing application
    programming interfaces.  The existing support for IPv4 addresses is
    retained.  Transition issues related to the coexistence of both IPv4
    and IPv6 addresses in DNS are discussed in [TRANS].

    This memo proposes a replacement for the specification in RFC 1886
    and a departure from current implementation practices.  The changes
    are designed to facilitate network renumbering and multihoming.
    Domains employing the A6 record for IPv6 addresses can insert
    automatically-generated AAAA records in zone files to ease
    transition.  It is expected that after a reasonable period, RFC 1886
    will become Historic.

    The next three major sections of this document are an overview of
    the facilities defined or employed by this specification, the
    specification itself, and examples of use.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [KWORD].  The key
    word "SUGGESTED" signifies a strength between MAY and SHOULD: it is
    believed that compliance with the suggestion has tangible benefits
    in most instances.




Expires November 22, 2000   Crawford et al.                     [Page 3]

Internet Draft                  IPv6 DNS                    May 17, 2000


3.  Overview

    This section provides an overview of the DNS facilities for storage
    of IPv6 addresses and for lookups based on IPv6 address, including
    those defined here and elsewhere.


3.1.  Name-to-Address Lookup

    IPv6 addresses are stored in one or more A6 resource records.  A
    single A6 record may include a complete IPv6 address, or a
    contiguous portion of an address and information leading to one or
    more prefixes.  Prefix information comprises a prefix length and a
    DNS name which is in turn the owner of one or more A6 records
    defining the prefix or prefixes which are needed to form one or more
    complete IPv6 addresses.  When the prefix length is zero, no DNS
    name is present and all the leading bits of the address are
    significant.  There may be multiples levels of indirection and the
    existence of multiple A6 records at any level multiplies the number
    of IPv6 addresses which are formed.

    An application looking up an IPv6 address will generally cause the
    DNS resolver to access several A6 records, and multiple IPv6
    addresses may be returned even if the queried name was the owner of
    only one A6 record.  The authenticity of the returned address(es)
    cannot be directly verified by DNS Security [DNSSEC].  The A6
    records which contributed to the address(es) may of course be
    verified if signed.

    Implementers are reminded of the necessity to limit the amount of
    work a resolver will perform in response to a client request.  This
    principle MUST be extended to also limit the generation of DNS
    requests in response to one name-to-address (or address-to-name)
    lookup request.


3.2.  Underlying Mechanisms for Reverse Lookups

    This section describes the new DNS features which this document
    exploits.  This section is an overview, not a specification of those
    features.  The reader is directed to the referenced documents for
    more details on each.


3.2.1.  Delegation on Arbitrary Boundaries

    This new scheme for reverse lookups relies on a new type of DNS
    label called the "bit-string label" [BITLBL].  This label compactly



Expires November 22, 2000   Crawford et al.                     [Page 4]

Internet Draft                  IPv6 DNS                    May 17, 2000


    represents an arbitrary string of bits which is treated as a
    hierarchical sequence of one-bit domain labels.  Resource records
    can thereby be stored at arbitrary bit-boundaries.

    Examples in section 6 will employ the following textual
    representation for bit-string labels, which is a subset of the
    syntax defined in [BITLBL].  A base indicator "x" for hexadecimal
    and a sequence of hexadecimal digits is enclosed between "\[" and
    "]".  The bits denoted by the digits represent a sequence of one-bit
    domain labels ordered from most to least significant.  (This is the
    opposite of the order they would appear if listed one bit at a time,
    but it appears to be a convenient notation.)  The digit string may
    be followed by a slash ("/") and a decimal count.  If omitted, the
    implicit count is equal to four times the number of hexadecimal
    digits.

    Consecutive bit-string labels are equivalent (up to the limit
    imposed by the size of the bit count field) to a single bit-string
    label containing all the bits of the consecutive labels in the
    proper order.  As an example, either of the following domain names
    could be used in a QCLASS=IN, QTYPE=PTR query to find the name of
    the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.

     \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.

     \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.



3.2.2.  Reusable Zones

    DNS address space delegation is implemented not by zone cuts and NS
    records, but by a new analogue to the CNAME record, called the DNAME
    resource record [DNAME].  The DNAME record provides alternate naming
    to an entire subtree of the domain name space, rather than to a
    single node.  It causes some suffix of a queried name to be
    substituted with a name from the DNAME record's RDATA.

    For example, a resolver or server providing recursion, while looking
    up a QNAME a.b.c.d.e.f may encounter a DNAME record

                         d.e.f.     DNAME     w.xy.

    which will cause it to look for a.b.c.w.xy.







Expires November 22, 2000   Crawford et al.                     [Page 5]

Internet Draft                  IPv6 DNS                    May 17, 2000


4.  Specifications


4.1.  The A6 Record Type

    The A6 record type is specific to the IN (Internet) class and has
    type number 38 (decimal).


4.1.1.  Format

    The RDATA portion of the A6 record contains two or three fields.

            +-----------+------------------+-------------------+
            |Prefix len.|  Address suffix  |    Prefix name    |
            | (1 octet) |  (0..16 octets)  |  (0..255 octets)  |
            +-----------+------------------+-------------------+


    o   A prefix length, encoded as an eight-bit unsigned integer with
        value between 0 and 128 inclusive.

    o   An IPv6 address suffix, encoded in network order (high-order
        octet first).  There MUST be exactly enough octets in this field
        to contain a number of bits equal to 128 minus prefix length,
        with 0 to 7 leading pad bits to make this field an integral
        number of octets.  Pad bits, if present, MUST be set to zero
        when loading a zone file and ignored (other than for SIG
        [DNSSEC] verification) on reception.

    o   The name of the prefix, encoded as a domain name.  By the rules
        of [DNSIS], this name MUST NOT be compressed.

    The domain name component SHALL NOT be present if the prefix length
    is zero.  The address suffix component SHALL NOT be present if the
    prefix length is 128.

    It is SUGGESTED that an A6 record intended for use as a prefix for
    other A6 records have all the insignificant trailing bits in its
    address suffix field set to zero.


4.1.2.  Processing

    A query with QTYPE=A6 causes type A6 and type NS additional section
    processing for the prefix names, if any, in the RDATA field of the
    A6 records in the answer section.  This processing SHOULD be
    recursively applied to the prefix names of A6 records included as



Expires November 22, 2000   Crawford et al.                     [Page 6]

Internet Draft                  IPv6 DNS                    May 17, 2000


    additional data.  When space in the reply packet is a limit,
    inclusion of additional A6 records takes priority over NS records.

    It is an error for a A6 record with prefix length L1 > 0 to refer to
    a domain name which owns a A6 record with a prefix length L2 > L1.
    If such a situation is encountered by a resolver, the A6 record with
    the offending (larger) prefix length MUST be ignored.  Robustness
    precludes signaling an error if addresses can still be formed from
    valid A6 records, but it is SUGGESTED that zone maintainers from
    time to time check all the A6 records their zones reference.


4.1.3.  Textual Representation

    The textual representation of the RDATA portion of the A6 resource
    record in a zone file comprises two or three fields separated by
    whitespace.

    o   A prefix length, represented as a decimal number between 0 and
        128 inclusive,

    o   the textual representation of an IPv6 address as defined in
        [AARCH] (although some leading and/or trailing bits may not be
        significant),

    o   a domain name, if the prefix length is not zero.

    The domain name MUST be absent if the prefix length is zero.  The
    IPv6 address MAY be be absent if the prefix length is 128.  A number
    of leading address bits equal to the prefix length SHOULD be zero,
    either implicitly (through the :: notation) or explicitly, as
    specified in section 4.1.1.


4.1.4.  Name Resolution Procedure