idnits 2.17.1 draft-ietf-dnsext-aaaa-a6-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: ---------------------------------------------------------------------------- ** 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? == 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. ** The abstract seems to contain references ([Crawford,2000], [Thomson,1995]), 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 (May 27, 2001) is 8363 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 410 looks like a reference -- Missing reference section? '1995' on line 36 looks like a reference -- Missing reference section? 'Draves' on line 375 looks like a reference -- Missing reference section? '2000' on line 400 looks like a reference -- Missing reference section? 'Hagino' on line 397 looks like a reference -- Missing reference section? 'Crawford' on line 400 looks like a reference -- Missing reference section? '1998' on line 410 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Jun-ichiro itojun Hagino 2 INTERNET-DRAFT IIJ Research Laboratory 3 Expires: November 27, 2001 May 27, 2001 5 Comparison of AAAA and A6 (do we really need A6?) 6 draft-ietf-dnsext-aaaa-a6-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as ``work in progress.'' 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/1id-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Distribution of this memo is unlimited. 30 The internet-draft will expire in 6 months. The date of expiration will 31 be November 27, 2001. 33 Abstract 35 At this moment, there are two resource record types defined for holding 36 IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6 [Crawford, 37 2000] . AAAA has been used for IPv6 network operation since 1996. 38 Questions arose whether we really need A6 or not, or whether it is 39 really possible to migrate to A6 or not. Some says AAAA is enough and 40 A6 is not necessary. Some says A6 is necessary and AAAA should get 41 deprecated. 43 The draft tries to understand pros and cons between these two record 44 types, and makes suggestions on deployment of IPv6 record type. 46 The draft does not cover the use of bit string label and DNAME resource 47 record (reverse mapping), as it seems that nibble form is well accepted 48 in the community, newer formats have too much deployment costs, thus we 49 see few need/voice that calls for migration. Refer to IETF50 dnsext 50 working group minutes for more details. 52 1. A brief summary of the IPv6 resource record types 54 1.1. AAAA record 56 AAAA resource record is formatted as follows. DNS record type value for 57 AAAA is 28 (assigned by IANA). Note that AAAA record is formatted as a 58 fixed-length data. 60 +------------+ 61 |IPv6 Address| 62 | (16 octets)| 63 +------------+ 65 With AAAA, we can define DNS records for IPv6 address resolution as 66 follows, just like A records for IPv4. 68 $ORIGIN X.EXAMPLE. 69 N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 70 N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 71 N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 73 1.2. A6 record 75 A6 resource record is formatted as follows. DNS record type value for 76 A6 is 38 (assigned by IANA). Note that A6 record is formatted as a 77 variable-length data. 79 +-----------+------------------+-------------------+ 80 |Prefix len.| Address suffix | Prefix name | 81 | (1 octet) | (0..16 octets) | (0..255 octets) | 82 +-----------+------------------+-------------------+ 84 With A6, it is possible to define an IPv6 address by using multiple DNS 85 records. Here is an example taken from RFC2874: 87 $ORIGIN X.EXAMPLE. 88 N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 89 SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 90 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. 91 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. 93 SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. 94 SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET. 96 SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET. 98 A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG. 100 A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG. 102 B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG. 104 C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: 105 D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: 106 E.NET.ALPHA-TLA.ORG. A6 0 2345:000E:: 108 If we translate the above into AAAA records, it will be as follows: 110 $ORIGIN X.EXAMPLE. 111 N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 112 N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 113 N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 115 It is also possible to use A6 records in ``non-fragmented'' manner, like 116 below. 118 $ORIGIN X.EXAMPLE. 119 N A6 0 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 120 N A6 0 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 121 N A6 0 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 123 There is a large design difference between A6 and AAAA. A6 imposes 124 address resolutions tasks more to the resolver side, to reduce the 125 amount of zone file maintenance cost. The complexity is in the resolver 126 side. AAAA asks zone file maintainers to supply the full 128bit IPv6 127 address in one record, and the resolver side can be implemented very 128 simple. 130 2. Deployment status 132 2.1. Name servers/resolvers 134 As of writing, AAAA is deployed pretty widely. BIND4 (since 4.9.4), 135 BIND8, BIND9 and other implementations support AAAA, as both DNS servers 136 and as resolver libraries. On the contrary, the author knows of only 137 one DNS server/resolver implementation that supports A6; BIND9. 139 Almost all of the IPv6-ready operating systems ship with BIND4 or BIND8 140 resolver library. Even for the implementations that use resolver 141 library other than BIND, they only support AAAA. Therefore, they cannot 142 query A6 records (unless aplications gets linked with BIND9 libraries 143 explicitly). 145 2.2. IPv6 network 147 IPv6 network has been deployed widely since 1996. Though many of the 148 participants consider it to be experimental, commercial IPv6 services 149 has been deployed since around 1999, especially in asian countries. 151 2.3. DNS database 153 There are no IPv6-reachable root DNS servers, partly because we have 154 both AAAA and A6, and we are not decided about which is the one we would 155 like to really deploy (so we cannot put IPv6 root NS records). The lack 156 of IPv6-reachable root DNS servers is now preventing IPv6-only or 157 IPv4/v6 dual stack network operations. 159 At this moment, very small number of ccTLD registries accept 160 registeration requests for IPv6 glue records. Many of the ccTLDs and 161 gTLDs do not take IPv6 glue records, partly because of the lack of 162 consensus between AAAA and A6. Again, the lack of IPv6 glue records is 163 causing pain in IPv6-ready network operations. For example, JP ccTLD 164 accepts IPv6 glue records and registers them as AAAA records. IPv6 NS 165 records (with AAAA) works flawlessly from our experiences. For example, 166 try the following commands to see how JP ccTLD registers IPv6 glue 167 records (``/e'' is for English-language output): 169 % whois -h whois.nic.ad.jp wide.ad.jp/e 170 % whois -h whois.nic.ad.jp ns1.v6.wide.ad.jp/e 172 3. Deploying DNS records 174 At this moment, the following four strategies are proposed for the 175 deployment of IPv6 DNS resource record; AAAA, fragmented A6 records, 176 non-fragmented A6 records, and AAAA synthesis. 178 3.1. AAAA records 180 AAAA records have been used on IPv6 network (also known as 6bone) since 181 it has started in 1996 and has been working just fine ever since. AAAA 182 record is a straight extension of A records; it needs a single query- 183 response roundtrip to resolve a name into an IPv6 address. 185 A6 was proposed to add network renumbering friendliness to AAAA. With 186 AAAA, a full 128bit IPv6 address needs to be supplied in a DNS resource 187 record. Therefore, in the event of network renumber, administrators 188 need to update the whole DNS zone file with the new IPv6 address 189 prefixes. We will discuss the issues with renumbering in a dedicated 190 section. 192 3.2. Fragmented A6 records 194 If we are to use fragmented A6s (128bit splitted into multiple A6s), we 195 have a lot of issues/worries. 197 If we are to resolve IPv6 addresses using fragmented A6 records, we need 198 to query DNS multiple times to resolve a single DNS name into an IPv6 199 address. Since there has been no DNS record types that require multiple 200 queries for resolution of the address itself, we have very little 201 experience on such resource records. 203 There will be more delays in name resolution compared to queries to 204 A/AAAA records. If we define a record with more number of fragments, 205 there will be more query roundtrips. There are only few possibilities 206 to query fragments in parallel. In the above example, we can resolve 207 A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others. 209 If the DNS record TTL is smaller than the communication delays between 210 the querier and the DNS servers, the querier will not be able to 211 reassemble a complete IPv6 record. With the following records, you 212 cannot reassemble an IPv6 address if the delay is larger than 1 second. 213 By the time you get the topmost 64 bits in the address, the lowermost 64 214 bits get invalidated. If the querier tries to query lowermost 64 bits 215 again, the querier can go into an infinite loop (see the section on 216 security considration). [BIND 9.2.0snap: resolver does not go into 217 infinite loop, meaning that BIND 9.2.0snap resolver does not really 218 honor DNS record TTL during A6 reassembly] 220 ; resolver can go into an infinite loop if RTT > 1 second 221 $ORIGIN X.EXAMPLE. 222 $TTL 1 223 N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 224 SUBNET-1.IP6 A6 0 2345:00C1:CA11:1:: 226 Some says that caches will avoid querying fragmented A6s again and 227 again. However, most of the library resolver implementations do not 228 cache anything. The traffic between library resolver and the first-hop 229 nameserver will not be decreased by the cached records. The TTL problem 230 (see above) is unavoidable for the library resolver without cache. [XXX 231 will they interpret TTL field? BIND8 resolver does not] 233 If some of the fragments are DNSSEC-signed and some are not, how should 234 we treat that address? RFC2874 section 6 briefly talks about it, not 235 sure if complete answer is given. 237 It is much harder to implement A6 fragment reassemble code, than to 238 implement AAAA record resolver. AAAA record resolver can be implemented 239 as a straight extension of A record resolver. 241 o It is much harder to design timeout handling for the A6 reassembly. 242 There would be multiple timeout parameters, including (1) communcation 243 timeout for a single A6 fragment, (2) communcation timeout for the 244 IPv6 address itself (total time needed for reassembly) and (3) TTL 245 timeout for A6 fragment records. 247 o In the case of library resolver implementation, it is harder to deal 248 with exceptions (signals in UNIX case) for the large code fragment for 249 resolvers. 251 o When A6 prefix length field is not multiple of 8, address suffix 252 portion needs to be shifted bitwise while A6 fragments are 253 reassembled. Also, resolver implementations must be careful about 254 overwraps of the bits. From our implementatation experiences, the 255 logic gets very complex and we (unfortunately) expect to see a lot of 256 security-critical bugs in the future. 258 In RFC2874, a suggestion is made to use limited number of fragments per 259 an IPv6 address. However, there is no protocol limitation defined. The 260 lack makes it easier for malicious parties to impose DoS attacks using 261 lots of A6 fragments (see the section on security consideration). [BIND 262 9.2.0snap: The implementation limits the number of fragments to be 263 smaller than 16; It is not a protocol limitation but an implementation 264 choice. Not sure if it is the right choice or not] 266 With fragmented A6 records, in multi-prefix network configuration, it is 267 not possible for us to limit the address on the DNS database to the 268 specific set of records, like for load distribution purposes. Consider 269 the following example. Even if we would like to advertise only 270 2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible 271 to do so. It becomes mandatory for us to define the whole IPv6 address 272 by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6 273 (renumber friendliness) goes away. 275 ; with the following record we would advertise both records 276 $ORIGIN X.EXAMPLE. 277 N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 278 M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6 279 SUBNET-1.IP6 A6 0 2345:00C1:CA11:1:: 280 A6 0 2345:00D2:DA11:1:: 282 ; we need to do the following, jeopardizing renumbering 283 ; friendliness for N.X.EXAMPLE 284 $ORIGIN X.EXAMPLE. 285 N A6 0 2345:00C1:CA11:1:1234:5678:9ABC:DEF0 286 M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6 287 SUBNET-1.IP6 A6 0 2345:00C1:CA11:1:: 288 A6 0 2345:00D2:DA11:1:: 290 A6 resource record type and A6 fragment/reassembly were introduced to 291 help administrators on network renumber. When network gets renumbered, 292 the administrator needs to update A6 fragment for the higher address 293 bits (prefixes) only. Again, we will discuss the issues with 294 renumbering in a dedicated section. 296 3.3. Non-fragmented A6 records 298 There are proposals to use non-fragmented A6 records in most of the 299 places, like ``A6 0 <128bit>'', so that we would be able to switch to 300 fragmented A6 records when we find a need for A6. 302 >From the packet format point of view, the approach has no benefit 303 against AAAA. Rather, there is a one-byte overhead to every 304 (unfragmented) A6 record compared to an AAAA record. 306 If the nameserver/resolver programs hardcode A6 processing to handle no 307 fragments, there will be no future possibility for us to introduce 308 fragmented A6 records. When there is no need for A6 reassembly, there 309 will be no code deployment, and even if the reassembly code gets 310 deployed they will not be tested enough. The author believes that the 311 ``prepare for the future, use non-fragmented A6'' argument is not 312 worthwhile. 314 In the event of renumbering, non-fragmented A6 record has the same 315 property as AAAA (the whole zone file has to be updated). 317 3.4. AAAA synthesis (A6 and AAAA hybrid approach) 319 At this moment, end hosts support AAAA records only. Some people would 320 like to see A6 deployment in DNS databases even with the lack of end 321 hosts support. To workaround the deployment issues of A6, the following 322 approach is proposed in IETF50 dnsext working group slot. It is called 323 ``AAAA synthesis'': 325 o Deploy A6 DNS records worldwide. The proposal was not specific about 326 whether we would deploy fragmented A6 records, or non-fragmented A6 327 records (``A6 0''). 329 o When a host queries AAAA record to a DNS server, the DNS server 330 queries A6 fragments, reassemble it, and respond with an AAAA record. 332 The approach needs to be diagnosed/specified in far more detail. For 333 example, the following questions need to be answered: 335 o What is the DNS error code against AAAA querier, if the A6 reassembly 336 fails? 338 o What TTL should the synthesized AAAA record have? [BIND 9.2.0snap 339 uses TTL=0] 341 o Which nameserver should synthesize the AAAA record, in the DNS 342 recursize query chain? Is the synthesis mandatory for every DNS 343 server implementation? 345 o What should we do if the A6 reassembly takes too much time? 347 o What should we do about DNSSEC signatures? 349 o What if the resolver wants no synthesis? Do we want to have a flag 350 bit in DNS packet, to enable/disable AAAA synthesis? 352 o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query 353 timeouts, and other timeout parameters? 355 The approach seems to be vulnerable against DoS attacks, because the 356 nameserver reassembles A6 fragments on behalf of the AAAA querier. See 357 security consideration section for more details. 359 3.5. Issues in keeping both AAAA and A6 361 If we are to keep both AAAA and A6 records onto the worldwide DNS 362 database, it would impose more query delays to the client resolvers. 363 Suppose we have a dual-stack host implementation. If they need to 364 resolve a name into addresses, the node would need to query in the 365 following order (in the order which RFC2874 suggests): 367 o Query A6 records, and get full IPv6 addresses by chasing and 368 reassembling A6 fragment chain. 370 o Query AAAA records. 372 o Query A records. 374 o Sort the result based on destination address ordering rule. An 375 example of the ordering rule is presented as a draft [Draves, 2000] . 377 o Contact the destination addresses in sequence. 379 The ordering imposes additional delays to the resolvers. The above 380 ordering would be necessary for all approaches that use A6, as there are 381 existing AAAA records in the world. 383 4. Network renumbering 385 Some says that there will be more frequent renumbers in IPv6 network 386 operation, and A6 is necessary to reduce the zone modification cost as 387 well as zone signing costs on renumber operation. 389 It is not clear if we really want to renumber that frequently. With 390 IPv6, it should be easier for ISPs to assign addresses statically to the 391 downstream customers, rather than dynamically like we do in IPv4 dialup 392 connectivity today. If ISPs do assign static IPv6 address block to the 393 customers, there is no need to renumber customer network that frequently 394 (unless the customer decides to switch the upstream ISPs that often). 395 NOTE: Roaming dialup users, like those who carry laptop computers 396 worldwide, seems to have a different issue from stationary dialup users. 397 See [Hagino, 2000] for more discussions. 399 It is questionable if it is possible to renumber IPv6 networks more 400 frequently than with IPv4. Router renumbering protocol [Crawford, 2000] 401 , IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998] 402 can help us renumber the IPv6 network, however, network renumbering 403 itself is not an easy task. If you would like to maintain reachability 404 from the outside world, a site administrator needs to carefully 405 coordinate site renumber. The minimal interval between renumber is 406 restricted by DNS record timeouts, as DNS records will be cached around 407 the world. If the TTL of DNS records are X, the interval between 408 renumber must be longer than 2 * X. If we consider clients/servers that 409 tries to validate addresses using reverse lookups, we also need to care 410 about the relationship between IPv6 address lifetime [Thomson, 1998] and 411 the interval between renumber. At IETF50 ipngwg session, there was a 412 presentation by JINMEI Tatsuya regarding to site renumbering experiment. 413 It is recommend to read through the IETF49 minutes and slides. [XXX 414 Fred Baker had a draft on this - where?] For the network renumbering to 415 be successful, no configuration files should have hardcoded (numeric) IP 416 addresses. It is a very hard requrement to meet. We fail to satisfy 417 this in many of the network renumbering events, and the failure causes a 418 lot of troubles. 420 At this moment there is no mechanism defined for ISPs to renumber 421 downstream customers at will. Router renumbering protocol [Crawford, 422 2000] is defined only for a single administrative domain (customers will 423 not want to share IPsec authentication key for routers, with the 424 upstream ISP). Even though it may sound interesting for ISPs, it would 425 cause a lot of (social and political) issues in doing so, so the author 426 would say it is rather unrealistic to pursue this route. 428 A6 was designed to help administators update zone files during network 429 renumbering events. Even with AAAA, zone file modification itself is 430 easy; you can just query-replace the addresses in the zone files. The 431 difficulty of network renumber comes from elsewhere. 433 With AAAA, we need to sign the whole zone again with DNSSEC keys, after 434 renumbering the network. With A6, we need to sign upper bits only with 435 DNSSEC keys. Therefore, A6 will impose less zone signing cost on the 436 event of network renumbering. As seen above, it is questionable if we 437 renumber network that often, so it is questionable if A6 brings us an 438 overall benefit. 440 5. Security consideration 442 There are a couple of security worries mentioned in the above. To give 443 a brief summary: 445 o There will be a higher delay imposed by query/reply roundtrips for 446 fragmented A6 records. This could affect every services that relies 447 upon DNS records. 449 o There is no upper limit defined for the number of A6 fragments for 450 defining an IPv6 address. Malicious parties may try to put a very 451 complex A6 chains and confuse nameservers worldwide. 453 o A6 resolver/nameserver is much harder to implement correctly than AAAA 454 resolver/nameserver. A6 fragment reassembly code needs to take care 455 of bitwise data reassembly, bitwise overwrap checks, and others. From 456 our implementatation experiences, we expect to see a lot of security- 457 issue bugs in the future. 459 o Interaction between DNS record TTL and the DNS query delays leads to 460 non-trivial timeout problem. 462 We would like to go into more details for some of these. 464 5.1. DoS attacks against AAAA synthesis 466 When a DNS server is configured for AAAA synthesis, malicious parties 467 can impose DoS attacks using the interaction between DNS TTL and query 468 delays. The attack can chew CPU time and/or memory, as well as some 469 network bandwidth on a victim nameserver, by the following steps: 471 o Bad guy configures a record with very complex A6 chain, onto some 472 nameservers. (bad guy has to have controls over the servers). The 473 nameservers can be located anywhere in the world. The A6 chain should 474 have a very low TTL (like 1 or 0 seconds). The attack works better if 475 we have higher delays between the victim nameservers and the 476 nameservers that serve A6 fragments. 478 o Bad guy queries the record using AAAA request, to the victim 479 nameserver. 481 o The victim nameserver will try to reassemble A6 fragments. During the 482 reassembly process, the victim nameserver puts A6 fragments into the 483 local cache. The cached records will expire during the reassembly 484 process. The nameserver will need to query a lot of A6 fragments 485 (more traffic). The server can go into an infinite loop, if it tries 486 to query the expired A6 fragments again. 488 To remedy this problem, we have a couple of solutions: 490 (1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the 491 problem goes away. 493 (2) Even if we use A6, do not configure nameservers for AAAA synthesis. 494 Deployment issues with existing IPv6 hosts get much harder. 496 (3) Impose a protocol limitation to the number of A6 fragments. 498 (4) Do not query the expired records in A6 chain again. In other words, 499 implement resolvers that ignore TTL on DNS records. Not sure if it 500 is the right thing to do. 502 6. Conclusion 504 NOTE: the section expresses the impressions of the author. 506 A6/AAAA discussion has been an obstacle for IPv6 deployment, as the 507 deployment of IPv6 NS recodrs have been deferred because of the 508 discussion. The author do not see benefit in keeping both AAAA and A6 509 records, as it imposes more query delays to the clients. So the author 510 believes that we need to pick one of them. 512 Given the unlikeliness of frequent network renumbering, the author 513 believes that the A6's benefit in lower zone signing cost is not 514 significant. The benefit of A6 (in zone signing cost) is much less than 515 the expected complication that will be imposed by A6 operations. 517 >From the above discussions, the author suggests to keep AAAA and 518 deprecate A6. The author believes that A6 can cause a lot of problem 519 than the benefits it may have. A6 will make IPv6 DNS operation more 520 complicated and vulnerable to attacks. AAAA is proven to work right in 521 our IPv6 network operation since 1996. AAAA has been working just fine 522 in existing IPv6 networks, and the author believes that it will in the 523 coming days. 525 References 527 Thomson, 1995. 528 S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in 529 RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt. 531 Crawford, 2000. 532 M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6 533 Address Aggregation and Renumbering" in RFC2874 (July 2000). 534 ftp://ftp.isi.edu/in-notes/rfc2874.txt. 536 Draves, 2000. 537 Richard Draves, "Default Address Selection for IPv6," Internet Draft 538 (November 2000). work in progress material. 540 Hagino, 2000. 541 Jun-ichiro Hagino and Kazu Yamamoto, "Requirements for IPv6 dialup PPP 542 operation" in draft-itojun-ipv6-dialup-requirement-00.txt (July 2000). 543 work in progress material. 545 Crawford, 2000. 546 Matt Crawford, "Router Renumbering for IPv6" in RFC2894 (August 2000). 548 ftp://ftp.isi.edu/in-notes/rfc2894.txt. 550 Thomson, 1998. 551 S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration" in 552 RFC2462 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2462.txt. 554 Change history 556 none. 558 Acknowledgements 560 The draft was written based on discussions in IETF IPv6 and dnsext 561 working groups, and help from WIDE research group. 563 Author's address 565 Jun-ichiro itojun HAGINO 566 Research Laboratory, Internet Initiative Japan Inc. 567 Takebashi Yasuda Bldg., 568 3-13 Kanda Nishiki-cho, 569 Chiyoda-ku,Tokyo 101-0054, JAPAN 570 Tel: +81-3-5259-6350 571 Fax: +81-3-5259-6351 572 Email: itojun@iijlab.net