RFC 2874
DNS Extensions to Support IPv6 Address Aggregation and Renumbering
DNS Extensions to Support IPv6 Address Aggregation and Renumbering 🎀
Okay bestie, here's the header info you need 💅
- Network Working Group, RFC 2874
- Authors: M. Crawford (Fermilab) and C. Huitema (Microsoft Corporation) ✨
- Category: Standards Track 🦋
- Date: July 2000 🌸
- Obsoletes/Updates: nothing is listed in this header, but the Introduction proposes a replacement for the specification in RFC 1886 [AAAA] 🙈
Status of This Memo
This doc is a standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💜.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. 🌈
Abstract
So this doc changes the Domain Name System so it can handle renumberable and aggregatable IPv6 addressing 🎀. There are two big changes. The first is a brand-new resource record type that stores an IPv6 address in a way that speeds up network renumbering. The second is updated definitions for existing query types that return Internet addresses as part of additional section processing 🔥.
For lookups keyed on IPv6 addresses (the ones people call reverse lookups), this doc defines a new zone structure. One zone can be used without any modification for parallel copies of an address space, like for a multihomed provider or site, and it keeps working across network renumbering events 🧚.
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 .................................. 201. Introduction ✨
Keeping address info in the DNS is one of several roadblocks that have made site and provider renumbering feel out of reach in IP version 4 😭. If you want the arguments about why renumbering matters for a stable routing system (and other stuff too), check out [RENUM1, RENUM2, RENUM3]. To store IPv6 addresses without getting in renumbering's way, we define these extensions:
- A new resource record type,
A6, maps a domain name to an IPv6 address, with a provision for indirection for leading "prefix" bits 🍓. - Existing queries that do additional section processing to find IPv4 addresses now get redefined to do that same processing for both IPv4 and IPv6 addresses 💅.
- A new domain,
IP6.ARPA, is defined to support lookups based on IPv6 address 🔥. - 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, and the existing support for IPv4 addresses is kept 🫶. Transition issues around IPv4 and IPv6 addresses coexisting in the DNS are discussed in [TRANS] 🌸.
This memo proposes a replacement for the specification in RFC 1886 [AAAA], and it's a departure from current implementation practices 🙈. The whole point is to make renumbering and multihoming easier. Domains using the A6 record for IPv6 addresses can insert automatically-generated AAAA records in zone files to ease the transition. It's 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 used by this spec, the spec 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 word "SUGGESTED" sits between MAY and SHOULD in strength: compliance with the suggestion is believed to have tangible benefits in most instances ✨.
2. Overview 🗺️
This section gives you the big-picture tour of the DNS facilities for storing IPv6 addresses and for doing lookups based on IPv6 address. That includes stuff defined here and stuff defined elsewhere 💖.
2.1. Name-to-Address Lookup
IPv6 addresses are stored in one or more A6 resource records 🌸. A single A6 record can include a complete IPv6 address, or a contiguous chunk of one plus info leading to one or more prefixes. Prefix info is a prefix length plus a DNS name, and that name owns one or more A6 records. Those records define the prefix (or prefixes) 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. You can have multiple levels of indirection, and having multiple A6 records at any level multiplies the number of IPv6 addresses formed 💅.
An application looking up an IPv6 address will usually make the DNS resolver access several A6 records. That means multiple IPv6 addresses can come back even if the queried name only owns one A6 record 😭. DNS Security [DNSSEC] can't directly verify the authenticity of the returned address(es). The A6 records that contributed to them can be verified, though, if they're signed 🔒.
Implementers, this one's for you 🫶: you have 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 this doc exploits 🦋. It's an overview, not a specification of those features, so go to the referenced docs for more details on each one 📚.
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. That means resource records can be stored at arbitrary bit boundaries ✨.
Examples in section 5 use the following textual representation for bit-string labels, which is a subset of the syntax defined in [BITLBL]. A base indicator "x" for hexadecimal, plus 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 🍓. (That's the opposite of the order you'd see if you 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 that's omitted, the implicit count equals 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 🧠. For 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 isn't done with zone cuts and NS records. Instead it uses a new analogue to the CNAME record, called the DNAME resource record [DNAME] 💅. DNAME gives alternate naming to an entire subtree of the domain name space, not just 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 run into 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) 🌸.
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) |
+-----------+------------------+-------------------+- A prefix length, encoded as an eight-bit unsigned integer with a value between 0 and 128 inclusive ✨.
- 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 🫶.
- 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
okay so a query with QTYPE=A6 kicks off type A6 and type NS additional section processing for the prefix names in the RDATA field of the A6 records in the answer section (if there are any) 💅. This processing SHOULD be applied recursively to the prefix names of any A6 records that got included as additional data 🔁. And if the reply packet is running out of room, extra A6 records get priority over NS records 🫶.
it's an error for an A6 record with prefix length L1 > 0 to point at a domain name that owns an A6 record with prefix length L2 > L1 🙈. if a resolver runs into this, the A6 record with the offending (bigger) prefix length MUST be ignored. robustness means no error gets signaled as long as addresses can still be formed from the valid A6 records, but it's SUGGESTED that zone maintainers check all the A6 records their zones reference every so often 🧚.
3.1.3. Textual Representation
the RDATA part of an A6 resource record in a zone file is written as two or three fields separated by whitespace ✨
- a prefix length, written as a decimal number from 0 to 128 inclusive,
- the text form of an IPv6 address as defined in [AARCH] (some leading and/or trailing bits might not matter, though),
- a domain name, but only if the prefix length isn't zero.
the domain name MUST be absent if the prefix length is zero. the IPv6 address MAY 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 get the IPv6 address (or addresses) for a given name, a DNS client MUST grab one or more complete chains of A6 records 🔗. each chain starts with a record owned by the given name, then includes the record owned by that record's prefix name, and so on recursively, ending with an A6 record whose prefix length is zero. one IPv6 address gets formed from each chain by taking each bit position from the earliest A6 record in the chain that validly covers that position, based on the prefix length. the full set of IPv6 addresses for the name is made from all the complete chains starting at that name, and any records with invalid prefix lengths (as defined in section 3.1.2) get thrown out 🗑️.
if some A6 queries fail but others work, a client might end up with a set of IPv6 addresses that isn't empty but isn't complete either 🥲. in lots of situations that's fine. and you can always check whether a set of A6 records is complete just by looking at it 👀.
3.2. Zone Structure for Reverse Lookups
ngl, very little of the new scheme's data actually lives under IP6.ARPA ✨. only the first level of delegation has to go under that domain. you could put more levels under IP6.ARPA if some top-level delegations used NS records instead of DNAME records, but that would make renumbering at the TLA level [AGGR] a lot harder 😩. so it's declared here that all address space delegations SHOULD be done with the DNAME mechanism instead of NS 💅.
also, uniformity makes address delegations way easier to maintain, so it's SUGGESTED that address and prefix info gets stored right below a DNS label "IP6" 🎀. put another way, following this suggestion means "IP6" is the first label in the RDATA field of any DNAME records that support IPv6 reverse lookups 💖.
when any "reserved" or "must be zero" bits sit next to a delegation boundary, the higher-level entity MUST keep those bits under its own control and only delegate the bits the lower-level entity has authority over 🔒.
to find the name of a node from its IPv6 address, a DNS client MUST send a query with QCLASS=IN and QTYPE=PTR on the name made from the 128-bit address as one or more bit-string labels [BITLBL], followed by the two standard labels "IP6.ARPA" 🔍. if recursive service wasn't available from a server and the PTR record you wanted didn't come back, the resolver MUST handle returned DNAME records as specified in [DNAME], handle NS records as specified in [DNSCF], and iterate 🔁.
4. Modifications to Existing Query Types ✨
every existing query type that does type A additional section processing (that's the name server (NS), mail exchange (MX), and mailbox (MB) types, plus the experimental AFS data base (AFSDB) and route through (RT) types) must be redefined to do type A, A6 and AAAA additional section processing 🌈. type A gets the highest priority for inclusion and type AAAA gets the lowest 👑. this redefinition means a name server can add any relevant IPv4 and IPv6 address info it has locally to the additional section of a response, no matter which of those queries it's handling 💜. recursively including A6 records that are referenced by A6 records already in the additional section is OPTIONAL 🧚.
5. Usage Illustrations 🦋
this section gives examples of the mechanisms from the last section in action. every address and domain mentioned here is totally fictitious and just for illustration 🎭. the example delegations sit on 4-bit boundaries purely so they're easier to read; this spec doesn't care about bit alignment 🙈. the examples assume the IPv6 aggregatable address format [AGGR] 💅.
5.1. A6 Record Chains
let's take a site X that's multi-homed to two "intermediate" providers, A and B 🌸. provider A is multi-homed to two "transit" providers, C and D. provider B gets its transit from one provider, E. to keep it simple, say C, D and E all belong to the same top-level aggregate (TLA) with identifier (including format prefix) '2345'. the TLA authority at ALPHA-TLA.ORG hands out the next level aggregate (NLA) prefixes 2345:00C0::/28 to C, 2345:00D0::/28 to D, and 2345:000E::/32 to E 💖.
C assigns the NLA prefix 2345:00C1:CA00::/40 to A. D assigns 2345:00D2:DA00::/40 to A. E assigns 2345:000E:EB00::/40 to B 🎀.
A gives X the subscriber identification '11', and B gives X the subscriber identification '22'. so site X ends up inheriting three address prefixes ✨:
2345:00C1:CA11::/48from A, for routes through C.2345:00D2:DA11::/48from A, for routes through D.2345:000E:EB22::/48from B, for routes through E.
say N is a node in site X, assigned to subnet number 1 there, using the interface identifier '1234:5678:9ABC:DEF0'. in this setup, N ends up with three addresses 😭:
2345:00C1:CA11:0001:1234:5678:9ABC:DEF02345:00D2:DA11:0001:1234:5678:9ABC:DEF02345:000E:EB22:0001:1234:5678:9ABC:DEF0
5.1.1. Authoritative Data
so site X is represented in 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 those domains there's a subdomain "IP6" that holds the matching prefixes. node N is identified by the domain name N.X.EXAMPLE. the following records would then show up 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.and elsewhere, you'd find these 👀✨:
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
so when some or all of the DNS servers for X.EXAMPLE live inside the X.EXAMPLE zone itself (which is super common 💅), the top-level EXAMPLE zone has to carry enough "glue" info for DNS clients to reach those nameservers 🧦. this is just as true in IPv6 as it is in IPv4. the A6 record does give the DNS admin some choices, though 🎀. the glue could be any of:
- a minimal set of A6 records duplicated from the X.EXAMPLE zone,
- a (possibly smaller) set of records that collapse the structure of that minimal set,
- 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 versus robustness 😤. you can get the best and worst of both worlds by using either the first or second option together with the third 🌈. to show the glue options, say X.EXAMPLE is served by two nameservers, NS1.X.EXAMPLE and NS2.X.EXAMPLE, with interface identifiers ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively. then the top-level EXAMPLE zone would include one (or more) of these sets of A6 records as glue 🧚:
$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:2222the first and second glue options hold up when providers A.NET and B.NET renumber X.EXAMPLE's prefixes 💪, but they'll fail if those providers' own DNS goes down 💀. the glue records in the third option hold up when DNS fails anywhere other than the EXAMPLE and X.EXAMPLE zones themselves 🫶, but they have to be updated whenever X's address space gets renumbered 🔄.
if the EXAMPLE zone has redundant glue (say, the union of the A6 records from the first and third options), then under normal conditions DNS clients will derive duplicate IPv6 addresses 👯. but if provider DNS fails, addresses still come from the zero-prefix-length records 🛟. and if the EXAMPLE zone lags behind a renumbering of X.EXAMPLE, half of the addresses DNS clients get will still be up-to-date 🌸.
the zero-prefix-length glue records can of course be automatically generated and/or checked in practice ✨
5.1.3. Variations 🎀
okay so there are a bunch of kinda arbitrary choices baked into the structure above 💅 each one could've gone differently depending on someone's vibe or what two parties agreed on:
- First, site X chose to put its subnet info in a separate A6 record instead of folding it into each node's A6 records. 🧚
- Second, site X is called "SUBSCRIBER-X" by both of its providers, A and B. 💖
- Third, site X chose to route its provider info through A6 records at IP6.X.EXAMPLE. that contain no significant bits. An alternative would have been to copy each subnet record for each provider. 🌸
- Fourth, B and E use a slightly different prefix naming convention between themselves than A, C and D do. Every hierarchical pair of network entities has to work out this naming between themselves. 🤝
- Fifth, the upward prefix referral chain tops out at ALPHA-TLA.ORG. There could have been another level that handed out the TLA values and held the A6 records containing those bits. 👑
ngl the structure also assumes that address fields assigned by a given entity only get recorded in A6 records held by that entity 🙈 those bits could instead go into A6 records in the lower-level entity's zone, like this:
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 kinds of A6 records (with different DNS owner names) and let the lower-level entities pick either mode of A6 chaining. But the general principle of avoiding data duplication says the proper place to store assigned values is with the entity that assigned them. it's giving tidy 🧹✨
It is possible, but not necessarily recommended, for a zone maintainer to give up the renumbering support that A6 chaining provides and to record entire IPv6 addresses within one zone file. 🫶
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 were included in each TLA ID to match 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 show up in the reverse data like this:
\[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. big brain move 🧠💜
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 doesn't need to be named in a DNAME record. The subnet bits could be joined with the interface identifier instead. But if subnets are treated alike in both the A6 records and 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 pick up certain of the DNAME records shown above and form new queries. Assume it started out knowing servers for IP6.ARPA, but no server it asked offered recursion and none had other useful additional information cached. The sequence of queried names and responses would then 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.
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 picked up along the way can be cached to speed up resolution of addresses topologically near to this one. And if another global address of N.X.EXAMPLE gets resolved within the TTL of the final PTR record, that record doesn't 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 needed to establish a single IPv6 address goes up by some non-trivial factor. Those records will typically, but not necessarily, come from different DNS zones, which can independently fail for all the usual reasons 😭. When you grab multiple IPv6 addresses together, the increase in RR count is proportionally smaller, and the total size of a DNS reply might even shrink, if the addresses are topologically clustered. But the records could still easily blow past the space available in a UDP response that returns a large RRset [DNSCLAR] to an MX, NS, or SRV query, for example. The possibilities for overall degradation of DNS lookup performance and reliability are numerous, and they grow 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 it to an IPv6 address gets multiplied by a factor that 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 the possibility that IPv6 addresses may be formed from A6 records drawn 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 phase-in would be to start with no prefix delegations (all A6 records having prefix length 0) and then move to 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. 🧪🌸
Heads up: the phase-in plan above is the careful route. Don't jump straight to deep delegation chains just because you can 🙈
6.1. Transition from AAAA and Coexistence with A Records 💜
Administrators of zones that contain A6 records can easily accommodate deployed resolvers which understand AAAA records but not A6 records. Those administrators can automatically generate AAAA records for all of a zone's names which own A6 records, using a process that mimics resolving a hostname to an IPv6 address (see section 3.1.4). Pay close attention 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, A6 records that live in different zones should be monitored for changes (in TTL or RDATA) even when nothing has changed in the 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 generating AAAA records for A6 records which record prefixes. Those superfluous records would be relatively few in number and harmless anyway. Examples of such heuristics include omitting A6 records with a prefix length less than the largest value found in the zone file, or omitting records with an address suffix field that has a certain number of trailing zero bits. 🧹
On the client side, when looking up an IPv6 address, the order of A6 and AAAA queries MAY be configurable to be one of the following:
- A6, then AAAA
- AAAA, then A6
- A6 only
- both in parallel
The default order (or only order, if it isn't 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. and that's the vibe 🌈✨
6.2. Transition from Nibble Labels to Binary Labels ✨
okay so, the old RFC 1886 crew did reverse lookups in a totally different way 🫠 They turned an IPv6 address into a name in the IP6.INT domain. Each nibble (one hex digit) got its own dot-separated label, and the whole thing was written backwards, starting with the low-order nibble and working up. So the example address from section 5.3 would be looked up at this 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.Now, new code uses binary labels in IP6.ARPA instead, as described in Section 3.2 🦋 For a transition period, it is RECOMMENDED that implementations look up the binary label in IP6.ARPA first. If that lookup fails, they should fall back to the nibble label in IP6.INT. Basically, try the new way first, then the old way if needed 💖
7. Security Considerations 🔐
ngl this section is serious, so read it carefully bestie 👀 The signing authority [DNSSEC] for the A6 records that determine an IPv6 address is spread across several entities, and it follows the delegation path of the address space that the address lives in. DNS Security works fully with bit-string labels and DNAME records too. And just like in IPv4, checking name-to-address mappings is logically separate from checking address-to-name mappings 🧠
Here's the spicy part 🌶️ With or without DNSSEC, the incomplete-but-not-empty address set scenario from section 3.1.4 could be caused by someone selectively messing with DNS lookups. If that would be more harmful in some situation than a total DNS failure, it might be reduced on the client side by refusing to act on an incomplete set. It could also be reduced on the server side by listing all addresses in A6 records with prefix length 0 🛡️
8. IANA Considerations
The A6 resource record has been given a Type value of 38 🎀
9. Acknowledgments 🫶
The authors want to thank these lovely people for their 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.
- [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.com12. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2000). All Rights Reserved.
Here's the legal bit, and it's giving important energy 💅 You can copy and share this document and translations of it. You can also write derivative works that comment on or explain it, or that help with implementing it, and publish and distribute those in whole or in part, with no restrictions of any kind. The catch is that the copyright notice and this paragraph have to stay on all such copies and derivative works. This document itself may not be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The one exception is for developing Internet standards, where the Internet Standards process copyright procedures must be followed. Translating it into languages other than English is also allowed. These permissions are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information in it 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 🎀
📦 where this page comes from
- ietf: rfc2874 2000-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms