rfc1518.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      organizations have deployed their own backbone. For example, lets
      suppose that the U.S. National Widget Manufacturers and
      Researchers have set up a U.S.-wide backbone, which is used by
      corporations who manufacture widgets, and certain universities
      which are known for their widget research efforts. We can expect
      that the various organizations which are in the widget group will
      run their internal networks as separate routing domains, and most
      of them will also be attached to other TRDs (since most of the
      organizations involved in widget manufacture and research will
      also be involved in other activities). We can therefore expect
      that many or most of the organizations in the widget group are
      dual-homed, with one attachment for widget-associated
      communications and the other attachment for other types of
      communications. Let's also assume that the total number of
      organizations involved in the widget group is small enough that it
      is reasonable to maintain a routing table containing one entry per
      organization, but that they are distributed throughout a larger



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


      internet with many millions of (mostly not widget-associated)
      routing domains.

      With the third approach, each multi-homed organization in the
      widget group would make use of an address assignment based on its
      other attachment(s) to TRDs (the attachments not associated with
      the widget group). The widget backbone would need to maintain
      routes to the routing domains associated with the various member
      organizations.  Similarly, all members of the widget group would
      need to maintain a table of routes to the other members via the
      widget backbone.  However, since the widget backbone does not
      inform other general worldwide TRDs of what addresses it can reach
      (since the backbone is not intended for use by other outside
      organizations), the relatively large set of routing prefixes needs
      to be maintained only in a limited number of places. The addresses
      assigned to the various organizations which are members of the
      widget group would provide a "default route" via each members
      other attachments to TRDs, while allowing communications within
      the widget group to use the preferred path.

      A fourth solution involves assignment of a particular address
      prefix for routing domains which are attached to precisely two (or
      more) specific routing domains. For example, suppose that there
      are two providers "SouthNorthNet" and "NorthSouthNet" which have a
      very large number of customers in common (i.e., there are a large
      number of routing domains which are attached to both). Rather than
      getting two address prefixes these organizations could obtain
      three prefixes.  Those routing domains which are attached to
      NorthSouthNet but not attached to SouthNorthNet obtain an address
      assignment based on one of the prefixes. Those routing domains
      which are attached to SouthNorthNet but not to NorthSouthNet would
      obtain an address based on the second prefix. Finally, those
      routing domains which are multi-homed to both of these networks
      would obtain an address based on the third prefix.  Each of these
      two TRDs would then advertise two prefixes to other TRDs, one
      prefix for leaf routing domains attached to it only, and one
      prefix for leaf routing domains attached to both.

      This fourth solution is likely to be important when use of public
      data networks becomes more common. In particular, it is likely
      that at some point in the future a substantial percentage of all
      routing domains will be attached to public data networks. In this
      case, nearly all government-sponsored networks (such as some
      current regionals) may have a set of customers which overlaps
      substantially with the public networks.

      There are therefore a number of possible solutions to the problem
      of assigning IP addresses to multi-homed routing domains. Each of



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


      these solutions has very different advantages and disadvantages.
      Each solution places a different real (i.e., financial) cost on
      the multi-homed organizations, and on the TRDs (including those to
      which the multi-homed organizations are not attached).

      In addition, most of the solutions described also highlight the
      need for each TRD to develop policy on whether and under what
      conditions to accept addresses that are not based on its own
      address prefix, and how such non-local addresses will be treated.
      For example, a somewhat conservative policy might be that non-
      local IP address prefixes will be accepted from any attached leaf
      routing domain, but not advertised to other TRDs.  In a less
      conservative policy, a TRD might accept such non-local prefixes
      and agree to exchange them with a defined set of other TRDs (this
      set could be an a priori group of TRDs that have something in
      common such as geographical location, or the result of an
      agreement specific to the requesting leaf routing domain). Various
      policies involve real costs to TRDs, which may be reflected in
      those policies.

5.5   Private Links

      The discussion up to this point concentrates on the relationship
      between IP addresses and routing between various routing domains
      over transit routing domains, where each transit routing domain
      interconnects a large number of routing domains and offers a
      more-or-less public service.

      However, there may also exist a number of links which interconnect
      two routing domains in such a way, that usage of these links may
      be limited to carrying traffic only between the two routing
      domains.  We'll refer to such links as "private".

      For example, let's suppose that the XYZ corporation does a lot of
      business with MBII. In this case, XYZ and MBII may contract with a
      carrier to provide a private link between the two corporations,
      where this link may only be used for packets whose source is
      within one of the two corporations, and whose destination is
      within the other of the two corporations. Finally, suppose that
      the point-to-point link is connected between a single router
      (router X) within XYZ corporation and a single router (router M)
      within MBII. It is therefore necessary to configure router X to
      know which addresses can be reached over this link (specifically,
      all addresses reachable in MBII). Similarly, it is necessary to
      configure router M to know which addresses can be reached over
      this link (specifically, all addresses reachable in XYZ
      Corporation).




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


      The important observation to be made here is that the additional
      connectivity due to such private links may be ignored for the
      purpose of IP address allocation, and do not pose a problem for
      routing. This is because the routing information associated with
      such connectivity is not propagated throughout the Internet, and
      therefore does not need to be collapsed into a TRD's prefix.

      In our example, let's suppose that the XYZ corporation has a
      single connection to a regional, and has therefore uses the IP
      address space from the space given to that regional.  Similarly,
      let's suppose that MBII, as an international corporation with
      connections to six different providers, has chosen the second
      solution from Section 5.4, and therefore has obtained six
      different address allocations. In this case, all addresses
      reachable in the XYZ Corporation can be described by a single
      address prefix (implying that router M only needs to be configured
      with a single address prefix to represent the addresses reachable
      over this link). All addresses reachable in MBII can be described
      by six address prefixes (implying that router X needs to be
      configured with six address prefixes to represent the addresses
      reachable over the link).

      In some cases, such private links may be permitted to forward
      traffic for a small number of other routing domains, such as
      closely affiliated organizations. This will increase the
      configuration requirements slightly. However, provided that the
      number of organizations using the link is relatively small, then
      this still does not represent a significant problem.

      Note that the relationship between routing and IP addressing
      described in other sections of this paper is concerned with
      problems in scaling caused by large, essentially public transit
      routing domains which interconnect a large number of routing
      domains.  However, for the purpose of IP address allocation,
      private links which interconnect only a small number of private
      routing domains do not pose a problem, and may be ignored. For
      example, this implies that a single leaf routing domain which has
      a single connection to a "public" backbone, plus a number of
      private links to other leaf routing domains, can be treated as if
      it were single-homed to the backbone for the purpose of IP address
      allocation.  We expect that this is also another way of dealing
      with multi-homed domains.

5.6   Zero-Homed Routing Domains

      Currently, a very large number of organizations have internal
      communications networks which are not connected to any service
      providers.  Such organizations may, however, have a number of



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


      private links that they use for communications with other
      organizations. Such organizations do not participate in global
      routing, but are satisfied with reachability to those
      organizations with which they have established private links.
      These are referred to as zero-homed routing domains.

      Zero-homed routing domains can be considered as the degenerate
      case of routing domains with private links, as discussed in the
      previous section, and do not pose a problem for inter-domain
      routing. As above, the routing information exchanged across the
      private links sees very limited distribution, usually only to the
      routing domain at the other end of the link. Thus, there are no
      address abstraction requirements beyond those inherent in the
      address prefixes exchanged across the private link.

      However, it is important that zero-homed routing domains use valid
      globally unique IP addresses. Suppose that the zero-homed routing
      domain is connected through a private link to a routing domain.
      Further, this routing domain participates in an internet that
      subscribes to the global IP addressing plan. This domain must be
      able to distinguish between the zero-homed routing domain's IP
      addresses and any other IP addresses that it may need to route to.
      The only way this can be guaranteed is if the zero-homed routing
      domain uses globally unique IP addresses.

5.7   Continental aggregation

      Another level of hierarchy may also be used in this addressing
      scheme to further reduce the amount of routing information
      necessary for inter-continental routing.  Continental aggregation
      is useful because continental boundaries provide natural barriers
      to topological connection and administrative boundaries.  Thus, it
      presents a natural boundary for another level of aggregation of
      inter-domain routing information.  To make use of this, it is
      necessary that each continent be assigned an appropriate subset of
      the address space.  Providers (both direct and indirect) within
      that continent would allocate their addresses from this space.
      Note that there are numerous exceptions to this, in which a
      service provider (either direct or indirect) spans a continental
      division.  These exceptions can be handled similarly to multi-
      homed routing domains, as discussed above.

      Note that, in contrast to the case of providers, the aggregation
      of continental routing information may not be done on the
      continent to which the prefix is allocated.  The cost of inter-
      continental links (and especially trans-oceanic links) is very
      high.  If aggregation is performed on the "near" side of the link,
      then routing information about unreachable destinations within



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


      that continent can only reside on that continent.  Alternatively,
      if continental aggregation is done on the "far" side of an inter-
      continental link, the "far" end can perform the aggregation and
      inject it into continental routing.  This means that destinations
      which are part of the continental aggregation, but for which there
      is not a corresponding more specific prefix can be rejected before