6to4 Reverse DNS Delegation Specification
RFC 5158
Document | Type |
RFC - Informational
(March 2008; Errata)
Was draft-huston-6to4-reverse-dns (individual in ops area)
|
|
---|---|---|---|
Author | Geoff Huston | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5158 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ron Bonica | ||
Send notices to | (None) |
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 toShow full document text