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-02.txt < prev    next >
Text File  |  1997-07-16  |  19KB  |  503 lines
  1.  
  2.  
  3. INTERNET-DRAFT                              R. Hinden, Ipsilon Networks
  4. July 16, 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-02.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 January 17, 1998.
  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-02.txt                           [Page 1]
  55.  
  56. INTERNET-DRAFT Aggregatable Global Unicast Address Format      July 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 sites that connect directly to providers and for
  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-02.txt                           [Page 2]
  111.  
  112. INTERNET-DRAFT Aggregatable Global Unicast Address Format      July 1997
  113.  
  114.  
  115.    While this address format is designed to support exchange-based
  116.    aggregation (in addition to current provider-based aggregation) it is
  117.    not dependent on exchanges for it's overall route aggregation
  118.    properties.  It will provide efficient route aggregation with only
  119.    provider-based aggregation.
  120.  
  121.    Aggregatable addresses are organized into a three level hierarchy:
  122.  
  123.       - Public Topology
  124.       - Site Topology
  125.       - Interface Identifier
  126.  
  127.    Public topology is the collection of providers and exchanges who
  128.    provide public Internet transit services.  Site topology is local to
  129.    a specific site or organization which does not provide public transit
  130.    service to nodes outside of the site.  Interface identifiers identify
  131.    interfaces on links.
  132.  
  133.         ______________                  ______________
  134.     --+/              \+--------------+/              \+----------
  135.       (       P1       )    +----+    (       P3       )  +----+
  136.       +\______________/     |    |----+\______________/+--|    |--
  137.       |                  +--| X1 |                       +| X2 |
  138.       | ______________  /   |    |-+    ______________  / |    |--
  139.       +/              \+    +-+--+  \  /              \+  +----+
  140.       (       P2       )     / \     +(      P4        )
  141.     --+\______________/     /   \      \______________/
  142.            |               /     \           |      |
  143.            |              /       |          |      |
  144.            |             /        |          |      |
  145.           _|_          _/_       _|_        _|_    _|_
  146.          /   \        /   \     /   \      /   \  /   \
  147.         ( S.A )      ( S.B )   ( P5  )    ( P6  )( S.C )
  148.          \___/        \___/     \___/      \___/  \___/
  149.                                   |          / \
  150.                                  _|_       _/_  \   ___
  151.                                 /   \     /   \  +-/   \
  152.                                ( S.D )   ( S.E )  ( S.F )
  153.                                 \___/     \___/    \___/
  154.  
  155.  
  156.    As shown in the figure above, the aggregatable address format is
  157.    designed to support long-haul providers (shown as P1, P2, P3, and
  158.    P4), exchanges [EXCH] (shown as X1 and X2), multiple levels of
  159.    providers (shown at P5 and P6), and subscribers (shown as S.x)
  160.    Exchanges (unlike current NAPs, FIXes, etc.) will allocate IPv6
  161.    addresses.  Organizations who connect to these exchanges will also
  162.    subscribe (directly, indirectly via the exchange, etc.) for long-haul
  163.  
  164.  
  165.  
  166. draft-ietf-ipngwg-unicast-aggr-02.txt                           [Page 3]
  167.  
  168. INTERNET-DRAFT Aggregatable Global Unicast Address Format      July 1997
  169.  
  170.  
  171.    service from one or more long-haul providers.  Doing so, they will
  172.    achieve addressing independence from long-haul transit providers.
  173.    They will be able to change long-haul providers without having to
  174.    renumber their organization.  They can also be multihomed via the
  175.    exchange to more than one long-haul provider without having to have
  176.    address prefixes from each long-haul provider.  Note that the
  177.    mechanisms used for this type of provider selection and portability
  178.    are not discussed in the document.
  179.  
  180.  
  181. 3.1 Aggregatable Global Unicast Address Structure
  182.  
  183.    The aggregatable global unicast address format is as follows:
  184.  
  185.       | 3 |  13 |    32     |   16   |          64 bits               |
  186.       +---+-----+-----------+--------+--------------------------------+
  187.       |FP | TLA | NLA ID    | SLA ID |         Interface ID           |
  188.       |   | ID  |           |        |                                |
  189.       +---+-----+-----------+--------+--------------------------------+
  190.  
  191.       <--Public Topology--->   Site
  192.                             <-------->
  193.                              Topology
  194.                                       <------Interface Identifier----->
  195.  
  196.    Where
  197.  
  198.       FP           Format Prefix (001)
  199.       TLA ID       Top-Level Aggregation Identifier
  200.       NLA ID       Next-Level Aggregation Identifier
  201.       SLA ID       Site-Level Aggregation Identifier
  202.       INTERFACE ID Interface Identifier
  203.  
  204.    The following sections specify each part of the IPv6 Aggregatable
  205.    Global Unicast address format.
  206.  
  207.  
  208. 3.2 Top-Level Aggregation ID
  209.  
  210.    Top-Level Aggregation Identifiers (TLA ID) are the top level in the
  211.    routing hierarchy.  Default-free routers must have a routing table
  212.    entry for every active TLA ID and will probably have additional
  213.    entries providing routing information for the TLA ID in which they
  214.    are located.  They may have additional entries in order to optimize
  215.    routing for their specific topology, but the routing topology at all
  216.    levels must be designed to minimize the number of additional entries
  217.    fed into the default free routing tables.
  218.  
  219.  
  220.  
  221.  
  222. draft-ietf-ipngwg-unicast-aggr-02.txt                           [Page 4]
  223.  
  224. INTERNET-DRAFT Aggregatable Global Unicast Address Format      July 1997
  225.  
  226.  
  227.    This addressing format supports 8,192 (2^13) TLA ID's.  Additional
  228.    TLA ID's may be added by using this format for additional format
  229.    prefixes.  The addition of another FP will add another 8,192 TLA
  230.    ID's.
  231.  
  232.    The rules for TLA ID assignment are defined in [TLAASN].
  233.  
  234.  
  235. 3.3 Next-Level Aggregation Identifier
  236.  
  237.    Next-Level Aggregation Identifier's are used by organizations
  238.    assigned a TLA ID to create an addressing hierarchy and to identify
  239.    sites.  The organization can assign the top part of the NLA ID in a
  240.    manner to create an addressing hierarchy appropriate to its network.
  241.    It can use the remainder of the bits in the field to identify sites
  242.    it wishes to serve.  This is shown as follows:
  243.  
  244.          |  n  |      32-n bits     |   16   |    64 bits      |
  245.          +-----+--------------------+--------+-----------------+
  246.          |NLA1 |      Site ID       | SLA ID | Interface ID    |
  247.          +-----+--------------------+--------+-----------------+
  248.  
  249.    Each organization assigned a TLA ID receives 32 bits of NLA ID space.
  250.    This NLA ID space allows each organization to provide service to
  251.    approximately as many organizations as the current IPv4 Internet can
  252.    support total nodes.
  253.  
  254.    Organizations assigned TLA ID's may also support NLA ID's in their
  255.    own Site ID space.  This allows the organization assigned a TLA ID to
  256.    provide service to organizations providing public transit service and
  257.    to organizations who do not provide public transit service.  These
  258.    organizations receiving an NLA ID may also choose to use their Site
  259.    ID space to support other NLA ID's.  This is shown as follows:
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. draft-ietf-ipngwg-unicast-aggr-02.txt                           [Page 5]
  279.  
  280. INTERNET-DRAFT Aggregatable Global Unicast Address Format      July 1997
  281.  
  282.  
  283.          |  n  |      32-n bits     |   16   |    64 bits      |
  284.          +-----+--------------------+--------+-----------------+
  285.          |NLA1 |      Site ID       | SLA ID | Interface ID    |
  286.          +-----+--------------------+--------+-----------------+
  287.  
  288.                |  m  |    32-n-m    |   16   |    64 bits      |
  289.                +-----+--------------+--------+-----------------+
  290.                |NLA2 |   Site ID    | SLA ID | Interface ID    |
  291.                +-----+--------------+--------+-----------------+
  292.  
  293.                      |  o  |32-n-m-o|   16   |    64 bits      |
  294.                      +-----+--------+--------+-----------------+
  295.                      |NLA3 | Site ID| SLA ID | Interface ID    |
  296.                      +-----+--------+--------+-----------------+
  297.  
  298.    The rules for NLA ID assignment are defined in [TLAASN].
  299.  
  300.    The design of the bit layout of the NLA ID space for a specific TLA
  301.    ID is left to the organization responsible for that TLA ID.  Likewise
  302.    the design of the bit layout of the next level NLA ID is the
  303.    responsibility of the previous level NLA ID.  It is recommended that
  304.    organizations assigning NLA address space use "slow start" allocation
  305.    procedures as is currently done with IPv4 CIDR blocks.
  306.  
  307.    The design of an NLA ID allocation plan is a tradeoff between routing
  308.    aggregation efficiency and flexibility.  Creating hierarchies allows
  309.    for greater amount of aggregation and results in smaller routing
  310.    tables.  Flat NLA ID assignment provides for easier allocation and
  311.    attachment flexibility, but results in larger routing tables.
  312.  
  313.  
  314. 3.4 Site-Level Aggregation Identifier
  315.  
  316.    The SLA ID field is used by an individual organization to create its
  317.    own local addressing hierarchy and to identify subnets.  This is
  318.    analogous to subnets in IPv4 except that each organization has a much
  319.    greater number of subnets.  The 16 bit SLA ID field support 65,535
  320.    individual subnets.
  321.  
  322.    Organizations may choose to either route their SLA ID "flat" (e.g.,
  323.    not create any logical relationship between the SLA identifiers that
  324.    results in larger routing tables), or to create a two or more level
  325.    hierarchy (that results in smaller routing tables) in the SLA ID
  326.    field.  The latter is shown as follows:
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334. draft-ietf-ipngwg-unicast-aggr-02.txt                           [Page 6]
  335.  
  336. INTERNET-DRAFT Aggregatable Global Unicast Address Format      July 1997
  337.  
  338.  
  339.          |  n  |   16-n     |              64 bits                |
  340.          +-----+------------+-------------------------------------+
  341.          |SLA1 |   Subnet   |            Interface ID             |
  342.          +-----+------------+-------------------------------------+
  343.  
  344.                | m  |16-n-m |              64 bits                |
  345.                +----+-------+-------------------------------------+
  346.                |SLA2|Subnet |            Interface ID             |
  347.                +----+-------+-------------------------------------+
  348.  
  349.    The approach chosen for structuring an SLA ID field is the
  350.    responsibility of the individual organization.
  351.  
  352.    The number of subnets supported in this address format should be
  353.    sufficient for all but the largest of organizations.  Organizations
  354.    which need additional subnets can arrange with the organization they
  355.    are obtaining Internet service from to obtain additional site
  356.    identifiers and use this to create additional subnets.
  357.  
  358.  
  359. 3.5 Interface ID
  360.  
  361.    Interface identifiers are used to identify interfaces on a link.
  362.    They are required to be unique on that link.  They may also be unique
  363.    over a broader scope.  In many cases an interface's identifier will
  364.    be the same or be based on the interface's link-layer address.
  365.    Interface IDs used in the aggregatable global unicast address format
  366.    are required to be 64 bits long and to be constructed in IEEE EUI-64
  367.    format [EUI-64].  These identifiers may have global scope when a
  368.    global token (e.g., IEEE 48bit MAC) is available or may have local
  369.    scope where a global token is not available (e.g., serial links,
  370.    tunnel end-points, etc.).  The "u" bit (universal/local bit in IEEE
  371.    EUI-64 terminology) in the EUI-64 identifier must be set correctly,
  372.    as defined in [ARCH], to indicate global or local scope.
  373.  
  374.    The procedures for creating EUI-64 based Interface Identifiers is
  375.    defined in [ARCH].  The details on forming interface identifiers is
  376.    defined in the appropriate "IPv6 over <link>" specification such as
  377.    "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390. draft-ietf-ipngwg-unicast-aggr-02.txt                           [Page 7]
  391.  
  392. INTERNET-DRAFT Aggregatable Global Unicast Address Format      July 1997
  393.  
  394.  
  395. 4.0 Acknowledgments
  396.  
  397.    The authors would like to express our thanks to Thomas Narten, Bob
  398.    Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
  399.    Scott Bradner, Brian Carpenter, and John Stewart for their review and
  400.    constructive comments.
  401.  
  402.  
  403. 5.0 References
  404.  
  405.    [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
  406.              RFC1881, December 1995.
  407.  
  408.    [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
  409.              Internet Draft, <draft-ietf-ipngwg-addr-arch-v2-02.txt>,
  410.              July 1997.
  411.  
  412.    [AUTH]    Atkinson, R., "IP Authentication Header", RFC1826, August
  413.              1995.
  414.  
  415.    [AUTO]    Thompson, S., Narten T., "IPv6 Stateless Address
  416.              Autoconfiguration", RFC1971, August 1996.
  417.  
  418.    [CIDR]    Fuller, V., T. Li, K. Varadhan, J. Yu, "Supernetting: an
  419.              Address Assignment and Aggregation Strategy", RFC1338.
  420.  
  421.    [ETHER]   Crawford, M., "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]    Huitema, C., R. Hinden, "Internet Exchanges", document
  431.              under preparation.
  432.  
  433.    [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
  434.              Networks", Internet Draft, <draft-ietf-ipngwg-trans-fddi-
  435.              net-00.txt>, March 1997.
  436.  
  437.    [IPV6]    Deering, S., Hinden, R., Editors, "Internet Protocol,
  438.              Version 6 (IPv6) Specification", RFC1883, December 1995.
  439.  
  440.    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  441.              Requirement Levels", RFC2119, BCP14, March 1997.
  442.  
  443.  
  444.  
  445.  
  446. draft-ietf-ipngwg-unicast-aggr-02.txt                           [Page 8]
  447.  
  448. INTERNET-DRAFT Aggregatable Global Unicast Address Format      July 1997
  449.  
  450.  
  451.    [TLAASN]  Hinden, R., "TLA and NLA Assignment Rules", Internet Draft,
  452.              <draft-ietf-ipngwg-tla-assignment-00.txt>, July 1997.
  453.  
  454.  
  455. 6.0 Security Considerations
  456.  
  457.    IPv6 addressing documents do not have any direct impact on Internet
  458.    infrastructure security.  Authentication of IPv6 packets is defined
  459.    in [AUTH].
  460.  
  461.  
  462. 7.0 Authors' Addresses
  463.  
  464.    Robert M. Hinden                     phone: 1 408 990-2004
  465.    Ipsilon Networks, Inc.               email: hinden@ipsilon.com
  466.    232 Java Drive
  467.    Sunnyvale, CA 94089
  468.    USA
  469.  
  470.    Mike O'Dell                          phone: 1 703 206-5890
  471.    UUNET Technologies, Inc.             email: mo@uunet.uu.net
  472.    3060 Williams Drive
  473.    Fairfax, VA 22030
  474.    USA
  475.  
  476.    Stephen E. Deering                   phone: 1 408 527-8213
  477.    Cisco Systems, Inc.                  email: deering@cisco.com
  478.    170 West Tasman Drive
  479.    San Jose, CA 95134-1706
  480.    USA
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502. draft-ietf-ipngwg-unicast-aggr-02.txt                           [Page 9]
  503.