draft-ietf-ipngwg-prefix-rr-disc-00.txt

bind-3.2.

IPng Working Group                                         Matt Crawford
Internet Draft                                                  Fermilab
                                                       November 17, 2000

      Discovery of Resource Records Designating IPv6 Address prefixes
                 <draft-ietf-ipngwg-prefix-rr-disc-00.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.

    Abstract

    The A6 resource record type [A6] was introduced to store IPv6
    addresses in a manner which facilitates prefix changes and
    assignment of addresses from multiple prefixes.  In order to allow
    use of dynamic DNS updates while still respecting whatever prefix
    hierarchy may be in use in a site's "reverse" DNS zone, a method is
    needed for discovering the name(s) of the A6 record(s) which specify
    an address prefix.

    This memo specifies such a method of prefix name discovery.


1.  Introduction

    The A6 resource record type [A6] was introduced to store IPv6
    addresses in a manner which facilitates prefix changes and
    assignment of addresses from multiple prefixes.  In order to allow
    use of dynamic DNS updates while still respecting whatever prefix
    hierarchy may be in use in a site's "reverse" DNS zone, a method is
    needed for discovering the name(s) of the A6 record(s) which specify
    an address prefix.



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


    This memo specifies such a method.  No new protocols or DNS record
    types are involved -- only a convention for storing the required
    information and a procedure for finding it.

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


2.  Prefix Name Storage

    Recall from [A6] that address-to-name mapping information may be
    stored in a subzone of IP6.ARPA, or in another zone reached by a
    chain of one or more DNAME records.  Nodenames are stored in PTR
    records in such a zone.  Extending that custom, we specify that
    prefixes are to be named in PTR records in the same way.  For a
    prefix "P" of length "L" bits there should be a PTR whose RDATA
    contains the owner name of an A6 record suitable for designating the
    prefix P/L, and this PTR record is to be stored so that it will be
    returned by a DNS query for the QNAME \[P/L].IP6.ARPA (possibly
    after resolving intervening DNAMEs [DNAME]).

    Since the purpose of prefix name discovery is to facilitate dynamic
    registration by hosts of their IPv6 addresses in DNS, only the names
    of "longest" prefixes need to be discoverable.  Accordingly, this
    example will show just a prefix which is not subnetted further.

    Building on the example from [A6], section 5.2.3, the addition of
    the required PTR record is shown below.

           $ORIGIN X.EXAMPLE.
           N            A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
           SUBNET-1.IP6 A6 48 0:0:0:1::  IP6
                        PTR   SUBNET-1.IP6        ; added record
           IP6          A6 48 0::0       SUBSCRIBER-X.IP6.A.NET.
           IP6          A6 48 0::0       SUBSCRIBER-X.IP6.B.NET.
           $ORIGIN IP6
           \[x0001/16]                   DNAME   SUBNET-1
           \[x123456789ABCDEF0].SUBNET-1 PTR     N.X.EXAMPLE.

    Notice that the owner and RDATA are the same.  This is a consequence
    of a somewhat arbitrary choice.  The new record could equally well
    have been

         \[x0001/16].IP6.X.EXAMPLE.  PTR   SUBNET-1.IP6.X.EXAMPLE.


    It cannot be determined by inspecting an A6 DNS record whether that



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


    record is meant to specify all the trailing bits of a 128-bit IPv6
    address or merely a prefix.  Inclusion of the trailing bits does not
    preclude its being pointed to as a prefix by some other A6 record.
    Nevertheless, a human or automated zone maintainer will generally
    know the intended purpose of each A6 record and which one should be
    named in a PTR for prefix name discovery.


3.  Prefix Name Discovery

    If a process wishing to do prefix name discovery has the prefix
    itself available (as opposed to a full address of which an unknown
    initial portion is the prefix), the prefix can be looked up
    directly.  Otherwise, two heuristics are available.

    First, it is possible that looking up a PTR record based on the full
    IPv6 address, as would be done for ordinary address-to-name mapping,
    will yield a PTR record containing a hostname.  That hostname will
    then be the owner of an A6 record.  If its prefix length field is
    non-zero, its prefix name field will contain the desired name.

    Otherwise, looking up a PTR record will fail, returning an
    authoritative name error no no data of the requested type.  There
    will be a set of DNAME records in the answer section of the reply.
    The last of these DNAMEs will indicate where to start looking for
    the required PTR record.  First its target should be tried, then its
    owner.  An especially persistent implementation can then prepend one
    bit at a time from the portion of the IPv6 address not mapped by the
    DNAME records to the target name, looking for a PTR record which was
    not at a DNAME cut point of its own.  An authoritative name error is
    a stopping signal for this search.


4.  Security Considerations

    No security concerns are raised by this specification beyond those
    which apply to all uses of the DNS.


5.  References


    [A6] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6
        Address Aggregation and Renumbering", RFC 2874, July 2000.

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




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


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

6.  Authors' Addresses

    Matt Crawford
    Fermilab
    MS 368
    PO Box 500
    Batavia, IL 60510
    USA

    [phone]
    [e-mail]





































Expires May 22, 2001        Crawford et al.                     [Page 4]