doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

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