idnits 2.17.1 draft-ietf-ipngwg-dns-lookups-07.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 (March 8, 2000) is 8815 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 347, but not defined == Missing Reference: 'TSIG' is mentioned on line 844, 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') -- Possible downref: Non-RFC (?) normative reference: ref. 'TRANS' Summary: 12 errors (**), 0 flaws (~~), 5 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 March 8, 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 ................................................ 5 58 4.1. The A6 Record Type ...................................... 5 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.INT, 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 3.2. Underlying Mechanisms for Reverse Lookups 170 This section describes the new DNS features which this document 171 exploits. This section is an overview, not a specification of those 172 features. The reader is directed to the referenced documents for 173 more details on each. 175 3.2.1. Delegation on Arbitrary Boundaries 177 This new scheme for reverse lookups relies on a new type of DNS 178 label called the "bit-string label" [BITLBL]. This label compactly 179 represents an arbitrary string of bits which is treated as a 180 hierarchical sequence of one-bit domain labels. Resource records 181 can thereby be stored at arbitrary bit-boundaries. 183 Examples in section 6 will employ the following textual 184 representation for bit-string labels, which is a subset of the 185 syntax defined in [BITLBL]. A base indicator "x" for hexadecimal 186 and a sequence of hexadecimal digits is enclosed between "\[" and 187 "]". The bits denoted by the digits represent a sequence of one-bit 188 domain labels ordered from most to least significant. (This is the 189 opposite of the order they would appear if listed one bit at a time, 190 but it appears to be a convenient notation.) The digit string may 191 be followed by a slash ("/") and a decimal count. If omitted, the 192 implicit count is equal to four times the number of hexadecimal 193 digits. 195 Consecutive bit-string labels are equivalent (up to the limit 196 imposed by the size of the bit count field) to a single bit-string 197 label containing all the bits of the consecutive labels in the 198 proper order. As an example, either of the following domain names 199 could be used in a QCLASS=IN, QTYPE=PTR query to find the name of 200 the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32. 202 \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.INT. 204 \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.INT. 206 3.2.2. Reusable Zones 208 DNS address space delegation is implemented not by zone cuts and NS 209 records, but by a new analogue to the CNAME record, called the DNAME 210 resource record [DNAME]. The DNAME record provides alternate naming 211 to an entire subtree of the domain name space, rather than to a 212 single node. It causes some suffix of a queried name to be 213 substituted with a name from the DNAME record's RDATA. 215 For example, a resolver or server providing recursion, while looking 216 up a QNAME a.b.c.d.e.f may encounter a DNAME record 218 d.e.f. DNAME w.xy. 220 which will cause it to look for a.b.c.w.xy. 222 4. Specifications 224 4.1. The A6 Record Type 226 The A6 record type is specific to the IN (Internet) class and has 227 type number 38 (decimal). 229 4.1.1. Format 231 The RDATA portion of the A6 record contains two or three fields. 233 +-----------+------------------+-------------------+ 234 |Prefix len.| Address suffix | Prefix name | 235 | (1 octet) | (0..16 octets) | (0..255 octets) | 236 +-----------+------------------+-------------------+ 238 o A prefix length, encoded as an eight-bit unsigned integer with 239 value between 0 and 128 inclusive. 241 o An IPv6 address suffix, encoded in network order (high-order 242 octet first). There MUST be exactly enough octets in this field 243 to contain a number of bits equal to 128 minus prefix length, 244 with 0 to 7 leading pad bits to make this field an integral 245 number of octets. Pad bits, if present, MUST be set to zero 246 when loading a zone file and ignored (other than for SIG 247 [DNSSEC] verification) on reception. 249 o The name of the prefix, encoded as a domain name. By the rules 250 of [DNSIS], this name MUST NOT be compressed. 252 The domain name component SHALL NOT be present if the prefix length 253 is zero. The address suffix component SHALL NOT be present if the 254 prefix length is 128. 256 It is SUGGESTED that an A6 record intended for use as a prefix for 257 other A6 records have all the insignificant trailing bits in its 258 address suffix field set to zero. 260 4.1.2. Processing 262 A query with QTYPE=A6 causes type A6 and type NS additional section 263 processing for the prefix names, if any, in the RDATA field of the 264 A6 records in the answer section. This processing SHOULD be 265 recursively applied to the prefix names of A6 records included as 266 additional data. When space in the reply packet is a limit, 267 inclusion of additional A6 records takes priority over NS records. 269 It is an error for a A6 record with prefix length L1 > 0 to refer to 270 a domain name which owns a A6 record with a prefix length L2 > L1. 271 If such a situation is encountered by a resolver, the A6 record with 272 the offending (larger) prefix length MUST be ignored. Robustness 273 precludes signaling an error if addresses can still be formed from 274 valid A6 records, but it is SUGGESTED that zone maintainers from 275 time to time check all the A6 records their zones reference. 277 4.1.3. Textual Representation 279 The textual representation of the RDATA portion of the A6 resource 280 record in a zone file comprises two or three fields separated by 281 whitespace. 283 o A prefix length, represented as a decimal number between 0 and 284 128 inclusive, 286 o the textual representation of an IPv6 address as defined in 287 [AARCH] (although some leading and/or trailing bits may not be 288 significant), 290 o a domain name, if the prefix length is not zero. 292 The domain name MUST be absent if the prefix length is zero. The 293 IPv6 address MAY be be absent if the prefix length is 128. A number 294 of leading address bits equal to the prefix length SHOULD be zero, 295 either implicitly (through the :: notation) or explicitly, as 296 specified in section 4.1.1. 298 4.1.4. Name Resolution Procedure 300 To obtain the IPv6 address or addresses which belong to a given 301 name, a DNS client MUST obtain one or more complete chains of A6 302 records, each chain beginning with a record owned by the given name 303 and including a record owned by the prefix name in that record, and 304 so on recursively, ending with an A6 record with a prefix length of 305 zero. One IPv6 address is formed from one such chain by taking the 306 value of each bit position from the earliest A6 record in the chain 307 which validly covers that position, as indicated by the prefix 308 length. The set of all IPv6 addresses for the given name comprises 309 the addresses formed from all complete chains of A6 records 310 beginning at that name, discarding records which have invalid prefix 311 lengths as defined in section 4.1.2. 313 If some A6 queries fail and others succeed, a client might obtain a 314 non-empty but incomplete set of IPv6 addresses for a host. In many 315 situations this may be acceptable. The completeness of a set of A6 316 records may always be determined by inspection. 318 4.2. Zone Structure for Reverse Lookups 320 Very little of the new scheme's data actually appears under IP6.INT; 321 only the first level of delegation needs to be under that domain. 322 More levels of delegation could be placed under IP6.INT if some 323 top-level delegations were done via NS records instead of DNAME 324 records, but this would incur some cost in renumbering ease at the 325 level of TLAs [AGGR]. Therefore, it is declared here that all 326 address space delegations SHOULD be done by the DNAME mechanism 327 rather than NS. 329 In addition, since uniformity in deployment will simplify 330 maintenance of address delegations, it is SUGGESTED that address and 331 prefix information be stored immediately below a DNS label "IP6". 332 Stated another way, conformance with this suggestion would mean that 333 "IP6" is the first label in the RDATA field of DNAME records which 334 support IPv6 reverse lookups. 336 When any "reserved" or "must be zero" bits are adjacent to a 337 delegation boundary, the higher-level entity MUST retain those bits 338 in its own control and delegate only the bits over which the lower- 339 level entity has authority. 341 To find the name of a node given its IPv6 address, a DNS client MUST 342 perform a query with QCLASS=IN, QTYPE=PTR on the name formed from 343 the 128 bit address as one or more bit-string labels [BITLBL], 344 followed by the two standard labels "IP6.INT". If recursive service 345 was not obtained from a server and the desired PTR record was not 346 returned, the resolver MUST handle returned DNAME records as 347 specified in [DNAME], and NS records as specified in [DNSCF], and 348 iterate. 350 5. Modifications to Existing Query Types 352 All existing query types that perform type A additional section 353 processing, i.e. the name server (NS), mail exchange (MX), and 354 mailbox (MB) query types, and the experimental AFS data base (AFSDB) 355 and route through (RT) types, must be redefined to perform type A, 356 A6 and AAAA additional section processing, with type A having the 357 highest priority for inclusion and type AAAA the lowest. This 358 redefinition means that a name server may add any relevant IPv4 and 359 IPv6 address information available locally to the additional section 360 of a response when processing any one of the above queries. The 361 recursive inclusion of A6 records referenced by A6 records already 362 included in the additional section is OPTIONAL. 364 6. Usage Illustrations 366 This section provides examples of use of the mechanisms defined in 367 the previous section. All addresses and domains mentioned here are 368 intended to be fictitious and for illustrative purposes only. 369 Example delegations will be on 4-bit boundaries solely for 370 readability; this specification is indifferent to bit alignment. 372 Use of the IPv6 aggregatable address format [AGGR] is assumed in the 373 examples. 375 6.1. A6 Record Chains 377 Let's take the example of a site X that is multi-homed to two 378 "intermediate" providers A and B. The provider A is itself multi- 379 homed to two "transit" providers, C and D. The provider B gets its 380 transit service from a single provider, E. For simplicity suppose 381 that C, D and E all belong to the same top-level aggregate (TLA) 382 with identifier (including format prefix) '2345', and the TLA 383 authority at ALPHA-TLA.ORG assigns to C, D and E respectively the 384 next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 385 and 2345:000E::/32. 387 C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the 388 prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to 389 B. 391 A assigns to X the subscriber identification '11' and B assigns the 392 subscriber identification '22'. As a result, the site X inherits 393 three address prefixes: 395 o 2345:00C1:CA11::/48 from A, for routes through C. 396 o 2345:00D2:DA11::/48 from A, for routes through D. 397 o 2345:000E:EB22::/48 from B, for routes through E. 399 Let us suppose that N is a node in the site X, that it is assigned 400 to subnet number 1 in this site, and that it uses the interface 401 identifier '1234:5678:9ABC:DEF0'. In our configuration, this node 402 will have three addresses: 404 o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 405 o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 406 o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 408 6.1.1. Authoritative Data 410 We will assume that the site X is represented in the DNS by the 411 domain name X.EXAMPLE, while A, B, C, D and E are represented by 412 A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we 413 assume a subdomain "IP6" that will hold the corresponding prefixes. 414 The node N is identified by the domain name N.X.EXAMPLE. The 415 following records would then appear in X's DNS. 417 $ORIGIN X.EXAMPLE. 418 N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 419 SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 420 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. 421 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. 423 And elsewhere there would appear 425 SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. 426 SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET. 428 SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET. 430 A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG. 432 A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG. 434 B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG. 436 C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: 437 D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: 438 E.NET.ALPHA-TLA.ORG. A6 0 2345:000E:: 440 6.1.2. Glue 442 When, as is common, some or all DNS servers for X.EXAMPLE are within 443 the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry 444 enough "glue" information to enable DNS clients to reach those 445 nameservers. This is true in IPv6 just as in IPv4. However, the A6 446 record affords the DNS administrator some choices. The glue could 447 be any of 449 o a minimal set of A6 records duplicated from the X.EXAMPLE zone, 451 o a (possibly smaller) set of records which collapse the structure 452 of that minimal set, 454 o or a set of A6 records with prefix length zero, giving the 455 entire global addresses of the servers. 457 The trade-off is ease of maintenance against robustness. The best 458 and worst of both may be had together by implementing either the 459 first or second option together with the third. To illustrate the 460 glue options, suppose that X.EXAMPLE is served by two nameservers 461 NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers 462 ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively. 463 Then the top-level zone EXAMPLE would include one (or more) of the 464 following sets of A6 records as glue. 466 $ORIGIN EXAMPLE. ; first option 467 X NS NS1.X 468 NS NS2.X 469 NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X 470 NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X 471 SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X 472 SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X 473 IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. 474 IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. 476 $ORIGIN EXAMPLE. ; second option 477 X NS NS1.X 478 NS NS2.X 479 NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET. 480 A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET. 481 NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET. 482 A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET. 484 $ORIGIN EXAMPLE. ; third option 485 X NS NS1.X 486 NS NS2.X 487 NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111 488 A6 0 2345:00D2:DA11:1:1:11:111:1111 489 A6 0 2345:000E:EB22:1:1:11:111:1111 490 NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222 491 A6 0 2345:00D2:DA11:2:2:22:222:2222 492 A6 0 2345:000E:EB22:2:2:22:222:2222 494 The first and second glue options are robust against renumbering of 495 X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if 496 those providers' own DNS is unreachable. The glue records of the 497 third option are robust against DNS failures elsewhere than the 498 zones EXAMPLE and X.EXAMPLE themselves, but must be updated when X's 499 address space is renumbered. 501 If the EXAMPLE zone includes redundant glue, for instance the union 502 of the A6 records of the first and third options, then under normal 503 circumstances duplicate IPv6 addresses will be derived by DNS 504 clients. But if provider DNS fails, addresses will still be 505 obtained from the zero-prefix-length records, while if the EXAMPLE 506 zone lags behind a renumbering of X.EXAMPLE, half of the addresses 507 obtained by DNS clients will still be up-to-date. 509 The zero-prefix-length glue records can of course be automatically 510 generated and/or checked in practice. 512 6.1.3. Variations 514 Several more-or-less arbitrary assumptions are reflected in the 515 above structure. All of the following choices could have been made 516 differently, according to someone's notion of convenience or an 517 agreement between two parties. 519 First, that site X has chosen to put subnet information in a 520 separate A6 record rather than incorporate it into each node's 521 A6 records. 523 Second, that site X is referred to as "SUBSCRIBER-X" by both of 524 its providers A and B. 526 Third, that site X chose to indirect its provider information 527 through A6 records at IP6.X.EXAMPLE containing no significant 528 bits. An alternative would have been to replicate each subnet 529 record for each provider. 531 Fourth, B and E used a slightly different prefix naming 532 convention between themselves than did A, C and D. Each 533 hierarchical pair of network entities must arrange this naming 534 between themselves. 536 Fifth, that the upward prefix referral chain topped out at 537 ALPHA-TLA.ORG. There could have been another level which 538 assigned the TLA values and holds A6 records containing those 539 bits. 541 Finally, the above structure reflects an assumption that address 542 fields assigned by a given entity are recorded only in A6 records 543 held by that entity. Those bits could be entered into A6 records in 544 the lower-level entity's zone instead, thus: 546 IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET. 547 IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET. 549 IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET. 550 and so on. 552 Or the higher-level entities could hold both sorts of A6 records 553 (with different DNS owner names) and allow the lower-level entities 554 to choose either mode of A6 chaining. But the general principle of 555 avoiding data duplication suggests that the proper place to store 556 assigned values is with the entity that assigned them. 558 It is possible, but not necessarily recommended, for a zone 559 maintainer to forego the renumbering support afforded by the 560 chaining of A6 records and to record entire IPv6 addresses within 561 one zone file. 563 6.2. Reverse Mapping Zones 565 Supposing that address space assignments in the TLAs with Format 566 Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in 567 zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then 568 the IP6.INT zone would include 570 $ORIGIN IP6.INT. 571 \[x234500/24] DNAME IP6.ALPHA-TLA.ORG. 572 \[x267800/24] DNAME IP6.BRAVO-TLA.ORG. 573 \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY. 575 Eight trailing zero bits have been included in each TLA ID to 576 reflect the eight reserved bits in the current aggregatable global 577 unicast addresses format [AGGR]. 579 6.2.1. The TLA level 581 ALPHA-TLA's assignments to network providers C, D and E are 582 reflected in the reverse data as follows. 584 \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. 585 \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET. 586 \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET. 588 6.2.2. The ISP level 590 The providers A through E carry the following delegation information 591 in their zone files. 593 \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. 594 \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET. 595 \[xEB/8].IP6.E.NET. DNAME IP6.B.NET. 596 \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. 597 \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE. 599 Note that some domain names appear in the RDATA of more than one 600 DNAME record. In those cases, one zone is being used to map 601 multiple prefixes. 603 6.2.3. The Site Level 605 Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to- 606 name translations. This domain is now referenced by two different 607 DNAME records held by two different providers. 609 $ORIGIN IP6.X.EXAMPLE. 610 \[x0001/16] DNAME SUBNET-1 611 \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. 612 and so on. 614 SUBNET-1 need not have been named in a DNAME record; the subnet bits 615 could have been joined with the interface identifier. But if 616 subnets are treated alike in both the A6 records and in the reverse 617 zone, it will always be possible to keep the forward and reverse 618 definition data for each prefix in one zone. 620 6.3. Lookups 622 A DNS resolver looking for a hostname for the address 623 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the 624 DNAME records shown above and would form new queries. Assuming that 625 it began the process knowing servers for IP6.INT, but that no server 626 it consulted provided recursion and none had other useful additional 627 information cached, the sequence of queried names and responses 628 would be (all with QCLASS=IN, QTYPE=PTR): 630 To a server for IP6.INT: 631 QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.INT. 633 Answer: 634 \[x234500/24].IP6.INT. DNAME IP6.ALPHA-TLA.ORG. 636 To a server for IP6.ALPHA-TLA.ORG: 637 QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG. 639 Answer: 640 \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. 642 To a server for IP6.C.NET.: 643 QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET. 645 Answer: 646 \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. 648 To a server for IP6.A.NET.: 649 QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET. 651 Answer: 652 \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. 654 To a server for IP6.X.EXAMPLE.: 655 QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE. 657 Answer: 658 \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. 659 \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE. 661 All the DNAME (and NS) records acquired along the way can be cached 662 to expedite resolution of addresses topologically near to this 663 address. And if another global address of N.X.EXAMPLE were resolved 664 within the TTL of the final PTR record, that record would not have 665 to be fetched again. 667 6.4. Operational Note 669 In the illustrations in section 6.1, hierarchically adjacent 670 entities, such as a network provider and a customer, must agree on a 671 DNS name which will own the definition of the delegated prefix(es). 672 One simple convention would be to use a bit-string label 673 representing exactly the bits which are assigned to the lower-level 674 entity by the higher. For example, "SUBSCRIBER-X" could be replaced 675 by "\[x11/8]". This would place the A6 record(s) defining the 676 delegated prefix at exactly the same point in the DNS tree as the 677 DNAME record associated with that delegation. The cost of this 678 simplification is that the lower-level zone must update its upward- 679 pointing A6 records when it is renumbered. This cost may be found 680 quite acceptable in practice. 682 7. Transition from RFC 1886 and Deployment Notes 684 When prefixes have been "delegated upward" with A6 records, the 685 number of DNS resource records required to establish a single IPv6 686 address increases by some non-trivial factor. Those records will 687 typically, but not necessarily, come from different DNS zones (which 688 can independently suffer failures for all the usual reasons). When 689 obtaining multiple IPv6 addresses together, this increase in RR 690 count will be proportionally less -- and the total size of a DNS 691 reply might even decrease -- if the addresses are topologically 692 clustered. But the records could still easily exceed the space 693 available in a UDP response which returns a large RRset [DNSCLAR] to 694 an MX, NS, or SRV query, for example. The possibilities for overall 695 degradation of performance and reliability of DNS lookups are 696 numerous, and increase with the number of prefix delegations 697 involved, especially when those delegations point to records in 698 other zones. 700 DNS Security [DNSSEC] addresses the trustworthiness of cached data, 701 which is a problem intrinsic to DNS, but the cost of applying this 702 to an IPv6 address is multiplied by a factor which may be greater 703 than the number of prefix delegations involved if different 704 signature chains must be verified for different A6 records. If a 705 trusted centralized caching server (as in [TSIG], for example) is 706 used, this cost might be amortized to acceptable levels. One new 707 phenomenon is the possibility that IPv6 addresses may be formed from 708 a A6 records from a combination of secure and unsecured zones. 710 Until more deployment experience is gained with the A6 record, it is 711 recommended that prefix delegations be limited to one or two levels. 712 A reasonable phasing-in mechanism would be to start with no prefix 713 delegations (all A6 records having prefix length 0) and then to move 714 to the use of a single level of delegation within a single zone. 715 (If the TTL of the "prefix" A6 records is kept to an appropriate 716 duration the capability for rapid renumbering is not lost.) More 717 aggressively flexible delegation could be introduced for a subset of 718 hosts for experimentation. 720 7.1. Transition from AAAA and Coexistence with A Records 722 Administrators of zones which contain A6 records can easily 723 accommodate deployed resolvers which understand AAAA records but not 724 A6 records. Such administrators can do automatic generation of AAAA 725 records for all of a zone's names which own A6 records by a process 726 which mimics the resolution of a hostname to an IPv6 address (see 727 section 4.1.4). Attention must be paid to the TTL assigned to a 728 generated AAAA record, which MUST be no more than the minimum of the 729 TTLs of the A6 records that were used to form the IPv6 address in 730 that record. For full robustness, those A6 records which were in 731 different zones should be monitored for changes (in TTL or RDATA) 732 even when there are no changes to zone for which AAAA records are 733 being generated. If the zone is secure [DNSSEC], the generated AAAA 734 records MUST be signed along with the rest of the zone data. 736 A zone-specific heuristic MAY be used to avoid generation of AAAA 737 records for A6 records which record prefixes, although such 738 superfluous records would be relatively few in number and harmless. 739 Examples of such heuristics include omitting A6 records with a 740 prefix length less than the largest value found in the zone file, or 741 records with an address suffix field with a certain number of 742 trailing zero bits. 744 On the client side, when looking up and IPv6 address, the order of 745 A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA; 746 AAAA, then A6; A6 only; or both in parallel. The default order (or 747 only order, if not configurable) MUST be to try A6 first, then AAAA. 748 If and when the AAAA becomes deprecated a new document will change 749 the default. 751 The guidelines and options for precedence between IPv4 and IPv6 752 addresses are specified in [TRANS]. All mentions of AAAA records in 753 that document are henceforth to be interpreted as meaning A6 and/or 754 AAAA records in the order specified in the previous paragraph. 756 7.2. Transition from Nibble Labels to Binary Labels 758 Implementations conforming to RFC 1886 perform reverse lookups as 759 follows: 761 An IPv6 address is represented as a name in the IP6.INT domain 762 by a sequence of nibbles separated by dots with the suffix 763 ".IP6.INT". The sequence of nibbles is encoded in reverse order, 764 i.e. the low-order nibble is encoded first, followed by the next 765 low-order nibble and so on. Each nibble is represented by a 766 hexadecimal digit. For example, a name for the address 767 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in 768 section 6.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.- 769 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." 771 Implementations conforming to this specification will perform a 772 lookup of a binary label in IP6.INT as specified in Section 3.2. It 773 is RECOMMENDED that for a transition period implementations first 774 lookup the binary label in IP6.INT and if this fails try to lookup 775 the 'nibble' label in IP6.INT. 777 8. Security Considerations 779 The signing authority [DNSSEC] for the A6 records which determine an 780 IPv6 address is distributed among several entities, reflecting the 781 delegation path of the address space which that address occupies. 782 DNS Security is fully applicable to bit-string labels and DNAME 783 records. And just as in IPv4, verification of name-to-address 784 mappings is logically independent of verification of address-to-name 785 mappings. 787 With or without DNSSEC, the incomplete but non-empty address set 788 scenario of section 4.1.4 could be caused by selective interference 789 with DNS lookups. If in some situation this would be more harmful 790 than complete DNS failure, it might be mitigated on the client side 791 by refusing to act on an incomplete set, or on the server side by 792 listing all addresses in A6 records with prefix length 0. 794 9. IANA Considerations 796 The A6 resource record has been assigned a Type value of 38. 798 10. Acknowledgments 800 The authors would like to thank the following persons for valuable 801 discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, 802 Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Francis 803 Dupont, Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob 804 Hinden, Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik 805 Nordmark, Mike O'Dell, Michael Patton and Ken Powell. 807 11. References 809 [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing 810 Architecture", RFC 2373, July 1998. 812 [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable 813 Global Unicast Address Format". RFC 2374, July 1998. 815 [BITLBL] Crawford, M., "Binary Labels in the Domain Name System", 816 RFC 2673, August 1999. 818 [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, 819 August 1999. 821 [DNSCLAR] Elz, R and R. Bush, "Clarifications to the DNS 822 Specification", RFC 2181, July 1997. 824 [DNSIS] Mockapetris, P. V., "Domain names - implementation and 825 specification", RFC 1035, November 1987. 827 [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System 828 Security Extensions", RFC 2535, March 1999. 830 [KWORD] Bradner, S., "Key words for use in RFCs to Indicate 831 Requirement Levels," RFC 2119. 833 [RENUM] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 834 1900, February 1996. 836 Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: 837 Why would I want it and what is it anyway?", RFC 2071, January 838 1997. 840 Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address 841 Behaviour Today", RFC 2101, February 1997. 843 [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 844 IPv6 Hosts and Routers", RFC 1933, April 1996. [TSIG] Vixie, 845 P., Gudmundsson, O., Eastlake, D. 3rd and B. Wellington, "Secret 846 Key Transaction Authentication for DNS (TSIG)", work in 847 progress. 849 12. Authors' Addresses 851 Matt Crawford Christian Huitema Susan Thomson 852 Fermilab Telcordia Telcordia 853 MS 368 MCC 1J236B MCC 1C259B 854 PO Box 500 445 South Street 445 South Street 855 Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960 856 USA USA USA 858 +1 630 840-3461 +1 201 829-4266 +1 201 829-4514 859 crawdad@fnal.gov huitema@research.telcordia.com 860 set@research.telcordia.com