contrib/bind9/doc/rfc/rfc3363.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            R. Bush
   8 Request for Comments: 3363                                     A. Durand
   9 Updates: 2673, 2874                                              B. Fink
  10 Category: Informational                                   O. Gudmundsson
  11                                                                  T. Hain
  12                                                                  Editors
  13                                                              August 2002
  14
  15
  16             Representing Internet Protocol version 6 (IPv6)
  17                Addresses in the Domain Name System (DNS)
  18
  19 Status of this Memo
  20
  21    This memo provides information for the Internet community.  It does
  22    not specify an Internet standard of any kind.  Distribution of this
  23    memo is unlimited.
  24
  25 Copyright Notice
  26
  27    Copyright (C) The Internet Society (2002).  All Rights Reserved.
  28
  29 Abstract
  30
  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
  34    status.
  35
  36 1.  Introduction
  37
  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
  45    situation.
  46
  47    This document also discusses issues relating to the usage of Binary
  48    Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
  49
  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.
  55
  56
  57
  58 Bush, et. al.                Informational                      [Page 1]
  59 \f
  60 RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
  61
  62
  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.
  66
  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
  69    [RFC3152].
  70
  71 1.1 Standards Action Taken
  72
  73    This document changes the status of RFCs 2673 and 2874 from Proposed
  74    Standard to Experimental.
  75
  76 2.  IPv6 Addresses: AAAA RR vs A6 RR
  77
  78    Working group consensus as perceived by the chairs of the DNSEXT and
  79    NGTRANS working groups is that:
  80
  81    a) AAAA records are preferable at the moment for production
  82       deployment of IPv6, and
  83
  84    b) that A6 records have interesting properties that need to be better
  85       understood before deployment.
  86
  87    c) It is not known if the benefits of A6 outweigh the costs and
  88       risks.
  89
  90 2.1 Rationale
  91
  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.
  95
  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.
 109
 110
 111
 112
 113
 114 Bush, et. al.                Informational                      [Page 2]
 115 \f
 116 RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
 117
 118
 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.
 123
 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.
 133
 134 2.2 Recommended Standard Action
 135
 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.
 139
 140 3.  Bitlabels in the Reverse DNS Tree
 141
 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.
 148
 149 3.1 Rationale
 150
 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.
 154
 155 3.2 Recommended Standard Action
 156
 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.
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170 Bush, et. al.                Informational                      [Page 3]
 171 \f
 172 RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
 173
 174
 175 4.  DNAME in IPv6 Reverse Tree
 176
 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
 182    tree be deprecated.
 183
 184 5.  Acknowledgments
 185
 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
 194    Savola, Paul Vixie.
 195
 196 6.  Security Considerations
 197
 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.
 204
 205 7.  IANA Considerations
 206
 207    None.
 208
 209 Normative References
 210
 211    [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
 212               Specification", STD 13, RFC 1035, November 1987.
 213
 214    [RFC1886]  Thompson, S. and C. Huitema, "DNS Extensions to support IP
 215               version 6", RFC 1886, December 1995.
 216
 217    [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
 218               RFC 2673, August 1999.
 219
 220    [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
 221               IPv6 Address Aggregation and Renumbering", RFC 2874, July
 222               2000.
 223
 224
 225
 226 Bush, et. al.                Informational                      [Page 4]
 227 \f
 228 RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
 229
 230
 231    [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
 232               August 2001.
 233
 234 Informative References
 235
 236    [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
 237               Support for Internet Protocol version 6 (IPv6)", RFC 3364,
 238               August 2002.
 239
 240 Editors' Addresses
 241
 242    Randy Bush
 243    EMail: randy@psg.com
 244
 245
 246    Alain Durand
 247    EMail: alain.durand@sun.com
 248
 249
 250    Bob Fink
 251    EMail: fink@es.net
 252
 253
 254    Olafur Gudmundsson
 255    EMail: ogud@ogud.com
 256
 257
 258    Tony Hain
 259    EMail: hain@tndh.net
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Bush, et. al.                Informational                      [Page 5]
 283 \f
 284 RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
 285
 286
 287 Full Copyright Statement
 288
 289    Copyright (C) The Internet Society (2002).  All Rights Reserved.
 290
 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
 303    English.
 304
 305    The limited permissions granted above are perpetual and will not be
 306    revoked by the Internet Society or its successors or assigns.
 307
 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.
 314
 315 Acknowledgement
 316
 317    Funding for the RFC Editor function is currently provided by the
 318    Internet Society.
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Bush, et. al.                Informational                      [Page 6]
 339 \f