Moving A6 to Historic Status
RFC 6563

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]