idnits 2.17.1 draft-ietf-ipngwg-aaaa-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([3], [4], [1,2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (February 6, 1998) is 9575 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 370, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1884 (ref. '3') (Obsoleted by RFC 2373) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1886 (ref. '5') (Obsoleted by RFC 3596) Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Christian Huitema 2 INTERNET DRAFT Susan Thomson 3 Bellcore 4 February 6, 1998 6 DNS Extensions to support IP version 6 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 "working draft" or "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet Drafts 23 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Distribution of this memo is unlimited. 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 new resource record type to store an IPv6 address, 34 a new 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. 38 Internet draft IPv6 DNS Extensions February 1998 40 1.Introduction 42 Current support for the storage of Internet addresses in the Domain 43 Name System (DNS)[1,2] cannot easily be extended to support IPv6 44 addresses[3] since applications assume that address queries return 45 32-bit IPv4 addresses only. 47 To support the storage of IPv6 addresses we define the following 48 extensions: 50 o A new resource record type is defined to map a domain name to an 51 IPv6 address. 53 o A new domain is defined to support lookups based on address. 55 o Existing queries that perform additional section processing to 56 locate IPv4 addresses are redefined to perform additional 57 section processing on both IPv4 and IPv6 addresses. 59 The changes are designed to be compatible with existing software. The 60 existing support for IPv4 addresses is retained. Transition issues 61 related to the co-existence of both IPv4 and IPv6 addresses in DNS 62 are discussed in [4]. 64 This memo proposes an incompatible extension to the specification in 65 RFC 1886, and a departure from current implementation practices. The 66 changes are designed to facilitate network renumbering. 68 2. NEW RESOURCE RECORD DEFINITION AND DOMAIN 70 A new record type is defined to store a system's IPv6 address, or 71 addresses. The new record contains the least significant bits of 72 the host's IPv6 address. When the number of significant bits is lower 73 than 128, the record also contains the domain name of another 74 IPv6 system, which typically describes a complete link, or a 75 complete site. The most significant bits will be copied from the 76 IPv6 address of that system. If that system has several IPv6 77 addresses, the low bits of the host address will be combined with 78 each prefix of the several addresses, resulting in as many IPv6 79 addresses for the host. 81 A system may need several records if it is connected to several domains, 82 as would be the case, for example, of a site connected to several 83 providers, or of a host connected to different links. 85 2.1 AAAA record type 87 The AAAA resource record type is a new record specific to the 88 Internet class that stores the lower bits of a single IPv6 address 89 and the name of a domain where to fetch the higher bits. 91 The value of the type is 28 (decimal). 93 Internet draft IPv6 DNS Extensions February 1998 95 Note that we decide here to reuse the name and code specified in 96 RFC 1886. The record format has been changed, but it has been 97 Changed in a compatible way. Essentially, we have added to 98 The old format an optional "tail". Updated systems will be capable 99 of reading the old records. Old systems, however, will only be 100 capable of using the new records if they decide to use the first 101 128 bits and ignore the remainder. This will be discussed in the 102 "transition" section. 104 2.2 AAAA data format 106 +------------------+--------------+-----------------------+ 107 | Ipv6 address | Pre. length | Domain name of prefix | 108 | (128 bits) | (1 octet) | (variable, 0..255) | 109 +------------------+--------------+-----------------------+ 111 The data portion of the AAAA record contains three fields: 113 o A 128 bit IPv6 address, encoded in network byte order 114 (high-order byte first). 116 o a prefix length, encoded as one single octet, with value in 117 the range [0..128]. 119 o the domain name of the prefix, encoded as a domain name, 120 possibly compressed as specified in [3]. (The compression of 121 the domain name saves space, but may cause problems if servers 122 that don't understand the AAAA type cache this record.) 124 The domain name component shall not be encoded if the length 125 of the prefix is zero. 127 2.3 AAAA query 129 An AAAA query for a specified domain name in the Internet class 130 returns all associated AAAA resource records in the answer section of 131 a response. 133 A type AAAA query does perform additional section processing, by 134 returning the AAAA records associated to the domain names mentioned 135 in the domain's AAAA records. 137 Internet draft IPv6 DNS Extensions February 1998 139 2.4 Textual format of AAAA records 141 The textual representation of the data portion of the AAAA resource 142 record used in a master database file is composed of three fields 143 separated by white spaces: 145 o the textual representation of the host's IPv6 address as 146 defined in [3], 148 o a prefix length, represented as a decimal number, 150 o a domain name. 152 The domain name may be absent if the prefix length is zero. 154 2.5 IP6.INT Domain 156 A special domain is defined to look up a record given an address. The 157 intent of this domain is to provide a way of mapping an IPv6 address 158 to a host name, although it may be used for other purposes as well. 159 The domain is rooted at IP6.INT. 161 An IPv6 address is represented as a name in the IP6.INT domain by a 162 sequence of nibbles separated by dots with the suffix ".IP6.INT". The 163 sequence of nibbles is encoded in reverse order, i.e. the low-order 164 nibble is encoded first, followed by the next low-order nibble and so 165 on. Each nibble is represented by a hexadecimal digit. For example, 166 the inverse lookup domain name corresponding to the address 168 4321:0:1:2:3:4:567:89ab 170 would be 172 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.INT. 174 4. MODIFICATIONS TO EXISTING QUERY TYPES 176 All existing query types that perform type A additional section 177 processing, i.e. name server (NS), mail exchange (MX) and mailbox 178 (MB) query types, must be redefined to perform both type A and type 179 AAAA additional section processing. These new definitions mean that a 180 name server may add any relevant IPv4 addresses and any relevant 181 IPv6 addresses available locally to the additional section of a 182 response when processing any one of the above queries. 184 Internet draft IPv6 DNS Extensions February 1998 186 5. TRANSITION FROM RFC-1886 TO NEW FORMAT 188 The new specification of the AAAA record allows domain managers to 189 only specify the lower bits of the Ipv6 address in the AAAA record. 190 The upper, or most significant, bits, will be derived from the 191 AAAA record of the prefix. This new format is designed to better 192 support network renumbering and network multi-homing, while 193 preserving some degree of compatibility with the existing records. 195 5.1 Typical usage of the new format. 197 Let's take the example of a site, X, that is multi-homed to two 198 "intermediate" providers A and B. The provider A is itself 199 multi-homed to two transit providers, C and D. The provider 200 B gets its transit service from a single provider, E. Using the 201 Ipv6 "aggregatable addresses" format, C, D and E are represented 202 by the top level aggregates (TLA) '2CCC', '2DDD', and '2EEE', 203 respectively. C assigns to A the "next level aggregate" '00CA', 204 D assigns '00DA' to A, and E assigns '00EB' to B. A assigns to 205 X the subscriber identification '001A', and B assigns the 206 subscriber identification '034B'. As a result, the site X 207 inherits three address prefixes: 209 o 2CCC:00CA:001A/48 from A, for routes through C, 210 o 2DDD:00DA:001A/48 from A, for routes through D, 211 o 2EEE:00EB:034B/48 from B, for routes through E, 213 Lets suppose that S is a station in the site X, that it is 214 connected to the link number 1 in this site, and that it uses 215 the interface identifier (UID) '1234:5678:90AB:CDEF'. In our 216 configuration, this station will be configured with three 217 addresses: 219 o 2CCC:00CA:001A:0001:1234:5678:90AB:CDEF 220 o 2DDD:00DA:001A:0001:1234:5678:90AB:CDEF 221 o 2EEE:00EB:034B:0001:1234:5678:90AB:CDEF 223 In the DNS, we will assume that the site X is represented by 224 the domain name XXX.COM, while A, B, C, D and E are represented 225 by A.NET, B.NET, C.NET, D.NET and E.NET. In each of these 226 domains, we create a subdomain "IP6" that will hold the 227 corresponding prefixes. The station S is identified by the 228 domain name S.XXX.COM. Using the new format, we have to 229 enter the following records in the DNS: 231 S.XXX.COM AAAA ::1:1234:5678:90AB:CDEF 48 IP6.XXX.COM 233 IP6.XXX.COM AAAA 0:0:001A:: 28 IP6.A.NET 234 IP6.XXX.COM AAAA 0:0:034B:: 28 IP6.B.NET 236 IP6.A.NET AAAA 0:00CA:: 16 IP6.C.NET 237 IP6.A.NET AAAA 0:00DA:: 16 IP6.D.NET 239 Internet draft IPv6 DNS Extensions February 1998 241 IP6.B.NET AAAA 0:00EB:: 16 IP6.E.NET 243 IP6.C.NET AAAA 2CCC:: 245 IP6.D.NET AAAA 2DDD:: 247 IP6.E.NET AAAA 2EEE:: 249 An immediate observation is that we will only manage one record 250 per station, or more precisely per interface, instead of one 251 per prefix per station. The new format allows us to easily 252 support renumbering. 254 5.2 Support for network renumbering 256 Network renumbering occurs when a site changes providers, when 257 a provider switches to a new provider, or when either the site or 258 one of its providers decides to "multihome". The new format 259 enables domain managers to manage these events by updating a 260 single DNS record. 262 Suppose, in our example, that the site X decides to replace its 263 Providers, A and B, by a direct connection to the transit network 264 C. A single DNS update would do the trick, replacing the 265 two AAAA records in "IP6.XXX.COM" by: 267 IP6.XXX.COM AAAA 0:0123:4567: 16 IP6.C.NET. 269 There will be no need to modify the individual records of the 270 site's stations. As a consequence, the TTL of the station's 271 record can be set to a large value, and the switching can be 272 prepare by simply reducing the TTL value of the site's 273 prefix record. 275 Note that in most cases the switching will be organized in 276 two phases. The connection to the new provider will be 277 installed, a new site AAAA record will be added for that 278 new connection. After a transition period, the site will 279 be disconnected from its previous providers, and the old 280 records will be removed from the DNS. 282 Similarly, if the network provider B decide to switch 283 transit provider, say from E to D, it will only have to 284 update its own AAAA network records. 286 Obviously, the DNS updates will have to be synchronized 287 with the address configuration and router renumbering 288 procedures. This should be specified in a separate memo. 290 Internet draft IPv6 DNS Extensions February 1998 292 5.3 Transition strategies 294 The new AAAA format is an extension of the format specified 295 in RFC 1886. Systems have already be deployed that 296 implement RFC 1886. These old systems will not be able to 297 understand the new format, while updated systems will still 298 be capable of understanding the old records. This suggest 299 a two-phase transition strategy: 301 1) develop resolvers that understand the new record format, 302 but ban actual usage of the new format in the DNS, 303 except for test purposes. 305 2) when the new resolvers have been deployed, start usage 306 of the indirection capabilities provided by the new 307 format. 309 5.4 Transition of the inverse tree 311 A characteristic of the new format is that a given prefix 312 information is stored in exactly one place. The current 313 "IP6.INT" domain does not share this desirable 314 characteristic: inverse trees have to be replicated for 315 each prefix. Moreover, it can be argue that the inverse 316 name format is quite ugly. The IPNG working group 317 examined several proposals that tried to solve these problems, 318 but could not settle on any of them. In fact, it is clear 319 that the problem is difficult, and that "better" solution 320 require a change in the DNS specifications. 322 The DNS working group is examining such changes. Some 323 proposals will allow "virtual links" within the naming 324 tree at a zone level -- such links are currently only 325 allowed for individual entries, using CNAME records. Other 326 proposal would allow "binary" labels. None of these proposals 327 is yet final. 329 When these new capabilities are defined, we expect to revisit 330 the structure of the inverse tree. 332 Internet draft IPv6 DNS Extensions February 1998 334 6. SECURITY CONSIDERATIONS 336 The AAAA and PTR records can be secured by using the DNS 337 security procedures. The signature of the AAAA record only proves 338 that the record is genuine, i.e. has been inserted in the DNS by the 339 manager of the specified domain. The signature of the NS and 340 SOA records in the inverse tree can be used to check the validity 341 of the address delegation. 342 Because the address will be composed by combining several records, 343 the security level will be determined by the weakest of these 344 records. Managers should take this in consideration when deciding to 345 use references to prefixes. 347 7. ACKNOWLEDGEMENTS 349 Many of the ideas here were developed during a discussion between the 350 authors, Robert Elz, Olafur Gudmundsson, Jim Bound, Bill Manning, 351 Bob Fink, Mike O'Dell, Matt Crawford, Ken Powell, Bob Hinden and 352 Steve Deering. 354 8. REFERENCES 356 [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 357 13, RFC 1034, USC/Information Sciences Institute, November 1987. 359 [2] Mockapetris, P., "Domain Names - Implementation and Specifica- 360 tion", STD 13, RFC 1035, USC/Information Sciences Institute, 361 November 1987. 363 [3] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing 364 Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 365 1995. 367 [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 368 Hosts and Routers", Work in Progress. 370 [5] Huitema C., and S. Thomson, "DNS Extensions to support IP 371 version 6." RFC 1886. 373 Internet draft IPv6 DNS Extensions February 1998 375 Authors' Addresses 377 Susan Thomson 378 Bellcore 379 MCC 1C259B 380 445 South Street 381 Morristown, NJ 07960 382 U.S.A. 384 Phone: +1 201-829-4514 385 EMail: set@bellcore.com 387 Christian Huitema 388 Bellcore 389 MCC 1J236B 390 445 South Street 391 Morristown, NJ 07960 392 U.S.A. 394 Phone: +1 201-829-4266 395 EMail: huitema@bellcore.com