idnits 2.17.1 draft-ietf-dnsext-rfc1886bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 273 has weird spacing: '...for the purpo...' == Line 292 has weird spacing: '... to perta...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2026' on line 13 == Unused Reference: '5' is defined on line 215, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 218, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '3') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. '4') (Obsoleted by RFC 4213) -- Obsolete informational reference (is this intentional?): RFC 1886 (ref. '5') (Obsoleted by RFC 3596) -- Obsolete informational reference (is this intentional?): RFC 3152 (ref. '6') (Obsoleted by RFC 3596) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '7') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '8') (Obsoleted by RFC 8945) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Thomson, Cisco 2 INTERNET-DRAFT C. Huitema, Microsoft 3 May 12, 2003 V. Ksinant, 6WIND 4 Expires November 12, 2003 M. Souissi, AFNIC 6 DNS Extensions to support IP version 6 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 This Internet Draft expires November 12, 2003. 29 Abstract 31 This document defines the changes that need to be made to the Domain 32 Name System to support hosts running IP version 6 (IPv6). The 33 changes include a resource record type to store an IPv6 address, 34 a domain to support lookups based on an IPv6 address, and updated 35 definitions of existing query types that return Internet addresses as 36 part of additional section processing. The extensions are designed 37 to be compatible with existing applications and, in particular, DNS 38 implementations themselves. 40 This Document combines RFC1886 and changes to RFC 1886 made by 41 RFC 3152, obsoleting both. Changes mainly consist in replacing 42 the IP6.INT domain by IP6.ARPA as defined in RFC 3152. 44 Table of Contents 46 1. Introduction............................................. 2 47 2. New resource record definition and domain................ 2 48 2.1. AAAA record type.................................... 3 49 2.2. AAAA data format.................................... 3 50 2.3. AAAA query.......................................... 3 51 2.4. Textual format of AAAA records...................... 3 52 2.5. IP6.ARPA domain..................................... 3 53 3. Modifications to existing query types.................... 4 54 4. Security Considerations.................................. 4 55 5. IANA Considerations...................................... 4 56 APPENDIX A: Changes from RFC-1886............................ 4 57 Acknowledgments.............................................. 5 58 References................................................... 5 59 Authors' Addresses........................................... 6 60 Full Copyright Statement..................................... 7 62 1. INTRODUCTION 64 Current support for the storage of Internet addresses in the Domain 65 Name System (DNS)[1,2] cannot easily be extended to support IPv6 66 addresses[3] since applications assume that address queries return 67 32-bit IPv4 addresses only. 69 To support the storage of IPv6 addresses in DNS, this document 70 defines the following extensions: 72 o A resource record type is defined to map a domain name to an 73 IPv6 address. 75 o A domain is defined to support lookups based on address. 77 o Existing queries that perform additional section processing to 78 locate IPv4 addresses are redefined to perform additional 79 section processing on both IPv4 and IPv6 addresses. 81 The changes are designed to be compatible with existing software. The 82 existing support for IPv4 addresses is retained. Transition issues 83 related to the co-existence of both IPv4 and IPv6 addresses in DNS 84 are discussed in [4]. 86 2. RESOURCE RECORD DEFINITION AND DOMAIN 88 A record type is defined to store a host's IPv6 address. A host 89 that has more than one IPv6 address must have more than one such 90 record. 92 2.1 AAAA record type 94 The AAAA resource record type is a record specific to the Internet 95 class that stores a single IPv6 address. 97 The IANA assigned value of the type is 28 (decimal). 99 2.2 AAAA data format 101 A 128 bit IPv6 address is encoded in the data portion of an AAAA 102 resource record in network byte order (high-order byte first). 104 2.3 AAAA query 106 An AAAA query for a specified domain name in the Internet class 107 returns all associated AAAA resource records in the answer section of 108 a response. 110 A type AAAA query does not perform additional section processing. 112 2.4 Textual format of AAAA records 114 The textual representation of the data portion of the AAAA resource 115 record used in a master database file is the textual representation 116 of a IPv6 address as defined in [3]. 118 2.5 IP6.ARPA Domain 120 A special domain is defined to look up a record given an address. The 121 intent of this domain is to provide a way of mapping an IPv6 address 122 to a host name, although it may be used for other purposes as well. 123 The domain is rooted at IP6.ARPA. 125 An IPv6 address is represented as a name in the IP6.ARPA domain by a 126 sequence of nibbles separated by dots with the suffix ".IP6.ARPA". 127 The sequence of nibbles is encoded in reverse order, i.e. the 128 low-order nibble is encoded first, followed by the next low-order 129 nibble and so on. Each nibble is represented by a hexadecimal digit. 130 For example, the inverse lookup domain name corresponding to the 131 address 133 4321:0:1:2:3:4:567:89ab 135 would be 137 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. 138 ARPA. 140 3. MODIFICATIONS TO EXISTING QUERY TYPES 142 All existing query types that perform type A additional section 143 processing, i.e. name server (NS), location of services (SRV) and 144 mail exchange (MX) query types, must be redefined to perform both 145 type A and type AAAA additional section processing. These definitions 146 mean that a name server must add any relevant IPv4 addresses and any 147 relevant IPv6 addresses available locally to the additional section 148 of a response when processing any one of the above queries. 150 4. SECURITY CONSIDERATIONS 152 Any information obtained from the DNS must be regarded as unsafe 153 unless techniques specified in [7] or [8] are used. The definitions 154 of the AAAA record type and of the IP6.ARPA domain do not change the 155 model for use of these techniques. 157 So, this specification is not believed to cause any new security 158 problems, nor to solve any existing ones. 160 5. IANA CONSIDERATIONS 162 There are no IANA assignments to be performed. 164 APPENDIX A: Changes from RFC 1886 166 The following changes were made from RFC 1886 "DNS Extensions to 167 support IP version 6": 169 - Replaced the "IP6.INT" domain by "IP6.ARPA". 170 - Mentioned SRV query types in section 3 "MODIFICATIONS TO 171 EXISTING QUERY TYPES" 172 - Added security considerations. 173 - Updated references : 174 * From RFC 1884 to RFC 3513 (IP Version 6 Addressing 175 Architecture). 176 * From "work in progress" to RFC 2893 (Transition Mechanisms for 177 IPv6 Hosts and Routers). 178 * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845. 179 - Updated document abstract 180 - Added table of contents 181 - Added full copyright statement 182 - Added IANA considerations section 184 Acknowledgements 186 Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien 187 Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael 188 Guerin (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), 189 Frederic Roudaut (IRISA) and G6 group for their help during the RFC 190 1886 Interop tests sessions. 192 Many thanks to Alain Durand and Olafur Gudmundsson for their support. 194 Normative References 196 [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 197 13, RFC 1034, USC/Information Sciences Institute, November 1987. 199 [2] Mockapetris, P., "Domain Names - Implementation and Specifica- 200 tion", STD 13, RFC 1035, USC/Information Sciences Institute, 201 November 1987. 203 Informative References 205 [3] Hinden, R., and S. Deering, "Internet Protocol Version 6 (IPv6) 206 Addressing Architecture", RFC 3513, Nokia, Cisco, April 2003. 208 [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 209 Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems 210 Inc., August 2000. 211 This RFC is being updated. The current draft is 212 "draft-ietf-v6ops-mech-v2-00.txt", Gilligan, R., and 213 E. Nordmark, February 24, 2003 215 [5] Thomson, S., and C. Huitema, "DNS Extensions to support IP 216 version 6", RFC 1886, Bellcore, INRIA, December 1995. 218 [6] Bush, R., "Delegation of IP6.ARPA", RFC 3152, RGnet, August 219 2001. 221 [7] Eastlake, D., "Domain Name System Security Extensions", 222 RFC 2535, IBM, March 1999 224 [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 225 "Secret Key Transaction Authentication for DNS (TSIG)", 226 RFC 2845, ISC, NAI Labs, Motorola, Nominum, May 2000. 228 Authors' Addresses 230 Susan Thomson 231 Cisco Systems 232 499 Thornall Street, 8th floor 233 Edison, NJ 08837 234 Telephone: 732-635-3086 235 Email: sethomso@cisco.com 237 Christian Huitema 238 Microsoft Corporation 239 One Microsoft Way 240 Redmond, WA 98052-6399 241 Email: huitema@microsoft.com 243 Vladimir Ksinant 244 6WIND S.A. 245 Immeuble Central Gare - Bat.C 246 1, place Charles de Gaulle 247 78180, Montigny-Le-Bretonneux - France 248 Phone: +33 1 39 30 92 36 249 Email: vladimir.ksinant@6wind.com 251 Mohsen Souissi 252 AFNIC 253 Immeuble International 254 2, rue Stephenson, 255 78181, Saint-Quentin en Yvelines Cedex - France 256 Phone: +33 1 39 30 83 40 257 Email: Mohsen.Souissi@nic.fr 259 Full Copyright Statement 261 Copyright (C) The Internet Society (date). All Rights 262 Reserved. 264 This document and translations of it may be copied and 265 furnished to others, and derivative works that comment on or 266 otherwise explain it or assist in its implmentation may be 267 prepared, copied, published and distributed, in whole or in 268 part, without restriction of any kind, provided that the above 269 copyright notice and this paragraph are included on all such 270 copies and derivative works. However, this document itself may 271 not be modified in any way, such as by removing the copyright 272 notice or references to the Internet Society or other Internet 273 organizations, except as needed for the purpose of developing 274 Internet standards in which case the procedures for copyrights 275 defined in the Internet Standards process must be followed, or 276 as required to translate it into languages other than English. 278 The limited permissions granted above are perpetual and will 279 not be revoked by the Internet Society or its successors or 280 assigns. 282 This document and the information contained herein is provided 283 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 284 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 285 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 286 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 287 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 288 PARTICULAR PURPOSE." 290 The IETF takes no position regarding the validity or scope of 291 any intellectual property or other rights that might be claimed 292 to pertain to the implementation or use of the technology 293 described in this document or the extent to which any license 294 under such rights might or might not be available; neither does 295 it represent that it has made any effort to identify any such 296 rights. Information on the IETF's procedures with respect to 297 rights in standards-track and standards-related documentation 298 can be found in BCP-11. Copies of claims of rights made 299 available for publication and any assurances of licenses to 300 be made available, or the result of an attempt made 301 to obtain a general license or permission for the use of such 302 proprietary rights by implementors or users of this 303 specification can be obtained from the IETF Secretariat. 305 The IETF invites any interested party to bring to its 306 attention any copyrights, patents or patent applications, or 307 other proprietary rights which may cover technology that may be 308 required to practice this standard. Please address the 309 information to the IETF Executive Director.