idnits 2.17.1 draft-jiang-a6-to-historic-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 26, 2011) is 4506 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1886 (Obsoleted by RFC 3596) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Jiang 2 Internet Draft Huawei Technologies Co., Ltd 3 Intended status: Informational D. Conrad 4 Expires: May 29, 2012 Cloudflare, Inc. 5 B. Carpenter 6 Univ. of Auckland 7 November 26, 2011 9 Moving A6 to Historic Status 10 draft-jiang-a6-to-historic-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute working 19 documents as Internet-Drafts. The list of current Internet-Drafts is 20 at http://datatracker.ietf.org/drafts/current/. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 This Internet-Draft will expire on May 29, 2012. 29 Copyright Notice 31 Copyright (c) 2011 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with respect 39 to this document. Code Components extracted from this document must 40 include Simplified BSD License text as described in Section 4.e of 41 the Trust Legal Provisions and are provided without warranty as 42 described in the Simplified BSD License. 44 Abstract 46 This document provides a summary of issues and discusses the current 47 usage status of A6 DNS records and moves the A6 specifications to 48 Historic status, providing clarity to implementers and operators. 50 Table of Contents 52 1. Introduction & Background .................................... 3 53 2. A6 Issues .................................................... 3 54 2.1. Resolution Latency ...................................... 4 55 2.2. Resolution failure ...................................... 4 56 2.3. Cross administration domains ............................ 4 57 2.4. Difficult Maintenance ................................... 5 58 2.5. Existence of Multiple RR Types for one Purpose is Harmful 5 59 2.6. Higher Security Risks ................................... 5 60 3. Status of A6 current usage ................................... 5 61 3.1. Reasons for Current A6 Usage ............................ 6 62 4. Moving A6 to Historic Status ................................. 6 63 4.1. Impact on Current A6 Usage .............................. 6 64 4.2. Transition phase for current A6 ......................... 6 65 5. Security Considerations ...................................... 7 66 6. IANA Considerations .......................................... 7 67 7. Acknowledgments .............................................. 7 68 8. References ................................................... 7 69 8.1. Normative References .................................... 7 70 8.2. Informative References .................................. 7 71 Author's Addresses .............................................. 8 73 1. Introduction & Background 75 The IETF began the process of standardizing two different DNS 76 protocol enhancements for IPv6 addresses in DNS (Domain Name System) 77 records: AAAA [RFC3596] in 1995 [RFC1886] and A6 [RFC2874] in 2000. 78 Both protocol enhancements reached Proposed Standard status. 80 The existence of multiple ways of representing IPv6 address in the 81 DNS has led to confusion and conflicts about which of these protocol 82 enhancements should be implemented and/or deployed. Having more than 83 one choice of how IPv6 addresses are to be represented within the DNS 84 can be argued to have led to delays in the deployment of IPv6. In 85 2002, "Representing IPv6 Addresses in the DNS" [RFC3363] moved A6 to 86 Experimental status, with an aim to clear up any confusion in this 87 area. [RFC3363] and [RFC3364] compared AAAA and A6, and examined many 88 of the issues in the A6 standard, these issues being summarized in 89 this document. 91 However, after ten years, the Experimental status of A6 has resulted 92 in continued confusion and parallel deployment of both A6 and AAAA, 93 albeit AAAA predominates by a large degree. Even in recent IPv6 94 transition tests and deployments, some providers informally mentioned 95 A6 support as a possible future choice. 97 This document provides a brief summary of the issues related to the 98 use of A6 recprds and discusses the current usage status of A6. Given 99 the implications of A6 on the DNS architecture and the state of A6 100 deployment, this document moves the A6 specifications to Historic 101 status, thereby clarifying that implementers and operators should 102 represent IPv6 addresses in the DNS only by using AAAA records. 104 1.1 Standards Action Taken 106 This document requests the IESG to change the status of RFC 2874 from 107 Experimental to Historic. 109 2. A6 Issues 111 This section summarizes the known issues associated with the use of 112 A6 resource records, including the analyses explored in [RFC3363]. 113 The reader is encouraged to review that document to fully understand 114 the issues relating to A6. 116 2.1. Resolution Latency 118 Resolving an A6 Record chain can involve resolving a series of sub- 119 queries that are likely to be independent of each other. Each of 120 these sub-queries takes a non-negligible amount of time unless the 121 answer already happens to be in the resolver's cache. The worst-case 122 time resolving a N-link chain A6 record would be the sum of the 123 latency resulting from each of the N resolutions. As a result, long 124 A6 chains would be likely to increase user frustration due to 125 excessive waiting times for domain names to resolve. 127 In practice, it is very hard to derive a reasonable timeout handling 128 strategy for the reassembly of all the results from A6 sub-queries. 129 It is proved difficult to decide multiple timeout parameters, 130 including (1) the communication timeout for a single A6 fragment, (2) 131 the communication timeout for the IPv6 address itself (total time 132 needed for reassembly) and (3) the TTL timeout for A6 fragment 133 records. 135 2.2. Resolution Failure 137 The probability of A6 resolution failure during the process of 138 resolving an N-link A6 chain is sum of the probabilities of failure 139 of each sub-query, since each of the queries involved in resolving an 140 A6 chain has a non-zero probability of failure and an A6 resolution 141 cannot complete until all sub-queries have succeeded. 143 Furthermore, the failure may happen at any link among 1~N of a N-Link 144 A6 chain. Therefore, it would take an indeterminate time to return a 145 failure result. 147 2.3. Cross Administrative Domains 149 One of the primary motivations for the A6 RR was to facilitate 150 renumbering and multihoming, where the prefix name field in the A6 RR 151 points to a target that is not only outside the DNS zone containing 152 the A6 RR, but is administered by a different organization entirely. 154 While pointers out of zone are not a problem per se, experience both 155 with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that 156 pointers to other organizations are often not maintained properly, 157 perhaps because they're less amenable to automation than pointers 158 within a single organization would be. 160 2.4. Difficult Maintenance 162 In A6, changes to components of an RR are not isolated from the use 163 of the composite IPv6 address. Any change to a non-128-bit component 164 of an A6 RR may cause change to a large number of IPv6 addresses. The 165 dependence relationship actually makes the maintenance of addresses 166 much more complicated and difficult. Without understanding these 167 complicated relationships, any arbitrary change for a non-128-bit A6 168 RR component may result in undesired consequences. 170 Multiple correlative sub-components of A6 records may have different 171 TTLs, which can make cache maintenance very complicated. 173 2.5. Existence of Multiple RR Types for one Purpose is Harmful 175 If both AAAA and A6 records were widely deployed in the global DNS, 176 it would impose more query delays to the client resolvers. DNS 177 clients have insufficient knowledge to choose between AAAA and A6 178 queries, requiring local policy to determine which record type to 179 query. If local policy dictates parallel queries for both AAAA and A6 180 and if those queries returned different results for any reason, the 181 clients would have no knowledge about which address to choose. 183 2.6. Higher Security Risks 185 The dependency relationships inherent in A6 chains increase security 186 risks. An attacker may successfully attack a single sub-component of 187 an A6 record, which would then influence many query results, and 188 possibly every host on a large site. There is also the danger of 189 unintentionally or maliciously creating a resolution loop - an A6 190 chain may create an infinite loop because an out of zone pointer may 191 point back to another component farther down the A6 chain. 193 3. Current Usage of A6 195 Full support for IPv6 in the global DNS can be argued to have started 196 when the first IPv6 records were associated with root servers in 197 early 2008. 199 One of the major DNS server software packages, BIND9 [BIND], supports 200 both A6 and AAAA and is unique among the major DNS resolvers in that 201 certain versions of the BIND9 resolver will attempt to query for A6 202 records and follow A6 chains. 204 According to published statistics for two root DNS servers (the "K" 205 root server [KROOT] and the "L" root server [LROOT]), there are 206 between 9,000 and 14,000 DNS queries per second on the "K" root 207 server and 13,000 to 19,000 queries per second on the "L" root 208 server. The distributions of those queries by RR type are similar: 209 roughly 60% A queries, 20~25% AAAA queries, and less than 1% A6 210 queries. 212 3.1. Reasons for Current A6 Usage 214 That there is A6 query traffic does not mean that A6 is actually in 215 use; it is likely the result of some recursive servers that issue 216 internally-generated A6 queries when looking up missing name server 217 addresses in addition to issuing A and AAAA queries. 219 BIND versions 9.0 through 9.2 could be configured to make A6 queries 220 and it is possible that some active name servers running those 221 versions have not yet been upgraded. 223 In the late 1990s, A6 was considered to be the future in preference 224 to AAAA [RFC2874]. As a result, A6 queries were tried by default in 225 BINDv9 versions. When it was pointed out that A6 had some fundamental 226 issues (discussed in [A6DISC] with the deprecation codified in RFC 227 3363), A6 was abandoned in favor of AAAA and BINDv9 no longer tried 228 A6 records by default. A6 was removed from the query order in the 229 BIND distribution in 2004 or 2005. 231 Some Linux/glibc versions may have had A6 query implementations in 232 gethostbyname() 8-10 years ago. These operating systems/libraries may 233 not have been replaced or upgraded everywhere yet. 235 4. Moving A6 to Historic Status 237 This document moves the A6 specification to Historic status. This 238 move provides a clear signal to implementers and/or operators that A6 239 should NOT be implemented or deployed. 241 4.1. Impact on Current A6 Usage 243 If A6 were in use and it were to be treated as an 'unknown record' 244 (RFC3597) as discussed below, it might lead to some interoperability 245 issues since resolvers that support A6 are required to do additional 246 section processing for these records on the wire. However, as there 247 are no known production uses of A6, this impact is considered 248 negligible. 250 4.2. Transition phase for current A6 252 Since there is no known A6-only client in production use, the 253 transition phase may not be strictly necessary. However, clients that 254 attempt to resolve A6 before AAAA will suffer a performance penalty. 255 Therefore, we recommend: 257 * Removing A6 handling from all new or updated host stacks; 259 * Recommend removing all existing A6 records; and 261 * All resolver and server implementations return the same response as 262 for any unknown or deprecated RR type for all A6 queries. If an AAAA 263 record exists for the name being resolved, a suitable response would 264 be 'no answers/no error', i.e. the response packet has an answer 265 count of 0 but no error is indicated. 267 5. Security Considerations 269 Eliminating A6 records will eliminate any security exposure related 270 to that RR type, and should introduce no new vulnerabilities. 272 6. IANA Considerations 274 IANA is requested to change the annotation of the A6 RR type from 275 "Experimental" to "Obsolete" in the DNS Parameters registry. 277 7. Acknowledgments 279 The authors would like to thank Ralph Droms, Roy Arends, Edward 280 Lewis, Andreas Gustafsson, Mark Andrews, Jun-ichiro "itojun" Hagino 281 and other members of DNS WGs for valuable contributions. 283 8. References 285 8.1. Normative References 287 [RFC2874] M. Crawford, C. Huitema, "DNS Extensions to Support IPv6 288 Address Aggregation and Renumbering", RFC 2874, July 2000. 290 [RFC3596] S. Thomson, C. Huitema, V. Ksinant, M. Souissi, "DNS 291 Extensions to Support IP Version 6", RFC 3596, October 292 2003. 294 8.2. Informative References 296 [RFC1886] S. Thomson and C. Huitema, "DNS Extensions to Support IP 297 Version 6", RFC 1886, December 1995. 299 [RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain, 300 "Representing Internet Protocol version 6 (IPv6) Addresses 301 in the Domain Name System (DNS)", RFC 3363, August 2002. 303 [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support 304 for Internet Protocol version 6 (IPv6)", RFC 3364, August 305 2002. 307 [A6DISC] J. Hagino, "Comparison of AAAA and A6 (do we really need 308 A6?)", working in progress, 2001. 310 [BIND] http://www.isc.org/software/bind 312 [KROOT] http://k.root-servers.org/ 314 [LROOT] http://dns.icann.org/lroot/ 316 Author's Addresses 318 Sheng Jiang 319 Huawei Technologies Co., Ltd 320 Q14, Huawei Campus 321 No.156 Beiqing Road 322 Hai-Dian District, Beijing 100095 323 P.R. China 324 Email: jiangsheng@huawei.com 326 David Conrad 327 Cloudflare, Inc. 328 665 3rd Street, Suite 207 329 San Francisco CA 94107 330 USA 331 Email: drc@cloudflare.com 333 Brian Carpenter 334 Department of Computer Science 335 University of Auckland 336 PB 92019 337 Auckland, 1142 338 New Zealand 339 Email: brian.e.carpenter@gmail.com