As per Relevance of the word renumbering, we have this rfc below:
Network Working Group M.
Request for Comments: 2874
Category: Standards Track C.
Microsoft
July 2000
DNS Extensions to Support IPv6 Address Aggregation and
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document defines changes to the Domain Name System to
renumberable and aggregatable IPv6 addressing. The changes include
new resource record type to store an IPv6 address in a manner
expedites network renumbering and updated definitions of
query types that return Internet addresses as part of
section processing
For lookups keyed on IPv6 addresses (often called reverse lookups),
this document defines a new zone structure which allows a zone to
used without modification for parallel copies of an address space (
for a multihomed provider or site) and across network
events
Crawford, et al. Standards Track [Page 1]
RFC 2874 IPv6 DNS July 2000
Table of
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.
Maintenance of address information in the DNS is one of
obstacles which have prevented site and provider renumbering
being feasible in IP version 4. Arguments about the importance
network renumbering for the preservation of a stable routing
and for other purposes may be read in [RENUM1, RENUM2, RENUM3].
support the storage of IPv6 addresses without impeding renumbering
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
to an IPv6 address, with a provision for indirection for
"prefix" bits
o Existing queries that perform additional section processing
locate IPv4 addresses are redefined to do that processing for
IPv4 and IPv6 addresses
o A new domain, IP6.ARPA, is defined to support lookups based
IPv6 address
o A new prefix-delegation method is defined, relying on new
features [BITLBL, DNAME].
The changes are designed to be compatible with existing
programming interfaces. The existing support for IPv4 addresses
retained. Transition issues related to the coexistence of both IPv
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.
changes are designed to facilitate network renumbering
multihoming. Domains employing the A6 record for IPv6 addresses
insert automatically-generated AAAA records in zone files to
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
facilities defined or employed by this specification,
specification itself, and examples of use
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [KWORD]. The key
"SUGGESTED" signifies a strength between MAY and SHOULD: it
believed that compliance with the suggestion has tangible benefits
most instances
2.
This section provides an overview of the DNS facilities for
of IPv6 addresses and for lookups based on IPv6 address,
those defined here and elsewhere
Crawford, et al. Standards Track [Page 3]
RFC 2874 IPv6 DNS July 2000
2.1. Name-to-Address
IPv6 addresses are stored in one or more A6 resource records.
single A6 record may include a complete IPv6 address, or a
portion of an address and information leading to one or
prefixes. Prefix information comprises a prefix length and a
name which is in turn the owner of one or more A6 records
the prefix or prefixes which are needed to form one or more
IPv6 addresses. When the prefix length is zero, no DNS name
present and all the leading bits of the address are significant
There may be multiple levels of indirection and the existence
multiple A6 records at any level multiplies the number of IPv
addresses which are formed
An application looking up an IPv6 address will generally cause
DNS resolver to access several A6 records, and multiple IPv
addresses may be returned even if the queried name was the owner
only one A6 record. The authenticity of the returned address(es
cannot be directly verified by DNS Security [DNSSEC]. The A6
which contributed to the address(es) may of course be verified
signed
Implementers are reminded of the necessity to limit the amount
work a resolver will perform in response to a client request.
principle MUST be extended to also limit the generation of
requests in response to one name-to-address (or address-to-name
lookup request
2.2. Underlying Mechanisms for Reverse
This section describes the new DNS features which this
exploits. This section is an overview, not a specification of
features. The reader is directed to the referenced documents
more details on each
2.2.1. Delegation on Arbitrary
This new scheme for reverse lookups relies on a new type of DNS
called the "bit-string label" [BITLBL]. This label
represents an arbitrary string of bits which is treated as
hierarchical sequence of one-bit domain labels. Resource records
thereby be stored at arbitrary bit-boundaries
Examples in section 5 will employ the following
representation for bit-string labels, which is a subset of the
defined in [BITLBL]. A base indicator "x" for hexadecimal and
sequence of hexadecimal digits is enclosed between "\[" and "]".
bits denoted by the digits represent a sequence of one-bit
Crawford, et al. Standards Track [Page 4]
RFC 2874 IPv6 DNS July 2000
labels ordered from most to least significant. (This is the
of the order they would appear if listed one bit at a time, but
appears to be a convenient notation.) The digit string may
followed by a slash ("/") and a decimal count. If omitted,
implicit count is equal to four times the number of
digits
Consecutive bit-string labels are equivalent (up to the limit
by the size of the bit count field) to a single bit-string
containing all the bits of the consecutive labels in the
order. As an example, either of the following domain names could
used in a QCLASS=IN, QTYPE=PTR query to find the name of the
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
DNS address space delegation is implemented not by zone cuts and
records, but by a new analogue to the CNAME record, called the
resource record [DNAME]. The DNAME record provides alternate
to an entire subtree of the domain name space, rather than to
single node. It causes some suffix of a queried name to
substituted with a name from the DNAME record's RDATA
For example, a resolver or server providing recursion, while
up a QNAME a.b.c.d.e.f may encounter a DNAME
d.e.f. DNAME w.xy
which will cause it to look for a.b.c.w.xy
3.
3.1. The A6 Record
The A6 record type is specific to the IN (Internet) class and
type number 38 (decimal).
Crawford, et al. Standards Track [Page 5]
RFC 2874 IPv6 DNS July 2000
3.1.1.
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
value between 0 and 128 inclusive
o An IPv6 address suffix, encoded in network order (high-order
first). There MUST be exactly enough octets in this field
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
octets. Pad bits, if present, MUST be set to zero when loading
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
[DNSIS], this name MUST NOT be compressed
The domain name component SHALL NOT be present if the prefix
is zero. The address suffix component SHALL NOT be present if
prefix length is 128.
It is SUGGESTED that an A6 record intended for use as a prefix
other A6 records have all the insignificant trailing bits in
address suffix field set to zero
3.1.2.
A query with QTYPE=A6 causes type A6 and type NS additional
processing for the prefix names, if any, in the RDATA field of the A
records in the answer section. This processing SHOULD be
applied to the prefix names of A6 records included as
data. When space in the reply packet is a limit, inclusion
additional A6 records takes priority over NS records
It is an error for an A6 record with prefix length L1 > 0 to refer
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
the offending (larger) prefix length MUST be ignored.
precludes signaling an error if addresses can still be formed
valid A6 records, but it is SUGGESTED that zone maintainers from
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
The textual representation of the RDATA portion of the A6
record in a zone file comprises two or three fields separated
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
[AARCH] (although some leading and/or trailing bits may not
significant),
o a domain name, if the prefix length is not zero
The domain name MUST be absent if the prefix length is zero.
IPv6 address MAY be be absent if the prefix length is 128. A
of leading address bits equal to the prefix length SHOULD be zero
either implicitly (through the :: notation) or explicitly,
specified in section 3.1.1.
3.1.4. Name Resolution
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
including a record owned by the prefix name in that record, and so
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
each bit position from the earliest A6 record in the chain
validly covers that position, as indicated by the prefix length.
set of all IPv6 addresses for the given name comprises the
formed from all complete chains of A6 records beginning at that name
discarding records which have invalid prefix lengths as defined
section 3.1.2.
If some A6 queries fail and others succeed, a client might obtain
non-empty but incomplete set of IPv6 addresses for a host. In
situations this may be acceptable. The completeness of a set of A
records may always be determined by inspection
3.2. Zone Structure for Reverse
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
top-level delegations were done via NS records instead of
records, but this would incur some cost in renumbering ease at
Crawford, et al. Standards Track [Page 7]
RFC 2874 IPv6 DNS July 2000
level of TLAs [AGGR]. Therefore, it is declared here that
address space delegations SHOULD be done by the DNAME
rather than NS
In addition, since uniformity in deployment will simplify
of address delegations, it is SUGGESTED that address and
information be stored immediately below a DNS label "IP6".
another way, conformance with this suggestion would mean that "IP6"
is the first label in the RDATA field of DNAME records which
IPv6 reverse lookups
When any "reserved" or "must be zero" bits are adjacent to
delegation boundary, the higher-level entity MUST retain those
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
perform a query with QCLASS=IN, QTYPE=PTR on the name formed from
128 bit address as one or more bit-string labels [BITLBL],
by the two standard labels "IP6.ARPA". If recursive service was
obtained from a server and the desired PTR record was not returned
the resolver MUST handle returned DNAME records as specified
[DNAME], and NS records as specified in [DNSCF], and iterate
4. Modifications to Existing Query
All existing query types that perform type A additional
processing, i.e. the name server (NS), mail exchange (MX),
mailbox (MB) query types, and the experimental AFS data base (AFSDB
and route through (RT) types, must be redefined to perform type A, A
and AAAA additional section processing, with type A having
highest priority for inclusion and type AAAA the lowest.
redefinition means that a name server may add any relevant IPv4
IPv6 address information available locally to the additional
of a response when processing any one of the above queries.
recursive inclusion of A6 records referenced by A6 records
included in the additional section is OPTIONAL
5. Usage
This section provides examples of use of the mechanisms defined
the previous section. All addresses and domains mentioned here
intended to be fictitious and for illustrative purposes only
Example delegations will be on 4-bit boundaries solely
readability; this specification is indifferent to bit alignment
Use of the IPv6 aggregatable address format [AGGR] is assumed in
examples
Crawford, et al. Standards Track [Page 8]
RFC 2874 IPv6 DNS July 2000
5.1. A6 Record
Let's take the example of a site X that is multi-homed to
"intermediate" providers A and B. The provider A is itself multi
homed to two "transit" providers, C and D. The provider B gets
transit service from a single provider, E. For simplicity
that C, D and E all belong to the same top-level aggregate (TLA)
identifier (including format prefix) '2345', and the TLA authority
ALPHA-TLA.ORG assigns to C, D and E respectively the next
aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28
2345:000E::/32.
C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns
prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40
B
A assigns to X the subscriber identification '11' and B assigns
subscriber identification '22'. As a result, the site X
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
subnet number 1 in this site, and that it uses the
identifier '1234:5678:9ABC:DEF0'. In our configuration, this
will have three addresses
o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF
o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF
o 2345:000E:EB22:0001:1234:5678:9ABC:DEF
5.1.1. Authoritative
We will assume that the site X is represented in the DNS by
domain name X.EXAMPLE, while A, B, C, D and E are represented
A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains,
assume a subdomain "IP6" that will hold the corresponding prefixes
The node N is identified by the domain name N.X.EXAMPLE.
following records would then appear in X's DNS
$ORIGIN X.EXAMPLE
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP
SUBNET-1.IP6 A6 48 0:0:0:1:: IP
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
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.
When, as is common, some or all DNS servers for X.EXAMPLE are
the X.EXAMPLE zone itself, the top-level zone EXAMPLE must
enough "glue" information to enable DNS clients to reach
nameservers. This is true in IPv6 just as in IPv4. However, the A
record affords the DNS administrator some choices. The glue could
any
o a minimal set of A6 records duplicated from the X.EXAMPLE zone
o a (possibly smaller) set of records which collapse the
of that minimal set
o or a set of A6 records with prefix length zero, giving the
global addresses of the servers
The trade-off is ease of maintenance against robustness. The
and worst of both may be had together by implementing either
first or second option together with the third. To illustrate
glue options, suppose that X.EXAMPLE is served by two
NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface
::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
following sets of A6 records as glue
Crawford, et al. Standards Track [Page 10]
RFC 2874 IPv6 DNS July 2000
$ORIGIN EXAMPLE. ; first
X NS NS1.
NS NS2.
NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.
NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.
SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.
SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.
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
X NS NS1.
NS NS2.
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
X NS NS1.
NS NS2.
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
X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail
those providers' own DNS is unreachable. The glue records of
third option are robust against DNS failures elsewhere than the
EXAMPLE and X.EXAMPLE themselves, but must be updated when X'
address space is renumbered
If the EXAMPLE zone includes redundant glue, for instance the
of the A6 records of the first and third options, then under
circumstances duplicate IPv6 addresses will be derived by
clients. But if provider DNS fails, addresses will still be
from the zero-prefix-length records, while if the EXAMPLE zone
behind a renumbering of X.EXAMPLE, half of the addresses obtained
DNS clients will still be up-to-date
The zero-prefix-length glue records can of course be
generated and/or checked in practice
Crawford, et al. Standards Track [Page 11]
RFC 2874 IPv6 DNS July 2000
5.1.3.
Several more-or-less arbitrary assumptions are reflected in the
structure. All of the following choices could have been
differently, according to someone's notion of convenience or
agreement between two parties
First, that site X has chosen to put subnet information in
separate A6 record rather than incorporate it into each node's A
records
Second, that site X is referred to as "SUBSCRIBER-X" by both
its providers A and B
Third, that site X chose to indirect its provider
through A6 records at IP6.X.EXAMPLE containing no
bits. An alternative would have been to replicate each
record for each provider
Fourth, B and E used a slightly different prefix naming
between themselves than did A, C and D. Each hierarchical pair
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
TLA values and holds A6 records containing those bits
Finally, the above structure reflects an assumption that
fields assigned by a given entity are recorded only in A6
held by that entity. Those bits could be entered into A6 records
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
(with different DNS owner names) and allow the lower-level
to choose either mode of A6 chaining. But the general principle
avoiding data duplication suggests that the proper place to
assigned values is with the entity that assigned them
It is possible, but not necessarily recommended, for a
maintainer to forego the renumbering support afforded by the
of A6 records and to record entire IPv6 addresses within one
file
Crawford, et al. Standards Track [Page 12]
RFC 2874 IPv6 DNS July 2000
5.2. Reverse Mapping
Supposing that address space assignments in the TLAs with
Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained
zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY,
the IP6.ARPA zone would
$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
the eight reserved bits in the current aggregatable global
addresses format [AGGR].
5.2.1. The TLA
ALPHA-TLA's assignments to network providers C, D and E are
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
The providers A through E carry the following delegation
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
DNAME record. In those cases, one zone is being used to map
prefixes
5.2.3. The Site
Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to
name translations. This domain is now referenced by two
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
could have been joined with the interface identifier. But if
are treated alike in both the A6 records and in the reverse zone,
will always be possible to keep the forward and reverse
data for each prefix in one zone
5.3.
A DNS resolver looking for a hostname for the
2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of
DNAME records shown above and would form new queries. Assuming
it began the process knowing servers for IP6.ARPA, but that no
it consulted provided recursion and none had other useful
information cached, the sequence of queried names and responses
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
to expedite resolution of addresses topologically near to
address. And if another global address of N.X.EXAMPLE were
within the TTL of the final PTR record, that record would not have
be fetched again
5.4. Operational
In the illustrations in section 5.1, hierarchically
entities, such as a network provider and a customer, must agree on
DNS name which will own the definition of the delegated prefix(es).
One simple convention would be to use a bit-string label
exactly the bits which are assigned to the lower-level entity by
higher. For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]".
This would place the A6 record(s) defining the delegated prefix
exactly the same point in the DNS tree as the DNAME record
with that delegation. The cost of this simplification is that
lower-level zone must update its upward-pointing A6 records when
is renumbered. This cost may be found quite acceptable in practice
6. Transition from RFC 1886 and Deployment
When prefixes have been "delegated upward" with A6 records,
number of DNS resource records required to establish a single IPv
address increases by some non-trivial factor. Those records
typically, but not necessarily, come from different DNS zones (
can independently suffer failures for all the usual reasons).
obtaining multiple IPv6 addresses together, this increase in RR
will be proportionally less -- and the total size of a DNS
might even decrease -- if the addresses are topologically clustered
But the records could still easily exceed the space available in
UDP response which returns a large RRset [DNSCLAR] to an MX, NS,
SRV query, for example. The possibilities for overall degradation
performance and reliability of DNS lookups are numerous, and
with the number of prefix delegations involved, especially when
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
an IPv6 address is multiplied by a factor which may be greater
the number of prefix delegations involved if different
chains must be verified for different A6 records. If a
centralized caching server (as in [TSIG], for example) is used,
cost might be amortized to acceptable levels. One new phenomenon
Crawford, et al. Standards Track [Page 15]
RFC 2874 IPv6 DNS July 2000
the possibility that IPv6 addresses may be formed from a A6
from a combination of secure and unsecured zones
Until more deployment experience is gained with the A6 record, it
recommended that prefix delegations be limited to one or two levels
A reasonable phasing-in mechanism would be to start with no
delegations (all A6 records having prefix length 0) and then to
to the use of a single level of delegation within a single zone. (
the TTL of the "prefix" A6 records is kept to an appropriate
the capability for rapid renumbering is not lost.) More
flexible delegation could be introduced for a subset of hosts
experimentation
6.1. Transition from AAAA and Coexistence with A
Administrators of zones which contain A6 records can
accommodate deployed resolvers which understand AAAA records but
A6 records. Such administrators can do automatic generation of
records for all of a zone's names which own A6 records by a
which mimics the resolution of a hostname to an IPv6 address (
section 3.1.4). Attention must be paid to the TTL assigned to
generated AAAA record, which MUST be no more than the minimum of
TTLs of the A6 records that were used to form the IPv6 address
that record. For full robustness, those A6 records which were
different zones should be monitored for changes (in TTL or RDATA
even when there are no changes to zone for which AAAA records
being generated. If the zone is secure [DNSSEC], the generated
records MUST be signed along with the rest of the zone data
A zone-specific heuristic MAY be used to avoid generation of
records for A6 records which record prefixes, although
superfluous records would be relatively few in number and harmless
Examples of such heuristics include omitting A6 records with a
length less than the largest value found in the zone file, or
with an address suffix field with a certain number of trailing
bits
On the client side, when looking up and IPv6 address, the order of A
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 (
only order, if not configurable) MUST be to try A6 first, then AAAA
If and when the AAAA becomes deprecated a new document will
the default
The guidelines and options for precedence between IPv4 and IPv
addresses are specified in [TRANS]. All mentions of AAAA records
that document are henceforth to be interpreted as meaning A6 and/
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
Implementations conforming to RFC 1886 [AAAA] perform reverse
as follows
An IPv6 address is represented as a name in the IP6.INT domain
a sequence of nibbles separated by dots with the
".IP6.INT". The sequence of nibbles is encoded in reverse order
i.e. the low-order nibble is encoded first, followed by the
low-order nibble and so on. Each nibble is represented by
hexadecimal digit. For example, a name for the
2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in
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
lookup of a binary label in IP6.ARPA as specified in Section 3.2.
is RECOMMENDED that for a transition period implementations
lookup the binary label in IP6.ARPA and if this fails try to
the 'nibble' label in IP6.INT
7. Security
The signing authority [DNSSEC] for the A6 records which determine
IPv6 address is distributed among several entities, reflecting
delegation path of the address space which that address occupies
DNS Security is fully applicable to bit-string labels and
records. And just as in IPv4, verification of name-to-
mappings is logically independent of verification of address-to-
mappings
With or without DNSSEC, the incomplete but non-empty address
scenario of section 3.1.4 could be caused by selective
with DNS lookups. If in some situation this would be more
than complete DNS failure, it might be mitigated on the client
by refusing to act on an incomplete set, or on the server side
listing all addresses in A6 records with prefix length 0.
8. IANA
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.
The authors would like to thank the following persons for
discussions and reviews: Mark Andrews, Rob Austein, Jim Bound,
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,
Nordmark, Mike O'Dell, Michael Patton and Ken Powell
10.
[AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support
version 6, RFC 1886, December 1995.
[AARCH] Hinden, R. and S. Deering, "IP Version 6
Architecture", RFC 2373, July 1998.
[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv
Aggregatable Global Unicast Address Format", RFC 2374,
1998.
[BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection",
2672, August 1999.
[DNSCLAR] Elz, R. and R. Bush, "Clarifications to the
Specification", RFC 2181, July 1997.
[DNSIS] Mockapetris, P., "Domain names - implementation
specification", STD 13, RFC 1035, November 1987.
[DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name
Security Extensions", RFC 2535, March 1999.
[KWORD] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
1900, February 1996.
[RENUM2] Ferguson, P. and H. Berkowitz, "Network
Overview: Why would I want it and what is it anyway?",
2071, January 1997.
[RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4
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
IPv6 Hosts and Routers", RFC 1933, April 1996.
[TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B
Wellington, "Secret Key Transaction Authentication for
(TSIG)", RFC 2845, May 2000.
11. Authors'
Matt
MS 368
PO Box 500
Batavia, IL 60510
Phone: +1 630 840-3461
EMail: crawdad@fnal.
Christian
Microsoft
One Microsoft
Redmond, WA 98052-6399
EMail: huitema@microsoft.
Crawford, et al. Standards Track [Page 19]
RFC 2874 IPv6 DNS July 2000
12. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Crawford, et al. Standards Track [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
