rfc1518.txt

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

      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
      leaving the continent on which they originated.

      For example, suppose that Europe is assigned a prefix of
      <194.0.0.0 254.0.0.0>, such that European routing also contains
      the longer prefixes <194.1.0.0 255.255.0.0> and <194.2.0.0
      255.255.0.0>.  All of the longer European prefixes may be
      advertised across a trans-Atlantic link to North America.  The
      router in North America would then aggregate these routes, and
      only advertise the prefix <194.0.0.0 255.0.0.0> into North
      American routing.  Packets which are destined for 194.1.1.1 would
      traverse North American routing, but would encounter the North
      American router which performed the European aggregation.  If the
      prefix <194.1.0.0 255.255.0.0> is unreachable, the router would
      drop the packet and send an ICMP Unreachable without using the
      trans-Atlantic link.

5.8   Transition Issues

      Allocation of IP addresses based on connectivity to TRDs is
      important to allow scaling of inter-domain routing to an internet
      containing millions of routing domains. However, such address
      allocation based on topology implies that in order to maximize the
      efficiency in routing gained by such allocation, certain changes
      in topology may suggest a change of address.

      Note that an address change need not happen immediately.  A domain
      which has changed service providers may still advertise its prefix
      through its new service provider.  Since upper levels in the
      routing hierarchy will perform routing based on the longest
      prefix, reachability is preserved, although the aggregation and
      scalability of the routing information has greatly diminished.
      Thus, a domain which does change its topology should change
      addresses as soon as convenient.  The timing and mechanics of such
      changes must be the result of agreements between the old service
      provider, the new provider, and the domain.

      This need to allow for change in addresses is a natural,
      inevitable consequence of routing data abstraction. The basic
      notion of routing data abstraction is that there is some
      correspondence between the address and where a system (i.e., a
      routing domain, subnetwork, or end system) is located. Thus if the
      system moves, in some cases the address will have to change. If it



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


      were possible to change the connectivity between routing domains
      without changing the addresses, then it would clearly be necessary
      to keep track of the location of that routing domain on an
      individual basis.

      In the short term, due to the rapid growth and increased
      commercialization of the Internet, it is possible that the
      topology may be relatively volatile. This implies that planning
      for address transition is very important. Fortunately, there are a
      number of steps which can be taken to help ease the effort
      required for address transition. A complete description of address
      transition issues is outside of the scope of this paper. However,
      a very brief outline of some transition issues is contained in
      this section.

      Also note that the possible requirement to transition addresses
      based on changes in topology imply that it is valuable to
      anticipate the future topology changes before finalizing a plan
      for address allocation. For example, in the case of a routing
      domain which is initially single-homed, but which is expecting to
      become multi-homed in the future, it may be advantageous to assign
      IP addresses based on the anticipated future topology.

      In general, it will not be practical to transition the IP
      addresses assigned to a routing domain in an instantaneous "change
      the address at midnight" manner. Instead, a gradual transition is
      required in which both the old and the new addresses will remain
      valid for a limited period of time. During the transition period,
      both the old and new addresses are accepted by the end systems in
      the routing domain, and both old and new addresses must result in
      correct routing of packets to the destination.

      During the transition period, it is important that packets using
      the old address be forwarded correctly, even when the topology has
      changed.  This is facilitated by the use of "longest match"
      inter-domain routing.

      For example, suppose that the XYZ Corporation was previously
      connected only to the NorthSouthNet regional. The XYZ Corporation
      therefore went off to the NorthSouthNet administration and got an
      IP address prefix assignment based on the IP address prefix value
      assigned to the NorthSouthNet regional. However, for a variety of
      reasons, the XYZ Corporation decided to terminate its association
      with the NorthSouthNet, and instead connect directly to the
      NewCommercialNet public data network. Thus the XYZ Corporation now
      has a new address assignment under the IP address prefix assigned
      to the NewCommercialNet. The old address for the XYZ Corporation
      would seem to imply that traffic for the XYZ Corporation should be



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


      routed to the NorthSouthNet, which no longer has any direct
      connection with XYZ Corporation.

      If the old TRD (NorthSouthNet) and the new TRD (NewCommercialNet)
      are adjacent and cooperative, then this transition is easy to
      accomplish.  In this case, packets routed to the XYZ Corporation
      using the old address assignment could be routed to the
      NorthSouthNet, which would directly forward them to the
      NewCommercialNet, which would in turn forward them to XYZ
      Corporation. In this case only NorthSouthNet and NewCommercialNet
      need be aware of the fact that the old address refers to a
      destination which is no longer directly attached to NorthSouthNet.

      If the old TRD and the new TRD are not adjacent, then the
      situation is a bit more complex, but there are still several
      possible ways to forward traffic correctly.

      If the old TRD and the new TRD are themselves connected by other
      cooperative transit routing domains, then these intermediate
      domains may agree to forward traffic for XYZ correctly. For
      example, suppose that NorthSouthNet and NewCommercialNet are not
      directly connected, but that they are both directly connected to
      the BBNet backbone.  In this case, all three of NorthSouthNet,
      NewCommercialNet, and the BBNet backbone would need to maintain a
      special entry for XYZ corporation so that traffic to XYZ using the
      old address allocation would be forwarded via NewCommercialNet.
      However, other routing domains would not need to be aware of the
      new location for XYZ Corporation.

      Suppose that the old TRD and the new TRD are separated by a non-
      cooperative routing domain, or by a long path of routing domains.
      In this case, the old TRD could encapsulate traffic to XYZ
      Corporation in order to deliver such packets to the correct
      backbone.

      Also, those locations which do a significant amount of business
      with XYZ Corporation could have a specific entry in their routing
      tables added to ensure optimal routing of packets to XYZ. For
      example, suppose that another commercial backbone
      "OldCommercialNet" has a large number of customers which exchange
      traffic with XYZ Corporation, and that this third TRD is directly
      connected to both NorthSouthNet and NewCommercialNet. In this case
      OldCommercialNet will continue to have a single entry in its
      routing tables for other traffic destined for NorthSouthNet, but
      may choose to add one additional (more specific) entry to ensure
      that packets sent to XYZ Corporation's old address are routed
      correctly.




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


      Whichever method is used to ease address transition, the goal is
      that knowledge relating XYZ to its old address that is held
      throughout the global internet would eventually be replaced with
      the new information.  It is reasonable to expect this to take
      weeks or months and will be accomplished through the distributed
      directory system.  Discussion of the directory, along with other
      address transition techniques such as automatically informing the
      source of a changed address, are outside the scope of this paper.

      Another significant transition difficulty is the establishment of
      appropriate addressing authorities.  In order not to delay the
      deployment of this addressing scheme, if no authority has been
      created at an appropriate level, a higher level authority may
      allocated addresses instead of the lower level authority.  For
      example, suppose that the continental authority has been allocated
      a portion of the address space and that the service providers
      present on that continent are clear, but have not yet established
      their addressing authority.  The continental authority may foresee
      (possibly with information from the provider) that the provider
      will eventually create an authority.  The continental authority
      may then act on behalf of that provider until the provider is
      prepared to assume its addressing authority duties.

      Finally, it is important to emphasize, that a change of addresses
      due to changes in topology is not mandated by this document.  The
      continental level addressing hierarchy, as discussed in Section
      5.7, is intended to handle the aggregation of reachability
      information in the cases where addresses do not directly reflect
      the connectivity between providers and subscribers.

5.9   Interaction with Policy Routing

      We assume that any inter-domain routing protocol will have
      difficulty trying to aggregate multiple destinations with
      dissimilar policies.  At the same time, the ability to aggregate
      routing information while not violating routing policies is
      essential. Therefore, we suggest that address allocation
      authorities attempt to allocate addresses so that aggregates of
      destinations with similar policies can be easily formed.

6.  Recommendations

      We anticipate that the current exponential growth of the Internet
      will continue or accelerate for the foreseeable future. In
      addition, we anticipate a rapid internationalization of the
      Internet. The ability of routing to scale is dependent upon the
      use of data abstraction based on hierarchical IP addresses. As
      CIDR [1] is introduced in the Internet, it is therefore essential



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


      to choose a hierarchical structure for IP addresses with great
      care.

      It is in the best interests of the internetworking community that
      the cost of operations be kept to a minimum where possible. In the
      case of IP address allocation, this again means that routing data
      abstraction must be encouraged.

      In order for data abstraction to be possible, the assignment of IP
      addresses must be accomplished in a manner which is consistent
      with the actual physical topology of the Internet. For example, in
      those cases where organizational and administrative boundaries are
      not related to actual network topology, address assignment b