From: hno <> Date: Thu, 5 Apr 2007 06:25:04 +0000 (+0000) Subject: Author: Amos Jeffries X-Git-Tag: SQUID_3_0_PRE6~136 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=cce51b55f36cf38bea43ecc9b3265c6b4cb99089;p=thirdparty%2Fsquid.git Author: Amos Jeffries IPV6 DNS and address formats RFCs rfc2874.txt DNS Extensions to Support IPv6 Address Aggregation and Renumbering Documents IPv6 reverse DNS lookups. fc3226.txt DNSSEC and IPv6 A6 aware server/resolver message size requirements Documents resolver requirements for IPv6 DNS structures and handling of advanced IPv6 lookups of A6 and DNAME records. rfc3513.txt Internet Protocol Version 6 (IPv6) Addressing Architecture Documents handling requirements for IP addresses under IPv6 and also new special case addresses defined by IANA. rfc3596.txt DNS Extensions to Support IP Version 6 Documents AAAA record details for basic IPv6 DNS resolvers. --- diff --git a/doc/rfc/1-index.txt b/doc/rfc/1-index.txt index 8c82df807e..5e086eca3f 100644 --- a/doc/rfc/1-index.txt +++ b/doc/rfc/1-index.txt @@ -22,14 +22,14 @@ rfc0959.txt FTP rfc1035.txt - DNS + DNS for IPv4 rfc1738.txt Uniform Resource Locators (URL) rfc1945.txt Hypertext Transfer Protocol -- HTTP/1.0 - + rfc2186.txt rfc2187.txt Internet Cache Protocol (ICP), version 2 @@ -61,6 +61,10 @@ rfc2818.txt HTTP Over TLS Documents the https:// scheme +rfc2874.txt + DNS Extensions to Support IPv6 Address Aggregation and Renumbering + Documents IPv6 reverse DNS lookups. + rfc2964.txt Use of HTTP State Management Cookies @@ -69,6 +73,11 @@ rfc2965.txt HTTP State Management Mechanism Cookies +rfc3226.txt + DNSSEC and IPv6 A6 aware server/resolver message size requirements + Documents resolver requirements for IPv6 DNS structures and handling + of advanced IPv6 lookups of A6 and DNAME records. + rfc3310.txt Updated Digest specification Most likely not in use for HTTP. Title says HTTP but all examples @@ -78,6 +87,15 @@ rfc3507.txt Internet Content Adaptation Protocol (ICAP/1.0) Common protocol for plugging into the datastream of a HTTP proxy +rfc3513.txt + Internet Protocol Version 6 (IPv6) Addressing Architecture + Documents handling requirements for IP addresses under IPv6 + and also new special case addresses defined by IANA. + +rfc3596.txt + DNS Extensions to Support IP Version 6 + Documents AAAA record details for basic IPv6 DNS resolvers. + rfc3875.txt CGI/1.1 specification used by cachemgr to get it's request arguments from the diff --git a/doc/rfc/rfc2874.txt b/doc/rfc/rfc2874.txt new file mode 100644 index 0000000000..915c104aa1 --- /dev/null +++ b/doc/rfc/rfc2874.txt @@ -0,0 +1,1123 @@ + + + + + + +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] + diff --git a/doc/rfc/rfc3226.txt b/doc/rfc/rfc3226.txt new file mode 100644 index 0000000000..d137ef2f28 --- /dev/null +++ b/doc/rfc/rfc3226.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group O. Gudmundsson +Request for Comments: 3226 December 2001 +Updates: 2874, 2535 +Category: Standards Track + + + DNSSEC and IPv6 A6 aware server/resolver message size requirements + +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 (2001). All Rights Reserved. + +Abstract + + This document mandates support for EDNS0 (Extension Mechanisms for + DNS) in DNS entities claiming to support either DNS Security + Extensions or A6 records. This requirement is necessary because + these new features increase the size of DNS messages. If EDNS0 is + not supported fall back to TCP will happen, having a detrimental + impact on query latency and DNS server load. This document updates + RFC 2535 and RFC 2874, by adding new requirements. + +1. Introduction + + Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions + [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful. + + STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP + have a data payload of 512 octets or less. Most DNS software today + will not accept larger UDP datagrams. Any answer that requires more + than 512 octets, results in a partial and sometimes useless reply + with the Truncation Bit set; in most cases the requester will then + retry using TCP. Furthermore, server delivery of truncated responses + varies widely and resolver handling of these responses also varies, + leading to additional inefficiencies in handling truncation. + + Compared to UDP, TCP is an expensive protocol to use for a simple + transaction like DNS: a TCP connection requires 5 packets for setup + and tear down, excluding data packets, thus requiring at least 3 + round trips on top of the one for the original UDP query. The DNS + + + +Gudmundsson Standards Track [Page 1] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + + server also needs to keep a state of the connection during this + transaction. Many DNS servers answer thousands of queries per + second, requiring them to use TCP will cause significant overhead and + delays. + +1.1. Requirements + + The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" + in this document are to be interpreted as described in RFC 2119. + +2. Motivating factors + +2.1. DNSSEC motivations + + DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each + RR set. These signatures range in size from about 80 octets to 800 + octets, most are going to be in the range of 80 to 200 octets. The + addition of signatures on each or most RR sets in an answer + significantly increases the size of DNS answers from secure zones. + + For performance reasons and to reduce load on DNS servers, it is + important that security aware servers and resolvers get all the data + in Answer and Authority section in one query without truncation. + Sending Additional Data in the same query is helpful when the server + is authoritative for the data, and this reduces round trips. + + DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that + it is interested in receiving DNSSEC records. The OK bit does not + eliminate the need for large answers for DNSSEC capable clients. + +2.1.1. Message authentication or TSIG motivation + + TSIG [RFC2845] allows for the light weight authentication of DNS + messages, but increases the size of the messages by at least 70 + octets. DNSSEC specifies for computationally expensive message + authentication SIG(0) using a standard public key signature. As only + one TSIG or SIG(0) can be attached to each DNS answer the size + increase of message authentication is not significant, but may still + lead to a truncation. + +2.2. IPv6 Motivations + + IPv6 addresses [RFC2874] are 128 bits and can be represented in the + DNS by multiple A6 records, each consisting of a domain name and a + bit field. The domain name refers to an address prefix that may + require additional A6 RRs to be included in the answer. Answers + where the queried name has multiple A6 addresses may overflow a 512- + octet UDP packet size. + + + +Gudmundsson Standards Track [Page 2] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +2.3. Root server and TLD server motivations + + The current number of root servers is limited to 13 as that is the + maximum number of name servers and their address records that fit in + one 512-octet answer for a SOA record. If root servers start + advertising A6 or KEY records then the answer for the root NS records + will not fit in a single 512-octet DNS message, resulting in a large + number of TCP query connections to the root servers. Even if all + client resolver query their local name server for information, there + are millions of these servers. Each name server must periodically + update its information about the high level servers. + + For redundancy, latency and load balancing reasons, large numbers of + DNS servers are required for some zones. Since the root zone is used + by the entire net, it is important to have as many servers as + possible. Large TLDs (and many high-visibility SLDs) often have + enough servers that either A6 or KEY records would cause the NS + response to overflow the 512 byte limit. Note that these zones with + large numbers of servers are often exactly those zones that are + critical to network operation and that already sustain fairly high + loads. + +2.4. UDP vs TCP for DNS messages + + Given all these factors, it is essential that any implementation that + supports DNSSEC and or A6 be able to use larger DNS messages than 512 + octets. + + The original 512 restriction was put in place to reduce the + probability of fragmentation of DNS responses. A fragmented UDP + message that suffers a loss of one of the fragments renders the + answer useless and the query must be retried. A TCP connection + requires a larger number of round trips for establishment, data + transfer and tear down, but only the lost data segments are + retransmitted. + + In the early days a number of IP implementations did not handle + fragmentation well, but all modern operating systems have overcome + that issue thus sending fragmented messages is fine from that + standpoint. The open issue is the effect of losses on fragmented + messages. If connection has high loss ratio only TCP will allow + reliable transfer of DNS data, most links have low loss ratios thus + sending fragmented UDP packet in one round trip is better than + establishing a TCP connection to transfer a few thousand octets. + + + + + + + +Gudmundsson Standards Track [Page 3] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +2.5. EDNS0 and large UDP messages + + EDNS0 [RFC2671] allows clients to declare the maximum size of UDP + message they are willing to handle. Thus, if the expected answer is + between 512 octets and the maximum size that the client can accept, + the additional overhead of a TCP connection can be avoided. + +3. Protocol changes: + + This document updates RFC 2535 and RFC 2874, by adding new + requirements. + + All RFC 2535 compliant servers and resolvers MUST support EDNS0 and + advertise message size of at least 1220 octets, but SHOULD advertise + message size of 4000. This value might be too low to get full + answers for high level servers and successor of this document may + require a larger value. + + All RFC 2874 compliant servers and resolver MUST support EDNS0 and + advertise message size of at least 1024 octets, but SHOULD advertise + message size of 2048. The IPv6 datagrams should be 1024 octets, + unless the MTU of the path is known. (Note that this is smaller than + the minimum IPv6 MTU to allow for some extension headers and/or + encapsulation without exceeding the minimum MTU.) + + All RFC 2535 and RFC 2874 compliant entities MUST be able to handle + fragmented IPv4 and IPv6 UDP packets. + + All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger + required value in EDNS0 advertisements. + +4. Acknowledgments + + Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas + Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis + Michael Patton and Kazu Yamamoto were instrumental in motivating and + shaping this document. + +5. Security Considerations: + + There are no additional security considerations other than those in + RFC 2671. + +6. IANA Considerations: + + None + + + + + +Gudmundsson Standards Track [Page 4] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +7. References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC2535] Eastlake, D. "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support + IPv6 Address Aggregation and Renumbering", RFC 2874, July + 2000. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + +8. Author Address + + Olafur Gudmundsson + 3826 Legation Street, NW + Washington, DC 20015 + USA + + EMail: ogud@ogud.com + + + + + + + + + + + + + + + + + + +Gudmundsson Standards Track [Page 5] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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. + + + + + + + + + + + + + + + + + + + +Gudmundsson Standards Track [Page 6] + diff --git a/doc/rfc/rfc3513.txt b/doc/rfc/rfc3513.txt new file mode 100644 index 0000000000..7793621b0a --- /dev/null +++ b/doc/rfc/rfc3513.txt @@ -0,0 +1,1460 @@ + + + + + +Network Working Group R. Hinden +Request for Comments: 3513 Nokia +Obsoletes: 2373 S. Deering +Category: Standards Track Cisco Systems + April 2003 + + + Internet Protocol Version 6 (IPv6) Addressing Architecture + +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 (2003). All Rights Reserved. + +Abstract + + This specification defines the addressing architecture of the IP + Version 6 (IPv6) protocol. The document includes the IPv6 addressing + model, text representations of IPv6 addresses, definition of IPv6 + unicast addresses, anycast addresses, and multicast addresses, and an + IPv6 node's required addresses. + + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 1] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +Table of Contents + + 1. Introduction.................................................3 + 2. IPv6 Addressing..............................................3 + 2.1 Addressing Model.........................................4 + 2.2 Text Representation of Addresses.........................4 + 2.3 Text Representation of Address Prefixes..................5 + 2.4 Address Type Identification..............................6 + 2.5 Unicast Addresses........................................7 + 2.5.1 Interface Identifiers..............................8 + 2.5.2 The Unspecified Address............................9 + 2.5.3 The Loopback Address...............................9 + 2.5.4 Global Unicast Addresses..........................10 + 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.......10 + 2.5.6 Local-use IPv6 Unicast Addresses..................11 + 2.6 Anycast Addresses.......................................12 + 2.6.1 Required Anycast Address..........................13 + 2.7 Multicast Addresses.....................................13 + 2.7.1 Pre-Defined Multicast Addresses...................15 + 2.8 A Node's Required Addresses.............................17 + 3. Security Considerations.....................................17 + 4. IANA Considerations.........................................18 + 5. References..................................................19 + 5.1 Normative References....................................19 + 5.2 Informative References..................................19 + APPENDIX A: Creating Modified EUI-64 format Interface IDs......21 + APPENDIX B: Changes from RFC-2373..............................24 + Authors' Addresses.............................................25 + Full Copyright Statement.......................................26 + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 2] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +1. Introduction + + This specification defines the addressing architecture of the IP + Version 6 (IPv6) protocol. It includes the basic formats for the + various types of IPv6 addresses (unicast, anycast, and multicast). + + The authors would like to acknowledge the contributions of Paul + Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, + Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, + Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg + Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, + Sue Thomson, Markku Savela, and Larry Masinter. + +2. IPv6 Addressing + + IPv6 addresses are 128-bit identifiers for interfaces and sets of + interfaces (where "interface" is as defined in section 2 of [IPV6]). + There are three types of addresses: + + Unicast: An identifier for a single interface. A packet sent to a + unicast address is delivered to the interface identified + by that address. + + Anycast: An identifier for a set of interfaces (typically belonging + to different nodes). A packet sent to an anycast address + is delivered to one of the interfaces identified by that + address (the "nearest" one, according to the routing + protocols' measure of distance). + + Multicast: An identifier for a set of interfaces (typically belonging + to different nodes). A packet sent to a multicast address + is delivered to all interfaces identified by that address. + + There are no broadcast addresses in IPv6, their function being + superseded by multicast addresses. + + In this document, fields in addresses are given a specific name, for + example "subnet". When this name is used with the term "ID" for + identifier after the name (e.g., "subnet ID"), it refers to the + contents of the named field. When it is used with the term "prefix" + (e.g., "subnet prefix") it refers to all of the address from the left + up to and including this field. + + In IPv6, all zeros and all ones are legal values for any field, + unless specifically excluded. Specifically, prefixes may contain, or + end with, zero-valued fields. + + + + + +Hinden & Deering Standards Track [Page 3] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +2.1 Addressing Model + + IPv6 addresses of all types are assigned to interfaces, not nodes. + An IPv6 unicast address refers to a single interface. Since each + interface belongs to a single node, any of that node's interfaces' + unicast addresses may be used as an identifier for the node. + + All interfaces are required to have at least one link-local unicast + address (see section 2.8 for additional required addresses). A + single interface may also have multiple IPv6 addresses of any type + (unicast, anycast, and multicast) or scope. Unicast addresses with + scope greater than link-scope are not needed for interfaces that are + not used as the origin or destination of any IPv6 packets to or from + non-neighbors. This is sometimes convenient for point-to-point + interfaces. There is one exception to this addressing model: + + A unicast address or a set of unicast addresses may be assigned to + multiple physical interfaces if the implementation treats the + multiple physical interfaces as one interface when presenting it + to the internet layer. This is useful for load-sharing over + multiple physical interfaces. + + Currently IPv6 continues the IPv4 model that a subnet prefix is + associated with one link. Multiple subnet prefixes may be assigned + to the same link. + +2.2 Text Representation of Addresses + + There are three conventional forms for representing IPv6 addresses as + text strings: + + 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the + hexadecimal values of the eight 16-bit pieces of the address. + + Examples: + + FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 + + 1080:0:0:0:8:800:200C:417A + + Note that it is not necessary to write the leading zeros in an + individual field, but there must be at least one numeral in every + field (except for the case described in 2.). + + 2. Due to some methods of allocating certain styles of IPv6 + addresses, it will be common for addresses to contain long strings + of zero bits. In order to make writing addresses containing zero + bits easier a special syntax is available to compress the zeros. + + + +Hinden & Deering Standards Track [Page 4] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + The use of "::" indicates one or more groups of 16 bits of zeros. + The "::" can only appear once in an address. The "::" can also be + used to compress leading or trailing zeros in an address. + + For example, the following addresses: + + 1080:0:0:0:8:800:200C:417A a unicast address + FF01:0:0:0:0:0:0:101 a multicast address + 0:0:0:0:0:0:0:1 the loopback address + 0:0:0:0:0:0:0:0 the unspecified addresses + + may be represented as: + + 1080::8:800:200C:417A a unicast address + FF01::101 a multicast address + ::1 the loopback address + :: the unspecified addresses + + 3. An alternative form that is sometimes more convenient when dealing + with a mixed environment of IPv4 and IPv6 nodes is + x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of + the six high-order 16-bit pieces of the address, and the 'd's are + the decimal values of the four low-order 8-bit pieces of the + address (standard IPv4 representation). Examples: + + 0:0:0:0:0:0:13.1.68.3 + + 0:0:0:0:0:FFFF:129.144.52.38 + + or in compressed form: + + ::13.1.68.3 + + ::FFFF:129.144.52.38 + +2.3 Text Representation of Address Prefixes + + The text representation of IPv6 address prefixes is similar to the + way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An + IPv6 address prefix is represented by the notation: + + ipv6-address/prefix-length + + where + + ipv6-address is an IPv6 address in any of the notations listed + in section 2.2. + + + + +Hinden & Deering Standards Track [Page 5] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + prefix-length is a decimal value specifying how many of the + leftmost contiguous bits of the address comprise + the prefix. + + For example, the following are legal representations of the 60-bit + prefix 12AB00000000CD3 (hexadecimal): + + 12AB:0000:0000:CD30:0000:0000:0000:0000/60 + 12AB::CD30:0:0:0:0/60 + 12AB:0:0:CD30::/60 + + The following are NOT legal representations of the above prefix: + + 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, + within any 16-bit chunk of the address + + 12AB::CD30/60 address to left of "/" expands to + 12AB:0000:0000:0000:0000:000:0000:CD30 + + 12AB::CD3/60 address to left of "/" expands to + 12AB:0000:0000:0000:0000:000:0000:0CD3 + + When writing both a node address and a prefix of that node address + (e.g., the node's subnet prefix), the two can combined as follows: + + the node address 12AB:0:0:CD30:123:4567:89AB:CDEF + and its subnet number 12AB:0:0:CD30::/60 + + can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 + +2.4 Address Type Identification + + The type of an IPv6 address is identified by the high-order bits of + the address, as follows: + + Address type Binary prefix IPv6 notation Section + ------------ ------------- ------------- ------- + Unspecified 00...0 (128 bits) ::/128 2.5.2 + Loopback 00...1 (128 bits) ::1/128 2.5.3 + Multicast 11111111 FF00::/8 2.7 + Link-local unicast 1111111010 FE80::/10 2.5.6 + Site-local unicast 1111111011 FEC0::/10 2.5.6 + Global unicast (everything else) + + Anycast addresses are taken from the unicast address spaces (of any + scope) and are not syntactically distinguishable from unicast + addresses. + + + + +Hinden & Deering Standards Track [Page 6] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + The general format of global unicast addresses is described in + section 2.5.4. Some special-purpose subtypes of global unicast + addresses which contain embedded IPv4 addresses (for the purposes of + IPv4-IPv6 interoperation) are described in section 2.5.5. + + Future specifications may redefine one or more sub-ranges of the + global unicast space for other purposes, but unless and until that + happens, implementations must treat all addresses that do not start + with any of the above-listed prefixes as global unicast addresses. + +2.5 Unicast Addresses + + IPv6 unicast addresses are aggregable with prefixes of arbitrary + bit-length similar to IPv4 addresses under Classless Interdomain + Routing. + + There are several types of unicast addresses in IPv6, in particular + global unicast, site-local unicast, and link-local unicast. There + are also some special-purpose subtypes of global unicast, such as + IPv6 addresses with embedded IPv4 addresses or encoded NSAP + addresses. Additional address types or subtypes can be defined in + the future. + + IPv6 nodes may have considerable or little knowledge of the internal + structure of the IPv6 address, depending on the role the node plays + (for instance, host versus router). At a minimum, a node may + consider that unicast addresses (including its own) have no internal + structure: + + | 128 bits | + +-----------------------------------------------------------------+ + | node address | + +-----------------------------------------------------------------+ + + A slightly sophisticated host (but still rather simple) may + additionally be aware of subnet prefix(es) for the link(s) it is + attached to, where different addresses may have different values for + n: + + | n bits | 128-n bits | + +------------------------------------------------+----------------+ + | subnet prefix | interface ID | + +------------------------------------------------+----------------+ + + Though a very simple router may have no knowledge of the internal + structure of IPv6 unicast addresses, routers will more generally have + knowledge of one or more of the hierarchical boundaries for the + operation of routing protocols. The known boundaries will differ + + + +Hinden & Deering Standards Track [Page 7] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + from router to router, depending on what positions the router holds + in the routing hierarchy. + +2.5.1 Interface Identifiers + + Interface identifiers in IPv6 unicast addresses are used to identify + interfaces on a link. They are required to be unique within a subnet + prefix. It is recommended that the same interface identifier not be + assigned to different nodes on a link. They may also be unique over + a broader scope. In some cases an interface's identifier will be + derived directly from that interface's link-layer address. The same + interface identifier may be used on multiple interfaces on a single + node, as long as they are attached to different subnets. + + Note that the uniqueness of interface identifiers is independent of + the uniqueness of IPv6 addresses. For example, a global unicast + address may be created with a non-global scope interface identifier + and a site-local address may be created with a global scope interface + identifier. + + For all unicast addresses, except those that start with binary value + 000, Interface IDs are required to be 64 bits long and to be + constructed in Modified EUI-64 format. + + Modified EUI-64 format based Interface identifiers may have global + scope when derived from a global token (e.g., IEEE 802 48-bit MAC or + IEEE EUI-64 identifiers [EUI64]) or may have local scope where a + global token is not available (e.g., serial links, tunnel end-points, + etc.) or where global tokens are undesirable (e.g., temporary tokens + for privacy [PRIV]). + + Modified EUI-64 format interface identifiers are formed by inverting + the "u" bit (universal/local bit in IEEE EUI-64 terminology) when + forming the interface identifier from IEEE EUI-64 identifiers. In + the resulting Modified EUI-64 format the "u" bit is set to one (1) to + indicate global scope, and it is set to zero (0) to indicate local + scope. The first three octets in binary of an IEEE EUI-64 identifier + are as follows: + + 0 0 0 1 1 2 + |0 7 8 5 6 3| + +----+----+----+----+----+----+ + |cccc|ccug|cccc|cccc|cccc|cccc| + +----+----+----+----+----+----+ + + written in Internet standard bit-order , where "u" is the + universal/local bit, "g" is the individual/group bit, and "c" are the + bits of the company_id. Appendix A: "Creating Modified EUI-64 format + + + +Hinden & Deering Standards Track [Page 8] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + Interface Identifiers" provides examples on the creation of Modified + EUI-64 format based interface identifiers. + + The motivation for inverting the "u" bit when forming an interface + identifier is to make it easy for system administrators to hand + configure non-global identifiers when hardware tokens are not + available. This is expected to be case for serial links, tunnel end- + points, etc. The alternative would have been for these to be of the + form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2, + etc. + + The use of the universal/local bit in the Modified EUI-64 format + identifier is to allow development of future technology that can take + advantage of interface identifiers with global scope. + + The details of forming interface identifiers are defined in the + appropriate "IPv6 over " specification such as "IPv6 over + Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. + +2.5.2 The Unspecified Address + + The address 0:0:0:0:0:0:0:0 is called the unspecified address. It + must never be assigned to any node. It indicates the absence of an + address. One example of its use is in the Source Address field of + any IPv6 packets sent by an initializing host before it has learned + its own address. + + The unspecified address must not be used as the destination address + of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a + source address of unspecified must never be forwarded by an IPv6 + router. + +2.5.3 The Loopback Address + + The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. + It may be used by a node to send an IPv6 packet to itself. It may + never be assigned to any physical interface. It is treated as + having link-local scope, and may be thought of as the link-local + unicast address of a virtual interface (typically called "the + loopback interface") to an imaginary link that goes nowhere. + + The loopback address must not be used as the source address in IPv6 + packets that are sent outside of a single node. An IPv6 packet with + a destination address of loopback must never be sent outside of a + single node and must never be forwarded by an IPv6 router. A packet + received on an interface with destination address of loopback must be + dropped. + + + + +Hinden & Deering Standards Track [Page 9] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +2.5.4 Global Unicast Addresses + + The general format for IPv6 global unicast addresses is as follows: + + | n bits | m bits | 128-n-m bits | + +------------------------+-----------+----------------------------+ + | global routing prefix | subnet ID | interface ID | + +------------------------+-----------+----------------------------+ + + where the global routing prefix is a (typically hierarchically- + structured) value assigned to a site (a cluster of subnets/links), + the subnet ID is an identifier of a link within the site, and the + interface ID is as defined in section 2.5.1. + + All global unicast addresses other than those that start with binary + 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as + described in section 2.5.1. Global unicast addresses that start with + binary 000 have no such constraint on the size or structure of the + interface ID field. + + Examples of global unicast addresses that start with binary 000 are + the IPv6 address with embedded IPv4 addresses described in section + 2.5.5 and the IPv6 address containing encoded NSAP addresses + specified in [NSAP]. An example of global addresses starting with a + binary value other than 000 (and therefore having a 64-bit interface + ID field) can be found in [AGGR]. + +2.5.5 IPv6 Addresses with Embedded IPv4 Addresses + + The IPv6 transition mechanisms [TRAN] include a technique for hosts + and routers to dynamically tunnel IPv6 packets over IPv4 routing + infrastructure. IPv6 nodes that use this technique are assigned + special IPv6 unicast addresses that carry a global IPv4 address in + the low-order 32 bits. This type of address is termed an "IPv4- + compatible IPv6 address" and has the format: + + | 80 bits | 16 | 32 bits | + +--------------------------------------+--------------------------+ + |0000..............................0000|0000| IPv4 address | + +--------------------------------------+----+---------------------+ + + Note: The IPv4 address used in the "IPv4-compatible IPv6 address" + must be a globally-unique IPv4 unicast address. + + A second type of IPv6 address which holds an embedded IPv4 address is + also defined. This address type is used to represent the addresses + of IPv4 nodes as IPv6 addresses. This type of address is termed an + "IPv4-mapped IPv6 address" and has the format: + + + +Hinden & Deering Standards Track [Page 10] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + | 80 bits | 16 | 32 bits | + +--------------------------------------+--------------------------+ + |0000..............................0000|FFFF| IPv4 address | + +--------------------------------------+----+---------------------+ + +2.5.6 Local-Use IPv6 Unicast Addresses + + There are two types of local-use unicast addresses defined. These + are Link-Local and Site-Local. The Link-Local is for use on a single + link and the Site-Local is for use in a single site. Link-Local + addresses have the following format: + + | 10 | + | bits | 54 bits | 64 bits | + +----------+-------------------------+----------------------------+ + |1111111010| 0 | interface ID | + +----------+-------------------------+----------------------------+ + + Link-Local addresses are designed to be used for addressing on a + single link for purposes such as automatic address configuration, + neighbor discovery, or when no routers are present. + + Routers must not forward any packets with link-local source or + destination addresses to other links. + + Site-Local addresses have the following format: + + | 10 | + | bits | 54 bits | 64 bits | + +----------+-------------------------+----------------------------+ + |1111111011| subnet ID | interface ID | + +----------+-------------------------+----------------------------+ + + Site-local addresses are designed to be used for addressing inside of + a site without the need for a global prefix. Although a subnet ID + may be up to 54-bits long, it is expected that globally-connected + sites will use the same subnet IDs for site-local and global + prefixes. + + Routers must not forward any packets with site-local source or + destination addresses outside of the site. + + + + + + + + + + +Hinden & Deering Standards Track [Page 11] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +2.6 Anycast Addresses + + An IPv6 anycast address is an address that is assigned to more than + one interface (typically belonging to different nodes), with the + property that a packet sent to an anycast address is routed to the + "nearest" interface having that address, according to the routing + protocols' measure of distance. + + Anycast addresses are allocated from the unicast address space, using + any of the defined unicast address formats. Thus, anycast addresses + are syntactically indistinguishable from unicast addresses. When a + unicast address is assigned to more than one interface, thus turning + it into an anycast address, the nodes to which the address is + assigned must be explicitly configured to know that it is an anycast + address. + + For any assigned anycast address, there is a longest prefix P of that + address that identifies the topological region in which all + interfaces belonging to that anycast address reside. Within the + region identified by P, the anycast address must be maintained as a + separate entry in the routing system (commonly referred to as a "host + route"); outside the region identified by P, the anycast address may + be aggregated into the routing entry for prefix P. + + Note that in the worst case, the prefix P of an anycast set may be + the null prefix, i.e., the members of the set may have no topological + locality. In that case, the anycast address must be maintained as a + separate routing entry throughout the entire internet, which presents + a severe scaling limit on how many such "global" anycast sets may be + supported. Therefore, it is expected that support for global anycast + sets may be unavailable or very restricted. + + One expected use of anycast addresses is to identify the set of + routers belonging to an organization providing internet service. + Such addresses could be used as intermediate addresses in an IPv6 + Routing header, to cause a packet to be delivered via a particular + service provider or sequence of service providers. + + Some other possible uses are to identify the set of routers attached + to a particular subnet, or the set of routers providing entry into a + particular routing domain. + + There is little experience with widespread, arbitrary use of internet + anycast addresses, and some known complications and hazards when + using them in their full generality [ANYCST]. Until more experience + has been gained and solutions are specified, the following + restrictions are imposed on IPv6 anycast addresses: + + + + +Hinden & Deering Standards Track [Page 12] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + o An anycast address must not be used as the source address of an + IPv6 packet. + + o An anycast address must not be assigned to an IPv6 host, that is, + it may be assigned to an IPv6 router only. + +2.6.1 Required Anycast Address + + The Subnet-Router anycast address is predefined. Its format is as + follows: + + | n bits | 128-n bits | + +------------------------------------------------+----------------+ + | subnet prefix | 00000000000000 | + +------------------------------------------------+----------------+ + + The "subnet prefix" in an anycast address is the prefix which + identifies a specific link. This anycast address is syntactically + the same as a unicast address for an interface on the link with the + interface identifier set to zero. + + Packets sent to the Subnet-Router anycast address will be delivered + to one router on the subnet. All routers are required to support the + Subnet-Router anycast addresses for the subnets to which they have + interfaces. + + The subnet-router anycast address is intended to be used for + applications where a node needs to communicate with any one of the + set of routers. + +2.7 Multicast Addresses + + An IPv6 multicast address is an identifier for a group of interfaces + (typically on different nodes). An interface may belong to any + number of multicast groups. Multicast addresses have the following + format: + + | 8 | 4 | 4 | 112 bits | + +------ -+----+----+---------------------------------------------+ + |11111111|flgs|scop| group ID | + +--------+----+----+---------------------------------------------+ + + binary 11111111 at the start of the address identifies the + address as being a multicast address. + + +-+-+-+-+ + flgs is a set of 4 flags: |0|0|0|T| + +-+-+-+-+ + + + +Hinden & Deering Standards Track [Page 13] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + The high-order 3 flags are reserved, and must be initialized + to 0. + + T = 0 indicates a permanently-assigned ("well-known") + multicast address, assigned by the Internet Assigned Number + Authority (IANA). + + T = 1 indicates a non-permanently-assigned ("transient") + multicast address. + + scop is a 4-bit multicast scope value used to limit the scope + of the multicast group. The values are: + + 0 reserved + 1 interface-local scope + 2 link-local scope + 3 reserved + 4 admin-local scope + 5 site-local scope + 6 (unassigned) + 7 (unassigned) + 8 organization-local scope + 9 (unassigned) + A (unassigned) + B (unassigned) + C (unassigned) + D (unassigned) + E global scope + F reserved + + interface-local scope spans only a single interface on a + node, and is useful only for loopback transmission of + multicast. + + link-local and site-local multicast scopes span the same + topological regions as the corresponding unicast scopes. + + admin-local scope is the smallest scope that must be + administratively configured, i.e., not automatically derived + from physical connectivity or other, non- multicast-related + configuration. + + organization-local scope is intended to span multiple sites + belonging to a single organization. + + scopes labeled "(unassigned)" are available for + administrators to define additional multicast regions. + + + + +Hinden & Deering Standards Track [Page 14] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + group ID identifies the multicast group, either permanent or + transient, within the given scope. + + The "meaning" of a permanently-assigned multicast address is + independent of the scope value. For example, if the "NTP servers + group" is assigned a permanent multicast address with a group ID of + 101 (hex), then: + + FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface + (i.e., the same node) as the sender. + + FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the + sender. + + FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the + sender. + + FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet. + + Non-permanently-assigned multicast addresses are meaningful only + within a given scope. For example, a group identified by the non- + permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one + site bears no relationship to a group using the same address at a + different site, nor to a non-permanent group using the same group ID + with different scope, nor to a permanent group with the same group + ID. + + Multicast addresses must not be used as source addresses in IPv6 + packets or appear in any Routing header. + + Routers must not forward any multicast packets beyond of the scope + indicated by the scop field in the destination multicast address. + + Nodes must not originate a packet to a multicast address whose scop + field contains the reserved value 0; if such a packet is received, it + must be silently dropped. Nodes should not originate a packet to a + multicast address whose scop field contains the reserved value F; if + such a packet is sent or received, it must be treated the same as + packets destined to a global (scop E) multicast address. + +2.7.1 Pre-Defined Multicast Addresses + + The following well-known multicast addresses are pre-defined. The + group ID's defined in this section are defined for explicit scope + values. + + Use of these group IDs for any other scope values, with the T flag + equal to 0, is not allowed. + + + +Hinden & Deering Standards Track [Page 15] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 + FF01:0:0:0:0:0:0:0 + FF02:0:0:0:0:0:0:0 + FF03:0:0:0:0:0:0:0 + FF04:0:0:0:0:0:0:0 + FF05:0:0:0:0:0:0:0 + FF06:0:0:0:0:0:0:0 + FF07:0:0:0:0:0:0:0 + FF08:0:0:0:0:0:0:0 + FF09:0:0:0:0:0:0:0 + FF0A:0:0:0:0:0:0:0 + FF0B:0:0:0:0:0:0:0 + FF0C:0:0:0:0:0:0:0 + FF0D:0:0:0:0:0:0:0 + FF0E:0:0:0:0:0:0:0 + FF0F:0:0:0:0:0:0:0 + + The above multicast addresses are reserved and shall never be + assigned to any multicast group. + + All Nodes Addresses: FF01:0:0:0:0:0:0:1 + FF02:0:0:0:0:0:0:1 + + The above multicast addresses identify the group of all IPv6 nodes, + within scope 1 (interface-local) or 2 (link-local). + + All Routers Addresses: FF01:0:0:0:0:0:0:2 + FF02:0:0:0:0:0:0:2 + FF05:0:0:0:0:0:0:2 + + The above multicast addresses identify the group of all IPv6 routers, + within scope 1 (interface-local), 2 (link-local), or 5 (site-local). + + Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX + + Solicited-node multicast address are computed as a function of a + node's unicast and anycast addresses. A solicited-node multicast + address is formed by taking the low-order 24 bits of an address + (unicast or anycast) and appending those bits to the prefix + FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the + range + + FF02:0:0:0:0:1:FF00:0000 + + to + + FF02:0:0:0:0:1:FFFF:FFFF + + + + +Hinden & Deering Standards Track [Page 16] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + For example, the solicited node multicast address corresponding to + the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 + addresses that differ only in the high-order bits, e.g., due to + multiple high-order prefixes associated with different aggregations, + will map to the same solicited-node address thereby, reducing the + number of multicast addresses a node must join. + + A node is required to compute and join (on the appropriate interface) + the associated Solicited-Node multicast addresses for every unicast + and anycast address it is assigned. + +2.8 A Node's Required Addresses + + A host is required to recognize the following addresses as + identifying itself: + + o Its required Link-Local Address for each interface. + o Any additional Unicast and Anycast Addresses that have been + configured for the node's interfaces (manually or + automatically). + o The loopback address. + o The All-Nodes Multicast Addresses defined in section 2.7.1. + o The Solicited-Node Multicast Address for each of its unicast + and anycast addresses. + o Multicast Addresses of all other groups to which the node + belongs. + + A router is required to recognize all addresses that a host is + required to recognize, plus the following addresses as identifying + itself: + + o The Subnet-Router Anycast Addresses for all interfaces for + which it is configured to act as a router. + o All other Anycast Addresses with which the router has been + configured. + o The All-Routers Multicast Addresses defined in section 2.7.1. + +3. Security Considerations + + IPv6 addressing documents do not have any direct impact on Internet + infrastructure security. Authentication of IPv6 packets is defined + in [AUTH]. + + + + + + + + + +Hinden & Deering Standards Track [Page 17] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +4. IANA Considerations + + The table and notes at http://www.isi.edu/in- + notes/iana/assignments/ipv6-address-space.txt should be replaced with + the following: + + INTERNET PROTOCOL VERSION 6 ADDRESS SPACE + + The initial assignment of IPv6 address space is as follows: + + Allocation Prefix Fraction of + (binary) Address Space + ----------------------------------- -------- ------------- + Unassigned (see Note 1 below) 0000 0000 1/256 + Unassigned 0000 0001 1/256 + Reserved for NSAP Allocation 0000 001 1/128 [RFC1888] + Unassigned 0000 01 1/64 + Unassigned 0000 1 1/32 + Unassigned 0001 1/16 + Global Unicast 001 1/8 [RFC2374] + Unassigned 010 1/8 + Unassigned 011 1/8 + Unassigned 100 1/8 + Unassigned 101 1/8 + Unassigned 110 1/8 + Unassigned 1110 1/16 + Unassigned 1111 0 1/32 + Unassigned 1111 10 1/64 + Unassigned 1111 110 1/128 + Unassigned 1111 1110 0 1/512 + Link-Local Unicast Addresses 1111 1110 10 1/1024 + Site-Local Unicast Addresses 1111 1110 11 1/1024 + Multicast Addresses 1111 1111 1/256 + + Notes: + + 1. The "unspecified address", the "loopback address", and the IPv6 + Addresses with Embedded IPv4 Addresses are assigned out of the + 0000 0000 binary prefix space. + + 2. For now, IANA should limit its allocation of IPv6 unicast address + space to the range of addresses that start with binary value 001. + The rest of the global unicast address space (approximately 85% of + the IPv6 address space) is reserved for future definition and use, + and is not to be assigned by IANA at this time. + + + + + + +Hinden & Deering Standards Track [Page 18] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +5. References + +5.1 Normative References + + [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9 , RFC 2026, October 1996. + +5.2 Informative References + + [ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting + Service", RFC 1546, November 1993. + + [AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC + 2402, November 1998. + + [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable + Global Unicast Address Format", RFC 2374, July 1998. + + [CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless + Inter-Domain Routing (CIDR): An Address Assignment and + Aggregation Strategy", RFC 1519, September 1993. + + [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet + Networks", RFC 2464, December 1998. + + [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) + Registration Authority", + http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, + March 1997. + + [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI + Networks", RFC 2467, December 1998. + + [MASGN] Hinden, R. and S. Deering, "IPv6 Multicast Address + Assignments", RFC 2375, July 1998. + + [NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J. + and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996. + + [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless + Address Autoconfiguration in IPv6", RFC 3041, January 2001. + + [TOKEN] Crawford, M., Narten, T. and S. Thomas, "Transmission of + IPv6 Packets over Token Ring Networks", RFC 2470, December + 1998. + + + +Hinden & Deering Standards Track [Page 19] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + [TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for + IPv6 Hosts and Routers", RFC 2893, August 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 20] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +APPENDIX A: Creating Modified EUI-64 format Interface Identifiers + + Depending on the characteristics of a specific link or node there are + a number of approaches for creating Modified EUI-64 format interface + identifiers. This appendix describes some of these approaches. + +Links or Nodes with IEEE EUI-64 Identifiers + + The only change needed to transform an IEEE EUI-64 identifier to an + interface identifier is to invert the "u" (universal/local) bit. For + example, a globally unique IEEE EUI-64 identifier of the form: + + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| + +----------------+----------------+----------------+----------------+ + + where "c" are the bits of the assigned company_id, "0" is the value + of the universal/local bit to indicate global scope, "g" is + individual/group bit, and "m" are the bits of the manufacturer- + selected extension identifier. The IPv6 interface identifier would + be of the form: + + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| + +----------------+----------------+----------------+----------------+ + + The only change is inverting the value of the universal/local bit. + +Links or Nodes with IEEE 802 48 bit MAC's + + [EUI64] defines a method to create a IEEE EUI-64 identifier from an + IEEE 48bit MAC identifier. This is to insert two octets, with + hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC + (between the company_id and vendor supplied id). For example, the 48 + bit IEEE MAC with global scope: + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 21] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + |0 1|1 3|3 4| + |0 5|6 1|2 7| + +----------------+----------------+----------------+ + |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| + +----------------+----------------+----------------+ + + where "c" are the bits of the assigned company_id, "0" is the value + of the universal/local bit to indicate global scope, "g" is + individual/group bit, and "m" are the bits of the manufacturer- + selected extension identifier. The interface identifier would be of + the form: + + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| + +----------------+----------------+----------------+----------------+ + + When IEEE 802 48bit MAC addresses are available (on an interface or a + node), an implementation may use them to create interface identifiers + due to their availability and uniqueness properties. + +Links with Other Kinds of Identifiers + + There are a number of types of links that have link-layer interface + identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs. Examples + include LocalTalk and Arcnet. The method to create an Modified EUI- + 64 format identifier is to take the link identifier (e.g., the + LocalTalk 8 bit node identifier) and zero fill it to the left. For + example, a LocalTalk 8 bit node identifier of hexadecimal value 0x4F + results in the following interface identifier: + + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |0000000000000000|0000000000000000|0000000000000000|0000000001001111| + +----------------+----------------+----------------+----------------+ + + Note that this results in the universal/local bit set to "0" to + indicate local scope. + +Links without Identifiers + + There are a number of links that do not have any type of built-in + identifier. The most common of these are serial links and configured + tunnels. Interface identifiers must be chosen that are unique within + a subnet-prefix. + + + + +Hinden & Deering Standards Track [Page 22] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + When no built-in identifier is available on a link the preferred + approach is to use a global interface identifier from another + interface or one which is assigned to the node itself. When using + this approach no other interface connecting the same node to the same + subnet-prefix may use the same identifier. + + If there is no global interface identifier available for use on the + link the implementation needs to create a local-scope interface + identifier. The only requirement is that it be unique within a + subnet prefix. There are many possible approaches to select a + subnet-prefix-unique interface identifier. These include: + + Manual Configuration + Node Serial Number + Other node-specific token + + The subnet-prefix-unique interface identifier should be generated in + a manner that it does not change after a reboot of a node or if + interfaces are added or deleted from the node. + + The selection of the appropriate algorithm is link and implementation + dependent. The details on forming interface identifiers are defined + in the appropriate "IPv6 over " specification. It is strongly + recommended that a collision detection algorithm be implemented as + part of any automatic algorithm. + + + + + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 23] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +APPENDIX B: Changes from RFC-2373 + + The following changes were made from RFC-2373 "IP Version 6 + Addressing Architecture": + + - Clarified text in section 2.2 to allow "::" to represent one or + more groups of 16 bits of zeros. + - Changed uniqueness requirement of Interface Identifiers from + unique on a link to unique within a subnet prefix. Also added a + recommendation that the same interface identifier not be assigned + to different machines on a link. + - Change site-local format to make the subnet ID field 54-bit long + and remove the 38-bit zero's field. + - Added description of multicast scop values and rules to handle the + reserved scop value 0. + - Revised sections 2.4 and 2.5.6 to simplify and clarify how + different address types are identified. This was done to insure + that implementations do not build in any knowledge about global + unicast format prefixes. Changes include: + o Removed Format Prefix (FP) terminology + o Revised list of address types to only include exceptions to + global unicast and a singe entry that identifies everything + else as Global Unicast. + o Removed list of defined prefix exceptions from section 2.5.6 + as it is now the main part of section 2.4. + - Clarified text relating to EUI-64 identifiers to distinguish + between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI- + 64 identifiers. + - Combined the sections on the Global Unicast Addresses and NSAP + Addresses into a single section on Global Unicast Addresses, + generalized the Global Unicast format, and cited [AGGR] and [NSAP] + as examples. + - Reordered sections 2.5.4 and 2.5.5. + - Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses + because this is being redefined elsewhere. + - Added an IANA considerations section that updates the IANA IPv6 + address allocations and documents the NSAP and AGGR allocations. + - Added clarification that the "IPv4-compatible IPv6 address" must + use global IPv4 unicast addresses. + - Divided references in to normative and non-normative sections. + - Added reference to [PRIV] in section 2.5.1 + - Added clarification that routers must not forward multicast + packets outside of the scope indicated in the multicast address. + - Added clarification that routers must not forward packets with + source address of the unspecified address. + - Added clarification that routers must drop packets received on an + interface with destination address of loopback. + - Clarified the definition of IPv4-mapped addresses. + + + +Hinden & Deering Standards Track [Page 24] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + - Removed the ABNF Description of Text Representations Appendix. + - Removed the address block reserved for IPX addresses. + - Multicast scope changes: + o Changed name of scope value 1 from "node-local" to + "interface-local" + o Defined scope value 4 as "admin-local" + - Corrected reference to RFC1933 and updated references. + - Many small changes to clarify and make the text more consistent. + +Authors' Addresses + + Robert M. Hinden + Nokia + 313 Fairchild Drive + Mountain View, CA 94043 + USA + + Phone: +1 650 625-2004 + EMail: hinden@iprg.nokia.com + + + Stephen E. Deering + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + USA + + Phone: +1 408 527-8213 + EMail: deering@cisco.com + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 25] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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. + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 26] + + + diff --git a/doc/rfc/rfc3596.txt b/doc/rfc/rfc3596.txt new file mode 100644 index 0000000000..5e0be2ac1c --- /dev/null +++ b/doc/rfc/rfc3596.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group S. Thomson +Request for Comments: 3596 Cisco +Obsoletes: 3152, 1886 C. Huitema +Category: Standards Track Microsoft + V. Ksinant + 6WIND + M. Souissi + AFNIC + October 2003 + + + DNS Extensions to Support IP Version 6 + +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 (2003). All Rights Reserved. + +Abstract + + This document defines the changes that need to be made to the Domain + Name System (DNS) to support hosts running IP version 6 (IPv6). The + changes include a resource record type to store an IPv6 address, a + domain to support lookups based on an IPv6 address, and updated + definitions of existing query types that return Internet addresses as + part of additional section processing. The extensions are designed + to be compatible with existing applications and, in particular, DNS + implementations themselves. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. New resource record definition and domain. . . . . . . . . . . 2 + 2.1. AAAA record type . . . . . . . . . . . . . . . . . . . . 3 + 2.2. AAAA data format . . . . . . . . . . . . . . . . . . . . 3 + 2.3. AAAA query . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.4. Textual format of AAAA records . . . . . . . . . . . . . 3 + 2.5. IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . . 3 + 3. Modifications to existing query types. . . . . . . . . . . . . 4 + 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 4 + 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 4 + + + +Thomson, et al. Standards Track [Page 1] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + + 6. Intellectual Property Statement. . . . . . . . . . . . . . . . 4 + Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 5 + Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . . 6 + Normative References . . . . . . . . . . . . . . . . . . . . . . . 6 + Informative References . . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8 + +1. Introduction + + Current support for the storage of Internet addresses in the Domain + Name System (DNS) [1,2] cannot easily be extended to support IPv6 + addresses [3] since applications assume that address queries return + 32-bit IPv4 addresses only. + + To support the storage of IPv6 addresses in the DNS, this document + defines the following extensions: + + o A resource record type is defined to map a domain name to an + IPv6 address. + + o A domain is defined to support lookups based on address. + + o Existing queries that perform additional section processing to + locate IPv4 addresses are redefined to perform additional + section processing on both IPv4 and IPv6 addresses. + + The changes are designed to be compatible with existing software. + The existing support for IPv4 addresses is retained. Transition + issues related to the co-existence of both IPv4 and IPv6 addresses in + the DNS are discussed in [4]. + + The IP protocol version used for querying resource records is + independent of the protocol version of the resource records; e.g., + IPv4 transport can be used to query IPv6 records and vice versa. + + This document combines RFC 1886 [5] and changes to RFC 1886 made by + RFC 3152 [6], obsoleting both. Changes mainly consist in replacing + the IP6.INT domain by IP6.ARPA as defined in RFC 3152. + +2. New resource record definition and domain + + A record type is defined to store a host's IPv6 address. A host that + has more than one IPv6 address must have more than one such record. + + + + + + + +Thomson, et al. Standards Track [Page 2] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +2.1 AAAA record type + + The AAAA resource record type is a record specific to the Internet + class that stores a single IPv6 address. + + The IANA assigned value of the type is 28 (decimal). + +2.2 AAAA data format + + A 128 bit IPv6 address is encoded in the data portion of an AAAA + resource record in network byte order (high-order byte first). + +2.3 AAAA query + + An AAAA query for a specified domain name in the Internet class + returns all associated AAAA resource records in the answer section of + a response. + + A type AAAA query does not trigger additional section processing. + +2.4 Textual format of AAAA records + + The textual representation of the data portion of the AAAA resource + record used in a master database file is the textual representation + of an IPv6 address as defined in [3]. + +2.5 IP6.ARPA Domain + + A special domain is defined to look up a record given an IPv6 + address. The intent of this domain is to provide a way of mapping an + IPv6 address to a host name, although it may be used for other + purposes as well. The domain is rooted at IP6.ARPA. + + An IPv6 address is represented as a name in the IP6.ARPA domain by a + sequence of nibbles separated by dots with the suffix ".IP6.ARPA". + 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, the reverse lookup domain name corresponding to the + address + + 4321:0:1:2:3:4:567:89ab + + would be + + b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. + ARPA. + + + + +Thomson, et al. Standards Track [Page 3] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +3. Modifications to existing query types + + All existing query types that perform type A additional section + processing, i.e., name server (NS), location of services (SRV) and + mail exchange (MX) query types, must be redefined to perform both + type A and type AAAA additional section processing. These + definitions mean that a name server must add any relevant IPv4 + addresses and any relevant IPv6 addresses available locally to the + additional section of a response when processing any one of the above + queries. + +4. Security Considerations + + Any information obtained from the DNS must be regarded as unsafe + unless techniques specified in [7] or [8] are used. The definitions + of the AAAA record type and of the IP6.ARPA domain do not change the + model for use of these techniques. + + So, this specification is not believed to cause any new security + problems, nor to solve any existing ones. + +5. IANA Considerations + + There are no IANA assignments to be performed. + +6. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + +Thomson, et al. Standards Track [Page 4] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Acknowledgments + + Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien + Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin + (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic + Roudaut (IRISA) and G6 group for their help during the RFC 1886 + Interop tests sessions. + + Many thanks to Alain Durand and Olafur Gudmundsson for their support. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 5] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Appendix A: Changes from RFC 1886 + + The following changes were made from RFC 1886 "DNS Extensions to + support IP version 6": + + - Replaced the "IP6.INT" domain by "IP6.ARPA". + - Mentioned SRV query types in section 3 "MODIFICATIONS TO + EXISTING QUERY TYPES" + - Added security considerations. + - Updated references : + * From RFC 1884 to RFC 3513 (IP Version 6 Addressing + Architecture). + * From "work in progress" to RFC 2893 (Transition Mechanisms for + IPv6 Hosts and Routers). + * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845. + - Updated document abstract + - Added table of contents + - Added full copyright statement + - Added IANA considerations section + - Added Intellectual Property Statement + +Normative References + + [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + +Informative References + + [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 + Hosts and Routers", RFC 2893, August 2000. + + [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP + version 6", RFC 1886, December 1995. + + [6] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August + 2001. + + [7] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999 + + + + + + +Thomson, et al. Standards Track [Page 6] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + + [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + +Authors' Addresses + + Susan Thomson + Cisco Systems + 499 Thornall Street, 8th floor + Edison, NJ 08837 + + Phone: +1 732-635-3086 + EMail: sethomso@cisco.com + + + Christian Huitema + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052-6399 + + EMail: huitema@microsoft.com + + + Vladimir Ksinant + 6WIND S.A. + Immeuble Central Gare - Bat.C + 1, place Charles de Gaulle + 78180, Montigny-Le-Bretonneux - France + + Phone: +33 1 39 30 92 36 + EMail: vladimir.ksinant@6wind.com + + + Mohsen Souissi + AFNIC + Immeuble International + 2, rue Stephenson, + 78181, Saint-Quentin en Yvelines Cedex - France + + Phone: +33 1 39 30 83 40 + EMail: Mohsen.Souissi@nic.fr + + + + + + + + + + +Thomson, et al. Standards Track [Page 7] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 assignees. + + 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. + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 8] +