idnits 2.17.1 draft-ietf-ipngwg-dns-lookups-01.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 15 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 569 has weird spacing: '...ore.com set@...' -- 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 (August 7, 1998) is 9387 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) -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-unicast-aggr is -04, but you're referring to -05. ** Downref: Normative reference to an Historic draft: draft-ietf-ipngwg-unicast-aggr (ref. 'AGGR') == Outdated reference: A later version (-05) exists of draft-ietf-dnsind-binary-labels-01 ** Downref: Normative reference to an Historic draft: draft-ietf-dnsind-binary-labels (ref. 'BITLBL') == Outdated reference: A later version (-03) exists of draft-ietf-dnsind-dname-00 ** Obsolete normative reference: RFC 2065 (ref. 'DNSSEC') (Obsoleted by RFC 2535) == Outdated reference: A later version (-03) exists of draft-ietf-dnsind-edns-01 -- Possible downref: Normative reference to a draft: ref. 'EDNS' == Outdated reference: A later version (-05) exists of draft-ietf-dnsind-local-compression-01 -- Possible downref: Normative reference to a draft: ref. 'LOCOMP' ** Obsolete normative reference: RFC 1933 (ref. 'TRANS') (Obsoleted by RFC 2893) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 5 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 August 7, 1998 8 DNS Extension to Support IP Version 6 9 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a 22 ``working draft'' or ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (North 27 Europe), ftp.nis.garr.it (South Europe), ftp.ietf.org (US East 28 Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 30 Distribution of this memo is unlimited. 32 1. Abstract 34 This document defines the changes that need to be made to the Domain 35 Name System to support hosts running IP version 6 (IPv6). The 36 changes include a new resource record type to store an IPv6 address 37 and updated definitions of existing query types that return Internet 38 addresses as part of additional section processing. 40 For lookups keyed on IPv6 addresses (often called reverse lookups), 41 this document defines a new domain to hold the top-level delegation 42 information and a zone structure which allows a zone to be used 43 without modification for parallel copies of an address space (as for 44 a multihomed provider or site) and across network renumbering 45 events. 47 2. Introduction 49 Current support for the storage of Internet addresses in the Domain 50 Name System (DNS) [DNSCF, DNSIS] cannot easily be extended to 51 support IPv6 addresses [AARCH] since applications assume that 52 address queries return 32-bit IPv4 addresses only. In addition, 53 maintenance of address information in the DNS is one of several 54 obstacles which have prevented site and provider renumbering from 55 being feasible. 57 To support the storage of IPv6 addresses without impeding 58 renumbering we define the following extensions. 60 o A new resource record type, AAAA, is defined to map a domain 61 name to an IPv6 address, with a provision for indirection for 62 leading "prefix" bits. 64 o Existing queries that perform additional section processing to 65 locate IPv4 addresses are redefined to do that processing for 66 both IPv4 and IPv6 addresses. 68 o A new domain, IP6.INT, is defined to support lookups based on 69 IPv6 address. 71 o A new prefix-delegation method is defined, relying on new DNS 72 features [BITLBL, DNAME, EDNS]. 74 The changes are designed to be compatible with existing 75 applications. The existing support for IPv4 addresses is retained. 76 Transition issues related to the coexistence of both IPv4 and IPv6 77 addresses in DNS are discussed in [TRANS]. 79 This memo proposes an incompatible extension to the specification in 80 RFC 1886 and a departure from current implementation practices. The 81 changes are designed to facilitate network renumbering and 82 multihoming. Upon approval of this document, RFC 1886 will become 83 Historic. 85 The next three major sections of this document are an overview of 86 the facilities defined or employed by this specification, the 87 specification itself, and examples of use. 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [KWORD]. The key 92 word "SUGGESTED" signifies a strength between MAY and SHOULD. It is 93 believed that compliance with the suggestion has tangible benefits 94 in most instances. 96 3. Overview 98 This section provides an overview of the DNS facilities for storage 99 of IPv6 addresses and for lookups based on IPv6 address, including 100 those defined here and elsewhere. 102 3.1. Name-to-Address Lookup 104 IPv6 addresses are stored in a new AAAA ("quad-A") resource record 105 type. A single AAAA record may include a complete IPv6 address, or 106 a contiguous portion of an address and information leading to one or 107 more prefixes. Prefix information comprises a prefix length and a 108 DNS name which is in turn the owner of one or more AAAA records 109 defining the prefix or prefixes which are needed to form one or more 110 complete IPv6 addresses. When the prefix length is zero, no DNS 111 name is present and all the leading bits of the address are 112 significant. There may be multiples levels of indirection and the 113 existence of multiple AAAA records at any level multiplies the 114 number of IPv6 addresses which are formed. 116 An application looking up an IPv6 address will generally cause the 117 DNS resolver to access several AAAA records, and multiple IPv6 118 addresses may be returned even if the queried name was the owner of 119 only one AAAA record. The authenticity [DNSSEC] of the returned 120 address(es) cannot be directly verified. The AAAA records which 121 contributed to the address(es) may of course be verified if signed. 123 3.2. Underlying Mechanisms for Reverse Lookups 125 This section describes the new DNS features which this document 126 exploits. The reader is directed to the referenced documents for 127 more details on each. 129 3.2.1. Delegation on Arbitrary Boundaries 131 This new scheme for reverse lookups relies on a new type of DNS 132 label called the "bit-string label" [BITLBL]. This label compactly 133 represents an arbitrary string of bits which is treated as a 134 hierarchical sequence of one-bit domain labels. Resource records 135 can be stored on arbitrary bit-boundaries and lookups will often 136 employ longest-match queries [EDNS] which will return records from 137 the nearest ancestor node which has them if the requested 138 information cannot be found at the queried name itself. 140 Examples in section 5 will employ the following textual 141 representation for bit-string labels. (This is a subset of the 142 syntax defined in [BITLBL].) A base indicator "x" for hexadecimal 143 and a sequence of hexadecimal digits is enclosed between "\[" and 144 "]". The bits denoted by the digits represent a sequence of one-bit 145 domain labels ordered from most to least significant. (This is the 146 opposite of the order they would appear if listed one bit at a time, 147 but it appears to be a convenient notation.) The digit string may 148 be followed by a slash ("/") and a decimal count. If omitted, the 149 implicit count is equal to four times the number of hexadecimal 150 digits. 152 Consecutive bit-string labels are equivalent (up to the limit 153 imposed by the size of the bit count field) to a single bit-string 154 label containing all the bits of the consecutive labels in the 155 proper order. As an example, either of the following domain names 156 could be used in a QCLASS=IN, QTYPE=PTR query to find the name of 157 the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32. 159 \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.INT. 161 \[x0A0020FFFE812B32/64].\[x0009/16]. 162 \[x07C00040/32].\[xFFF0/13].\[x2/3].IP6.INT. 164 Note that bits are left-justified in a hexadecimal string. 166 3.2.2. Reusable Zones 168 DNS address space delegation is implemented not by zone cuts and NS 169 records, but by a new analogue to the CNAME record, called the DNAME 170 resource record [DNAME]. The DNAME record provides alternate naming 171 to an entire subtree of the domain name space, rather than to a 172 single node. It causes some suffix of a queried name to be 173 substituted with a name from the DNAME record's RDATA. 175 For example, a resolver or server providing recursion, while looking 176 up a QNAME a.b.c.d.e.f may encounter a DNAME record 178 d.e.f. DNAME w.xy. 180 which will cause it to look for a.b.c.w.xy. 182 4. Specifications 184 4.1. The AAAA Record Type 186 The AAAA record type is specific to the IN (Internet) class and has 187 type number 28 (decimal). 189 4.1.1. Format 191 The RDATA portion of the AAAA record contains two or three fields. 193 +---------------------+-----------+-----------------------+ 194 | Ipv6 address |Pre. length| Domain name of prefix | 195 | (128 bits) | (1 octet) | (variable, 0..255) | 196 +---------------------+-----------+-----------------------+ 198 o A 128 bit IPv6 address, encoded in network order (high-order 199 octet first). 201 o A prefix length, encoded an eight-bit unsigned integer with 202 value between 0 and 128 inclusive. 204 o The domain name of the prefix, encoded as a domain name, 205 possibly compressed as specified in [DNSIS]. (The compression 206 of the domain name may cause problems if servers that don't 207 understand the AAAA type cache this record. This problem is 208 addressed in [LOCOMP] and [EDNS].) 210 The domain name component SHALL NOT be present if the prefix length 211 is zero. If the prefix length is non-zero, that number of leading 212 bits of the IPv6 address field SHOULD be zero. 214 4.1.2. Processing 216 The AAAA RR causes type AAAA and type NS additional section 217 processing for the DNS name, if present, in its RDATA field. 219 It is an error for a AAAA record with prefix length L1 > 0 to refer 220 a domain name which owns a AAAA record with a prefix length L2 > L1. 221 If such a situation is encountered by a resolver, the AAAA record 222 with the offending prefix length MUST be ignored. Robustness 223 precludes signalling an error if addresses can still be formed from 224 valid records, but it is SUGGESTED that zone maintainers from time 225 to time check all the AAAA records their zones reference. 227 4.1.3. Textual Representation 229 The textual representation of the RDATA portion of the AAAA resource 230 record in a zone file comprises two or three fields separated by 231 whitespace. 233 o The textual representation of the host's IPv6 address as defined 234 in [AARCH], 236 o a prefix length, represented as a decimal number between 0 and 237 128 inclusive and 239 o a domain name, if the prefix length is not zero. 241 The domain name MUST be absent if the prefix length is zero. A 242 number of leading address bits equal to the prefix length SHOULD be 243 zero, either implicitly (through the :: notation) or explicitly, as 244 specified in section 4.1.1. 246 4.2. Zone Structure for Reverse Lookups 248 Very little of the new scheme's data actually appears under IP6.INT. 249 Only the first level of delegation needs to be under that domain, 250 although more levels of delegation could be placed under IP6.INT if 251 some top-level delegations were done via NS records instead of DNAME 252 records. This would incur some cost in renumbering ease at the 253 level of TLAs [AGGR]. Therefore, it is declared here that all 254 address space delegations SHOULD be done by the DNAME mechanism 255 rather than NS. 257 In addition, since uniformity in deployment will simplify 258 maintenance of address delegations, it is SUGGESTED that address and 259 prefix information be stored immediately below a DNS label "IP6". 260 Stated another way, conformance with this suggestion would mean that 261 "IP6" is the first label in the RDATA field of DNAME records which 262 support IPv6 reverse lookups. 264 When any "reserved" or "must be zero" bits are adjacent to a 265 delegation boundary, the higher-level entity MUST retain those bits 266 in its own control and delegate only the bits over which the lower- 267 level entity has authority. 269 To find the name of a node given its IPv6 address, a DNS client MUST 270 perform a query with QCLASS=IN, QTYPE=PTR on the name formed from 271 the 128 bit address as one or more bit-string labels [BITLBL], 272 followed by the two standard labels "IP6.INT". If recursive service 273 was not obtained from a server and the desired PTR record was not 274 returned, the resolver MUST handle returned DNAME records as 275 specified in [DNAME] and iterate. 277 5. Usage Illustrations 279 This section provides examples of use of the mechanisms defined in 280 the previous section. All addresses and domains mentioned here are 281 fictitious and for illustrative purposes only. Example delegations 282 will be on 4-bit boundaries solely for readability; this 283 specification is indifferent to bit alignment. 285 Use of the IPv6 aggregatable address format [AGGR] is assumed in the 286 examples. 288 5.1. AAAA Record Chains 290 Let's take the example of a site X that is multi-homed to two 291 "intermediate" providers A and B. The provider A is itself multi- 292 homed to two "transit" providers, C and D. The provider B gets its 293 transit service from a single provider, E. For simplicity suppose 294 that C, D and E all belong to the same top-level aggregate (TLA) 295 with identifier (including format prefix) '2345', and the TLA 296 authority at ALPHA-TLA.ORG assigns to C, D and E respectively the 297 next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 298 and 2345:000E::/32. 300 C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the 301 prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to 302 B. 304 A assigns to X the subscriber identification '11' and B assigns the 305 subscriber identification '22'. As a result, the site X inherits 306 three address prefixes: 308 o 2345:00C1:CA11::/48 from A, for routes through C. 309 o 2345:00D2:DA11::/48 from A, for routes through D. 310 o 2345:000E:EB22::/48 from B, for routes through E. 312 Let us suppose that N is a node in the site X, that it is assigned 313 to subnet number 1 in this site, and that it uses the interface 314 identifier '1234:5678:9ABC:DEF0'. In our configuration, this node 315 will have three addresses: 317 o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 318 o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 319 o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 320 We will assume that the site X is represented in the DNS by the 321 domain name X.EXAMPLE, while A, B, C, D and E are represented by 322 A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we 323 assume a subdomain "IP6" that will hold the corresponding prefixes. 324 The node N is identified by the domain name N.X.EXAMPLE. The 325 following records would then appear in X's DNS. 327 $ORIGIN X.EXAMPLE. 328 N AAAA ::1234:5678:9ABC:DEF0 64 SUBNET-1.IP6 329 SUBNET-1.IP6 AAAA 0:0:0:1:: 48 IP6 330 IP6 AAAA 0::0 48 SUBSCRIBER-X.IP6.A.NET. 331 IP6 AAAA 0::0 48 SUBSCRIBER-X.IP6.B.NET. 333 And elsewhere there would appear 335 SUBSCRIBER-X.IP6.A.NET. AAAA 0:0:0011:: 40 A.NET.IP6.C.NET. 336 SUBSCRIBER-X.IP6.A.NET. AAAA 0:0:0011:: 40 A.NET.IP6.D.NET. 338 SUBSCRIBER-X.IP6.B.NET. AAAA 0:0:0022:: 40 B-NET.IP6.E.NET. 340 A.NET.IP6.C.NET. AAAA 0:0001:CA00:: 28 C.NET.ALPHA-TLA.ORG. 342 A.NET.IP6.D.NET. AAAA 0:0002:DA00:: 28 D.NET.ALPHA-TLA.ORG. 344 B-NET.IP6.E.NET. AAAA 0:0:EB00:: 32 D.NET.ALPHA-TLA.ORG. 346 C.NET.ALPHA-TLA.ORG. AAAA 2345:00C0:: 0 347 D.NET.ALPHA-TLA.ORG. AAAA 2345:00D0:: 0 348 E.NET.ALPHA-TLA.ORG. AAAA 2345:000E:: 0 350 Several more-or-less arbitrary assumptions are reflected in the 351 above structure. All of the following choices could have been made 352 differently, according to someone's notion of convenience or an 353 agreement between two parties. 355 First, that site X has chosen to put subnet information in a 356 separate AAAA record rather than incorporate it into each node's 357 AAAA records. 359 Second, that site X is referred to as "SUBSCRIBER-X" by both of 360 its providers A and B. 362 Third, that site X chose to indirect its provider information 363 through AAAA records at IP6.X.EXAMPLE containing no significant 364 bits. An alternative would have been to replicate each subnet 365 record for each provider. 367 Fourth, B and E used a slightly different prefix naming 368 convention between themselves than did A, C and D. Each 369 hierarchical pair of network entities must arrange this naming 370 between themselves. 372 Fifth, that the upward prefix referral chain topped out at 373 ALPHA-TLA.ORG. There could have been another level which 374 assigned the TLA values and holds AAAA records containing those 375 bits. 377 Finally, the above structure reflects an assumption that address 378 fields assigned by a given entity are recorded only in AAAA records 379 held by that entity. Those bits could be entered into AAAA records 380 in the lower-level entity's zone instead, thus: 382 IP6.X.EXAMPLE. AAAA 0:0:11:: 40 IP6.A.NET. 383 IP6.X.EXAMPLE. AAAA 0:0:22:: 40 IP6.B.NET. 385 IP6.A.NET. AAAA 0:0:CA00:: 32 IP6.C.NET. 386 and so on. 388 Or the higher-level entity could hold both sorts of AAAA records and 389 allow the lower-level entity to choose to record a copy of the 390 delegated bits or refer to the higher-level entity's copy. But the 391 general rule of avoiding data duplication suggests that the proper 392 place to store assigned values is with the entity that assigned 393 them. 395 5.2. Reverse Mapping Zones 397 Supposing that address space assignments in the TLAs with Format 398 Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in 399 zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then 400 the IP6.INT zone would include 402 $ORIGIN IP6.INT. 403 \[x234500/24] DNAME IP6.ALPHA-TLA.ORG. 404 \[x267800/24] DNAME IP6.BRAVO-TLA.ORG. 405 \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY. 407 Eight trailing zero bits have been included in each TLA ID to 408 reflect the eight reserved bits in the current aggregatable global 409 unicast addresses format [AGGR]. 411 5.2.1. The TLA level 413 ALPHA-TLA's assignments to network providers C, D and E are 414 reflected in the reverse data as follows. 416 \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. 417 \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET. 418 \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET. 420 5.2.2. The ISP level 422 The providers A through E carry the following delegation information 423 in their zone files. 425 \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. 426 \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET. 427 \[xEB/8].IP6.E.NET. DNAME IP6.B.NET. 428 \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. 429 \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE. 431 Note that some domain names appear in the RDATA of more than one 432 DNAME record. In those cases, one zone is being used to map 433 multiple prefixes. 435 5.2.3. The Site Level 437 Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to- 438 name translations. This domain is now referenced by two different 439 DNAME records held by two different providers. 441 $ORIGIN IP6.X.EXAMPLE. 442 \[x0001/16] DNAME SUBNET-1 443 \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. 444 and so on. 446 SUBNET-1 need not have been named in a DNAME record; the subnet bits 447 could have been joined with the interface identifier. But if 448 subnets are treated alike in both the AAAA records and in the 449 reverse zone, it will always be possible to keep the forward and 450 reverse definition data for each prefix in one zone. 452 5.3. Lookups 454 A DNS resolver looking for a hostname for the address 455 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the 456 DNAME records shown above and would form new queries. Assuming that 457 it began the process knowing servers for IP6.INT, but that no server 458 it consulted provided recursion and none had other useful additional 459 information cached, the sequence of queried names and responses 460 would be (all with QCLASS=IN, QTYPE=PTR): 462 To a server for IP6.INT: 463 QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.INT. 465 Answer: 466 \[x234500/24].IP6.INT. DNAME IP6.ALPHA-TLA.ORG. 468 To a server for IP6.ALPHA-TLA.ORG: 469 QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG. 471 Answer: 472 \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. 474 To a server for IP6.C.NET.: 475 QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET. 477 Answer: 478 \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. 480 To a server for IP6.A.NET.: 481 QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET. 483 Answer: 484 \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. 486 To a server for IP6.X.EXAMPLE.: 487 QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE. 489 Answer: 490 \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. 491 \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE. 493 All the DNAME (and NS) records acquired along the way can be cached 494 to expedite resolution of addresses topologically near to this 495 address. And if another global address of N.X.EXAMPLE were resolved 496 within the TTL of the final PTR record, that record would not have 497 to be fetched again. 499 5.4. Deployment Note 501 In the illustrations in section 5.1, hierarchically adjacent 502 entities, such as a network provider and a customer, must agree on a 503 DNS name which will own the definition of the delegated prefix(es). 504 One simple convention would be to use a bit-string label 505 representing exactly the bits which are assigned to the lower-level 506 entity by the higher. For example, "SUBSCRIBER-X" could be replaced 507 by "\[x11/8]". This would place the AAAA record(s) defining the 508 delegated prefix at exactly the same point in the DNS tree as the 509 DNAME record associated with that delegation. The cost of this 510 simplification is that the lower-level zone must update its upward- 511 pointing AAAA records when it is renumbered. This cost may be found 512 quite acceptable in practice. 514 6. Security Considerations 516 DNS Security [DNSSEC] is fully applicable to bit-string labels and 517 DNAME records. However, just as with IPv4's IN-ADDR.ARPA, 518 authentication of data in the reverse zones is not equivalent to 519 authentication of any forward data. 521 7. References 523 [AARCH] R. Hinden, S. Deering, "IP Version 6 Addressing 524 Architecture", Currently draft-ietf-ipngwg-addr-arch-v2- 525 06.txt. 527 [AGGR] R. Hinden, M. O'Dell, S. Deering, "An IPv6 Aggregatable 528 Global Unicast Address Format". Currently draft-ietf- 529 ipngwg-unicast-aggr-05.txt. 531 [BITLBL] M. Crawford, "Binary Labels in the Domain Name System", 532 currently draft-ietf-dnsind-binary-labels-01.txt. 534 [DNAME] M. Crawford, "Non-Terminal DNS Name Redirection", currently 535 draft-ietf-dnsind-dname-00.txt. 537 [DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities", 538 RFC 1034. 540 [DNSIS] P.V. Mockapetris, "Domain names - implementation and 541 specification", RFC 1035. 543 [DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security 544 Extensions", RFC 2065. 546 [EDNS] P. Vixie, "Extensions to DNS (EDNS)" currently draft-ietf- 547 dnsind-edns-01.txt. 549 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 550 Requirement Levels," RFC 2119. 552 [LOCOMP] P. Koch, "A New Scheme for the Compression of Domain 553 Names", currently draft-ietf-dnsind-local-compression- 554 01.txt. 556 [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 557 Hosts and Routers", RFC 1933. 559 8. Authors' Addresses 561 Matt Crawford Christian Huitema Susan Thomson 562 Fermilab Bellcore Bellcore 563 MS 368 MCC 1J236B MCC 1C259B 564 PO Box 500 445 South Street 445 South Street 565 Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960 566 USA USA USA 568 +1 630 840-3461 +1 201 829-4266 +1 201 829-4514 569 crawdad@fnal.gov huitema@bellcore.com set@bellcore.com