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
|
<pre>Network Working Group R. Bush
Request for Comments: 3363 A. Durand
Updates: <a href="./rfc2673">2673</a>, <a href="./rfc2874">2874</a> B. Fink
Category: Informational O. Gudmundsson
T. Hain
Editors
August 2002
<span class="h1">Representing Internet Protocol version 6 (IPv6)</span>
<span class="h1">Addresses in the Domain Name System (DNS)</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document clarifies and updates the standards status of RFCs that
define direct and reverse map of IPv6 addresses in DNS. This
document moves the A6 and Bit label specifications to experimental
status.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The IETF had begun the process of standardizing two different address
formats for IPv6 addresses AAAA [<a href="./rfc1886" title=""DNS Extensions to support IP version 6"">RFC1886</a>] and A6 [<a href="./rfc2874" title=""DNS Extensions to Support IPv6 Address Aggregation and Renumbering"">RFC2874</a>] and both
are at proposed standard. This had led to confusion and conflicts on
which one to deploy. It is important for deployment that any
confusion in this area be cleared up, as there is a feeling in the
community that having more than one choice will lead to delays in the
deployment of IPv6. The goal of this document is to clarify the
situation.
This document also discusses issues relating to the usage of Binary
Labels [<a href="./rfc2673">RFC 2673</a>] to support the reverse mapping of IPv6 addresses.
This document is based on extensive technical discussion on various
relevant working groups mailing lists and a joint DNSEXT and NGTRANS
meeting at the 51st IETF in August 2001. This document attempts to
capture the sense of the discussions and reflect them in this
document to represent the consensus of the community.
<span class="grey">Bush, et. al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3363">RFC 3363</a> Representation of IPv6 Addresses in DNS August 2002</span>
The main arguments and the issues are covered in a separate document
[<a href="./rfc3364" title=""Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)"">RFC3364</a>] that reflects the current understanding of the issues.
This document summarizes the outcome of these discussions.
The issue of the root of reverse IPv6 address map is outside the
scope of this document and is covered in a different document
[<a href="./rfc3152" title=""Delegation of IP6.ARPA"">RFC3152</a>].
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a> Standards Action Taken</span>
This document changes the status of RFCs 2673 and 2874 from Proposed
Standard to Experimental.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. IPv6 Addresses: AAAA RR vs A6 RR</span>
Working group consensus as perceived by the chairs of the DNSEXT and
NGTRANS working groups is that:
a) AAAA records are preferable at the moment for production
deployment of IPv6, and
b) that A6 records have interesting properties that need to be better
understood before deployment.
c) It is not known if the benefits of A6 outweigh the costs and
risks.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> Rationale</span>
There are several potential issues with A6 RRs that stem directly
from the feature that makes them different from AAAA RRs: the ability
to build up addresses via chaining.
Resolving a chain of A6 RRs involves resolving a series of what are
nearly-independent queries. Each of these sub-queries takes some
non-zero amount of time, unless the answer happens to be in the
resolver's local cache already. Other things being equal, we expect
that the time it takes to resolve an N-link chain of A6 RRs will be
roughly proportional to N. What data we have suggests that users are
already impatient with the length of time it takes to resolve A RRs
in the IPv4 Internet, which suggests that users are not likely to be
patient with significantly longer delays in the IPv6 Internet, but
terminating queries prematurely is both a waste of resources and
another source of user frustration. Thus, we are forced to conclude
that indiscriminate use of long A6 chains is likely to lead to
increased user frustration.
<span class="grey">Bush, et. al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3363">RFC 3363</a> Representation of IPv6 Addresses in DNS August 2002</span>
The probability of failure during the process of resolving an N-link
A6 chain also appears to be roughly proportional to N, since each of
the queries involved in resolving an A6 chain has roughly the same
probability of failure as a single AAAA query.
Last, several of the most interesting potential applications for A6
RRs involve situations 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 susceptible to automation than pointers
within a single organization would be.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> Recommended Standard Action</span>
Based on the perceived consensus, this document recommends that <a href="./rfc1886">RFC</a>
<a href="./rfc1886">1886</a> stay on standards track and be advanced, while moving <a href="./rfc2874">RFC 2874</a>
to Experimental status.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Bitlabels in the Reverse DNS Tree</span>
<a href="./rfc2673">RFC 2673</a> defines a new DNS label type. This was the first new type
defined since <a href="./rfc1035">RFC 1035</a> [<a href="./rfc1035" title=""Domain Names - Implementation and Specification"">RFC1035</a>]. Since the development of 2673 it
has been learned that deployment of a new type is difficult since DNS
servers that do not support bitlabels reject queries containing bit
labels as being malformed. The community has also indicated that
this new label type is not needed for mapping reverse addresses.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Rationale</span>
The hexadecimal text representation of IPv6 addresses appears to be
capable of expressing all of the delegation schemes that we expect to
be used in the DNS reverse tree.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Recommended Standard Action</span>
<a href="./rfc2673">RFC 2673</a> standard status is to be changed from Proposed to
Experimental. Future standardization of these documents is to be
done by the DNSEXT working group or its successor.
<span class="grey">Bush, et. al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3363">RFC 3363</a> Representation of IPv6 Addresses in DNS August 2002</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. DNAME in IPv6 Reverse Tree</span>
The issues for DNAME in the reverse mapping tree appears to be
closely tied to the need to use fragmented A6 in the main tree: if
one is necessary, so is the other, and if one isn't necessary, the
other isn't either. Therefore, in moving <a href="./rfc2874">RFC 2874</a> to experimental,
the intent of this document is that use of DNAME RRs in the reverse
tree be deprecated.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgments</span>
This document is based on input from many members of the various IETF
working groups involved in this issues. Special thanks go to the
people that prepared reading material for the joint DNSEXT and
NGTRANS working group meeting at the 51st IETF in London, Rob
Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
Christian Huitema. Number of other people have made number of
comments on mailing lists about this issue including Andrew W.
Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka
Savola, Paul Vixie.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
As this document specifies a course of action, there are no direct
security considerations. There is an indirect security impact of the
choice, in that the relationship between A6 and DNSSEC is not well
understood throughout the community, while the choice of AAAA does
leads to a model for use of DNSSEC in IPv6 networks which parallels
current IPv4 practice.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
None.
Normative References
[<a id="ref-RFC1035">RFC1035</a>] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.
[<a id="ref-RFC1886">RFC1886</a>] Thompson, S. and C. Huitema, "DNS Extensions to support IP
version 6", <a href="./rfc1886">RFC 1886</a>, December 1995.
[<a id="ref-RFC2673">RFC2673</a>] Crawford, M., "Binary Labels in the Domain Name System",
<a href="./rfc2673">RFC 2673</a>, August 1999.
[<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.
<span class="grey">Bush, et. al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3363">RFC 3363</a> Representation of IPv6 Addresses in DNS August 2002</span>
[<a id="ref-RFC3152">RFC3152</a>] Bush, R., "Delegation of IP6.ARPA", <a href="https://www.rfc-editor.org/bcp/bcp49">BCP 49</a>, <a href="./rfc3152">RFC 3152</a>
August 2001.
Informative References
[<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.
Editors' Addresses
Randy Bush
EMail: randy@psg.com
Alain Durand
EMail: alain.durand@sun.com
Bob Fink
EMail: fink@es.net
Olafur Gudmundsson
EMail: ogud@ogud.com
Tony Hain
EMail: hain@tndh.net
<span class="grey">Bush, et. al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3363">RFC 3363</a> Representation of IPv6 Addresses in DNS August 2002</span>
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bush, et. al. Informational [Page 6]
</pre>
|
