rfc2008.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 732 行 · 第 1/3 页

Network Working Group                                      Y. Rekhter
Request for Comments: 2008                                      T. Li
BCP: 7                                                  Cisco Systems
Category: Best Current Practice                          October 1996


              Implications of Various Address Allocation
                     Policies for Internet Routing

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

IESG Note:

   The addressing constraints described in this document are largely the
   result of the interaction of existing router technology, address
   assignment, and architectural history.  After extensive review and
   discussion, the authors of this document, the IETF working group that
   reviewed it, and the IESG have concluded that there are no other
   currently deployable technologies available to overcome these
   limitations.  In the event that routing or router technology develops
   to the point that adequate routing aggregation can be achieved by
   other means or that routers can deal with larger routing and more
   dynamic tables, it may be appropriate to review these constraints.

1 Abstract

   IP unicast address allocation and management are essential
   operational functions for the Public Internet. The exact policies for
   IP unicast address allocation and management continue to be the
   subject of many discussions. Such discussions cannot be pursued in a
   vacuum - the participants must understand the technical issues and
   implications associated with various address allocation and
   management policies.

   The purpose of this document is to articulate certain relevant
   fundamental technical issues that must be considered in formulating
   unicast address allocation and management policies for the Public
   Internet, and to provide recommendations with respect to these
   policies.

   The major focus of this document is on two possible policies,
   "address ownership" and "address lending," and the technical
   implications of these policies for the Public Internet.  For the
   organizations that could provide reachability to a sufficiently large



Rekhter & Li             Best Current Practice                  [Page 1]

RFC 2008                                                    October 1996


   fraction of the total destinations in the Internet, and could express
   such reachability through a single IP address prefix the document
   suggests to use the "address ownership" policy. However, applying the
   "address ownership" policy to every individual site or organization
   that connects to the Internet results in a non-scalable routing.

   Consequently, this document also recomments that the "address
   lending" policy should be formally added to the set of address
   allocation policies in the Public Internet. The document also
   recommends that organizations that do not provide a sufficient degree
   of routing information aggregation, but wish to obtain access to the
   Internet routing services should be strongly encouraged to use this
   policy to gain access to the services.

2 On the intrinsic value of IP addresses

   Syntactically, the set of IPv4 unicast addresses is the (finite) set
   of integers in the range 0x00000000 - 0xDFFFFFFF. IP addresses are
   used for Network Layer (IP) routing. An IP address is the sole piece
   of information about the node injected into the routing system.

   The notable semantics of an IP unicast address is its ability to
   interact with the Public Internet routing service and thereby
   exchange data with the remainder of the Internet. In other words, for
   the Public Internet, it is the reachability of an IP address that
   gives it an intrinsic value. Observe, however, that IP addresses are
   used outside of the Public Internet. This document does not cover the
   value of addresses in other than the Public Internet context.

   The above implies that in the Public Internet it is the service
   environment (the Internet) and its continued operation, including its
   routing system, which gives an IP address its intrinsic value, rather
   than the inverse. Consequently, if the Public Internet routing system
   ceases to be operational, the service disappears, and the addresses
   cease to have any functional value in the Internet. At this point,
   for the Public Internet, all address allocation and management
   policies, including existing policies, are rendered meaningless.

3 Hierarchical routing and its implication on address allocation

   Hierarchical routing [Kleinrock 77] is a mechanism that improves the
   scaling properties of a routing system. It is the only proven
   mechanism for scaling routing to the current size of the Internet.

   Hierarchical routing requires that addresses be assigned to reflect
   the actual network topology. Hierarchical routing works by taking the
   set of addresses covered by a portion of the topology, and generating
   a single routing advertisement (route) for the entire set. Further,



Rekhter & Li             Best Current Practice                  [Page 2]

RFC 2008                                                    October 1996


   hierarchical routing allows this to be done recursively: multiple
   advertisements (routes) can be combined into a single advertisement
   (route). By exercising this recursion, the amount of information
   necessary to provide routing can be decreased substantially.

   A common example of hierarchical routing is the phone network, where
   country codes, area codes, exchanges, and finally subscriber lines
   are different levels in the hierarchy. In the phone network, a switch
   need not keep detailed routing information about every possible
   subscriber in a distant area code. Instead, the switch usually knows
   one routing entry for the entire area code.

   Notice that the effect on scaling is dramatic. If we look at the
   space complexity of the different schemes, the switch that knows
   about every subscriber in the world needs O(n) space for n worldwide
   subscribers.  Now consider the case of hierarchical routing. We can
   break n down into the number of subscribers in the local area (l),
   the other exchanges in the area code (e), the other area codes in the
   local country code (a) and other country codes (c). Using this
   notation, hierarchical routing has space complexity O(l + e + a + c).
   Notice that each of these factors is much, much less than n, and
   grows very slowly, if at all. This implies that a phone switch can be
   built today that has some hope of not running out of space when it is
   deployed.

   The fundamental property of hierarchical routing that makes this
   scalability possible is the ability to form abstractions: here, the
   ability to group subscribers into exchanges, area codes and country
   codes. Further, such abstractions must provide useful information for
   the ability to do routing. Some abstractions, such as the group of
   users with green phones, are not useful when it comes time to route a
   call.

   Since the information that the routing system really needs is the
   location of the address within the topology, for hierarchical
   routing, the useful abstraction must capture the topological location
   of an address within the network. In principle this could be
   accomplished in one of two ways.  Either (a) constrain the topology
   (and allowed topology changes) to match address assignment. Or, (b)
   avoid constraints on the topology (and topology changes), but require
   that as the topology changes, an entity's address change as well. The
   process of changing an entity's address is known as "renumbering."









Rekhter & Li             Best Current Practice                  [Page 3]

RFC 2008                                                    October 1996


4 Scaling the Internet routing system

   The enormous growth of the Public Internet places a heavy load on the
   Internet routing system. Before the introduction of CIDR the growth
   rate had doubled the size of the routing table roughly every nine
   months. Capacity of computer technology doubles roughly every 24
   months. Even if we could double the capacities of the routers in the
   Internet every 24 months, inevitably the size of the routing tables
   is going to exceed the limit of the routers. Therefore, to preserve
   uninterrupted continuous growth of the Public Internet, deploying
   mechanisms that contain the growth rate of the routing information is
   essential.

   Lacking mechanisms to contain the growth rate of the routing
   information, the growth of the Internet would have to be either
   limited or frozen, or the Internet routing system would become
   overloaded. The result of overloading routing is that the routing
   subsystem will fail: either equipment (routers) could not maintain
   enough routes to insure global connectivity, or providers will simply
   exclude certain routes to insure that other routes provide
   connectivity to particular sites. This document assumes that neither
   of the outcomes mentioned in this paragraph is acceptable.

   Classless Inter-Domain Routing (CIDR) [RFC1518, RFC1519] has been
   deployed since late 1992 in the Public Internet as the primary
   mechanism to contain the growth rate of the routing information -
   without CIDR the Internet routing system would have already
   collapsed. For example, in October 1995, within AlterNet (one of the
   major Internet Service Providers) there were 3194 routes. Thanks to
   aggregation, AlterNet advertised only 799 routes to the rest of the
   Internet - a saving of 2395 routes (75%) [Partan 95]. In October 1995
   the Internet Routing Registry (IRR) contained 61,430 unique prefixes
   listed, not counting prefixes marked as withdrawn (or 65,191 prefixes
   with prefixes marked as withdrawn). That is roughly a lower bound
   since many prefixes are not registered in the IRR. CIDR aggregation
   resulted in less than 30,000 routes in the default-free part of the
   Internet routing system [Villamizar 95].

   CIDR is an example of the application of hierarchical routing in the
   Public Internet, where subnets, subscribers, and finally providers
   are some possible levels in the hierarchy. For example, a router
   within a site need not keep detailed routing information about every
   possible host in that site. Instead, the router maintains routing
   information on a per subnet basis. Likewise, a router within a
   provider need not keep detailed routing information about individual
   subnets within its subscribers. Instead, the router could maintain
   routing information on a per subscriber basis. Moreover, a router
   within a provider need not keep detailed routing information about



Rekhter & Li             Best Current Practice                  [Page 4]

RFC 2008                                                    October 1996


   stub (single home) subscribers of other providers by maintaining
   routing information on a per provider basis.

   Because of pre-CIDR address allocation, many routes in the Internet
   are not suitable for hierarchical aggregation. Moreover, unconnected
   sites with pre-CIDR address allocations exist. If these sites connect
   to the Internet at some point in the future, the routes to these
   sites are unlikely to be suitable for hierarchical aggregation. Also,
   when a site uses addresses obtain from its provider, but then later
   switches to a different provider (while continuing to use the same
   addresses), the route to the site may no longer be suitable for
   hierarchical aggregation.

   Hierarchical routing requires that aggregation boundaries for the