rfc2260.txt

中、英文RFC文档大全打包下载完全版 .


RFC 2260                      Multihoming                   January 1998


   with the enterprise's border routers. The non-direct peering could be
   maintained with any router within the ISP. Doing this could improve
   the overall robustness in the presence of failures within the ISP.

5.3. Combining the two

   One could observe that while the approach described in Section 5.2
   allows to completely eliminate the routing overhead due to multi-
   homed enterprises in the "default-free" zone of the Internet, it may
   result in a suboptimal routing in the presence of link failures. The
   sub-optimality could be reduced by combining the approach described
   in Section 5.2 with a slightly modified version of the approach
   described in Section 5.1. The modification consists of constraining
   the scope of propagation of additional routes that are advertised by
   an enterprise border router when the router detects problems with the
   Internet connectivity through its other border routers. A way to
   constrain the scope is by using the BGP Community attribute
   [RFC1997].

5.4. Better (more optimal) routing in steady state

   The approach described in this document assumes that in a steady
   state an enterprise border router would advertise to a directly
   connected ISP border router only the reachability to the address
   prefix that this ISP allocated to the enterprise. As a result,
   traffic originated by other enterprises connected to that ISP and
   destined to the parts of the enterprise numbered out of other address
   prefixes would not enter the enterprise at this border router,
   resulting in potentially suboptimal paths. To improve the situation
   the border router may (in steady state) advertise reachability not
   only to the address prefix that was allocated by the ISP that the
   router is directly connected to, but to the address prefixes
   allocated by some other ISPs (directly connected to some other border
   routers within the enterprise).  Distribution of such advertisements
   should be carefully constrained, or otherwise this may result in
   significant additional routing information that would need to be
   maintained in the "default-free" part of the Internet. A way to
   constrain the distribution of such advertisements is by using the BGP
   Community attribute [RFC1997].

6. Comparison with other approaches

   CIDR [RFC1518] proposes several possible address allocation
   strategies for multi-homed enterprises that are connected to multiple
   ISPs.  The following briefly reviews the alternatives being used
   today, and compares them with the approaches described above.





Bates & Rekhter              Informational                      [Page 7]

RFC 2260                      Multihoming                   January 1998


6.1. Solution 1

   One possible solution suggested in [RFC1518] is for each multi-homed
   enterprise to obtain its IP address space independently from the ISPs
   to which it is attached.  This allows each multi-homed enterprise to
   base its IP assignments on a single prefix, and to thereby summarize
   the set of all IP addresses reachable within that enterprise via a
   single prefix.  The disadvantage of this approach is that since the
   IP address for that enterprise has no relationship to the addresses
   of any particular ISPs, the reachability information advertised by
   the enterprise is not aggregatable with any, but default route.
   results in the routing overhead in the "default-free" zone of the
   Internet of O(N), where N is the total number of multi-homed
   enterprises across the whole Internet that are connected to multiple
   ISPs.

   As a result, this approach can't be viewed as a viable alternative
   for all, but the enterprises that provide high enough degree of
   addressing information aggregation. Since by definition the number of
   such enterprises is likely to be fairly small, this approach isn't
   viable for most of the multi-homed enterprises connected to multiple
   ISPs.

6.2. Solution 2

   Another possible solution suggested in [RFC1518] is to assign each
   multi-homed enterprise a single address prefix, based on one of its
   connections to one of its ISPs.  Other ISPs to which the multi-homed
   enterprise is attached maintain a routing table entry for the
   organization, but are extremely selective in terms of which other
   ISPs are told of this route and would need to perform "proxy"
   aggregation.  Most of the complexity associated with this approach is
   due to the need to perform "proxy" aggregation, which in turn
   requires t addiional inter-ISP coordination and more complex router
   configuration.

7. Discussion

   The approach described in this document assumes that addresses that
   an enterprise would use are allocated based on the "address lending"
   policy. Consequently, whenever an enterprise changes its ISP, the
   enterprise would need to renumber part of its network that was
   numbered out of the address block that the ISP allocated to the
   enterprise.  However, these issues are not specific to multihoming
   and should be considered accepted practice in todays internet. The
   approach described in this document effectively eliminates any
   distinction between single-home and multi-homed enterprise with
   respect to the impact of changing ISPs on renumbering.



Bates & Rekhter              Informational                      [Page 8]

RFC 2260                      Multihoming                   January 1998


   The approach described in this document also requires careful address
   assignment within an enterprise, as address assignment impacts
   traffic distribution among multiple connections between an enterprise
   and its ISPs.

   Both the issue of address assignment and renumbering could be
   addressed by the appropriate use of network address translation
   (NAT). The use of NAT for multi-homed enterprises is the beyond the
   scope of this document.

   Use of auto route injection (as described in Section 5.1) increases
   the number of routers in the default-free zone of the Internet that
   could be affected by changes in the connectivity of multi-homed
   enterprises, as compared to the use of provider-independed addresses
   (as described in Section 6.1).  Specifically, with auto route
   injection when a multi-homed enterprise loses its connectivity
   through one of its ISPs, the auto injected route has to be propagated
   to all the routers in the default-free zone of the Internet. In
   contrast, when an enterprise uses provider-independent addresses,
   only some (but not all) of the routers in the default-free zone would
   see changes in routing when the enterprise loses its connectivity
   through one of its ISPs.

   To supress excessive routing load due to link flapping the auto
   injected route has to be advertised until the connectivity via the
   other connection (that was previously down and that triggered auto
   route injection) becomes stable.

   Use of the non-direct EBGP approach (as described in Section 5.2)
   allows to eliminate route flapping due to multi-homed enterprises in
   the default-free zone of the Internet. That is the non-direct EBGP
   approach has better properties with respect to routing stability than
   the use of provider-independent addresses (as described in Section
   6.1).

8. Applications to multi-homed ISPs

   The approach described in this document could be applicable to a
   small to medium size ISP that is connected to several upstream ISPs.
   The ISP would acquire blocks of addresses (address prefixes) from its
   upstream ISPs, and would use these addresses for allocations to its
   customers.  Either auto route injection, or the non-direct EBGP
   approach, or a combination of both could be used by the ISP when
   peering with its upstream ISPs. Doing this would provide routability
   for the customers of such ISP, without advertsely affecting the
   overall scalability of the Internet routing system.





Bates & Rekhter              Informational                      [Page 9]

RFC 2260                      Multihoming                   January 1998


9. Security Considerations

   Since the non-direct EBGP approach (as described in Section 5.2)
   requires EBGP sessions between routers that are more than one IP hop
   from each other, routers that maintain these sessions should use an
   appropriate authentication mechanism(s) for BGP peer authentication.

   Security issues related to the IBGP peering, as well as the EBGP
   peering between routers that are one IP hop from each other are
   outside the scope of this document.

10. Acknowledgments

   The authors of this document do not make any claims on the
   originality of the ideas described in this document. Anyone who
   thought about these ideas before should be given all due credit.

11. References

   [RFC1518]
        Rekhter, Y., and T. Li, "An Architecture for IP Address
        Allocation with CIDR", RFC 1518, September 1993.

   [RFC1771]
        Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
        RFC 1771, March 1995.

   [RFC1773]
        Hanks, S., Li, T., Farinacci, T., and P. Traina, "Generic
        Routing Encapsulation over IPv4 networks", RFC 1773, October
        1994.

   [RFC1918]
        Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G.J., and
        E. Lear, "Address Allocation for Private Internets", RFC 1918,
        February 1996.

   [RFC1997]
        Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute",
        RFC 1997, August 1996.

   [RFC2008]
        Rekhter, Y., and T. Li, "Implications of Various Address
        Allocation Policies for Internet Routing", BCP 7, RFC 2008,
        October 1996.






Bates & Rekhter              Informational                     [Page 10]

RFC 2260                      Multihoming                   January 1998


12. Authors' Addresses

   Tony Bates
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134

   EMail: [e-mail]


   Yakov Rekhter
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   EMail: [e-mail]




































Bates & Rekhter              Informational                     [Page 11]

RFC 2260                      Multihoming                   January 1998


13.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Bates & Rekhter              Informational                     [Page 12]