[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
   IP: Next Generation Area                               Paul Vixie (ISC)
   INTERNET-DRAFT                                                May, 1996
         Reverse Name Lookups of Encapsulated IPv4 Addresses in IPv6
   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
      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.''
      To learn the current status of any Internet-Draft, please check the
      ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
      Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
      munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
      ftp.isi.edu (US West Coast).
      [RFC1884] specified two IPv6 address forms that encapsulated IPv4
      addresses.  [RFC1886] specified a new DNS RR type (AAAA) to map
      domain names to IPv6 addresses, and also specified the form of the
      PTR RR owner name used to map IPv6 addresses back to the domain name
      of that host or interface.
      This memo amends [RFC1886] and gives two exceptions to its rules
      regarding PTR RR owner name correspondance to IPv6 addresses.
      Specifically, the two IPv4 encapsulation methods are exempted from
      [RFC1886]'s nybble mapping, and are made subject to the appropriate
      rules from [RFC1035] and [RFC1101].
   Expires November 1996                                           [Page 1]

   INTERNET-DRAFT                  IPV6 PTR                        May 1996
   1 - Overview
   1.1. In [RFC1884 2.4.4] we see that addresses of the form ::D.D.D.D
   (which means the first 96 bits of the address are binary zero, and the
   last 32 bits are an IPv4 address) are used to ``tunnel IPv6 packets over
   IPv4 routing infrastructure.''  Later in [ibid] we see that addresses of
   the form ::FFFF:D.D.D.D (that is, 80 ``zero'' bits, 16 ``one'' bits, and
   an IPv4 address) are used to ``represent the addresses of IPv4-only
   nodes (those that *do not* support IPv6) as IPv6 addresses.''
   1.2. In [RFC1886 2.5] we see that an inverse name lookup for an IPv6
   address is done by reversing the nybbles, formatting them as hexadecimal
   ASCII, and using each as a DNS label under the domain IP6.INT.  Thus, to
   find the name associated with address ``4321:0:1:2:3:4:567:89ab,'' one
   would search for a PTR RR at the name:
   1.3. This leaves open the question of how to do inverse name lookups on
   the two IPv6 address forms which actually describe IPv4 endpoints.
   Should a resolver look under the IP6.INT for a nybble wise name, or
   under IN-ADDR.ARPA for a byte wise name?  Due to format differences,
   there is no data oriented solution (such as CNAME RRs or replicate NS
   RRs) available to simply make a union in the namespace so that it does
   not matter which query name is used.
   1.4. This memo recommends that the two IPv6 address forms which
   encapsulate IPv4 addresses shall follow the usual IPv4 inverse naming
   rules (i.e., IN-ADDR.ARPA).  It is the author's view that inverse naming
   authority and address allocation authority must always be delegated
   together, and that any IPv4 address, no matter what context it is used
   in, has a single correct PTR RRset denoting the name(s) of the host or
   interface to which that address is bound.
   Expires November 1996                                           [Page 2]

   INTERNET-DRAFT                  IPV6 PTR                        May 1996
   2 - Detail
   2.1. For a mapped or tunnelled IPv4 address represented in IPv6
   notation, inverse name lookups are to be done by stripping off the first
   96 bits of the address, and using the last 32 bits as a raw IPv4
   address.  From [RFC1884]:
                         IPv6-Tunnelled IPv4 Address
      |                80 bits               | 16 |      32 bits        |
      |0000..............................0000|0000|    IPv4 address     |
                           IPv6-Mapped IPv4 Address
      |                80 bits               | 16 |      32 bits        |
      |0000..............................0000|FFFF|    IPv4 address     |
   2.2. The encapsulated 32 bit IPv4 is to be broken down into four octets,
   and these octets are reversed, formatted in decimal ASCII, and used as
   labels under the IN-ADDR.ARPA domain.
                                 IPv4 Address
      |     8 bits     |     8 bits     |     8 bits     |     8 bits     |
      |     Octet1     |     Octet2     |     Octet3     |     Octet4     |
                           IN-ADDR.ARPA Owner Name
      <Octet4> . <Octet3> . <Octet2> . <Octet1> . IN-ADDR . ARPA
   2.3. A normal DNS query for a PTR RR is done.  If the response contains
   an RRset matching the owner name and PTR type, then the RDATA(s) of
   these RRs are the names associated with the hosts or interfaces using
   the IPv4 address corresponding to this owner name.  Multiple RRs can be
   present in the response PTR RRset, if this address is reachable by more
   than one A RR name.  Thus, A RRs and PTR RRs are symmetric, while CNAME
   aliases are single ended.
   Expires November 1996                                           [Page 3]

   INTERNET-DRAFT                  IPV6 PTR                        May 1996
   3 - Example
      IPv6 Address           PTR Owner Name
   4 - Security Considerations
   5 - References
      P. Mockapetris, ``Domain Names - Implementation and Specification,''
      RFC 1035, USC/Information Sciences Institute, November 1987.
      P. Mockapetris, ``DNS Encoding of Network Names and Other Types,'',
      RFC 1101, USC/Information Sciences Institute, April 1898.
      R. Hinden, S. Deering, ``IP Version 6 Addressing Architecture,'' RFC
      1884, Ipsilon Networks and Xerox PARC, December, 1995.
      S. Thomson, C. Huitema, ``DNS Extensions to support IP version 6,''
      RFC 1886, Bellcore and INRIA, December 1995.
   6 - Acknowledgements
   The <ipng@sunroof.eng.sun.com> mailing list was instrumental in
   crystallizing the views presented in this document.
   7 - Author's Address
      Paul Vixie
         Internet Software Consortium
         Star Route Box 159A
         Woodside, CA 94062
         +1 415 747 0204
   Expires November 1996                                           [Page 4]