6to4 Reverse DNS Delegation Specification
RFC 5158

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

Network Working Group                                          G. Huston
Request for Comments: 5158                                         APNIC
Category: Informational                                       March 2008

               6to4 Reverse DNS Delegation Specification

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   This memo describes the service mechanism for entering a delegation
   of DNS servers that provide reverse lookup of 6to4 IPv6 addresses
   into the 6to4 reverse zone file.  The mechanism is based on a
   conventional DNS delegation service interface, allowing the service
   client to enter the details of a number of DNS servers for the
   delegated domain.  In the context of a 6to4 reverse delegation, the
   client is primarily authenticated by its source address used in the
   delegation request, and is authorized to use the function if its IPv6
   address prefix corresponds to an address from within the requested
   6to4 delegation address block.

Huston                       Informational                      [Page 1]
RFC 5158                    6to4 Reverse DNS                  March 2008

1.  Introduction

   6to4 [RFC3056] defines a mechanism for allowing isolated IPv6 sites
   to communicate using IPv6 over the public IPv4 Internet.  This is
   achieved through the use of a dedicated IPv6 global unicast address
   prefix.  A 6to4 'router' can use its IPv4 address value in
   conjunction with this global prefix to create a local IPv6 site
   prefix.  Local IPv6 hosts use this site prefix to form their local
   IPv6 address.

   This address structure allows any site that is connected to the IPv4
   Internet the ability to use IPv6 via automatically created IPv6 over
   IPv4 tunnels.  The advantage of this approach is that it allows the
   piecemeal deployment of IPv6 using tunnels to traverse IPv4 network
   segments.  A local site can connect to an IPv6 network without
   necessarily obtaining IPv6 services from its adjacent upstream
   network provider.

   As noted in [6to4-dns], the advantage of this approach is that: "it
   decouples deployment of IPv6 by the core of the network (e.g.
   Internet Service Providers or ISPs) from deployment of IPv6 at the
   edges (e.g. customer sites), allowing each site or ISP to deploy IPv6
   support in its own time frame according to its own priorities.  With
   6to4, the edges may communicate with one another using IPv6 even if
   one or more of their ISPs do not yet provide native IPv6 service."

   The particular question here is the task of setting up a set of
   delegations that allows "reverse lookups" for this address space.

      "[This] requires that there be a delegation path for the IP
      address being queried, from the DNS root to the servers for the
      [DNS] zone which provides the PTR records for that IP address.
      For ordinary IPv6 addresses, the necessary DNS servers and records
      for IPv6 reverse lookups would be maintained by the each
      organization to which an address block is delegated; the
      delegation path of DNS records reflects the delegation of address
      blocks themselves.  However, for IPv6 addresses beginning with the
      6to4 address prefix, the DNS records would need to reflect IPv4
      address delegation.  Since the entire motivation of 6to4 is to
      decouple site deployment of IPv6 from infrastructure deployment of
      IPv6, such records cannot be expected to be present for a site
      using 6to4 - especially for a site whose ISP did not yet support
      IPv6 in any form." [6to4-dns]

Huston                       Informational                      [Page 2]
RFC 5158                    6to4 Reverse DNS                  March 2008

   The desired characteristics of a reverse lookup delegation mechanism
   are that it:

      *  is deployable with minimal overhead or tool development

      *  has no impact on existing DNS software and existing DNS
         operations

      *  performs name lookup efficiently

      *  does not compromise any DNS security functions

2.  Potential Approaches

   There are a number of approaches to this problem, ranging from a
   conventional explicit delegation structure to various forms of
   modified server behaviors that attempt to guess the location of non-
   delegated servers for fragments of this address space.  These
   approaches have been explored in some detail in terms of their
   advantages and drawbacks in [6to4-dns], so only a summary of these
   approaches will be provided here.

2.1.  Conventional Address Delegation

   The problem with this form of delegation is the anticipated piecemeal
   deployment of 6to4 sites.  The reason why an end site would use 6to4
   is commonly that the upstream Internet Service Provider does not
   support an IPv6 transit service and the end site is using 6to4 to