rfc2373.txt

bind 9.3结合mysql数据库


RFC 2373              IPv6 Addressing Architecture             July 1998


   The subnet-router anycast address is intended to be used for
   applications where a node needs to communicate with one of a set of
   routers on a remote subnet.  For example when a mobile host needs to
   communicate with one of the mobile agents on its "home" subnet.

2.7 Multicast Addresses

   An IPv6 multicast address is an identifier for a group of nodes.  A
   node may belong to any number of multicast groups.  Multicast
   addresses have the following format:

   |   8    |  4 |  4 |                  112 bits                   |
   +------ -+----+----+---------------------------------------------+
   |11111111|flgs|scop|                  group ID                   |
   +--------+----+----+---------------------------------------------+

      11111111 at the start of the address identifies the address as
      being a multicast address.

                                    +-+-+-+-+
      flgs is a set of 4 flags:     |0|0|0|T|
                                    +-+-+-+-+

         The high-order 3 flags are reserved, and must be initialized to
         0.

         T = 0 indicates a permanently-assigned ("well-known") multicast
         address, assigned by the global internet numbering authority.

         T = 1 indicates a non-permanently-assigned ("transient")
         multicast address.

      scop is a 4-bit multicast scope value used to limit the scope of
      the multicast group.  The values are:

         0  reserved
         1  node-local scope
         2  link-local scope
         3  (unassigned)
         4  (unassigned)
         5  site-local scope
         6  (unassigned)
         7  (unassigned)
         8  organization-local scope
         9  (unassigned)
         A  (unassigned)
         B  (unassigned)
         C  (unassigned)



Hinden & Deering            Standards Track                    [Page 14]

RFC 2373              IPv6 Addressing Architecture             July 1998


         D  (unassigned)
         E  global scope
         F  reserved

      group ID identifies the multicast group, either permanent or
      transient, within the given scope.

   The "meaning" of a permanently-assigned multicast address is
   independent of the scope value.  For example, if the "NTP servers
   group" is assigned a permanent multicast address with a group ID of
   101 (hex), then:

      FF01:0:0:0:0:0:0:101 means all NTP servers on the same node as the
      sender.

      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
      sender.

      FF05:0:0:0:0:0:0:101 means all NTP servers at the same site as the
      sender.

      FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.

   Non-permanently-assigned multicast addresses are meaningful only
   within a given scope.  For example, a group identified by the non-
   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
   site bears no relationship to a group using the same address at a
   different site, nor to a non-permanent group using the same group ID
   with different scope, nor to a permanent group with the same group
   ID.

   Multicast addresses must not be used as source addresses in IPv6
   packets or appear in any routing header.

2.7.1 Pre-Defined Multicast Addresses

   The following well-known multicast addresses are pre-defined:

      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
                                      FF01:0:0:0:0:0:0:0
                                      FF02:0:0:0:0:0:0:0
                                      FF03:0:0:0:0:0:0:0
                                      FF04:0:0:0:0:0:0:0
                                      FF05:0:0:0:0:0:0:0
                                      FF06:0:0:0:0:0:0:0
                                      FF07:0:0:0:0:0:0:0
                                      FF08:0:0:0:0:0:0:0
                                      FF09:0:0:0:0:0:0:0



Hinden & Deering            Standards Track                    [Page 15]

RFC 2373              IPv6 Addressing Architecture             July 1998


                                      FF0A:0:0:0:0:0:0:0
                                      FF0B:0:0:0:0:0:0:0
                                      FF0C:0:0:0:0:0:0:0
                                      FF0D:0:0:0:0:0:0:0
                                      FF0E:0:0:0:0:0:0:0
                                      FF0F:0:0:0:0:0:0:0

   The above multicast addresses are reserved and shall never be
   assigned to any multicast group.

      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
                              FF02:0:0:0:0:0:0:1

   The above multicast addresses identify the group of all IPv6 nodes,
   within scope 1 (node-local) or 2 (link-local).

      All Routers Addresses:   FF01:0:0:0:0:0:0:2
                               FF02:0:0:0:0:0:0:2
                               FF05:0:0:0:0:0:0:2

   The above multicast addresses identify the group of all IPv6 routers,
   within scope 1 (node-local), 2 (link-local), or 5 (site-local).

      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX

   The above multicast address is computed as a function of a node's
   unicast and anycast addresses.  The solicited-node multicast address
   is formed by taking the low-order 24 bits of the address (unicast or
   anycast) and appending those bits to the prefix
   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
   range

      FF02:0:0:0:0:1:FF00:0000

   to

      FF02:0:0:0:0:1:FFFF:FFFF

   For example, the solicited node multicast address corresponding to
   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
   addresses that differ only in the high-order bits, e.g. due to
   multiple high-order prefixes associated with different aggregations,
   will map to the same solicited-node address thereby reducing the
   number of multicast addresses a node must join.

   A node is required to compute and join the associated Solicited-Node
   multicast addresses for every unicast and anycast address it is
   assigned.



Hinden & Deering            Standards Track                    [Page 16]

RFC 2373              IPv6 Addressing Architecture             July 1998


2.7.2 Assignment of New IPv6 Multicast Addresses

   The current approach [ETHER] to map IPv6 multicast addresses into
   IEEE 802 MAC addresses takes the low order 32 bits of the IPv6
   multicast address and uses it to create a MAC address.  Note that
   Token Ring networks are handled differently.  This is defined in
   [TOKEN].  Group ID's less than or equal to 32 bits will generate
   unique MAC addresses.  Due to this new IPv6 multicast addresses
   should be assigned so that the group identifier is always in the low
   order 32 bits as shown in the following:

   |   8    |  4 |  4 |          80 bits          |     32 bits     |
   +------ -+----+----+---------------------------+-----------------+
   |11111111|flgs|scop|   reserved must be zero   |    group ID     |
   +--------+----+----+---------------------------+-----------------+

   While this limits the number of permanent IPv6 multicast groups to
   2^32 this is unlikely to be a limitation in the future.  If it
   becomes necessary to exceed this limit in the future multicast will
   still work but the processing will be sightly slower.

   Additional IPv6 multicast addresses are defined and registered by the
   IANA [MASGN].

2.8 A Node's Required Addresses

   A host is required to recognize the following addresses as
   identifying itself:

      o Its Link-Local Address for each interface
      o Assigned Unicast Addresses
      o Loopback Address
      o All-Nodes Multicast Addresses
      o Solicited-Node Multicast Address for each of its assigned
        unicast and anycast addresses
      o Multicast Addresses of all other groups to which the host
        belongs.

   A router is required to recognize all addresses that a host is
   required to recognize, plus the following addresses as identifying
   itself:

      o The Subnet-Router anycast addresses for the interfaces it is
        configured to act as a router on.
      o All other Anycast addresses with which the router has been
        configured.
      o All-Routers Multicast Addresses




Hinden & Deering            Standards Track                    [Page 17]

RFC 2373              IPv6 Addressing Architecture             July 1998


      o Multicast Addresses of all other groups to which the router
        belongs.

   The only address prefixes which should be predefined in an
   implementation are the:

      o Unspecified Address
      o Loopback Address
      o Multicast Prefix (FF)
      o Local-Use Prefixes (Link-Local and Site-Local)
      o Pre-Defined Multicast Addresses
      o IPv4-Compatible Prefixes

   Implementations should assume all other addresses are unicast unless
   specifically configured (e.g., anycast addresses).

3. Security Considerations

   IPv6 addressing documents do not have any direct impact on Internet
   infrastructure security.  Authentication of IPv6 packets is defined
   in [AUTH].






























Hinden & Deering            Standards Track                    [Page 18]

RFC 2373              IPv6 Addressing Architecture             July 1998


APPENDIX A : Creating EUI-64 based Interface Identifiers
--------------------------------------------------------

   Depending on the characteristics of a specific link or node there are
   a number of approaches for creating EUI-64 based interface
   identifiers.  This appendix describes some of these approaches.

Links or Nodes with EUI-64 Identifiers

   The only change needed to transform an EUI-64 identifier to an
   interface identifier is to invert the "u" (universal/local) bit.  For
   example, a globally unique EUI-64 identifier of the form:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   where "c" are the bits of the assigned company_id, "0" is the value
   of the universal/local bit to indicate global scope, "g" is
   individual/group bit, and "m" are the bits of the manufacturer-
   selected extension identifier.  The IPv6 interface identifier would
   be of the form:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   The only change is inverting the value of the universal/local bit.

Links or Nodes with IEEE 802 48 bit MAC's

   [EUI64] defines a method to create a EUI-64 identifier from an IEEE
   48bit MAC identifier.  This is to insert two octets, with hexadecimal
   values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the
   company_id and vendor supplied id).  For example the 48 bit MAC with
   global scope:

   |0              1|1              3|3              4|
   |0              5|6              1|2              7|
   +----------------+----------------+----------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+





Hinden & Deering            Standards Track                    [Page 19]

RFC 2373              IPv6 Addressing Architecture             July 1998


   where "c" are the bits of the assigned company_id, "0" is the value
   of the universal/local bit to indicate global scope, "g" is
   individual/group bit, and "m" are the bits of the manufacturer-
   selected extension identifier.  The interface identifier would be of
   the form:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

   When IEEE 802 48bit MAC addresses are available (on an interface or a
   node), an implementation should use them to create interface
   identifiers due to their availability and uniqueness properties.

Links with Non-Global Identifiers

   There are a number of types of links that, while multi-access, do not
   have globally unique link identifiers.  Examples include LocalTalk
   and Arcnet.  The method to create an EUI-64 formatted identifier is
   to take the link identifier (e.g., the LocalTalk 8 bit node
   identifier) and zero fill it to the left.  For example a LocalTalk 8
   bit node identifier of hexadecimal value 0x4F results in the
   following interface identifier: