doc: Add RFC documents

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]
+