doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc2008.txt b/doc/rfc/rfc2008.txt
new file mode 100644
index 0000000..a482401
--- /dev/null
+++ b/doc/rfc/rfc2008.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+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
+   addressing information be formed along some hierarchy. As a result,
+   many exceptions will be injected into the routing system in the
+   future, besides those exceptions that currently exist. Each exception
+   added to the routing system deters the scalability of the routing
+   system. The exact number of exceptions that can be tolerated is
+   dependent on the technology used to support routing. Unbridled growth
+   in the number of such exceptions will cause the routing system to
+   collapse.
+
+5 Address allocation and management policies
+
+   IP address allocation and management policy is a complex,
+   multifaceted issue. It covers a broad range of issues, such as who
+   formulates the policies, who executes the policies, what is the role
+   of various registries, what is the role of various organizations
+   (e.g., ISOC, IAB, IESG, IETF, IEPG, various government bodies, etc.),
+   the participation of end users in requesting addresses, and so on.
+   Address allocation and management and the scalability of the routing
+   system are interrelated - only certain address allocation and
+   management policies yield scalable routing. The Internet routing
+   system is subject to both technological and fundamental constraints.
+   These constraints restrict the choices of address allocation policies
+   that are practical.
+
+5.1 The "address ownership" allocation policy and its implications on
+   the Public Internet
+
+   "Address ownership" is one possible address allocation and management
+   policy. The "address ownership" policy means that part of the address
+   space, once allocated to an organization, remains allocated to the
+   organization as long as that organization wants it. Further, that
+   portion of the address space would not be allocated to any other
+   organization.  Often, such addresses are called "portable." It was
+   assumed that if an organization acquires its addresses via the
+
+
+
+Rekhter & Li             Best Current Practice                  [Page 5]
+
+RFC 2008                                                    October 1996
+
+
+   "address ownership" policy, the organization would be able to use
+   these addresses to gain access to the Internet routing services,
+   regardless of where the organization connects to the Internet.
+
+   While it has never been explicitly stated that various Internet
+   Registries use the "address ownership" allocation policy, it has
+   always been assumed (and practiced).
+
+   To understand the implications of the "address ownership" policy
+   ("portable" addresses) on the scalability of the Internet routing
+   system, one must observe that:
+
+     (a) By definition, address ownership assumes that addresses, once
+     assigned, fall under the control of the assignee. It is the
+     assignee that decides when to relinquish the ownership (although
+     the decision could be influenced by various factors).
+     Specifically, the assignee is not required (but may be influenced)
+     to relinquish the ownership as the connectivity of the assignee to
+     the Internet changes.
+
+     (b) By definition, hierarchical routing assumes that addresses
+     reflect the network topology as much as possible.
+
+   Therefore, the only presently known practical way to satisfy both
+   scalable hierarchical routing and address ownership for everyone is
+   to assume that the topology (or at least certain pieces of it) will
+   be permanently fixed. Given the distributed, decentralized, largely
+   unregulated, and global (international) nature of the Internet,
+   constraining the Internet topology (or even certain parts of it) may
+   have broad technical, social, economical, and political implications.
+   To date, little is known of what these implications are; even less is
+   known whether these implications would be acceptable (feasible) in
+   practice. Therefore, at least for now, we have to support an Internet
+   with an unconstrained topology (and unconstrained topological
+   changes).
+
+   Since the Internet does not constrain its topology (or allowed
+   topology changes), we can either have address ownership for everyone
+   or a routable Internet, but not both, or we need to develop and
+   deploy new mechanisms (e.g., by decoupling the address owned by the
+   end users from those used by the Internet routing, and provide
+   mechanisms to translate between the two). In the absence of new
+   mechanisms, if we have address ownership ("portable" addresses) for
+   everyone, then the routing overhead will lead to a breakdown of the
+   routing system resulting in a fragmented (partitioned) Internet.
+   Alternately, we can have a routable Internet, but without address
+    ownership ("portable" addresses) for everyone.
+
+
+
+
+Rekhter & Li             Best Current Practice                  [Page 6]
+
+RFC 2008                                                    October 1996
+
+
+5.2 The "address lending" allocation policy and its implications for the
+   Public Internet
+
+   Recently, especially since the arrival of CIDR, some subscribers and
+   providers have followed a model in which address space is not owned
+   (not portable), but is bound to the topology. This model suggests an
+   address allocation and management policy that differs from the
+   "address ownership" policy. The following describes a policy, called
+   "address lending," that provides a better match (as compared to the
+   "address ownership" policy) to the model.
+
+   An "address lending" policy means that an organization gets its
+   addresses on a "loan" basis. For the length of the loan, the lender
+   cannot lend the addresses to any other borrower. Assignments and
+   allocations based on the "address lending" policy should explicitly
+   include the conditions of the loan. Such conditions must specify that
+   allocations are returned if the borrower is no longer contractually
+   bound to the lender, and the lender can no longer provide aggregation
+   for the allocation. If a loan ends, the organization can no longer
+   use the borrowed addresses, and therefore must get new addresses and
+   renumber to use them. The "address lending" policy does not constrain
+   how the new addresses could be acquired.
+
+   This document expects that the "address lending" policy would be used
+   primarily by Internet Registries associated with providers; however,
+   this document does not preclude the use of the "address lending"
+   policy by an Internet Registry that is not associated with a
+   provider.
+
+   This document expects that when the "address lending" policy is used
+   by an Internet Registry associated with a provider, the provider is
+   responsible for arranging aggregation of these addresses to a degree
+   that is sufficient to achieve Internet-wide IP connectivity.
+
+   This document expects that when the "address lending" policy is used
+   by an Internet Registry associated with a provider, the terms and
+   conditions of the loan would be coupled to the service agreement
+   between the provider and the subscribers. That is, if the subscriber
+   moves to another provider, the loan would be canceled.
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Li             Best Current Practice                  [Page 7]
+
+RFC 2008                                                    October 1996
+
+
+   To reduce disruptions when a subscriber changes its providers, this
+   document strongly recommends that the terms and conditions of the
+   loan should include provision for a grace period. This provision
+   would allow a subscriber that disconnects from its provider a certain
+   grace period after the disconnection. During this grace period, the
+   borrower (the subscriber) may continue to use the addresses obtained
+   under the loan. This document recommends a grace period of at least
+   30 days. Further, to contain the routing information overhead, this
+   document suggests that a grace period be no longer than six months.
+
+   To understand the scalability implications of the "address lending"
+   policy, observe that if a subscriber borrows its addresses from its
+   provider's block, then the provider can advertise a single address
+   prefix. This reduces the routing information that needs to be carried
+   by the Internet routing system (for more information, see Section
+   5.3.1 of RFC1518). As the subscriber changes its provider, the loan
+   from the old provider would be returned, and the loan from the new
+   provider would be established. As a result, the subscriber would
+   renumber to the new addresses. Once the subscriber renumbers into the
+   new provider's existing blocks, no new routes need to be introduced
+   into the routing system.
+
+   Therefore, the "address lending" policy, if applied appropriately, is
+   consistent with the constraints on address allocation policies
+   imposed by hierarchical routing, and thus promotes a scalable routing
+   system.  Thus, the "address lending" policy, if applied
+   appropriately, could play an important role in enabling the
+   continuous uninterrupted growth of the Internet.
+
+   To be able to scale routing in other parts of the hierarchy, the
+   "lending" policy may also be applied hierarchically, so that
+   addresses may in turn be lent to other organizations. The implication
+   here is that the end of a single loan may have effects on
+   organizations that have recursively borrowed parts of the address
+   space from the main allocation. In this case, the exact effects are
+   difficult to determine a priori.
+
+5.3 In the absence of an explicit "address lending" policy
+
+   Organizations connecting to the Internet should be aware that even if
+   their current provider, and the provider they switch to in the future
+   do not require renumbering, renumbering may still be needed to
+   achieve Internet-wide IP connectivity. For example, an organization
+   may now receive Internet service from some provider and allocate its
+   addresses out of the CIDR block associated with the provider. Later
+   the organization may switch to another provider. The previous
+   provider may still be willing to allow the organization to retain
+   part of the provider's CIDR block, and accept a more specific prefix
+
+
+
+Rekhter & Li             Best Current Practice                  [Page 8]
+
+RFC 2008                                                    October 1996
+
+
+   for that organization from the new provider. Likewise, the new
+   provider may be willing to accept that organization without
+   renumbering and advertise the more specific prefix (that covers
+   destinations within the organization) to the rest of the Internet.
+   However, if one or more other providers exist, that are unwilling or
+   unable to accept the longer prefix advertised by the new provider,
+   then the organization would not have IP connectivity to part of the
+   Internet. Among the possible solutions open to the organization may
+   be either to renumber, or for others to acquire connectivity to
+   providers that are willing and able to accept the prefix.
+
+   The above shows that the absence of an explicit "address lending"
+   policy from a current provider in no way ensures that renumbering
+   will not be required in the future when changing providers.
+   Organizations should be aware of this fact should they encounter a
+   provider making claims to the contrary.
+
+6 Recommendations
+
+   Observe that the goal of hierarchical routing in the Internet is not
+   to reduce the total amount of routing information in the Internet to
+   the theoretically possible minimum, but just to contain the volume of
+   routing information within the limits of technology,
+   price/performance, and human factors.  Therefore, organizations that
+   could provide reachability to a sufficiently large fraction of the
+   total destinations in the Internet and could express such
+   reachability through a single IP address prefix could expect that a
+   route with this prefix will be maintained throughout the default-free
+   part of the Internet routing system, regardless of where they connect
+   to the Internet.  Therefore, using the "address ownership" policy
+   when allocating addresses to such organizations is a reasonable
+   choice.  Within such organizations this document suggests the use of
+   the "address lending" policy.
+
+   For all other organizations that expect Internet-wide IP
+   connectivity, the reachability information they inject into the
+   Internet routing system should be subject to hierarchical
+   aggregation. For such organizations, allocating addresses based on
+   the "address ownership" policy makes hierarchical aggregation
+   difficult, if not impossible. This, in turn, has a very detrimental
+   effect on the Internet routing system. To prevent the collapse of the
+   Internet routing system, for such organizations, this document
+   recommends using the "address lending" policy. Consequently, when
+   such an organization first connects to the Public Internet or changes
+   its topological attachment to the Public Internet, the organization
+   eventually needs to renumber. Renumbering allows the organization to
+   withdraw any exceptional prefixes that the organization would
+   otherwise inject into the Internet routing system. This applies to
+
+
+
+Rekhter & Li             Best Current Practice                  [Page 9]
+
+RFC 2008                                                    October 1996
+
+
+   the case where the organization takes its addresses out of its direct
+   provider's block and the organization changes its direct provider.
+   This may also apply to the case where the organization takes its
+   addresses out of its indirect provider's block, and the organization
+   changes its indirect provider, or the organization's direct provider
+   changes its provider.
+
+   Carrying routing information has a cost associated with it. This
+   cost, at some point, may be passed back in full to the organizations
+   that inject the routing information. Aggregation of addressing
+   information (via CIDR) could reduce the cost, as it allows an
+   increase in the number of destinations covered by a single route.
+   Organizations whose addresses are allocated based on the "address
+   ownership" policy (and thus may not be suitable for aggregation)
+   should be prepared to absorb the cost completely on their own.
+
+   Observe that neither the "address ownership," nor the "address
+   lending" policy, by itself, is sufficient to guarantee Internet-wide
+   IP connectivity. Therefore, we recommend that sites with addresses
+   allocated based on either policy should consult their providers about
+   the reachability scope that could be achieved with these addresses,
+   and associated costs that result from using these addresses.
+
+   If an organization doesn't require Internet-wide IP connectivity,
+   then address allocation for the organization could be done based on
+   the "address ownership" policy. Here, the organization may still
+   maintain limited IP connectivity (e.g., with all the subscribers of
+   its direct provider) by limiting the distribution scope of its
+   routing information to its direct provider. Connectivity to the rest
+   of the Internet can be handled by mediating gateways (e.g.,
+   application layer gateways, Network Address Translators (NATs)). Note
+   that use of mediating gateways eliminates the need for renumbering,
+   and avoids burdening the Internet routing system with non-
+   aggregatable addressing information; however they have other
+   drawbacks which may prove awkward in certain situations.
+
+   Both renumbering (due to the "address lending" policy), and non-
+   aggregated routing information (due to the "address ownership"
+   policy), and the use of mediating gateways result in some costs.
+   Therefore, an organization needs to analyze its own connectivity
+   requirements carefully and compare the tradeoffs associated with
+   addresses acquired via either policy vs. having connectivity via
+   mediating gateways (possibly augmented by limited IP connectivity)
+   using addresses acquired via "address ownership." To reduce the cost
+   of renumbering, organizations should be strongly encouraged to deploy
+   tools that simplify renumbering (e.g., Dynamic Host Configuration
+   Protocol [RFC 1541]). Use of the DNS should be strongly encouraged.
+
+
+
+
+Rekhter & Li             Best Current Practice                 [Page 10]
+
+RFC 2008                                                    October 1996
+
+
+7 Summary
+
+   Any address allocation and management policy for IP addresses used
+   for Internet connectivity must take into account its impact on the
+   scalability of the Public Internet routing system. Among all of the
+   possible address allocation and management policies only the ones
+   that yield a scalable routing system are feasible. All other policies
+   are self-destructive in nature, as they lead to a collapse of the
+   Internet routing system, and therefore to the fragmentation
+   (partitioning) of the Public Internet.
+
+   Within the context of the current Public Internet, address allocation
+   and management policies that assume unrestricted address ownership
+   have an extremely negative impact on the scalability of the Internet
+   routing system. Such policies are almost certain to exhaust the
+   scalability of the Internet routing system well before we approach
+   the exhaustion of the IPv4 address space and before we can make
+   effective use of the IPv6 address space. Given the Internet's growth
+   rate and current technology, the notion that everyone can own address
+   space and receive Internet-wide routing services, despite where they
+   connect to the Internet, is currently technically infeasible.
+   Therefore, this document makes two recommendations. First, the
+   "address lending" policy should be formally added to the set of
+   address allocation policies in the Public Internet. Second,
+   organizations that do not provide a sufficient degree of routing
+   information aggregation to obtain access to the Internet routing
+   services should be strongly encouraged to use this policy to gain
+   access to the services.
+
+   Since the current IPv6 address allocation architecture is based on
+   CIDR, recommendations presented in this document apply to IPv6
+   address allocation and management policies as well.
+
+8 Security Considerations
+
+   Renumbering a site has several possible implications on the security
+   policies of both the site itself and sites that regularly communicate
+   with the renumbering sites.
+
+   Many sites currently use "firewall" systems to provide coarse-grained
+   access control from external networks, such as The Internet, to their
+   internal systems.  Such firewalls might include access control
+   decisions based on the claimed source address of packets arriving at
+   such firewall systems.  When the firewall policy relates to packets
+   arriving on the firewall from inside the site, then that firewall
+   will need to be reconfigured at the same time that the site itself
+   renumbers.  When the firewall policy relates to packets arriving at
+   the firewall from outside the site, then such firewalls will need to
+
+
+
+Rekhter & Li             Best Current Practice                 [Page 11]
+
+RFC 2008                                                    October 1996
+
+
+   be reconfigured whenever an outside site that is granted any access
+   inside the site through the firewall is renumbered.
+
+   It is highly inadvisable to rely upon unauthenticated source or
+   destination IP addresses for security policy decisions. [Bellovin89]
+   IP address spoofing is not difficult with widely available systems,
+   such as personal computers.  A better approach would probably involve
+   the use of IP Security techniques, such as the IP Authentication
+   Header [RFC-1826] or IP Encapsulating Security Payload [RFC-1827], at
+   the firewall so that the firewall can rely on cryptographic
+   techniques for identification when making its security policy
+   decisions.
+
+   It is strongly desirable that authentication be present in any
+   mechanism used to renumber IP nodes.  A renumbering mechanism that
+   lacks authentication could be used by an adversary to renumber
+   systems that should not have been renumbered, for example.
+
+   There may be other security considerations that are not covered in
+   this document.
+
+9 Acknowledgments
+
+   This document borrows heavily from various postings on various
+   mailing lists. Special thanks to Noel Chiappa, Dennis Ferguson, Eric
+   Fleischman, Geoff Huston, and Jon Postel whose postings were used in
+   this document.
+
+   Most of the Section 5.3 was contributed by Curtis Villamizar.  The
+   Security section was contributed by Ran Atkinson.
+
+   Many thanks to Scott Bradner, Randy Bush, Brian Carpenter, Noel
+   Chiappa, David Conrad, John Curran, Sean Doran, Dorian Kim, Thomas
+   Narten, Andrew Partan, Dave Piscitello, Simon Poole, Curtis
+   Villamizar, and Nicolas Williams for their review, comments, and
+   contributions to this document.
+
+   Finally, we like to thank all the members of the CIDR Working Group
+   for their review and comments.
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Li             Best Current Practice                 [Page 12]
+
+RFC 2008                                                    October 1996
+
+
+9 References
+
+   [Bellovin89] Bellovin, S., "Security Problems in the TCP/IP Protocol
+   Suite", ACM Computer Communications Review, Vol. 19, No. 2, March
+   1989.
+
+   [Kleinrock 77] Kleinrock, L., and K. Farouk, K., "Hierarchical
+   Routing for Large Networks," Computer Networks 1 (1977), North-
+   Holland Publishing Company.
+
+   [Partan 95] Partan, A., private communications, October 1995.
+
+   [RFC 1541] Droms, R., "Dynamic Host Configuration Protocol", October
+   1993.
+
+   [RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
+   Inter-Domain Routing (CIDR): an Address Assignment and Aggregation
+   Strategy", September 1993.
+
+   [RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP Address
+   Allocation with CIDR", September 1993.
+
+   [RFC 1825] Atkinson, R., "IP Security Architecture", RFC 1825, August
+   1995.
+
+   [RFC 1826] Atkinson, R., "IP Authentication Header (AH), RFC 1826,
+   August 1995.
+
+   [RFC 1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
+   RFC 1827, August 1995.
+
+   [Villamizar 95] Villamizar, C., private communications, October 1995.
+
+10 Authors' Addresses
+
+      Yakov Rekhter
+      cisco Systems, Inc.
+      170 Tasman Dr.
+      San Jose, CA 95134
+      Phone: (914) 528-0090
+      EMail: yakov@cisco.com
+
+      Tony Li
+      cisco Systems, Inc.
+      170 Tasman Dr.
+      San Jose, CA 95134
+      Phone: (408) 526-8186
+      EMail: tli@cisco.com
+
+
+
+Rekhter & Li             Best Current Practice                 [Page 13]
+