RFC 6563

Part 1 of 2 💖

Moving A6 to Historic Status 🎀

okay so this RFC is RFC 6563, titled "Moving A6 to Historic Status" 💅 It's an Informational doc from March 2012, ISSN 2070-1721. The authors are S. Jiang (Huawei Technologies Co., Ltd), D. Conrad (Cloudflare, Inc.), and B. Carpenter (Univ. of Auckland). Its category is Informational. The header doesn't list anything it obsoletes or updates, but it does move RFC 2874 to Historic status, which is the whole point 🫶

Abstract ✨

bestie, here's the TL;DR. This doc sums up the problems with A6 records, talks about where A6 stands right now, and moves RFC 2874 to Historic status so implementers and operators know exactly where they stand 🧚

Status of This Memo 📜

This one is not an Internet Standards Track spec. It's published just for info 🌸

It's a product of the IETF, so it does reflect the consensus of the IETF community. It got public review and was approved for publication by the IESG. Not everything the IESG approves is up for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the details 💅

You can find the current status, errata, and feedback info at http://www.rfc-editor.org/info/rfc6563. ✨

Copyright Notice 🦋

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 🙈 Any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.

Table of Contents 📚

1. Introduction and Background .....................................2
   1.1. Standards Action Taken .....................................3
2. A6 Issues .......................................................3
   2.1. Resolution Latency .........................................3
   2.2. Resolution Failure .........................................3
   2.3. Cross Administrative Domains ...............................4
   2.4. Difficult Maintenance ......................................4
   2.5. Existence of Multiple RR Types for One Purpose is Harmful ..4
   2.6. Higher Security Risks ......................................4
3. Current Usage of A6 .............................................5
   3.1. Reasons for Current A6 Usage ...............................5
4. Moving A6 to Historic Status ....................................6
   4.1. Impact on Current A6 Usage .................................6
   4.2. Transition Phase for Current A6 Usage ......................6
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Acknowledgments .................................................6
8. References ......................................................7
   8.1. Normative References .......................................7
   8.2. Informative References .....................................7

1. Introduction and Background 🌈

okay so the IETF was standardizing two different DNS upgrades for IPv6 addresses at the same time 👑 AAAA got specified in 1995 as a Proposed Standard [RFC1886], then leveled up in 2003 to a Draft Standard [RFC3596]. A6 showed up in 2000 as a Proposed Standard [RFC2874].

Having more than one way to write an IPv6 address in the DNS caused a lot of confusion about which one people should implement and/or deploy 😭 It can be argued that having that choice slowed down IPv6 deployment. In 2002, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)" [RFC3363] moved A6 to Experimental status to try to clear things up. [RFC3363] and [RFC3364] compared AAAA and A6 and dug into a bunch of the issues with the A6 standard, and this doc summarizes those issues ✨

Ten years later, A6 is still Experimental, and that still causes confusion and parallel deployment of both A6 and AAAA. AAAA wins by a huge margin though 💅 In recent IPv6 transition tests and deployments, some providers informally said A6 support could be a future option.

This doc gives a quick summary of the issues with A6 records and looks at how A6 is being used right now. Since A6 has big implications for the DNS architecture and how little it's deployed, this doc moves RFC 2874 [RFC2874] to Historic status. The takeaway is that implementers and operators should represent IPv6 addresses in the DNS using AAAA records only 🫶

1.1. Standards Action Taken 🎬

With this doc, RFC 2874 goes from Experimental to Historic. That's it, that's the tea ☕

2. A6 Issues ⚠️

This section sums up the known problems with A6 resource records (RRs), including the analyses in [RFC3363]. Go read that doc if you want the full picture on A6 issues 🤓

2.1. Resolution Latency ⏳

Resolving an A6 record chain can mean resolving a bunch of subqueries that are probably independent of each other. Each one takes a non-negligible amount of time unless the answer is already sitting in the resolver's cache. In the worst case, an N-link A6 record chain takes the sum of the latency from each of the N resolutions. So long A6 chains would probably make users really frustrated by how long domain names take to resolve 😩

It's also super hard to come up with a reasonable timeout strategy for reassembling all the results from the A6 subqueries. Multiple timeout parameters have been hard to pick, including: (1) the communication timeout for a single A6 fragment, (2) the communication timeout for the IPv6 address itself (the total time needed for reassembly), and (3) the Time to Live (TTL) timeout for A6 fragment records 🌀

2.2. Resolution Failure 💔

The chance of A6 resolution failing while resolving an N-link A6 chain is the sum of the failure probabilities of each subquery. Every query in the chain has a nonzero chance of failing, and an A6 resolution can't finish until every subquery has succeeded 😬

The failure can also happen at any link among 1~N of an N-Link A6 chain. So it could take an indeterminate amount of time to return a failure result 🫠

2.3. Cross Administrative Domains 🏢

One of the main reasons A6 RRs exist is to make renumbering and multihoming easier. In that setup, the prefix name field in an A6 RR points to a target that's not only outside the DNS zone holding the A6 RR, but is run by a totally different organization 👀

Pointers that go out of zone aren't a problem by themselves. But experience with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that pointers to other organizations often don't get maintained properly, maybe because they're harder to automate than pointers inside one organization would be 🤷‍♀️

2.4. Difficult Maintenance 🛠️

In A6, changes to the components of an RR aren't isolated from the composite IPv6 address that uses them. Any change to a non-128-bit component of an A6 RR may change a huge number of IPv6 addresses. That dependency makes maintaining addresses way more complicated and difficult. Without understanding those complicated relationships, any random change to a non-128-bit A6 RR component could have unintended consequences 💀

Multiple related subcomponents of A6 records can also have different TTLs, which can make cache maintenance very complicated 🌪️

2.5. Existence of Multiple RR Types for One Purpose Is Harmful 🙅‍♀️

If AAAA and A6 records were both widely deployed in the global DNS, it would add more query delays for client resolvers. DNS clients don't have enough info to choose between AAAA and A6 queries, so they need local policy to decide which record type to query. If local policy says to send parallel queries for both AAAA and A6 records, and those queries return different results for any reason, clients have no way of knowing which address to pick 😵‍💫

2.6. Higher Security Risks 🚨

The dependency relationships built into A6 chains make security risks worse. An attacker who successfully attacks a single subcomponent of an A6 record could influence lots of query results, possibly every host on a big site 😱 There's also the danger of accidentally or maliciously creating a resolution loop. An A6 chain can turn into an infinite loop if an out-of-zone pointer points back to another component further down the chain 🔁

3. Current Usage of A6 📊

Full support for IPv6 in the global DNS can be argued to have started when the first IPv6 records were associated with root servers in early 2008 🎉

One of the major DNS server software packages, BIND9 [BIND], supports both A6 and AAAA. It's unique among the major DNS resolvers because certain versions of the BIND9 resolver will try to query for A6 records and follow A6 chains 🧐

According to published stats for two root DNS servers (the "K" root server [KROOT] and the "L" root server [LROOT]), there are between 9,000 and 14,000 DNS queries per second on the "K" root server, and between 13,000 to 19,000 queries per second on the "L" root server. The breakdown by RR type is pretty similar: roughly 60% A queries, 20~25% AAAA queries, and less than 1% A6 queries 📈

3.1. Reasons for Current A6 Usage 🕵️‍♀️

Just because there's A6 query traffic doesn't mean A6 is actually in use. It's probably from recursive servers that send internally generated A6 queries when they look up missing name server addresses, on top of their A and AAAA queries 🤔

BIND versions 9.0 through 9.2 could be configured to make A6 queries, and some active name servers running those versions might not have been upgraded yet 🕰️

In the late 1990s, A6 was considered the future over AAAA [RFC2874]. So A6 queries were tried by default in BINDv9 versions. Then people pointed out that A6 had some fundamental issues (discussed in [A6DISC], with the deprecation codified in RFC 3363). A6 got abandoned in favor of AAAA, and BINDv9 stopped trying A6 records by default. A6 was removed from the query order in the BIND distribution in 2004 or 2005 🪦

Some Linux/glibc versions may have had A6 query implementations in gethostbyname() 8-10 years ago. Those operating systems and libraries might not have been replaced or upgraded everywhere yet 🐧

4.1. Impact on Current A6 Usage ✨

okay so if A6 were actually in use and got treated as an 'unknown record' (RFC3597) like we talked about, it could cause some interoperability issues 😬 because resolvers that support A6 are required to do additional section processing for these records on the wire. BUT, and this is the tea 🍵, there are no known production uses of A6, so the impact is considered negligible 💅

4.2. Transition Phase for Current A6 Usage 🦋

since there's no known A6-only client in production use, the transition phase may not be strictly necessary 🤷‍♀️ however, clients that try to resolve A6 before AAAA will take a performance hit 💀 so we recommend that:

• A6 handling from all new or updated host stacks be removed;
• All existing A6 records be removed; and,
• All resolver and server implementations return the same response as for any unknown or deprecated RR type for all A6 queries. If a AAAA record exists for the name being resolved, a suitable response would be 'no answers/no error', i.e., the response packet has an answer count of 0 but no error is indicated.

5. Security Considerations 🔐

removing A6 records will eliminate any security exposure related to that RR type, and should introduce no new vulnerabilities 🛡️✨ bestie, that's the kind of cleanup that's giving main character energy 👑

6. IANA Considerations 🌸

IANA has updated the annotation of the A6 RR type (code 38) from "Experimental" to "Obsolete" in the DNS Parameters registry 🎀 A6 is officially retired, periodt 💅

7. Acknowledgments 🫶

the authors would like to thank Ralph Droms, Roy Arends, Edward Lewis, Andreas Gustafsson, Mark Andrews, Jun-ichiro "itojun" Hagino, and other members of DNS WGs for valuable contributions 💖 the real MVPs 👑

8. References 📚

8.1. Normative References

• [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
• [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.

8.2. Informative References 🧚

• [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.
• [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, August 2002.
• [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002.
• [A6DISC] Hagino, J., "Comparison of AAAA and A6 (do we really need A6?)", (Work In Progress), July 2001.
• [BIND] "Internet Systems Consortium", http://www.isc.org/software/bind.
• [KROOT] "RIPE Network Coordination Centre", http://k.root-servers.org/.
• [LROOT] "ICANN DNS Operations", http://dns.icann.org/lroot/

Author's Addresses 🎀

Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing 100095
P.R. China
EMail: jiangsheng@huawei.com

David Conrad
Cloudflare, Inc.
665 3rd Street, Suite 207
San Francisco CA 94107
USA
EMail: drc@cloudflare.com

Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
EMail: brian.e.carpenter@gmail.com

---

that's the whole RFC, bestie 🌈💜 A6 is retired and everyone's AAAA era is thriving 🧚✨