IPng Working Group Matt Crawford
Internet Draft Fermilab
November 17, 2000
Discovery of Resource Records Designating IPv6 Address prefixes
<draft-ietf-ipngwg-prefix-rr-disc-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The A6 resource record type [A6] was introduced to store IPv6
addresses in a manner which facilitates prefix changes and
assignment of addresses from multiple prefixes. In order to allow
use of dynamic DNS updates while still respecting whatever prefix
hierarchy may be in use in a site's "reverse" DNS zone, a method is
needed for discovering the name(s) of the A6 record(s) which specify
an address prefix.
This memo specifies such a method of prefix name discovery.
1. Introduction
The A6 resource record type [A6] was introduced to store IPv6
addresses in a manner which facilitates prefix changes and
assignment of addresses from multiple prefixes. In order to allow
use of dynamic DNS updates while still respecting whatever prefix
hierarchy may be in use in a site's "reverse" DNS zone, a method is
needed for discovering the name(s) of the A6 record(s) which specify
an address prefix.
Expires May 22, 2001 Crawford et al. [Page 1]
Internet Draft IPv6 DNS November 17, 2000
This memo specifies such a method. No new protocols or DNS record
types are involved -- only a convention for storing the required
information and a procedure for finding it.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD].
2. Prefix Name Storage
Recall from [A6] that address-to-name mapping information may be
stored in a subzone of IP6.ARPA, or in another zone reached by a
chain of one or more DNAME records. Nodenames are stored in PTR
records in such a zone. Extending that custom, we specify that
prefixes are to be named in PTR records in the same way. For a
prefix "P" of length "L" bits there should be a PTR whose RDATA
contains the owner name of an A6 record suitable for designating the
prefix P/L, and this PTR record is to be stored so that it will be
returned by a DNS query for the QNAME \[P/L].IP6.ARPA (possibly
after resolving intervening DNAMEs [DNAME]).
Since the purpose of prefix name discovery is to facilitate dynamic
registration by hosts of their IPv6 addresses in DNS, only the names
of "longest" prefixes need to be discoverable. Accordingly, this
example will show just a prefix which is not subnetted further.
Building on the example from [A6], section 5.2.3, the addition of
the required PTR record is shown below.
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
PTR SUBNET-1.IP6 ; added record
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
$ORIGIN IP6
\[x0001/16] DNAME SUBNET-1
\[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
Notice that the owner and RDATA are the same. This is a consequence
of a somewhat arbitrary choice. The new record could equally well
have been
\[x0001/16].IP6.X.EXAMPLE. PTR SUBNET-1.IP6.X.EXAMPLE.
It cannot be determined by inspecting an A6 DNS record whether that
Expires May 22, 2001 Crawford et al. [Page 2]
Internet Draft IPv6 DNS November 17, 2000
record is meant to specify all the trailing bits of a 128-bit IPv6
address or merely a prefix. Inclusion of the trailing bits does not
preclude its being pointed to as a prefix by some other A6 record.
Nevertheless, a human or automated zone maintainer will generally
know the intended purpose of each A6 record and which one should be
named in a PTR for prefix name discovery.
3. Prefix Name Discovery
If a process wishing to do prefix name discovery has the prefix
itself available (as opposed to a full address of which an unknown
initial portion is the prefix), the prefix can be looked up
directly. Otherwise, two heuristics are available.
First, it is possible that looking up a PTR record based on the full
IPv6 address, as would be done for ordinary address-to-name mapping,
will yield a PTR record containing a hostname. That hostname will
then be the owner of an A6 record. If its prefix length field is
non-zero, its prefix name field will contain the desired name.
Otherwise, looking up a PTR record will fail, returning an
authoritative name error no no data of the requested type. There
will be a set of DNAME records in the answer section of the reply.
The last of these DNAMEs will indicate where to start looking for
the required PTR record. First its target should be tried, then its
owner. An especially persistent implementation can then prepend one
bit at a time from the portion of the IPv6 address not mapped by the
DNAME records to the target name, looking for a PTR record which was
not at a DNAME cut point of its own. An authoritative name error is
a stopping signal for this search.
4. Security Considerations
No security concerns are raised by this specification beyond those
which apply to all uses of the DNS.
5. References
[A6] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering", RFC 2874, July 2000.
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
Expires May 22, 2001 Crawford et al. [Page 3]
Internet Draft IPv6 DNS November 17, 2000
[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
August 1999.
6. Authors' Addresses
Matt Crawford
Fermilab
MS 368
PO Box 500
Batavia, IL 60510
USA
+1 630 840-3461
crawdad@fnal.gov
Expires May 22, 2001 Crawford et al. [Page 4]