6to4 Reverse DNS Delegation Specification
RFC 5158
| Document | Type |
RFC - Informational
(March 2008; Errata)
Was draft-huston-6to4-reverse-dns (individual in ops area)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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
Show full document text