home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipngwg-tla-assignment-00.txt < prev    next >
Text File  |  1997-07-16  |  10KB  |  279 lines
  1.  
  2.  
  3. INTERNET-DRAFT                              R. Hinden, Ipsilon Networks
  4. July 16, 1997                                          M. O'Dell, UUNET
  5.  
  6.  
  7.  
  8.  
  9.                       TLA and NLA Assignment Rules
  10.  
  11.  
  12.                <draft-ietf-ipngwg-tla-assignment-00.txt>
  13.  
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document is an Internet Draft.  Internet Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its Areas,
  20.    and its Working Groups.  Note that other groups may also distribute
  21.    working documents as Internet Drafts.
  22.  
  23.    Internet Drafts are draft documents valid for a maximum of six
  24.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  25.    other documents at any time.  It is not appropriate to use Internet
  26.    Drafts as reference material or to cite them other than as a
  27.    ``working draft'' or ``work in progress.''
  28.  
  29.    Please check the 1id-abstracts.txt listing contained in the internet-
  30.    drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  31.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  32.    current status of any Internet Draft.
  33.  
  34.    This internet draft expires on January 17, 1998.
  35.  
  36.  
  37. 1.0 Introduction
  38.  
  39.  
  40.    This document defines assignment rules for Top-Level Aggregation
  41.    Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID)
  42.    as defined in [AGGR].  These rules apply to registries allocating TLA
  43.    ID's and to organizations receiving TLA ID's.
  44.  
  45.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  46.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  47.    document are to be interpreted as described in [RFC 2119].
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. draft-ietf-ipngwg-tla-assignment-00.txt                         [Page 1]
  55.  
  56. INTERNET-DRAFT        TLA and NLA Assignment Rules             July 1997
  57.  
  58.  
  59. 2.0 IPv6 Aggregatable Global Unicast Address Format
  60.  
  61.    This document defines assignment rules for the TLA ID and NLA ID
  62.    fields in the IPv6 Aggregatable Global Unicast Address Format.  This
  63.    address format is designed to support both the current provider-based
  64.    aggregation and a new type of exchange-based aggregation.  The
  65.    combination will allow efficient routing aggregation for sites that
  66.    connect directly to providers and for sites that connect to
  67.    exchanges.  Sites will have the choice to connect to either type of
  68.    aggregation entity.
  69.  
  70.    While this address format is designed to support exchange-based
  71.    aggregation (in addition to current provider-based aggregation) it is
  72.    not dependent on exchanges for it's overall route aggregation
  73.    properties.  It will provide efficient route aggregation with only
  74.    provider-based aggregation.
  75.  
  76.    The aggregatable global unicast address format as defined in [AGGR]
  77.    is as follows:
  78.  
  79.       | 3 |  13 |    32     |   16   |          64 bits               |
  80.       +---+-----+-----------+--------+--------------------------------+
  81.       |FP | TLA | NLA ID    | SLA ID |         Interface ID           |
  82.       |   | ID  |           |        |                                |
  83.       +---+-----+-----------+--------+--------------------------------+
  84.  
  85.       <--Public Topology--->   Site
  86.                             <-------->
  87.                              Topology
  88.                                       <------Interface Identifier----->
  89.  
  90.    Where
  91.  
  92.       FP           Format Prefix (001)
  93.       TLA ID       Top-Level Aggregation Identifier
  94.       NLA ID       Next-Level Aggregation Identifier
  95.       SLA ID       Site-Level Aggregation Identifier
  96.       INTERFACE ID Interface Identifier
  97.  
  98.  
  99. 3.0 Rules for Assignment of Top-Level Aggregation ID's
  100.  
  101.    TLA ID's are assigned to organizations providing public transit
  102.    topology.  They are specifically not assigned to organizations only
  103.    providing leaf or private transit topology.  TLA ID assignment does
  104.    not imply ownership.  It does imply stewardship over valuable
  105.    Internet property.
  106.  
  107.  
  108.  
  109.  
  110. draft-ietf-ipngwg-tla-assignment-00.txt                         [Page 2]
  111.  
  112. INTERNET-DRAFT        TLA and NLA Assignment Rules             July 1997
  113.  
  114.  
  115.    The IAB and IESG have authorized the Internet Assigned Numbers
  116.    Authority (IANA) as the appropriate entity to have the responsibility
  117.    for the management of the IPv6 address space as defined in [ALLOC].
  118.  
  119.    The IANA will assign small blocks of TLA ID's to IPv6 registries.
  120.    The registries will assign the TLA ID's to organizations meeting the
  121.    requirements for TLA ID assignment.  When the registries have
  122.    assigned all of their TLA ID's they can request that the IANA give
  123.    them another block.  The blocks do not have to be contiguous.  The
  124.    IANA may also assign TLA ID's to organizations directly.
  125.  
  126.    Registries are required to insure that organizations assigned TLA
  127.    ID's meet the following requirements:
  128.  
  129.     - Must have a plan to offer public native IPv6 service within 6
  130.       months from assignment.  The plan must include plan for NLA ID
  131.       allocation.
  132.  
  133.     - Must have a plan or track record of providing public Internet
  134.       transit service on fair, reasonable, and non-discriminatory terms,
  135.       to other providers.  TLA ID's must not be assigned to
  136.       organizations that are only providing leaf service even if
  137.       multihomed.
  138.  
  139.     - Must provide registry services on fair, reasonable, and non-
  140.       discriminatory terms, for the NLA ID address space it is
  141.       responsible for under its TLA ID.  This must include both sites
  142.       and next level providers.
  143.  
  144.     - Must provide transit routing and forwarding to all assigned TLA
  145.       ID's on fair, reasonable, and non-discriminatory terms.
  146.       Organizations are not allowed to filter out any specific TLA ID's
  147.       (except temporarily for diagnostic purposes or emergency repair
  148.       purposed).
  149.  
  150.     - Periodically (interval set by registry) provide to registry
  151.       utilization statistics of the TLA ID it has custody of.  The
  152.       organization must also show evidence of carrying TLA routing and
  153.       transit traffic.  This can be in the form of traffic statistics,
  154.       traceroutes, routing table dumps, or similar means.
  155.  
  156.    Organizations which are given custody of a TLA ID and fail to
  157.    continue to meet these may have the TLA ID custody revoked.
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166. draft-ietf-ipngwg-tla-assignment-00.txt                         [Page 3]
  167.  
  168. INTERNET-DRAFT        TLA and NLA Assignment Rules             July 1997
  169.  
  170.  
  171. 4.0 Rules Assignment of Next-Level Aggregation ID's
  172.  
  173.    Next-Level Aggregation ID's are used by organization assigned a TLA
  174.    ID to create an addressing hierarchy and to identify sites.  The
  175.    organization can assign the top part of the NLA ID in a manner to
  176.    create an addressing hierarchy appropriate to its network.
  177.  
  178.    Organizations assigned TLA ID's are required to assume registry
  179.    duties for the NLA ID's they assign.  Each organization assigned a
  180.    NLA ID is required to assume registry duties for the next level NLA
  181.    ID's it assigns.
  182.  
  183.    The design of the bit layout of the NLA ID space for a specific TLA
  184.    ID is left to the organization responsible for that TLA ID.  Likewise
  185.    the design of the bit layout of the next level NLA ID is the
  186.    responsibility of the organization assigned the previous level NLA
  187.    ID.  It is recommended that organizations assigning NLA address space
  188.    use "slow start" allocation procedures as is currently done with IPv4
  189.    CIDR blocks [CIDR].
  190.  
  191.    The design of an NLA ID allocation plan is a tradeoff between routing
  192.    aggregation efficiency and flexibility.  Creating hierarchies allows
  193.    for greater amount of aggregation and results in smaller routing
  194.    tables.  Flat NLA ID assignment provides for easier allocation and
  195.    attachment flexibility, but results in larger routing tables.
  196.  
  197.  
  198. 5.0 Acknowledgments
  199.  
  200.    The authors would like to express our thanks to Thomas Narten, Bob
  201.    Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
  202.    Scott Bradner, Brian Carpenter, and John Stewart for their review and
  203.    constructive comments.
  204.  
  205.  
  206. 5.0 References
  207.  
  208.    [AGGR]    Hinden, R., Deering, S., O'Dell, M., "An Aggregatable
  209.              Global Unicast Address Format", Internet Draft, <draft-
  210.              ietf-ipngwg-unicast-aggr-02.txt>, July 1997.
  211.  
  212.    [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
  213.              RFC1881, December 1995.
  214.  
  215.    [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
  216.              Internet Draft, <draft-ietf-ipngwg-addr-arch-v2-02.txt>,
  217.              July 1997.
  218.  
  219.  
  220.  
  221.  
  222. draft-ietf-ipngwg-tla-assignment-00.txt                         [Page 4]
  223.  
  224. INTERNET-DRAFT        TLA and NLA Assignment Rules             July 1997
  225.  
  226.  
  227.    [AUTH]    Atkinson, R., "IP Authentication Header", RFC1826, August
  228.              1995.
  229.  
  230.    [CIDR]    Fuller, V., T. Li, K. Varadhan, J. Yu, "Supernetting: an
  231.              Address Assignment and Aggregation Strategy", RFC1338.
  232.  
  233.    [IPV6]    Deering, S., Hinden, R., Editors, "Internet Protocol,
  234.              Version 6 (IPv6) Specification", RFC1883, December 1995.
  235.  
  236.    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  237.              Requirement Levels", RFC2119, BCP14, March 1997.
  238.  
  239.  
  240. 6.0 Security Considerations
  241.  
  242.    IPv6 addressing documents do not have any direct impact on Internet
  243.    infrastructure security.  Authentication of IPv6 packets is defined
  244.    in [AUTH].
  245.  
  246.  
  247. 7.0 Authors' Addresses
  248.  
  249.    Robert M. Hinden                     phone: 1 408 990-2004
  250.    Ipsilon Networks, Inc.               email: hinden@ipsilon.com
  251.    232 Java Drive
  252.    Sunnyvale, CA 94089
  253.    USA
  254.  
  255.    Mike O'Dell                          phone: 1 703 206-5890
  256.    UUNET Technologies, Inc.             email: mo@uunet.uu.net
  257.    3060 Williams Drive
  258.    Fairfax, VA 22030
  259.    USA
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. draft-ietf-ipngwg-tla-assignment-00.txt                         [Page 5]
  279.