IPng Working Group Matt Crawford
Internet Draft Fermilab
Christian Huitema
Susan Thomson
Bellcore
August 7, 1998
DNS Extension to Support IP Version 6
<draft-ietf-ipngwg-dns-lookups-01.txt>
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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``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), ftp.nordu.net (North
Europe), ftp.nis.garr.it (South Europe), ftp.ietf.org (US East
Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Distribution of this memo is unlimited.
1. Abstract
This document defines the changes that need to be made to the Domain
Name System to support hosts running IP version 6 (IPv6). The
changes include a new resource record type to store an IPv6 address
and updated definitions of existing query types that return Internet
addresses as part of additional section processing.
For lookups keyed on IPv6 addresses (often called reverse lookups),
this document defines a new domain to hold the top-level delegation
information and a zone structure which allows a zone to be used
without modification for parallel copies of an address space (as for
a multihomed provider or site) and across network renumbering
events.
Expires February 12, 1999 Crawford et al. [Page 1]
Internet Draft IPv6 DNS August 7, 1998
2. Introduction
Current support for the storage of Internet addresses in the Domain
Name System (DNS) [DNSCF, DNSIS] cannot easily be extended to
support IPv6 addresses [AARCH] since applications assume that
address queries return 32-bit IPv4 addresses only. In addition,
maintenance of address information in the DNS is one of several
obstacles which have prevented site and provider renumbering from
being feasible.
To support the storage of IPv6 addresses without impeding
renumbering we define the following extensions.
o A new resource record type, AAAA, is defined to map a domain
name to an IPv6 address, with a provision for indirection for
leading "prefix" bits.
o Existing queries that perform additional section processing to
locate IPv4 addresses are redefined to do that processing for
both IPv4 and IPv6 addresses.
o A new domain, IP6.INT, is defined to support lookups based on
IPv6 address.
o A new prefix-delegation method is defined, relying on new DNS
features [BITLBL, DNAME, EDNS].
The changes are designed to be compatible with existing
applications. The existing support for IPv4 addresses is retained.
Transition issues related to the coexistence of both IPv4 and IPv6
addresses in DNS are discussed in [TRANS].
This memo proposes an incompatible extension to the specification in
RFC 1886 and a departure from current implementation practices. The
changes are designed to facilitate network renumbering and
multihoming. Upon approval of this document, RFC 1886 will become
Historic.
The next three major sections of this document are an overview of
the facilities defined or employed by this specification, the
specification itself, and examples of use.
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]. The key
word "SUGGESTED" signifies a strength between MAY and SHOULD. It is
believed that compliance with the suggestion has tangible benefits
in most instances.
Expires February 12, 1999 Crawford et al. [Page 2]
Internet Draft IPv6 DNS August 7, 1998
3. Overview
This section provides an overview of the DNS facilities for storage
of IPv6 addresses and for lookups based on IPv6 address, including
those defined here and elsewhere.
3.1. Name-to-Address Lookup
IPv6 addresses are stored in a new AAAA ("quad-A") resource record
type. A single AAAA record may include a complete IPv6 address, or
a contiguous portion of an address and information leading to one or
more prefixes. Prefix information comprises a prefix length and a
DNS name which is in turn the owner of one or more AAAA records
defining the prefix or prefixes which are needed to form one or more
complete IPv6 addresses. When the prefix length is zero, no DNS
name is present and all the leading bits of the address are
significant. There may be multiples levels of indirection and the
existence of multiple AAAA records at any level multiplies the
number of IPv6 addresses which are formed.
An application looking up an IPv6 address will generally cause the
DNS resolver to access several AAAA records, and multiple IPv6
addresses may be returned even if the queried name was the owner of
only one AAAA record. The authenticity [DNSSEC] of the returned
address(es) cannot be directly verified. The AAAA records which
contributed to the address(es) may of course be verified if signed.
3.2. Underlying Mechanisms for Reverse Lookups
This section describes the new DNS features which this document
exploits. The reader is directed to the referenced documents for
more details on each.
3.2.1. Delegation on Arbitrary Boundaries
This new scheme for reverse lookups relies on a new type of DNS
label called the "bit-string label" [BITLBL]. This label compactly
represents an arbitrary string of bits which is treated as a
hierarchical sequence of one-bit domain labels. Resource records
can be stored on arbitrary bit-boundaries and lookups will often
employ longest-match queries [EDNS] which will return records from
the nearest ancestor node which has them if the requested
information cannot be found at the queried name itself.
Examples in section 5 will employ the following textual
Expires February 12, 1999 Crawford et al. [Page 3]
Internet Draft IPv6 DNS August 7, 1998
representation for bit-string labels. (This is a subset of the
syntax defined in [BITLBL].) A base indicator "x" for hexadecimal
and a sequence of hexadecimal digits is enclosed between "\[" and
"]". The bits denoted by the digits represent a sequence of one-bit
domain labels ordered from most to least significant. (This is the
opposite of the order they would appear if listed one bit at a time,
but it appears to be a convenient notation.) The digit string may
be followed by a slash ("/") and a decimal count. If omitted, the
implicit count is equal to four times the number of hexadecimal
digits.
Consecutive bit-string labels are equivalent (up to the limit
imposed by the size of the bit count field) to a single bit-string
label containing all the bits of the consecutive labels in the
proper order. As an example, either of the following domain names
could be used in a QCLASS=IN, QTYPE=PTR query to find the name of
the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.INT.
\[x0A0020FFFE812B32/64].\[x0009/16].
\[x07C00040/32].\[xFFF0/13].\[x2/3].IP6.INT.
Note that bits are left-justified in a hexadecimal string.
3.2.2. Reusable Zones
DNS address space delegation is implemented not by zone cuts and NS
records, but by a new analogue to the CNAME record, called the DNAME
resource record [DNAME]. The DNAME record provides alternate naming
to an entire subtree of the domain name space, rather than to a
single node. It causes some suffix of a queried name to be
substituted with a name from the DNAME record's RDATA.
For example, a resolver or server providing recursion, while looking
up a QNAME a.b.c.d.e.f may encounter a DNAME record
d.e.f. DNAME w.xy.
which will cause it to look for a.b.c.w.xy.
Expires February 12, 1999 Crawford et al. [Page 4]
Internet Draft IPv6 DNS August 7, 1998
4. Specifications
4.1. The AAAA Record Type
The AAAA record type is specific to the IN (Internet) class and has
type number 28 (decimal).
4.1.1. Format
The RDATA portion of the AAAA record contains two or three fields.
+---------------------+-----------+-----------------------+
| Ipv6 address |Pre. length| Domain name of prefix |
| (128 bits) | (1 octet) | (variable, 0..255) |
+---------------------+-----------+-----------------------+
o A 128 bit IPv6 address, encoded in network order (high-order
octet first).
o A prefix length, encoded an eight-bit unsigned integer with
value between 0 and 128 inclusive.
o The domain name of the prefix, encoded as a domain name,
possibly compressed as specified in [DNSIS]. (The compression
of the domain name may cause problems if servers that don't
understand the AAAA type cache this record. This problem is
addressed in [LOCOMP] and [EDNS].)
The domain name component SHALL NOT be present if the prefix length
is zero. If the prefix length is non-zero, that number of leading
bits of the IPv6 address field SHOULD be zero.
4.1.2. Processing
The AAAA RR causes type AAAA and type NS additional section
processing for the DNS name, if present, in its RDATA field.
It is an error for a AAAA record with prefix length L1 > 0 to refer
a domain name which owns a AAAA record with a prefix length L2 > L1.
If such a situation is encountered by a resolver, the AAAA record
with the offending prefix length MUST be ignored. Robustness
precludes signalling an error if addresses can still be formed from
valid records, but it is SUGGESTED that zone maintainers from time
to time check all the AAAA records their zones reference.
Expires February 12, 1999 Crawford et al. [Page 5]
Internet Draft IPv6 DNS August 7, 1998
4.1.3. Textual Representation
The textual representation of the RDATA portion of the AAAA resource
record in a zone file comprises two or three fields separated by
whitespace.
o The textual representation of the host's IPv6 address as defined
in [AARCH],
o a prefix length, represented as a decimal number between 0 and
128 inclusive and
o a domain name, if the prefix length is not zero.
The domain name MUST be absent if the prefix length is zero. A
number of leading address bits equal to the prefix length SHOULD be
zero, either implicitly (through the :: notation) or explicitly, as
specified in section 4.1.1.
4.2. Zone Structure for Reverse Lookups
Very little of the new scheme's data actually appears under IP6.INT.
Only the first level of delegation needs to be under that domain,
although more levels of delegation could be placed under IP6.INT if
some top-level delegations were done via NS records instead of DNAME
records. This would incur some cost in renumbering ease at the
level of TLAs [AGGR]. Therefore, it is declared here that all
address space delegations SHOULD be done by the DNAME mechanism
rather than NS.
In addition, since uniformity in deployment will simplify
maintenance of address delegations, it is SUGGESTED that address and
prefix information be stored immediately below a DNS label "IP6".
Stated another way, conformance with this suggestion would mean that
"IP6" is the first label in the RDATA field of DNAME records which
support IPv6 reverse lookups.
When any "reserved" or "must be zero" bits are adjacent to a
delegation boundary, the higher-level entity MUST retain those bits
in its own control and delegate only the bits over which the lower-
level entity has authority.
To find the name of a node given its IPv6 address, a DNS client MUST
perform a query with QCLASS=IN, QTYPE=PTR on the name formed from
the 128 bit address as one or more bit-string labels [BITLBL],
followed by the two standard labels "IP6.INT". If recursive service
was not obtained from a server and the desired PTR record was not
Expires February 12, 1999 Crawford et al. [Page 6]
Internet Draft IPv6 DNS August 7, 1998
returned, the resolver MUST handle returned DNAME records as
specified in [DNAME] and iterate.
5. Usage Illustrations
This section provides examples of use of the mechanisms defined in
the previous section. All addresses and domains mentioned here are
fictitious and for illustrative purposes only. Example delegations
will be on 4-bit boundaries solely for readability; this
specification is indifferent to bit alignment.
Use of the IPv6 aggregatable address format [AGGR] is assumed in the
examples.
5.1. AAAA Record Chains
Let's take the example of a site X that is multi-homed to two
"intermediate" providers A and B. The provider A is itself multi-
homed to two "transit" providers, C and D. The provider B gets its
transit service from a single provider, E. For simplicity suppose
that C, D and E all belong to the same top-level aggregate (TLA)
with identifier (including format prefix) '2345', and the TLA
authority at ALPHA-TLA.ORG assigns to C, D and E respectively the
next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28
and 2345:000E::/32.
C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
B.
A assigns to X the subscriber identification '11' and B assigns the
subscriber identification '22'. As a result, the site X inherits
three address prefixes:
o 2345:00C1:CA11::/48 from A, for routes through C.
o 2345:00D2:DA11::/48 from A, for routes through D.
o 2345:000E:EB22::/48 from B, for routes through E.
Let us suppose that N is a node in the site X, that it is assigned
to subnet number 1 in this site, and that it uses the interface
identifier '1234:5678:9ABC:DEF0'. In our configuration, this node
will have three addresses:
o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
Expires February 12, 1999 Crawford et al. [Page 7]
Internet Draft IPv6 DNS August 7, 1998
We will assume that the site X is represented in the DNS by the
domain name X.EXAMPLE, while A, B, C, D and E are represented by
A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we
assume a subdomain "IP6" that will hold the corresponding prefixes.
The node N is identified by the domain name N.X.EXAMPLE. The
following records would then appear in X's DNS.
$ORIGIN X.EXAMPLE.
N AAAA ::1234:5678:9ABC:DEF0 64 SUBNET-1.IP6
SUBNET-1.IP6 AAAA 0:0:0:1:: 48 IP6
IP6 AAAA 0::0 48 SUBSCRIBER-X.IP6.A.NET.
IP6 AAAA 0::0 48 SUBSCRIBER-X.IP6.B.NET.
And elsewhere there would appear
SUBSCRIBER-X.IP6.A.NET. AAAA 0:0:0011:: 40 A.NET.IP6.C.NET.
SUBSCRIBER-X.IP6.A.NET. AAAA 0:0:0011:: 40 A.NET.IP6.D.NET.
SUBSCRIBER-X.IP6.B.NET. AAAA 0:0:0022:: 40 B-NET.IP6.E.NET.
A.NET.IP6.C.NET. AAAA 0:0001:CA00:: 28 C.NET.ALPHA-TLA.ORG.
A.NET.IP6.D.NET. AAAA 0:0002:DA00:: 28 D.NET.ALPHA-TLA.ORG.
B-NET.IP6.E.NET. AAAA 0:0:EB00:: 32 D.NET.ALPHA-TLA.ORG.
C.NET.ALPHA-TLA.ORG. AAAA 2345:00C0:: 0
D.NET.ALPHA-TLA.ORG. AAAA 2345:00D0:: 0
E.NET.ALPHA-TLA.ORG. AAAA 2345:000E:: 0
Several more-or-less arbitrary assumptions are reflected in the
above structure. All of the following choices could have been made
differently, according to someone's notion of convenience or an
agreement between two parties.
First, that site X has chosen to put subnet information in a
separate AAAA record rather than incorporate it into each node's
AAAA records.
Second, that site X is referred to as "SUBSCRIBER-X" by both of
its providers A and B.
Third, that site X chose to indirect its provider information
through AAAA records at IP6.X.EXAMPLE containing no significant
bits. An alternative would have been to replicate each subnet
record for each provider.
Fourth, B and E used a slightly different prefix naming
Expires February 12, 1999 Crawford et al. [Page 8]
Internet Draft IPv6 DNS August 7, 1998
convention between themselves than did A, C and D. Each
hierarchical pair of network entities must arrange this naming
between themselves.
Fifth, that the upward prefix referral chain topped out at
ALPHA-TLA.ORG. There could have been another level which
assigned the TLA values and holds AAAA records containing those
bits.
Finally, the above structure reflects an assumption that address
fields assigned by a given entity are recorded only in AAAA records
held by that entity. Those bits could be entered into AAAA records
in the lower-level entity's zone instead, thus:
IP6.X.EXAMPLE. AAAA 0:0:11:: 40 IP6.A.NET.
IP6.X.EXAMPLE. AAAA 0:0:22:: 40 IP6.B.NET.
IP6.A.NET. AAAA 0:0:CA00:: 32 IP6.C.NET.
and so on.
Or the higher-level entity could hold both sorts of AAAA records and
allow the lower-level entity to choose to record a copy of the
delegated bits or refer to the higher-level entity's copy. But the
general rule of avoiding data duplication suggests that the proper
place to store assigned values is with the entity that assigned
them.
5.2. Reverse Mapping Zones
Supposing that address space assignments in the TLAs with Format
Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
the IP6.INT zone would include
$ORIGIN IP6.INT.
\[x234500/24] DNAME IP6.ALPHA-TLA.ORG.
\[x267800/24] DNAME IP6.BRAVO-TLA.ORG.
\[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
Eight trailing zero bits have been included in each TLA ID to
reflect the eight reserved bits in the current aggregatable global
unicast addresses format [AGGR].
Expires February 12, 1999 Crawford et al. [Page 9]
Internet Draft IPv6 DNS August 7, 1998
5.2.1. The TLA level
ALPHA-TLA's assignments to network providers C, D and E are
reflected in the reverse data as follows.
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
\[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET.
\[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET.
5.2.2. The ISP level
The providers A through E carry the following delegation information
in their zone files.
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
\[x2DA/12].IP6.D.NET. DNAME IP6.A.NET.
\[xEB/8].IP6.E.NET. DNAME IP6.B.NET.
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
\[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
Note that some domain names appear in the RDATA of more than one
DNAME record. In those cases, one zone is being used to map
multiple prefixes.
5.2.3. The Site Level
Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
name translations. This domain is now referenced by two different
DNAME records held by two different providers.
$ORIGIN IP6.X.EXAMPLE.
\[x0001/16] DNAME SUBNET-1
\[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
and so on.
SUBNET-1 need not have been named in a DNAME record; the subnet bits
could have been joined with the interface identifier. But if
subnets are treated alike in both the AAAA records and in the
reverse zone, it will always be possible to keep the forward and
reverse definition data for each prefix in one zone.
Expires February 12, 1999 Crawford et al. [Page 10]
Internet Draft IPv6 DNS August 7, 1998
5.3. Lookups
A DNS resolver looking for a hostname for the address
2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
DNAME records shown above and would form new queries. Assuming that
it began the process knowing servers for IP6.INT, but that no server
it consulted provided recursion and none had other useful additional
information cached, the sequence of queried names and responses
would be (all with QCLASS=IN, QTYPE=PTR):
To a server for IP6.INT:
QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.INT.
Answer:
\[x234500/24].IP6.INT. DNAME IP6.ALPHA-TLA.ORG.
To a server for IP6.ALPHA-TLA.ORG:
QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
Answer:
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
To a server for IP6.C.NET.:
QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
Answer:
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
To a server for IP6.A.NET.:
QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
Answer:
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
To a server for IP6.X.EXAMPLE.:
QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
Answer:
\[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
\[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
All the DNAME (and NS) records acquired along the way can be cached
to expedite resolution of addresses topologically near to this
address. And if another global address of N.X.EXAMPLE were resolved
within the TTL of the final PTR record, that record would not have
to be fetched again.
Expires February 12, 1999 Crawford et al. [Page 11]
Internet Draft IPv6 DNS August 7, 1998
5.4. Deployment Note
In the illustrations in section 5.1, hierarchically adjacent
entities, such as a network provider and a customer, must agree on a
DNS name which will own the definition of the delegated prefix(es).
One simple convention would be to use a bit-string label
representing exactly the bits which are assigned to the lower-level
entity by the higher. For example, "SUBSCRIBER-X" could be replaced
by "\[x11/8]". This would place the AAAA record(s) defining the
delegated prefix at exactly the same point in the DNS tree as the
DNAME record associated with that delegation. The cost of this
simplification is that the lower-level zone must update its upward-
pointing AAAA records when it is renumbered. This cost may be found
quite acceptable in practice.
6. Security Considerations
DNS Security [DNSSEC] is fully applicable to bit-string labels and
DNAME records. However, just as with IPv4's IN-ADDR.ARPA,
authentication of data in the reverse zones is not equivalent to
authentication of any forward data.
7. References
[AARCH] R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", Currently draft-ietf-ipngwg-addr-arch-v2-
06.txt.
[AGGR] R. Hinden, M. O'Dell, S. Deering, "An IPv6 Aggregatable
Global Unicast Address Format". Currently draft-ietf-
ipngwg-unicast-aggr-05.txt.
[BITLBL] M. Crawford, "Binary Labels in the Domain Name System",
currently draft-ietf-dnsind-binary-labels-01.txt.
[DNAME] M. Crawford, "Non-Terminal DNS Name Redirection", currently
draft-ietf-dnsind-dname-00.txt.
[DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities",
RFC 1034.
[DNSIS] P.V. Mockapetris, "Domain names - implementation and
specification", RFC 1035.
[DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security
Expires February 12, 1999 Crawford et al. [Page 12]
Internet Draft IPv6 DNS August 7, 1998
Extensions", RFC 2065.
[EDNS] P. Vixie, "Extensions to DNS (EDNS)" currently draft-ietf-
dnsind-edns-01.txt.
[KWORD] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[LOCOMP] P. Koch, "A New Scheme for the Compression of Domain
Names", currently draft-ietf-dnsind-local-compression-
01.txt.
[TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 1933.
8. Authors' Addresses
Matt Crawford Christian Huitema Susan Thomson
Fermilab Bellcore Bellcore
MS 368 MCC 1J236B MCC 1C259B
PO Box 500 445 South Street 445 South Street
Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960
USA USA USA
+1 630 840-3461 +1 201 829-4266 +1 201 829-4514
crawdad@fnal.gov huitema@bellcore.com set@bellcore.com
Expires February 12, 1999 Crawford et al. [Page 13]