rfc1518.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,251 行 · 第 1/5 页

Rekhter & Li                                                    [Page 9]

RFC 1518          CIDR Address Allocation Architecture    September 1993


      times 4 providers).  If each client takes its addresses from a
      single address space then the total number of entries would be
      only 100. Finally, if all the clients take their addresses from
      the same address space then the total number of entries would be
      only 1.

      We expect that in the near term the number of routing domains in
      the Internet will grow to the point that it will be infeasible to
      route on the basis of a flat field of routing domains. It will
      therefore be essential to provide a greater degree of information
      abstraction.

      Direct providers may give part of their address space (prefixes)
      to leaf domains, based on an address prefix given to the provider.
      This results in direct providers advertising to backbones a small
      fraction of the number of address prefixes that would be necessary
      if they enumerated the individual prefixes of the leaf routing
      domains.  This represents a significant savings given the expected
      scale of global internetworking.

      Are leaf routing domains willing to accept prefixes derived from
      the direct providers? In the supplier/consumer model, the direct
      provider is offering connectivity as the service, priced according
      to its costs of operation. This includes the "price" of obtaining
      service from one or more indirect providers (e.g., backbones). In
      general, indirect providers will want to handle as few address
      prefixes as possible to keep costs low. In the Internet
      environment, which does not operate as a typical marketplace, leaf
      routing domains must be sensitive to the resource constraints of
      the providers (both direct and indirect). The efficiencies gained
      in inter-domain routing clearly warrant the adoption of IP address
      prefixes derived from the IP address space of the providers.

      The mechanics of this scenario are straightforward. Each direct
      provider is given a unique small set of IP address prefixes, from
      which its attached leaf routing domains can allocates slightly
      longer IP address prefixes.  For example assume that NIST is a
      leaf routing domain whose inter-domain link is via SURANet. If
      SURANet is assigned an unique IP address prefix <198.1.0.0
      255.255.0.0>, NIST could use a unique IP prefix of <198.1.0.0
      255.255.240.0>.

      If a direct service provider is connected to another provider(s)
      (either direct or indirect) via multiple attachment points, then
      in certain cases it may be advantageous to the direct provider to
      exert a certain degree of control over the coupling between the
      attachment points and flow of the traffic destined to a particular
      subscriber.  Such control can be facilitated by first partitioning



Rekhter & Li                                                   [Page 10]

RFC 1518          CIDR Address Allocation Architecture    September 1993


      all the subscribers into groups, such that traffic destined to all
      the subscribers within a group should flow through a particular
      attachment point. Once the partitioning is done, the address space
      of the provider is subdivided along the group boundaries. A leaf
      routing domain that is willing to accept prefixes derived from its
      direct provider gets a prefix from the provider's address space
      subdivision associated with the group the domain belongs to. Note
      that the advertisement by the direct provider of the routing
      information associated with each subdivision must be done with
      care to ensure that such an advertisement would not result in a
      global distribution of separate reachability information
      associated with each subdivision, unless such distribution is
      warranted for some other purposes (e.g., supporting certain
      aspects of policy-based routing).

5.3.2   Indirect Providers (Backbones)

      There does not appear to be a strong case for direct providers to
      take their address spaces from the the IP space of an indirect
      provider (e.g., backbone). The benefit in routing data abstraction
      is relatively small. The number of direct providers today is in
      the tens and an order of magnitude increase would not cause an
      undue burden on the backbones.  Also, it may be expected that as
      time goes by there will be increased direct interconnection of the
      direct providers, leaf routing domains directly attached to the
      backbones, and international links directly attached to the
      providers. Under these circumstances, the distinction between
      direct and indirect providers may become blurred.

      An additional factor that discourages allocation of IP addresses
      from a backbone prefix is that the backbones and their attached
      providers are perceived as being independent. Providers may take
      their long- haul service from one or more backbones, or may switch
      backbones should a more cost-effective service be provided
      elsewhere. Having IP addresses derived from a backbone is
      inconsistent with the nature of the relationship.

5.4   Multi-homed Routing Domains

      The discussions in Section 5.3 suggest methods for allocating IP
      addresses based on direct or indirect provider connectivity. This
      allows a great deal of information reduction to be achieved for
      those routing domains which are attached to a single TRD. In
      particular, such routing domains may select their IP addresses
      from a space delegated to them by the direct provider. This allows
      the provider, when announcing the addresses that it can reach to
      other providers, to use a single address prefix to describe a
      large number of IP addresses corresponding to multiple routing



Rekhter & Li                                                   [Page 11]

RFC 1518          CIDR Address Allocation Architecture    September 1993


      domains.

      However, there are additional considerations for routing domains
      which are attached to multiple providers. Such "multi-homed"
      routing domains may, for example, consist of single-site campuses
      and companies which are attached to multiple backbones, large
      organizations which are attached to different providers at
      different locations in the same country, or multi-national
      organizations which are attached to backbones in a variety of
      countries worldwide. There are a number of possible ways to deal
      with these multi-homed routing domains.

      One possible solution is for each multi-homed organization to
      obtain its IP address space independently from the providers to
      which it is attached.  This allows each multi-homed organization
      to base its IP assignments on a single prefix, and to thereby
      summarize the set of all IP addresses reachable within that
      organization via a single prefix.  The disadvantage of this
      approach is that since the IP address for that organization has no
      relationship to the addresses of any particular TRD, the TRDs to
      which this organization is attached will need to advertise the
      prefix for this organization to other providers.  Other providers
      (potentially worldwide) will need to maintain an explicit entry
      for that organization in their routing tables.

      For example, suppose that a very large North American company
      "Mega Big International Incorporated" (MBII) has a fully
      interconnected internal network and is assigned a single prefix as
      part of the North American prefix.  It is likely that outside of
      North America, a single entry may be maintained in routing tables
      for all North American destinations.  However, within North
      America, every provider will need to maintain a separate address
      entry for MBII. If MBII is in fact an international corporation,
      then it may be necessary for every provider worldwide to maintain
      a separate entry for MBII (including backbones to which MBII is
      not attached). Clearly this may be acceptable if there are a small
      number of such multi-homed routing domains, but would place an
      unacceptable load on routers within backbones if all organizations
      were to choose such address assignments.  This solution may not
      scale to internets where there are many hundreds of thousands of
      multi-homed organizations.

      A second possible approach would be for multi-homed organizations
      to be assigned a separate IP address space for each connection to
      a TRD, and to assign a single prefix to some subset of its
      domain(s) based on the closest interconnection point. For example,
      if MBII had connections to two providers in the U.S. (one east
      coast, and one west coast), as well as three connections to



Rekhter & Li                                                   [Page 12]

RFC 1518          CIDR Address Allocation Architecture    September 1993


      national backbones in Europe, and one in the far east, then MBII
      may make use of six different address prefixes.  Each part of MBII
      would be assigned a single address prefix based on the nearest
      connection.

      For purposes of external routing of traffic from outside MBII to a
      destination inside of MBII, this approach works similarly to
      treating MBII as six separate organizations. For purposes of
      internal routing, or for routing traffic from inside of MBII to a
      destination outside of MBII, this approach works the same as the
      first solution.

      If we assume that incoming traffic (coming from outside of MBII,
      with a destination within MBII) is always to enter via the nearest
      point to the destination, then each TRD which has a connection to
      MBII needs to announce to other TRDs the ability to reach only
      those parts of MBII whose address is taken from its own address
      space. This implies that no additional routing information needs
      to be exchanged between TRDs, resulting in a smaller load on the
      inter-domain routing tables maintained by TRDs when compared to
      the first solution. This solution therefore scales better to
      extremely large internets containing very large numbers of multi-
      homed organizations.

      One problem with the second solution is that backup routes to
      multi-homed organizations are not automatically maintained. With
      the first solution, each TRD, in announcing the ability to reach
      MBII, specifies that it is able to reach all of the hosts within
      MBII. With the second solution, each TRD announces that it can
      reach all of the hosts based on its own address prefix, which only
      includes some of the hosts within MBII. If the connection between
      MBII and one particular TRD were severed, then the hosts within
      MBII with addresses based on that TRD would become unreachable via
      inter-domain routing. The impact of this problem can be reduced
      somewhat by maintenance of additional information within routing
      tables, but this reduces the scaling advantage of the second
      approach.

      The second solution also requires that when external connectivity
      changes, internal addresses also change.

      Also note that this and the previous approach will tend to cause
      packets to take different routes. With the first approach, packets
      from outside of MBII destined for within MBII will tend to enter
      via the point which is closest to the source (which will therefore
      tend to maximize the load on the networks internal to MBII). With
      the second solution, packets from outside destined for within MBII
      will tend to enter via the point which is closest to the



Rekhter & Li                                                   [Page 13]

RFC 1518          CIDR Address Allocation Architecture    September 1993


      destination (which will tend to minimize the load on the networks
      within MBII, and maximize the load on the TRDs).

      These solutions also have different effects on policies. For
      example, suppose that country "X" has a law that traffic from a
      source within country X to a destination within country X must at
      all times stay entirely within the country. With the first
      solution, it is not possible to determine from the destination
      address whether or not the destination is within the country. With
      the second solution, a separate address may be assigned to those
      hosts which are within country X, thereby allowing routing
      policies to be followed.  Similarly, suppose that "Little Small
      Company" (LSC) has a policy that its packets may never be sent to
      a destination that is within MBII. With either solution, the
      routers within LSC may be configured to discard any traffic that
      has a destination within MBII's address space. However, with the
      first solution this requires one entry; with the second it
      requires many entries and may be impossible as a practical matter.