idnits 2.17.1 draft-ietf-dnsext-aaaa-a6-01.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 19, 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) -- Missing reference section? 'Thomson' on line 415 looks like a reference -- Missing reference section? '1995' on line 34 looks like a reference -- Missing reference section? 'Crawford' on line 405 looks like a reference -- Missing reference section? '2000' on line 405 looks like a reference -- Missing reference section? 'Austein' on line 328 looks like a reference -- Missing reference section? '2001' on line 380 looks like a reference -- Missing reference section? 'Draves' on line 380 looks like a reference -- Missing reference section? 'Hagino' on line 402 looks like a reference -- Missing reference section? '1998' on line 415 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Jun-ichiro itojun Hagino 3 INTERNET-DRAFT IIJ Research Laboratory 4 Expires: January 19, 2002 July 19, 2001 6 Comparison of AAAA and A6 (do we really need A6?) 7 draft-ietf-dnsext-aaaa-a6-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-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 material 21 or to cite them other than as ``work in progress.'' 23 To view the list Internet-Draft Shadow Directories, see 24 http://www.ietf.org/shadow.html. 26 Distribution of this memo is unlimited. 28 The internet-draft will expire in 6 months. The date of expiration will 29 be January 19, 2002. 31 Abstract 33 At this moment, there are two DNS resource record types defined for 34 holding IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6 35 [Crawford, 2000] . AAAA has been used for IPv6 network operation since 36 1996. Questions arose whether we really need A6 or not, or whether it 37 is really possible to migrate to A6 or not. Some says AAAA is enough 38 and A6 is not necessary. Some says A6 is necessary and AAAA should get 39 deprecated. 41 The draft tries to understand pros and cons between these two record 42 types, and makes suggestions on deployment of IPv6 record type. 44 The draft does not cover the use of bit string label and DNAME resource 45 record (reverse mapping), as it seems that nibble form is well accepted 46 in the community, newer formats have too much deployment costs, thus we 47 see few need/voice that calls for migration. Refer to IETF50 dnsext 48 working group minutes for more details. 50 1. A brief summary of the IPv6 resource record types 52 1.1. AAAA record 54 AAAA resource record is formatted as follows. DNS record type value for 55 AAAA is 28 (assigned by IANA). Note that AAAA record is formatted as a 56 fixed-length data. 58 +------------+ 59 |IPv6 Address| 60 | (16 octets)| 61 +------------+ 63 With AAAA, we can define DNS records for IPv6 address resolution as 64 follows, just like A records for IPv4. 66 $ORIGIN X.EXAMPLE. 67 N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 68 N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 69 N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 71 1.2. A6 record 73 A6 resource record is formatted as follows. DNS record type value for 74 A6 is 38 (assigned by IANA). Note that A6 record is formatted as a 75 variable-length data. 77 +-----------+------------------+-------------------+ 78 |Prefix len.| Address suffix | Prefix name | 79 | (1 octet) | (0..16 octets) | (0..255 octets) | 80 +-----------+------------------+-------------------+ 82 With A6, it is possible to define an IPv6 address by using multiple DNS 83 records. Here is an example taken from RFC2874: 85 $ORIGIN X.EXAMPLE. 86 N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 87 SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 88 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. 89 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. 91 SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. 92 SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET. 94 SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET. 96 A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG. 98 A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG. 100 B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG. 102 C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: 103 D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: 104 E.NET.ALPHA-TLA.ORG. A6 0 2345:000E:: 106 If we translate the above into AAAA records, it will be as follows: 108 $ORIGIN X.EXAMPLE. 109 N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 110 N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 111 N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 113 It is also possible to use A6 records in ``non-fragmented'' manner, like 114 below. 116 $ORIGIN X.EXAMPLE. 117 N A6 0 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 118 N A6 0 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 119 N A6 0 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 121 There is a large design difference between A6 and AAAA. A6 imposes 122 address resolutions tasks more to the resolver side, to reduce the 123 amount of zone file maintenance cost. The complexity is in the resolver 124 side. AAAA asks zone file maintainers to supply the full 128bit IPv6 125 address in one record, and the resolver side can be implemented very 126 simple. 128 2. Deployment status 130 2.1. Name servers/resolvers 132 As of writing, AAAA is deployed pretty widely. BIND4 (since 4.9.4), 133 BIND8, BIND9 and other implementations support AAAA, as both DNS servers 134 and as resolver libraries. On the contrary, the author knows of only 135 one DNS server/resolver implementation that supports A6; BIND9. 137 Almost all of the IPv6-ready operating systems ship with BIND4 or BIND8 138 resolver library. [need to check situations with resolver libraries 139 based on non-BIND code] Therefore, they cannot query A6 records (unless 140 applications gets linked with BIND9 libraries explicitly). 142 2.2. IPv6 network 144 IPv6 network has been deployed widely since 1996. Though many of the 145 participants consider it to be experimental, commercial IPv6 services 146 has been deployed since around 1999, especially in Asian countries. 147 Even today, there are numerous IPv6 networks operated just as serious as 148 IPv4. 150 2.3. DNS database 152 There are no IPv6-reachable root DNS servers, partly because we have 153 both AAAA and A6, and we are not decided about which is the one we would 154 like to really deploy (so we cannot put IPv6 root NS records). The lack 155 of IPv6-reachable root DNS servers is now preventing IPv6-only or 156 IPv4/v6 dual stack network operations. 158 At this moment, very small number of ccTLD registries accept 159 registeration requests for IPv6 glue records. Many of the ccTLDs and 160 gTLDs do not take IPv6 glue records, partly because of the lack of 161 consensus between AAAA and A6. Again, the lack of IPv6 glue records is 162 causing pain in IPv6-ready network operations. For example, JP ccTLD 163 accepts IPv6 glue records and registers them as AAAA records. IPv6 NS 164 records (with AAAA) works flawlessly from our experiences. For example, 165 try the following commands to see how JP ccTLD registers IPv6 glue 166 records (``/e'' is for English-language output): 168 % whois -h whois.nic.ad.jp wide.ad.jp/e 169 % whois -h whois.nic.ad.jp ns1.v6.wide.ad.jp/e 171 3. Deploying DNS records 173 At this moment, the following four strategies are proposed for the 174 deployment of IPv6 DNS resource record; AAAA, fragmented A6 records, 175 non-fragmented A6 records, and AAAA synthesis. 177 3.1. AAAA records 179 AAAA records have been used on IPv6 network (also known as 6bone) since 180 it has started in 1996 and has been working just fine ever since. AAAA 181 record is a straight extension of A record; it needs a single query- 182 response roundtrip to resolve a name into an IPv6 address. 184 A6 was proposed to add network renumbering friendliness to AAAA. With 185 AAAA, a full 128bit IPv6 address needs to be supplied in a DNS resource 186 record. Therefore, in the event of network renumber, administrators 187 need to update the whole DNS zone file with the new IPv6 address 188 prefixes. We will discuss the issues with renumbering in a dedicated 189 section. 191 3.2. Fragmented A6 records 193 If we are to use fragmented A6s (128bit splitted into multiple A6s), we 194 have a lot of issues/worries. 196 If we are to resolve IPv6 addresses using fragmented A6 records, we need 197 to query DNS multiple times to resolve a single DNS name into an IPv6 198 address. Since there has been no DNS record types that require multiple 199 queries for resolution of the address itself, we have very little 200 experience on such resource records. 202 There will be more delays in name resolution compared to queries to 203 A/AAAA records. If we define a record with more number of fragments, 204 there will be more query roundtrips. There are only few possibilities 205 to query fragments in parallel. In the above example, we can resolve 206 A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others. 208 At this moment, there is very little documents available, regarding to 209 the relationship between DNS record TTL and the query delays. For 210 example, if the DNS record TTL is smaller than the communication delays 211 between the querier and the DNS servers, what should happen? 213 o If we compute DNS record TTL based on the wallclock on the DNS server 214 side, the DNS records are already expired and the querier will not be 215 able to reassemble a complete IPv6 record. Worse, by setting up 216 records with very low TTL, we can let recursive DNS resolvers to go 217 into infinite loop by letting them chase a wrong A6 chain (see the 218 section on security considration) [BIND 9.2.0snap: resolver does not 219 go into infinite loop, meaning that BIND 9.2.0snap resolver does not 220 really honor DNS record TTL during A6 reassembly]. 222 o If we compute it starting from the time the querier got the record, we 223 will have some jitter in TTL computation among multiple queriers. If 224 the query delays are long enough, the querier would end up having 225 inconsistent A6 fragments, and the IPv6 address can be bogus after 226 reassembly. With record types other than A6, we had no such problem, 227 since we have never tried to reassemble an address out of multiple DNS 228 records (with CNAME chain chasing a similar problem can arise, but the 229 failure mode is much simpler to diagnose as the records are considered 230 as an atomic entity). 232 Some says that caches will avoid querying fragmented A6s again and 233 again. However, most of the library resolver implementations do not 234 cache anything. The traffic between library resolver and the first-hop 235 nameserver will not be decreased by the cached records. The TTL problem 236 (see above) is unavoidable for the library resolver without cache. [XXX 237 will they interpret TTL field? BIND8 resolver does not] 238 If some of the fragments are DNSSEC-signed and some are not, how should 239 we treat that address? RFC2874 section 6 briefly talks about it, not 240 sure if complete answer is given. 242 It is much harder to implement A6 fragment reassemble code, than to 243 implement AAAA record resolver. AAAA record resolver can be implemented 244 as a straight extension of A record resolver. 246 o It is much harder to design timeout handling for the A6 reassembly. 247 There would be multiple timeout parameters, including (1) communcation 248 timeout for a single A6 fragment, (2) communcation timeout for the 249 IPv6 address itself (total time needed for reassembly) and (3) TTL 250 timeout for A6 fragment records. 252 o In the case of library resolver implementation, it is harder to deal 253 with exceptions (signals in UNIX case) for the large code fragment for 254 resolvers. 256 o When A6 prefix length field is not multiple of 8, address suffix 257 portion needs to be shifted bitwise while A6 fragments are 258 reassembled. Also, resolver implementations must be careful about 259 overwraps of the bits. From our implementatation experiences, the 260 logic gets very complex and we (unfortunately) expect to see a lot of 261 security-critical bugs in the future. 263 In RFC2874, a suggestion is made to use limited number of fragments per 264 an IPv6 address. However, there is no protocol limitation defined. The 265 lack makes it easier for malicious parties to impose DoS attacks using 266 lots of A6 fragments (see the section on security consideration). [BIND 267 9.2.0snap: The implementation limits the number of fragments within an 268 A6 chain to be smaller than 16; It is not a protocol limitation but an 269 implementation choice. Not sure if it is the right choice or not] 271 With fragmented A6 records, in multi-prefix network configuration, it is 272 not possible for us to limit the address on the DNS database to the 273 specific set of records, like for load distribution purposes. Consider 274 the following example. Even if we would like to advertise only 275 2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible 276 to do so. It becomes mandatory for us to define the whole IPv6 address 277 by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6 278 (renumber friendliness) goes away. 280 ; with the following record we would advertise both records 281 $ORIGIN X.EXAMPLE. 282 N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 283 M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6 284 SUBNET-1.IP6 A6 0 2345:00C1:CA11:1:: 285 A6 0 2345:00D2:DA11:1:: 287 ; we need to do the following, jeopardizing renumbering 288 ; friendliness for N.X.EXAMPLE 289 $ORIGIN X.EXAMPLE. 290 N A6 0 2345:00C1:CA11:1:1234:5678:9ABC:DEF0 291 M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6 292 SUBNET-1.IP6 A6 0 2345:00C1:CA11:1:: 293 A6 0 2345:00D2:DA11:1:: 295 A6 resource record type and A6 fragment/reassembly were introduced to 296 help administrators on network renumber. When network gets renumbered, 297 the administrator needs to update A6 fragment for the higher address 298 bits (prefixes) only. Again, we will discuss the issues with 299 renumbering in a dedicated section. 301 3.3. Non-fragmented A6 records 303 There are proposals to use non-fragmented A6 records in most of the 304 places, like ``A6 0 <128bit>'', so that we would be able to switch to 305 fragmented A6 records when we find a need for A6. 307 >From the packet format point of view, the approach has no benefit 308 against AAAA. Rather, there is a one-byte overhead to every 309 (unfragmented) A6 record compared to a AAAA record. 311 If the nameserver/resolver programs hardcode A6 processing to handle no 312 fragments, there will be no future possibility for us to introduce 313 fragmented A6 records. When there is no need for A6 reassembly, there 314 will be no code deployment, and even if the reassembly code gets 315 deployed they will not be tested enough. The author believes that the 316 ``prepare for the future, use non-fragmented A6'' argument is not 317 worthwhile. 319 In the event of renumbering, non-fragmented A6 record has the same 320 property as AAAA (the whole zone file has to be updated). 322 3.4. AAAA synthesis (A6 and AAAA hybrid approach) 324 At this moment, end hosts support AAAA records only. Some people would 325 like to see A6 deployment in DNS databases even with the lack of end 326 hosts support. To workaround the deployment issues of A6, the following 327 approach is proposed in IETF50 dnsext working group slot. It is called 328 ``AAAA synthesis'' [Austein, 2001] : 330 o Deploy A6 DNS records worldwide. The proposal was not specific about 331 whether we would deploy fragmented A6 records, or non-fragmented A6 332 records (``A6 0''). 334 o When a host queries AAAA record to a DNS server, the DNS server 335 queries A6 fragments, reassemble it, and respond with a AAAA record. 337 The approach needs to be diagnosed/specified in far more detail. For 338 example, the following questions need to be answered: 340 o What is the DNS error code against AAAA querier, if the A6 reassembly 341 fails? 343 o What TTL should the synthesized AAAA record have? [BIND 9.2.0snap 344 uses TTL=0] 346 o Which nameserver should synthesize the AAAA record, in the DNS 347 recursize query chain? Is the synthesis mandatory for every DNS 348 server implementation? 350 o What should we do if the A6 reassembly takes too much time? 352 o What should we do about DNSSEC signatures? 354 o What if the resolver wants no synthesis? Do we want to have a flag 355 bit in DNS packet, to enable/disable AAAA synthesis? 357 o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query 358 timeouts, and other timeout parameters? 360 The approach seems to be vulnerable against DoS attacks, because the 361 nameserver reassembles A6 fragments on behalf of the AAAA querier. See 362 security consideration section for more details. 364 3.5. Issues in keeping both AAAA and A6 366 If we are to keep both AAAA and A6 records onto the worldwide DNS 367 database, it would impose more query delays to the client resolvers. 368 Suppose we have a dual-stack host implementation. If they need to 369 resolve a name into addresses, the node would need to query in the 370 following order (in the order which RFC2874 suggests): 372 o Query A6 records, and get full IPv6 addresses by chasing and 373 reassembling A6 fragment chain. 375 o Query AAAA records. 377 o Query A records. 379 o Sort the result based on destination address ordering rule. An 380 example of the ordering rule is presented as a draft [Draves, 2001] . 382 o Contact the destination addresses in sequence. 384 The ordering imposes additional delays to the resolvers. The above 385 ordering would be necessary for all approaches that use A6, as there are 386 existing AAAA records in the world. 388 4. Network renumbering 390 Some says that there will be more frequent renumbers in IPv6 network 391 operation, and A6 is necessary to reduce the zone modification cost as 392 well as zone signing costs on renumber operation. 394 It is not clear if we really want to renumber that frequently. With 395 IPv6, it should be easier for ISPs to assign addresses statically to the 396 downstream customers, rather than dynamically like we do in IPv4 dialup 397 connectivity today. If ISPs do assign static IPv6 address block to the 398 customers, there is no need to renumber customer network that frequently 399 (unless the customer decides to switch the upstream ISPs that often). 400 NOTE: Roaming dialup users, like those who carry laptop computers 401 worldwide, seems to have a different issue from stationary dialup users. 402 See [Hagino, 2000] for more discussions. 404 It is questionable if it is possible to renumber IPv6 networks more 405 frequently than with IPv4. Router renumbering protocol [Crawford, 2000] 406 , IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998] 407 can help us renumber the IPv6 network, however, network renumbering 408 itself is not an easy task. If you would like to maintain reachability 409 from the outside world, a site administrator needs to carefully 410 coordinate site renumber. The minimal interval between renumber is 411 restricted by DNS record timeouts, as DNS records will be cached around 412 the world. If the TTL of DNS records are X, the interval between 413 renumber must be longer than 2 * X. If we consider clients/servers that 414 tries to validate addresses using reverse lookups, we also need to care 415 about the relationship between IPv6 address lifetime [Thomson, 1998] and 416 the interval between renumber. At IETF50 ipngwg session, there was a 417 presentation by JINMEI Tatsuya regarding to site renumbering experiment. 418 It is recommend to read through the IETF49 minutes and slides. [XXX 419 Fred Baker had a draft on this - where?] For the network renumbering to 420 be successful, no configuration files should have hardcoded (numeric) IP 421 addresses. It is a very hard requirement to meet. We fail to satisfy 422 this in many of the network renumbering events, and the failure causes a 423 lot of troubles. 425 At this moment there is no mechanism defined for ISPs to renumber 426 downstream customers at will. Even though it may sound interesting for 427 ISPs, it would cause a lot of (social and political) issues in doing so, 428 so the author would say it is rather unrealistic to pursue this route. 429 The only possible candidate, router renumbering protocol [Crawford, 430 2000] does not really fit into the situation. The protocol is defined 431 using IPsec authentication over site-local multicast packets. It would 432 be cumbersome to run router renumbering protocol across multiple 433 administrative domains, as (1) customers will not want to share IPsec 434 authentication key for routers with the upstream ISP, and (2) customer 435 network will be administered as a separate site from the upstream ISP 436 (Even though router renumbering protocol could be used with unicast 437 addresess, it is not realistic to assume that we can maintain the list 438 of IPv6 addresses for all the routers in both customers' and ISPs' 439 networks). 441 A6 was designed to help administators update zone files during network 442 renumbering events. Even with AAAA, zone file modification itself is 443 easy; you can just query-replace the addresses in the zone files. The 444 difficulty of network renumber comes from elsewhere. 446 With AAAA, we need to sign the whole zone again with DNSSEC keys, after 447 renumbering the network. With A6, we need to sign upper bits only with 448 DNSSEC keys. Therefore, A6 will impose less zone signing cost on the 449 event of network renumbering. As seen above, it is questionable if we 450 renumber network that often, so it is questionable if A6 brings us an 451 overall benefit. Note, however, even if we use A6 to facilitate more 452 frequent renumbering and lower signing cost, all glue records has to be 453 installed as non-fragmented A6 records (``A6 0''), and required to be 454 signed again on renumbering events. 456 5. Security consideration 458 There are a couple of security worries mentioned in the above. To give 459 a brief summary: 461 o There will be a higher delay imposed by query/reply roundtrips for 462 fragmented A6 records. This could affect every services that relies 463 upon DNS records. 465 o There is no upper limit defined for the number of A6 fragments for 466 defining an IPv6 address. Malicious parties may try to put a very 467 complex A6 chains and confuse nameservers worldwide. 469 o A6 resolver/nameserver is much harder to implement correctly than AAAA 470 resolver/nameserver. A6 fragment reassembly code needs to take care 471 of bitwise data reassembly, bitwise overwrap checks, and others. From 472 our implementatation experiences, we expect to see a lot of security- 473 issue bugs in the future. 475 o Interaction between DNS record TTL and the DNS query delays leads to 476 non-trivial timeout problem. 478 We would like to go into more details for some of these. 480 5.1. DoS attacks against AAAA synthesis 482 When a DNS server is configured for AAAA synthesis, malicious parties 483 can impose DoS attacks using the interaction between DNS TTL and query 484 delays. The attack can chew CPU time and/or memory, as well as some 485 network bandwidth on a victim nameserver, by the following steps: 487 o A bad guy configures a record with very complex A6 chain, onto some 488 nameservers. (the bad guy has to have controls over the servers). 489 The nameservers can be located anywhere in the world. The A6 chain 490 should have a very low TTL (like 1 or 0 seconds). The attack works 491 better if we have higher delays between the victim nameservers and the 492 nameservers that serve A6 fragments. 494 o The bad guy queries the record using AAAA request, to the victim 495 nameserver. 497 o The victim nameserver will try to reassemble A6 fragments. During the 498 reassembly process, the victim nameserver puts A6 fragments into the 499 local cache. The cached records will expire during the reassembly 500 process. The nameserver will need to query a lot of A6 fragments 501 (more traffic). The server can go into an infinite loop, if it tries 502 to query the expired A6 fragments again. 504 Note, however, this problem could be considered as a problem in 505 recursize resolvers in general (like CNAME and NS chasing); A6 and AAAA 506 synthesis makes the problem more apparent, and more complex to diagnose. 508 To remedy this problem, we have a couple of solutions: 510 (1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the 511 problem goes away. 513 (2) Even if we use A6, do not configure nameservers for AAAA synthesis. 514 Deployment issues with existing IPv6 hosts get much harder. 516 (3) Impose a protocol limitation to the number of A6 fragments. 518 (4) Do not query the expired records in A6 chain again. In other words, 519 implement resolvers that ignore TTL on DNS records. Not sure if it 520 is the right thing to do. 522 6. Conclusion 524 NOTE: the section expresses the impressions of the author. 526 A6/AAAA discussion has been an obstacle for IPv6 deployment, as the 527 deployment of IPv6 NS recodrs have been deferred because of the 528 discussion. The author do not see benefit in keeping both AAAA and A6 529 records, as it imposes more query delays to the clients. So the author 530 believes that we need to pick one of them. 532 Given the unlikeliness of frequent network renumbering, the author 533 believes that the A6's benefit in lower zone signing cost is not 534 significant. The benefit of A6 (in zone signing cost) is much less than 535 the expected complication that will be imposed by A6 operations. 537 >From the above discussions, the author suggests to keep AAAA and 538 deprecate A6 (move A6 document to historic state). The author believes 539 that A6 can cause a lot of problem than the benefits it may have. A6 540 will make IPv6 DNS operation more complicated and vulnerable to attacks. 541 AAAA is proven to work right in our IPv6 network operation since 1996. 542 AAAA has been working just fine in existing IPv6 networks, and the 543 author believes that it will in the coming days. 545 References 547 Thomson, 1995. 548 S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in 549 RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt. 551 Crawford, 2000. 552 M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6 553 Address Aggregation and Renumbering" in RFC2874 (July 2000). 554 ftp://ftp.isi.edu/in-notes/rfc2874.txt. 556 Austein, 2001. 557 R. Austein, "Tradeoffs in DNS support for IPv6" in draft-ietf-dnsext- 558 ipv6-dns-tradeoffs-00.txt (July 2001). work in progress material. 560 Draves, 2001. 561 Richard Draves, "Default Address Selection for IPv6" in draft-ietf- 562 ipngwg-default-addr-select-04.txt (May 2001). work in progress material. 564 Hagino, 2000. 565 Jun-ichiro Hagino and Kazu Yamamoto, "Requirements for IPv6 dialup PPP 566 operation" in draft-itojun-ipv6-dialup-requirement-00.txt (July 2000). 567 work in progress material. 569 Crawford, 2000. 570 Matt Crawford, "Router Renumbering for IPv6" in RFC2894 (August 2000). 571 ftp://ftp.isi.edu/in-notes/rfc2894.txt. 573 Thomson, 1998. 574 S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration" in 575 RFC2462 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2462.txt. 577 Change history 579 none. 581 Acknowledgements 583 The draft was written based on discussions in IETF IPv6 and dnsext 584 working groups, and help from WIDE research group. 586 Author's address 588 Jun-ichiro itojun HAGINO 589 Research Laboratory, Internet Initiative Japan Inc. 590 Takebashi Yasuda Bldg., 591 3-13 Kanda Nishiki-cho, 592 Chiyoda-ku,Tokyo 101-0054, JAPAN 593 Tel: +81-3-5259-6350 594 Fax: +81-3-5259-6351 595 Email: itojun@iijlab.net