summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6563.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6563.txt')
-rw-r--r--doc/rfc/rfc6563.txt451
1 files changed, 451 insertions, 0 deletions
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]
+