rfc3513.txt

bind 9.3结合mysql数据库

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


APPENDIX A: Creating Modified EUI-64 format Interface Identifiers

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

Links or Nodes with IEEE EUI-64 Identifiers

   The only change needed to transform an IEEE EUI-64 identifier to an
   interface identifier is to invert the "u" (universal/local) bit.  For
   example, a globally unique IEEE 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 IEEE 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 IEEE MAC with global scope:












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


   |0              1|1              3|3              4|
   |0              5|6              1|2              7|
   +----------------+----------------+----------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|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 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 may use them to create interface identifiers
   due to their availability and uniqueness properties.

Links with Other Kinds of Identifiers

   There are a number of types of links that have link-layer interface
   identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs.  Examples
   include LocalTalk and Arcnet.  The method to create an Modified EUI-
   64 format 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:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
   +----------------+----------------+----------------+----------------+

   Note that this results in the universal/local bit set to "0" to
   indicate local scope.

Links without Identifiers

   There are a number of links that do not have any type of built-in
   identifier.  The most common of these are serial links and configured
   tunnels.  Interface identifiers must be chosen that are unique within
   a subnet-prefix.




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


   When no built-in identifier is available on a link the preferred
   approach is to use a global interface identifier from another
   interface or one which is assigned to the node itself.  When using
   this approach no other interface connecting the same node to the same
   subnet-prefix may use the same identifier.

   If there is no global interface identifier available for use on the
   link the implementation needs to create a local-scope interface
   identifier.  The only requirement is that it be unique within a
   subnet prefix.  There are many possible approaches to select a
   subnet-prefix-unique interface identifier.  These include:

      Manual Configuration
      Node Serial Number
      Other node-specific token

   The subnet-prefix-unique interface identifier should be generated in
   a manner that it does not change after a reboot of a node or if
   interfaces are added or deleted from the node.

   The selection of the appropriate algorithm is link and implementation
   dependent.  The details on forming interface identifiers are defined
   in the appropriate "IPv6 over <link>" specification.  It is strongly
   recommended that a collision detection algorithm be implemented as
   part of any automatic algorithm.


























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


APPENDIX B: Changes from RFC-2373

   The following changes were made from RFC-2373 "IP Version 6
   Addressing Architecture":

   -  Clarified text in section 2.2 to allow "::" to represent one or
      more groups of 16 bits of zeros.
   -  Changed uniqueness requirement of Interface Identifiers from
      unique on a link to unique within a subnet prefix.  Also added a
      recommendation that the same interface identifier not be assigned
      to different machines on a link.
   -  Change site-local format to make the subnet ID field 54-bit long
      and remove the 38-bit zero's field.
   -  Added description of multicast scop values and rules to handle the
      reserved scop value 0.
   -  Revised sections 2.4 and 2.5.6 to simplify and clarify how
      different address types  are identified.  This was done to insure
      that implementations do not build in any knowledge about global
      unicast format prefixes.  Changes include:
         o  Removed Format Prefix (FP) terminology
         o  Revised list of address types to only include exceptions to
            global unicast and a singe entry that identifies everything
            else as Global Unicast.
         o  Removed list of defined prefix exceptions from section 2.5.6
            as it is now the main part of section 2.4.
   -  Clarified text relating to EUI-64 identifiers to distinguish
      between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI-
      64 identifiers.
   -  Combined the sections on the Global Unicast Addresses and NSAP
      Addresses into a single section on Global Unicast Addresses,
      generalized the Global Unicast format, and cited [AGGR] and [NSAP]
      as examples.
   -  Reordered sections 2.5.4 and 2.5.5.
   -  Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses
      because this is being redefined elsewhere.
   -  Added an IANA considerations section that updates the IANA IPv6
      address allocations and documents the NSAP and AGGR allocations.
   -  Added clarification that the "IPv4-compatible IPv6 address" must
      use global IPv4 unicast addresses.
   -  Divided references in to normative and non-normative sections.
   -  Added reference to [PRIV] in section 2.5.1
   -  Added clarification that routers must not forward multicast
      packets outside of the scope indicated in the multicast address.
   -  Added clarification that routers must not forward packets with
       source address of the unspecified address.
   -  Added clarification that routers must drop packets received on an
      interface with destination address of loopback.
   -  Clarified the definition of IPv4-mapped addresses.



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


   -  Removed the ABNF Description of Text Representations Appendix.
   -  Removed the address block reserved for IPX addresses.
   -  Multicast scope changes:
         o  Changed name of scope value 1 from "node-local" to
            "interface-local"
         o  Defined scope value 4 as "admin-local"
   -  Corrected reference to RFC1933 and updated references.
   -  Many small changes to clarify and make the text more consistent.

Authors' Addresses

   Robert M. Hinden
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

   Phone: [phone]
   EMail: [e-mail]


   Stephen E. Deering
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   USA

   Phone: [phone]
   EMail: [e-mail]






















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


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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.



















Hinden & Deering            Standards Track                    [Page 26]