summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2270.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2270.txt')
-rw-r--r--doc/rfc/rfc2270.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2270.txt b/doc/rfc/rfc2270.txt
new file mode 100644
index 0000000..08041a2
--- /dev/null
+++ b/doc/rfc/rfc2270.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group J. Stewart
+Request for Comments: 2270 ISI
+Category: Informational T. Bates
+ R. Chandra
+ E. Chen
+ Cisco
+ January 1998
+
+
+ Using a Dedicated AS for Sites Homed to a Single Provider
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ With the increased growth of the Internet, the number of customers
+ using BGP4 has grown significantly. RFC1930 outlines a set of
+ guidelines for when one needs and should use an AS. However, the
+ customer and service provider (ISP) are left with a problem as a
+ result of this in that while there is no need for an allocated AS
+ under the guidelines, certain conditions make the use of BGP4 a very
+ pragmatic and perhaps only way to connect a customer homed to a
+ single ISP. This paper proposes a solution to this problem in line
+ with recommendations set forth in RFC1930.
+
+1. Problems
+
+ With the increased growth of the Internet, the number of customers
+ using BGP4 [1],[2] has grown significantly. RFC1930 [4] outlines a
+ set of guidelines for when one needs and should use an AS. However,
+ the customer and service provider (ISP) are left with a problem as a
+ result of this in that while there is no need for an allocated AS
+ under the guidelines, certain conditions make the use of BGP4 a very
+ pragmatic and perhaps only way to connect a customer homed to a
+ single ISP. These conditions are as follows:
+
+ 1) Customers multi-homed to single provider
+
+
+
+
+
+
+Stewart, et. al. Informational [Page 1]
+
+RFC 2270 Dedicated AS January 1998
+
+
+ Consider the scenario outlined in Figure 1 below.
+
+
+
+ +-------+ +-------+
+ +----+ | | |
+ +------+ | | ISP A +------+ ISP B |
+ | Cust.+---+ | | | |
+ | X +--------+ | | |
+ +------+ ++-----++\ +-------+
+ | | \
+ | | \ +--------+
+ ++-----++ +-| |
+ | Cust. | | ISP C |
+ | Y | | |
+ +-------+ +--------+
+
+ Figure 1: Customers multi-home to a single provider
+
+ Here both customer X and customer Y are multi-homed to a single
+ provider, ISP A. Because these multiple connections are "localized"
+ between the ISP A and its customers, the rest of the routing system
+ (ISP B and ISP C in this case) doesn't need to see routing
+ information for a single multi-homed customer any differently than a
+ singly-homed customer as it has the same routing policy as ISP A
+ relative to ISP B and ISP C. In other words, with respect to the
+ rest of the Internet routing system the organization is singly-homed,
+ so the complexity of the multiple connections is not relevant in a
+ global sense. Autonomous System Numbers (AS) are identifiers used in
+ routing protocols and are needed by routing domains as part of the
+ global routing system. However, as [4] correctly outlines,
+ organizations with the same routing policy as their upstream provider
+ do not need an AS.
+
+ Despite this fact, a problem exists in that many ISPs can only
+ support the load-sharing and reliability requirements of a multi-
+ homed customer if that customer exchanges routing information using
+ BGP-4 which does require an AS as part of the protocol.
+
+ 2) Singly-homed customers requiring dynamic advertisement of NLRI's
+
+ While this is not a common case as static routing is generally
+ used for this purpose, if a large amount of NLRI's need to be
+ advertised from the customer to the ISP it is often
+ administratively easier for these prefixes to be advertised using
+ a dynamic routing protocol. Today, the only exterior gateway
+ protocol (EGP) that is able to do this is BGP. This leads to the
+ same problem outlined in condition 1 above.
+
+
+
+Stewart, et. al. Informational [Page 2]
+
+RFC 2270 Dedicated AS January 1998
+
+
+ As can be seen there is clearly a problem with the recommendations
+ set forth in [4] and the practice of using BGP4 in the scenarios
+ above. Section 2 proposes a solution to this problem with following
+ sections describing the implications and application of the proposed
+ solution.
+
+ It should also be noted that if a customer is multi-homed to more
+ than one ISP then they are advised to obtain an official allocated AS
+ from their allocation registry.
+
+2. Solution
+
+ The solution we are proposing is that all BGP customers homed to the
+ same single ISP use a single, dedicated AS specified by the ISP.
+
+ Logically, this solution results in an ISP having many peers with the
+ same AS, although that AS exists in "islands" completely disconnected
+ from one another.
+
+ Several practical implications of this solution are discussed in the
+ next section.
+
+3. Implications
+
+3.1 Full Routing Table Announcement
+
+ The solution precludes the ability for a BGP customer using the
+ dedicated AS to receive 100% full routes. Because of routing loop
+ detection of AS path, a BGP speaker rejects routes with its own AS
+ number in the AS path. Imagine Customer X and Customer Y maintain
+ BGP peers with Provider A using AS number N. Then, Customer X will
+ not be able to received routes of Customer Y. We do not believe that
+ this would cause a problem for Customer X, though, because Customer X
+ and Customer Y are both stub networks so default routing is adequate,
+ and the absence of a very small portion of the full routing table is
+ unlikely to have a noticeable impact on traffic patterns guided by
+ MEDs received.
+
+ A BGP customer using the dedicated AS must carry a default route
+ (preferably receiving from its provider via BGP).
+
+3.2 Change of External Connectivity
+
+ The dedicated AS specified by a provider is purely for use in peering
+ between its customers and the provider. When a customer using the
+ dedicated AS changes its external connectivity, it may be necessary
+ for the customer to reconfigure their network to use a different AS
+ number (either a globally unique one if homed to multiple providers,
+
+
+
+Stewart, et. al. Informational [Page 3]
+
+RFC 2270 Dedicated AS January 1998
+
+
+ or a dedicated AS of a different provider).
+
+3.3 Aggregation
+
+ As BGP customers using this dedicated AS are only homed to one ISP,
+ their routes allocated from its providers CIDR block do not need to
+ be announced upstream by its provider as the providers will already
+ be originating the larger block. [6].
+
+3.4 Routing Registries
+
+ The Internet Routing Registry (IRR) [5] is used by providers to
+ generate route filtering lists. Such lists are derived primarily
+ from the "origin" attribute of the route objects. The "origin" is
+ the AS that originates the route. With multiple customers using the
+ same AS, finer granularity will be necessary to generate the correct
+ route filtering. For example, the "mntner" attribute or the
+ "community" attribute of a route object can be used along with the
+ "origin" attribute in generating the filtering lists.
+
+4. Practice
+
+ The AS number specified by a provider can either be an AS from the
+ private AS space (64512 - 65535) [4], or be an AS previously
+ allocated to the provider. With the former, the dedicated AS like
+ all other private AS's should be stripped from its AS path while the
+ route is being propagated to the rest of the Internet routing system.
+
+5. Security Considerations
+
+ The usage of AS numbers described in this document has no effective
+ security impact. Acceptance and filtering of AS numbers from
+ customers is an issue dealt with in other documents.
+
+6. Acknowledgments
+
+ The authors would like to thank Roy Alcala of MCI and Arpakorn
+ Boonkongchuen for their input to this document. The members of the
+ IDR Working Group also provided helpful comments.
+
+7. References
+
+ [1] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
+ RFC 1771, March 1995.
+
+ [2] Rekhter, Y., and P. Gross, "Application of the Border Gateway
+ Protocol in the Internet", RFC 1772, March 1995.
+
+
+
+
+Stewart, et. al. Informational [Page 4]
+
+RFC 2270 Dedicated AS January 1998
+
+
+ [3] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787,
+ April 1995.
+
+ [4] Hawkinson, J., and T. Bates, "Guidelines for creation, selection,
+ and registration of an Autonomous System (AS)", RFC 1930, March 1996.
+
+ [5] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M, Karrenberg,
+ D., Terpstra, M., and J. Yu., "Representation of IP Routing Policies
+ in a Routing Registry (ripe-81++)", RFC 1786, March 1995.
+
+ [6] Chen, E., and J. Stewart., "A Framework for Inter-Domain Route
+ Aggregation", Work in Progress.
+
+8. Authors' Addresses
+
+ John Stewart
+ USC/ISI
+ 4350 North Fairfax Drive
+ Suite 620
+ Arlington, VA 22203
+
+ EMail: jstewart@isi.edu
+
+
+ Tony Bates
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+
+ EMail: tbates@cisco.com
+
+
+ Ravi Chandra
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+
+ EMail: rchandra@cisco.com
+
+
+ Enke Chen
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+
+ EMail: enkechen@cisco.com
+
+
+
+
+
+Stewart, et. al. Informational [Page 5]
+
+RFC 2270 Dedicated AS January 1998
+
+
+9. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et. al. Informational [Page 6]
+