diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc3364.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc3364.txt | 619 |
1 files changed, 0 insertions, 619 deletions
diff --git a/contrib/bind9/doc/rfc/rfc3364.txt b/contrib/bind9/doc/rfc/rfc3364.txt deleted file mode 100644 index 189c0d2..0000000 --- a/contrib/bind9/doc/rfc/rfc3364.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -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. - -Abstract - - The 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. - -Introduction - - RFC 1886 [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. - - - - - - - -Austein Informational [Page 1] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - - 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. - -Main Advantages of Going with A6 - - While the A6 RR proposed in [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. - - - -Austein Informational [Page 2] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - -Main Advantages of Going with AAAA - - The AAAA RR proposed in [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). - -Less Compelling Arguments in Favor of A6 - - Since the A6 RR allows a zone administrator to write zone files whose - description of addresses maps to the underlying network topology, A6 - RRs can be construed as a "better" way of representing addresses than - AAAA. This may well be a useful capability, but in and of itself - it's more of an argument for better tools for zone administrators to - use when constructing zone files than a justification for changing - 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 appears to be - based on the wider deployment of AAAA. Since it is possible to - construct transition tools (see discussion of AAAA synthesis, later - in this note), this does not appear to be a compelling argument if A6 - provides features that we really need. - - Another argument in favor of AAAA RRs over A6 RRs appears to be that - the A6 RR's advanced capabilities increase the number of ways in - which a zone administrator could build a non-working configuration. - While operational issues are certainly important, this is more of - argument that we need better tools for zone administrators than it is - a justification for turning away from A6 if A6 provides features that - we really need. - - - - - - - - - -Austein Informational [Page 3] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - -Potential Problems with A6 - - The enhanced capabilities of the A6 RR, while interesting, are not in - themselves justification for choosing A6 if we don't really need - those capabilities. The A6 RR is "optimized for write", in the sense - that, by making it possible to store fragmented IPv6 addresses in the - DNS, it makes it possible to reduce the effort that it takes to - inject new data into the DNS (at the expense of increasing the effort - involved in fetching data from the DNS). This may be justified if we - expect the effort involved in maintaining AAAA-style DNS entries to - be prohibitive, but in general, we expect the DNS data to be read - more frequently than it is written, so we need to evaluate this - particular tradeoff very carefully. - - There are also several potential issues with A6 RRs that stem - directly from the feature that makes them different from AAAA RRs: - the ability to build up address via chaining. - - Resolving a chain of A6 RRs involves resolving a series of what are - almost independent queries, but not quite. Each of these sub-queries - takes some non-zero amount of time, unless the answer happens to be - in the resolver's local cache already. Assuming that resolving an - AAAA RR takes time T as a baseline, we can guess that, on the - average, it will take something approaching time N*T to resolve an - N-link chain of A6 RRs, although we would expect to see a fairly good - caching factor for the A6 fragments representing the more significant - bits of an address. This leaves us with two choices, neither of - which is very good: we can decrease the amount of time that the - resolver is willing to wait for each fragment, or we can increase the - amount of time that a resolver is willing to wait before returning - failure to a client. What little data we have on this subject - suggests that users are already impatient with the length of time it - takes to resolve A RRs in the IPv4 Internet, which suggests that they - are not likely to be patient with significantly longer delays in the - IPv6 Internet. At the same time, terminating queries prematurely is - both a waste of resources and another source of user frustration. - Thus, we are forced to conclude that indiscriminate use of long A6 - chains is likely to lead to problems. - - To make matters worse, the places where A6 RRs are likely to be most - critical for rapid renumbering or GSE-like routing are 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 - administered by a different organization (for example, in the case of - an end user's site, the prefix name will most likely point to a name - belonging to an ISP that provides connectivity for the site). While - pointers out of zone are not a problem per se, pointers to other - organizations are somewhat more difficult to maintain and less - - - -Austein Informational [Page 4] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - - 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. - -Interactions with DNSSEC - - One of the areas where AAAA and A6 RRs differ is in the precise - details of how they interact with DNSSEC. The following comments - apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are - semantically equivalent to AAAA RRs). - - - - - - -Austein Informational [Page 5] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - - 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. - -Interactions with Dynamic Update - - DNS dynamic update appears 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. At present, no - mechanism exists to inform a dynamic update client of these values, - but presumably such a mechanism could be provided via an extension to - DHCP, or some other equivalent could be devised. - - - - - - - -Austein Informational [Page 6] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - -Transition from AAAA to A6 Via AAAA Synthesis - - While AAAA is at present more widely deployed than A6, 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 that is performing - 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 - - While the differences between AAAA and A6 RRs have generated most of - the discussion to date, 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, 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 - - - -Austein Informational [Page 7] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - - 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. - -DNAME RRs - - [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. - -Recommendation - - Distilling the above feature comparisons down to their key elements, - the important questions appear to be: - - (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) appears to be the key to the debate. This is really a - decision for the IPv6 community to make, not the DNS community. - - Question (b) is also for the IPv6 community to make, but it seems - fairly obvious that the answer is "no". - - - - - -Austein Informational [Page 8] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - - 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. - -Security Considerations - - This note compares two mechanisms with similar security - characteristics, but there are a few security implications to the - choice between these two mechanisms: - - (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. - - - - - - -Austein Informational [Page 9] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - -Acknowledgments - - This note is based on a number of discussions both public and private - over a period of (at least) eight years, but particular thanks go to - Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun - Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush, - and Sue Thomson, none of whom are responsible for what the author did - with their ideas. - -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 - - - - - - - - - - - - - - - - -Austein Informational [Page 10] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - -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. - - - - - - - - - - - - - - - - - - - -Austein Informational [Page 11] - |
