One document matched: draft-ietf-ipngwg-tla-assignment-01.txt

Differences from draft-ietf-ipngwg-tla-assignment-00.txt

INTERNET-DRAFT                              R. Hinden, Ipsilon Networks
November 7, 1997                                       M. O'Dell, UUNET




                      TLA and NLA Assignment Rules


               <draft-ietf-ipngwg-tla-assignment-01.txt>



Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the 1id-abstracts.txt listing contained in the internet-
   drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.

   This internet draft expires on May 7, 1998.


1.0 Introduction


   This document defines assignment rules for Top-Level Aggregation
   Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID)
   as defined in [AGGR].  These rules apply to registries allocating TLA
   ID's and to organizations receiving TLA ID's.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].






draft-ietf-ipngwg-tla-assignment-01.txt                         [Page 1]

INTERNET-DRAFT        TLA and NLA Assignment Rules         November 1997


2.0 IPv6 Aggregatable Global Unicast Address Format

   This document defines assignment rules for the TLA ID and NLA ID
   fields in the IPv6 Aggregatable Global Unicast Address Format.  This
   address format is designed to support both the current provider-based
   aggregation and a new type of exchange-based aggregation.  The
   combination will allow efficient routing aggregation for sites that
   connect directly to providers and for sites that connect to
   exchanges.  Sites will have the choice to connect to either type of
   aggregation entity.

   While this address format is designed to support exchange-based
   aggregation (in addition to current provider-based aggregation) it is
   not dependent on exchanges for it's overall route aggregation
   properties.  It will provide efficient route aggregation with only
   provider-based aggregation.

   The aggregatable global unicast address format as defined in [AGGR]
   is as follows:

      | 3 |  13 |    32     |   16   |          64 bits               |
      +---+-----+-----------+--------+--------------------------------+
      |FP | TLA | NLA ID    | SLA ID |         Interface ID           |
      |   | ID  |           |        |                                |
      +---+-----+-----------+--------+--------------------------------+

      <--Public Topology--->   Site
                            <-------->
                             Topology
                                      <------Interface Identifier----->

   Where

      FP           Format Prefix (001)
      TLA ID       Top-Level Aggregation Identifier
      NLA ID       Next-Level Aggregation Identifier
      SLA ID       Site-Level Aggregation Identifier
      INTERFACE ID Interface Identifier


3.0 Rules for Assignment of Top-Level Aggregation ID's

   TLA ID's are assigned to organizations providing public transit
   topology.  They are specifically not assigned to organizations only
   providing leaf or private transit topology.  TLA ID assignment does
   not imply ownership.  It does imply stewardship over valuable
   Internet resource.




draft-ietf-ipngwg-tla-assignment-01.txt                         [Page 2]

INTERNET-DRAFT        TLA and NLA Assignment Rules         November 1997


   The IAB and IESG have authorized the Internet Assigned Numbers
   Authority (IANA) as the appropriate entity to have the responsibility
   for the management of the IPv6 address space as defined in [ALLOC].

   The IANA will assign small blocks of TLA ID's to IPv6 registries.
   The registries will assign the TLA ID's to organizations meeting the
   requirements for TLA ID assignment.  When the registries have
   assigned all of their 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 TLA ID's to organizations directly.  This
   includes the temporary TLA assignment for testing and experimental
   usage for activities such as the 6bone.

   Registries are required to insure that organizations assigned TLA
   ID's meet the following requirements:

   1) Must have a plan to offer public native IPv6 service within 6
      months from assignment.  The plan must include NLA ID allocation
      and registration procedures.

      Native IPv6 service is defined as providing IPv6 service as
      defined in the appropriate IPv6 over <LINK> specification 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 it's network is independent of this definition
      and is a local issue for the organization.

   2) Must have a verifiable track record of providing public Internet
      transit service on fair, reasonable, and non-discriminatory terms,
      to other providers.  TLA ID's must not be assigned to
      organizations that are only providing leaf service even if
      multihomed.

      Verification of an organizations track record in providing public
      Internet transit service must include an independent third party
      public listing.  Examples include listing as a major national
      service provider by publications such as Boardwatch Magazine,
      listed as an established telecommunications provider in the
      Fortune Magazine "Fortune 500" list, etc.

   3) Payment of a one time registration fee of $5,000.00 (in US
      Dollars) to the Internet Assigned Numbers Authority (IANA).  This
      payment must be made prior to the actual TLA assignment.  Funds
      collected will be used to support the operations of the IANA and
      IPv6 registries.

   4) Must provide registry services on fair, reasonable, and non-



draft-ietf-ipngwg-tla-assignment-01.txt                         [Page 3]

INTERNET-DRAFT        TLA and NLA Assignment Rules         November 1997


      discriminatory terms, for the NLA ID address space it is
      responsible for under its TLA ID.  This must include both sites
      and next level providers.

   5) Must provide transit routing and forwarding to all assigned TLA
      ID's on fair, reasonable, and non-discriminatory terms.
      Organizations are not allowed to filter out any specific TLA ID's
      (except temporarily for diagnostic purposes or emergency repair
      purposed).

   6) Periodically (interval set by registry) provide to registry
      utilization statistics of the 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.

   The IANA will hold an annual auction for fifty (50) TLA ID's for
   organizations that plan to provide public Internet transit service on
   fair, reasonable, and non-discriminatory terms but do not have a
   verifiable track record as defined in 2).  All other requirements
   must be meet including prepayment of the registration fee (refundable
   if a TLA ID is not obtained at the auction).  All fees collected
   during the auction will be used to support the operations of the IANA
   and IPv6 registries.  The IANA will determine the procedures and
   manner that the auction is held including setting a minimum bid.

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


4.0 Rules Assignment of Next-Level Aggregation ID's

   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.

   Organizations assigned TLA ID's are required to assume 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.

   The design of the bit layout of the NLA ID space for a specific TLA
   ID is left to the organization responsible for that 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



draft-ietf-ipngwg-tla-assignment-01.txt                         [Page 4]

INTERNET-DRAFT        TLA and NLA Assignment Rules         November 1997


   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.


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, Eric Hoffman, and Jon
   Postel for their review and constructive comments.


6.0 Security Considerations

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


7.0 References

   [AGGR]    Hinden, R., Deering, S., O'Dell, M., "An Aggregatable
             Global Unicast Address Format", Internet Draft, <draft-
             ietf-ipngwg-unicast-aggr-02.txt>, July 1997.

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

   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
             Internet Draft, <draft-ietf-ipngwg-addr-arch-v2-04.txt>,
             November 1997.

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

   [CIDR]    Fuller, V., T. Li, K. Varadhan, J. Yu, "Supernetting: an
             Address Assignment and Aggregation Strategy", RFC1338.

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

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate



draft-ietf-ipngwg-tla-assignment-01.txt                         [Page 5]

INTERNET-DRAFT        TLA and NLA Assignment Rules         November 1997


             Requirement Levels", RFC2119, BCP14, March 1997.


8.0 Authors' Addresses

   Robert M. Hinden                     phone: 1 408 990-2004
   Ipsilon Networks, Inc.               email: hinden@ipsilon.com
   232 Java Drive
   Sunnyvale, CA 94089
   USA

   Mike O'Dell                          phone: 1 703 206-5890
   UUNET Technologies, Inc.             email: mo@uunet.uu.net
   3060 Williams Drive
   Fairfax, VA 22030
   USA



































draft-ietf-ipngwg-tla-assignment-01.txt                         [Page 6]