RFC 3363

Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)

📅 published August 2002, from ietf

RFC 3363: Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) 💖

Okay bestie, here's the tea 🫶 This one comes from the Network Working Group and is dated August 2002. It's Informational 🙈, which means it's giving info, not an official standard. The editors are Randy Bush, Alain Durand, Bob Fink, Olafur Gudmundsson, and Tony Hain 👑. It updates RFC 2673 and RFC 2874 🦋. The header doesn't list anything it obsoletes, so nothing is getting replaced here.

Status of this Memo ✨

This memo gives info to the Internet community. It doesn't specify an Internet standard of any kind, and it can be distributed freely, with no limits 💅.

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

Abstract 🌸

Okay so this doc cleans up the standards status of the RFCs that define the direct and reverse mapping of IPv6 addresses in DNS 🧚. It also moves the A6 and Bit label specs over to experimental status, which is a big deal ngl 💀.

1. Introduction ✨

So the IETF had started standardizing two different address formats for IPv6, AAAA [RFC1886] and A6 [RFC2874], and both were sitting at proposed standard 😭. Obviously this made everyone confused about which one to actually deploy, and that confusion is not it 🙈. People in the community were worried that having more than one choice would slow down IPv6 deployment, so clearing this up matters a lot 🔥. The goal of this document is to get everyone on the same page.

This doc also talks about Binary Labels [RFC 2673] and how they can be used for reverse mapping of IPv6 addresses 🦋.

This document came out of a ton of technical discussion on various relevant working group mailing lists, plus a joint DNSEXT and NGTRANS meeting at the 51st IETF in August 2001 💜. It tries to capture the vibe of those discussions and show what the community agreed on 🫶.

The main arguments and issues are covered in a separate document [RFC3364], which reflects the current understanding of the issues. This doc just summarizes what came out of those discussions ✨.

The question of the root of the reverse IPv6 address map is out of scope here. It's handled in a different document [RFC3152] 💅.

1.1 Standards Action Taken

This document changes the status of RFCs 2673 and 2874 from Proposed Standard to Experimental 🌈.

2. IPv6 Addresses: AAAA RR vs A6 RR 💖

The working group consensus, as the chairs of the DNSEXT and NGTRANS working groups saw it, goes like this:

  • a) AAAA records are preferable right now for production deployment of IPv6, and
  • b) A6 records have interesting properties that need to be better understood before deployment.
  • c) It isn't known whether the benefits of A6 outweigh the costs and risks.

2.1 Rationale 🧠

There are a few potential issues with A6 RRs, and they all come from the thing that makes them different from AAAA RRs: the ability to build up addresses through chaining 🔗.

Resolving a chain of A6 RRs means resolving a series of queries that are nearly independent 😩. Each sub-query takes some non-zero amount of time, unless the answer is already in the resolver's local cache 🕰️. All else being equal, we expect the time to resolve an N-link chain of A6 RRs to be roughly proportional to N. The data we have shows that users are already impatient with how long it takes to resolve A RRs in the IPv4 Internet, so they probably won't be patient with much longer delays on the IPv6 Internet 😤. Cutting queries off early wastes resources and causes its own frustration, so we're basically forced to conclude that using long A6 chains without limits will likely lead to more user frustration 💀.

The probability of failure while resolving an N-link A6 chain also seems to be roughly proportional to N, since each query in an A6 chain has about the same failure probability as a single AAAA query 📉.

Last but not least, a lot of the most exciting potential uses of A6 RRs involve a prefix name field that points to a target which is not only outside the DNS zone containing the A6 RR, but is run by a completely different organization 🏢. Pointers 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 🙈. That might be because they're less likely to be automated than pointers inside a single organization would be 🤖.

Based on the perceived consensus, this document recommends that RFC 1886 stay on the standards track and be advanced, while RFC 2874 moves to Experimental status 👑.

3. Bitlabels in the Reverse DNS Tree 🌸

RFC 2673 defines a new DNS label type. It was the first new type defined since RFC 1035 [RFC1035] 🎀. Since 2673 was developed, people have learned that deploying a new type is hard, because DNS servers that don't support bitlabels reject queries containing bit labels as malformed 😱. The community has also said that this new label type isn't actually needed for mapping reverse addresses 🙅.

3.1 Rationale 🧠

The hexadecimal text representation of IPv6 addresses seems to be able to express all of the delegation schemes we expect to use in the DNS reverse tree 🧚.

RFC 2673's standard status is changing from Proposed to Experimental. Future standardization of these documents will be handled by the DNSEXT working group or its successor 💅.

4. DNAME in IPv6 Reverse Tree 🌈

The issues with DNAME in the reverse mapping tree seem to be closely 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 🔗. So when RFC 2874 moves to experimental, the intent of this document is for the use of DNAME RRs in the reverse tree to be deprecated 🚫.

5. Acknowledgments 💜

This document is based on input from lots of members of the various IETF working groups involved with this issue 🫶. Special thanks go to the people who prepared reading material for the joint DNSEXT and NGTRANS working group meeting at the 51st IETF in London: Rob Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino, and Christian Huitema 👑. A bunch of other people also left comments on mailing lists about this issue, including Andrew W. Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka Savola, and Paul Vixie 🥰.

6. Security Considerations 💀

Because this document specifies a course of action, there are no direct security considerations. There is an indirect security impact from the choice, though 😬. The relationship between A6 and DNSSEC isn't well understood across the community, while choosing AAAA leads to a model for using DNSSEC in IPv6 networks that parallels current IPv4 practice 🔐.

7. IANA Considerations 🌸

None.

Normative References 📚

[RFC1035]  Mockapetris, P., "Domain Names - Implementation and
              Specification", STD 13, RFC 1035, November 1987.

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

[RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
              RFC 2673, August 1999.

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

[RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
              August 2001.

Informative References 📖

[RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
              August 2002.

Editors' Addresses 💌

Randy Bush
EMail: randy@psg.com

Alain Durand
EMail: alain.durand@sun.com

Bob Fink
EMail: fink@es.net

Olafur Gudmundsson
EMail: ogud@ogud.com

Tony Hain
EMail: hain@tndh.net

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

This document and translations of it may be copied and given to others. Derivative works that comment on or explain it, or help implement it, may be written, copied, published, and distributed, in whole or in part, with no restrictions at all. The copyright notice and this paragraph have to stay on all of those copies and derivative works 💖. But the document itself can't be changed in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need it to develop Internet standards, in which case the copyright procedures in the Internet Standards process have to be followed, or when you're translating it into a language other than English 🌍.

The permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns ♾️.

This document and the information in it are 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