Network Working Group R. Austein Request for Comments: 3364 Bourgeois Dilettant Updates: 2673, 2874 August 2002 Category: Informational Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) Status of this Memo This memo provides information for 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.
AbstractThe IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on. RFC1886] specified straightforward mechanisms to support IPv6 addresses in the DNS. These mechanisms closely resemble the mechanisms used to support IPv4, with a minor improvement to the reverse mapping mechanism based on experience with CIDR. RFC 1886 is currently listed as a Proposed Standard. RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6 addresses in the DNS. These mechanisms provide new features that make it possible for an IPv6 address stored in the DNS to be broken up into multiple DNS resource records in ways that can reflect the network topology underlying the address, thus making it possible for the data stored in the DNS to reflect certain kinds of network topology changes or routing architectures that are either impossible or more difficult to represent without these mechanisms. RFC 2874 is also currently listed as a Proposed Standard.
Both of these Proposed Standards were the output of the IPNG Working Group. Both have been implemented, although implementation of [RFC1886] is more widespread, both because it was specified earlier and because it's simpler to implement. There's little question that the mechanisms proposed in [RFC2874] are more general than the mechanisms proposed in [RFC1886], and that these enhanced mechanisms might be valuable if IPv6's evolution goes in certain directions. The questions are whether we really need the more general mechanism, what new usage problems might come along with the enhanced mechanisms, and what effect all this will have on IPv6 deployment. The one thing on which there does seem to be widespread agreement is that we should make up our minds about all this Real Soon Now. RFC2874] is very general and provides a superset of the functionality provided by the AAAA RR in [RFC1886], many of the features of A6 can also be implemented with AAAA RRs via preprocessing during zone file generation. There is one specific area where A6 RRs provide something that cannot be provided using AAAA RRs: A6 RRs can represent addresses in which a prefix portion of the address can change without any action (or perhaps even knowledge) by the parties controlling the DNS zone containing the terminal portion (least significant bits) of the address. This includes both so-called "rapid renumbering" scenarios (where an entire network's prefix may change very quickly) and routing architectures such as the former "GSE" proposal [GSE] (where the "routing goop" portion of an address may be subject to change without warning). A6 RRs do not completely remove the need to update leaf zones during all renumbering events (for example, changing ISPs would usually 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. Note that constructing AAAA RRs via preprocessing during zone file generation requires exactly the sort of information that A6 RRs store in the DNS. This begs the question of where the hypothetical preprocessor obtains that information if it's not getting it from the DNS. Note also that the A6 RR, when restricted to its zero-length-prefix form ("A6 0"), is semantically equivalent to an AAAA RR (with one "wasted" octet in the wire representation), so anything that can be done with an AAAA RR can also be done with an A6 RR.
RFC1886], while providing only a subset of the functionality provided by the A6 RR proposed in [RFC2874], has two main points to recommend it: - AAAA RRs are essentially identical (other than their length) to IPv4's A RRs, so 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", in the sense that, by storing a complete address rather than making the resolver fetch the address in pieces, it minimizes the effort involved in fetching addresses from the DNS (at the expense of increasing the effort involved in injecting new data into the DNS).
susceptible to automation than pointers within a single organization would be. Experience both with glue RRs and with PTR RRs in the IN- ADDR.ARPA tree suggests that many zone administrators do not really understand how to set up and maintain these pointers properly, and we have no particular reason to believe that these zone administrators will do a better job with A6 chains than they do today. To be fair, however, the alternative case of building AAAA RRs via preprocessing before loading zones has many of the same problems; at best, one can claim that using AAAA RRs for this purpose would allow DNS clients to get the wrong answer somewhat more efficiently than with A6 RRs. Finally, assuming near total ignorance of how likely a query is to fail, the probability of failure with an N-link A6 chain would appear to be roughly proportional to N, since each of the queries involved in resolving an A6 chain would have the same probability of failure as a single AAAA query. Note again that this comment applies to failures in the the process of resolving a query, not to the data obtained via that process. Arguably, in an ideal world, A6 RRs would increase the probability of the answer a client (finally) gets being right, assuming that nothing goes wrong in the query process, but we have no real idea how to quantify that assumption at this point even to the hand-wavey extent used elsewhere in this note. One potential problem that has been raised in the past regarding A6 RRs turns out not to be a serious issue. The A6 design includes the possibility of there being more than one A6 RR matching the prefix name portion of a leaf A6 RR. That is, an A6 chain may not be a simple linked list, it may in fact be a tree, where each branch represents a possible prefix. Some critics of A6 have been concerned that this will lead to a wild expansion of queries, but this turns out not to be a problem if a resolver simply follows the "bounded work per query" rule described in RFC 1034 (page 35). That rule applies to all work resulting from attempts to process a query, regardless of whether it's a simple query, a CNAME chain, an A6 tree, or an infinite loop. The client may not get back a useful answer in cases where the zone has been configured badly, but a proper implementation should not produce a query explosion as a result of processing even the most perverse A6 tree, chain, or loop.
Other things being equal, the time it takes to re-sign all of the addresses in a zone after a renumbering event is longer with AAAA RRs than with A6 RRs (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). Note, however, that in general this does not present a serious scaling problem, because the re-signing is performed in the leaf zones. Other things being equal, there's more work involved in verifying the signatures received back for A6 RRs, because each address fragment has a separate associated signature. Similarly, a DNS message containing a set of A6 address fragments and their associated signatures will be larger than the equivalent packet with a single AAAA (or A6 0) and a single associated signature. Since AAAA RRs cannot really represent rapid renumbering or GSE-style routing scenarios very well, it should not be surprising that DNSSEC signatures of AAAA RRs are also somewhat problematic. In cases where the AAAA RRs would have to be changing very quickly to keep up with prefix changes, the time required to re-sign the AAAA RRs may be prohibitive. Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that 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 this, assuming one A RR, one AAAA RR, and one NXT RR per host, this suggests that it would take this laptop a few hours to sign a zone listing 10**5 hosts, or about a day to sign a zone listing 10**6 hosts using AAAA RRs. This suggests that the additional effort of re-signing a large zone full of AAAA RRs during a re-numbering event, while noticeable, is only likely to be prohibitive in the rapid renumbering case where AAAA RRs don't work well anyway.
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, broken up with a dot between each hexadecimal digit. The resulting DNS names are somewhat tedious for humans to type, but are very easy for programs to generate. Making each hexadecimal digit a separate label means that delegation on arbitrary bit boundaries will result in a maximum of 16 NS RRsets per label level; again, the mechanism is somewhat tedious for humans, but is very easy to program. As with IPv4's IN-ADDR.ARPA tree, the one place where this scheme is weak is in handling delegations in the least significant label; however, since there appears to be no real need to delegate the least significant four bits of an IPv6 address, this does not appear to be a serious restriction. [RFC2874] proposed a radically different way of naming entries in the reverse mapping tree: rather than using textual representations of addresses, it proposes to use a new kind of DNS label (a "bit label") to represent binary addresses directly in the DNS. This has the advantage of being significantly more compact than the textual representation, and arguably might have been a better solution for DNS to use for this purpose 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 that are authoritative for any portion of the name in question must be upgraded before the new label type can be used, as must any resolvers involved in the resolution process. Any name server that has not been upgraded to understand the new label type will reject the query as being malformed. Since the main benefit of the bit label approach appears to be an ability that we don't really need (delegation in the least significant four bits of an IPv6 address), and since the upgrade problem is likely to render bit labels unusable until a significant portion of the DNS code base has been upgraded, it is difficult to escape the conclusion that the textual solution is good enough. RFC2874] also proposes using DNAME RRs as a way of providing the equivalent of A6's fragmented addresses in the reverse mapping tree. That is, by using DNAME RRs, one can write zone files for the reverse mapping tree that have the same ability to cope with rapid renumbering or GSE-style routing that the A6 RR offers in the main portion of the DNS tree. Consequently, the need to use DNAME in the reverse mapping tree appears 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. Other uses have also been proposed for the DNAME RR, but since they are outside the scope of the IPv6 address discussion, they will not be addressed here.
Recommendations based on these 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; in general, any network that can be described adequately using A6 0 RRs and without using DNAME RRs should be described that way, and the enhanced features should be used only when absolutely necessary, at least until we have much more experience with them and have a better understanding of their failure modes. 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.
[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.
Full Copyright Statement 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.