rfc2374.txt

RFC 的详细文档！


RFC 2374           IPv6 Global Unicast Address Format          July 1998


   |  n  |   16-n     |              64 bits                |
   +-----+------------+-------------------------------------+
   |SLA1 |   Subnet   |            Interface ID             |
   +-----+------------+-------------------------------------+

         | m  |16-n-m |              64 bits                |
         +----+-------+-------------------------------------+
         |SLA2|Subnet |            Interface ID             |
         +----+-------+-------------------------------------+

   The approach chosen for structuring an SLA ID field is the
   responsibility of the individual organization.

   The number of subnets supported in this address format should be
   sufficient for all but the largest of organizations.  Organizations
   which need additional subnets can arrange with the organization they
   are obtaining Internet service from to obtain additional site
   identifiers and use this to create additional subnets.

3.6 Interface ID

   Interface identifiers are used to identify interfaces on a link.
   They are required to be unique on that link.  They may also be unique
   over a broader scope.  In many cases an interfaces identifier will be
   the same or be based on the interface's link-layer address.
   Interface IDs used in the aggregatable global unicast address format
   are required to be 64 bits long and to be constructed in IEEE EUI-64
   format [EUI-64].  These identifiers may have global scope when a
   global token (e.g., IEEE 48bit MAC) is available or may have local
   scope where a global token is not available (e.g., serial links,
   tunnel end-points, etc.).  The "u" bit (universal/local bit in IEEE
   EUI-64 terminology) in the EUI-64 identifier must be set correctly,
   as defined in [ARCH], to indicate global or local scope.

   The procedures for creating EUI-64 based Interface Identifiers is
   defined in [ARCH].  The details on forming interface identifiers is
   defined in the appropriate "IPv6 over <link>" specification such as
   "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.

4.0 Technical Motivation

   The design choices for the size of the fields in the aggregatable
   address format were based on the need to meet a number of technical
   requirements.  These are described in the following paragraphs.

   The size of the Top-Level Aggregation Identifier is 13 bits.  This
   allows for 8,192 TLA ID's.  This size was chosen to insure that the
   default-free routing table in top level routers in the Internet is



Hinden, et. al.             Standards Track                     [Page 7]

RFC 2374           IPv6 Global Unicast Address Format          July 1998


   kept within the limits, with a reasonable margin, of the current
   routing technology.  The margin is important because default-free
   routers will also carry a significant number of longer (i.e., more-
   specific) prefixes for optimizing paths internal to a TLA and between
   TLAs.

   The important issue is not only the size of the default-free routing
   table, but the complexity of the topology that determines the number
   of copies of the default-free routes that a router must examine while
   computing a forwarding table.  Current practice with IPv4 it is
   common to see a prefix announced fifteen times via different paths.

   The complexity of Internet topology is very likely to increase in the
   future.  It is important that IPv6 default-free routing support
   additional complexity as well as a considerably larger internet.

   It should be noted for comparison that at the time of this writing
   (spring, 1998) the IPv4 default-free routing table contains
   approximately 50,000 prefixes.  While this shows that it is possible
   to support more routes than 8,192 it is matter of debate if the
   number of prefixes supported today in IPv4 is already too high for
   current routing technology.  There are serious issues of route
   stability as well as cases of providers not supporting all top level
   prefixes.  The technical requirement was to pick a TLA ID size that
   was below, with a reasonable margin, what was being done with IPv4.

   The choice of 13 bits for the TLA field was an engineering
   compromise.  Fewer bits would have been too small by not supporting
   enough top level organizations.  More bits would have exceeded what
   can be reasonably accommodated, with a reasonable margin, with
   current routing technology in order to deal with the issues described
   in the previous paragraphs.

   If in the future, routing technology improves to support a larger
   number of top level routes in the default-free routing tables there
   are two choices on how to increase the number TLA identifiers.  The
   first is to expand the TLA ID field into the reserved field.  This
   would increase the number of TLA ID's to approximately 2 million.
   The second approach is to allocate another format prefix (FP) for use
   with this address format.  Either or a combination of these
   approaches allows the number of TLA ID's to increase significantly.

   The size of the Reserved field is 8 bits.  This size was chosen to
   allow significant growth of either the TLA ID and/or the NLA ID
   fields.

   The size of the Next-Level Aggregation Identifier field is 24 bits.




Hinden, et. al.             Standards Track                     [Page 8]

RFC 2374           IPv6 Global Unicast Address Format          July 1998


   This allows for approximately sixteen million NLA ID's if used in a
   flat manner.  Used hierarchically it allows for a complexity roughly
   equivalent to the IPv4 address space (assuming an average network
   size of 254 interfaces).  If in the future additional room for
   complexity is needed in the NLA ID, this may be accommodated by
   extending the NLA ID into the Reserved field.

   The size of the Site-Level Aggregation Identifier field is 16 bits.
   This supports 65,535 individual subnets per site.  The design goal
   for the size of this field was to be sufficient for all but the
   largest of organizations.  Organizations which need additional
   subnets can arrange with the organization they are obtaining Internet
   service from to obtain additional site identifiers and use this to
   create additional subnets.

   The Site-Level Aggregation Identifier field was given a fixed size in
   order to force the length of all prefixes identifying a particular
   site to be the same length (i.e., 48 bits).  This facilitates
   movement of sites in the topology (e.g., changing service providers
   and multi-homing to multiple service providers).

   The Interface ID Interface Identifier field is 64 bits.  This size
   was chosen to meet the requirement specified in [ARCH] to support
   EUI-64 based Interface Identifiers.

5.0 Acknowledgments

   The authors would like to express our thanks to Thomas Narten, Bob
   Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
   Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
   for their review and constructive comments.

6.0 References

   [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
             RFC 1881, December 1995.

   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
             RFC 2373, July 1998.

   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
             1995.

   [AUTO]    Thompson, S., and T. Narten., "IPv6 Stateless Address
             Autoconfiguration", RFC 1971, August 1996.

   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
             Networks", Work in Progress.



Hinden, et. al.             Standards Track                     [Page 9]

RFC 2374           IPv6 Global Unicast Address Format          July 1998


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

   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
             Networks", Work in Progress.

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

   [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
             and J. Postel, "Internet Registry IP Allocation
             Guidelines", BCP 12, RFC 1466, November 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

7.0 Security Considerations

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




























Hinden, et. al.             Standards Track                    [Page 10]

RFC 2374           IPv6 Global Unicast Address Format          July 1998


8.0 Authors' Addresses

   Robert M. Hinden
   Nokia
   232 Java Drive
   Sunnyvale, CA 94089
   USA

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


   Mike O'Dell
   UUNET Technologies, Inc.
   3060 Williams Drive
   Fairfax, VA 22030
   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, et. al.             Standards Track                    [Page 11]

RFC 2374           IPv6 Global Unicast Address Format          July 1998


9.0  Full Copyright Statement

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
























Hinden, et. al.             Standards Track                    [Page 12]