idnits 2.17.1 draft-ietf-ipngwg-aaaa-00.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-26) 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 == It seems as if not all pages are separated by form feeds - found 7 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 are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 15 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 (November 5, 1997) is 9669 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 348, 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 (~~), 3 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 November 5, 1997 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 November 1997 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 subnet, 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 subnets. 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 November 1997 95 (Note that we decide here to reuse the name and code specified in 96 RFC 1886. This is questionable, as the record formats are in fact 97 incompatible. An alternative would be to allocate a new code. 98 Another alternative would be to adopt a compatible record format, 99 composed of 128 bits of address as in RFC 1886, followed by the 100 prefix and domain name. Updated systems would be capable of 101 reading the old records. Old systems, however, would only be 102 capable of using the new records if they decide to use the first 103 128 bits and ignore the remainder. In fact, they are more likely 104 to complain of a wrong record length.) 106 2.2 AAAA data format 108 +--------------+------------------+-----------------------+ 109 | Pre. length | Address low bits | Domain name of subnet | 110 | (1 octet) | (0..16 octets) | (variable, 0..256) | 111 +--------------+------------------+-----------------------+ 113 The data portion of the AAAA record contains three fields: 115 o a prefix length, encoded as one single octet. 117 o the lower bits of the address, encoded on a variable number 118 of octets. 120 o the domain name of the subnet, encoded as a domain name, 121 possibly compressed as specified in [3]. (The compression of 122 the domain name saves space, but may cause problems if servers 123 that don't understand the AAAA type cache this record.) 125 The number of octets used to encode the lower bits shall be exactly 126 sufficient to encode the complement to 128 bits of the prefix length. 127 The following table gives a set of examples: 129 Prefix length Number of octets of address 130 0 16 131 16 14 132 27 13 133 48 10 134 64 8 136 When the number of low order bits is not a multiple of 8, the 137 address should be padded to the left with binary zeroes. The 138 least significant address bit will always be encoded as the 139 least significant bit of the rightmost address octet. 141 The domain name component shall not be encoded if the length 142 of the prefix is zero. 144 Internet draft IPv6 DNS Extensions November 1997 146 2.3 AAAA query 148 An AAAA query for a specified domain name in the Internet class 149 returns all associated AAAA resource records in the answer section of 150 a response. 152 A type AAAA query does perform additional section processing, by 153 returning the AAAA records associated to the domain names mentioned 154 in the domain's AAAA records. 156 2.4 Textual format of AAAA records 158 The textual representation of the data portion of the AAAA resource 159 record used in a master database file is composed of three fields 160 separated by white spaces: 161 o a prefix length, represented as a decimal number, 163 o the textual representation of the host's IPv6 address as 164 defined in [3], 166 o a domain name. 168 The domain name may be absent if the prefix length is zero. 170 3. Inverse queries 172 Inverse queries are performed by looking for a DBIT record in 173 the IP6.INT domain. The DBIT resource records contains a prefix 174 length and a domain name. When the prefix length is not equal 175 to 128, the search should recurse by looking in the specified domain. 177 3.1 DBIT record type 179 The DBIT resource record type is a new record specific to the 180 Internet class that stores a single IPv6 address. 182 The value of the type is TBD (decimal). 184 3.2 DBIT data format 186 +--------------+--------------------+ 187 | Pre. length | Domain name | 188 | (1 octet) | (variable, 0..256) | 189 +--------------+--------------------+ 191 The data portion of the DBIT record contains two fields: 193 o a prefix length, encoded as one single octet. 195 o the domain name of the subnet, encoded as a domain name, 196 possibly compressed as specified in [3]. (The compression of 197 the domain name saves space, but may cause problems if servers 198 that don't understand the DBIT type cache this record.) 200 Internet draft IPv6 DNS Extensions November 1997 202 The prefix length is always relative to the start of the address, so 203 that if a prefix describes completely an address its length is always 204 set to 128. 206 3.3 DBIT query 208 An DBIT query for a specified domain name in the Internet class 209 returns all associated DBIT resource records in the answer section of 210 a response. 212 A type DBIT query does not perform additional section processing. 214 3.4 Textual format of DBIT records 216 The textual representation of the data portion of the DBIT resource 217 record used in a master database file is composed of two fields 218 separated by white spaces: 220 o a prefix length, represented as a decimal number, 222 o a domain name. 224 3.5 IP6.INT Domain 226 A special domain is defined to look up a record given an address. The 227 intent of this domain is to provide a way of mapping an IPv6 address 228 to a host name, although it may be used for other purposes as well. 229 The domain is rooted at IP6.INT. 231 An IPv6 address is represented as a name in the IP6.INT domain by a 232 sequence of nibbles separated by dots with the suffix ".IP6.INT". The 233 sequence of nibbles is encoded in reverse order, i.e. the low-order 234 nibble is encoded first, followed by the next low-order nibble and so 235 on. Each nibble is represented by a hexadecimal digit. For example, 236 the inverse lookup domain name corresponding to the address 238 4321:0:1:7:3:4:567:89ab 240 would be 242 b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.7.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT. 244 3.6 Processing of inverse queries 246 The DBIT request may result in one of the three following 247 possibilities: 249 * an error, 251 * the return of a DBIT record indicating a prefix length of 128, 253 Internet draft IPv6 DNS Extensions November 1997 255 * the return of a DBIT record indicating a prefix length indicating 256 a prefix length less than 128. 258 The third case will occur if the request has been matched by a 259 wildcard entry. For example, if all the IPv6 addresses that 260 start with the prefix 4321:0:1::/48 have been delegated to 261 the domain "net.foo.bar", it is possible to enter the record 263 DBIT 48 net.foo.bar. 265 for the wildcard entry: 267 *.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT. 269 The system that tried to find the name corresponding to the address 271 4321:0:1:7:3:4:567:89ab 273 will receive this record and will note that the prefix length is only 274 equal to 48. It will thus have to rewrite the inverse name. The new 275 name will be rooted by the specified prefix, and will only contain 276 the nibbles that are not subsumed by the prefix. In our example, that 277 means: 279 b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.7.0.0.0.net.foo.bar. 281 The system will repeat the DBIT query for that new name. If the 282 prefix length in the resulting DBIT is still not equal to 128, it 283 will have to repeat the operation. 285 If the prefix does not fit on an even number of nibbles, the most 286 significant hexadecimal digit will only include the bits that were 287 not specified in the prefix. The other bits will be set to zero. 288 For example, if the address 290 4321:0:1:7:3:4:567:89ab 292 had been matched by the prefix 4321:0:1:6/63, for example by 294 DBIT 63 subnet6.foo.bar. 296 the name used for the recursion would be: 298 b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.1.subnet6.foo.bar. 300 Not that the use of wildcard entries is natural in this procedure, 301 but is not mandatory. Other solutions, such as enumeration of 302 legal names and replication of the DBIT records, are also acceptable. 304 Internet draft IPv6 DNS Extensions November 1997 306 4. MODIFICATIONS TO EXISTING QUERY TYPES 308 All existing query types that perform type A additional section 309 processing, i.e. name server (NS), mail exchange (MX) and mailbox 310 (MB) query types, must be redefined to perform both type A and type 311 AAAA additional section processing. These new definitions mean that a 312 name server must add any relevant IPv4 addresses and any relevant 313 IPv6 addresses available locally to the additional section of a 314 response when processing any one of the above queries. 316 5. SECURITY CONSIDERATIONS 318 The AAAA and DBIT records can be secured by using the DNS 319 security procedures. The signature of the AAAA record only proves 320 that the record is genuine, i.e. has been inserted in the DNS by the 321 manager of the specified domain. The signature of the DBIT record 322 can be used to check the validity of the address delegation. 324 6. ACKNOWLEDGEMENTS 326 Many of the ideas here were developed during a discussion between the 327 authors, Robert Elz, Olafur Gudmundsson, Jim Bound, Bill Manning, 328 Bob Fink, Mike O'Dell, Matt Crawford, Bob Hinden and Steve Deering. 329 The specific AAAA format presented here was proposed by Robert Elz. 330 The idea of a DBIT record was proposed by Olafur Gudmundsson. 332 6. REFERENCES 334 [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 335 13, RFC 1034, USC/Information Sciences Institute, November 1987. 337 [2] Mockapetris, P., "Domain Names - Implementation and Specifica- 338 tion", STD 13, RFC 1035, USC/Information Sciences Institute, 339 November 1987. 341 [3] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing 342 Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 343 1995. 345 [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 346 Hosts and Routers", Work in Progress. 348 [5] Huitema C., and S. Thomson, "DNS Extensions to support IP 349 version 6." RFC 1886. 351 Internet draft IPv6 DNS Extensions November 1997 353 Authors' Addresses 355 Susan Thomson 356 Bellcore 357 MCC 1C259B 358 445 South Street 359 Morristown, NJ 07960 360 U.S.A. 362 Phone: +1 201-829-4514 363 EMail: set@bellcore.com 365 Christian Huitema 366 Bellcore 367 MCC 1J236B 368 445 South Street 369 Morristown, NJ 07960 370 U.S.A. 372 Phone: +1 201-829-4266 373 EMail: huitema@bellcore.com