rfc3513.txt

bind 9.3结合mysql数据库


RFC 3513              IPv6 Addressing Architecture            April 2003


            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 Internet Assigned Number
            Authority (IANA).

            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  interface-local scope
            2  link-local scope
            3  reserved
            4  admin-local scope
            5  site-local scope
            6  (unassigned)
            7  (unassigned)
            8  organization-local scope
            9  (unassigned)
            A  (unassigned)
            B  (unassigned)
            C  (unassigned)
            D  (unassigned)
            E  global scope
            F  reserved

            interface-local scope spans only a single interface on a
            node, and is useful only for loopback transmission of
            multicast.

            link-local and site-local multicast scopes span the same
            topological regions as the corresponding unicast scopes.

            admin-local scope is the smallest scope that must be
            administratively configured, i.e., not automatically derived
            from physical connectivity or other, non- multicast-related
            configuration.

            organization-local scope is intended to span multiple sites
            belonging to a single organization.

            scopes labeled "(unassigned)" are available for
            administrators to define additional multicast regions.




Hinden & Deering            Standards Track                    [Page 14]

RFC 3513              IPv6 Addressing Architecture            April 2003


         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 interface
      (i.e., 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 in 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.

   Routers must not forward any multicast packets beyond of the scope
   indicated by the scop field in the destination multicast address.

   Nodes must not originate a packet to a multicast address whose scop
   field contains the reserved value 0; if such a packet is received, it
   must be silently dropped.  Nodes should not originate a packet to a
   multicast address whose scop field contains the reserved value F; if
   such a packet is sent or received, it must be treated the same as
   packets destined to a global (scop E) multicast address.

2.7.1 Pre-Defined Multicast Addresses

   The following well-known multicast addresses are pre-defined.  The
   group ID's defined in this section are defined for explicit scope
   values.

   Use of these group IDs for any other scope values, with the T flag
   equal to 0, is not allowed.



Hinden & Deering            Standards Track                    [Page 15]

RFC 3513              IPv6 Addressing Architecture            April 2003


      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
                                      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 (interface-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 (interface-local), 2 (link-local), or 5 (site-local).

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

   Solicited-node multicast address are computed as a function of a
   node's unicast and anycast addresses.  A solicited-node multicast
   address is formed by taking the low-order 24 bits of an 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




Hinden & Deering            Standards Track                    [Page 16]

RFC 3513              IPv6 Addressing Architecture            April 2003


   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 (on the appropriate interface)
   the associated Solicited-Node multicast addresses for every unicast
   and anycast address it is assigned.

2.8 A Node's Required Addresses

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

      o  Its required Link-Local Address for each interface.
      o  Any additional Unicast and Anycast Addresses that have been
         configured for the node's interfaces (manually or
         automatically).
      o  The loopback address.
      o  The All-Nodes Multicast Addresses defined in section 2.7.1.
      o  The Solicited-Node Multicast Address for each of its unicast
         and anycast addresses.
      o  Multicast Addresses of all other groups to which the node
         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 all interfaces for
         which it is configured to act as a router.
      o  All other Anycast Addresses with which the router has been
         configured.
      o  The All-Routers Multicast Addresses defined in section 2.7.1.

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 17]

RFC 3513              IPv6 Addressing Architecture            April 2003


4. IANA Considerations

   The table and notes at http://www.isi.edu/in-
   notes/iana/assignments/ipv6-address-space.txt should be replaced with
   the following:

   INTERNET PROTOCOL VERSION 6 ADDRESS SPACE

   The initial assignment of IPv6 address space is as follows:

   Allocation                            Prefix         Fraction of
                                         (binary)       Address Space
   -----------------------------------   --------       -------------
   Unassigned (see Note 1 below)         0000 0000      1/256
   Unassigned                            0000 0001      1/256
   Reserved for NSAP Allocation          0000 001       1/128 [RFC1888]
   Unassigned                            0000 01        1/64
   Unassigned                            0000 1         1/32
   Unassigned                            0001           1/16
   Global Unicast                        001            1/8   [RFC2374]
   Unassigned                            010            1/8
   Unassigned                            011            1/8
   Unassigned                            100            1/8
   Unassigned                            101            1/8
   Unassigned                            110            1/8
   Unassigned                            1110           1/16
   Unassigned                            1111 0         1/32
   Unassigned                            1111 10        1/64
   Unassigned                            1111 110       1/128
   Unassigned                            1111 1110 0    1/512
   Link-Local Unicast Addresses          1111 1110 10   1/1024
   Site-Local Unicast Addresses          1111 1110 11   1/1024
   Multicast Addresses                   1111 1111      1/256

   Notes:

   1. The "unspecified address", the "loopback address", and the IPv6
      Addresses with Embedded IPv4 Addresses are assigned out of the
      0000 0000 binary prefix space.

   2. For now, IANA should limit its allocation of IPv6 unicast address
      space to the range of addresses that start with binary value 001.
      The rest of the global unicast address space (approximately 85% of
      the IPv6 address space) is reserved for future definition and use,
      and is not to be assigned by IANA at this time.






Hinden & Deering            Standards Track                    [Page 18]

RFC 3513              IPv6 Addressing Architecture            April 2003


5.  References

5.1  Normative References

   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", BCP 9 , RFC 2026, October 1996.

5.2  Informative References

   [ANYCST]  Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
             Service", RFC 1546, November 1993.

   [AUTH]    Kent, S. and R. Atkinson, "IP Authentication Header", RFC
             2402, November 1998.

   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable
             Global Unicast Address Format", RFC 2374, July 1998.

   [CIDR]    Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
             Inter-Domain Routing (CIDR): An Address Assignment and
             Aggregation Strategy", RFC 1519, September 1993.

   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
             Networks", RFC 2464, December 1998.

   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
             Registration Authority",
             http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
             March 1997.

   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
             Networks", RFC 2467, December 1998.

   [MASGN]   Hinden, R. and S. Deering, "IPv6 Multicast Address
             Assignments", RFC 2375, July 1998.

   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.
             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.

   [PRIV]    Narten, T. and R. Draves, "Privacy Extensions for Stateless
             Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [TOKEN]   Crawford, M., Narten, T. and S. Thomas, "Transmission of
             IPv6 Packets over Token Ring Networks", RFC 2470, December
             1998.



Hinden & Deering            Standards Track                    [Page 19]

RFC 3513              IPv6 Addressing Architecture            April 2003


   [TRAN]    Gilligan, R. and E. Nordmark, "Transition Mechanisms for
             IPv6 Hosts and Routers", RFC 2893, August 2000.