RFC 3364

🎀 RFC 3364: Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) ✨

Okay bestie, let's start with the basics 🦋. This one is from the Network Working Group, written by R. Austein and Bourgeois Dilettant in August 2002. It's labelled Category: Informational, so it's sharing info and isn't setting any official standard 💅. It updates RFC 2673 and RFC 2874, and its header doesn't list anything it obsoletes 🌸.

---

Status of this Memo 📋

This memo gives info to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 💜.

Copyright Notice ©️

Copyright (C) The Internet Society (2002). All Rights Reserved 🫶.

Abstract ✨

So the IETF has two different proposals on the table for how DNS should support IPv6, and honestly they still haven't agreed on which one is better 😭. This note looks at the pros and cons of each approach, so the debate gets clearer and we can finally reach closure and move on 🔥.

Introduction 🧚

Okay so RFC 1886 [RFC1886] specified the straightforward mechanisms for supporting IPv6 addresses in the DNS 🍓. They look a lot like the ones used for IPv4, with one small upgrade to the reverse mapping, which was based on experience with CIDR. RFC 1886 is currently listed as a Proposed Standard ✨.

Then there's RFC 2874 [RFC2874], which specified enhanced mechanisms for IPv6 addresses in the DNS 👑. These bring new features that let an IPv6 address stored in the DNS get split into multiple DNS resource records, and those pieces can reflect the network topology underneath the address. That makes it possible to show certain kinds of topology changes or routing architectures that are either impossible or much harder to represent without these mechanisms 🦋. RFC 2874 is also currently listed as a Proposed Standard 💖.

Both of these Proposed Standards came out of the IPNG Working Group 🎀. Both have been implemented, but implementation of [RFC1886] is way more widespread. That's because it came out earlier, and it's simpler to implement 💅.

It's pretty clear that the mechanisms in [RFC2874] are more general than the ones in [RFC1886], and these enhanced mechanisms might be super valuable if IPv6 evolves in certain directions 🌈. The real questions are: do we actually need the more general mechanism, what new usage problems could come along with the enhanced mechanisms, and what effect will all of this have on IPv6 deployment? 🤔

The one thing everyone seems to agree on is that we should make up our minds about all this Real Soon Now 😭🫶.

Main Advantages of Going with A6 👑

Here's the tea 🍵. The A6 RR proposed in [RFC2874] is very general and provides a superset of the functionality of the AAAA RR in [RFC1886]. But lots of A6 features can also be done with AAAA RRs, using preprocessing during zone file generation ✨.

There is one specific area where A6 RRs do something AAAA RRs just can't 😳. A6 RRs can represent addresses where the prefix part of the address can change without any action (or maybe even knowledge) from the people who control the DNS zone that holds the terminal portion (the least significant bits) of the address. This covers so-called "rapid renumbering" scenarios, where an entire network's prefix might change really quickly 🌪️. It also covers routing architectures like the former "GSE" proposal [GSE], where the "routing goop" portion of an address may change without warning 💀. A6 RRs don't completely get rid of the need to update leaf zones during every renumbering event. For example, changing ISPs would usually still require a change to the upward delegation pointer. But careful use of A6 RRs could keep the number of RRs that need to change during such an event to a minimum 🧚.

Also, constructing AAAA RRs through preprocessing during zone file generation requires exactly the kind of information that A6 RRs store in the DNS. So that raises the question: if the hypothetical preprocessor isn't getting that info from the DNS, where is it getting it from? 🙈

And here's another fun one: when the A6 RR is restricted to its zero-length-prefix form ("A6 0"), it's semantically equivalent to an AAAA RR (with one "wasted" octet in the wire representation). So anything you can do with an AAAA RR, you can also do with an A6 RR 🎀.

Main Advantages of Going with AAAA 💜

The AAAA RR proposed in [RFC1886] only provides a subset of the functionality of the A6 RR proposed in [RFC2874]. But it has two main points going for it 💅:

• AAAA RRs are basically identical (other than their length) to IPv4's A RRs. That means we have more than 15 years of experience to help us predict the usage patterns, failure scenarios and so forth associated with AAAA RRs 📚.
• The AAAA RR is "optimized for read". By storing a complete address instead of making the resolver fetch the address in pieces, it minimizes the effort involved in fetching addresses from the DNS. The tradeoff is that it increases the effort involved in injecting new data into the DNS 🔥.

Less Compelling Arguments in Favor of A6 🦋

Since the A6 RR lets a zone administrator write zone files whose description of addresses maps to the underlying network topology, A6 RRs can be argued to be a "better" way of representing addresses than AAAA 🌸. That might be a genuinely useful capability. But in and of itself, it's more of an argument for better tools that zone administrators use when constructing zone files, rather than a reason to change the resolution protocol used on the wire 🛠️.

Less Compelling Arguments in Favor of AAAA 🌈

Some of the pressure to go with AAAA instead of A6 seems to come from how widely AAAA is deployed. But since it's possible to build transition tools (see the discussion of AAAA synthesis later in this note), that doesn't seem like a compelling argument if A6 provides features we really need 💖.

Another argument for AAAA RRs over A6 RRs seems to be that A6's advanced capabilities increase the number of ways a zone administrator could build a non-working configuration 🙃. Operational issues are definitely important. But this is more of an argument that we need better tools for zone administrators than a justification for turning away from A6, if A6 provides features we really need ✨.

Potential Problems with A6 ✨

Okay bestie, the fancy new powers of the A6 RR are super interesting 🤩, but they are NOT a reason to pick A6 if we don't actually need them 🙅‍♀️. The A6 RR is "optimized for write," which means that by letting you store fragmented IPv6 addresses in the DNS, it makes it way easier to inject new data 💉. The catch is that fetching data gets harder 😬. That might be worth it if maintaining AAAA-style DNS entries would be totally impossible, but in general DNS data gets read way more often than it gets written 📖, so we need to think about this tradeoff super carefully 🧐.

There are also some issues with A6 RRs that come straight from the thing that makes them different from AAAA RRs 🔗: the ability to build up an address via chaining.

Resolving a chain of A6 RRs means resolving a bunch of queries that are almost independent, but not quite 🧩. Each sub-query takes some non-zero amount of time, unless the answer is already sitting in the resolver's local cache 💾. If resolving an AAAA RR takes time T as a baseline, then we can guess that, on average, an N-link chain of A6 RRs will take something approaching time N*T 🐢. We'd expect a pretty good caching factor for the A6 fragments holding the more significant bits of an address, though ✨. That leaves us with two choices, and neither is very cute 😭: we can shrink how long the resolver is willing to wait for each fragment, or we can grow how long a resolver will wait before returning failure to a client. What little data we have suggests users are already impatient with how long it takes to resolve A RRs on the IPv4 Internet 😤, so they're not likely to be patient with even longer delays on the IPv6 Internet. Also, cutting queries off early wastes resources and frustrates users even more 💀. So we are forced to conclude that using long A6 chains without thinking is likely to cause problems 🚩.

And it gets worse 🙈. The places where A6 RRs would be most critical for rapid renumbering or GSE-like routing are exactly the situations where the prefix name field in the A6 RR points to a target that is not only outside the DNS zone containing the A6 RR, but is also administered by a different organization 🏢. For example, with an end user's site, the prefix name will most likely point to a name belonging to the ISP providing connectivity for that site. Pointers that leave the zone are not a problem on their own 👍, but pointers to other organizations are harder to maintain and much less automation-friendly than pointers inside a single organization 🤖. Experience with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that plenty of zone administrators don't really understand how to set up and maintain these pointers properly 😩. We have no particular reason to think they'll do a better job with A6 chains than they do today. To be fair, though, building AAAA RRs through preprocessing before loading zones has many of the same problems 🫠. At best, you could say that using AAAA RRs this way would let DNS clients get the wrong answer a bit more efficiently than A6 RRs would 🤷‍♀️.

Finally, if we assume near total ignorance of how likely a query is to fail 🎲, the probability of failure with an N-link A6 chain would seem to be roughly proportional to N, since each query involved in resolving the chain has the same chance of failing as a single AAAA query 📉. Again, this is about failures in the process of resolving a query, NOT about the data you get back from that process 📦. Arguably, in an ideal world, A6 RRs would make it more likely that the answer a client finally gets is right 🎯, as long as nothing goes wrong in the query process. But we have no real idea how to quantify that, even to the hand-wavey extent used elsewhere in this note 🙃.

One potential problem that people raised in the past about A6 RRs turns out NOT to be a serious issue 🙌. The A6 design allows more than one A6 RR to match the prefix name portion of a leaf A6 RR. So an A6 chain might not be a simple linked list at all 🌳. It could actually be a tree, where each branch represents a possible prefix. Some critics were worried this would lead to a wild explosion of queries 💥, but that won't happen if a resolver simply follows the "bounded work per query" rule described in RFC 1034 (page 35) 📜. That rule covers ALL work that comes from trying to process a query, whether it's a simple query, a CNAME chain, an A6 tree, or an infinite loop 🔁. The client might not get a useful answer if the zone has been configured badly 😢, but a proper implementation should not cause a query explosion while processing even the most perverse A6 tree, chain, or loop 💪.

---

Interactions with DNSSEC 🔐

AAAA and A6 RRs differ in the precise details of how they interact with DNSSEC 👀. The comments below apply ONLY to non-zero-prefix A6 RRs. (A6 0 RRs, once again, are semantically equivalent to AAAA RRs 💁‍♀️.)

Other things being equal, re-signing all of the addresses in a zone after a renumbering event takes longer with AAAA RRs than with A6 RRs ⏳. That's because each address record has to be re-signed, rather than just signing a common prefix A6 RR and a few A6 0 RRs associated with the zone's name servers 🧾. Still, this isn't generally a serious scaling problem 📈, because the re-signing happens in the leaf zones 🍃.

Other things being equal, verifying the signatures you get back for A6 RRs is more work 🧮, because each address fragment has its own separate signature ✍️. Similarly, a DNS message containing a set of A6 address fragments and their associated signatures will be bigger than the equivalent packet with a single AAAA (or A6 0) and a single associated signature 📦.

AAAA RRs can't really represent rapid renumbering or GSE-style routing scenarios very well 🙁, so it's no surprise that DNSSEC signatures of AAAA RRs are also kind of problematic 😬. If AAAA RRs would have to change very quickly to keep up with prefix changes, the time needed to re-sign them may be totally prohibitive 🛑.

Bill Sommerfeld [Sommerfeld] ran some empirical testing 🧪 and found that a 333MHz Celeron laptop with 128KB L2 cache and 64MB RAM, running the BIND-9 dnssec-signzone program under NetBSD, can generate roughly 40 1024-bit RSA signatures per second 💻. Extrapolating from that, and assuming one A RR, one AAAA RR, and one NXT RR per host, it would take this laptop a few hours to sign a zone listing 10**5 hosts ⏰. Signing a zone listing 10**6 hosts using AAAA RRs would take about a day 📅.

So the extra effort of re-signing a big zone full of AAAA RRs during a renumbering event is noticeable 👀, but it's only likely to be prohibitive in the rapid renumbering case, where AAAA RRs don't work well anyway 🤷‍♀️. Not a surprise, honestly 💅.

---

Interactions with Dynamic Update 🔄

DNS dynamic update seems to work equally well for AAAA or A6 RRs 👍, with one minor exception 🤏: with A6 RRs, the dynamic update client needs to know the prefix length and prefix name 📝. Right now there's no mechanism to tell a dynamic update client these values 😶, but presumably one could be provided via an extension to DHCP, or some other equivalent could be devised 🛠️.

---

Transition from AAAA to A6 Via AAAA Synthesis 🦋

AAAA is more widely deployed than A6 right now 📊, but it IS possible to transition from AAAA-aware DNS software to A6-aware DNS software 🙌. A rough plan for this was presented at IETF-50 in Minneapolis 🌆 and has been discussed on the ipng mailing list 💬. So if the IETF concludes that A6's enhanced capabilities are necessary, it should be possible to transition from AAAA to A6 🚀.

The details of this transition have been left to a separate document 📄, but the general idea is that the resolver doing iterative resolution on behalf of a DNS client program could synthesize AAAA RRs representing the result of performing the equivalent A6 queries 🪄. Note that in this case it is NOT possible to generate an equivalent DNSSEC signature for the AAAA RR 🚫. So clients that care about performing DNSSEC validation for themselves would have to issue A6 queries directly, rather than relying on AAAA synthesis 🔍.

---

Bitlabels 🏷️

The AAAA vs. A6 differences have generated most of the discussion so far 🗣️, but there are also two proposed mechanisms for building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-ADDR.ARPA tree) 🔙.

[RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA mechanism used for IPv4 addresses 👯. The RR name is the hexadecimal representation of the IPv6 address, reversed and concatenated with a well-known suffix, and broken up with a dot between each hexadecimal digit 🔢. The resulting DNS names are somewhat tedious for humans to type 😵‍💫, but they're very easy for programs to generate 🤖. Making each hexadecimal digit its own label means delegation on arbitrary bit boundaries results in a maximum of 16 NS RRsets per label level 📚. Again, it's a bit tedious for humans, but super easy to program 💖. Like IPv4's IN-ADDR.ARPA tree, the one place this scheme is weak is in handling delegations in the least significant label 🙃. Still, since there appears to be no real need to delegate the least significant four bits of an IPv6 address, this doesn't look like a serious restriction 👌.

[RFC2874] proposed a radically different way of naming entries in the reverse mapping tree 🌟. Instead of textual representations of addresses, it proposes a new kind of DNS label (a "bit label") to represent binary addresses directly in the DNS 🧠. This is significantly more compact than the textual representation ✂️, and arguably it might have been a better choice for DNS if it had been designed into the protocol from the outset 🏗️. Unfortunately, experience to date suggests that deploying a new DNS label type is very hard 😭. ALL of the DNS name servers authoritative for any portion of the name in question must be upgraded before the new label type can be used 🔧, and so must any resolvers involved in the resolution process 🔧. Any name server that hasn't been upgraded to understand the new label type will reject the query as malformed 🙅‍♀️.

Since the main benefit of bit labels appears to be an ability we don't really need (delegation in the least significant four bits of an IPv6 address) 🫤, and since the upgrade problem is likely to make bit labels unusable until a significant portion of the DNS code base has been upgraded 🐌, it's hard to escape the conclusion that the textual solution is good enough 💯✨.

DNAME RRs

okay so [RFC2874] also proposes using DNAME RRs to get the equivalent of A6's fragmented addresses in the reverse mapping tree 🔄✨ With DNAME RRs, you can write reverse-tree zone files that handle rapid renumbering or GSE-style routing just as well as the A6 RR does in the main part of the DNS tree 💅 So the need to use DNAME in the reverse tree is tied to the need to use fragmented A6 in the main tree. If one is necessary, so is the other, and if one isn't necessary, the other isn't either 🎀

There are other uses people have proposed for DNAME RRs too 🦋 But those are outside the IPv6 address discussion, so we're not covering them here 🙈

Recommendation

okay so distilling all those feature comparisons down to the important bits, the questions that matter are 🧚

(a) Is IPv6 going to do rapid renumbering or GSE-like routing?

(b) Is the reverse mapping tree for IPv6 going to require delegation in the least significant four bits of the address?

Question (a) is literally the key to the whole debate 🔥 And it's really a decision for the IPv6 community to make, not the DNS community 💜 Question (b) is also for the IPv6 community, but it's fairly obvious that the answer is "no" 💀

Here are the recommendations based on those questions:

1. If the IPv6 working groups seriously intend to specify and deploy rapid renumbering or GSE-like routing, we should transition to using the A6 RR in the main tree and to using DNAME RRs as necessary in the reverse tree. 👑
2. Otherwise, we should keep the simpler AAAA solution in the main tree and should not use DNAME RRs in the reverse tree. 🌸
3. In either case, the reverse tree should use the textual representation described in [RFC1886] rather than the bit label representation described in [RFC2874]. 🍓
4. If we do go to using A6 RRs in the main tree and to using DNAME RRs in the reverse tree, we should write applicability statements and implementation guidelines designed to discourage excessively complex uses of these features. The vibe is: in general, any network that can be described adequately using A6 0 RRs and without using DNAME RRs should be described that way ✨ The enhanced features should be used only when absolutely necessary, at least until we have much more experience with them and a better understanding of their failure modes 🫶

Security Considerations

🚨 Serious security corner, bestie. This note compares two mechanisms with similar security characteristics, but the choice between them still has a few security implications.

1. The two mechanisms have similar but not identical interactions with DNSSEC. Please see the section entitled "Interactions with DNSSEC" (above) for a discussion of these issues. 🔐
2. To the extent that operational complexity is the enemy of security, the tradeoffs in operational complexity discussed throughout this note have an impact on security. 🧠
3. To the extent that protocol complexity is the enemy of security, the additional protocol complexity of [RFC2874] as compared to [RFC1886] has some impact on security. 🛡️

IANA Considerations

None, since all of these RR types have already been allocated. 🎀

Acknowledgments

This note is based on a number of discussions, both public and private, over a period of (at least) eight years 🌈 Huge thanks to Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush, and Sue Thomson 🫶 None of them are responsible for what the author did with their ideas, so no blame, only love 💖

References

[RFC1886]    Thomson, S. and C. Huitema, "DNS Extensions to support
             IP version 6", RFC 1886, December 1995.

[RFC2874]    Crawford, M. and C. Huitema, "DNS Extensions to Support
             IPv6 Address Aggregation and Renumbering", RFC 2874,
             July 2000.

[Sommerfeld] Private message to the author from Bill Sommerfeld dated
             21 March 2001, summarizing the result of experiments he
             performed on a copy of the MIT.EDU zone.

[GSE]        "GSE" was an evolution of the so-called "8+8" proposal
             discussed by the IPng working group in 1996 and 1997.
             The GSE proposal itself was written up as an Internet-
             Draft, which has long since expired.  Readers interested
             in the details and history of GSE should review the IPng
             working group's mailing list archives and minutes from
             that period.

Author's Address

Rob Austein 🦋

EMail: sra@hactrn.net

Full Copyright Statement

This is the legal bit, so it stays word for word 📜

   Copyright (C) The Internet Society (2002).  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. 💜🎀