7
Network Working Group R. Bush
8
Request for Comments: 3363 A. Durand
9
Updates: 2673, 2874 B. Fink
10
Category: Informational O. Gudmundsson
16
Representing Internet Protocol version 6 (IPv6)
17
Addresses in the Domain Name System (DNS)
21
This memo provides information for the Internet community. It does
22
not specify an Internet standard of any kind. Distribution of this
27
Copyright (C) The Internet Society (2002). All Rights Reserved.
31
This document clarifies and updates the standards status of RFCs that
32
define direct and reverse map of IPv6 addresses in DNS. This
33
document moves the A6 and Bit label specifications to experimental
38
The IETF had begun the process of standardizing two different address
39
formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both
40
are at proposed standard. This had led to confusion and conflicts on
41
which one to deploy. It is important for deployment that any
42
confusion in this area be cleared up, as there is a feeling in the
43
community that having more than one choice will lead to delays in the
44
deployment of IPv6. The goal of this document is to clarify the
47
This document also discusses issues relating to the usage of Binary
48
Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
50
This document is based on extensive technical discussion on various
51
relevant working groups mailing lists and a joint DNSEXT and NGTRANS
52
meeting at the 51st IETF in August 2001. This document attempts to
53
capture the sense of the discussions and reflect them in this
54
document to represent the consensus of the community.
58
Bush, et. al. Informational [Page 1]
60
RFC 3363 Representation of IPv6 Addresses in DNS August 2002
63
The main arguments and the issues are covered in a separate document
64
[RFC3364] that reflects the current understanding of the issues.
65
This document summarizes the outcome of these discussions.
67
The issue of the root of reverse IPv6 address map is outside the
68
scope of this document and is covered in a different document
71
1.1 Standards Action Taken
73
This document changes the status of RFCs 2673 and 2874 from Proposed
74
Standard to Experimental.
76
2. IPv6 Addresses: AAAA RR vs A6 RR
78
Working group consensus as perceived by the chairs of the DNSEXT and
79
NGTRANS working groups is that:
81
a) AAAA records are preferable at the moment for production
82
deployment of IPv6, and
84
b) that A6 records have interesting properties that need to be better
85
understood before deployment.
87
c) It is not known if the benefits of A6 outweigh the costs and
92
There are several potential issues with A6 RRs that stem directly
93
from the feature that makes them different from AAAA RRs: the ability
94
to build up addresses via chaining.
96
Resolving a chain of A6 RRs involves resolving a series of what are
97
nearly-independent queries. Each of these sub-queries takes some
98
non-zero amount of time, unless the answer happens to be in the
99
resolver's local cache already. Other things being equal, we expect
100
that the time it takes to resolve an N-link chain of A6 RRs will be
101
roughly proportional to N. What data we have suggests that users are
102
already impatient with the length of time it takes to resolve A RRs
103
in the IPv4 Internet, which suggests that users are not likely to be
104
patient with significantly longer delays in the IPv6 Internet, but
105
terminating queries prematurely is both a waste of resources and
106
another source of user frustration. Thus, we are forced to conclude
107
that indiscriminate use of long A6 chains is likely to lead to
108
increased user frustration.
114
Bush, et. al. Informational [Page 2]
116
RFC 3363 Representation of IPv6 Addresses in DNS August 2002
119
The probability of failure during the process of resolving an N-link
120
A6 chain also appears to be roughly proportional to N, since each of
121
the queries involved in resolving an A6 chain has roughly the same
122
probability of failure as a single AAAA query.
124
Last, several of the most interesting potential applications for A6
125
RRs involve situations where the prefix name field in the A6 RR
126
points to a target that is not only outside the DNS zone containing
127
the A6 RR, but is administered by a different organization entirely.
128
While pointers out of zone are not a problem per se, experience both
129
with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
130
pointers to other organizations are often not maintained properly,
131
perhaps because they're less susceptible to automation than pointers
132
within a single organization would be.
134
2.2 Recommended Standard Action
136
Based on the perceived consensus, this document recommends that RFC
137
1886 stay on standards track and be advanced, while moving RFC 2874
138
to Experimental status.
140
3. Bitlabels in the Reverse DNS Tree
142
RFC 2673 defines a new DNS label type. This was the first new type
143
defined since RFC 1035 [RFC1035]. Since the development of 2673 it
144
has been learned that deployment of a new type is difficult since DNS
145
servers that do not support bitlabels reject queries containing bit
146
labels as being malformed. The community has also indicated that
147
this new label type is not needed for mapping reverse addresses.
151
The hexadecimal text representation of IPv6 addresses appears to be
152
capable of expressing all of the delegation schemes that we expect to
153
be used in the DNS reverse tree.
155
3.2 Recommended Standard Action
157
RFC 2673 standard status is to be changed from Proposed to
158
Experimental. Future standardization of these documents is to be
159
done by the DNSEXT working group or its successor.
170
Bush, et. al. Informational [Page 3]
172
RFC 3363 Representation of IPv6 Addresses in DNS August 2002
175
4. DNAME in IPv6 Reverse Tree
177
The issues for DNAME in the reverse mapping tree appears to be
178
closely tied to the need to use fragmented A6 in the main tree: if
179
one is necessary, so is the other, and if one isn't necessary, the
180
other isn't either. Therefore, in moving RFC 2874 to experimental,
181
the intent of this document is that use of DNAME RRs in the reverse
186
This document is based on input from many members of the various IETF
187
working groups involved in this issues. Special thanks go to the
188
people that prepared reading material for the joint DNSEXT and
189
NGTRANS working group meeting at the 51st IETF in London, Rob
190
Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
191
Christian Huitema. Number of other people have made number of
192
comments on mailing lists about this issue including Andrew W.
193
Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka
196
6. Security Considerations
198
As this document specifies a course of action, there are no direct
199
security considerations. There is an indirect security impact of the
200
choice, in that the relationship between A6 and DNSSEC is not well
201
understood throughout the community, while the choice of AAAA does
202
leads to a model for use of DNSSEC in IPv6 networks which parallels
203
current IPv4 practice.
205
7. IANA Considerations
211
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
212
Specification", STD 13, RFC 1035, November 1987.
214
[RFC1886] Thompson, S. and C. Huitema, "DNS Extensions to support IP
215
version 6", RFC 1886, December 1995.
217
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
218
RFC 2673, August 1999.
220
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
221
IPv6 Address Aggregation and Renumbering", RFC 2874, July
226
Bush, et. al. Informational [Page 4]
228
RFC 3363 Representation of IPv6 Addresses in DNS August 2002
231
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
234
Informative References
236
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
237
Support for Internet Protocol version 6 (IPv6)", RFC 3364,
247
EMail: alain.durand@sun.com
282
Bush, et. al. Informational [Page 5]
284
RFC 3363 Representation of IPv6 Addresses in DNS August 2002
287
Full Copyright Statement
289
Copyright (C) The Internet Society (2002). All Rights Reserved.
291
This document and translations of it may be copied and furnished to
292
others, and derivative works that comment on or otherwise explain it
293
or assist in its implementation may be prepared, copied, published
294
and distributed, in whole or in part, without restriction of any
295
kind, provided that the above copyright notice and this paragraph are
296
included on all such copies and derivative works. However, this
297
document itself may not be modified in any way, such as by removing
298
the copyright notice or references to the Internet Society or other
299
Internet organizations, except as needed for the purpose of
300
developing Internet standards in which case the procedures for
301
copyrights defined in the Internet Standards process must be
302
followed, or as required to translate it into languages other than
305
The limited permissions granted above are perpetual and will not be
306
revoked by the Internet Society or its successors or assigns.
308
This document and the information contained herein is provided on an
309
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
310
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
311
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
312
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
313
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
317
Funding for the RFC Editor function is currently provided by the
338
Bush, et. al. Informational [Page 6]
added
removed
doc/rfc/rfc3363.txt
