idnits 2.17.1 draft-ietf-ipngwg-dns-lookups-08.txt: ** The Abstract section seems to be numbered 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 4 characters in excess of 72. == There are 12 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 18 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 (May 17, 2000) is 8743 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) == Missing Reference: 'DNSCF' is mentioned on line 353, but not defined ** Obsolete normative reference: RFC 2373 (ref. 'AARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2374 (ref. 'AGGR') (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 2673 (ref. 'BITLBL') (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (ref. 'DNAME') (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 2535 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Downref: Normative reference to an Informational RFC: RFC 1900 (ref. 'RENUM') ** Obsolete normative reference: RFC 1933 (ref. 'TRANS') (Obsoleted by RFC 2893) -- Possible downref: Non-RFC (?) normative reference: ref. 'TSIG' Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPng Working Group Matt Crawford 2 Internet Draft Fermilab 3 Christian Huitema 4 Susan Thomson 5 Telcordia 6 May 17, 2000 8 DNS Extensions to Support IPv6 Address Aggregation and Renumbering 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet- Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Abstract 32 This document defines changes to the Domain Name System to support 33 renumberable and aggregatable IPv6 addressing. The changes include 34 a new resource record type to store an IPv6 address in a manner 35 which expedites network renumbering and updated definitions of 36 existing query types that return Internet addresses as part of 37 additional section processing. 39 For lookups keyed on IPv6 addresses (often called reverse lookups), 40 this document defines a new zone structure which allows a zone to be 41 used without modification for parallel copies of an address space 42 (as for a multihomed provider or site) and across network 43 renumbering events. 45 Status of this Memo ............................................... 1 47 1. Abstract ...................................................... 1 49 2. Introduction .................................................. 3 51 3. Overview ...................................................... 4 52 3.1. Name-to-Address Lookup .................................. 4 53 3.2. Underlying Mechanisms for Reverse Lookups ............... 4 54 3.2.1. Delegation on Arbitrary Boundaries ................ 4 55 3.2.2. Reusable Zones .................................... 5 57 4. Specifications ................................................ 6 58 4.1. The A6 Record Type ...................................... 6 59 4.1.1. Format ............................................ 6 60 4.1.2. Processing ........................................ 6 61 4.1.3. Textual Representation ............................ 7 62 4.1.4. Name Resolution Procedure ......................... 7 63 4.2. Zone Structure for Reverse Lookups ...................... 8 65 5. Modifications to Existing Query Types ......................... 8 67 6. Usage Illustrations ........................................... 9 68 6.1. A6 Record Chains ........................................ 9 69 6.1.1. Authoritative Data ................................ 10 70 6.1.2. Glue .............................................. 10 71 6.1.3. Variations ........................................ 12 72 6.2. Reverse Mapping Zones ................................... 13 73 6.2.1. The TLA level ..................................... 13 74 6.2.2. The ISP level ..................................... 14 75 6.2.3. The Site Level .................................... 14 76 6.3. Lookups ................................................. 14 77 6.4. Operational Note ........................................ 15 79 7. Transition from RFC 1886 and Deployment Notes ................. 16 80 7.1. Transition from AAAA and Coexistence with A Records ..... 17 81 7.2. Transition from Nibble Labels to Binary Labels .......... 17 83 8. Security Considerations ....................................... 18 85 9. IANA Considerations ........................................... 18 87 10. Acknowledgments .............................................. 18 89 11. References ................................................... 19 91 12. Authors' Addresses ........................................... 20 92 2. Introduction 94 Maintenance of address information in the DNS is one of several 95 obstacles which have prevented site and provider renumbering from 96 being feasible in IP version 4. Arguments about the importance of 97 network renumbering for the preservation of a stable routing system 98 and for other purposes may be read in documents cited here as 99 [RENUM]. To support the storage of IPv6 addresses without impeding 100 renumbering we define the following extensions. 102 o A new resource record type, "A6", is defined to map a domain 103 name to an IPv6 address, with a provision for indirection for 104 leading "prefix" bits. 106 o Existing queries that perform additional section processing to 107 locate IPv4 addresses are redefined to do that processing for 108 both IPv4 and IPv6 addresses. 110 o A new domain, IP6.ARPA, is defined to support lookups based on 111 IPv6 address. 113 o A new prefix-delegation method is defined, relying on new DNS 114 features [BITLBL, DNAME]. 116 The changes are designed to be compatible with existing application 117 programming interfaces. The existing support for IPv4 addresses is 118 retained. Transition issues related to the coexistence of both IPv4 119 and IPv6 addresses in DNS are discussed in [TRANS]. 121 This memo proposes a replacement for the specification in RFC 1886 122 and a departure from current implementation practices. The changes 123 are designed to facilitate network renumbering and multihoming. 124 Domains employing the A6 record for IPv6 addresses can insert 125 automatically-generated AAAA records in zone files to ease 126 transition. It is expected that after a reasonable period, RFC 1886 127 will become Historic. 129 The next three major sections of this document are an overview of 130 the facilities defined or employed by this specification, the 131 specification itself, and examples of use. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [KWORD]. The key 136 word "SUGGESTED" signifies a strength between MAY and SHOULD: it is 137 believed that compliance with the suggestion has tangible benefits 138 in most instances. 140 3. Overview 142 This section provides an overview of the DNS facilities for storage 143 of IPv6 addresses and for lookups based on IPv6 address, including 144 those defined here and elsewhere. 146 3.1. Name-to-Address Lookup 148 IPv6 addresses are stored in one or more A6 resource records. A 149 single A6 record may include a complete IPv6 address, or a 150 contiguous portion of an address and information leading to one or 151 more prefixes. Prefix information comprises a prefix length and a 152 DNS name which is in turn the owner of one or more A6 records 153 defining the prefix or prefixes which are needed to form one or more 154 complete IPv6 addresses. When the prefix length is zero, no DNS 155 name is present and all the leading bits of the address are 156 significant. There may be multiples levels of indirection and the 157 existence of multiple A6 records at any level multiplies the number 158 of IPv6 addresses which are formed. 160 An application looking up an IPv6 address will generally cause the 161 DNS resolver to access several A6 records, and multiple IPv6 162 addresses may be returned even if the queried name was the owner of 163 only one A6 record. The authenticity of the returned address(es) 164 cannot be directly verified by DNS Security [DNSSEC]. The A6 165 records which contributed to the address(es) may of course be 166 verified if signed. 168 Implementers are reminded of the necessity to limit the amount of 169 work a resolver will perform in response to a client request. This 170 principle MUST be extended to also limit the generation of DNS 171 requests in response to one name-to-address (or address-to-name) 172 lookup request. 174 3.2. Underlying Mechanisms for Reverse Lookups 176 This section describes the new DNS features which this document 177 exploits. This section is an overview, not a specification of those 178 features. The reader is directed to the referenced documents for 179 more details on each. 181 3.2.1. Delegation on Arbitrary Boundaries 183 This new scheme for reverse lookups relies on a new type of DNS 184 label called the "bit-string label" [BITLBL]. This label compactly 185 represents an arbitrary string of bits which is treated as a 186 hierarchical sequence of one-bit domain labels. Resource records 187 can thereby be stored at arbitrary bit-boundaries. 189 Examples in section 6 will employ the following textual 190 representation for bit-string labels, which is a subset of the 191 syntax defined in [BITLBL]. A base indicator "x" for hexadecimal 192 and a sequence of hexadecimal digits is enclosed between "\[" and 193 "]". The bits denoted by the digits represent a sequence of one-bit 194 domain labels ordered from most to least significant. (This is the 195 opposite of the order they would appear if listed one bit at a time, 196 but it appears to be a convenient notation.) The digit string may 197 be followed by a slash ("/") and a decimal count. If omitted, the 198 implicit count is equal to four times the number of hexadecimal 199 digits. 201 Consecutive bit-string labels are equivalent (up to the limit 202 imposed by the size of the bit count field) to a single bit-string 203 label containing all the bits of the consecutive labels in the 204 proper order. As an example, either of the following domain names 205 could be used in a QCLASS=IN, QTYPE=PTR query to find the name of 206 the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32. 208 \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA. 210 \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA. 212 3.2.2. Reusable Zones 214 DNS address space delegation is implemented not by zone cuts and NS 215 records, but by a new analogue to the CNAME record, called the DNAME 216 resource record [DNAME]. The DNAME record provides alternate naming 217 to an entire subtree of the domain name space, rather than to a 218 single node. It causes some suffix of a queried name to be 219 substituted with a name from the DNAME record's RDATA. 221 For example, a resolver or server providing recursion, while looking 222 up a QNAME a.b.c.d.e.f may encounter a DNAME record 224 d.e.f. DNAME w.xy. 226 which will cause it to look for a.b.c.w.xy. 228 4. Specifications 230 4.1. The A6 Record Type 232 The A6 record type is specific to the IN (Internet) class and has 233 type number 38 (decimal). 235 4.1.1. Format 237 The RDATA portion of the A6 record contains two or three fields. 239 +-----------+------------------+-------------------+ 240 |Prefix len.| Address suffix | Prefix name | 241 | (1 octet) | (0..16 octets) | (0..255 octets) | 242 +-----------+------------------+-------------------+ 244 o A prefix length, encoded as an eight-bit unsigned integer with 245 value between 0 and 128 inclusive. 247 o An IPv6 address suffix, encoded in network order (high-order 248 octet first). There MUST be exactly enough octets in this field 249 to contain a number of bits equal to 128 minus prefix length, 250 with 0 to 7 leading pad bits to make this field an integral 251 number of octets. Pad bits, if present, MUST be set to zero 252 when loading a zone file and ignored (other than for SIG 253 [DNSSEC] verification) on reception. 255 o The name of the prefix, encoded as a domain name. By the rules 256 of [DNSIS], this name MUST NOT be compressed. 258 The domain name component SHALL NOT be present if the prefix length 259 is zero. The address suffix component SHALL NOT be present if the 260 prefix length is 128. 262 It is SUGGESTED that an A6 record intended for use as a prefix for 263 other A6 records have all the insignificant trailing bits in its 264 address suffix field set to zero. 266 4.1.2. Processing 268 A query with QTYPE=A6 causes type A6 and type NS additional section 269 processing for the prefix names, if any, in the RDATA field of the 270 A6 records in the answer section. This processing SHOULD be 271 recursively applied to the prefix names of A6 records included as 272 additional data. When space in the reply packet is a limit, 273 inclusion of additional A6 records takes priority over NS records. 275 It is an error for a A6 record with prefix length L1 > 0 to refer to 276 a domain name which owns a A6 record with a prefix length L2 > L1. 277 If such a situation is encountered by a resolver, the A6 record with 278 the offending (larger) prefix length MUST be ignored. Robustness 279 precludes signaling an error if addresses can still be formed from 280 valid A6 records, but it is SUGGESTED that zone maintainers from 281 time to time check all the A6 records their zones reference. 283 4.1.3. Textual Representation 285 The textual representation of the RDATA portion of the A6 resource 286 record in a zone file comprises two or three fields separated by 287 whitespace. 289 o A prefix length, represented as a decimal number between 0 and 290 128 inclusive, 292 o the textual representation of an IPv6 address as defined in 293 [AARCH] (although some leading and/or trailing bits may not be 294 significant), 296 o a domain name, if the prefix length is not zero. 298 The domain name MUST be absent if the prefix length is zero. The 299 IPv6 address MAY be be absent if the prefix length is 128. A number 300 of leading address bits equal to the prefix length SHOULD be zero, 301 either implicitly (through the :: notation) or explicitly, as 302 specified in section 4.1.1. 304 4.1.4. Name Resolution Procedure 306 To obtain the IPv6 address or addresses which belong to a given 307 name, a DNS client MUST obtain one or more complete chains of A6 308 records, each chain beginning with a record owned by the given name 309 and including a record owned by the prefix name in that record, and 310 so on recursively, ending with an A6 record with a prefix length of 311 zero. One IPv6 address is formed from one such chain by taking the 312 value of each bit position from the earliest A6 record in the chain 313 which validly covers that position, as indicated by the prefix 314 length. The set of all IPv6 addresses for the given name comprises 315 the addresses formed from all complete chains of A6 records 316 beginning at that name, discarding records which have invalid prefix 317 lengths as defined in section 4.1.2. 319 If some A6 queries fail and others succeed, a client might obtain a 320 non-empty but incomplete set of IPv6 addresses for a host. In many 321 situations this may be acceptable. The completeness of a set of A6 322 records may always be determined by inspection. 324 4.2. Zone Structure for Reverse Lookups 326 Very little of the new scheme's data actually appears under 327 IP6.ARPA; only the first level of delegation needs to be under that 328 domain. More levels of delegation could be placed under IP6.ARPA if 329 some top-level delegations were done via NS records instead of DNAME 330 records, but this would incur some cost in renumbering ease at the 331 level of TLAs [AGGR]. Therefore, it is declared here that all 332 address space delegations SHOULD be done by the DNAME mechanism 333 rather than NS. 335 In addition, since uniformity in deployment will simplify 336 maintenance of address delegations, it is SUGGESTED that address and 337 prefix information be stored immediately below a DNS label "IP6". 338 Stated another way, conformance with this suggestion would mean that 339 "IP6" is the first label in the RDATA field of DNAME records which 340 support IPv6 reverse lookups. 342 When any "reserved" or "must be zero" bits are adjacent to a 343 delegation boundary, the higher-level entity MUST retain those bits 344 in its own control and delegate only the bits over which the lower- 345 level entity has authority. 347 To find the name of a node given its IPv6 address, a DNS client MUST 348 perform a query with QCLASS=IN, QTYPE=PTR on the name formed from 349 the 128 bit address as one or more bit-string labels [BITLBL], 350 followed by the two standard labels "IP6.ARPA". If recursive 351 service was not obtained from a server and the desired PTR record 352 was not returned, the resolver MUST handle returned DNAME records as 353 specified in [DNAME], and NS records as specified in [DNSCF], and 354 iterate. 356 5. Modifications to Existing Query Types 358 All existing query types that perform type A additional section 359 processing, i.e. the name server (NS), mail exchange (MX), and 360 mailbox (MB) query types, and the experimental AFS data base (AFSDB) 361 and route through (RT) types, must be redefined to perform type A, 362 A6 and AAAA additional section processing, with type A having the 363 highest priority for inclusion and type AAAA the lowest. This 364 redefinition means that a name server may add any relevant IPv4 and 365 IPv6 address information available locally to the additional section 366 of a response when processing any one of the above queries. The 367 recursive inclusion of A6 records referenced by A6 records already 368 included in the additional section is OPTIONAL. 370 6. Usage Illustrations 372 This section provides examples of use of the mechanisms defined in 373 the previous section. All addresses and domains mentioned here are 374 intended to be fictitious and for illustrative purposes only. 375 Example delegations will be on 4-bit boundaries solely for 376 readability; this specification is indifferent to bit alignment. 378 Use of the IPv6 aggregatable address format [AGGR] is assumed in the 379 examples. 381 6.1. A6 Record Chains 383 Let's take the example of a site X that is multi-homed to two 384 "intermediate" providers A and B. The provider A is itself multi- 385 homed to two "transit" providers, C and D. The provider B gets its 386 transit service from a single provider, E. For simplicity suppose 387 that C, D and E all belong to the same top-level aggregate (TLA) 388 with identifier (including format prefix) '2345', and the TLA 389 authority at ALPHA-TLA.ORG assigns to C, D and E respectively the 390 next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 391 and 2345:000E::/32. 393 C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the 394 prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to 395 B. 397 A assigns to X the subscriber identification '11' and B assigns the 398 subscriber identification '22'. As a result, the site X inherits 399 three address prefixes: 401 o 2345:00C1:CA11::/48 from A, for routes through C. 402 o 2345:00D2:DA11::/48 from A, for routes through D. 403 o 2345:000E:EB22::/48 from B, for routes through E. 405 Let us suppose that N is a node in the site X, that it is assigned 406 to subnet number 1 in this site, and that it uses the interface 407 identifier '1234:5678:9ABC:DEF0'. In our configuration, this node 408 will have three addresses: 410 o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 411 o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 412 o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 414 6.1.1. Authoritative Data 416 We will assume that the site X is represented in the DNS by the 417 domain name X.EXAMPLE, while A, B, C, D and E are represented by 418 A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we 419 assume a subdomain "IP6" that will hold the corresponding prefixes. 420 The node N is identified by the domain name N.X.EXAMPLE. The 421 following records would then appear in X's DNS. 423 $ORIGIN X.EXAMPLE. 424 N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 425 SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 426 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. 427 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. 429 And elsewhere there would appear 431 SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. 432 SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET. 434 SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET. 436 A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG. 438 A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG. 440 B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG. 442 C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: 443 D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: 444 E.NET.ALPHA-TLA.ORG. A6 0 2345:000E:: 446 6.1.2. Glue 448 When, as is common, some or all DNS servers for X.EXAMPLE are within 449 the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry 450 enough "glue" information to enable DNS clients to reach those 451 nameservers. This is true in IPv6 just as in IPv4. However, the A6 452 record affords the DNS administrator some choices. The glue could 453 be any of 454 o a minimal set of A6 records duplicated from the X.EXAMPLE zone, 456 o a (possibly smaller) set of records which collapse the structure 457 of that minimal set, 459 o or a set of A6 records with prefix length zero, giving the 460 entire global addresses of the servers. 462 The trade-off is ease of maintenance against robustness. The best 463 and worst of both may be had together by implementing either the 464 first or second option together with the third. To illustrate the 465 glue options, suppose that X.EXAMPLE is served by two nameservers 466 NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers 467 ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively. 468 Then the top-level zone EXAMPLE would include one (or more) of the 469 following sets of A6 records as glue. 471 $ORIGIN EXAMPLE. ; first option 472 X NS NS1.X 473 NS NS2.X 474 NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X 475 NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X 476 SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X 477 SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X 478 IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. 479 IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. 481 $ORIGIN EXAMPLE. ; second option 482 X NS NS1.X 483 NS NS2.X 484 NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET. 485 A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET. 486 NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET. 487 A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET. 489 $ORIGIN EXAMPLE. ; third option 490 X NS NS1.X 491 NS NS2.X 492 NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111 493 A6 0 2345:00D2:DA11:1:1:11:111:1111 494 A6 0 2345:000E:EB22:1:1:11:111:1111 495 NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222 496 A6 0 2345:00D2:DA11:2:2:22:222:2222 497 A6 0 2345:000E:EB22:2:2:22:222:2222 499 The first and second glue options are robust against renumbering of 500 X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if 501 those providers' own DNS is unreachable. The glue records of the 502 third option are robust against DNS failures elsewhere than the 503 zones EXAMPLE and X.EXAMPLE themselves, but must be updated when X's 504 address space is renumbered. 506 If the EXAMPLE zone includes redundant glue, for instance the union 507 of the A6 records of the first and third options, then under normal 508 circumstances duplicate IPv6 addresses will be derived by DNS 509 clients. But if provider DNS fails, addresses will still be 510 obtained from the zero-prefix-length records, while if the EXAMPLE 511 zone lags behind a renumbering of X.EXAMPLE, half of the addresses 512 obtained by DNS clients will still be up-to-date. 514 The zero-prefix-length glue records can of course be automatically 515 generated and/or checked in practice. 517 6.1.3. Variations 519 Several more-or-less arbitrary assumptions are reflected in the 520 above structure. All of the following choices could have been made 521 differently, according to someone's notion of convenience or an 522 agreement between two parties. 524 First, that site X has chosen to put subnet information in a 525 separate A6 record rather than incorporate it into each node's 526 A6 records. 528 Second, that site X is referred to as "SUBSCRIBER-X" by both of 529 its providers A and B. 531 Third, that site X chose to indirect its provider information 532 through A6 records at IP6.X.EXAMPLE containing no significant 533 bits. An alternative would have been to replicate each subnet 534 record for each provider. 536 Fourth, B and E used a slightly different prefix naming 537 convention between themselves than did A, C and D. Each 538 hierarchical pair of network entities must arrange this naming 539 between themselves. 541 Fifth, that the upward prefix referral chain topped out at 542 ALPHA-TLA.ORG. There could have been another level which 543 assigned the TLA values and holds A6 records containing those 544 bits. 546 Finally, the above structure reflects an assumption that address 547 fields assigned by a given entity are recorded only in A6 records 548 held by that entity. Those bits could be entered into A6 records in 549 the lower-level entity's zone instead, thus: 551 IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET. 552 IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET. 554 IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET. 555 and so on. 557 Or the higher-level entities could hold both sorts of A6 records 558 (with different DNS owner names) and allow the lower-level entities 559 to choose either mode of A6 chaining. But the general principle of 560 avoiding data duplication suggests that the proper place to store 561 assigned values is with the entity that assigned them. 563 It is possible, but not necessarily recommended, for a zone 564 maintainer to forego the renumbering support afforded by the 565 chaining of A6 records and to record entire IPv6 addresses within 566 one zone file. 568 6.2. Reverse Mapping Zones 570 Supposing that address space assignments in the TLAs with Format 571 Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in 572 zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then 573 the IP6.ARPA zone would include 575 $ORIGIN IP6.ARPA. 576 \[x234500/24] DNAME IP6.ALPHA-TLA.ORG. 577 \[x267800/24] DNAME IP6.BRAVO-TLA.ORG. 578 \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY. 580 Eight trailing zero bits have been included in each TLA ID to 581 reflect the eight reserved bits in the current aggregatable global 582 unicast addresses format [AGGR]. 584 6.2.1. The TLA level 586 ALPHA-TLA's assignments to network providers C, D and E are 587 reflected in the reverse data as follows. 589 \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. 590 \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET. 591 \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET. 593 6.2.2. The ISP level 595 The providers A through E carry the following delegation information 596 in their zone files. 598 \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. 599 \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET. 600 \[xEB/8].IP6.E.NET. DNAME IP6.B.NET. 601 \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. 602 \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE. 604 Note that some domain names appear in the RDATA of more than one 605 DNAME record. In those cases, one zone is being used to map 606 multiple prefixes. 608 6.2.3. The Site Level 610 Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to- 611 name translations. This domain is now referenced by two different 612 DNAME records held by two different providers. 614 $ORIGIN IP6.X.EXAMPLE. 615 \[x0001/16] DNAME SUBNET-1 616 \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. 617 and so on. 619 SUBNET-1 need not have been named in a DNAME record; the subnet bits 620 could have been joined with the interface identifier. But if 621 subnets are treated alike in both the A6 records and in the reverse 622 zone, it will always be possible to keep the forward and reverse 623 definition data for each prefix in one zone. 625 6.3. Lookups 627 A DNS resolver looking for a hostname for the address 628 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the 629 DNAME records shown above and would form new queries. Assuming that 630 it began the process knowing servers for IP6.ARPA, but that no 631 server it consulted provided recursion and none had other useful 632 additional information cached, the sequence of queried names and 633 responses would be (all with QCLASS=IN, QTYPE=PTR): 635 To a server for IP6.ARPA: 636 QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA. 638 Answer: 639 \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG. 641 To a server for IP6.ALPHA-TLA.ORG: 642 QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG. 644 Answer: 645 \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. 647 To a server for IP6.C.NET.: 648 QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET. 650 Answer: 651 \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. 653 To a server for IP6.A.NET.: 654 QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET. 656 Answer: 657 \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. 659 To a server for IP6.X.EXAMPLE.: 660 QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE. 662 Answer: 663 \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. 664 \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE. 666 All the DNAME (and NS) records acquired along the way can be cached 667 to expedite resolution of addresses topologically near to this 668 address. And if another global address of N.X.EXAMPLE were resolved 669 within the TTL of the final PTR record, that record would not have 670 to be fetched again. 672 6.4. Operational Note 674 In the illustrations in section 6.1, hierarchically adjacent 675 entities, such as a network provider and a customer, must agree on a 676 DNS name which will own the definition of the delegated prefix(es). 677 One simple convention would be to use a bit-string label 678 representing exactly the bits which are assigned to the lower-level 679 entity by the higher. For example, "SUBSCRIBER-X" could be replaced 680 by "\[x11/8]". This would place the A6 record(s) defining the 681 delegated prefix at exactly the same point in the DNS tree as the 682 DNAME record associated with that delegation. The cost of this 683 simplification is that the lower-level zone must update its upward- 684 pointing A6 records when it is renumbered. This cost may be found 685 quite acceptable in practice. 687 7. Transition from RFC 1886 and Deployment Notes 689 When prefixes have been "delegated upward" with A6 records, the 690 number of DNS resource records required to establish a single IPv6 691 address increases by some non-trivial factor. Those records will 692 typically, but not necessarily, come from different DNS zones (which 693 can independently suffer failures for all the usual reasons). When 694 obtaining multiple IPv6 addresses together, this increase in RR 695 count will be proportionally less -- and the total size of a DNS 696 reply might even decrease -- if the addresses are topologically 697 clustered. But the records could still easily exceed the space 698 available in a UDP response which returns a large RRset [DNSCLAR] to 699 an MX, NS, or SRV query, for example. The possibilities for overall 700 degradation of performance and reliability of DNS lookups are 701 numerous, and increase with the number of prefix delegations 702 involved, especially when those delegations point to records in 703 other zones. 705 DNS Security [DNSSEC] addresses the trustworthiness of cached data, 706 which is a problem intrinsic to DNS, but the cost of applying this 707 to an IPv6 address is multiplied by a factor which may be greater 708 than the number of prefix delegations involved if different 709 signature chains must be verified for different A6 records. If a 710 trusted centralized caching server (as in [TSIG], for example) is 711 used, this cost might be amortized to acceptable levels. One new 712 phenomenon is the possibility that IPv6 addresses may be formed from 713 a A6 records from a combination of secure and unsecured zones. 715 Until more deployment experience is gained with the A6 record, it is 716 recommended that prefix delegations be limited to one or two levels. 717 A reasonable phasing-in mechanism would be to start with no prefix 718 delegations (all A6 records having prefix length 0) and then to move 719 to the use of a single level of delegation within a single zone. 720 (If the TTL of the "prefix" A6 records is kept to an appropriate 721 duration the capability for rapid renumbering is not lost.) More 722 aggressively flexible delegation could be introduced for a subset of 723 hosts for experimentation. 725 7.1. Transition from AAAA and Coexistence with A Records 727 Administrators of zones which contain A6 records can easily 728 accommodate deployed resolvers which understand AAAA records but not 729 A6 records. Such administrators can do automatic generation of AAAA 730 records for all of a zone's names which own A6 records by a process 731 which mimics the resolution of a hostname to an IPv6 address (see 732 section 4.1.4). Attention must be paid to the TTL assigned to a 733 generated AAAA record, which MUST be no more than the minimum of the 734 TTLs of the A6 records that were used to form the IPv6 address in 735 that record. For full robustness, those A6 records which were in 736 different zones should be monitored for changes (in TTL or RDATA) 737 even when there are no changes to zone for which AAAA records are 738 being generated. If the zone is secure [DNSSEC], the generated AAAA 739 records MUST be signed along with the rest of the zone data. 741 A zone-specific heuristic MAY be used to avoid generation of AAAA 742 records for A6 records which record prefixes, although such 743 superfluous records would be relatively few in number and harmless. 744 Examples of such heuristics include omitting A6 records with a 745 prefix length less than the largest value found in the zone file, or 746 records with an address suffix field with a certain number of 747 trailing zero bits. 749 On the client side, when looking up and IPv6 address, the order of 750 A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA; 751 AAAA, then A6; A6 only; or both in parallel. The default order (or 752 only order, if not configurable) MUST be to try A6 first, then AAAA. 753 If and when the AAAA becomes deprecated a new document will change 754 the default. 756 The guidelines and options for precedence between IPv4 and IPv6 757 addresses are specified in [TRANS]. All mentions of AAAA records in 758 that document are henceforth to be interpreted as meaning A6 and/or 759 AAAA records in the order specified in the previous paragraph. 761 7.2. Transition from Nibble Labels to Binary Labels 763 Implementations conforming to RFC 1886 perform reverse lookups as 764 follows: 766 An IPv6 address is represented as a name in the IP6.INT domain 767 by a sequence of nibbles separated by dots with the suffix 768 ".IP6.INT". The sequence of nibbles is encoded in reverse order, 769 i.e. the low-order nibble is encoded first, followed by the next 770 low-order nibble and so on. Each nibble is represented by a 771 hexadecimal digit. For example, a name for the address 772 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in 773 section 6.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.- 774 8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int." 776 Implementations conforming to this specification will perform a 777 lookup of a binary label in IP6.ARPA as specified in Section 3.2. 778 It is RECOMMENDED that for a transition period implementations first 779 lookup the binary label in IP6.ARPA and if this fails try to lookup 780 the 'nibble' label in IP6.INT. 782 8. Security Considerations 784 The signing authority [DNSSEC] for the A6 records which determine an 785 IPv6 address is distributed among several entities, reflecting the 786 delegation path of the address space which that address occupies. 787 DNS Security is fully applicable to bit-string labels and DNAME 788 records. And just as in IPv4, verification of name-to-address 789 mappings is logically independent of verification of address-to-name 790 mappings. 792 With or without DNSSEC, the incomplete but non-empty address set 793 scenario of section 4.1.4 could be caused by selective interference 794 with DNS lookups. If in some situation this would be more harmful 795 than complete DNS failure, it might be mitigated on the client side 796 by refusing to act on an incomplete set, or on the server side by 797 listing all addresses in A6 records with prefix length 0. 799 9. IANA Considerations 801 The A6 resource record has been assigned a Type value of 38. 803 10. Acknowledgments 805 The authors would like to thank the following persons for valuable 806 discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, 807 Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Francis 808 Dupont, Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob 809 Hinden, Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik 810 Nordmark, Mike O'Dell, Michael Patton and Ken Powell. 812 11. References 814 [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing 815 Architecture", RFC 2373, July 1998. 817 [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable 818 Global Unicast Address Format". RFC 2374, July 1998. 820 [BITLBL] Crawford, M., "Binary Labels in the Domain Name System", 821 RFC 2673, August 1999. 823 [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, 824 August 1999. 826 [DNSCLAR] Elz, R and R. Bush, "Clarifications to the DNS 827 Specification", RFC 2181, July 1997. 829 [DNSIS] Mockapetris, P. V., "Domain names - implementation and 830 specification", RFC 1035, November 1987. 832 [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System 833 Security Extensions", RFC 2535, March 1999. 835 [KWORD] Bradner, S., "Key words for use in RFCs to Indicate 836 Requirement Levels," RFC 2119. 838 [RENUM] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 839 1900, February 1996. 841 Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: 842 Why would I want it and what is it anyway?", RFC 2071, January 843 1997. 845 Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address 846 Behaviour Today", RFC 2101, February 1997. 848 [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 849 IPv6 Hosts and Routers", RFC 1933, April 1996. 851 [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B. 852 Wellington, "Secret Key Transaction Authentication for DNS 853 (TSIG)", work in progress. 855 12. Authors' Addresses 857 Matt Crawford Christian Huitema Susan Thomson 858 Fermilab Telcordia Telcordia 859 MS 368 MCC 1J236B MCC 1C259B 860 PO Box 500 445 South Street 445 South Street 861 Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960 862 USA USA USA 864 +1 630 840-3461 +1 201 829-4266 +1 201 829-4514 865 crawdad@fnal.gov huitema@research.telcordia.com 866 set@research.telcordia.com