diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2874.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2874.txt | 1123 |
1 files changed, 0 insertions, 1123 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2874.txt b/contrib/bind9/doc/rfc/rfc2874.txt deleted file mode 100644 index 915c104..0000000 --- a/contrib/bind9/doc/rfc/rfc2874.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - - - - -Network Working Group M. Crawford -Request for Comments: 2874 Fermilab -Category: Standards Track C. Huitema - Microsoft Corporation - July 2000 - - - DNS Extensions to Support IPv6 Address Aggregation and Renumbering - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This document defines changes to the Domain Name System to support - renumberable and aggregatable IPv6 addressing. The changes include a - new resource record type to store an IPv6 address in a manner which - expedites network renumbering and updated definitions of existing - query types that return Internet addresses as part of additional - section processing. - - For lookups keyed on IPv6 addresses (often called reverse lookups), - this document defines a new zone structure which allows a zone to be - used without modification for parallel copies of an address space (as - for a multihomed provider or site) and across network renumbering - events. - - - - - - - - - - - - - - - - -Crawford, et al. Standards Track [Page 1] - -RFC 2874 IPv6 DNS July 2000 - - -Table of Contents - - 1. Introduction ............................................... 2 - 2. Overview ................................................... 3 - 2.1. Name-to-Address Lookup ............................... 4 - 2.2. Underlying Mechanisms for Reverse Lookups ............ 4 - 2.2.1. Delegation on Arbitrary Boundaries ............. 4 - 2.2.2. Reusable Zones ................................. 5 - 3. Specifications ............................................. 5 - 3.1. The A6 Record Type ................................... 5 - 3.1.1. Format ......................................... 6 - 3.1.2. Processing ..................................... 6 - 3.1.3. Textual Representation ......................... 7 - 3.1.4. Name Resolution Procedure ...................... 7 - 3.2. Zone Structure for Reverse Lookups ................... 7 - 4. Modifications to Existing Query Types ...................... 8 - 5. Usage Illustrations ........................................ 8 - 5.1. A6 Record Chains ..................................... 9 - 5.1.1. Authoritative Data ............................. 9 - 5.1.2. Glue ........................................... 10 - 5.1.3. Variations ..................................... 12 - 5.2. Reverse Mapping Zones ................................ 13 - 5.2.1. The TLA level .................................. 13 - 5.2.2. The ISP level .................................. 13 - 5.2.3. The Site Level ................................. 13 - 5.3. Lookups .............................................. 14 - 5.4. Operational Note ..................................... 15 - 6. Transition from RFC 1886 and Deployment Notes .............. 15 - 6.1. Transition from AAAA and Coexistence with A Records .. 16 - 6.2. Transition from Nibble Labels to Binary Labels ....... 17 - 7. Security Considerations .................................... 17 - 8. IANA Considerations ........................................ 17 - 9. Acknowledgments ............................................ 18 - 10. References ................................................ 18 - 11. Authors' Addresses ........................................ 19 - 12. Full Copyright Statement .................................. 20 - -1. Introduction - - Maintenance of address information in the DNS is one of several - obstacles which have prevented site and provider renumbering from - being feasible in IP version 4. Arguments about the importance of - network renumbering for the preservation of a stable routing system - and for other purposes may be read in [RENUM1, RENUM2, RENUM3]. To - support the storage of IPv6 addresses without impeding renumbering we - define the following extensions. - - - - - -Crawford, et al. Standards Track [Page 2] - -RFC 2874 IPv6 DNS July 2000 - - - o A new resource record type, "A6", is defined to map a domain name - to an IPv6 address, with a provision for indirection for leading - "prefix" bits. - - o Existing queries that perform additional section processing to - locate IPv4 addresses are redefined to do that processing for both - IPv4 and IPv6 addresses. - - o A new domain, IP6.ARPA, is defined to support lookups based on - IPv6 address. - - o A new prefix-delegation method is defined, relying on new DNS - features [BITLBL, DNAME]. - - The changes are designed to be compatible with existing application - programming interfaces. The existing support for IPv4 addresses is - retained. Transition issues related to the coexistence of both IPv4 - and IPv6 addresses in DNS are discussed in [TRANS]. - - This memo proposes a replacement for the specification in RFC 1886 - [AAAA] and a departure from current implementation practices. The - changes are designed to facilitate network renumbering and - multihoming. Domains employing the A6 record for IPv6 addresses can - insert automatically-generated AAAA records in zone files to ease - transition. It is expected that after a reasonable period, RFC 1886 - will become Historic. - - The next three major sections of this document are an overview of the - facilities defined or employed by this specification, the - specification itself, and examples of use. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [KWORD]. The key word - "SUGGESTED" signifies a strength between MAY and SHOULD: it is - believed that compliance with the suggestion has tangible benefits in - most instances. - -2. Overview - - This section provides an overview of the DNS facilities for storage - of IPv6 addresses and for lookups based on IPv6 address, including - those defined here and elsewhere. - - - - - - - - -Crawford, et al. Standards Track [Page 3] - -RFC 2874 IPv6 DNS July 2000 - - -2.1. Name-to-Address Lookup - - IPv6 addresses are stored in one or more A6 resource records. A - single A6 record may include a complete IPv6 address, or a contiguous - portion of an address and information leading to one or more - prefixes. Prefix information comprises a prefix length and a DNS - name which is in turn the owner of one or more A6 records defining - the prefix or prefixes which are needed to form one or more complete - IPv6 addresses. When the prefix length is zero, no DNS name is - present and all the leading bits of the address are significant. - There may be multiple levels of indirection and the existence of - multiple A6 records at any level multiplies the number of IPv6 - addresses which are formed. - - An application looking up an IPv6 address will generally cause the - DNS resolver to access several A6 records, and multiple IPv6 - addresses may be returned even if the queried name was the owner of - only one A6 record. The authenticity of the returned address(es) - cannot be directly verified by DNS Security [DNSSEC]. The A6 records - which contributed to the address(es) may of course be verified if - signed. - - Implementers are reminded of the necessity to limit the amount of - work a resolver will perform in response to a client request. This - principle MUST be extended to also limit the generation of DNS - requests in response to one name-to-address (or address-to-name) - lookup request. - -2.2. Underlying Mechanisms for Reverse Lookups - - This section describes the new DNS features which this document - exploits. This section is an overview, not a specification of those - features. The reader is directed to the referenced documents for - more details on each. - -2.2.1. Delegation on Arbitrary Boundaries - - This new scheme for reverse lookups relies on a new type of DNS label - called the "bit-string label" [BITLBL]. This label compactly - represents an arbitrary string of bits which is treated as a - hierarchical sequence of one-bit domain labels. Resource records can - thereby be stored at arbitrary bit-boundaries. - - Examples in section 5 will employ the following textual - representation for bit-string labels, which is a subset of the syntax - defined in [BITLBL]. A base indicator "x" for hexadecimal and a - sequence of hexadecimal digits is enclosed between "\[" and "]". The - bits denoted by the digits represent a sequence of one-bit domain - - - -Crawford, et al. Standards Track [Page 4] - -RFC 2874 IPv6 DNS July 2000 - - - labels ordered from most to least significant. (This is the opposite - of the order they would appear if listed one bit at a time, but it - appears to be a convenient notation.) The digit string may be - followed by a slash ("/") and a decimal count. If omitted, the - implicit count is equal to four times the number of hexadecimal - digits. - - Consecutive bit-string labels are equivalent (up to the limit imposed - by the size of the bit count field) to a single bit-string label - containing all the bits of the consecutive labels in the proper - order. As an example, either of the following domain names could be - used in a QCLASS=IN, QTYPE=PTR query to find the name of the node - with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32. - - \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA. - - \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA. - -2.2.2. Reusable Zones - - DNS address space delegation is implemented not by zone cuts and NS - records, but by a new analogue to the CNAME record, called the DNAME - resource record [DNAME]. The DNAME record provides alternate naming - to an entire subtree of the domain name space, rather than to a - single node. It causes some suffix of a queried name to be - substituted with a name from the DNAME record's RDATA. - - For example, a resolver or server providing recursion, while looking - up a QNAME a.b.c.d.e.f may encounter a DNAME record - - d.e.f. DNAME w.xy. - - which will cause it to look for a.b.c.w.xy. - -3. Specifications - -3.1. The A6 Record Type - - The A6 record type is specific to the IN (Internet) class and has - type number 38 (decimal). - - - - - - - - - - - -Crawford, et al. Standards Track [Page 5] - -RFC 2874 IPv6 DNS July 2000 - - -3.1.1. Format - - The RDATA portion of the A6 record contains two or three fields. - - +-----------+------------------+-------------------+ - |Prefix len.| Address suffix | Prefix name | - | (1 octet) | (0..16 octets) | (0..255 octets) | - +-----------+------------------+-------------------+ - - o A prefix length, encoded as an eight-bit unsigned integer with - value between 0 and 128 inclusive. - - o An IPv6 address suffix, encoded in network order (high-order octet - first). There MUST be exactly enough octets in this field to - contain a number of bits equal to 128 minus prefix length, with 0 - to 7 leading pad bits to make this field an integral number of - octets. Pad bits, if present, MUST be set to zero when loading a - zone file and ignored (other than for SIG [DNSSEC] verification) - on reception. - - o The name of the prefix, encoded as a domain name. By the rules of - [DNSIS], this name MUST NOT be compressed. - - The domain name component SHALL NOT be present if the prefix length - is zero. The address suffix component SHALL NOT be present if the - prefix length is 128. - - It is SUGGESTED that an A6 record intended for use as a prefix for - other A6 records have all the insignificant trailing bits in its - address suffix field set to zero. - -3.1.2. Processing - - A query with QTYPE=A6 causes type A6 and type NS additional section - processing for the prefix names, if any, in the RDATA field of the A6 - records in the answer section. This processing SHOULD be recursively - applied to the prefix names of A6 records included as additional - data. When space in the reply packet is a limit, inclusion of - additional A6 records takes priority over NS records. - - It is an error for an A6 record with prefix length L1 > 0 to refer to - a domain name which owns an A6 record with a prefix length L2 > L1. - If such a situation is encountered by a resolver, the A6 record with - the offending (larger) prefix length MUST be ignored. Robustness - precludes signaling an error if addresses can still be formed from - valid A6 records, but it is SUGGESTED that zone maintainers from time - to time check all the A6 records their zones reference. - - - - -Crawford, et al. Standards Track [Page 6] - -RFC 2874 IPv6 DNS July 2000 - - -3.1.3. Textual Representation - - The textual representation of the RDATA portion of the A6 resource - record in a zone file comprises two or three fields separated by - whitespace. - - o A prefix length, represented as a decimal number between 0 and 128 - inclusive, - - o the textual representation of an IPv6 address as defined in - [AARCH] (although some leading and/or trailing bits may not be - significant), - - o a domain name, if the prefix length is not zero. - - The domain name MUST be absent if the prefix length is zero. The - IPv6 address MAY be be absent if the prefix length is 128. A number - of leading address bits equal to the prefix length SHOULD be zero, - either implicitly (through the :: notation) or explicitly, as - specified in section 3.1.1. - -3.1.4. Name Resolution Procedure - - To obtain the IPv6 address or addresses which belong to a given name, - a DNS client MUST obtain one or more complete chains of A6 records, - each chain beginning with a record owned by the given name and - including a record owned by the prefix name in that record, and so on - recursively, ending with an A6 record with a prefix length of zero. - One IPv6 address is formed from one such chain by taking the value of - each bit position from the earliest A6 record in the chain which - validly covers that position, as indicated by the prefix length. The - set of all IPv6 addresses for the given name comprises the addresses - formed from all complete chains of A6 records beginning at that name, - discarding records which have invalid prefix lengths as defined in - section 3.1.2. - - If some A6 queries fail and others succeed, a client might obtain a - non-empty but incomplete set of IPv6 addresses for a host. In many - situations this may be acceptable. The completeness of a set of A6 - records may always be determined by inspection. - -3.2. Zone Structure for Reverse Lookups - - Very little of the new scheme's data actually appears under IP6.ARPA; - only the first level of delegation needs to be under that domain. - More levels of delegation could be placed under IP6.ARPA if some - top-level delegations were done via NS records instead of DNAME - records, but this would incur some cost in renumbering ease at the - - - -Crawford, et al. Standards Track [Page 7] - -RFC 2874 IPv6 DNS July 2000 - - - level of TLAs [AGGR]. Therefore, it is declared here that all - address space delegations SHOULD be done by the DNAME mechanism - rather than NS. - - In addition, since uniformity in deployment will simplify maintenance - of address delegations, it is SUGGESTED that address and prefix - information be stored immediately below a DNS label "IP6". Stated - another way, conformance with this suggestion would mean that "IP6" - is the first label in the RDATA field of DNAME records which support - IPv6 reverse lookups. - - When any "reserved" or "must be zero" bits are adjacent to a - delegation boundary, the higher-level entity MUST retain those bits - in its own control and delegate only the bits over which the lower- - level entity has authority. - - To find the name of a node given its IPv6 address, a DNS client MUST - perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the - 128 bit address as one or more bit-string labels [BITLBL], followed - by the two standard labels "IP6.ARPA". If recursive service was not - obtained from a server and the desired PTR record was not returned, - the resolver MUST handle returned DNAME records as specified in - [DNAME], and NS records as specified in [DNSCF], and iterate. - -4. Modifications to Existing Query Types - - All existing query types that perform type A additional section - processing, i.e. the name server (NS), mail exchange (MX), and - mailbox (MB) query types, and the experimental AFS data base (AFSDB) - and route through (RT) types, must be redefined to perform type A, A6 - and AAAA additional section processing, with type A having the - highest priority for inclusion and type AAAA the lowest. This - redefinition means that a name server may add any relevant IPv4 and - IPv6 address information available locally to the additional section - of a response when processing any one of the above queries. The - recursive inclusion of A6 records referenced by A6 records already - included in the additional section is OPTIONAL. - -5. Usage Illustrations - - This section provides examples of use of the mechanisms defined in - the previous section. All addresses and domains mentioned here are - intended to be fictitious and for illustrative purposes only. - Example delegations will be on 4-bit boundaries solely for - readability; this specification is indifferent to bit alignment. - - Use of the IPv6 aggregatable address format [AGGR] is assumed in the - examples. - - - -Crawford, et al. Standards Track [Page 8] - -RFC 2874 IPv6 DNS July 2000 - - -5.1. A6 Record Chains - - Let's take the example of a site X that is multi-homed to two - "intermediate" providers A and B. The provider A is itself multi- - homed to two "transit" providers, C and D. The provider B gets its - transit service from a single provider, E. For simplicity suppose - that C, D and E all belong to the same top-level aggregate (TLA) with - identifier (including format prefix) '2345', and the TLA authority at - ALPHA-TLA.ORG assigns to C, D and E respectively the next level - aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and - 2345:000E::/32. - - C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the - prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to - B. - - A assigns to X the subscriber identification '11' and B assigns the - subscriber identification '22'. As a result, the site X inherits - three address prefixes: - - o 2345:00C1:CA11::/48 from A, for routes through C. - o 2345:00D2:DA11::/48 from A, for routes through D. - o 2345:000E:EB22::/48 from B, for routes through E. - - Let us suppose that N is a node in the site X, that it is assigned to - subnet number 1 in this site, and that it uses the interface - identifier '1234:5678:9ABC:DEF0'. In our configuration, this node - will have three addresses: - - o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 - o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 - o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 - -5.1.1. Authoritative Data - - We will assume that the site X is represented in the DNS by the - domain name X.EXAMPLE, while A, B, C, D and E are represented by - A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we - assume a subdomain "IP6" that will hold the corresponding prefixes. - The node N is identified by the domain name N.X.EXAMPLE. The - following records would then appear in X's DNS. - - $ORIGIN X.EXAMPLE. - N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 - SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 - IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. - IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. - - - - -Crawford, et al. Standards Track [Page 9] - -RFC 2874 IPv6 DNS July 2000 - - - And elsewhere there would appear - - SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. - SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET. - - SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET. - - A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG. - - A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG. - - B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG. - - C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: - D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: - E.NET.ALPHA-TLA.ORG. A6 0 2345:000E:: - -5.1.2. Glue - - When, as is common, some or all DNS servers for X.EXAMPLE are within - the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry - enough "glue" information to enable DNS clients to reach those - nameservers. This is true in IPv6 just as in IPv4. However, the A6 - record affords the DNS administrator some choices. The glue could be - any of - - o a minimal set of A6 records duplicated from the X.EXAMPLE zone, - - o a (possibly smaller) set of records which collapse the structure - of that minimal set, - - o or a set of A6 records with prefix length zero, giving the entire - global addresses of the servers. - - The trade-off is ease of maintenance against robustness. The best - and worst of both may be had together by implementing either the - first or second option together with the third. To illustrate the - glue options, suppose that X.EXAMPLE is served by two nameservers - NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers - ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively. - Then the top-level zone EXAMPLE would include one (or more) of the - following sets of A6 records as glue. - - - - - - - - - -Crawford, et al. Standards Track [Page 10] - -RFC 2874 IPv6 DNS July 2000 - - - $ORIGIN EXAMPLE. ; first option - X NS NS1.X - NS NS2.X - NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X - NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X - SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X - SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X - IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. - IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. - - - $ORIGIN EXAMPLE. ; second option - X NS NS1.X - NS NS2.X - NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET. - A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET. - NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET. - A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET. - - - $ORIGIN EXAMPLE. ; third option - X NS NS1.X - NS NS2.X - NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111 - A6 0 2345:00D2:DA11:1:1:11:111:1111 - A6 0 2345:000E:EB22:1:1:11:111:1111 - NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222 - A6 0 2345:00D2:DA11:2:2:22:222:2222 - A6 0 2345:000E:EB22:2:2:22:222:2222 - - The first and second glue options are robust against renumbering of - X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if - those providers' own DNS is unreachable. The glue records of the - third option are robust against DNS failures elsewhere than the zones - EXAMPLE and X.EXAMPLE themselves, but must be updated when X's - address space is renumbered. - - If the EXAMPLE zone includes redundant glue, for instance the union - of the A6 records of the first and third options, then under normal - circumstances duplicate IPv6 addresses will be derived by DNS - clients. But if provider DNS fails, addresses will still be obtained - from the zero-prefix-length records, while if the EXAMPLE zone lags - behind a renumbering of X.EXAMPLE, half of the addresses obtained by - DNS clients will still be up-to-date. - - The zero-prefix-length glue records can of course be automatically - generated and/or checked in practice. - - - - -Crawford, et al. Standards Track [Page 11] - -RFC 2874 IPv6 DNS July 2000 - - -5.1.3. Variations - - Several more-or-less arbitrary assumptions are reflected in the above - structure. All of the following choices could have been made - differently, according to someone's notion of convenience or an - agreement between two parties. - - First, that site X has chosen to put subnet information in a - separate A6 record rather than incorporate it into each node's A6 - records. - - Second, that site X is referred to as "SUBSCRIBER-X" by both of - its providers A and B. - - Third, that site X chose to indirect its provider information - through A6 records at IP6.X.EXAMPLE containing no significant - bits. An alternative would have been to replicate each subnet - record for each provider. - - Fourth, B and E used a slightly different prefix naming convention - between themselves than did A, C and D. Each hierarchical pair of - network entities must arrange this naming between themselves. - - Fifth, that the upward prefix referral chain topped out at ALPHA- - TLA.ORG. There could have been another level which assigned the - TLA values and holds A6 records containing those bits. - - Finally, the above structure reflects an assumption that address - fields assigned by a given entity are recorded only in A6 records - held by that entity. Those bits could be entered into A6 records in - the lower-level entity's zone instead, thus: - - IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET. - IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET. - - IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET. - and so on. - - Or the higher-level entities could hold both sorts of A6 records - (with different DNS owner names) and allow the lower-level entities - to choose either mode of A6 chaining. But the general principle of - avoiding data duplication suggests that the proper place to store - assigned values is with the entity that assigned them. - - It is possible, but not necessarily recommended, for a zone - maintainer to forego the renumbering support afforded by the chaining - of A6 records and to record entire IPv6 addresses within one zone - file. - - - -Crawford, et al. Standards Track [Page 12] - -RFC 2874 IPv6 DNS July 2000 - - -5.2. Reverse Mapping Zones - - Supposing that address space assignments in the TLAs with Format - Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in - zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then - the IP6.ARPA zone would include - - $ORIGIN IP6.ARPA. - \[x234500/24] DNAME IP6.ALPHA-TLA.ORG. - \[x267800/24] DNAME IP6.BRAVO-TLA.ORG. - \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY. - - Eight trailing zero bits have been included in each TLA ID to reflect - the eight reserved bits in the current aggregatable global unicast - addresses format [AGGR]. - -5.2.1. The TLA level - - ALPHA-TLA's assignments to network providers C, D and E are reflected - in the reverse data as follows. - - \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. - \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET. - \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET. - -5.2.2. The ISP level - - The providers A through E carry the following delegation information - in their zone files. - - \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. - \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET. - \[xEB/8].IP6.E.NET. DNAME IP6.B.NET. - \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. - \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE. - - Note that some domain names appear in the RDATA of more than one - DNAME record. In those cases, one zone is being used to map multiple - prefixes. - -5.2.3. The Site Level - - Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to- - name translations. This domain is now referenced by two different - DNAME records held by two different providers. - - - - - - -Crawford, et al. Standards Track [Page 13] - -RFC 2874 IPv6 DNS July 2000 - - - $ORIGIN IP6.X.EXAMPLE. - \[x0001/16] DNAME SUBNET-1 - \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. - and so on. - - SUBNET-1 need not have been named in a DNAME record; the subnet bits - could have been joined with the interface identifier. But if subnets - are treated alike in both the A6 records and in the reverse zone, it - will always be possible to keep the forward and reverse definition - data for each prefix in one zone. - -5.3. Lookups - - A DNS resolver looking for a hostname for the address - 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the - DNAME records shown above and would form new queries. Assuming that - it began the process knowing servers for IP6.ARPA, but that no server - it consulted provided recursion and none had other useful additional - information cached, the sequence of queried names and responses would - be (all with QCLASS=IN, QTYPE=PTR): - - To a server for IP6.ARPA: - QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA. - - Answer: - \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG. - - To a server for IP6.ALPHA-TLA.ORG: - QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG. - - Answer: - \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. - - To a server for IP6.C.NET.: - QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET. - - Answer: - \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. - - To a server for IP6.A.NET.: - QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET. - - Answer: - \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. - - To a server for IP6.X.EXAMPLE.: - QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE. - - - - -Crawford, et al. Standards Track [Page 14] - -RFC 2874 IPv6 DNS July 2000 - - - Answer: - \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. - \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE. - - All the DNAME (and NS) records acquired along the way can be cached - to expedite resolution of addresses topologically near to this - address. And if another global address of N.X.EXAMPLE were resolved - within the TTL of the final PTR record, that record would not have to - be fetched again. - -5.4. Operational Note - - In the illustrations in section 5.1, hierarchically adjacent - entities, such as a network provider and a customer, must agree on a - DNS name which will own the definition of the delegated prefix(es). - One simple convention would be to use a bit-string label representing - exactly the bits which are assigned to the lower-level entity by the - higher. For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]". - This would place the A6 record(s) defining the delegated prefix at - exactly the same point in the DNS tree as the DNAME record associated - with that delegation. The cost of this simplification is that the - lower-level zone must update its upward-pointing A6 records when it - is renumbered. This cost may be found quite acceptable in practice. - -6. Transition from RFC 1886 and Deployment Notes - - When prefixes have been "delegated upward" with A6 records, the - number of DNS resource records required to establish a single IPv6 - address increases by some non-trivial factor. Those records will - typically, but not necessarily, come from different DNS zones (which - can independently suffer failures for all the usual reasons). When - obtaining multiple IPv6 addresses together, this increase in RR count - will be proportionally less -- and the total size of a DNS reply - might even decrease -- if the addresses are topologically clustered. - But the records could still easily exceed the space available in a - UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or - SRV query, for example. The possibilities for overall degradation of - performance and reliability of DNS lookups are numerous, and increase - with the number of prefix delegations involved, especially when those - delegations point to records in other zones. - - DNS Security [DNSSEC] addresses the trustworthiness of cached data, - which is a problem intrinsic to DNS, but the cost of applying this to - an IPv6 address is multiplied by a factor which may be greater than - the number of prefix delegations involved if different signature - chains must be verified for different A6 records. If a trusted - centralized caching server (as in [TSIG], for example) is used, this - cost might be amortized to acceptable levels. One new phenomenon is - - - -Crawford, et al. Standards Track [Page 15] - -RFC 2874 IPv6 DNS July 2000 - - - the possibility that IPv6 addresses may be formed from a A6 records - from a combination of secure and unsecured zones. - - Until more deployment experience is gained with the A6 record, it is - recommended that prefix delegations be limited to one or two levels. - A reasonable phasing-in mechanism would be to start with no prefix - delegations (all A6 records having prefix length 0) and then to move - to the use of a single level of delegation within a single zone. (If - the TTL of the "prefix" A6 records is kept to an appropriate duration - the capability for rapid renumbering is not lost.) More aggressively - flexible delegation could be introduced for a subset of hosts for - experimentation. - -6.1. Transition from AAAA and Coexistence with A Records - - Administrators of zones which contain A6 records can easily - accommodate deployed resolvers which understand AAAA records but not - A6 records. Such administrators can do automatic generation of AAAA - records for all of a zone's names which own A6 records by a process - which mimics the resolution of a hostname to an IPv6 address (see - section 3.1.4). Attention must be paid to the TTL assigned to a - generated AAAA record, which MUST be no more than the minimum of the - TTLs of the A6 records that were used to form the IPv6 address in - that record. For full robustness, those A6 records which were in - different zones should be monitored for changes (in TTL or RDATA) - even when there are no changes to zone for which AAAA records are - being generated. If the zone is secure [DNSSEC], the generated AAAA - records MUST be signed along with the rest of the zone data. - - A zone-specific heuristic MAY be used to avoid generation of AAAA - records for A6 records which record prefixes, although such - superfluous records would be relatively few in number and harmless. - Examples of such heuristics include omitting A6 records with a prefix - length less than the largest value found in the zone file, or records - with an address suffix field with a certain number of trailing zero - bits. - - On the client side, when looking up and IPv6 address, the order of A6 - and AAAA queries MAY be configurable to be one of: A6, then AAAA; - AAAA, then A6; A6 only; or both in parallel. The default order (or - only order, if not configurable) MUST be to try A6 first, then AAAA. - If and when the AAAA becomes deprecated a new document will change - the default. - - The guidelines and options for precedence between IPv4 and IPv6 - addresses are specified in [TRANS]. All mentions of AAAA records in - that document are henceforth to be interpreted as meaning A6 and/or - AAAA records in the order specified in the previous paragraph. - - - -Crawford, et al. Standards Track [Page 16] - -RFC 2874 IPv6 DNS July 2000 - - -6.2. Transition from Nibble Labels to Binary Labels - - Implementations conforming to RFC 1886 [AAAA] perform reverse lookups - as follows: - - An IPv6 address is represented as a name in the IP6.INT domain by - a sequence of nibbles separated by dots with the suffix - ".IP6.INT". The sequence of nibbles is encoded in reverse order, - i.e. the low-order nibble is encoded first, followed by the next - low-order nibble and so on. Each nibble is represented by a - hexadecimal digit. For example, a name for the address - 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section - 5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.- - 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." - - Implementations conforming to this specification will perform a - lookup of a binary label in IP6.ARPA as specified in Section 3.2. It - is RECOMMENDED that for a transition period implementations first - lookup the binary label in IP6.ARPA and if this fails try to lookup - the 'nibble' label in IP6.INT. - -7. Security Considerations - - The signing authority [DNSSEC] for the A6 records which determine an - IPv6 address is distributed among several entities, reflecting the - delegation path of the address space which that address occupies. - DNS Security is fully applicable to bit-string labels and DNAME - records. And just as in IPv4, verification of name-to-address - mappings is logically independent of verification of address-to-name - mappings. - - With or without DNSSEC, the incomplete but non-empty address set - scenario of section 3.1.4 could be caused by selective interference - with DNS lookups. If in some situation this would be more harmful - than complete DNS failure, it might be mitigated on the client side - by refusing to act on an incomplete set, or on the server side by - listing all addresses in A6 records with prefix length 0. - -8. IANA Considerations - - The A6 resource record has been assigned a Type value of 38. - - - - - - - - - - -Crawford, et al. Standards Track [Page 17] - -RFC 2874 IPv6 DNS July 2000 - - -9. Acknowledgments - - The authors would like to thank the following persons for valuable - discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, Randy - Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont, - Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden, - Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik - Nordmark, Mike O'Dell, Michael Patton and Ken Powell. - -10. References - - [AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support IP - version 6, RFC 1886, December 1995. - - [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - - [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 - Aggregatable Global Unicast Address Format", RFC 2374, July - 1998. - - [BITLBL] Crawford, M., "Binary Labels in the Domain Name System", - RFC 2673, August 1999. - - [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC - 2672, August 1999. - - [DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [DNSIS] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System - Security Extensions", RFC 2535, March 1999. - - [KWORD] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC - 1900, February 1996. - - [RENUM2] Ferguson, P. and H. Berkowitz, "Network Renumbering - Overview: Why would I want it and what is it anyway?", RFC - 2071, January 1997. - - [RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address - Behaviour Today", RFC 2101, February 1997. - - - -Crawford, et al. Standards Track [Page 18] - -RFC 2874 IPv6 DNS July 2000 - - - [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for - IPv6 Hosts and Routers", RFC 1933, April 1996. - - [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - -11. Authors' Addresses - - Matt Crawford - Fermilab - MS 368 - PO Box 500 - Batavia, IL 60510 - USA - - Phone: +1 630 840-3461 - EMail: crawdad@fnal.gov - - - Christian Huitema - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052-6399 - - EMail: huitema@microsoft.com - - - - - - - - - - - - - - - - - - - - - - - - - -Crawford, et al. Standards Track [Page 19] - -RFC 2874 IPv6 DNS July 2000 - - -12. Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Crawford, et al. Standards Track [Page 20] - |
