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

Versions: 00                                                            
Internet-Draft                                            O. Gudmundsson
IPng Working Group                                                   TIS
<draft-ietf-ipng-dns-reverse-lookup-00.txt>                November 1997

                 Reverse Address lookup in DNS for IPng.

  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.


     This document proposes a new mechanism to represent inverse address
     mapping in the Domain Name System (DNS) for IP version 6 (IPv6).
     Documented in here are the changes needed for securing the binding
     and delegation of address ranges, to facilitate queries for the
     binding of address to host name. This document also defines a
     mechanism for dumb resolvers to query directly for the binding.

     The changes include a new resource record to delegate the address
     space in segments based on arbitrary bit boundaries. This proposal
     provides a mechanism that is self checking and can be traversed
     from both top and bottom. Additional processing requirements on
     IPv6 aware resolvers and servers are defined.

Gudmundsson                        Expires May 1998             [Page 1]

Internet-Draft      ipngwg-dns-reverse-lookup-00.txt       November 1997

  1. Introduction

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

     A proposal to store IPv6 address was proposed[RFC1886] but that
     proposal does not scale well to the new IPv6 address
     architecture[HD97]. The main drawbacks are that there has to be a
     AAAA record for all routing prefixes for every host. If one routing
     prefix changes, all AAAA records affected need to be changed and,
     if DNSSEC[RFC2065] is used, then all affected AAAA sets need to be
     resigned.  A new proposal[HT97] addresses a how IPv6 address lookup
     can be accomplished while avoiding the above problems.

     To support the lookup of the mapping from address to host name
     (reverse lookup) for IPv6 addresses this document defines the
     following extensions:

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

        * A new resource record type to represent delegations in the
          reverse map.

     This memo proposes an incompatible extension to the specification
     in RFC 1886, and a departure from current implementation practices,
     but is as compatible with current practices as possible.  The
     structure defined in here can also be extended to other address
     types, such as IPv4.

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     this document are to be interpreted as described in [RFC2119].

  2. Motivation and Design criteria

     Reverse address maps are used to identify what computer is trying
     to connect to another computer. This is an essential tool for
     network services providers, this is also used to debug network

Gudmundsson                        Expires May 1998             [Page 2]

Internet-Draft      ipngwg-dns-reverse-lookup-00.txt       November 1997

     This document proposes a radical new way to handle reverse mapping
     of addresses for IPng. The main motivations for this proposal are
     to meet the following requirements:
        * IPng new addressing architecture
        * Support for rapid renumbering with minimal cost to DNS servers
        * Allow the reverse address map to be maintained in a
          distributed way similar to the forward address map
        * Provide verifiable binding of addresses to names when
          DNSSEC is used.

     This design takes into account many of the lessons learned from the
     problems in IPv4 reverse address maps when classless delegations
     where introduced.

     This proposal requires that the domain names in the reverse map be
     binary values. This is done to save space and time. If the
     community does not think this is a good idea it is possible to
     encode the binary values in Base64 or Hex, but given that most
     reverse lookups are performed by computers without any human
     interaction this should not be a problem and will reduce DNS server

     This proposal allows delegations to occur on any bit boundary in
     the address. This could in theory lead to the problem where a
     reverse address has 130 labels (128 bits + 2 for IP6.INT.).  In
     practice this is impossible as the bottom delegation is in most
     cases 64 bits. It is also expected that the high level delegations
     will be larger than one bit, somewhere in the range of 4-16 bits,
     but at this point in time there is no guarantee that all
     delegations will take place on boundaries that are a multiple of 4.
     Thus in practice the number of labels in the reverse map is quite

     This proposal encodes each label as a length followed by bit field,
     this differs from the previous RFC[RFC1886] in which reverse
     address labels were on nibble boundaries.

  3. Inverse queries

     Inverse queries are performed by looking for DBIT (Delegated BITs)
     records in the IP6.INT domain.  A DBIT record contains the last bit
     in the next delegation and a domain name that prefix is delegated
     to. The domain name of the DBIT record encodes the delegation
     hierarchy of the IPv6 address.

     The DBIT record is specially designed to allow distributed
     maintenance of the reverse mapping and to fit well with
     DNSSEC[RFC2065]. This draft requires all address allocation

Gudmundsson                        Expires May 1998             [Page 3]

Internet-Draft      ipngwg-dns-reverse-lookup-00.txt       November 1997

     authorities and network providers to maintain an accurate
     reflection of their delegations in the DBIT records.  It is further
     assumed that the DBIT records are signed to protect the data

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

  3.2.1 Encoding of domain names for DBIT records

     Domain names in the IP6.INT. domain encode each label in the
     following way:

        | number of bits  | bit field padded from left   |
        |  (1 octet)      | (variable, 0..128)           |

     Thus a full domain name can be expressed as follows:


     Length of bit field is the smallest number of octets that the
     <bits> bits can fit in, the bit field is right justified and padded
     from left if necessary with bits set to zero.  Suppression of
     leading bytes with value of zero, MUST NOT take place.

     Each label corresponds to a delegation, each delegation is at least
     1 bit.  The labels are in the inverse order of delegation. The top
     level delegation is closest to the IP6 label and the lowest
     delegation is the left most.

Gudmundsson                        Expires May 1998             [Page 4]

Internet-Draft      ipngwg-dns-reverse-lookup-00.txt       November 1997

     Domain names in the IP6.INT. domain are BINARY values.  (This can
     be changed to hex or base64 encoding but at significant cost in
     server processing overhead and name size.)

     Calculating how many bits have been delegated is done by adding up
     the first octet of all but the two right most labels (IP6.INT.).

     There is no direct mapping between IPv6 address such as
     4321:0:1:2:3:4:567:89ab and an IP6.INT. name. The name depends on
     the delegations of address space. Section 3.6.2 describes how to
     support "dumb resolvers".

  3.3 DBIT rdata format

     The data portion of the DBIT record contains two fields:

        | Last bit   |  Name delegated to  |
        | (2 octets) | (variable, 1..256)  |

        * The last bit in the next delegation. (Counted from the first
          bit in an IPv6 address.) Size of this field is set to 2
          octets for compatibility reasons with similar records such
          as NS and MX.

        * the domain name of the authority to which the delegation
          size bits has been delegated to, encoded as a domain name.
          Name compression is not allowed.

     There are two special values that resolvers need to be aware of in
     the last bit field.  Value of 128 delegates all remaining bits in
     the address.  Value of 0 indicates that a host name is represented
     in the domain name.

     DBIT records in the IP6.INT. domain are self checking, so that
     records reflect correct delegation sizes. If a resolver has the
     whole chain of DBIT records from the IP6.INT. root, this allows the
     resolver to perform full verification of the delegations. Similarly
     if a resolver gets a random DBIT record it can derive which bits
     have been delegated and at which boundaries, from the domain name.

Gudmundsson                        Expires May 1998             [Page 5]

Internet-Draft      ipngwg-dns-reverse-lookup-00.txt       November 1997

     When a resolver gets a DBIT record with value 128 it sends the next
     DBIT query to a name in the zone defined in the name delegated
     field. This is done for the following reasons:
        * The same DBIT 0 record can be used for all routing prefixes of
          a site and to avoid resigning all DBIT 0 records at a site when
          prefixes change.
        * EID records at a site are random and do not reflect routing in
          any way.

     When a resolver gets a DBIT record with the value 0 it has reached
     the end. It can now verify all the responses.

     In all cases where the value of ``Last bit'' is greater than 0,
     there MUST be one and only one DBIT record. When the value of
     ``Last bit'' is 0 there MAY be multiple DBIT records, each
     reflecting different host name for that address.

  3.4 DBIT query

     A 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 successful DBIT query MAY contain the NS records for the domain
     name in the DBIT record in the additional data section and MAY
     contain the address records for these name servers in as well as
     the KEY record for the domain name[RFC2065].

  3.5 Textual presentation of DBIT records

     Textual encoding the binary names on the DBIT records can be
     accomplished in hex or base64, or using standard \nnn octet
     notation for each byte, this draft uses hex for clarity reasons.

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

        * last delegated bit as a decimal number,

        * a domain name.

Gudmundsson                        Expires May 1998             [Page 6]

Internet-Draft      ipngwg-dns-reverse-lookup-00.txt       November 1997

  3.6 Processing of inverse queries

     In the following section the word ``resolver'' is used to denote
     both DNS server and a smart DNS resolver that can process multiple
     DBIT records and verify that bindings are correct.  A DNS resolver
     that does not understand or does not want to perform or know about
     DBIT processing is called a "dumb resolver".

     The DBIT request may result in one of the four following

        * an error, either in RCODE or the answer does not contain a
          DBIT record.

        * the return of a DBIT record with delegation value of 1-127

        * the return of a DBIT record with delegation value of 128.

        * the return of a DBIT record with delegation value of 0.

     In the first case the server is stating that the delegation
     requested does not exist. The second case is a valid delegation.
     The third case indicates that all remaining bits are delegated to
     the next level and the domain name should be queried about the
     remaining bits as EID.  The fourth is the host name corresponding
     to the address.

  3.6.1 Smart Resolver query

     A DNS server or Smart Resolver will walk the IP6.INT. delegation
     tree to find the correct DBIT records. It will start at the top of
     the IP6.INT. tree and work its way down the delegation tree.

     As an example, a find reverse mapping of the following address

     To find the top delegation in IP6.INT. the server for INT. is
     queried for

        IP6.INT. DBIT

     In this example the numbering authority is delegated 8 bits, thus
     the answer is:

        IP6.INT.  DBIT  8  iana.org.

Gudmundsson                        Expires May 1998             [Page 7]

Internet-Draft      ipngwg-dns-reverse-lookup-00.txt       November 1997

     Resolver now encodes the top eight bits of the address into a name
     08aa.IP6.INT. and queries the name server for iana.org.  The answer

        08aa.IP6.INT.  DBIT  20   ripe.org.

     Now the resolver knows that the next 12 bits (bits 8-19) are
     delegated to ripe.org.  Next query is sent to the name server for

        0c2f0.08aa.IP6.INT.   DBIT   32   isnet.is.example.

     and this is followed up with a query for

        0c034.0c2f0.08aa.IP6.INT.   DBIT   64   ismennt.is.example.

     and followed by a query for name
     with answer:

        2000010000.0c034.0c2f0.08aa.IP6.INT.   DBIT   128 \

     As this is a delegation for all the remaining bits the query moved
     from the IP6.INT. domain and is issued for 40000000003fff1234. in
     the domain pointed to. Now query is issued for
     with answer:

        40000000003fff1234.thorshofn.isment.is.example.  DBIT   0  \

  3.6.2 Dumb resolver query

     Resolver that that does not want to process DBIT query issues a
     query for 80aa2f003400010000000000003fff1234.IP6.INT.

     DNS Server that gets this in a query MUST know to break it down
     into components as defined in previous section. The DNS server
     returns back to the resolver an answer that is synthesized from the
     responses it got in the answer section.

     The server MUST return the relevant DBIT records and their
     signatures in the additional data section.

Gudmundsson                        Expires May 1998             [Page 8]

Internet-Draft      ipngwg-dns-reverse-lookup-00.txt       November 1997

     In the above example DBIT aware server would have returned in the
     answer section

        80aa2f003400010000000000003fff1234.IP6.INT. DBIT 0 \

     The answer SHOULD have contained in the additional data section the
     DBIT records used to derive this answer from, along with their
     signatures. In the example above the answer would have looked like

        IP6.INT.                             DBIT   8  iana.org.
        08aa.IP6.INT.                        DBIT  20  ripe.org.
        0c2f0.08aa.IP6.INT.                  DBIT  32  isnet.is.example.
        0c034.0c2f0.08aa.IP6.INT.            DBIT  64  ismennt.is.example.
        2000010000.0c034.0c2f0.08aa.IP6.INT. DBIT 128 \
        40000000003fff1234.thorshofn.isment.is.example.  DBIT   0  \

     If a DNS server receiving a dumb DBIT query is authoritative for
     part of the delegation or if it has DBIT records in its cache that
     provide prefix match it MAY start from the longest correct prefix
     DBIT record. For example if the above dumb query has been asked of
     ripe.org. or someone that had the 0c02f3.08aa.IP6.INT. DBIT record.
     In any case the resolver expects to get the 80..... DBIT 0 record

  4. Security Considerations

     This proposal does not address security per se. Correct verifiable
     operation of this model assumes that DNSSEC will be used in the
     IP6.INT. tree and the leaf notes. If DNSSEC is not used, it is
     possible to get verifiable answers if secure transmission channels
     are used to ALL authoritative name servers queried and no data is
     retrieved from untrusted caching servers. In the absence of those
     two secured communication mechanisms DNS data can be spoofed.

  5. Acknowledgments

     Many of the ideas here were developed during a discussion between
     the author, Jim Bound, and Bill Manning. Further evolution of the
     idea has been taken place in conversations with Robert Elz,
     Christian Huitema,  Susan Thompson, and Karen Tracy.

Gudmundsson                        Expires May 1998             [Page 9]

Internet-Draft      ipngwg-dns-reverse-lookup-00.txt       November 1997

  6. References

[RFC1034]  P. Mockapetris, ``Domain Names - Concepts and
           Facilities,'' RFC 1034, ISI, November 1987.

[RFC1035]  P. Mockapetris, ``Domain Names - Implementation
           and Specification,'' RFC 1034, ISI, November

[RFC1886]  S. Thomson, Huitema, ``DNS Extensions to support
           IP version 6,'' RFC 1886, Bellcore, December

[RFC2065]  D. Eastlake , C Kaufman, ``Domain Name System
           Security Extensions,'' RFC 2065, CyberCash &
           Iris, January 1997.

[RFC2119]  S. Bradner, ``Key words for use in RFCs to Indi-
           cate Requirement Level,'' RFC 2119, Harvard,
           March 1997.

[RFC2137]  D. Eastlake 3rd, ``Secure Domain Name System
           Dynamic Update,'' CyberCash, April 1997.

[RFC2181]  R. Elz, R. Bush, ``Clarifications to the DNS
           Specification.'', RFC 2181, Univeristy of Mel-
           borne, RGnet, July 1997.

[HD97]     R. Hinden, S. Deering, ``IP Version 6 Addressing
           Architecture'', Internet Draft, draft-ietf-
           ipngwg-addr-arch-v2-05.txt, Ipsilon, Cisco.

[HT97]     C. Huitema, S. Thomson, ``DNS Extensions to sup-
           port IP version 6'', Internet Draft, draft-ietf-
           ipngwg-aaaa-00.txt, Bellcore.

7. Authors Address

   Olafur Gudmundsson
   Trusted Information Systems
   3060 Washington Road, MD 21738
   (301) 854-5700    (301)-854-5363 FAX.

Gudmundsson                        Expires May 1998            [Page 10]