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-unicast-aggr-01.txt < prev    next >
Text File  |  1997-06-13  |  20KB  |  559 lines
  1.  
  2.  
  3. INTERNET-DRAFT                              R. Hinden, Ipsilon Networks
  4. June 12, 1997                                          M. O'Dell, UUNET
  5.                                                       S. Deering, Cisco
  6.  
  7.  
  8.  
  9.  
  10.            An IPv6 Aggregatable Global Unicast Address Format
  11.  
  12.  
  13.                 <draft-ietf-ipngwg-unicast-aggr-01.txt>
  14.  
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This document is an Internet Draft.  Internet Drafts are working
  20.    documents of the Internet Engineering Task Force (IETF), its Areas,
  21.    and its Working Groups.  Note that other groups may also distribute
  22.    working documents as Internet Drafts.
  23.  
  24.    Internet Drafts are draft documents valid for a maximum of six
  25.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  26.    other documents at any time.  It is not appropriate to use Internet
  27.    Drafts as reference material or to cite them other than as a
  28.    ``working draft'' or ``work in progress.''
  29.  
  30.    Please check the 1id-abstracts.txt listing contained in the internet-
  31.    drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  32.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  33.    current status of any Internet Draft.
  34.  
  35.    This internet draft expires on December 13, 1997.
  36.  
  37.  
  38. 1.0 Introduction
  39.  
  40.    This document defines an IPv6 aggregatable global unicast address
  41.    format for use in the Internet.  The address format defined in this
  42.    document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
  43.    Addressing Architecture" [ARCH].  It is designed to facilitate
  44.    scalable Internet routing.
  45.  
  46.    This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
  47.    Address Format".  RFC 2073 will become historic.
  48.  
  49.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  50.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  51.  
  52.  
  53.  
  54. draft-ietf-ipngwg-unicast-aggr-01.txt                           [Page 1]
  55.  
  56. INTERNET-DRAFT Aggregatable Global Unicast Address Format      June 1997
  57.  
  58.  
  59.    document are to be interpreted as described in [RFC 2119].
  60.  
  61.  
  62. 2.0 Overview of the IPv6 Address
  63.  
  64.    IPv6 addresses are 128-bit identifiers for interfaces and sets of
  65.    interfaces.  There are three types of addresses: Unicast, Anycast,
  66.    and Multicast.  This document defines a specific type of Unicast
  67.    address.
  68.  
  69.    In this document, fields in addresses are given specific names, for
  70.    example "subnet".  When this name is used with the term "ID" (for
  71.    "identifier") after the name (e.g., "subnet ID"), it refers to the
  72.    contents of the named field.  When it is used with the term "prefix"
  73.    (e.g.  "subnet prefix") it refers to all of the addressing bits to
  74.    the left of and including this field.
  75.  
  76.    IPv6 unicast addresses are designed assuming that the internet
  77.    routing system makes forwarding decisions based on a "longest prefix
  78.    match" algorithm on arbitrary bit boundaries and does not have any
  79.    knowledge of the internal structure of IPv6 addresses.  The structure
  80.    in IPv6 addresses is for assignment and allocation.  The only
  81.    exception to this is the distinction made between unicast and
  82.    multicast addresses.
  83.  
  84.    The specific type of an IPv6 address is indicated by the leading bits
  85.    in the address.  The variable-length field comprising these leading
  86.    bits is called the Format Prefix (FP).
  87.  
  88.    This document defines an address format for the 001 (binary) Format
  89.    Prefix for Aggregatable Global Unicast addresses. The same address
  90.    format could be used for other Format Prefixes, as long as these
  91.    Format Prefixes also identify IPv6 unicast addresses.  Only the "001"
  92.    Format Prefix is defined here.
  93.  
  94.  
  95. 3.0 IPv6 Aggregatable Global Unicast Address Format
  96.  
  97.    This document defines an address format for the IPv6 aggregatable
  98.    global unicast address assignment.  The authors believe that this
  99.    address format will be widely used for IPv6 nodes connected to the
  100.    Internet.  This address format is designed to support both the
  101.    current provider-based aggregation and a new type of exchange-based
  102.    aggregation.  The combination will allow efficient routing
  103.    aggregation for both sites that connect directly to providers and
  104.    sites that connect to exchanges.  Sites will have the choice to
  105.    connect to either type of aggregation entity.
  106.  
  107.  
  108.  
  109.  
  110. draft-ietf-ipngwg-unicast-aggr-01.txt                           [Page 2]
  111.  
  112. INTERNET-DRAFT Aggregatable Global Unicast Address Format      June 1997
  113.  
  114.  
  115.    Aggregatable addresses are organized into a three level hierarchy:
  116.  
  117.       - Public Topology
  118.       - Site Topology
  119.       - Interface Identifier
  120.  
  121.    Public topology is the collection of providers and exchanges who
  122.    provide public Internet transit services.  Site topology is local to
  123.    a specific site or organization which does not provide public transit
  124.    service to nodes outside of the site.  Interface identifiers identify
  125.    interfaces on links.
  126.  
  127.         ______________                  ______________
  128.     --+/              \+--------------+/              \+----------
  129.       (       P1       )    +----+    (       P3       )  +----+
  130.       +\______________/     |    |----+\______________/+--|    |--
  131.       |                  +--| X1 |                       +| X2 |
  132.       | ______________  /   |    |-+    ______________  / |    |--
  133.       +/              \+    +-+--+  \  /              \+  +----+
  134.       (       P2       )     / \     +(      P4        )
  135.     --+\______________/     /   \      \______________/
  136.            |               /     \           |      |
  137.            |              /       |          |      |
  138.            |             /        |          |      |
  139.           _|_          _/_       _|_        _|_    _|_
  140.          /   \        /   \     /   \      /   \  /   \
  141.         ( S.A )      ( S.B )   ( P5  )    ( P6  )( S.D )
  142.          \___/        \___/     \___/      \___/  \___/
  143.                                   |          / \
  144.                                  _|_       _/_  \   ___
  145.                                 /   \     /   \  +-/   \
  146.                                ( S.E )   ( S.F )  ( S.G )
  147.                                 \___/     \___/    \___/
  148.  
  149.  
  150.    As shown in the figure above, the aggregatable address format is
  151.    designed to support long-haul providers (shown as P1, P2, P3, and
  152.    P4), exchanges [EXCH] (shown as X1 and X2), multiple levels of
  153.    providers (shown at P5 and P6), and subscribers (shown as S.x)
  154.    Exchanges (unlike current NAPs, FIXes, etc.) will allocate IPv6
  155.    addresses.  Organizations who connect to these exchanges will also
  156.    subscribe (directly, indirectly via the exchange, etc.)  for long-
  157.    haul service from one or more long-haul providers.  Doing so, they
  158.    will achieve addressing independence from long-haul transit
  159.    providers.  They will be able to change long-haul providers without
  160.    having to renumber their organization.  They can also be multihomed
  161.    via the exchange to more than one long-haul provider without having
  162.    to have address prefixes from each long-haul provider.  Note that the
  163.  
  164.  
  165.  
  166. draft-ietf-ipngwg-unicast-aggr-01.txt                           [Page 3]
  167.  
  168. INTERNET-DRAFT Aggregatable Global Unicast Address Format      June 1997
  169.  
  170.  
  171.    mechanisms used for this type of provider selection and portability
  172.    are not discussed in the document.
  173.  
  174.  
  175.  
  176.  
  177.  
  178. 3.1 Aggregatable Global Unicast Address Structure
  179.  
  180.    The aggregatable global unicast address format is as follows:
  181.  
  182.       | 3 |  13 |    32     |   16   |          64 bits               |
  183.       +---+-----+-----------+--------+--------------------------------+
  184.       |FP | TLA |   NLA*    |  SLA*  |         Interface ID           |
  185.       +---+-----+-----------+--------+--------------------------------+
  186.  
  187.  
  188.       <--Public Topology--->   Site
  189.                             <-------->
  190.                              Topology
  191.                                       <------Interface Identifier----->
  192.  
  193.    Where
  194.  
  195.       FP           Format Prefix (001)
  196.       TLA          Top-Level Aggregator
  197.       NLA*         Next-Level Aggregator(s)
  198.       SLA*         Site-Level Aggregator(s)
  199.       INTERFACE ID Interface Identifier
  200.  
  201.    The following sections specify each part of the IPv6 Aggregatable
  202.    Global Unicast address format.
  203.  
  204.  
  205. 3.2 Top-Level Aggregator
  206.  
  207.    Top-Level Aggregators (TLA) are the top level in the routing
  208.    hierarchy.  Default-free routers must have a routing table entry for
  209.    every active TLA.  They may have additional entries, but the routing
  210.    topology at all levels must be designed to minimize the number of
  211.    additional entries fed into the default free routing tables.
  212.  
  213.    This addressing format supports 8,192 (2^^13) TLA's.  Additional TLA
  214.    may be added by using this format for additional format prefixes.
  215.    The addition of another FP will add another 8,192 TLA's.
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222. draft-ietf-ipngwg-unicast-aggr-01.txt                           [Page 4]
  223.  
  224. INTERNET-DRAFT Aggregatable Global Unicast Address Format      June 1997
  225.  
  226.  
  227. 3.2.1 Assignment of TLAs
  228.  
  229.    TLAs are assigned to organizations providing public transit topology.
  230.    They are specifically not assigned to organizations only providing
  231.    leaf or private transit topology.  TLA assignment does not imply
  232.    ownership.  It does imply stewardship over valuable Internet
  233.    property.
  234.  
  235.    The IAB and IESG have authorized the Internet Assigned Numbers
  236.    Authority (IANA) as the appropriate entity to have the responsibility
  237.    for the management of the IPv6 address space as defined in [ALLOC].
  238.  
  239.    The IANA will assign small blocks of TLAs to IPv6 registries.  The
  240.    registries will assign the TLAs to organizations meeting the
  241.    requirements for TLAs.  When the registries have assigned all of
  242.    their TLAs they can request that the IANA give them another block.
  243.    The blocks do not have to be contiguous.  The IANA may also assign
  244.    TLAs to organizations directly.
  245.  
  246.    Organizations assigned TLAs are required to meet the following
  247.    requirements:
  248.  
  249.     - Must have a plan to offer public native IPv6 service within 6
  250.       months from assignment.  Plan must include plan for NLA
  251.       allocation.
  252.  
  253.     - Plan or track record providing public internet transit service on
  254.       fair, reasonable, and non-discriminatory terms, to other
  255.       providers.  TLAs must not be assigned to organizations that are
  256.       only providing leaf service even if multihomed.
  257.  
  258.     - Must provide registry services on fair, reasonable, and non-
  259.       discriminatory terms, for the NLA address space it is responsible
  260.       for under its TLA.  This must include both sites and next level
  261.       providers.
  262.  
  263.     - Must provide transit routing and forwarding to all assigned TLAs
  264.       on fair, reasonable, and non-discriminatory terms.  Organizations
  265.       are not allowed to filter out any specific TLA's (except
  266.       temporarily for diagnostic purposes or emergency repair purposed).
  267.  
  268.  
  269.     - Periodically (interval set by registry) provide to registry
  270.       utilization statistics of the TLA it has custody of.  The
  271.       organization must also show evidence of carrying TLA routing and
  272.       transit traffic.  This can be in the form of traffic statistics,
  273.       traceroutes, routing table dumps, or similar means.
  274.  
  275.  
  276.  
  277.  
  278. draft-ietf-ipngwg-unicast-aggr-01.txt                           [Page 5]
  279.  
  280. INTERNET-DRAFT Aggregatable Global Unicast Address Format      June 1997
  281.  
  282.  
  283.    Organizations which are given custody of a TLA and fail to continue
  284.    to meet these may have the TLA custody revoked.
  285.  
  286.  
  287. 3.3 Next-Level Aggregator(s)
  288.  
  289.    Next-Level Aggregator(s) are used by TLA's to create an addressing
  290.    hierarchy and to identify sites.  The TLA can assign the top part of
  291.    the NLA in a manner to create an addressing hierarchy appropriate to
  292.    its network.  It can use the remainder of the bits in the field to
  293.    identify sites it wishes to serve.  This is shown as follows:
  294.  
  295.          |  n  |      32-n bits     |   16   |    64 bits      |
  296.          +-----+--------------------+--------+-----------------+
  297.          |NLA1 |       Site         |  SLA*  | Interface ID    |
  298.          +-----+--------------------+--------+-----------------+
  299.  
  300.    Each TLA receives 32 bits of NLA* space.  This NLA* space allows each
  301.    TLA to provide service to about as many organizations as the current
  302.    IPv4 internet can support total nodes.
  303.  
  304.    The TLAs may also support NLAs in their own Site ID space.  This
  305.    allows the TLAs to provide service to organizations providing public
  306.    transit service and organizations who do not.  The organizations
  307.    providing public transit service become NLA's themselves.  These NLAs
  308.    may also choose to use their Site ID space to support other NLAs.
  309.    This is shown as follows:
  310.  
  311.          |  n  |      32-n bits     |   16   |    64 bits      |
  312.          +-----+--------------------+--------+-----------------+
  313.          |NLA1 |       Site         |  SLA*  | Interface ID    |
  314.          +-----+--------------------+--------+-----------------+
  315.  
  316.                |  m  |    32-n-m    |   16   |    64 bits      |
  317.                +-----+--------------+--------+-----------------+
  318.                |NLA2 |    Site      |  SLA*  | Interface ID    |
  319.                +-----+--------------+--------+-----------------+
  320.  
  321.                      |  o  |32-n-m-o|   16   |    64 bits      |
  322.                      +-----+--------+--------+-----------------+
  323.                      |NLA3 |  Site  |  SLA*  | Interface ID    |
  324.                      +-----+--------+--------+-----------------+
  325.  
  326.    The NLA delegation works in the same manner as CIDR delegation in
  327.    IPv4 [CIDR].  TLAs are required to assume registry duties for the
  328.    NLAs.  Each level of NLA is required to assume registry duties for
  329.    the next level NLA.
  330.  
  331.  
  332.  
  333.  
  334. draft-ietf-ipngwg-unicast-aggr-01.txt                           [Page 6]
  335.  
  336. INTERNET-DRAFT Aggregatable Global Unicast Address Format      June 1997
  337.  
  338.  
  339.    The design of the bit layout of the NLA space for a specific TLA is
  340.    left to the organization responsible for that TLA.  Likewise the
  341.    design of the bit layout of the next level NLA is the responsibility
  342.    of the previous level NLA.  It is recommended that organizations
  343.    assigning NLA address space use "slow start" allocation procedures as
  344.    is currently done with IPV4 CIDR blocks.
  345.  
  346.    The design of an NLA allocation plan is a tradeoff between routing
  347.    aggregation efficiency and flexibility.  Creating hierarchies allows
  348.    for greater amount of aggregation and results in smaller routing
  349.    tables.  Flat NLA assignment provides for easier allocation and
  350.    attachment flexibility but results in larger routing tables.
  351.  
  352.  
  353. 3.4 Site-Level Aggregator(s)
  354.  
  355.    The SLA* field is used by an individual organization to create its
  356.    own local addressing hierarchy and to identify subnets.  This is
  357.    analogous to subnets in IPv4 except that each organization has a much
  358.    greater number of subnets.  The 16 bit SLA* field support 65,535
  359.    individual subnets.
  360.  
  361.    Organizations may choose to either route their SLA* "flat" (e.g., not
  362.    create any logical relationship between the SLA identifiers which
  363.    results in larger routing tables), or to create a two or more level
  364.    hierarchy (which results in smaller routing tables) in the SLA*
  365.    field.  The latter is shown as follows:
  366.  
  367.          |  n  |   16-n     |              64 bits                |
  368.          +-----+------------+-------------------------------------+
  369.          |SLA1 |   Subnet   |            Interface ID             |
  370.          +-----+------------+-------------------------------------+
  371.  
  372.                | m  |16-n-m |              64 bits                |
  373.                +----+-------+-------------------------------------+
  374.                |SLA2|Subnet |            Interface ID             |
  375.                +----+-------+-------------------------------------+
  376.  
  377.    The approach chosen for how to the structure of an SLA* field is the
  378.    responsibility of the individual organization.
  379.  
  380.    The number of subnets supported should be sufficient for all but the
  381.    largest of organizations.  Organizations which need additional
  382.    subnets can arrange with the organization they are obtaining internet
  383.    service from to obtain additional site identifiers and use this to
  384.    create additional subnets.
  385.  
  386.  
  387.  
  388.  
  389.  
  390. draft-ietf-ipngwg-unicast-aggr-01.txt                           [Page 7]
  391.  
  392. INTERNET-DRAFT Aggregatable Global Unicast Address Format      June 1997
  393.  
  394.  
  395. 3.5 Interface ID
  396.  
  397.    Interface identifiers are used to identify interfaces on a link.
  398.    They are required to be unique on that link.  They may also be unique
  399.    over a broader scope.  In many cases an interface's identifier will
  400.    be the same as that interface's link-layer address.  Interface IDs
  401.    used in the aggregatable global unicast address format are required
  402.    to be 64 bits long and to be constructed in IEEE EUI-64 format
  403.    [EUI-64].  These identifiers may have global scope when a global
  404.    token (e.g., IEEE 48bit MAC) is available or may have local scope
  405.    where a global token is not available (e.g., serial links, tunnel
  406.    end-points, etc.).  The "u" bit (universal/local bit in IEEE EUI-64
  407.    terminology) in the EUI-64 identifier must be set correctly, as
  408.    defined in [ARCH], to indicate global or local scope.
  409.  
  410.    The procedures for creating EUI-64 based Interface Identifiers is
  411.    defined in [ARCH].  The details on forming interface identifiers is
  412.    defined in the appropriate "IPv6 over <link>" specification such as
  413.    "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446. draft-ietf-ipngwg-unicast-aggr-01.txt                           [Page 8]
  447.  
  448. INTERNET-DRAFT Aggregatable Global Unicast Address Format      June 1997
  449.  
  450.  
  451. 4.0 Acknowledgments
  452.  
  453.    The authors would like to express our thanks to Thomas Narten, Bob
  454.    Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
  455.    Scott Bradner, Brian Carpenter, and John Stewart.  for their review
  456.    and constructive comments.
  457.  
  458.  
  459. 5.0 References
  460.  
  461.      [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
  462.               RFC1881, December 1995.
  463.  
  464.      [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
  465.               Internet Draft, <draft-ietf-ipngwg-addr-arch-00.txt>, May
  466.               1997.
  467.  
  468.      [AUTO]    Thompson, S., Narten T., "IPv6 Stateless Address
  469.               Autoconfiguration", RFC1971, August 1996.
  470.  
  471.      [CIDR]    Fuller, V., T. Li, K. Varadhan, J. Yu, "Supernetting: an
  472.               Address Assignment and Aggregation Strategy", RFC1338.
  473.  
  474.      [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
  475.               Networks", Internet Draft, <draft-ietf-ipngwg-trans-
  476.               ethernet-00.txt>, March 1997.
  477.  
  478.      [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
  479.               Registration Authority",
  480.               http://standards.ieee.org/db/oui/tutorials/EUI64.html,
  481.               March 1997.
  482.  
  483.      [EXCH]    Hinden, R., Huitema, C. "Internet Exchanges", document
  484.               under preparation.
  485.  
  486.      [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
  487.               Networks", Internet Draft, <draft-ietf-ipngwg-trans-fddi-
  488.               net-00.txt>, March 1997.
  489.  
  490.      [IPV6]    Deering, S., Hinden, R., Editors, "Internet Protocol,
  491.               Version 6 (IPv6) Specification", RFC1883, December 1995.
  492.  
  493.      [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  494.               Requirement Levels", RFC2119, BCP14, March 1997.
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502. draft-ietf-ipngwg-unicast-aggr-01.txt                           [Page 9]
  503.  
  504. INTERNET-DRAFT Aggregatable Global Unicast Address Format      June 1997
  505.  
  506.  
  507. 6.0 Security Considerations
  508.  
  509.    Documents of this type do not directly impact the security of the
  510.    Internet infrastructure or its applications.
  511.  
  512.  
  513. 7.0 Authors' Addresses
  514.  
  515.    Robert M. Hinden                     phone: 1 408 990-2004
  516.    Ipsilon Networks, Inc.               email: hinden@ipsilon.com
  517.    232 Java Drive
  518.    Sunnyvale, CA 94089
  519.    USA
  520.  
  521.    Mike O'Dell                          phone: 1 703 206-5890
  522.    UUNET Technologies, Inc.             email: mo@uunet.uu.net
  523.    3060 Williams Drive
  524.    Fairfax, VA 22030
  525.    USA
  526.  
  527.    Stephen E. Deering                   phone: 1 408 527-8213
  528.    Cisco Systems, Inc.                  email: deering@cisco.com
  529.    170 West Tasman Drive
  530.    San Jose, CA 95134-1706
  531.    USA
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558. draft-ietf-ipngwg-unicast-aggr-01.txt                          [Page 10]
  559.