From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6563.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc6563.txt (limited to 'doc/rfc/rfc6563.txt') diff --git a/doc/rfc/rfc6563.txt b/doc/rfc/rfc6563.txt new file mode 100644 index 0000000..ca1543f --- /dev/null +++ b/doc/rfc/rfc6563.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Jiang +Request for Comments: 6563 Huawei Technologies Co., Ltd +Category: Informational D. Conrad +ISSN: 2070-1721 Cloudflare, Inc. + B. Carpenter + Univ. of Auckland + March 2012 + + + Moving A6 to Historic Status + +Abstract + + This document provides a summary of issues related to the use of A6 + records, discusses the current status, and moves RFC 2874 to Historic + status, providing clarity to implementers and operators. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6563. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Jiang, et al. Informational [Page 1] + +RFC 6563 Moving A6 to Historic Status March 2012 + + +Table of Contents + + 1. Introduction and Background .....................................2 + 1.1. Standards Action Taken .....................................3 + 2. A6 Issues .......................................................3 + 2.1. Resolution Latency .........................................3 + 2.2. Resolution Failure .........................................3 + 2.3. Cross Administrative Domains ...............................4 + 2.4. Difficult Maintenance ......................................4 + 2.5. Existence of Multiple RR Types for One Purpose is Harmful ..4 + 2.6. Higher Security Risks ......................................4 + 3. Current Usage of A6 .............................................5 + 3.1. Reasons for Current A6 Usage ...............................5 + 4. Moving A6 to Historic Status ....................................6 + 4.1. Impact on Current A6 Usage .................................6 + 4.2. Transition Phase for Current A6 Usage ......................6 + 5. Security Considerations .........................................6 + 6. IANA Considerations .............................................6 + 7. Acknowledgments .................................................6 + 8. References ......................................................7 + 8.1. Normative References .......................................7 + 8.2. Informative References .....................................7 + +1. Introduction and Background + + The IETF began standardizing two different DNS protocol enhancements + for IPv6 addresses in DNS records: AAAA was specified in 1995 as a + Proposed Standard [RFC1886] and later in 2003 as a Draft Standard + [RFC3596], and A6 appeared in 2000 as a Proposed Standard [RFC2874]. + + The existence of multiple ways to represent an IPv6 address in the + DNS has led to confusion and conflicts about which of these protocol + enhancements should be implemented and/or deployed. Having more than + one choice of how IPv6 addresses are to be represented within the DNS + can be argued to have led to delays in the deployment of IPv6. In + 2002, "Representing Internet Protocol version 6 (IPv6) Addresses in + the Domain Name System (DNS)" [RFC3363] moved A6 to Experimental + status, with an aim of clearing up any confusion in this area. + [RFC3363] and [RFC3364] compared AAAA and A6, and examined many of + the issues in the A6 standard; these issues are summarized in this + document. + + After ten years, the Experimental status of A6 continues to result in + confusion and parallel deployment of both A6 and AAAA, albeit AAAA + predominates by a large degree. In recent IPv6 transition tests and + deployments, some providers informally mentioned A6 support as a + possible future choice. + + + + +Jiang, et al. Informational [Page 2] + +RFC 6563 Moving A6 to Historic Status March 2012 + + + This document provides a brief summary of the issues related to the + use of A6 records and discusses the current usage status of A6. + Given the implications of A6 on the DNS architecture and the state of + A6 deployment, this document moves RFC 2874 [RFC2874] to Historic + status, thereby clarifying that implementers and operators should + represent IPv6 addresses in the DNS by using AAAA records only. + +1.1. Standards Action Taken + + Per this document, the status of RFC 2874 has been changed from + Experimental to Historic. + +2. A6 Issues + + This section summarizes the known issues associated with the use of + A6 resource records (RRs), including the analyses explored in + [RFC3363]. The reader is encouraged to review that document to fully + understand the issues relating to A6. + +2.1. Resolution Latency + + Resolving an A6 record chain can involve resolving a series of + subqueries that are likely to be independent of each other. Each of + these subqueries takes a non-negligible amount of time unless the + answer already happens to be in the resolver's cache. In the worst- + case scenario, the time spent resolving an N-link chain A6 record + would be the sum of the latency resulting from each of the N + resolutions. As a result, long A6 chains would likely increase user + frustration due to an excessive wait time for domain names to + resolve. + + In practice, it is very hard to derive a reasonable timeout-handling + strategy for the reassembly of all the results from A6 subqueries. + It has proved difficult to decide multiple timeout parameters, + including: (1) the communication timeout for a single A6 fragment, + (2) the communication timeout for the IPv6 address itself (total time + needed for reassembly), and (3) the Time to Live (TTL) timeout for A6 + fragment records. + +2.2. Resolution Failure + + The probability of A6 resolution failure during the process of + resolving an N-link A6 chain is the sum of the probabilities of + failure of each subquery, since each of the queries involved in + resolving an A6 chain has a nonzero probability of failure, and an A6 + resolution cannot complete until all subqueries have succeeded. + + + + + +Jiang, et al. Informational [Page 3] + +RFC 6563 Moving A6 to Historic Status March 2012 + + + Furthermore, the failure may happen at any link among 1~N of an N- + Link A6 chain. Therefore, it would take an indeterminate time to + return a failure result. + +2.3. Cross Administrative Domains + + One of the primary motivations for the A6 RR is to facilitate + renumbering and multihoming, where the prefix name field in the A6 RR + points to a target that is not only outside the DNS zone containing + the A6 RR, but is administered by a different organization entirely. + + While pointers out-of-zone are not a problem per se, experience both + with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that + pointers to other organizations are often not maintained properly, + perhaps because they're less amenable to automation than pointers + within a single organization would be. + +2.4. Difficult Maintenance + + In A6, changes to components of an RR are not isolated from the use + of the composite IPv6 address. Any change to a non-128-bit component + of an A6 RR may cause change to a large number of IPv6 addresses. + The relationship dependency actually makes the maintenance of + addresses much more complicated and difficult. Without understanding + these complicated relationships, any arbitrary change for a + non-128-bit A6 RR component may result in undesired consequences. + + Multiple correlative subcomponents of A6 records may have different + TTLs, which can make cache maintenance very complicated. + +2.5. Existence of Multiple RR Types for One Purpose Is Harmful + + If both AAAA and A6 records were widely deployed in the global DNS, + it would impose more query delays to the client resolvers. DNS + clients have insufficient knowledge to choose between AAAA and A6 + queries, requiring local policy to determine which record type to + query. If local policy dictates parallel queries for both AAAA and + A6 records, and if those queries returned different results for any + reason, the clients would have no knowledge about which address to + choose. + +2.6. Higher Security Risks + + The dependency relationships inherent in A6 chains increase security + risks. An attacker may successfully attack a single subcomponent of + an A6 record, which would then influence many query results, and + possibly every host on a large site. There is also the danger of + unintentionally or maliciously creating a resolution loop -- an A6 + + + +Jiang, et al. Informational [Page 4] + +RFC 6563 Moving A6 to Historic Status March 2012 + + + chain may create an infinite loop because an out of zone pointer may + point back to another component farther down the A6 chain. + +3. Current Usage of A6 + + Full support for IPv6 in the global DNS can be argued to have started + when the first IPv6 records were associated with root servers in + early 2008. + + One of the major DNS server software packages, BIND9 [BIND], supports + both A6 and AAAA, and is unique among the major DNS resolvers in that + certain versions of the BIND9 resolver will attempt to query for A6 + records and follow A6 chains. + + According to published statistics for two root DNS servers (the "K" + root server [KROOT] and the "L" root server [LROOT]), there are + between 9,000 and 14,000 DNS queries per second on the "K" root + server and between 13,000 to 19,000 queries per second on the "L" + root server. The distributions of those queries by RR type are + similar: roughly 60% A queries, 20~25% AAAA queries, and less than 1% + A6 queries. + +3.1. Reasons for Current A6 Usage + + That there is A6 query traffic does not mean that A6 is actually in + use; it is likely the result of some recursive servers that issue + internally generated A6 queries when looking up missing name server + addresses, in addition to issuing A and AAAA queries. + + BIND versions 9.0 through 9.2 could be configured to make A6 queries, + and it is possible that some active name servers running those + versions have not yet been upgraded. + + In the late 1990s, A6 was considered to be the future in preference + to AAAA [RFC2874]. As a result, A6 queries were tried by default in + BINDv9 versions. When it was pointed out that A6 had some + fundamental issues (discussed in [A6DISC] with the deprecation + codified in RFC 3363), A6 was abandoned in favor of AAAA and BINDv9 + no longer tried A6 records by default. A6 was removed from the query + order in the BIND distribution in 2004 or 2005. + + Some Linux/glibc versions may have had A6 query implementations in + gethostbyname() 8-10 years ago. These operating systems/libraries + may not have been replaced or upgraded everywhere yet. + + + + + + + +Jiang, et al. Informational [Page 5] + +RFC 6563 Moving A6 to Historic Status March 2012 + + +4. Moving A6 to Historic Status + + This document moves the A6 specification to Historic status. This + move provides a clear signal to implementers and/or operators that A6 + should NOT be implemented or deployed. + +4.1. Impact on Current A6 Usage + + If A6 were in use and it were to be treated as an 'unknown record' + (RFC3597) as discussed below, it might lead to some interoperability + issues since resolvers that support A6 are required to do additional + section processing for these records on the wire. However, as there + are no known production uses of A6, the impact is considered + negligible. + +4.2. Transition Phase for Current A6 Usage + + Since there is no known A6-only client in production use, the + transition phase may not be strictly necessary. However, clients + that attempt to resolve A6 before AAAA will suffer a performance + penalty. Therefore, we recommend that: + + * A6 handling from all new or updated host stacks be removed; + + * All existing A6 records be removed; and, + + * All resolver and server implementations to return the same + response as for any unknown or deprecated RR type for all A6 + queries. If a AAAA record exists for the name being resolved, + a suitable response would be 'no answers/no error', i.e., the + response packet has an answer count of 0 but no error is + indicated. + +5. Security Considerations + + Removing A6 records will eliminate any security exposure related to + that RR type, and should introduce no new vulnerabilities. + +6. IANA Considerations + + IANA has updated the annotation of the A6 RR type (code 38) from + "Experimental" to "Obsolete" in the DNS Parameters registry. + +7. Acknowledgments + + The authors would like to thank Ralph Droms, Roy Arends, Edward + Lewis, Andreas Gustafsson, Mark Andrews, Jun-ichiro "itojun" Hagino, + and other members of DNS WGs for valuable contributions. + + + +Jiang, et al. Informational [Page 6] + +RFC 6563 Moving A6 to Historic Status March 2012 + + +8. References + +8.1. Normative References + + [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support + IPv6 Address Aggregation and Renumbering", RFC 2874, July + 2000. + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October + 2003. + +8.2. Informative References + + [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP + version 6", RFC 1886, December 1995. + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. + + [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support + for Internet Protocol version 6 (IPv6)", RFC 3364, August + 2002. + + [A6DISC] Hagino, J., "Comparison of AAAA and A6 (do we really need + A6?)", (Work In Progress), July 2001. + + [BIND] "Internet Systems Consortium", + http://www.isc.org/software/bind. + + [KROOT] "RIPE Network Coordination Centre", http://k.root- + servers.org/. + + [LROOT] "ICANN DNS Operations", http://dns.icann.org/lroot/ + + + + + + + + + + + + + + + +Jiang, et al. Informational [Page 7] + +RFC 6563 Moving A6 to Historic Status March 2012 + + +Author's Addresses + + Sheng Jiang + Huawei Technologies Co., Ltd + Q14, Huawei Campus + No.156 Beiqing Road + Hai-Dian District, Beijing 100095 + P.R. China + EMail: jiangsheng@huawei.com + + David Conrad + Cloudflare, Inc. + 665 3rd Street, Suite 207 + San Francisco CA 94107 + USA + EMail: drc@cloudflare.com + + Brian Carpenter + Department of Computer Science + University of Auckland + PB 92019 + Auckland, 1142 + New Zealand + EMail: brian.e.carpenter@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jiang, et al. Informational [Page 8] + -- cgit v1.2.3