home *** CD-ROM | disk | FTP | other *** search
/ Hackers Toolkit 2.0 / Hackers_Toolkit_v2.0.iso / HTML / archive / Texts / Rfc / rfc1518.txt < prev    next >
Encoding:
Text File  |  1999-11-04  |  70.9 KB  |  1,539 lines

  1. Network Working Group                                         Y. Rekhter
  2. Request for Comments: 1518        T.J. Watson Research Center, IBM Corp.
  3. Category: Standards Track                                          T. Li
  4.                                                            cisco Systems
  5.                                                                  Editors
  6.                                                           September 1993
  7.  
  8.  
  9.           An Architecture for IP Address Allocation with CIDR
  10.  
  11. Status of this Memo
  12.  
  13.    This RFC specifies an Internet standards track protocol for the
  14.    Internet community, and requests discussion and suggestions for
  15.    improvements.  Please refer to the current edition of the "Internet
  16.    Official Protocol Standards" for the standardization state and status
  17.    of this protocol.  Distribution of this memo is unlimited.
  18.  
  19. 1.  Introduction
  20.  
  21.    This paper provides an architecture and a plan for allocating IP
  22.    addresses in the Internet. This architecture and the plan are
  23.    intended to play an important role in steering the Internet towards
  24.    the Address Assignment and Aggregating Strategy outlined in [1].
  25.  
  26.    The IP address space is a scarce shared resource that must be managed
  27.    for the good of the community. The managers of this resource are
  28.    acting as its custodians. They have a responsibility to the community
  29.    to manage it for the common good.
  30.  
  31. 2.  Scope
  32.  
  33.    The global Internet can be modeled as a collection of hosts
  34.    interconnected via transmission and switching facilities.  Control
  35.    over the collection of hosts and the transmission and switching
  36.    facilities that compose the networking resources of the global
  37.    Internet is not homogeneous, but is distributed among multiple
  38.    administrative authorities. Resources under control of a single
  39.    administration form a domain.  For the rest of this paper, "domain"
  40.    and "routing domain" will be used interchangeably.  Domains that
  41.    share their resources with other domains are called network service
  42.    providers (or just providers). Domains that utilize other domain's
  43.    resources are called network service subscribers (or just
  44.    subscribers).  A given domain may act as a provider and a subscriber
  45.    simultaneously.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52. Rekhter & Li                                                    [Page 1]
  53.  
  54.  
  55. RFC 1518          CIDR Address Allocation Architecture    September 1993
  56.  
  57.  
  58.    There are two aspects of interest when discussing IP address
  59.    allocation within the Internet. The first is the set of
  60.    administrative requirements for obtaining and allocating IP
  61.    addresses; the second is the technical aspect of such assignments,
  62.    having largely to do with routing, both within a routing domain
  63.    (intra-domain routing) and between routing domains (inter-domain
  64.    routing). This paper focuses on the technical issues.
  65.  
  66.    In the current Internet many routing domains (such as corporate and
  67.    campus networks) attach to transit networks (such as regionals) in
  68.    only one or a small number of carefully controlled access points.
  69.    The former act as subscribers, while the latter act as providers.
  70.  
  71.    The architecture and recommendations provided in this paper are
  72.    intended for immediate deployment. This paper specifically does not
  73.    address long-term research issues, such as complex policy-based
  74.    routing requirements.
  75.  
  76.    Addressing solutions which require substantial changes or constraints
  77.    on the current topology are not considered.
  78.  
  79.    The architecture and recommendations in this paper are oriented
  80.    primarily toward the large-scale division of IP address allocation in
  81.    the Internet. Topics covered include:
  82.  
  83.       - Benefits of encoding some topological information in IP
  84.         addresses to significantly reduce routing protocol overhead;
  85.  
  86.       - The anticipated need for additional levels of hierarchy in
  87.         Internet addressing to support network growth;
  88.  
  89.       - The recommended mapping between Internet topological entities
  90.         (i.e., service providers, and service subscribers) and IP
  91.         addressing and routing components;
  92.  
  93.       - The recommended division of IP address assignment among service
  94.         providers (e.g., backbones, regionals), and service subscribers
  95.         (e.g., sites);
  96.  
  97.       - Allocation of the IP addresses by the Internet Registry;
  98.  
  99.       - Choice of the high-order portion of the IP addresses in leaf
  100.         routing domains that are connected to more than one service
  101.         provider (e.g., backbone or a regional network).
  102.  
  103.    It is noted that there are other aspects of IP address allocation,
  104.    both technical and administrative, that are not covered in this
  105.    paper.  Topics not covered or mentioned only superficially include:
  106.  
  107.  
  108.  
  109. Rekhter & Li                                                    [Page 2]
  110.  
  111.  
  112. RFC 1518          CIDR Address Allocation Architecture    September 1993
  113.  
  114.  
  115.       - Identification of specific administrative domains in the
  116.         Internet;
  117.  
  118.       - Policy or mechanisms for making registered information known to
  119.         third parties (such as the entity to which a specific IP address
  120.         or a portion of the IP address space has been allocated);
  121.  
  122.       - How a routing domain (especially a site) should organize its
  123.         internal topology or allocate portions of its IP address space;
  124.         the relationship between topology and addresses is discussed,
  125.         but the method of deciding on a particular topology or internal
  126.         addressing plan is not; and,
  127.  
  128.        - Procedures for assigning host IP addresses.
  129.  
  130. 3.  Background
  131.  
  132.    Some background information is provided in this section that is
  133.    helpful in understanding the issues involved in IP address
  134.    allocation. A brief discussion of IP routing is provided.
  135.  
  136.    IP partitions the routing problem into three parts:
  137.  
  138.       - routing exchanges between end systems and routers (ARP),
  139.  
  140.       - routing exchanges between routers in the same routing domain
  141.         (interior routing), and,
  142.  
  143.       - routing among routing domains (exterior routing).
  144.  
  145. 4. IP Addresses and Routing
  146.  
  147.    For the purposes of this paper, an IP prefix is an IP address and
  148.    some indication of the leftmost contiguous significant bits within
  149.    this address. Throughout this paper IP address prefixes will be
  150.    expressed as <IP-address IP-mask> tuples, such that a bitwise logical
  151.    AND operation on the IP-address and IP-mask components of a tuple
  152.    yields the sequence of leftmost contiguous significant bits that form
  153.    the IP address prefix. For example a tuple with the value <193.1.0.0
  154.    255.255.0.0> denotes an IP address prefix with 16 leftmost contiguous
  155.    significant bits.
  156.  
  157.    When determining an administrative policy for IP address assignment,
  158.    it is important to understand the technical consequences. The
  159.    objective behind the use of hierarchical routing is to achieve some
  160.    level of routing data abstraction, or summarization, to reduce the
  161.    cpu, memory, and transmission bandwidth consumed in support of
  162.    routing.
  163.  
  164.  
  165.  
  166. Rekhter & Li                                                    [Page 3]
  167.  
  168.  
  169. RFC 1518          CIDR Address Allocation Architecture    September 1993
  170.  
  171.  
  172.    While the notion of routing data abstraction may be applied to
  173.    various types of routing information, this paper focuses on one
  174.    particular type, namely reachability information. Reachability
  175.    information describes the set of reachable destinations.  Abstraction
  176.    of reachability information dictates that IP addresses be assigned
  177.    according to topological routing structures. However, administrative
  178.    assignment falls along organizational or political boundaries. These
  179.    may not be congruent to topological boundaries and therefore the
  180.    requirements of the two may collide. It is necessary to find a
  181.    balance between these two needs.
  182.  
  183.    Routing data abstraction occurs at the boundary between
  184.    hierarchically arranged topological routing structures. An element
  185.    lower in the hierarchy reports summary routing information to its
  186.    parent(s).
  187.  
  188.    At routing domain boundaries, IP address information is exchanged
  189.    (statically or dynamically) with other routing domains. If IP
  190.    addresses within a routing domain are all drawn from non-contiguous
  191.    IP address spaces (allowing no abstraction), then the boundary
  192.    information consists of an enumerated list of all the IP addresses.
  193.  
  194.    Alternatively, should the routing domain draw IP addresses for all
  195.    the hosts within the domain from a single IP address prefix, boundary
  196.    routing information can be summarized into the single IP address
  197.    prefix.  This permits substantial data reduction and allows better
  198.    scaling (as compared to the uncoordinated addressing discussed in the
  199.    previous paragraph).
  200.  
  201.    If routing domains are interconnected in a more-or-less random (i.e.,
  202.    non-hierarchical) scheme, it is quite likely that no further
  203.    abstraction of routing data can occur. Since routing domains would
  204.    have no defined hierarchical relationship, administrators would not
  205.    be able to assign IP addresses within the domains out of some common
  206.    prefix for the purpose of data abstraction. The result would be flat
  207.    inter-domain routing; all routing domains would need explicit
  208.    knowledge of all other routing domains that they route to.  This can
  209.    work well in small and medium sized internets.  However, this does
  210.    not scale to very large internets.  For example, we expect growth in
  211.    the future to an Internet which has tens or hundreds of thousands of
  212.    routing domains in North America alone.  This requires a greater
  213.    degree of the reachability information abstraction beyond that which
  214.    can be achieved at the "routing domain" level.
  215.  
  216.    In the Internet, however, it should be possible to significantly
  217.    constrain the volume and the complexity of routing information by
  218.    taking advantage of the existing hierarchical interconnectivity, as
  219.    discussed in Section 5. Thus, there is the opportunity for a group of
  220.  
  221.  
  222.  
  223. Rekhter & Li                                                    [Page 4]
  224.  
  225.  
  226. RFC 1518          CIDR Address Allocation Architecture    September 1993
  227.  
  228.  
  229.    routing domains each to be assigned an address prefix from a shorter
  230.    prefix assigned to another routing domain whose function is to
  231.    interconnect the group of routing domains. Each member of the group
  232.    of routing domains now has its (somewhat longer) prefix, from which
  233.    it assigns its addresses.
  234.  
  235.    The most straightforward case of this occurs when there is a set of
  236.    routing domains which are all attached to a single service provider
  237.    domain (e.g., regional network), and which use that provider for all
  238.    external (inter-domain) traffic.  A small prefix may be given to the
  239.    provider, which then gives slightly longer prefixes (based on the
  240.    provider's prefix) to each of the routing domains that it
  241.    interconnects. This allows the provider, when informing other routing
  242.    domains of the addresses that it can reach, to abbreviate the
  243.    reachability information for a large number of routing domains as a
  244.    single prefix. This approach therefore can allow a great deal of
  245.    hierarchical abbreviation of routing information, and thereby can
  246.    greatly improve the scalability of inter-domain routing.
  247.  
  248.    Clearly, this approach is recursive and can be carried through
  249.    several iterations. Routing domains at any "level" in the hierarchy
  250.    may use their prefix as the basis for subsequent suballocations,
  251.    assuming that the IP addresses remain within the overall length and
  252.    structure constraints.
  253.  
  254.    At this point, we observe that the number of nodes at each lower
  255.    level of a hierarchy tends to grow exponentially. Thus the greatest
  256.    gains in the reachability information abstraction (for the benefit of
  257.    all higher levels of the hierarchy) occur when the reachability
  258.    information aggregation occurs near the leaves of the hierarchy; the
  259.    gains drop significantly at each higher level. Therefore, the law of
  260.    diminishing returns suggests that at some point data abstraction
  261.    ceases to produce significant benefits. Determination of the point at
  262.    which data abstraction ceases to be of benefit requires a careful
  263.    consideration of the number of routing domains that are expected to
  264.    occur at each level of the hierarchy (over a given period of time),
  265.    compared to the number of routing domains and address prefixes that
  266.    can conveniently and efficiently be handled via dynamic inter-domain
  267.    routing protocols.
  268.  
  269. 4.1  Efficiency versus Decentralized Control
  270.  
  271.    If the Internet plans to support a decentralized address
  272.    administration [4], then there is a balance that must be sought
  273.    between the requirements on IP addresses for efficient routing and
  274.    the need for decentralized address administration. A proposal
  275.    described in [3] offers an example of how these two needs might be
  276.    met.
  277.  
  278.  
  279.  
  280. Rekhter & Li                                                    [Page 5]
  281.  
  282.  
  283. RFC 1518          CIDR Address Allocation Architecture    September 1993
  284.  
  285.  
  286.    The IP address prefix <198.0.0.0 254.0.0.0> provides for
  287.    administrative decentralization. This prefix identifies part of the
  288.    IP address space allocated for North America. The lower order part of
  289.    that prefix allows allocation of IP addresses along topological
  290.    boundaries in support of increased data abstraction.  Clients within
  291.    North America use parts of the IP address space that is underneath
  292.    the IP address space of their service providers.  Within a routing
  293.    domain addresses for subnetworks and hosts are allocated from the
  294.    unique IP prefix assigned to the domain.
  295.  
  296. 5.  IP Address Administration and Routing in the Internet
  297.  
  298.    The basic Internet routing components are service providers (e.g.,
  299.    backbones, regional networks), and service subscribers (e.g., sites
  300.    or campuses).  These components are arranged hierarchically for the
  301.    most part.  A natural mapping from these components to IP routing
  302.    components is that providers and subscribers act as routing domains.
  303.  
  304.    Alternatively, a subscriber (e.g., a site) may choose to operate as a
  305.    part of a domain formed by a service provider. We assume that some,
  306.    if not most, sites will prefer to operate as part of their provider's
  307.    routing domain.  Such sites can exchange routing information with
  308.    their provider via interior routing protocol route leaking or via an
  309.    exterior routing protocol.  For the purposes of this discussion, the
  310.    choice is not significant.  The site is still allocated a prefix from
  311.    the provider's address space, and the provider will advertise its own
  312.    prefix into inter-domain routing.
  313.  
  314.    Given such a mapping, where should address administration and
  315.    allocation be performed to satisfy both administrative
  316.    decentralization and data abstraction? The following possibilities
  317.    are considered:
  318.  
  319.       - at some part within a routing domain,
  320.  
  321.       - at the leaf routing domain,
  322.  
  323.       - at the transit routing domain (TRD), and
  324.  
  325.       - at the continental boundaries.
  326.  
  327.       A point within a routing domain corresponds to a subnetwork. If a
  328.       domain is composed of multiple subnetworks, they are
  329.       interconnected via routers.  Leaf routing domains correspond to
  330.       sites, where the primary purpose is to provide intra-domain
  331.       routing services. Transit routing domains are deployed to carry
  332.       transit (i.e., inter-domain) traffic; backbones and providers are
  333.       TRDs.
  334.  
  335.  
  336.  
  337. Rekhter & Li                                                    [Page 6]
  338.  
  339.  
  340. RFC 1518          CIDR Address Allocation Architecture    September 1993
  341.  
  342.  
  343.       The greatest burden in transmitting and operating on routing
  344.       information is at the top of the routing hierarchy, where routing
  345.       information tends to accumulate. In the Internet, for example,
  346.       providers must manage the set of network numbers for all networks
  347.       reachable through the provider. Traffic destined for other
  348.       providers is generally routed to the backbones (which act as
  349.       providers as well).  The backbones, however, must be cognizant of
  350.       the network numbers for all attached providers and their
  351.       associated networks.
  352.  
  353.       In general, the advantage of abstracting routing information at a
  354.       given level of the routing hierarchy is greater at the higher
  355.       levels of the hierarchy. There is relatively little direct benefit
  356.       to the administration that performs the abstraction, since it must
  357.       maintain routing information individually on each attached
  358.       topological routing structure.
  359.  
  360.       For example, suppose that a given site is trying to decide whether
  361.       to obtain an IP address prefix directly from the IP address space
  362.       allocated for North America, or from the IP address space
  363.       allocated to its service provider. If considering only their own
  364.       self-interest, the site itself and the attached provider have
  365.       little reason to choose one approach or the other. The site must
  366.       use one prefix or another; the source of the prefix has little
  367.       effect on routing efficiency within the site. The provider must
  368.       maintain information about each attached site in order to route,
  369.       regardless of any commonality in the prefixes of the sites.
  370.  
  371.       However, there is a difference when the provider distributes
  372.       routing information to other providers (e.g., backbones or TRDs).
  373.       In the first case, the provider cannot aggregate the site's
  374.       address into its own prefix; the address must be explicitly listed
  375.       in routing exchanges, resulting in an additional burden to other
  376.       providers which must exchange and maintain this information.
  377.  
  378.       In the second case, each other provider (e.g., backbone or TRD)
  379.       sees a single address prefix for the provider, which encompasses
  380.       the new site. This avoids the exchange of additional routing
  381.       information to identify the new site's address prefix. Thus, the
  382.       advantages primarily accrue to other providers which maintain
  383.       routing information about this site and provider.
  384.  
  385.       One might apply a supplier/consumer model to this problem: the
  386.       higher level (e.g., a backbone) is a supplier of routing services,
  387.       while the lower level (e.g., a TRD) is the consumer of these
  388.       services. The price charged for services is based upon the cost of
  389.       providing them.  The overhead of managing a large table of
  390.       addresses for routing to an attached topological entity
  391.  
  392.  
  393.  
  394. Rekhter & Li                                                    [Page 7]
  395.  
  396.  
  397. RFC 1518          CIDR Address Allocation Architecture    September 1993
  398.  
  399.  
  400.       contributes to this cost.
  401.  
  402.       The Internet, however, is not a market economy. Rather, efficient
  403.       operation is based on cooperation. The recommendations discussed
  404.       below describe simple and tractable ways of managing the IP
  405.       address space that benefit the entire community.
  406.  
  407. 5.1   Administration of IP addresses within a domain
  408.  
  409.       If individual subnetworks take their IP addresses from a myriad of
  410.       unrelated IP address spaces, there will be effectively no data
  411.       abstraction beyond what is built into existing intra-domain
  412.       routing protocols.  For example, assume that within a routing
  413.       domain uses three independent prefixes assigned from three
  414.       different IP address spaces associated with three different
  415.       attached providers.
  416.  
  417.       This has a negative effect on inter-domain routing, particularly
  418.       on those other domains which need to maintain routes to this
  419.       domain.  There is no common prefix that can be used to represent
  420.       these IP addresses and therefore no summarization can take place
  421.       at the routing domain boundary. When addresses are advertised by
  422.       this routing domain to other routing domains, an enumerated list
  423.       of the three individual prefixes must be used.
  424.  
  425.       This situation is roughly analogous to the present dissemination
  426.       of routing information in the Internet, where each domain may have
  427.       non-contiguous network numbers assigned to it.  The result of
  428.       allowing subnetworks within a routing domain to take their IP
  429.       addresses from unrelated IP address spaces is flat routing at the
  430.       A/B/C class network level.  The number of IP prefixes that leaf
  431.       routing domains would advertise is on the order of the number of
  432.       attached network numbers; the number of prefixes a provider's
  433.       routing domain would advertise is approximately the number of
  434.       network numbers attached to the client leaf routing domains; and
  435.       for a backbone this would be summed across all attached providers.
  436.       This situation is just barely acceptable in the current Internet,
  437.       and as the Internet grows this will quickly become intractable. A
  438.       greater degree of hierarchical information reduction is necessary
  439.       to allow continued growth in the Internet.
  440.  
  441. 5.2   Administration at the Leaf Routing Domain
  442.  
  443.       As mentioned previously, the greatest degree of data abstraction
  444.       comes at the lowest levels of the hierarchy. Providing each leaf
  445.       routing domain (that is, site) with a prefix from its provider's
  446.       prefix results in the biggest single increase in abstraction. From
  447.       outside the leaf routing domain, the set of all addresses
  448.  
  449.  
  450.  
  451. Rekhter & Li                                                    [Page 8]
  452.  
  453.  
  454. RFC 1518          CIDR Address Allocation Architecture    September 1993
  455.  
  456.  
  457.       reachable in the domain can then be represented by a single
  458.       prefix.  Further, all destinations reachable within the provider's
  459.       prefix can be represented by a single prefix.
  460.  
  461.       For example, consider a single campus which is a leaf routing
  462.       domain which would currently require 4 different IP networks.
  463.       Under the new allocation scheme, they might instead be given a
  464.       single prefix which provides the same number of destination
  465.       addresses.  Further, since the prefix is a subset of the
  466.       provider's prefix, they impose no additional burden on the higher
  467.       levels of the routing hierarchy.
  468.  
  469.       There is a close relationship between subnetworks and routing
  470.       domains implicit in the fact that they operate a common routing
  471.       protocol and are under the control of a single administration. The
  472.       routing domain administration subdivides the domain into
  473.       subnetworks.  The routing domain represents the only path between
  474.       a subnetwork and the rest of the internetwork. It is reasonable
  475.       that this relationship also extend to include a common IP
  476.       addressing space. Thus, the subnetworks within the leaf routing
  477.       domain should take their IP addresses from the prefix assigned to
  478.       the leaf routing domain.
  479.  
  480. 5.3   Administration at the Transit Routing Domain
  481.  
  482.       Two kinds of transit routing domains are considered, direct
  483.       providers and indirect providers. Most of the subscribers of a
  484.       direct provider are domains that act solely as service subscribers
  485.       (they carry no transit traffic). Most of the subscribers of an
  486.       indirect provider are domains that, themselves, act as service
  487.       providers. In present terminology a backbone is an indirect
  488.       provider, while a TRD is a direct provider. Each case is discussed
  489.       separately below.
  490.  
  491. 5.3.1   Direct Service Providers
  492.  
  493.       It is interesting to consider whether direct service providers'
  494.       routing domains should use their IP address space for assigning IP
  495.       addresses from a unique prefix to the leaf routing domains that
  496.       they serve. The benefits derived from data abstraction are greater
  497.       than in the case of leaf routing domains, and the additional
  498.       degree of data abstraction provided by this may be necessary in
  499.       the short term.
  500.  
  501.       As an illustration consider an example of a direct provider that
  502.       serves 100 clients. If each client takes its addresses from 4
  503.       independent address spaces then the total number of entries that
  504.       are needed to handle routing to these clients is 400 (100 clients
  505.  
  506.  
  507.  
  508. Rekhter & Li                                                    [Page 9]
  509.  
  510.  
  511. RFC 1518          CIDR Address Allocation Architecture    September 1993
  512.  
  513.  
  514.       times 4 providers).  If each client takes its addresses from a
  515.       single address space then the total number of entries would be
  516.       only 100. Finally, if all the clients take their addresses from
  517.       the same address space then the total number of entries would be
  518.       only 1.
  519.  
  520.       We expect that in the near term the number of routing domains in
  521.       the Internet will grow to the point that it will be infeasible to
  522.       route on the basis of a flat field of routing domains. It will
  523.       therefore be essential to provide a greater degree of information
  524.       abstraction.
  525.  
  526.       Direct providers may give part of their address space (prefixes)
  527.       to leaf domains, based on an address prefix given to the provider.
  528.       This results in direct providers advertising to backbones a small
  529.       fraction of the number of address prefixes that would be necessary
  530.       if they enumerated the individual prefixes of the leaf routing
  531.       domains.  This represents a significant savings given the expected
  532.       scale of global internetworking.
  533.  
  534.       Are leaf routing domains willing to accept prefixes derived from
  535.       the direct providers? In the supplier/consumer model, the direct
  536.       provider is offering connectivity as the service, priced according
  537.       to its costs of operation. This includes the "price" of obtaining
  538.       service from one or more indirect providers (e.g., backbones). In
  539.       general, indirect providers will want to handle as few address
  540.       prefixes as possible to keep costs low. In the Internet
  541.       environment, which does not operate as a typical marketplace, leaf
  542.       routing domains must be sensitive to the resource constraints of
  543.       the providers (both direct and indirect). The efficiencies gained
  544.       in inter-domain routing clearly warrant the adoption of IP address
  545.       prefixes derived from the IP address space of the providers.
  546.  
  547.       The mechanics of this scenario are straightforward. Each direct
  548.       provider is given a unique small set of IP address prefixes, from
  549.       which its attached leaf routing domains can allocates slightly
  550.       longer IP address prefixes.  For example assume that NIST is a
  551.       leaf routing domain whose inter-domain link is via SURANet. If
  552.       SURANet is assigned an unique IP address prefix <198.1.0.0
  553.       255.255.0.0>, NIST could use a unique IP prefix of <198.1.0.0
  554.       255.255.240.0>.
  555.  
  556.       If a direct service provider is connected to another provider(s)
  557.       (either direct or indirect) via multiple attachment points, then
  558.       in certain cases it may be advantageous to the direct provider to
  559.       exert a certain degree of control over the coupling between the
  560.       attachment points and flow of the traffic destined to a particular
  561.       subscriber.  Such control can be facilitated by first partitioning
  562.  
  563.  
  564.  
  565. Rekhter & Li                                                   [Page 10]
  566.  
  567.  
  568. RFC 1518          CIDR Address Allocation Architecture    September 1993
  569.  
  570.  
  571.       all the subscribers into groups, such that traffic destined to all
  572.       the subscribers within a group should flow through a particular
  573.       attachment point. Once the partitioning is done, the address space
  574.       of the provider is subdivided along the group boundaries. A leaf
  575.       routing domain that is willing to accept prefixes derived from its
  576.       direct provider gets a prefix from the provider's address space
  577.       subdivision associated with the group the domain belongs to. Note
  578.       that the advertisement by the direct provider of the routing
  579.       information associated with each subdivision must be done with
  580.       care to ensure that such an advertisement would not result in a
  581.       global distribution of separate reachability information
  582.       associated with each subdivision, unless such distribution is
  583.       warranted for some other purposes (e.g., supporting certain
  584.       aspects of policy-based routing).
  585.  
  586. 5.3.2   Indirect Providers (Backbones)
  587.  
  588.       There does not appear to be a strong case for direct providers to
  589.       take their address spaces from the the IP space of an indirect
  590.       provider (e.g., backbone). The benefit in routing data abstraction
  591.       is relatively small. The number of direct providers today is in
  592.       the tens and an order of magnitude increase would not cause an
  593.       undue burden on the backbones.  Also, it may be expected that as
  594.       time goes by there will be increased direct interconnection of the
  595.       direct providers, leaf routing domains directly attached to the
  596.       backbones, and international links directly attached to the
  597.       providers. Under these circumstances, the distinction between
  598.       direct and indirect providers may become blurred.
  599.  
  600.       An additional factor that discourages allocation of IP addresses
  601.       from a backbone prefix is that the backbones and their attached
  602.       providers are perceived as being independent. Providers may take
  603.       their long- haul service from one or more backbones, or may switch
  604.       backbones should a more cost-effective service be provided
  605.       elsewhere. Having IP addresses derived from a backbone is
  606.       inconsistent with the nature of the relationship.
  607.  
  608. 5.4   Multi-homed Routing Domains
  609.  
  610.       The discussions in Section 5.3 suggest methods for allocating IP
  611.       addresses based on direct or indirect provider connectivity. This
  612.       allows a great deal of information reduction to be achieved for
  613.       those routing domains which are attached to a single TRD. In
  614.       particular, such routing domains may select their IP addresses
  615.       from a space delegated to them by the direct provider. This allows
  616.       the provider, when announcing the addresses that it can reach to
  617.       other providers, to use a single address prefix to describe a
  618.       large number of IP addresses corresponding to multiple routing
  619.  
  620.  
  621.  
  622. Rekhter & Li                                                   [Page 11]
  623.  
  624.  
  625. RFC 1518          CIDR Address Allocation Architecture    September 1993
  626.  
  627.  
  628.       domains.
  629.  
  630.       However, there are additional considerations for routing domains
  631.       which are attached to multiple providers. Such "multi-homed"
  632.       routing domains may, for example, consist of single-site campuses
  633.       and companies which are attached to multiple backbones, large
  634.       organizations which are attached to different providers at
  635.       different locations in the same country, or multi-national
  636.       organizations which are attached to backbones in a variety of
  637.       countries worldwide. There are a number of possible ways to deal
  638.       with these multi-homed routing domains.
  639.  
  640.       One possible solution is for each multi-homed organization to
  641.       obtain its IP address space independently from the providers to
  642.       which it is attached.  This allows each multi-homed organization
  643.       to base its IP assignments on a single prefix, and to thereby
  644.       summarize the set of all IP addresses reachable within that
  645.       organization via a single prefix.  The disadvantage of this
  646.       approach is that since the IP address for that organization has no
  647.       relationship to the addresses of any particular TRD, the TRDs to
  648.       which this organization is attached will need to advertise the
  649.       prefix for this organization to other providers.  Other providers
  650.       (potentially worldwide) will need to maintain an explicit entry
  651.       for that organization in their routing tables.
  652.  
  653.       For example, suppose that a very large North American company
  654.       "Mega Big International Incorporated" (MBII) has a fully
  655.       interconnected internal network and is assigned a single prefix as
  656.       part of the North American prefix.  It is likely that outside of
  657.       North America, a single entry may be maintained in routing tables
  658.       for all North American destinations.  However, within North
  659.       America, every provider will need to maintain a separate address
  660.       entry for MBII. If MBII is in fact an international corporation,
  661.       then it may be necessary for every provider worldwide to maintain
  662.       a separate entry for MBII (including backbones to which MBII is
  663.       not attached). Clearly this may be acceptable if there are a small
  664.       number of such multi-homed routing domains, but would place an
  665.       unacceptable load on routers within backbones if all organizations
  666.       were to choose such address assignments.  This solution may not
  667.       scale to internets where there are many hundreds of thousands of
  668.       multi-homed organizations.
  669.  
  670.       A second possible approach would be for multi-homed organizations
  671.       to be assigned a separate IP address space for each connection to
  672.       a TRD, and to assign a single prefix to some subset of its
  673.       domain(s) based on the closest interconnection point. For example,
  674.       if MBII had connections to two providers in the U.S. (one east
  675.       coast, and one west coast), as well as three connections to
  676.  
  677.  
  678.  
  679. Rekhter & Li                                                   [Page 12]
  680.  
  681.  
  682. RFC 1518          CIDR Address Allocation Architecture    September 1993
  683.  
  684.  
  685.       national backbones in Europe, and one in the far east, then MBII
  686.       may make use of six different address prefixes.  Each part of MBII
  687.       would be assigned a single address prefix based on the nearest
  688.       connection.
  689.  
  690.       For purposes of external routing of traffic from outside MBII to a
  691.       destination inside of MBII, this approach works similarly to
  692.       treating MBII as six separate organizations. For purposes of
  693.       internal routing, or for routing traffic from inside of MBII to a
  694.       destination outside of MBII, this approach works the same as the
  695.       first solution.
  696.  
  697.       If we assume that incoming traffic (coming from outside of MBII,
  698.       with a destination within MBII) is always to enter via the nearest
  699.       point to the destination, then each TRD which has a connection to
  700.       MBII needs to announce to other TRDs the ability to reach only
  701.       those parts of MBII whose address is taken from its own address
  702.       space. This implies that no additional routing information needs
  703.       to be exchanged between TRDs, resulting in a smaller load on the
  704.       inter-domain routing tables maintained by TRDs when compared to
  705.       the first solution. This solution therefore scales better to
  706.       extremely large internets containing very large numbers of multi-
  707.       homed organizations.
  708.  
  709.       One problem with the second solution is that backup routes to
  710.       multi-homed organizations are not automatically maintained. With
  711.       the first solution, each TRD, in announcing the ability to reach
  712.       MBII, specifies that it is able to reach all of the hosts within
  713.       MBII. With the second solution, each TRD announces that it can
  714.       reach all of the hosts based on its own address prefix, which only
  715.       includes some of the hosts within MBII. If the connection between
  716.       MBII and one particular TRD were severed, then the hosts within
  717.       MBII with addresses based on that TRD would become unreachable via
  718.       inter-domain routing. The impact of this problem can be reduced
  719.       somewhat by maintenance of additional information within routing
  720.       tables, but this reduces the scaling advantage of the second
  721.       approach.
  722.  
  723.       The second solution also requires that when external connectivity
  724.       changes, internal addresses also change.
  725.  
  726.       Also note that this and the previous approach will tend to cause
  727.       packets to take different routes. With the first approach, packets
  728.       from outside of MBII destined for within MBII will tend to enter
  729.       via the point which is closest to the source (which will therefore
  730.       tend to maximize the load on the networks internal to MBII). With
  731.       the second solution, packets from outside destined for within MBII
  732.       will tend to enter via the point which is closest to the
  733.  
  734.  
  735.  
  736. Rekhter & Li                                                   [Page 13]
  737.  
  738.  
  739. RFC 1518          CIDR Address Allocation Architecture    September 1993
  740.  
  741.  
  742.       destination (which will tend to minimize the load on the networks
  743.       within MBII, and maximize the load on the TRDs).
  744.  
  745.       These solutions also have different effects on policies. For
  746.       example, suppose that country "X" has a law that traffic from a
  747.       source within country X to a destination within country X must at
  748.       all times stay entirely within the country. With the first
  749.       solution, it is not possible to determine from the destination
  750.       address whether or not the destination is within the country. With
  751.       the second solution, a separate address may be assigned to those
  752.       hosts which are within country X, thereby allowing routing
  753.       policies to be followed.  Similarly, suppose that "Little Small
  754.       Company" (LSC) has a policy that its packets may never be sent to
  755.       a destination that is within MBII. With either solution, the
  756.       routers within LSC may be configured to discard any traffic that
  757.       has a destination within MBII's address space. However, with the
  758.       first solution this requires one entry; with the second it
  759.       requires many entries and may be impossible as a practical matter.
  760.  
  761.       There are other possible solutions as well. A third approach is to
  762.       assign each multi-homed organization a single address prefix,
  763.       based on one of its connections to a TRD. Other TRDs to which the
  764.       multi-homed organization are attached maintain a routing table
  765.       entry for the organization, but are extremely selective in terms
  766.       of which other TRDs are told of this route. This approach will
  767.       produce a single "default" routing entry which all TRDs will know
  768.       how to reach (since presumably all TRDs will maintain routes to
  769.       each other), while providing more direct routing in some cases.
  770.  
  771.       There is at least one situation in which this third approach is
  772.       particularly appropriate. Suppose that a special interest group of
  773.       organizations have deployed their own backbone. For example, lets
  774.       suppose that the U.S. National Widget Manufacturers and
  775.       Researchers have set up a U.S.-wide backbone, which is used by
  776.       corporations who manufacture widgets, and certain universities
  777.       which are known for their widget research efforts. We can expect
  778.       that the various organizations which are in the widget group will
  779.       run their internal networks as separate routing domains, and most
  780.       of them will also be attached to other TRDs (since most of the
  781.       organizations involved in widget manufacture and research will
  782.       also be involved in other activities). We can therefore expect
  783.       that many or most of the organizations in the widget group are
  784.       dual-homed, with one attachment for widget-associated
  785.       communications and the other attachment for other types of
  786.       communications. Let's also assume that the total number of
  787.       organizations involved in the widget group is small enough that it
  788.       is reasonable to maintain a routing table containing one entry per
  789.       organization, but that they are distributed throughout a larger
  790.  
  791.  
  792.  
  793. Rekhter & Li                                                   [Page 14]
  794.  
  795.  
  796. RFC 1518          CIDR Address Allocation Architecture    September 1993
  797.  
  798.  
  799.       internet with many millions of (mostly not widget-associated)
  800.       routing domains.
  801.  
  802.       With the third approach, each multi-homed organization in the
  803.       widget group would make use of an address assignment based on its
  804.       other attachment(s) to TRDs (the attachments not associated with
  805.       the widget group). The widget backbone would need to maintain
  806.       routes to the routing domains associated with the various member
  807.       organizations.  Similarly, all members of the widget group would
  808.       need to maintain a table of routes to the other members via the
  809.       widget backbone.  However, since the widget backbone does not
  810.       inform other general worldwide TRDs of what addresses it can reach
  811.       (since the backbone is not intended for use by other outside
  812.       organizations), the relatively large set of routing prefixes needs
  813.       to be maintained only in a limited number of places. The addresses
  814.       assigned to the various organizations which are members of the
  815.       widget group would provide a "default route" via each members
  816.       other attachments to TRDs, while allowing communications within
  817.       the widget group to use the preferred path.
  818.  
  819.       A fourth solution involves assignment of a particular address
  820.       prefix for routing domains which are attached to precisely two (or
  821.       more) specific routing domains. For example, suppose that there
  822.       are two providers "SouthNorthNet" and "NorthSouthNet" which have a
  823.       very large number of customers in common (i.e., there are a large
  824.       number of routing domains which are attached to both). Rather than
  825.       getting two address prefixes these organizations could obtain
  826.       three prefixes.  Those routing domains which are attached to
  827.       NorthSouthNet but not attached to SouthNorthNet obtain an address
  828.       assignment based on one of the prefixes. Those routing domains
  829.       which are attached to SouthNorthNet but not to NorthSouthNet would
  830.       obtain an address based on the second prefix. Finally, those
  831.       routing domains which are multi-homed to both of these networks
  832.       would obtain an address based on the third prefix.  Each of these
  833.       two TRDs would then advertise two prefixes to other TRDs, one
  834.       prefix for leaf routing domains attached to it only, and one
  835.       prefix for leaf routing domains attached to both.
  836.  
  837.       This fourth solution is likely to be important when use of public
  838.       data networks becomes more common. In particular, it is likely
  839.       that at some point in the future a substantial percentage of all
  840.       routing domains will be attached to public data networks. In this
  841.       case, nearly all government-sponsored networks (such as some
  842.       current regionals) may have a set of customers which overlaps
  843.       substantially with the public networks.
  844.  
  845.       There are therefore a number of possible solutions to the problem
  846.       of assigning IP addresses to multi-homed routing domains. Each of
  847.  
  848.  
  849.  
  850. Rekhter & Li                                                   [Page 15]
  851.  
  852.  
  853. RFC 1518          CIDR Address Allocation Architecture    September 1993
  854.  
  855.  
  856.       these solutions has very different advantages and disadvantages.
  857.       Each solution places a different real (i.e., financial) cost on
  858.       the multi-homed organizations, and on the TRDs (including those to
  859.       which the multi-homed organizations are not attached).
  860.  
  861.       In addition, most of the solutions described also highlight the
  862.       need for each TRD to develop policy on whether and under what
  863.       conditions to accept addresses that are not based on its own
  864.       address prefix, and how such non-local addresses will be treated.
  865.       For example, a somewhat conservative policy might be that non-
  866.       local IP address prefixes will be accepted from any attached leaf
  867.       routing domain, but not advertised to other TRDs.  In a less
  868.       conservative policy, a TRD might accept such non-local prefixes
  869.       and agree to exchange them with a defined set of other TRDs (this
  870.       set could be an a priori group of TRDs that have something in
  871.       common such as geographical location, or the result of an
  872.       agreement specific to the requesting leaf routing domain). Various
  873.       policies involve real costs to TRDs, which may be reflected in
  874.       those policies.
  875.  
  876. 5.5   Private Links
  877.  
  878.       The discussion up to this point concentrates on the relationship
  879.       between IP addresses and routing between various routing domains
  880.       over transit routing domains, where each transit routing domain
  881.       interconnects a large number of routing domains and offers a
  882.       more-or-less public service.
  883.  
  884.       However, there may also exist a number of links which interconnect
  885.       two routing domains in such a way, that usage of these links may
  886.       be limited to carrying traffic only between the two routing
  887.       domains.  We'll refer to such links as "private".
  888.  
  889.       For example, let's suppose that the XYZ corporation does a lot of
  890.       business with MBII. In this case, XYZ and MBII may contract with a
  891.       carrier to provide a private link between the two corporations,
  892.       where this link may only be used for packets whose source is
  893.       within one of the two corporations, and whose destination is
  894.       within the other of the two corporations. Finally, suppose that
  895.       the point-to-point link is connected between a single router
  896.       (router X) within XYZ corporation and a single router (router M)
  897.       within MBII. It is therefore necessary to configure router X to
  898.       know which addresses can be reached over this link (specifically,
  899.       all addresses reachable in MBII). Similarly, it is necessary to
  900.       configure router M to know which addresses can be reached over
  901.       this link (specifically, all addresses reachable in XYZ
  902.       Corporation).
  903.  
  904.  
  905.  
  906.  
  907. Rekhter & Li                                                   [Page 16]
  908.  
  909.  
  910. RFC 1518          CIDR Address Allocation Architecture    September 1993
  911.  
  912.  
  913.       The important observation to be made here is that the additional
  914.       connectivity due to such private links may be ignored for the
  915.       purpose of IP address allocation, and do not pose a problem for
  916.       routing. This is because the routing information associated with
  917.       such connectivity is not propagated throughout the Internet, and
  918.       therefore does not need to be collapsed into a TRD's prefix.
  919.  
  920.       In our example, let's suppose that the XYZ corporation has a
  921.       single connection to a regional, and has therefore uses the IP
  922.       address space from the space given to that regional.  Similarly,
  923.       let's suppose that MBII, as an international corporation with
  924.       connections to six different providers, has chosen the second
  925.       solution from Section 5.4, and therefore has obtained six
  926.       different address allocations. In this case, all addresses
  927.       reachable in the XYZ Corporation can be described by a single
  928.       address prefix (implying that router M only needs to be configured
  929.       with a single address prefix to represent the addresses reachable
  930.       over this link). All addresses reachable in MBII can be described
  931.       by six address prefixes (implying that router X needs to be
  932.       configured with six address prefixes to represent the addresses
  933.       reachable over the link).
  934.  
  935.       In some cases, such private links may be permitted to forward
  936.       traffic for a small number of other routing domains, such as
  937.       closely affiliated organizations. This will increase the
  938.       configuration requirements slightly. However, provided that the
  939.       number of organizations using the link is relatively small, then
  940.       this still does not represent a significant problem.
  941.  
  942.       Note that the relationship between routing and IP addressing
  943.       described in other sections of this paper is concerned with
  944.       problems in scaling caused by large, essentially public transit
  945.       routing domains which interconnect a large number of routing
  946.       domains.  However, for the purpose of IP address allocation,
  947.       private links which interconnect only a small number of private
  948.       routing domains do not pose a problem, and may be ignored. For
  949.       example, this implies that a single leaf routing domain which has
  950.       a single connection to a "public" backbone, plus a number of
  951.       private links to other leaf routing domains, can be treated as if
  952.       it were single-homed to the backbone for the purpose of IP address
  953.       allocation.  We expect that this is also another way of dealing
  954.       with multi-homed domains.
  955.  
  956. 5.6   Zero-Homed Routing Domains
  957.  
  958.       Currently, a very large number of organizations have internal
  959.       communications networks which are not connected to any service
  960.       providers.  Such organizations may, however, have a number of
  961.  
  962.  
  963.  
  964. Rekhter & Li                                                   [Page 17]
  965.  
  966.  
  967. RFC 1518          CIDR Address Allocation Architecture    September 1993
  968.  
  969.  
  970.       private links that they use for communications with other
  971.       organizations. Such organizations do not participate in global
  972.       routing, but are satisfied with reachability to those
  973.       organizations with which they have established private links.
  974.       These are referred to as zero-homed routing domains.
  975.  
  976.       Zero-homed routing domains can be considered as the degenerate
  977.       case of routing domains with private links, as discussed in the
  978.       previous section, and do not pose a problem for inter-domain
  979.       routing. As above, the routing information exchanged across the
  980.       private links sees very limited distribution, usually only to the
  981.       routing domain at the other end of the link. Thus, there are no
  982.       address abstraction requirements beyond those inherent in the
  983.       address prefixes exchanged across the private link.
  984.  
  985.       However, it is important that zero-homed routing domains use valid
  986.       globally unique IP addresses. Suppose that the zero-homed routing
  987.       domain is connected through a private link to a routing domain.
  988.       Further, this routing domain participates in an internet that
  989.       subscribes to the global IP addressing plan. This domain must be
  990.       able to distinguish between the zero-homed routing domain's IP
  991.       addresses and any other IP addresses that it may need to route to.
  992.       The only way this can be guaranteed is if the zero-homed routing
  993.       domain uses globally unique IP addresses.
  994.  
  995. 5.7   Continental aggregation
  996.  
  997.       Another level of hierarchy may also be used in this addressing
  998.       scheme to further reduce the amount of routing information
  999.       necessary for inter-continental routing.  Continental aggregation
  1000.       is useful because continental boundaries provide natural barriers
  1001.       to topological connection and administrative boundaries.  Thus, it
  1002.       presents a natural boundary for another level of aggregation of
  1003.       inter-domain routing information.  To make use of this, it is
  1004.       necessary that each continent be assigned an appropriate subset of
  1005.       the address space.  Providers (both direct and indirect) within
  1006.       that continent would allocate their addresses from this space.
  1007.       Note that there are numerous exceptions to this, in which a
  1008.       service provider (either direct or indirect) spans a continental
  1009.       division.  These exceptions can be handled similarly to multi-
  1010.       homed routing domains, as discussed above.
  1011.  
  1012.       Note that, in contrast to the case of providers, the aggregation
  1013.       of continental routing information may not be done on the
  1014.       continent to which the prefix is allocated.  The cost of inter-
  1015.       continental links (and especially trans-oceanic links) is very
  1016.       high.  If aggregation is performed on the "near" side of the link,
  1017.       then routing information about unreachable destinations within
  1018.  
  1019.  
  1020.  
  1021. Rekhter & Li                                                   [Page 18]
  1022.  
  1023.  
  1024. RFC 1518          CIDR Address Allocation Architecture    September 1993
  1025.  
  1026.  
  1027.       that continent can only reside on that continent.  Alternatively,
  1028.       if continental aggregation is done on the "far" side of an inter-
  1029.       continental link, the "far" end can perform the aggregation and
  1030.       inject it into continental routing.  This means that destinations
  1031.       which are part of the continental aggregation, but for which there
  1032.       is not a corresponding more specific prefix can be rejected before
  1033.       leaving the continent on which they originated.
  1034.  
  1035.       For example, suppose that Europe is assigned a prefix of
  1036.       <194.0.0.0 254.0.0.0>, such that European routing also contains
  1037.       the longer prefixes <194.1.0.0 255.255.0.0> and <194.2.0.0
  1038.       255.255.0.0>.  All of the longer European prefixes may be
  1039.       advertised across a trans-Atlantic link to North America.  The
  1040.       router in North America would then aggregate these routes, and
  1041.       only advertise the prefix <194.0.0.0 255.0.0.0> into North
  1042.       American routing.  Packets which are destined for 194.1.1.1 would
  1043.       traverse North American routing, but would encounter the North
  1044.       American router which performed the European aggregation.  If the
  1045.       prefix <194.1.0.0 255.255.0.0> is unreachable, the router would
  1046.       drop the packet and send an ICMP Unreachable without using the
  1047.       trans-Atlantic link.
  1048.  
  1049. 5.8   Transition Issues
  1050.  
  1051.       Allocation of IP addresses based on connectivity to TRDs is
  1052.       important to allow scaling of inter-domain routing to an internet
  1053.       containing millions of routing domains. However, such address
  1054.       allocation based on topology implies that in order to maximize the
  1055.       efficiency in routing gained by such allocation, certain changes
  1056.       in topology may suggest a change of address.
  1057.  
  1058.       Note that an address change need not happen immediately.  A domain
  1059.       which has changed service providers may still advertise its prefix
  1060.       through its new service provider.  Since upper levels in the
  1061.       routing hierarchy will perform routing based on the longest
  1062.       prefix, reachability is preserved, although the aggregation and
  1063.       scalability of the routing information has greatly diminished.
  1064.       Thus, a domain which does change its topology should change
  1065.       addresses as soon as convenient.  The timing and mechanics of such
  1066.       changes must be the result of agreements between the old service
  1067.       provider, the new provider, and the domain.
  1068.  
  1069.       This need to allow for change in addresses is a natural,
  1070.       inevitable consequence of routing data abstraction. The basic
  1071.       notion of routing data abstraction is that there is some
  1072.       correspondence between the address and where a system (i.e., a
  1073.       routing domain, subnetwork, or end system) is located. Thus if the
  1074.       system moves, in some cases the address will have to change. If it
  1075.  
  1076.  
  1077.  
  1078. Rekhter & Li                                                   [Page 19]
  1079.  
  1080.  
  1081. RFC 1518          CIDR Address Allocation Architecture    September 1993
  1082.  
  1083.  
  1084.       were possible to change the connectivity between routing domains
  1085.       without changing the addresses, then it would clearly be necessary
  1086.       to keep track of the location of that routing domain on an
  1087.       individual basis.
  1088.  
  1089.       In the short term, due to the rapid growth and increased
  1090.       commercialization of the Internet, it is possible that the
  1091.       topology may be relatively volatile. This implies that planning
  1092.       for address transition is very important. Fortunately, there are a
  1093.       number of steps which can be taken to help ease the effort
  1094.       required for address transition. A complete description of address
  1095.       transition issues is outside of the scope of this paper. However,
  1096.       a very brief outline of some transition issues is contained in
  1097.       this section.
  1098.  
  1099.       Also note that the possible requirement to transition addresses
  1100.       based on changes in topology imply that it is valuable to
  1101.       anticipate the future topology changes before finalizing a plan
  1102.       for address allocation. For example, in the case of a routing
  1103.       domain which is initially single-homed, but which is expecting to
  1104.       become multi-homed in the future, it may be advantageous to assign
  1105.       IP addresses based on the anticipated future topology.
  1106.  
  1107.       In general, it will not be practical to transition the IP
  1108.       addresses assigned to a routing domain in an instantaneous "change
  1109.       the address at midnight" manner. Instead, a gradual transition is
  1110.       required in which both the old and the new addresses will remain
  1111.       valid for a limited period of time. During the transition period,
  1112.       both the old and new addresses are accepted by the end systems in
  1113.       the routing domain, and both old and new addresses must result in
  1114.       correct routing of packets to the destination.
  1115.  
  1116.       During the transition period, it is important that packets using
  1117.       the old address be forwarded correctly, even when the topology has
  1118.       changed.  This is facilitated by the use of "longest match"
  1119.       inter-domain routing.
  1120.  
  1121.       For example, suppose that the XYZ Corporation was previously
  1122.       connected only to the NorthSouthNet regional. The XYZ Corporation
  1123.       therefore went off to the NorthSouthNet administration and got an
  1124.       IP address prefix assignment based on the IP address prefix value
  1125.       assigned to the NorthSouthNet regional. However, for a variety of
  1126.       reasons, the XYZ Corporation decided to terminate its association
  1127.       with the NorthSouthNet, and instead connect directly to the
  1128.       NewCommercialNet public data network. Thus the XYZ Corporation now
  1129.       has a new address assignment under the IP address prefix assigned
  1130.       to the NewCommercialNet. The old address for the XYZ Corporation
  1131.       would seem to imply that traffic for the XYZ Corporation should be
  1132.  
  1133.  
  1134.  
  1135. Rekhter & Li                                                   [Page 20]
  1136.  
  1137.  
  1138. RFC 1518          CIDR Address Allocation Architecture    September 1993
  1139.  
  1140.  
  1141.       routed to the NorthSouthNet, which no longer has any direct
  1142.       connection with XYZ Corporation.
  1143.  
  1144.       If the old TRD (NorthSouthNet) and the new TRD (NewCommercialNet)
  1145.       are adjacent and cooperative, then this transition is easy to
  1146.       accomplish.  In this case, packets routed to the XYZ Corporation
  1147.       using the old address assignment could be routed to the
  1148.       NorthSouthNet, which would directly forward them to the
  1149.       NewCommercialNet, which would in turn forward them to XYZ
  1150.       Corporation. In this case only NorthSouthNet and NewCommercialNet
  1151.       need be aware of the fact that the old address refers to a
  1152.       destination which is no longer directly attached to NorthSouthNet.
  1153.  
  1154.       If the old TRD and the new TRD are not adjacent, then the
  1155.       situation is a bit more complex, but there are still several
  1156.       possible ways to forward traffic correctly.
  1157.  
  1158.       If the old TRD and the new TRD are themselves connected by other
  1159.       cooperative transit routing domains, then these intermediate
  1160.       domains may agree to forward traffic for XYZ correctly. For
  1161.       example, suppose that NorthSouthNet and NewCommercialNet are not
  1162.       directly connected, but that they are both directly connected to
  1163.       the BBNet backbone.  In this case, all three of NorthSouthNet,
  1164.       NewCommercialNet, and the BBNet backbone would need to maintain a
  1165.       special entry for XYZ corporation so that traffic to XYZ using the
  1166.       old address allocation would be forwarded via NewCommercialNet.
  1167.       However, other routing domains would not need to be aware of the
  1168.       new location for XYZ Corporation.
  1169.  
  1170.       Suppose that the old TRD and the new TRD are separated by a non-
  1171.       cooperative routing domain, or by a long path of routing domains.
  1172.       In this case, the old TRD could encapsulate traffic to XYZ
  1173.       Corporation in order to deliver such packets to the correct
  1174.       backbone.
  1175.  
  1176.       Also, those locations which do a significant amount of business
  1177.       with XYZ Corporation could have a specific entry in their routing
  1178.       tables added to ensure optimal routing of packets to XYZ. For
  1179.       example, suppose that another commercial backbone
  1180.       "OldCommercialNet" has a large number of customers which exchange
  1181.       traffic with XYZ Corporation, and that this third TRD is directly
  1182.       connected to both NorthSouthNet and NewCommercialNet. In this case
  1183.       OldCommercialNet will continue to have a single entry in its
  1184.       routing tables for other traffic destined for NorthSouthNet, but
  1185.       may choose to add one additional (more specific) entry to ensure
  1186.       that packets sent to XYZ Corporation's old address are routed
  1187.       correctly.
  1188.  
  1189.  
  1190.  
  1191.  
  1192. Rekhter & Li                                                   [Page 21]
  1193.  
  1194.  
  1195. RFC 1518          CIDR Address Allocation Architecture    September 1993
  1196.  
  1197.  
  1198.       Whichever method is used to ease address transition, the goal is
  1199.       that knowledge relating XYZ to its old address that is held
  1200.       throughout the global internet would eventually be replaced with
  1201.       the new information.  It is reasonable to expect this to take
  1202.       weeks or months and will be accomplished through the distributed
  1203.       directory system.  Discussion of the directory, along with other
  1204.       address transition techniques such as automatically informing the
  1205.       source of a changed address, are outside the scope of this paper.
  1206.  
  1207.       Another significant transition difficulty is the establishment of
  1208.       appropriate addressing authorities.  In order not to delay the
  1209.       deployment of this addressing scheme, if no authority has been
  1210.       created at an appropriate level, a higher level authority may
  1211.       allocated addresses instead of the lower level authority.  For
  1212.       example, suppose that the continental authority has been allocated
  1213.       a portion of the address space and that the service providers
  1214.       present on that continent are clear, but have not yet established
  1215.       their addressing authority.  The continental authority may foresee
  1216.       (possibly with information from the provider) that the provider
  1217.       will eventually create an authority.  The continental authority
  1218.       may then act on behalf of that provider until the provider is
  1219.       prepared to assume its addressing authority duties.
  1220.  
  1221.       Finally, it is important to emphasize, that a change of addresses
  1222.       due to changes in topology is not mandated by this document.  The
  1223.       continental level addressing hierarchy, as discussed in Section
  1224.       5.7, is intended to handle the aggregation of reachability
  1225.       information in the cases where addresses do not directly reflect
  1226.       the connectivity between providers and subscribers.
  1227.  
  1228. 5.9   Interaction with Policy Routing
  1229.  
  1230.       We assume that any inter-domain routing protocol will have
  1231.       difficulty trying to aggregate multiple destinations with
  1232.       dissimilar policies.  At the same time, the ability to aggregate
  1233.       routing information while not violating routing policies is
  1234.       essential. Therefore, we suggest that address allocation
  1235.       authorities attempt to allocate addresses so that aggregates of
  1236.       destinations with similar policies can be easily formed.
  1237.  
  1238. 6.  Recommendations
  1239.  
  1240.       We anticipate that the current exponential growth of the Internet
  1241.       will continue or accelerate for the foreseeable future. In
  1242.       addition, we anticipate a rapid internationalization of the
  1243.       Internet. The ability of routing to scale is dependent upon the
  1244.       use of data abstraction based on hierarchical IP addresses. As
  1245.       CIDR [1] is introduced in the Internet, it is therefore essential
  1246.  
  1247.  
  1248.  
  1249. Rekhter & Li                                                   [Page 22]
  1250.  
  1251.  
  1252. RFC 1518          CIDR Address Allocation Architecture    September 1993
  1253.  
  1254.  
  1255.       to choose a hierarchical structure for IP addresses with great
  1256.       care.
  1257.  
  1258.       It is in the best interests of the internetworking community that
  1259.       the cost of operations be kept to a minimum where possible. In the
  1260.       case of IP address allocation, this again means that routing data
  1261.       abstraction must be encouraged.
  1262.  
  1263.       In order for data abstraction to be possible, the assignment of IP
  1264.       addresses must be accomplished in a manner which is consistent
  1265.       with the actual physical topology of the Internet. For example, in
  1266.       those cases where organizational and administrative boundaries are
  1267.       not related to actual network topology, address assignment based
  1268.       on such organization boundaries is not recommended.
  1269.  
  1270.       The intra-domain routing protocols allow for information
  1271.       abstraction to be maintained within a domain.  For zero-homed and
  1272.       single-homed routing domains (which are expected to remain zero-
  1273.       homed or single-homed), we recommend that the IP addresses
  1274.       assigned within a single routing domain use a single address
  1275.       prefix assigned to that domain.  Specifically, this allows the set
  1276.       of all IP addresses reachable within a single domain to be fully
  1277.       described via a single prefix.
  1278.  
  1279.       We anticipate that the total number of routing domains existing on
  1280.       a worldwide Internet to be great enough that additional levels of
  1281.       hierarchical data abstraction beyond the routing domain level will
  1282.       be necessary.
  1283.  
  1284.       In most cases, network topology will have a close relationship
  1285.       with national boundaries. For example, the degree of network
  1286.       connectivity will often be greater within a single country than
  1287.       between countries.  It is therefore appropriate to make specific
  1288.       recommendations based on national boundaries, with the
  1289.       understanding that there may be specific situations where these
  1290.       general recommendations need to be modified.
  1291.  
  1292. 6.1   Recommendations for an address allocation plan
  1293.  
  1294.       We anticipate that public interconnectivity between private
  1295.       routing domains will be provided by a diverse set of TRDs,
  1296.       including (but not necessarily limited to):
  1297.  
  1298.       - backbone networks (Alternet, ANSnet, CIX, EBone, PSI,
  1299.         SprintLink);
  1300.  
  1301.       - a number of regional or national networks; and,
  1302.  
  1303.  
  1304.  
  1305.  
  1306. Rekhter & Li                                                   [Page 23]
  1307.  
  1308.  
  1309. RFC 1518          CIDR Address Allocation Architecture    September 1993
  1310.  
  1311.  
  1312.       - a number of commercial Public Data Networks.
  1313.  
  1314.    These networks will not be interconnected in a strictly hierarchical
  1315.    manner (for example, there is expected to be direct connectivity
  1316.    between regionals, and all of these types of networks may have direct
  1317.    international connections).  However, the total number of such TRDs
  1318.    is expected to remain (for the foreseeable future) small enough to
  1319.    allow addressing of this set of TRDs via a flat address space. These
  1320.    TRDs will be used to interconnect a wide variety of routing domains,
  1321.    each of which may comprise a single corporation, part of a
  1322.    corporation, a university campus, a government agency, or other
  1323.    organizational unit.
  1324.  
  1325.    In addition, some private corporations may be expected to make use of
  1326.    dedicated private TRDs for communication within their own
  1327.    corporation.
  1328.  
  1329.    We anticipate that the great majority of routing domains will be
  1330.    attached to only one of the TRDs. This will permit hierarchical
  1331.    address aggregation based on TRD. We therefore strongly recommend
  1332.    that addresses be assigned hierarchically, based on address prefixes
  1333.    assigned to individual TRDs.
  1334.  
  1335.    To support continental aggregation of routes, we recommend that all
  1336.    addresses for TRDs which are wholly within a continent be taken from
  1337.    the continental prefix.
  1338.  
  1339.    For the proposed address allocation scheme, this implies that
  1340.    portions of IP address space should be assigned to each TRD
  1341.    (explicitly including the backbones and regionals). For those leaf
  1342.    routing domains which are connected to a single TRD, they should be
  1343.    assigned a prefix value from the address space assigned to that TRD.
  1344.  
  1345.    For routing domains which are not attached to any publically
  1346.    available TRD, there is not the same urgent need for hierarchical
  1347.    address abbreviation. We do not, therefore, make any additional
  1348.    recommendations for such "isolated" routing domains.  Where such
  1349.    domains are connected to other domains by private point-to-point
  1350.    links, and where such links are used solely for routing between the
  1351.    two domains that they interconnect, again no additional technical
  1352.    problems relating to address abbreviation is caused by such a link,
  1353.    and no specific additional recommendations are necessary.
  1354.  
  1355.    Further, in order to allow aggregation of IP addresses at national
  1356.    and continental boundaries into as few prefixes as possible, we
  1357.    further recommend that IP addresses allocated to routing domains
  1358.    should be assigned based on each routing domain's connectivity to
  1359.    national and continental Internet backbones.
  1360.  
  1361.  
  1362.  
  1363. Rekhter & Li                                                   [Page 24]
  1364.  
  1365.  
  1366. RFC 1518          CIDR Address Allocation Architecture    September 1993
  1367.  
  1368.  
  1369. 6.2   Recommendations for Multi-Homed Routing Domains
  1370.  
  1371.    There are several possible ways that these multi-homed routing
  1372.    domains may be handled, as described in Section 5.4.  Each of these
  1373.    methods vary with respect to the amount of information that must be
  1374.    maintained for inter-domain routing and also with respect to the
  1375.    inter-domain routes. In addition, the organization that will bear the
  1376.    brunt of this cost varies with the possible solutions. For example,
  1377.    the solutions vary with respect to:
  1378.  
  1379.       - resources used within routers within the TRDs;
  1380.  
  1381.       - administrative cost on TRD personnel; and,
  1382.  
  1383.       - difficulty of configuration of policy-based inter-domain routing
  1384.         information within leaf routing domains.
  1385.  
  1386.    Also, the solution used may affect the actual routes which packets
  1387.    follow, and may effect the availability of backup routes when the
  1388.    primary route fails.
  1389.  
  1390.    For these reasons it is not possible to mandate a single solution for
  1391.    all situations. Rather, economic considerations will require a
  1392.    variety of solutions for different routing domains, service
  1393.    providers, and backbones.
  1394.  
  1395. 6.3   Recommendations for the Administration of IP addresses
  1396.  
  1397.    A companion document [3] provides recommendations for the
  1398.    administrations of IP addresses.
  1399.  
  1400. 7.  Acknowledgments
  1401.  
  1402.    The authors would like to acknowledge the substantial contributions
  1403.    made by the authors of RFC 1237 [2], Richard Colella, Ella Gardner,
  1404.    and Ross Callon.  The significant concepts (and a large portion of
  1405.    the text) in this document are taken directly from their work.
  1406.  
  1407.    The authors would like to acknowledge the substantial contributions
  1408.    made by the members of the following two groups, the Federal
  1409.    Engineering Planning Group (FEPG) and the International Engineering
  1410.    Planning Group (IEPG). This document also reflects many concepts
  1411.    expressed at the IETF Addressing BOF which took place in Cambridge,
  1412.    MA in July 1992.
  1413.  
  1414.    We would also like to thank Peter Ford (Los Alamos National
  1415.    Laboratory), Elise Gerich (MERIT), Steve Kent (BBN), Barry Leiner
  1416.    (ADS), Jon Postel (ISI), Bernhard Stockman (NORDUNET/SUNET), Claudio
  1417.  
  1418.  
  1419.  
  1420. Rekhter & Li                                                   [Page 25]
  1421.  
  1422.  
  1423. RFC 1518          CIDR Address Allocation Architecture    September 1993
  1424.  
  1425.  
  1426.    Topolcic (CNRI), and Kannan Varadhan (OARnet) for their review and
  1427.    constructive comments.
  1428.  
  1429. 8.  References
  1430.  
  1431.    [1] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an
  1432.        Address Assignment and Aggregation Strategy", RFC 1338, BARRNet,
  1433.        cicso, Merit, OARnet, June 1992.
  1434.  
  1435.    [2] Colella, R., Gardner, E, and R. Callon, "Guidelines for OSI NSAP
  1436.        Allocation in the Internet", RFC 1237, JuNIST, Mitre, DEC, July
  1437.        1991.
  1438.  
  1439.    [3] Gerich, E., "Guidelines for Management of IP Address Space", RFC
  1440.        1466, Merit, May 1993.
  1441.  
  1442.    [4] Cerf, V., "IAB Recommended Policy on Distributing Internet
  1443.        Identifier Assignment and IAB Recommended Policy Change to
  1444.        Internet "Connected" Status", RFC 1174, CNRI, August 1990.
  1445.  
  1446. 9.  Security Considerations
  1447.  
  1448.    Security issues are not discussed in this memo.
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458.  
  1459.  
  1460.  
  1461.  
  1462.  
  1463.  
  1464.  
  1465.  
  1466.  
  1467.  
  1468.  
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474.  
  1475.  
  1476.  
  1477. Rekhter & Li                                                   [Page 26]
  1478.  
  1479.  
  1480. RFC 1518          CIDR Address Allocation Architecture    September 1993
  1481.  
  1482.  
  1483. 10.  Authors' Addresses
  1484.  
  1485.    Yakov Rekhter
  1486.    T.J. Watson Research Center, IBM Corporation
  1487.    P.O. Box 218
  1488.    Yorktown Heights, NY 10598
  1489.  
  1490.    Phone:  (914) 945-3896
  1491.    EMail:  yakov@watson.ibm.com
  1492.  
  1493.  
  1494.    Tony Li
  1495.    cisco Systems, Inc.
  1496.    1525 O'Brien Drive
  1497.    Menlo Park, CA 94025
  1498.  
  1499.    EMail: tli@cisco.com
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.  
  1523.  
  1524.  
  1525.  
  1526.  
  1527.  
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533.  
  1534. Rekhter & Li                                                   [Page 27]
  1535.  
  1536.  
  1537.  
  1538.  
  1539.