idnits 2.17.1 draft-ietf-ipngwg-dns-lookups-05.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? ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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 are 12 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 17 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 (October 14, 1999) is 8955 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) ** 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) Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 Bellcore 6 October 14, 1999 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 RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 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 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 1. Abstract 29 This document defines changes to the Domain Name System to support 30 renumberable and aggregatable IPv6 addressing. The changes include 31 a new resource record type to store an IPv6 address in a manner 32 which expedites network renumbering, one new query type and updated 33 definitions of existing query types that return Internet addresses 34 as part of additional section processing. 36 For lookups keyed on IPv6 addresses (often called reverse lookups), 37 this document defines a new zone structure which allows a zone to be 38 used without modification for parallel copies of an address space 39 (as for a multihomed provider or site) and across network 40 renumbering events. 42 2. Introduction 44 Maintenance of address information in the DNS is one of several 45 obstacles which have prevented site and provider renumbering from 46 being feasible in IP version 4. Arguments about the importance of 47 network renumbering for the preservation of a stable routing system 48 and for other purposes may be read in documents cited here as 49 [RENUM]. To support the storage of IPv6 addresses without impeding 50 renumbering we define the following extensions. 52 o A new resource record type, "A6", is defined to map a domain 53 name to an IPv6 address, with a provision for indirection for 54 leading "prefix" bits. 56 o Existing queries that perform additional section processing to 57 locate IPv4 addresses are redefined to do that processing for 58 both IPv4 and IPv6 addresses. 60 o A new domain, IP6.INT, is defined to support lookups based on 61 IPv6 address. 63 o A new prefix-delegation method is defined, relying on new DNS 64 features [BITLBL, DNAME]. 66 The changes are designed to be compatible with existing application 67 programming interfaces. The existing support for IPv4 addresses is 68 retained. Transition issues related to the coexistence of both IPv4 69 and IPv6 addresses in DNS are discussed in [TRANS]. 71 This memo proposes a replacement for the specification in RFC 1886 72 and a departure from current implementation practices. The changes 73 are designed to facilitate network renumbering and multihoming. 74 Domains employing the A6 record for IPv6 addresses can insert 75 automatically-generated AAAA records in zone files to ease 76 transition. It is expected that after a reasonable period, RFC 1886 77 will become Historic. 79 The next three major sections of this document are an overview of 80 the facilities defined or employed by this specification, the 81 specification itself, and examples of use. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [KWORD]. The key 86 word "SUGGESTED" signifies a strength between MAY and SHOULD: it is 87 believed that compliance with the suggestion has tangible benefits 88 in most instances. 90 3. Overview 92 This section provides an overview of the DNS facilities for storage 93 of IPv6 addresses and for lookups based on IPv6 address, including 94 those defined here and elsewhere. 96 3.1. Name-to-Address Lookup 98 IPv6 addresses are stored in one or more A6 resource records. A 99 single A6 record may include a complete IPv6 address, or a 100 contiguous portion of an address and information leading to one or 101 more prefixes. Prefix information comprises a prefix length and a 102 DNS name which is in turn the owner of one or more A6 records 103 defining the prefix or prefixes which are needed to form one or more 104 complete IPv6 addresses. When the prefix length is zero, no DNS 105 name is present and all the leading bits of the address are 106 significant. There may be multiples levels of indirection and the 107 existence of multiple A6 records at any level multiplies the number 108 of IPv6 addresses which are formed. 110 An application looking up an IPv6 address will generally cause the 111 DNS resolver to access several A6 records, and multiple IPv6 112 addresses may be returned even if the queried name was the owner of 113 only one A6 record. The authenticity of the returned address(es) 114 cannot be directly verified by DNS Security [DNSSEC]. The A6 115 records which contributed to the address(es) may of course be 116 verified if signed. 118 3.2. Underlying Mechanisms for Reverse Lookups 120 This section describes the new DNS features which this document 121 exploits. This section is an overview, not a specification of those 122 features. The reader is directed to the referenced documents for 123 more details on each. 125 3.2.1. Delegation on Arbitrary Boundaries 127 This new scheme for reverse lookups relies on a new type of DNS 128 label called the "bit-string label" [BITLBL]. This label compactly 129 represents an arbitrary string of bits which is treated as a 130 hierarchical sequence of one-bit domain labels. Resource records 131 can thereby be stored on arbitrary bit-boundaries. 133 Examples in section 6 will employ the following textual 134 representation for bit-string labels, which is a subset of the 135 syntax defined in [BITLBL]. A base indicator "x" for hexadecimal 136 and a sequence of hexadecimal digits is enclosed between "\[" and 137 "]". The bits denoted by the digits represent a sequence of one-bit 138 domain labels ordered from most to least significant. (This is the 139 opposite of the order they would appear if listed one bit at a time, 140 but it appears to be a convenient notation.) The digit string may 141 be followed by a slash ("/") and a decimal count. If omitted, the 142 implicit count is equal to four times the number of hexadecimal 143 digits. 145 Consecutive bit-string labels are equivalent (up to the limit 146 imposed by the size of the bit count field) to a single bit-string 147 label containing all the bits of the consecutive labels in the 148 proper order. As an example, either of the following domain names 149 could be used in a QCLASS=IN, QTYPE=PTR query to find the name of 150 the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32. 152 \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.INT. 154 \[x0A0020FFFE812B32/64].\[x0009/16]. 155 \[x07C00040/32].\[xFFF0/13].\[x2/3].IP6.INT. 157 Note that bits are left-justified in a hexadecimal string. 159 3.2.2. Reusable Zones 161 DNS address space delegation is implemented not by zone cuts and NS 162 records, but by a new analogue to the CNAME record, called the DNAME 163 resource record [DNAME]. The DNAME record provides alternate naming 164 to an entire subtree of the domain name space, rather than to a 165 single node. It causes some suffix of a queried name to be 166 substituted with a name from the DNAME record's RDATA. 168 For example, a resolver or server providing recursion, while looking 169 up a QNAME a.b.c.d.e.f may encounter a DNAME record 171 d.e.f. DNAME w.xy. 173 which will cause it to look for a.b.c.w.xy. 175 4. Specifications 177 4.1. The A6 Record Type 179 The A6 record type is specific to the IN (Internet) class and has 180 type number 38 (decimal). 182 4.1.1. Format 184 The RDATA portion of the A6 record contains two or three fields. 186 +-----------+------------------+-------------------+ 187 |Prefix len.| Address suffix | Prefix name | 188 | (1 octet) | (0..16 octets) | (0..255 octets) | 189 +-----------+------------------+-------------------+ 191 o A prefix length, encoded as an eight-bit unsigned integer with 192 value between 0 and 128 inclusive. 194 o An IPv6 address suffix, encoded in network order (high-order 195 octet first). There MUST be exactly enough octets in this field 196 to contain a number of bits equal to 128 minus prefix length, 197 with 0 to 7 leading pad bits to make this field an integral 198 number of octets. Pad bits, if present, MUST be set to zero 199 when loading a zone file and ignored (other than for SIG 200 [DNSSEC] verification) on reception. 202 o The name of the prefix, encoded as a domain name. By the rules 203 of [DNSIS], this name MUST NOT be compressed. 205 The domain name component SHALL NOT be present if the prefix length 206 is zero. The address suffix component SHALL NOT be present if the 207 prefix length is 128. 209 It is SUGGESTED that an A6 record intended for use as a prefix for 210 other A6 records have all the insignificant trailing bits in its 211 address suffix field set to zero. 213 4.1.2. Processing 215 A query with QTYPE=A6 causes type A6 and type NS additional section 216 processing for the prefix names, if any, in the RDATA field of the 217 A6 records in the answer section. This processing SHOULD be 218 recursively applied to the prefix names of A6 records included as 219 additional data. When space in the reply packet is a limit, 220 inclusion of additional A6 records takes priority over NS records. 222 It is an error for a A6 record with prefix length L1 > 0 to refer to 223 a domain name which owns a A6 record with a prefix length L2 > L1. 224 If such a situation is encountered by a resolver, the A6 record with 225 the offending (larger) prefix length MUST be ignored. Robustness 226 precludes signaling an error if addresses can still be formed from 227 valid A6 records, but it is SUGGESTED that zone maintainers from 228 time to time check all the A6 records their zones reference. 230 4.1.3. Textual Representation 232 The textual representation of the RDATA portion of the A6 resource 233 record in a zone file comprises two or three fields separated by 234 whitespace. 236 o A prefix length, represented as a decimal number between 0 and 237 128 inclusive, 239 o the textual representation of an IPv6 address as defined in 240 [AARCH] (although some leading and/or trailing bits may not be 241 significant), 243 o a domain name, if the prefix length is not zero. 245 The domain name MUST be absent if the prefix length is zero. The 246 IPv6 address MAY be be absent if the prefix length is 128. A number 247 of leading address bits equal to the prefix length SHOULD be zero, 248 either implicitly (through the :: notation) or explicitly, as 249 specified in section 4.1.1. 251 4.1.4. Name Resolution Procedure 253 To obtain the IPv6 address or addresses which belong to a given 254 hostname, a DNS client MUST obtain one or more complete chains of A6 255 records, each chain beginning with a record owned by the given 256 hostname and including a record owned by the prefix name in that 257 record, and so on recursively, ending with an A6 record with a 258 prefix length of zero. One IPv6 address is formed from one such 259 chain by taking the value of each bit position from the earliest A6 260 record which validly covers that position, as indicated by the 261 prefix length. The set of all IPv6 addresses for the given hostname 262 comprises the addresses formed from all complete chains of A6 263 records beginning at that hostname, discarding records which have 264 invalid prefix lengths as defined in section 4.1.2. 266 If some A6 queries fail and others succeed, a client might obtain a 267 non-empty but incomplete set of IPv6 addresses for a host. In many 268 situations this may be acceptable. The completeness of a set of A6 269 records may always be determined by inspection. 271 4.2. Zone Structure for Reverse Lookups 273 Very little of the new scheme's data actually appears under IP6.INT; 274 only the first level of delegation needs to be under that domain. 275 More levels of delegation could be placed under IP6.INT if some 276 top-level delegations were done via NS records instead of DNAME 277 records, but this would incur some cost in renumbering ease at the 278 level of TLAs [AGGR]. Therefore, it is declared here that all 279 address space delegations SHOULD be done by the DNAME mechanism 280 rather than NS. 282 In addition, since uniformity in deployment will simplify 283 maintenance of address delegations, it is SUGGESTED that address and 284 prefix information be stored immediately below a DNS label "IP6". 285 Stated another way, conformance with this suggestion would mean that 286 "IP6" is the first label in the RDATA field of DNAME records which 287 support IPv6 reverse lookups. 289 When any "reserved" or "must be zero" bits are adjacent to a 290 delegation boundary, the higher-level entity MUST retain those bits 291 in its own control and delegate only the bits over which the lower- 292 level entity has authority. 294 To find the name of a node given its IPv6 address, a DNS client MUST 295 perform a query with QCLASS=IN, QTYPE=PTR on the name formed from 296 the 128 bit address as one or more bit-string labels [BITLBL], 297 followed by the two standard labels "IP6.INT". If recursive service 298 was not obtained from a server and the desired PTR record was not 299 returned, the resolver MUST handle returned DNAME records as 300 specified in [DNAME] and iterate. 302 5. Modifications to Existing Query Types 304 All existing query types that perform type A additional section 305 processing, i.e. the name server (NS), mail exchange (MX), and 306 mailbox (MB) query types, and the experimental AFS data base (AFSDB) 307 and route through (RT) types, must be redefined to perform type A, 308 A6 and AAAA additional section processing, with type A having the 309 highest priority for inclusion and type AAAA the lowest. This 310 redefinition means that a name server may add any relevant IPv4 and 311 IPv6 address information available locally to the additional section 312 of a response when processing any one of the above queries. The 313 recursive inclusion of A6 records referenced by A6 records already 314 included in the additional section is OPTIONAL. 316 6. Usage Illustrations 318 This section provides examples of use of the mechanisms defined in 319 the previous section. All addresses and domains mentioned here are 320 intended to be fictitious and for illustrative purposes only. 321 Example delegations will be on 4-bit boundaries solely for 322 readability; this specification is indifferent to bit alignment. 324 Use of the IPv6 aggregatable address format [AGGR] is assumed in the 325 examples. 327 6.1. A6 Record Chains 329 Let's take the example of a site X that is multi-homed to two 330 "intermediate" providers A and B. The provider A is itself multi- 331 homed to two "transit" providers, C and D. The provider B gets its 332 transit service from a single provider, E. For simplicity suppose 333 that C, D and E all belong to the same top-level aggregate (TLA) 334 with identifier (including format prefix) '2345', and the TLA 335 authority at ALPHA-TLA.ORG assigns to C, D and E respectively the 336 next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 337 and 2345:000E::/32. 339 C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the 340 prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to 341 B. 343 A assigns to X the subscriber identification '11' and B assigns the 344 subscriber identification '22'. As a result, the site X inherits 345 three address prefixes: 347 o 2345:00C1:CA11::/48 from A, for routes through C. 348 o 2345:00D2:DA11::/48 from A, for routes through D. 349 o 2345:000E:EB22::/48 from B, for routes through E. 351 Let us suppose that N is a node in the site X, that it is assigned 352 to subnet number 1 in this site, and that it uses the interface 353 identifier '1234:5678:9ABC:DEF0'. In our configuration, this node 354 will have three addresses: 356 o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 357 o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 358 o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 360 6.1.1. Authoritative Data 362 We will assume that the site X is represented in the DNS by the 363 domain name X.EXAMPLE, while A, B, C, D and E are represented by 364 A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we 365 assume a subdomain "IP6" that will hold the corresponding prefixes. 366 The node N is identified by the domain name N.X.EXAMPLE. The 367 following records would then appear in X's DNS. 369 $ORIGIN X.EXAMPLE. 370 N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 371 SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 372 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. 373 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. 375 And elsewhere there would appear 377 SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. 378 SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET. 380 SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET. 382 A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG. 384 A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG. 386 B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG. 388 C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: 389 D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: 390 E.NET.ALPHA-TLA.ORG. A6 0 2345:000E:: 392 6.1.2. Glue 394 When, as is common, some or all DNS servers for X.EXAMPLE are within 395 the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry 396 enough "glue" information to enable DNS clients to reach those 397 nameservers. This is true in IPv6 just as in IPv4. However, the A6 398 record affords the DNS administrator some choices. The glue could 399 be any of 400 o a minimal set of A6 records duplicated from the X.EXAMPLE zone, 402 o a (possibly smaller) set of records which collapse the structure 403 of that minimal set, 405 o or a set of A6 records with prefix length zero, giving the 406 entire global addresses of the servers. 408 The trade-off is ease of maintenance against robustness. The best 409 and worst of both may be had together by implementing either the 410 first or second option together with the third. To illustrate the 411 glue options, suppose that X.EXAMPLE is served by two nameservers 412 NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers 413 ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively. 414 Then the top-level zone EXAMPLE would include one (or more) of the 415 following sets of A6 records as glue. 417 $ORIGIN EXAMPLE. ; first option 418 X NS NS1.X 419 NS NS2.X 420 NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X 421 NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X 422 SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X 423 SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X 424 IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. 425 IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. 427 $ORIGIN EXAMPLE. ; second option 428 X NS NS1.X 429 NS NS2.X 430 NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET. 431 A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET. 432 NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET. 433 A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET. 435 $ORIGIN EXAMPLE. ; third option 436 X NS NS1.X 437 NS NS2.X 438 NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111 439 A6 0 2345:00D2:DA11:1:1:11:111:1111 440 A6 0 2345:000E:EB22:1:1:11:111:1111 441 NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222 442 A6 0 2345:00D2:DA11:2:2:22:222:2222 443 A6 0 2345:000E:EB22:2:2:22:222:2222 445 The first and second glue options are robust against renumbering of 446 X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if 447 those providers' own DNS is unreachable. The glue records of the 448 third option are robust against DNS failures elsewhere than the 449 zones EXAMPLE and X.EXAMPLE themselves, but must be updated when X's 450 address space is renumbered. 452 If the EXAMPLE zone includes redundant glue, for instance the union 453 of the A6 records of the first and third options, then under normal 454 circumstances duplicate IPv6 addresses will be derived by DNS 455 clients. But if provider DNS fails, addresses will still be 456 obtained from the zero-prefix-length records, while if the EXAMPLE 457 zone lags behind a renumbering of X.EXAMPLE, half of the addresses 458 obtained by DNS clients will still be up-to-date. 460 The zero-prefix-length glue records can of course be automatically 461 generated and/or checked in practice. 463 6.1.3. Variations 465 Several more-or-less arbitrary assumptions are reflected in the 466 above structure. All of the following choices could have been made 467 differently, according to someone's notion of convenience or an 468 agreement between two parties. 470 First, that site X has chosen to put subnet information in a 471 separate A6 record rather than incorporate it into each node's 472 A6 records. 474 Second, that site X is referred to as "SUBSCRIBER-X" by both of 475 its providers A and B. 477 Third, that site X chose to indirect its provider information 478 through A6 records at IP6.X.EXAMPLE containing no significant 479 bits. An alternative would have been to replicate each subnet 480 record for each provider. 482 Fourth, B and E used a slightly different prefix naming 483 convention between themselves than did A, C and D. Each 484 hierarchical pair of network entities must arrange this naming 485 between themselves. 487 Fifth, that the upward prefix referral chain topped out at 488 ALPHA-TLA.ORG. There could have been another level which 489 assigned the TLA values and holds A6 records containing those 490 bits. 492 Finally, the above structure reflects an assumption that address 493 fields assigned by a given entity are recorded only in A6 records 494 held by that entity. Those bits could be entered into A6 records in 495 the lower-level entity's zone instead, thus: 497 IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET. 498 IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET. 500 IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET. 501 and so on. 503 Or the higher-level entities could hold both sorts of A6 records 504 (with different DNS owner names) and allow the lower-level entities 505 to choose either mode of A6 chaining. But the general principle of 506 avoiding data duplication suggests that the proper place to store 507 assigned values is with the entity that assigned them. 509 It is possible, but not necessarily recommended, for a zone 510 maintainer to forego the renumbering support afforded by the 511 chaining of A6 records and to record entire IPv6 addresses within 512 one zone file. 514 6.2. Reverse Mapping Zones 516 Supposing that address space assignments in the TLAs with Format 517 Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in 518 zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then 519 the IP6.INT zone would include 521 $ORIGIN IP6.INT. 522 \[x234500/24] DNAME IP6.ALPHA-TLA.ORG. 523 \[x267800/24] DNAME IP6.BRAVO-TLA.ORG. 524 \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY. 526 Eight trailing zero bits have been included in each TLA ID to 527 reflect the eight reserved bits in the current aggregatable global 528 unicast addresses format [AGGR]. 530 6.2.1. The TLA level 532 ALPHA-TLA's assignments to network providers C, D and E are 533 reflected in the reverse data as follows. 535 \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. 536 \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET. 537 \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET. 539 6.2.2. The ISP level 541 The providers A through E carry the following delegation information 542 in their zone files. 544 \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. 545 \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET. 546 \[xEB/8].IP6.E.NET. DNAME IP6.B.NET. 547 \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. 548 \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE. 550 Note that some domain names appear in the RDATA of more than one 551 DNAME record. In those cases, one zone is being used to map 552 multiple prefixes. 554 6.2.3. The Site Level 556 Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to- 557 name translations. This domain is now referenced by two different 558 DNAME records held by two different providers. 560 $ORIGIN IP6.X.EXAMPLE. 561 \[x0001/16] DNAME SUBNET-1 562 \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. 563 and so on. 565 SUBNET-1 need not have been named in a DNAME record; the subnet bits 566 could have been joined with the interface identifier. But if 567 subnets are treated alike in both the A6 records and in the reverse 568 zone, it will always be possible to keep the forward and reverse 569 definition data for each prefix in one zone. 571 6.3. Lookups 573 A DNS resolver looking for a hostname for the address 574 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the 575 DNAME records shown above and would form new queries. Assuming that 576 it began the process knowing servers for IP6.INT, but that no server 577 it consulted provided recursion and none had other useful additional 578 information cached, the sequence of queried names and responses 579 would be (all with QCLASS=IN, QTYPE=PTR): 581 To a server for IP6.INT: 582 QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.INT. 584 Answer: 585 \[x234500/24].IP6.INT. DNAME IP6.ALPHA-TLA.ORG. 587 To a server for IP6.ALPHA-TLA.ORG: 588 QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG. 590 Answer: 591 \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. 593 To a server for IP6.C.NET.: 594 QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET. 596 Answer: 597 \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. 599 To a server for IP6.A.NET.: 600 QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET. 602 Answer: 603 \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. 605 To a server for IP6.X.EXAMPLE.: 606 QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE. 608 Answer: 609 \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. 610 \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE. 612 All the DNAME (and NS) records acquired along the way can be cached 613 to expedite resolution of addresses topologically near to this 614 address. And if another global address of N.X.EXAMPLE were resolved 615 within the TTL of the final PTR record, that record would not have 616 to be fetched again. 618 6.4. Deployment Note 620 In the illustrations in section 6.1, hierarchically adjacent 621 entities, such as a network provider and a customer, must agree on a 622 DNS name which will own the definition of the delegated prefix(es). 623 One simple convention would be to use a bit-string label 624 representing exactly the bits which are assigned to the lower-level 625 entity by the higher. For example, "SUBSCRIBER-X" could be replaced 626 by "\[x11/8]". This would place the A6 record(s) defining the 627 delegated prefix at exactly the same point in the DNS tree as the 628 DNAME record associated with that delegation. The cost of this 629 simplification is that the lower-level zone must update its upward- 630 pointing A6 records when it is renumbered. This cost may be found 631 quite acceptable in practice. 633 7. Transition from AAAA Records on coexistence with A Records 635 Administrators of zones which contain A6 records can easily 636 accommodate deployed resolvers which understand AAAA records but not 637 A6 records. Such administrators can do automatic generation of AAAA 638 records for all of a zone's names which own A6 records by a process 639 which mimics the resolution of a hostname to an IPv6 address (see 640 section 4.1.4). Attention must be paid to the TTL assigned to a 641 generated AAAA record, which MUST be no more than the minimum of the 642 TTLs of the A6 records that were used to form the IPv6 address in 643 that record. For full robustness, those A6 records which were in 644 different zones should be monitored for changes (in TTL or RDATA) 645 even when there are no changes to zone for which AAAA records are 646 being generated. If the zone is secure [DNSSEC], the generated AAAA 647 records SHOULD be signed along with the rest of the zone data. 649 A zone-specific heuristic MAY be used to avoid generation of AAAA 650 records for A6 records which record prefixes, although such 651 superfluous records would be relatively few in number and harmless. 652 Examples of such heuristics include omitting A6 records with a 653 prefix length less than the largest value found in the zone file, or 654 records with an address suffix field with a certain number of 655 trailing zero bits. 657 On the client side, when looking up and IPv6 address, the order of 658 A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA; 659 AAAA, then A6; A6 only; or both in parallel. The default order (or 660 only order, if not configurable) MUST be to try A6 first, then AAAA. 661 If and when the AAAA becomes deprecated a new document will change 662 the default. 664 The guidelines and options for precedence between IPv4 and IPv6 665 addresses are specified in [TRANS]. All mentions of AAAA records in 666 that document are henceforth to be interpreted as meaning A6 and/or 667 AAAA records in the order specified in the previous paragraph. 669 8. Security Considerations 671 The signing authority [DNSSEC] for the A6 records which determine an 672 IPv6 address is distributed among several entities, reflecting the 673 delegation path of the address space which that address occupies. 674 DNS Security is fully applicable to bit-string labels and DNAME 675 records. However, just as with IPv4's IN-ADDR.ARPA, authentication 676 of data in the reverse zones is not equivalent to authentication of 677 any forward data. 679 9. IANA Considerations 681 The A6 resource record has been assigned a Type value of 38. 683 10. Acknowledgments 685 The authors would like to thank the following persons for valuable 686 discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, 687 Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Francis 688 Dupont, Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob 689 Hinden, Bill Manning, Keith Moore, Thomas Narten, Erik Nordmark, 690 Mike O'Dell, Michael Patton and Ken Powell. 692 11. References 694 [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing 695 Architecture", RFC 2373, July 1998. 697 [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable 698 Global Unicast Address Format". RFC 2374, July 1998. 700 [BITLBL] Crawford, M., "Binary Labels in the Domain Name System", 701 RFC 2673, August 1999. 703 [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, 704 August 1999. 706 [DNSIS] Mockapetris, P. V., "Domain names - implementation and 707 specification", RFC 1035, November 1987. 709 [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System 710 Security Extensions", RFC 2535, March 1999. 712 [KWORD] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels," RFC 2119. 715 [RENUM] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 716 1900, February 1996. 718 Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: 719 Why would I want it and what is it anyway?", RFC 2071, January 720 1997. 722 Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address 723 Behaviour Today", RFC 2101, February 1997. 725 [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 726 IPv6 Hosts and Routers", RFC 1933, April 1996. 728 12. Authors' Addresses 730 Matt Crawford Christian Huitema Susan Thomson 731 Fermilab Bellcore Bellcore 732 MS 368 MCC 1J236B MCC 1C259B 733 PO Box 500 445 South Street 445 South Street 734 Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960 735 USA USA USA 737 +1 630 840-3461 +1 201 829-4266 +1 201 829-4514 738 crawdad@fnal.gov 739 huitema@research.telcordia.comset@research.telcordia.com