rfc2874.txt

bind 9.3结合mysql数据库

   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