rfc2874.txt

RFC 的详细文档！

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,