external/bsd/bind/dist/doc/rfc/rfc3596.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         S. Thomson
   8 Request for Comments: 3596                                         Cisco
   9 Obsoletes: 3152, 1886                                         C. Huitema
  10 Category: Standards Track                                      Microsoft
  11                                                               V. Ksinant
  12                                                                    6WIND
  13                                                               M. Souissi
  14                                                                    AFNIC
  15                                                             October 2003
  16
  17
  18                  DNS Extensions to Support IP Version 6
  19
  20 Status of this Memo
  21
  22    This document specifies an Internet standards track protocol for the
  23    Internet community, and requests discussion and suggestions for
  24    improvements.  Please refer to the current edition of the "Internet
  25    Official Protocol Standards" (STD 1) for the standardization state
  26    and status of this protocol.  Distribution of this memo is unlimited.
  27
  28 Copyright Notice
  29
  30    Copyright (C) The Internet Society (2003).  All Rights Reserved.
  31
  32 Abstract
  33
  34    This document defines the changes that need to be made to the Domain
  35    Name System (DNS) to support hosts running IP version 6 (IPv6).  The
  36    changes include a resource record type to store an IPv6 address, a
  37    domain to support lookups based on an IPv6 address, and updated
  38    definitions of existing query types that return Internet addresses as
  39    part of additional section processing.  The extensions are designed
  40    to be compatible with existing applications and, in particular, DNS
  41    implementations themselves.
  42
  43 Table of Contents
  44
  45    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  46    2.  New resource record definition and domain. . . . . . . . . . .  2
  47        2.1.  AAAA record type . . . . . . . . . . . . . . . . . . . .  3
  48        2.2.  AAAA data format . . . . . . . . . . . . . . . . . . . .  3
  49        2.3.  AAAA query . . . . . . . . . . . . . . . . . . . . . . .  3
  50        2.4.  Textual format of AAAA records . . . . . . . . . . . . .  3
  51        2.5.  IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . .  3
  52    3.  Modifications to existing query types. . . . . . . . . . . . .  4
  53    4.  Security Considerations. . . . . . . . . . . . . . . . . . . .  4
  54    5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  4
  55
  56
  57
  58 Thomson, et al.             Standards Track                     [Page 1]
  59 \f
  60 RFC 3596             DNS Extensions to Support IPv6         October 2003
  61
  62
  63    6.  Intellectual Property Statement. . . . . . . . . . . . . . . .  4
  64    Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . .  5
  65    Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . .  6
  66    Normative References . . . . . . . . . . . . . . . . . . . . . . .  6
  67    Informative References . . . . . . . . . . . . . . . . . . . . . .  6
  68    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7
  69    Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .  8
  70
  71 1. Introduction
  72
  73    Current support for the storage of Internet addresses in the Domain
  74    Name System (DNS) [1,2] cannot easily be extended to support IPv6
  75    addresses [3] since applications assume that address queries return
  76    32-bit IPv4 addresses only.
  77
  78    To support the storage of IPv6 addresses in the DNS, this document
  79    defines the following extensions:
  80
  81       o A resource record type is defined to map a domain name to an
  82         IPv6 address.
  83
  84       o A domain is defined to support lookups based on address.
  85
  86       o Existing queries that perform additional section processing to
  87         locate IPv4 addresses are redefined to perform additional
  88         section processing on both IPv4 and IPv6 addresses.
  89
  90    The changes are designed to be compatible with existing software.
  91    The existing support for IPv4 addresses is retained.  Transition
  92    issues related to the co-existence of both IPv4 and IPv6 addresses in
  93    the DNS are discussed in [4].
  94
  95    The IP protocol version used for querying resource records is
  96    independent of the protocol version of the resource records; e.g.,
  97    IPv4 transport can be used to query IPv6 records and vice versa.
  98
  99    This document combines RFC 1886 [5] and changes to RFC 1886 made by
 100    RFC 3152 [6], obsoleting both.  Changes mainly consist in replacing
 101    the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
 102
 103 2. New resource record definition and domain
 104
 105    A record type is defined to store a host's IPv6 address.  A host that
 106    has more than one IPv6 address must have more than one such record.
 107
 108
 109
 110
 111
 112
 113
 114 Thomson, et al.             Standards Track                     [Page 2]
 115 \f
 116 RFC 3596             DNS Extensions to Support IPv6         October 2003
 117
 118
 119 2.1 AAAA record type
 120
 121    The AAAA resource record type is a record specific to the Internet
 122    class that stores a single IPv6 address.
 123
 124    The IANA assigned value of the type is 28 (decimal).
 125
 126 2.2 AAAA data format
 127
 128    A 128 bit IPv6 address is encoded in the data portion of an AAAA
 129    resource record in network byte order (high-order byte first).
 130
 131 2.3 AAAA query
 132
 133    An AAAA query for a specified domain name in the Internet class
 134    returns all associated AAAA resource records in the answer section of
 135    a response.
 136
 137    A type AAAA query does not trigger additional section processing.
 138
 139 2.4 Textual format of AAAA records
 140
 141    The textual representation of the data portion of the AAAA resource
 142    record used in a master database file is the textual representation
 143    of an IPv6 address as defined in [3].
 144
 145 2.5 IP6.ARPA Domain
 146
 147    A special domain is defined to look up a record given an IPv6
 148    address.  The intent of this domain is to provide a way of mapping an
 149    IPv6 address to a host name, although it may be used for other
 150    purposes as well.  The domain is rooted at IP6.ARPA.
 151
 152    An IPv6 address is represented as a name in the IP6.ARPA domain by a
 153    sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
 154    The sequence of nibbles is encoded in reverse order, i.e., the
 155    low-order nibble is encoded first, followed by the next low-order
 156    nibble and so on.  Each nibble is represented by a hexadecimal digit.
 157    For example, the reverse lookup domain name corresponding to the
 158    address
 159
 160        4321:0:1:2:3:4:567:89ab
 161
 162    would be
 163
 164    b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
 165                                                                   ARPA.
 166
 167
 168
 169
 170 Thomson, et al.             Standards Track                     [Page 3]
 171 \f
 172 RFC 3596             DNS Extensions to Support IPv6         October 2003
 173
 174
 175 3. Modifications to existing query types
 176
 177    All existing query types that perform type A additional section
 178    processing, i.e., name server (NS), location of services (SRV) and
 179    mail exchange (MX) query types, must be redefined to perform both
 180    type A and type AAAA additional section processing.  These
 181    definitions mean that a name server must add any relevant IPv4
 182    addresses and any relevant IPv6 addresses available locally to the
 183    additional section of a response when processing any one of the above
 184    queries.
 185
 186 4. Security Considerations
 187
 188    Any information obtained from the DNS must be regarded as unsafe
 189    unless techniques specified in [7] or [8] are used.  The definitions
 190    of the AAAA record type and of the IP6.ARPA domain do not change the
 191    model for use of these techniques.
 192
 193    So, this specification is not believed to cause any new security
 194    problems, nor to solve any existing ones.
 195
 196 5. IANA Considerations
 197
 198    There are no IANA assignments to be performed.
 199
 200 6. Intellectual Property Statement
 201
 202    The IETF takes no position regarding the validity or scope of any
 203    intellectual property or other rights that might be claimed to
 204    pertain to the implementation or use of the technology described in
 205    this document or the extent to which any license under such rights
 206    might or might not be available; neither does it represent that it
 207    has made any effort to identify any such rights.  Information on the
 208    IETF's procedures with respect to rights in standards-track and
 209    standards-related documentation can be found in BCP-11.  Copies of
 210    claims of rights made available for publication and any assurances of
 211    licenses to be made available, or the result of an attempt made to
 212    obtain a general license or permission for the use of such
 213    proprietary rights by implementors or users of this specification can
 214    be obtained from the IETF Secretariat.
 215
 216    The IETF invites any interested party to bring to its attention any
 217    copyrights, patents or patent applications, or other proprietary
 218    rights which may cover technology that may be required to practice
 219    this standard.  Please address the information to the IETF Executive
 220    Director.
 221
 222
 223
 224
 225
 226 Thomson, et al.             Standards Track                     [Page 4]
 227 \f
 228 RFC 3596             DNS Extensions to Support IPv6         October 2003
 229
 230
 231 Acknowledgments
 232
 233    Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien
 234    Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin
 235    (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic
 236    Roudaut (IRISA) and G6 group for their help during the RFC 1886
 237    Interop tests sessions.
 238
 239    Many thanks to Alain Durand and Olafur Gudmundsson for their support.
 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 Thomson, et al.             Standards Track                     [Page 5]
 283 \f
 284 RFC 3596             DNS Extensions to Support IPv6         October 2003
 285
 286
 287 Appendix A: Changes from RFC 1886
 288
 289    The following changes were made from RFC 1886 "DNS Extensions to
 290    support IP version 6":
 291
 292    - Replaced the "IP6.INT" domain by "IP6.ARPA".
 293    - Mentioned SRV query types in section 3 "MODIFICATIONS TO
 294      EXISTING QUERY TYPES"
 295    - Added security considerations.
 296    - Updated references :
 297      * From RFC 1884 to RFC 3513 (IP Version 6 Addressing
 298        Architecture).
 299      * From "work in progress" to RFC 2893 (Transition Mechanisms for
 300        IPv6 Hosts and Routers).
 301      * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845.
 302    - Updated document abstract
 303    - Added table of contents
 304    - Added full copyright statement
 305    - Added IANA considerations section
 306    - Added Intellectual Property Statement
 307
 308 Normative References
 309
 310    [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
 311         13, RFC 1034, November 1987.
 312
 313    [2]  Mockapetris, P., "Domain Names - Implementation and
 314         Specification", STD 13, RFC 1035, November 1987.
 315
 316    [3]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
 317         Addressing Architecture", RFC 3513, April 2003.
 318
 319 Informative References
 320
 321    [4]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
 322         Hosts and Routers", RFC 2893, August 2000.
 323
 324    [5]  Thomson, S. and C. Huitema, "DNS Extensions to support IP
 325         version 6", RFC 1886, December 1995.
 326
 327    [6]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August
 328         2001.
 329
 330    [7]  Eastlake, D., "Domain Name System Security Extensions", RFC
 331         2535, March 1999
 332
 333
 334
 335
 336
 337
 338 Thomson, et al.             Standards Track                     [Page 6]
 339 \f
 340 RFC 3596             DNS Extensions to Support IPv6         October 2003
 341
 342
 343    [8]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
 344         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
 345         2845, May 2000.
 346
 347 Authors' Addresses
 348
 349    Susan Thomson
 350    Cisco Systems
 351    499 Thornall Street, 8th floor
 352    Edison, NJ 08837
 353
 354    Phone: +1 732-635-3086
 355    EMail:  sethomso@cisco.com
 356
 357
 358    Christian Huitema
 359    Microsoft Corporation
 360    One Microsoft Way
 361    Redmond, WA 98052-6399
 362
 363    EMail: huitema@microsoft.com
 364
 365
 366    Vladimir Ksinant
 367    6WIND S.A.
 368    Immeuble Central Gare - Bat.C
 369    1, place Charles de Gaulle
 370    78180, Montigny-Le-Bretonneux - France
 371
 372    Phone: +33 1 39 30 92 36
 373    EMail: vladimir.ksinant@6wind.com
 374
 375
 376    Mohsen Souissi
 377    AFNIC
 378    Immeuble International
 379    2, rue Stephenson,
 380    78181, Saint-Quentin en Yvelines Cedex - France
 381
 382    Phone: +33 1 39 30 83 40
 383    EMail: Mohsen.Souissi@nic.fr
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Thomson, et al.             Standards Track                     [Page 7]
 395 \f
 396 RFC 3596             DNS Extensions to Support IPv6         October 2003
 397
 398
 399 Full Copyright Statement
 400
 401    Copyright (C) The Internet Society (2003).  All Rights Reserved.
 402
 403    This document and translations of it may be copied and furnished to
 404    others, and derivative works that comment on or otherwise explain it
 405    or assist in its implementation may be prepared, copied, published
 406    and distributed, in whole or in part, without restriction of any
 407    kind, provided that the above copyright notice and this paragraph are
 408    included on all such copies and derivative works.  However, this
 409    document itself may not be modified in any way, such as by removing
 410    the copyright notice or references to the Internet Society or other
 411    Internet organizations, except as needed for the purpose of
 412    developing Internet standards in which case the procedures for
 413    copyrights defined in the Internet Standards process must be
 414    followed, or as required to translate it into languages other than
 415    English.
 416
 417    The limited permissions granted above are perpetual and will not be
 418    revoked by the Internet Society or its successors or assignees.
 419
 420    This document and the information contained herein is provided on an
 421    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 422    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 423    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 424    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 425    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 426
 427 Acknowledgement
 428
 429    Funding for the RFC Editor function is currently provided by the
 430    Internet Society.
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Thomson, et al.             Standards Track                     [Page 8]
 451 \f