rfc2008.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 732 行 · 第 1/3 页

   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: [phone]
      EMail: [e-mail]

      Tony Li
      cisco Systems, Inc.
      170 Tasman Dr.
      San Jose, CA 95134
      Phone: [phone]
      EMail: [e-mail]



Rekhter & Li             Best Current Practice                 [Page 13]