1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
|
<pre>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
<span class="h1">Moving A6 to Historic Status</span>
Abstract
This document provides a summary of issues related to the use of A6
records, discusses the current status, and moves <a href="./rfc2874">RFC 2874</a> 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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6563">http://www.rfc-editor.org/info/rfc6563</a>.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Jiang, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6563">RFC 6563</a> Moving A6 to Historic Status March 2012</span>
Table of Contents
<a href="#section-1">1</a>. Introduction and Background .....................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Standards Action Taken .....................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. A6 Issues .......................................................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Resolution Latency .........................................<a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Resolution Failure .........................................<a href="#page-3">3</a>
<a href="#section-2.3">2.3</a>. Cross Administrative Domains ...............................<a href="#page-4">4</a>
<a href="#section-2.4">2.4</a>. Difficult Maintenance ......................................<a href="#page-4">4</a>
<a href="#section-2.5">2.5</a>. Existence of Multiple RR Types for One Purpose is Harmful ..4
<a href="#section-2.6">2.6</a>. Higher Security Risks ......................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Current Usage of A6 .............................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Reasons for Current A6 Usage ...............................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Moving A6 to Historic Status ....................................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Impact on Current A6 Usage .................................<a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. Transition Phase for Current A6 Usage ......................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-6">6</a>
<a href="#section-6">6</a>. IANA Considerations .............................................<a href="#page-6">6</a>
<a href="#section-7">7</a>. Acknowledgments .................................................<a href="#page-6">6</a>
<a href="#section-8">8</a>. References ......................................................<a href="#page-7">7</a>
<a href="#section-8.1">8.1</a>. Normative References .......................................<a href="#page-7">7</a>
<a href="#section-8.2">8.2</a>. Informative References .....................................<a href="#page-7">7</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction and Background</span>
The IETF began standardizing two different DNS protocol enhancements
for IPv6 addresses in DNS records: AAAA was specified in 1995 as a
Proposed Standard [<a href="./rfc1886" title=""DNS Extensions to support IP version 6"">RFC1886</a>] and later in 2003 as a Draft Standard
[<a href="./rfc3596" title=""DNS Extensions to Support IP Version 6"">RFC3596</a>], and A6 appeared in 2000 as a Proposed Standard [<a href="./rfc2874" title=""DNS Extensions to Support IPv6 Address Aggregation and Renumbering"">RFC2874</a>].
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)" [<a href="./rfc3363" title=""Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)"">RFC3363</a>] moved A6 to Experimental
status, with an aim of clearing up any confusion in this area.
[<a href="./rfc3363" title=""Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)"">RFC3363</a>] and [<a href="./rfc3364" title=""Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)"">RFC3364</a>] 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.
<span class="grey">Jiang, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6563">RFC 6563</a> Moving A6 to Historic Status March 2012</span>
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 <a href="./rfc2874">RFC 2874</a> [<a href="./rfc2874" title=""DNS Extensions to Support IPv6 Address Aggregation and Renumbering"">RFC2874</a>] to Historic
status, thereby clarifying that implementers and operators should
represent IPv6 addresses in the DNS by using AAAA records only.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Standards Action Taken</span>
Per this document, the status of <a href="./rfc2874">RFC 2874</a> has been changed from
Experimental to Historic.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. A6 Issues</span>
This section summarizes the known issues associated with the use of
A6 resource records (RRs), including the analyses explored in
[<a href="./rfc3363" title=""Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)"">RFC3363</a>]. The reader is encouraged to review that document to fully
understand the issues relating to A6.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Resolution Latency</span>
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.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Resolution Failure</span>
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.
<span class="grey">Jiang, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6563">RFC 6563</a> Moving A6 to Historic Status March 2012</span>
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.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Cross Administrative Domains</span>
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.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Difficult Maintenance</span>
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.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Existence of Multiple RR Types for One Purpose Is Harmful</span>
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.
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Higher Security Risks</span>
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
<span class="grey">Jiang, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6563">RFC 6563</a> Moving A6 to Historic Status March 2012</span>
chain may create an infinite loop because an out of zone pointer may
point back to another component farther down the A6 chain.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Current Usage of A6</span>
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 [<a href="#ref-BIND" title=""Internet Systems Consortium"">BIND</a>], 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 [<a href="#ref-KROOT" title=""RIPE Network Coordination Centre"">KROOT</a>] and the "L" root server [<a href="#ref-LROOT" title=""ICANN DNS Operations"">LROOT</a>]), 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.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Reasons for Current A6 Usage</span>
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 [<a href="./rfc2874" title=""DNS Extensions to Support IPv6 Address Aggregation and Renumbering"">RFC2874</a>]. 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 [<a href="#ref-A6DISC" title=""Comparison of AAAA and A6 (do we really need A6?)"">A6DISC</a>] with the deprecation
codified in <a href="./rfc3363">RFC 3363</a>), 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.
<span class="grey">Jiang, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6563">RFC 6563</a> Moving A6 to Historic Status March 2012</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Moving A6 to Historic Status</span>
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.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Impact on Current A6 Usage</span>
If A6 were in use and it were to be treated as an 'unknown record'
(<a href="./rfc3597">RFC3597</a>) 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.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Transition Phase for Current A6 Usage</span>
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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
Removing A6 records will eliminate any security exposure related to
that RR type, and should introduce no new vulnerabilities.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
IANA has updated the annotation of the A6 RR type (code 38) from
"Experimental" to "Obsolete" in the DNS Parameters registry.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgments</span>
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.
<span class="grey">Jiang, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6563">RFC 6563</a> Moving A6 to Historic Status March 2012</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2874">RFC2874</a>] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", <a href="./rfc2874">RFC 2874</a>, July
2000.
[<a id="ref-RFC3596">RFC3596</a>] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
Extensions to Support IP Version 6", <a href="./rfc3596">RFC 3596</a>, October
2003.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC1886">RFC1886</a>] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6", <a href="./rfc1886">RFC 1886</a>, December 1995.
[<a id="ref-RFC3363">RFC3363</a>] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", <a href="./rfc3363">RFC 3363</a>,
August 2002.
[<a id="ref-RFC3364">RFC3364</a>] Austein, R., "Tradeoffs in Domain Name System (DNS) Support
for Internet Protocol version 6 (IPv6)", <a href="./rfc3364">RFC 3364</a>, August
2002.
[<a id="ref-A6DISC">A6DISC</a>] Hagino, J., "Comparison of AAAA and A6 (do we really need
A6?)", (Work In Progress), July 2001.
[<a id="ref-BIND">BIND</a>] "Internet Systems Consortium",
<a href="http://www.isc.org/software/bind">http://www.isc.org/software/bind</a>.
[<a id="ref-KROOT">KROOT</a>] "RIPE Network Coordination Centre", <a href="http://k.root-servers.org/">http://k.root-</a>
<a href="http://k.root-servers.org/">servers.org/</a>.
[<a id="ref-LROOT">LROOT</a>] "ICANN DNS Operations", <a href="http://dns.icann.org/lroot/">http://dns.icann.org/lroot/</a>
<span class="grey">Jiang, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6563">RFC 6563</a> Moving A6 to Historic Status March 2012</span>
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]
</pre>
|
