1124 lines
43 KiB
Plaintext
1124 lines
43 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group M. Crawford
|
||
Request for Comments: 2874 Fermilab
|
||
Category: Standards Track C. Huitema
|
||
Microsoft Corporation
|
||
July 2000
|
||
|
||
|
||
DNS Extensions to Support IPv6 Address Aggregation and Renumbering
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
This document defines changes to the Domain Name System to support
|
||
renumberable and aggregatable IPv6 addressing. The changes include a
|
||
new resource record type to store an IPv6 address in a manner which
|
||
expedites network renumbering 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 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 1]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction ............................................... 2
|
||
2. Overview ................................................... 3
|
||
2.1. Name-to-Address Lookup ............................... 4
|
||
2.2. Underlying Mechanisms for Reverse Lookups ............ 4
|
||
2.2.1. Delegation on Arbitrary Boundaries ............. 4
|
||
2.2.2. Reusable Zones ................................. 5
|
||
3. Specifications ............................................. 5
|
||
3.1. The A6 Record Type ................................... 5
|
||
3.1.1. Format ......................................... 6
|
||
3.1.2. Processing ..................................... 6
|
||
3.1.3. Textual Representation ......................... 7
|
||
3.1.4. Name Resolution Procedure ...................... 7
|
||
3.2. Zone Structure for Reverse Lookups ................... 7
|
||
4. Modifications to Existing Query Types ...................... 8
|
||
5. Usage Illustrations ........................................ 8
|
||
5.1. A6 Record Chains ..................................... 9
|
||
5.1.1. Authoritative Data ............................. 9
|
||
5.1.2. Glue ........................................... 10
|
||
5.1.3. Variations ..................................... 12
|
||
5.2. Reverse Mapping Zones ................................ 13
|
||
5.2.1. The TLA level .................................. 13
|
||
5.2.2. The ISP level .................................. 13
|
||
5.2.3. The Site Level ................................. 13
|
||
5.3. Lookups .............................................. 14
|
||
5.4. Operational Note ..................................... 15
|
||
6. Transition from RFC 1886 and Deployment Notes .............. 15
|
||
6.1. Transition from AAAA and Coexistence with A Records .. 16
|
||
6.2. Transition from Nibble Labels to Binary Labels ....... 17
|
||
7. Security Considerations .................................... 17
|
||
8. IANA Considerations ........................................ 17
|
||
9. Acknowledgments ............................................ 18
|
||
10. References ................................................ 18
|
||
11. Authors' Addresses ........................................ 19
|
||
12. Full Copyright Statement .................................. 20
|
||
|
||
1. Introduction
|
||
|
||
Maintenance of address information in the DNS is one of several
|
||
obstacles which have prevented site and provider renumbering from
|
||
being feasible in IP version 4. Arguments about the importance of
|
||
network renumbering for the preservation of a stable routing system
|
||
and for other purposes may be read in [RENUM1, RENUM2, RENUM3]. To
|
||
support the storage of IPv6 addresses without impeding renumbering we
|
||
define the following extensions.
|
||
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 2]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
o A new resource record type, "A6", 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.ARPA, is defined to support lookups based on
|
||
IPv6 address.
|
||
|
||
o A new prefix-delegation method is defined, relying on new DNS
|
||
features [BITLBL, DNAME].
|
||
|
||
The changes are designed to be compatible with existing application
|
||
programming interfaces. 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 a replacement for the specification in RFC 1886
|
||
[AAAA] and a departure from current implementation practices. The
|
||
changes are designed to facilitate network renumbering and
|
||
multihoming. Domains employing the A6 record for IPv6 addresses can
|
||
insert automatically-generated AAAA records in zone files to ease
|
||
transition. It is expected that after a reasonable period, 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.
|
||
|
||
2. 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 3]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
2.1. Name-to-Address Lookup
|
||
|
||
IPv6 addresses are stored in one or more A6 resource records. A
|
||
single A6 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 A6 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 multiple levels of indirection and the existence of
|
||
multiple A6 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 A6 records, and multiple IPv6
|
||
addresses may be returned even if the queried name was the owner of
|
||
only one A6 record. The authenticity of the returned address(es)
|
||
cannot be directly verified by DNS Security [DNSSEC]. The A6 records
|
||
which contributed to the address(es) may of course be verified if
|
||
signed.
|
||
|
||
Implementers are reminded of the necessity to limit the amount of
|
||
work a resolver will perform in response to a client request. This
|
||
principle MUST be extended to also limit the generation of DNS
|
||
requests in response to one name-to-address (or address-to-name)
|
||
lookup request.
|
||
|
||
2.2. Underlying Mechanisms for Reverse Lookups
|
||
|
||
This section describes the new DNS features which this document
|
||
exploits. This section is an overview, not a specification of those
|
||
features. The reader is directed to the referenced documents for
|
||
more details on each.
|
||
|
||
2.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
|
||
thereby be stored at arbitrary bit-boundaries.
|
||
|
||
Examples in section 5 will employ the following textual
|
||
representation for bit-string labels, which 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
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 4]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
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.ARPA.
|
||
|
||
\[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
|
||
|
||
2.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.
|
||
|
||
3. Specifications
|
||
|
||
3.1. The A6 Record Type
|
||
|
||
The A6 record type is specific to the IN (Internet) class and has
|
||
type number 38 (decimal).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 5]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
3.1.1. Format
|
||
|
||
The RDATA portion of the A6 record contains two or three fields.
|
||
|
||
+-----------+------------------+-------------------+
|
||
|Prefix len.| Address suffix | Prefix name |
|
||
| (1 octet) | (0..16 octets) | (0..255 octets) |
|
||
+-----------+------------------+-------------------+
|
||
|
||
o A prefix length, encoded as an eight-bit unsigned integer with
|
||
value between 0 and 128 inclusive.
|
||
|
||
o An IPv6 address suffix, encoded in network order (high-order octet
|
||
first). There MUST be exactly enough octets in this field to
|
||
contain a number of bits equal to 128 minus prefix length, with 0
|
||
to 7 leading pad bits to make this field an integral number of
|
||
octets. Pad bits, if present, MUST be set to zero when loading a
|
||
zone file and ignored (other than for SIG [DNSSEC] verification)
|
||
on reception.
|
||
|
||
o The name of the prefix, encoded as a domain name. By the rules of
|
||
[DNSIS], this name MUST NOT be compressed.
|
||
|
||
The domain name component SHALL NOT be present if the prefix length
|
||
is zero. The address suffix component SHALL NOT be present if the
|
||
prefix length is 128.
|
||
|
||
It is SUGGESTED that an A6 record intended for use as a prefix for
|
||
other A6 records have all the insignificant trailing bits in its
|
||
address suffix field set to zero.
|
||
|
||
3.1.2. Processing
|
||
|
||
A query with QTYPE=A6 causes type A6 and type NS additional section
|
||
processing for the prefix names, if any, in the RDATA field of the A6
|
||
records in the answer section. This processing SHOULD be recursively
|
||
applied to the prefix names of A6 records included as additional
|
||
data. When space in the reply packet is a limit, inclusion of
|
||
additional A6 records takes priority over NS records.
|
||
|
||
It is an error for an A6 record with prefix length L1 > 0 to refer to
|
||
a domain name which owns an A6 record with a prefix length L2 > L1.
|
||
If such a situation is encountered by a resolver, the A6 record with
|
||
the offending (larger) prefix length MUST be ignored. Robustness
|
||
precludes signaling an error if addresses can still be formed from
|
||
valid A6 records, but it is SUGGESTED that zone maintainers from time
|
||
to time check all the A6 records their zones reference.
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 6]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
3.1.3. Textual Representation
|
||
|
||
The textual representation of the RDATA portion of the A6 resource
|
||
record in a zone file comprises two or three fields separated by
|
||
whitespace.
|
||
|
||
o A prefix length, represented as a decimal number between 0 and 128
|
||
inclusive,
|
||
|
||
o the textual representation of an IPv6 address as defined in
|
||
[AARCH] (although some leading and/or trailing bits may not be
|
||
significant),
|
||
|
||
o a domain name, if the prefix length is not zero.
|
||
|
||
The domain name MUST be absent if the prefix length is zero. The
|
||
IPv6 address MAY be be absent if the prefix length is 128. 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 3.1.1.
|
||
|
||
3.1.4. Name Resolution Procedure
|
||
|
||
To obtain the IPv6 address or addresses which belong to a given name,
|
||
a DNS client MUST obtain one or more complete chains of A6 records,
|
||
each chain beginning with a record owned by the given name and
|
||
including a record owned by the prefix name in that record, and so on
|
||
recursively, ending with an A6 record with a prefix length of zero.
|
||
One IPv6 address is formed from one such chain by taking the value of
|
||
each bit position from the earliest A6 record in the chain which
|
||
validly covers that position, as indicated by the prefix length. The
|
||
set of all IPv6 addresses for the given name comprises the addresses
|
||
formed from all complete chains of A6 records beginning at that name,
|
||
discarding records which have invalid prefix lengths as defined in
|
||
section 3.1.2.
|
||
|
||
If some A6 queries fail and others succeed, a client might obtain a
|
||
non-empty but incomplete set of IPv6 addresses for a host. In many
|
||
situations this may be acceptable. The completeness of a set of A6
|
||
records may always be determined by inspection.
|
||
|
||
3.2. Zone Structure for Reverse Lookups
|
||
|
||
Very little of the new scheme's data actually appears under IP6.ARPA;
|
||
only the first level of delegation needs to be under that domain.
|
||
More levels of delegation could be placed under IP6.ARPA if some
|
||
top-level delegations were done via NS records instead of DNAME
|
||
records, but this would incur some cost in renumbering ease at the
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 7]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
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.ARPA". If recursive service was not
|
||
obtained from a server and the desired PTR record was not returned,
|
||
the resolver MUST handle returned DNAME records as specified in
|
||
[DNAME], and NS records as specified in [DNSCF], and iterate.
|
||
|
||
4. Modifications to Existing Query Types
|
||
|
||
All existing query types that perform type A additional section
|
||
processing, i.e. the name server (NS), mail exchange (MX), and
|
||
mailbox (MB) query types, and the experimental AFS data base (AFSDB)
|
||
and route through (RT) types, must be redefined to perform type A, A6
|
||
and AAAA additional section processing, with type A having the
|
||
highest priority for inclusion and type AAAA the lowest. This
|
||
redefinition means that a name server may add any relevant IPv4 and
|
||
IPv6 address information available locally to the additional section
|
||
of a response when processing any one of the above queries. The
|
||
recursive inclusion of A6 records referenced by A6 records already
|
||
included in the additional section is OPTIONAL.
|
||
|
||
5. Usage Illustrations
|
||
|
||
This section provides examples of use of the mechanisms defined in
|
||
the previous section. All addresses and domains mentioned here are
|
||
intended to be 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.
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 8]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
5.1. A6 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
|
||
|
||
5.1.1. Authoritative Data
|
||
|
||
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 A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
|
||
SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
|
||
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
|
||
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 9]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
And elsewhere there would appear
|
||
|
||
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
|
||
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
|
||
|
||
SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
|
||
|
||
A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
|
||
|
||
A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
|
||
|
||
B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
|
||
|
||
C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
|
||
D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
|
||
E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
|
||
|
||
5.1.2. Glue
|
||
|
||
When, as is common, some or all DNS servers for X.EXAMPLE are within
|
||
the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
|
||
enough "glue" information to enable DNS clients to reach those
|
||
nameservers. This is true in IPv6 just as in IPv4. However, the A6
|
||
record affords the DNS administrator some choices. The glue could be
|
||
any of
|
||
|
||
o a minimal set of A6 records duplicated from the X.EXAMPLE zone,
|
||
|
||
o a (possibly smaller) set of records which collapse the structure
|
||
of that minimal set,
|
||
|
||
o or a set of A6 records with prefix length zero, giving the entire
|
||
global addresses of the servers.
|
||
|
||
The trade-off is ease of maintenance against robustness. The best
|
||
and worst of both may be had together by implementing either the
|
||
first or second option together with the third. To illustrate the
|
||
glue options, suppose that X.EXAMPLE is served by two nameservers
|
||
NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
|
||
::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
|
||
Then the top-level zone EXAMPLE would include one (or more) of the
|
||
following sets of A6 records as glue.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 10]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
$ORIGIN EXAMPLE. ; first option
|
||
X NS NS1.X
|
||
NS NS2.X
|
||
NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
|
||
NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
|
||
SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X
|
||
SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X
|
||
IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
|
||
IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
|
||
|
||
|
||
$ORIGIN EXAMPLE. ; second option
|
||
X NS NS1.X
|
||
NS NS2.X
|
||
NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
|
||
A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
|
||
NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
|
||
A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
|
||
|
||
|
||
$ORIGIN EXAMPLE. ; third option
|
||
X NS NS1.X
|
||
NS NS2.X
|
||
NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111
|
||
A6 0 2345:00D2:DA11:1:1:11:111:1111
|
||
A6 0 2345:000E:EB22:1:1:11:111:1111
|
||
NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222
|
||
A6 0 2345:00D2:DA11:2:2:22:222:2222
|
||
A6 0 2345:000E:EB22:2:2:22:222:2222
|
||
|
||
The first and second glue options are robust against renumbering of
|
||
X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
|
||
those providers' own DNS is unreachable. The glue records of the
|
||
third option are robust against DNS failures elsewhere than the zones
|
||
EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
|
||
address space is renumbered.
|
||
|
||
If the EXAMPLE zone includes redundant glue, for instance the union
|
||
of the A6 records of the first and third options, then under normal
|
||
circumstances duplicate IPv6 addresses will be derived by DNS
|
||
clients. But if provider DNS fails, addresses will still be obtained
|
||
from the zero-prefix-length records, while if the EXAMPLE zone lags
|
||
behind a renumbering of X.EXAMPLE, half of the addresses obtained by
|
||
DNS clients will still be up-to-date.
|
||
|
||
The zero-prefix-length glue records can of course be automatically
|
||
generated and/or checked in practice.
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 11]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
5.1.3. Variations
|
||
|
||
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 A6 record rather than incorporate it into each node's A6
|
||
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 A6 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 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 A6 records containing those bits.
|
||
|
||
Finally, the above structure reflects an assumption that address
|
||
fields assigned by a given entity are recorded only in A6 records
|
||
held by that entity. Those bits could be entered into A6 records in
|
||
the lower-level entity's zone instead, thus:
|
||
|
||
IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET.
|
||
IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
|
||
|
||
IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET.
|
||
and so on.
|
||
|
||
Or the higher-level entities could hold both sorts of A6 records
|
||
(with different DNS owner names) and allow the lower-level entities
|
||
to choose either mode of A6 chaining. But the general principle of
|
||
avoiding data duplication suggests that the proper place to store
|
||
assigned values is with the entity that assigned them.
|
||
|
||
It is possible, but not necessarily recommended, for a zone
|
||
maintainer to forego the renumbering support afforded by the chaining
|
||
of A6 records and to record entire IPv6 addresses within one zone
|
||
file.
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 12]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
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.ARPA zone would include
|
||
|
||
$ORIGIN IP6.ARPA.
|
||
\[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].
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 13]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
$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 A6 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.
|
||
|
||
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.ARPA, 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.ARPA:
|
||
QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
|
||
|
||
Answer:
|
||
\[x234500/24].IP6.ARPA. 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.
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 14]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
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.
|
||
|
||
5.4. Operational 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 A6 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 A6 records when it
|
||
is renumbered. This cost may be found quite acceptable in practice.
|
||
|
||
6. Transition from RFC 1886 and Deployment Notes
|
||
|
||
When prefixes have been "delegated upward" with A6 records, the
|
||
number of DNS resource records required to establish a single IPv6
|
||
address increases by some non-trivial factor. Those records will
|
||
typically, but not necessarily, come from different DNS zones (which
|
||
can independently suffer failures for all the usual reasons). When
|
||
obtaining multiple IPv6 addresses together, this increase in RR count
|
||
will be proportionally less -- and the total size of a DNS reply
|
||
might even decrease -- if the addresses are topologically clustered.
|
||
But the records could still easily exceed the space available in a
|
||
UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or
|
||
SRV query, for example. The possibilities for overall degradation of
|
||
performance and reliability of DNS lookups are numerous, and increase
|
||
with the number of prefix delegations involved, especially when those
|
||
delegations point to records in other zones.
|
||
|
||
DNS Security [DNSSEC] addresses the trustworthiness of cached data,
|
||
which is a problem intrinsic to DNS, but the cost of applying this to
|
||
an IPv6 address is multiplied by a factor which may be greater than
|
||
the number of prefix delegations involved if different signature
|
||
chains must be verified for different A6 records. If a trusted
|
||
centralized caching server (as in [TSIG], for example) is used, this
|
||
cost might be amortized to acceptable levels. One new phenomenon is
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 15]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
the possibility that IPv6 addresses may be formed from a A6 records
|
||
from a combination of secure and unsecured zones.
|
||
|
||
Until more deployment experience is gained with the A6 record, it is
|
||
recommended that prefix delegations be limited to one or two levels.
|
||
A reasonable phasing-in mechanism would be to start with no prefix
|
||
delegations (all A6 records having prefix length 0) and then to move
|
||
to the use of a single level of delegation within a single zone. (If
|
||
the TTL of the "prefix" A6 records is kept to an appropriate duration
|
||
the capability for rapid renumbering is not lost.) More aggressively
|
||
flexible delegation could be introduced for a subset of hosts for
|
||
experimentation.
|
||
|
||
6.1. Transition from AAAA and Coexistence with A Records
|
||
|
||
Administrators of zones which contain A6 records can easily
|
||
accommodate deployed resolvers which understand AAAA records but not
|
||
A6 records. Such administrators can do automatic generation of AAAA
|
||
records for all of a zone's names which own A6 records by a process
|
||
which mimics the resolution of a hostname to an IPv6 address (see
|
||
section 3.1.4). Attention must be paid to the TTL assigned to a
|
||
generated AAAA record, which MUST be no more than the minimum of the
|
||
TTLs of the A6 records that were used to form the IPv6 address in
|
||
that record. For full robustness, those A6 records which were in
|
||
different zones should be monitored for changes (in TTL or RDATA)
|
||
even when there are no changes to zone for which AAAA records are
|
||
being generated. If the zone is secure [DNSSEC], the generated AAAA
|
||
records MUST be signed along with the rest of the zone data.
|
||
|
||
A zone-specific heuristic MAY be used to avoid generation of AAAA
|
||
records for A6 records which record prefixes, although such
|
||
superfluous records would be relatively few in number and harmless.
|
||
Examples of such heuristics include omitting A6 records with a prefix
|
||
length less than the largest value found in the zone file, or records
|
||
with an address suffix field with a certain number of trailing zero
|
||
bits.
|
||
|
||
On the client side, when looking up and IPv6 address, the order of A6
|
||
and AAAA queries MAY be configurable to be one of: A6, then AAAA;
|
||
AAAA, then A6; A6 only; or both in parallel. The default order (or
|
||
only order, if not configurable) MUST be to try A6 first, then AAAA.
|
||
If and when the AAAA becomes deprecated a new document will change
|
||
the default.
|
||
|
||
The guidelines and options for precedence between IPv4 and IPv6
|
||
addresses are specified in [TRANS]. All mentions of AAAA records in
|
||
that document are henceforth to be interpreted as meaning A6 and/or
|
||
AAAA records in the order specified in the previous paragraph.
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 16]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
6.2. Transition from Nibble Labels to Binary Labels
|
||
|
||
Implementations conforming to RFC 1886 [AAAA] perform reverse lookups
|
||
as follows:
|
||
|
||
An IPv6 address is represented as a name in the IP6.INT domain by
|
||
a sequence of nibbles separated by dots with the suffix
|
||
".IP6.INT". The sequence of nibbles is encoded in reverse order,
|
||
i.e. the low-order nibble is encoded first, followed by the next
|
||
low-order nibble and so on. Each nibble is represented by a
|
||
hexadecimal digit. For example, a name for the address
|
||
2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section
|
||
5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
|
||
8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
|
||
|
||
Implementations conforming to this specification will perform a
|
||
lookup of a binary label in IP6.ARPA as specified in Section 3.2. It
|
||
is RECOMMENDED that for a transition period implementations first
|
||
lookup the binary label in IP6.ARPA and if this fails try to lookup
|
||
the 'nibble' label in IP6.INT.
|
||
|
||
7. Security Considerations
|
||
|
||
The signing authority [DNSSEC] for the A6 records which determine an
|
||
IPv6 address is distributed among several entities, reflecting the
|
||
delegation path of the address space which that address occupies.
|
||
DNS Security is fully applicable to bit-string labels and DNAME
|
||
records. And just as in IPv4, verification of name-to-address
|
||
mappings is logically independent of verification of address-to-name
|
||
mappings.
|
||
|
||
With or without DNSSEC, the incomplete but non-empty address set
|
||
scenario of section 3.1.4 could be caused by selective interference
|
||
with DNS lookups. If in some situation this would be more harmful
|
||
than complete DNS failure, it might be mitigated on the client side
|
||
by refusing to act on an incomplete set, or on the server side by
|
||
listing all addresses in A6 records with prefix length 0.
|
||
|
||
8. IANA Considerations
|
||
|
||
The A6 resource record has been assigned a Type value of 38.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 17]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
9. Acknowledgments
|
||
|
||
The authors would like to thank the following persons for valuable
|
||
discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, Randy
|
||
Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont,
|
||
Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden,
|
||
Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
|
||
Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
|
||
|
||
10. References
|
||
|
||
[AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support IP
|
||
version 6, RFC 1886, December 1995.
|
||
|
||
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
|
||
Architecture", RFC 2373, July 1998.
|
||
|
||
[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6
|
||
Aggregatable Global Unicast Address Format", RFC 2374, July
|
||
1998.
|
||
|
||
[BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
|
||
RFC 2673, August 1999.
|
||
|
||
[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
|
||
2672, August 1999.
|
||
|
||
[DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
|
||
Specification", RFC 2181, July 1997.
|
||
|
||
[DNSIS] Mockapetris, P., "Domain names - implementation and
|
||
specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
|
||
Security Extensions", RFC 2535, March 1999.
|
||
|
||
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
|
||
1900, February 1996.
|
||
|
||
[RENUM2] Ferguson, P. and H. Berkowitz, "Network Renumbering
|
||
Overview: Why would I want it and what is it anyway?", RFC
|
||
2071, January 1997.
|
||
|
||
[RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
|
||
Behaviour Today", RFC 2101, February 1997.
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 18]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
|
||
IPv6 Hosts and Routers", RFC 1933, April 1996.
|
||
|
||
[TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
|
||
Wellington, "Secret Key Transaction Authentication for DNS
|
||
(TSIG)", RFC 2845, May 2000.
|
||
|
||
11. Authors' Addresses
|
||
|
||
Matt Crawford
|
||
Fermilab
|
||
MS 368
|
||
PO Box 500
|
||
Batavia, IL 60510
|
||
USA
|
||
|
||
Phone: +1 630 840-3461
|
||
EMail: crawdad@fnal.gov
|
||
|
||
|
||
Christian Huitema
|
||
Microsoft Corporation
|
||
One Microsoft Way
|
||
Redmond, WA 98052-6399
|
||
|
||
EMail: huitema@microsoft.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 19]
|
||
|
||
RFC 2874 IPv6 DNS July 2000
|
||
|
||
|
||
12. Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford, et al. Standards Track [Page 20]
|
||
|