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