idnits 2.17.1 draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Sommerfeld], [Tweedledum], [Tweedledee]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2001) is 8315 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1886 (ref. 'Tweedledee') (Obsoleted by RFC 3596) ** Downref: Normative reference to an Historic RFC: RFC 2874 (ref. 'Tweedledum') -- Possible downref: Non-RFC (?) normative reference: ref. 'Sommerfeld' Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Austein 3 draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt InterNetShare, Inc. 4 July 2001 6 Tradeoffs in DNS support for IPv6 8 Status of this document 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 26 The list of Internet-Draft Shadow Directories can be accessed at 27 29 Distribution of this document is unlimited. Please send comments to 30 the Namedroppers mailing list . 32 Abstract 34 The IETF has two different proposals on the table for how to do DNS 35 support for IPv6, and has thus far failed to reach a clear consensus 36 on which approach is better. This note attempts to examine the pros 37 and cons of each approach, in the hope of clarifying the debate so 38 that we can reach closure and move on. 40 Introduction 42 RFC 1886 [Tweedledee] specified straightforward mechanisms to support 43 IPv6 addresses in the DNS. These mechanisms closely resemble the 44 mechanisms used to support IPv4, and with a minor improvement to the 45 reverse mapping mechanism based on experience with CIDR. RFC 1886 is 46 currently listed as a Proposed Standard. 48 RFC 2874 [Tweedledum] specified enhanced mechanisms to support IPv6 49 addresses in the DNS. These mechanisms provide new features that 50 make it possible for an IPv6 address stored in the DNS to be broken 51 up into multiple DNS resource records in ways that can reflect the 52 network topology underlying the address, thus making it possible for 53 the data stored in the DNS to reflect certain kinds of network 54 topology changes or routing architectures that are either impossible 55 or more difficult to represent without these mechanisms. RFC 2874 is 56 also currently listed as a Proposed Standard. 58 Both of these Proposed Standards were the output of the IPNG Working 59 Group. Both have been implemented, although implementation of 60 [Tweedledee] is more widespread, both because it was specified 61 earlier and because it's simpler to implement. 63 There's little question that the mechanisms proposed in [Tweedledum] 64 are more general than the mechanisms proposed in [Tweedledee], and 65 that these enhanced mechanisms might be valuable if IPv6's evolution 66 goes in certain directions. The questions are whether we really need 67 the more general mechanism, what new usage problems might come along 68 with the enhanced mechanisms, and what effect all this will have on 69 IPv6 deployment. 71 The one thing on which there does seem to be widespread agreement is 72 that we should make up our minds about all this Real Soon Now. 74 Main advantages of going with A6 76 While the A6 RR proposed in [Tweedledum] is very general and provides 77 a superset of the functionality provided by the AAAA RR in 78 [Tweedledee], many of the features of A6 can also be implemented with 79 AAAA RRs via preprocessing during zone file generation. 81 There is one specific area where A6 RRs provide something that cannot 82 be provided using AAAA RRs: A6 RRs can represent addresses in which a 83 prefix portion of the address can change without any action (or 84 perhaps even knowledge) by the parties controlling the DNS zone 85 containing the terminal portion (least significant bits) of the 86 address. This includes both so-called "rapid renumbering" scenarios 87 (where an entire network's prefix may change very quickly) and 88 routing architectures such as GSE (where the "routing goop" portion 89 of an address may be subject to change without warning). A6 RRs do 90 not completely remove the need to update leaf zones during all 91 renumbering events (for example, changing ISPs would usually require 92 a change to the upward delegation pointer), but careful use of A6 RRs 93 could keep the number of RRs that need to change during such an event 94 to a minimum. 96 Note that constructing AAAA RRs via preprocessing during zone file 97 generation requires exactly the sort of information that A6 RRs store 98 in the DNS. This begs the question of where the hypothetical 99 preprocessor obtains that information if it's not getting it from the 100 DNS. 102 Note also that the A6 RR, when restricted to its zero-length-prefix 103 form ("A6 0"), is semantically equivalent to an AAAA RR (with one 104 "wasted" octet in the wire representation), so anything that can be 105 done with an AAAA RR can also be done with an A6 RR. 107 Main advantages of going with AAAA 109 The AAAA RR proposed in [Tweedledee], while providing only a subset 110 of the functionality provided by the A6 RR proposed in [Tweedledum], 111 has two main points to recommend it: 113 - AAAA RRs are essentially identical (other than their length) to 114 IPv4's A RRs, so we have more than 15 years of experience to help 115 us predict the usage patterns, failure scenarios and so forth 116 associated with AAAA RRs. 118 - The AAAA RR is "optimized for read", in the sense that, by storing 119 a complete address rather than making the resolver fetch the 120 address in pieces, it minimizes the effort involved in fetching 121 addresses from the DNS (at the expense of increasing the effort 122 involved in injecting new data into the DNS). 124 Less compelling arguments in favor of A6 126 Since the A6 RR allows a zone administrator to write zone files whose 127 description of addresses maps to the underlying network topology, A6 128 RRs can be construed as a "better" way of representing addresses than 129 AAAA. This may well be a useful capability, but in and of itself 130 it's more of an argument for better tools for zone administrators to 131 use when constructing zone files than a justification for changing 132 the resolution protocol used on the wire. 134 Less compelling arguments in favor of AAAA 136 Some of the pressure to go with AAAA instead of A6 appears to be 137 based on the wider deployment of AAAA. Since it is possible to 138 construct transition tools (see discussion of AAAA synthesis, later 139 in this note), this does not appear to be a compelling argument if A6 140 provides features that we really need. 142 Another argument in favor of AAAA RRs over A6 RRs appears to be that 143 the A6 RR's advanced capabilities increase the number of ways in 144 which a zone administrator could build a non-working configuration. 145 While operational issues are certainly important, this is more of 146 argument that we need better tools for zone administrators than it is 147 a justification for turning away from A6 if A6 provides features that 148 we really need. 150 Potential problems with A6 152 The enhanced capabilities of the A6 RR, while interesting, are not in 153 themselves justification for choosing A6 if we don't really need 154 those capabilities. The A6 RR is "optimized for write", in the sense 155 that, by making it possible to store fragmented IPv6 addresses in the 156 DNS, it makes it possible to reduce the effort that it takes to 157 inject new data into the DNS (at the expense of increasing the effort 158 involved in fetching data from the DNS). This may be justified if we 159 expect the effort involved in maintaining AAAA-style DNS entries to 160 be prohibitive, but in general, we expect the DNS data to be read 161 more frequently than it is written, so we need to evaluate this 162 particular tradeoff very carefully. 164 There are also several potential issues with A6 RRs that stem 165 directly from the feature that makes them different from AAAA RRs: 166 the ability to build up address via chaining. 168 Resolving a chain of A6 RRs involves resolving a series of what are 169 almost independent queries, but not quite. Each of these sub-queries 170 takes some non-zero amount of time, unless the answer happens to be 171 in the resolver's local cache already. Assuming that resolving an 172 AAAA RR takes time T as a baseline, we can guess that, on the 173 average, it will take something approaching time N*T to resolve an N- 174 link chain of A6 RRs, although we would expect to see a fairly good 175 caching factor for the A6 fragments representing the more significant 176 bits of an address. This leaves us with two choices, neither of 177 which is very good: we can decrease the amount of time that the 178 resolver is willing to wait for each fragment, or we can increase the 179 amount of time that a resolver is willing to wait before returning 180 failure to a client. What little data we have on this subject 181 suggests that users are already impatient with the length of time it 182 takes to resolve A RRs in the IPv4 Internet, which suggests that they 183 are not likely to be patient with significantly longer delays in the 184 IPv6 Internet. At the same time, terminating queries prematurely is 185 both a waste of resources and another source of user frustration. 186 Thus, we are forced to conclude that indiscriminate use of long A6 187 chains is likely to lead to problems. 189 To make matters worse, the places where A6 RRs are likely to be most 190 critical for rapid renumbering or GSE-like routing are situations 191 where the prefix name field in the A6 RR points to a target that is 192 not only outside the DNS zone containing the A6 RR, but is 193 administered by a different organization (for example, in the case of 194 an end user's site, the prefix name will most likely point to a name 195 belonging to an ISP that provides connectivity for the site). While 196 pointers out of zone are not a problem per se, pointers to other 197 organizations are somewhat more difficult to maintain and less 198 susceptible to automation than pointers within a single organization 199 would be. Experience both with glue RRs and with PTR RRs in the IN- 200 ADDR.ARPA tree suggests that many zone administrators do not really 201 understand how to set up and maintain these pointers properly, and we 202 have no particular reason to believe that these zone administrators 203 will do a better job with A6 chains than they do today. To be fair, 204 however, the alternative case of building AAAA RRs via preprocessing 205 before loading zones has many of the same problems; at best, one can 206 claim that using AAAA RRs for this purpose would allow DNS clients to 207 get the wrong answer somewhat more efficiently than with A6 RRs. 209 Finally, assuming near total ignorance of how likely a query is to 210 fail, the probability of failure with an N-link A6 chain would appear 211 to be roughly proportional to N, since each of the queries involved 212 in resolving an A6 chain would have the same probability of failure 213 as a single AAAA query. Note again that this comment applies to 214 failures in the the process of resolving a query, not to the data 215 obtained via that process. Arguably, in an ideal world, A6 RRs would 216 increase the probability of the answer a client (finally) gets being 217 right, assuming that nothing goes wrong in the query process, but we 218 have no real idea how to quantify that assumption at this point even 219 to the hand-wavey extent used elsewhere in this note. 221 One potential problem that has been raised in the past regarding A6 222 RRs turns out not to be a serious issue. The A6 design includes the 223 possibility of there being more than one A6 RR matching the prefix 224 name portion of a leaf A6 RR. That is, an A6 chain may not be a 225 simple linked list, it may in fact be a tree, where each branch 226 represents a possible prefix. Some critics of A6 have been concerned 227 that this will lead to a wild expansion of queries, but this turns 228 out not to be a problem if a resolver simply follows the "bounded 229 work per query" rule described in RFC 1034 (page 35). That rule 230 applies to all work resulting from attempts to process a query, 231 regardless of whether it's a simple query, a CNAME chain, an A6 tree, 232 or an infinite loop. The client may not get back a useful answer in 233 cases where the zone has been configured badly, but a proper 234 implementation should not produce a query explosion as a result of 235 processing even the most perverse A6 tree, chain, or loop. 237 Interactions with DNSSEC 239 One of the areas where AAAA and A6 RRs differ is in the precise 240 details of how they interact with DNSSEC. The following comments 241 apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are 242 semantically equivalent to AAAA RRs). 244 Other things being equal, the time it takes to re-sign all of the 245 addresses in a zone after a renumbering event is longer with AAAA RRs 246 than with A6 RRs (because each address record has to be re-signed 247 rather than just signing a common prefix A6 RR and a few A6 0 RRs 248 associated with the zone's name servers). Note, however, that in 249 general this does not present a serious scaling problem, because the 250 re-signing is performed in the leaf zones. 252 Other things being equal, there's more work involved in verifying the 253 signatures received back for A6 RRs, because each address fragment 254 has a separate associated signature. Similarly, a DNS message 255 containing a set of A6 address fragments and their associated 256 signatures will be larger than the equivalent packet with a single 257 AAAA (or A6 0) and a single associated signature. 259 Since AAAA RRs cannot really represent rapid renumbering or GSE-style 260 routing scenarios very well, it should not be surprising that DNSSEC 261 signatures of AAAA RRs are also somewhat problematic. In cases where 262 the AAAA RRs would have to be changing very quickly to keep up with 263 prefix changes, the time required to re-sign the AAAA RRs may be 264 prohibitive. 266 Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that 267 333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the 268 BIND-9 dnssec-signzone program under NetBSD can generate roughly 40 269 1024-bit RSA signatures per second. Extrapolating from this, 270 assuming one A RR, one AAAA RR, and one NXT RR per host, this 271 suggests that it would take this laptop a few hours to sign a zone 272 listing 10**5 hosts, or about a day to sign a zone listing 10**6 273 hosts using AAAA RRs. 275 This suggests that the additional effort of re-signing a large zone 276 full of AAAA RRs during a re-numbering event, while noticeable, is 277 only likely to be prohibitive in the rapid renumbering case where 278 AAAA RRs don't work well anyway. 280 Interactions with dynamic update 282 DNS dynamic update appears to work equally well for AAAA or A6 RRs, 283 with one minor exception: with A6 RRs, the dynamic update client 284 needs to know the prefix length and prefix name. At present, no 285 mechanism exists to inform a dynamic update client of these values, 286 but presumably such a mechanism could be provided via an extension to 287 DHCP, or some other equivalent could be devised. 289 Transition from AAAA to A6 via AAAA synthesis 291 While AAAA is at present more widely deployed than A6, it is possible 292 to transition from AAAA-aware DNS software to A6-aware DNS software. 293 A rough plan for this was presented at IETF-50 in Minneapolis and has 294 been discussed on the ipng mailing list. So if the IETF concludes 295 that A6's enhanced capabilities are necessary, it should be possible 296 to transition from AAAA to A6. 298 The details of this transition have been left to a separate document, 299 but the general idea is that the resolver that is performing 300 iterative resolution on behalf of a DNS client program could 301 synthesize AAAA RRs representing the result of performing the 302 equivalent A6 queries. Note that in this case it is not possible to 303 generate an equivalent DNSSEC signature for the AAAA RR, so clients 304 that care about performing DNSSEC validation for themselves would 305 have to issue A6 queries directly rather than relying on AAAA 306 synthesis. 308 Bitlabels 310 While the differences between AAAA and A6 RRs have generated most of 311 the discussion to date, there are also two proposed mechanisms for 312 building the reverse mapping tree (the IPv6 equivalent of IPv4's IN- 313 ADDR.ARPA tree). 315 [Tweedledee] proposes a mechanism very similar to the IN-ADDR.ARPA 316 mechanism used for IPv4 addresses: the RR name is the hexadecimal 317 representation of the IPv6 address, reversed and concatenated with a 318 well-known suffix, broken up with a dot between each hexadecimal 319 digit. The resulting DNS names are somewhat tedious for humans to 320 type, but are very easy for programs to generate. Making each 321 hexadecimal digit a separate label means that delegation on arbitrary 322 bit boundaries will result in a maximum of 16 NS RRs per label; 323 again, the mechanism is somewhat tedious for humans, but is very easy 324 to program. As with IPv4's IN-ADDR.ARPA tree, the one place where 325 this scheme is weak is in handling delegations in the least 326 significant label; however, since there appears to be no real need to 327 delegate the least significant four bits of an IPv6 address, this 328 does not appear to be a serious restriction. 330 [Tweedledum] proposed a radically different way of naming entries in 331 the reverse mapping tree: rather than using textual representations 332 of addresses, it proposes to use a new kind of DNS label (a "bit 333 label") to represent binary addresses directly in the DNS. This has 334 the advantage of being significantly more compact than the textual 335 representation, and arguably might have been a better solution for 336 DNS to use for this purpose if it had been designed into the protocol 337 from the outset. Unfortunately, experience to date suggests that 338 deploying a new DNS label type is very hard: all of the DNS name 339 servers that are authoritative for any portion of the name in 340 question must be upgraded before the new label type can be used, as 341 must any resolvers involved in the resolution process. Any name 342 server that has not been upgraded to understand the new label type 343 will reject the query as being malformed. 345 Since the main benefit of the bit label approach appears to be an 346 ability that we don't really need (delegation in the least 347 significant four bits of an IPv6 address), and since the upgrade 348 problem is likely to render bit labels unusable until a significant 349 portion of the DNS code base has been upgraded, it is difficult to 350 escape the conclusion that the textual solution is good enough. 352 DNAME RRs 354 [Tweedledum] also proposes using DNAME RRs as a way of providing the 355 equivalent of A6's fragmented addresses in the reverse mapping tree. 356 That is, by using DNAME RRs, one can write zone files for the reverse 357 mapping tree that have the same ability to cope with rapid 358 renumbering or GSE-style routing that the A6 RR offers in the main 359 portion of the DNS tree. Consequently, the need to use DNAME in the 360 reverse mapping tree appears to be closely tied to the need to use 361 fragmented A6 in the main tree: if one is necessary, so is the other, 362 and if one isn't necessary, the other isn't either. 364 Other uses have also been proposed for the DNAME RR, but since they 365 are outside the scope of the IPv6 address discussion, they will not 366 be addressed here. 368 Other topics ??? 370 Recommendation 372 Distilling the above feature comparisons down to their key elements, 373 the important questions appear to be: 375 (a) Is IPv6 going to do rapid renumber or GSE-like routing? 376 (b) Is the reverse mapping tree for IPv6 going to require delegation 377 in the least significant four bits of the address? 379 Question (a) appears to be the key to the debate. This is really a 380 decision for the IPv6 community to make, not the DNS community. 382 Question (b) is also for the IPv6 community to make, but it seems 383 fairly obvious that the answer is "no". 385 Recommendations based on these questions: 387 (1) If the IPv6 working groups seriously intend to specify and deploy 388 rapid renumbering or GSE-like routing, we should transition to 389 using the A6 RR in the main tree and to using DNAME RRs as 390 necessary in the reverse tree. 391 (2) Otherwise, we should keep the simpler AAAA solution in the main 392 tree and should not use DNAME RRs in the reverse tree. 393 (3) In either case, the reverse tree should use the textual 394 representation described in [Tweedledee] rather than the bit 395 label representation described in [Tweedledum]. 396 (4) If we do go to using A6 RRs in the main tree and to using DNAME 397 RRs in the reverse tree, we should write applicability statements 398 and implementation guidelines designed to discourage excessively 399 complex uses of these features; in general, any network that can 400 be described adequately using A6 0 RRs and without using DNAME 401 RRs should be described that way, and the enhanced features 402 should be used only when absolutely necessary, at least until we 403 have much more experience with them and have a better 404 understanding of their failure modes. 406 Security Considerations 408 ??? 410 IANA Considerations 412 None, since all of these RR types have already been allocated. 414 Acknowledgments 416 This note is based on a number of discussions both public and private 417 over a period of (at least) eight years, but particular thanks go to 418 Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun 419 Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush, 420 and Sue Thomson, none of whom are responsible for what the author did 421 with their ideas. 423 References 425 [Tweedledee] Thomson, S., and Huitema, C., "DNS Extensions to support 426 IP version 6", RFC 1886, December 1995. 428 [Tweedledum] Crawford, M., and Huitema, C., "DNS Extensions to 429 Support IPv6 Address Aggregation and Renumbering" RFC 2874, July 430 2000. 432 [Sommerfeld] Private message to the author from Bill Sommerfeld dated 433 21 March 2001, summarizing the result of experiments he 434 performed on a copy of the MIT.EDU zone. 436 Author's addresses: 438 Rob Austein 439 InterNetShare, Inc. 440 505 West Olive Ave., Suite 321 441 Sunnyvale, CA 94086 442 USA 443 sra@hactrn.net