rfc2450.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

    TLA ID = 0x0001 = Top-Level Aggregation Identifier

       This is the TLA ID assigned by the IANA for Sub-TLA allocation.

    Sub-TLA ID = Sub-TLA Aggregation Identifier

       The Sub-TLA ID field is used by the registries for initial
       allocations to organizations meeting the requirements in Section
       5.2 of this document.  The IANA will assign small blocks (e.g.,
       few hundred) of Sub-TLA ID's to registries.  The registries will
       assign the Sub-TLA ID's to organizations meeting the requirements
       specified in Section 5.2.  When the registries have assigned all
       of their Sub-TLA ID's they can request that the IANA give them
       another block.  The blocks do not have to be contiguous.  The

       IANA may also assign Sub-TLA ID's to organizations directly.
       This includes the temporary TLA assignment for testing and
       experimental usage for activities such as the 6bone or new
       approaches like exchanges.







Hinden                       Informational                      [Page 6]

RFC 2450         Proposed TLA and NLA Assignment Rules     December 1998


    NLA ID = Next-Level Aggregation Identifier

       Next-Level Aggregation ID's are used by organizations assigned a
       TLA ID to create an addressing hierarchy and to identify sites.
       The organization can assign the top part of the NLA ID in a
       manner to create an addressing hierarchy appropriate to its
       network.  See Section 6.0 for more detail.

   Sub-TLA allocations are interim until the organization receiving the
   Sub-TLA can show evidence of IPv6 Internet transit service.  If
   transit service can not be demonstrated by three months from the date
   of allocation the Sub-TLA allocation will be revoked.

   As part of assigning a TLA ID to an organization, the IANA or
   Registries may initially only assign a fraction of the NLA ID space
   for a particular TLA ID to the organization receiving the TLA ID
   assignment.  When the organization has assigned more than 90% of the
   NLA ID space it may request additional NLA ID space in its TLA ID.

5.2 Proposed Assignment Requirements

   The proposed assignment requirements are intended as input from the
   IPng working group to the IANA and Registries.  It is not intended
   for any official IETF status.

   Registries enforce the following requirements for organizations
   assigned Sub-TLA and TLA ID's:

   1) Must have a plan to offer native IPv6 service within 3 months from
      assignment.  The plan must include NLA ID allocation and
      registration procedures.  NLA ID allocation and registration may
      be subcontracted to other organizations such as a registry.

      Native IPv6 service is defined as providing IPv6 service as
      defined in the appropriate "IPv6 over <link>" specification such
      as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.,
      for the link at the boundary of the organization.  This should
      include running Neighbor Discovery (as appropriate) and exchanging
      IPv6 routing information.  The method the organization uses to
      carry IPv6 traffic across its network is independent of this
      definition and is a local issue for the organization.

   2) Must have a verifiable track record of providing Internet transit
      to other organizations.  Sub-TLA and/or TLA ID's must not be
      assigned to organizations that are only providing leaf service
      even if multihomed.





Hinden                       Informational                      [Page 7]

RFC 2450         Proposed TLA and NLA Assignment Rules     December 1998


      Verification of an organization's track record in providing
      Internet transit service must be verified by techniques such as
      traceroute, BGP advertisements, etc.

   3) Payment of a registration fee to the Internet Assigned Numbers
      Authority (IANA).  Registries may also charge some fee for
      services rendered, generally in relation to the cost of providing
      those services.  All payment of registration and service fees must
      be made prior to the actual Sub-TLA ID and/or TLA ID assignment.

   4) Must provide registry services for the NLA ID address space it is
      responsible for under its Sub-TLA ID and/or TLA ID.  This must
      include both sites and next level providers.  The database of NLA
      assignments must be public and made available to the registries.

   5) Periodically (interval set by registry) provide to registry
      utilization statistics of the Sub-TLA ID and/or TLA ID it has
      custody of.  The organization must also show evidence of carrying
      TLA routing and transit traffic.  This can be in the form of
      traffic statistics, traceroutes, routing table dumps, or similar
      means.

   6) Organizations requesting another Sub-TLA and/or TLA ID must show
      evidence to the registries that they have assigned more than 90%
      of the NLA ID space in their previous allocations.

   Organizations which are given custody of a Sub-TLA ID and/or TLA ID,
   and fail to continue to meet all the above requirements may have the
   Sub-TLA ID and/or TLA ID custody revoked.

6.0 Proposed Rules Assignment of Next-Level Aggregation ID's

   Next-Level Aggregation ID's are used by organizations assigned a
   Sub-TLA ID and/or TLA ID to create an addressing hierarchy and to
   identify sites.  The organization can assign the top part of the NLA
   ID in a manner to create an addressing hierarchy appropriate to its
   network.

   Registries may initially only assign a fraction of the NLA ID space
   for a particular Sub-TLA ID and/or TLA ID to the organization
   receiving the Sub-TLA ID and/or TLA ID assignment.  When the
   organization has assigned more than 90% of the NLA ID space it may
   request additional NLA ID space in its Sub-TLA ID and/or TLA ID.

   Organizations assigned Sub-TLA ID and/or TLA ID's are required to
   assume (directly or indirectly) registry duties for the NLA ID's they
   assign.  Each organization assigned a NLA ID is required to assume
   registry duties for the next level NLA ID's it assigns and follow



Hinden                       Informational                      [Page 8]

RFC 2450         Proposed TLA and NLA Assignment Rules     December 1998


   Registry guidelines.  This responsibility includes passing this
   information back to the registry that assigned the TLA and/or
   Sub-TLA.  The TLA ID and/or Sub-TLA ID holder collects this
   information from the next level, the next level holder collects this
   information from the level below, etc.

   The design of the bit layout of the NLA ID space for a specific
   Sub-TLA ID and/or TLA ID is left to the organization responsible for
   that Sub-TLA ID and/or TLA ID.  Likewise the design of the bit layout
   of the next level NLA ID is the responsibility of the organization
   assigned the previous level NLA ID.  It is recommended that
   organizations assigning NLA address space use "slow start" allocation
   procedures as is currently done with IPv4 CIDR blocks [CIDR].

   The design of an NLA ID allocation plan is a tradeoff between routing
   aggregation efficiency and flexibility.  Creating hierarchies allows
   for greater amount of aggregation and results in smaller routing
   tables.  Flat NLA ID assignment provides for easier allocation and
   attachment flexibility, but results in larger routing tables.

7.0 Acknowledgments

   The author would like to express his thanks to Thomas Narten, Steve
   Deering, Bob Fink, Matt Crawford, Rebecca Nitzan, Allison Mankin, Jim
   Bound, Christian Huitema, Scott Bradner, Brian Carpenter, John
   Stewart, Eric Hoffman, Jon Postel, Daniel Karrenberg, Kim Hubbard,
   Mirjam Kuehne, Paula Caslav, David Conrad, and David Kessens for
   their review and constructive comments.

8.0 Security Considerations

   IPv6 addressing documents do not have any direct impact on Internet
   infrastructure security.  Authentication of IPv6 packets is defined
   in [AUTH].  Authentication of the ownership of prefixes to avoid
   "prefix stealing" is a related security issue but is beyond the scope
   of this document.

9.0 References

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

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

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




Hinden                       Informational                      [Page 9]

RFC 2450         Proposed TLA and NLA Assignment Rules     December 1998


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

   [CIDR]    Fuller, V., Li, T., Varadhan, K. and J. Yu, "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.

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

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

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

10.0 Author's Address

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

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






















Hinden                       Informational                     [Page 10]

RFC 2450         Proposed TLA and NLA Assignment Rules     December 1998


11.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                       Informational                     [Page 11]