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