doc: Add RFC documents

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]
+