doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc3765.txt b/doc/rfc/rfc3765.txt
new file mode 100644
index 0000000..5f7e07c
--- /dev/null
+++ b/doc/rfc/rfc3765.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          G. Huston
+Request for Comments: 3765                                       Telstra
+Category: Informational                                       April 2004
+
+
+           NOPEER Community for Border Gateway Protocol (BGP)
+                          Route Scope Control
+
+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 (2004).  All Rights Reserved.
+
+Abstract
+
+   This document describes the use of a scope control Border Gateway
+   Protocol (BGP) community.  This well-known advisory transitive
+   community allows an origin AS to specify the extent to which a
+   specific route should be externally propagated.  In particular this
+   community, NOPEER, allows an origin AS to specify that a route with
+   this attribute need not be advertised across bilateral peer
+   connections.
+
+1.  Introduction
+
+   BGP today has a limited number of commonly defined mechanisms that
+   allow a route to be propagated across some subset of the routing
+   system.  The NOEXPORT community allows a BGP speaker to specify that
+   redistribution should extend only to the neighbouring AS.  Providers
+   commonly define a number of communities that allow their neighbours
+   to specify how advertised routes should be re-advertised.  Current
+   operational practice is that such communities are defined on as AS by
+   AS basis, and while they allow an AS to influence the re-
+   advertisement behaviour of routes passed from a neighbouring AS, they
+   do not allow this scope definition ability to be passed in a
+   transitive fashion to a remote AS.
+
+   Advertisement scope specification is of most use in specifying the
+   boundary conditions of route propagation.  The specification can take
+   on a number of forms, including as AS transit hop count, a set of
+   target ASs, the presence of a particular route object, or a
+   particular characteristic of the inter-AS connection.
+
+
+
+
+Huston                       Informational                      [Page 1]
+
+RFC 3765                         NOPEER                       April 2004
+
+
+   There are a number of motivations for controlling the scope of
+   advertisement of route prefixes, including support of limited transit
+   services where advertisements are restricted to certain transit
+   providers, and various forms of selective transit in a multi-homed
+   environment.
+
+   This memo does not attempt to address all such motivations of scope
+   control, and addresses in particular the situation of both multi-
+   homing and traffic engineering.  The commonly adopted operational
+   technique is that the originating AS advertises an encompassing
+   aggregate route to all multi-home neighbours, and also selectively
+   advertises a collection of more specific routes.  This implements a
+   form of destination-based traffic engineering with some level of fail
+   over protection.  The more specific routes typically cease to lever
+   any useful traffic engineering outcome beyond a certain radius of
+   redistribution, and a means of advising that such routes need not to
+   be distributed beyond such a point is of some value in moderating one
+   of the factors of continued route table growth.
+
+   Analysis of the BGP routing tables reveals a significant use of the
+   technique of advertising more specific prefixes in addition to
+   advertising a covering aggregate.  In an effort to ameliorate some of
+   the effects of this practice, in terms of overall growth of the BGP
+   routing tables in the Internet and the associated burden of global
+   propagation of dynamic changes in the reachability of such more
+   specific address prefixes, this memo describes the use of a
+   transitive BGP route attribute that allows more specific route tables
+   entries to be discarded from the BGP tables under appropriate
+   conditions.  Specifically, this attribute, NOPEER, allows a remote AS
+   not to advertise a route object to a neighbour AS when the two AS's
+   are interconnected under the conditions of some form of sender keep
+   all arrangement, as distinct from some form of provider / customer
+   arrangement.
+
+2.  NOPEER Attribute
+
+   This memo defines the use a new well-known bgp transitive community,
+   NOPEER.
+
+   The semantics of this attribute is to allow an AS to interpret the
+   presence of this community as an advisory qualification to
+   readvertisement of a route prefix, permitting an AS not to
+   readvertise the route prefix to all external bilateral peer neighbour
+   AS's.  It is consistent with these semantics that an AS may filter
+   received prefixes that are received across a peering session that the
+   receiver regards as a bilateral peer sessions.
+
+
+
+
+
+Huston                       Informational                      [Page 2]
+
+RFC 3765                         NOPEER                       April 2004
+
+
+3.  Motivation
+
+   The size of the BGP routing table has been increasing at an
+   accelerating rate since late 1998.  At the time of publication of
+   this memo the BGP forwarding table contains over 118,000 entries, and
+   the three year growth rate of this table shows a trend rate which can
+   be correlated to a compound growth rate of no less than 10% per year
+   [2].
+
+   One of the aspects of the current BGP routing table is the widespread
+   use of the technique of advertising both an aggregate and a number of
+   more specific address prefixes.  For example, the table may contain a
+   routing entry for the prefix 10.0.0.0/23 and also contain entries for
+   the prefixes 10.0.0.0/24 and 10.0.1.0/24.  In this example the
+   specific routes fully cover the aggregate announcement.  Sparse
+   coverage of aggregates with more specifics is also observed, where,
+   for example, routing entries for 10.0.0.0/8 and 10.0.1.0/24 both
+   exist in the routing table.  In total, these more specific route
+   entries occupy some 51% of the routing table, so that more than one
+   half of the routing table does not add additional address
+   reachability information into the routing system, but instead is used
+   to impose a finer level of detail on existing reachability
+   information.
+
+   There are a number of motivations for having both an aggregate route
+   and a number of more specific routes in the routing table, including
+   various forms of multi-homed configurations, where there is a
+   requirement to specify a different reachability policy for a part of
+   the advertised address space.
+
+   One of the observed common requirements in the multi-homed network
+   configuration is that of undertaking some form of load balancing of
+   incoming traffic across a number of external connections to a number
+   of different neighbouring ASs.  If, for example, an AS wishes to use
+   a multi-homed configuration for routing-based load balancing and some
+   form of mutual fail over between the multiple access connections for
+   incoming traffic, then one approach is for the AS to advertise the
+   same aggregate address prefix to a number of its upstream transit
+   providers, and then advertise a number of more specifics to
+   individual upstream providers.  In such a case all of the traffic
+   destined to the more specific address prefixes will be received only
+   over those connections where the more specific has been advertised.
+   If the neighbour BGP peering session of the more specific
+   advertisement fails, the more specific will cease to be announced and
+   incoming traffic will then be passed to the originating network based
+   on the path associated with the advertisement of the encompassing
+   aggregate.  In this situation the more specific routes are not
+   automatically subsumed by the presence of the aggregate at any remote
+
+
+
+Huston                       Informational                      [Page 3]
+
+RFC 3765                         NOPEER                       April 2004
+
+
+   AS.  Both the aggregate and the associated more specific routes are
+   redistributed across the entire external BGP routing domain.  In many
+   cases, particularly those associated with desire to undertake traffic
+   engineering and service resilience, the more specific routes are
+   redistributed well beyond the scope where there is any outcomes in
+   terms of traffic differentiation.
+
+   To the extent that remote analysis of BGP tables can observe this
+   form of configuration, the number of entries in the BGP forwarding
+   table where more specific entries share a common origin AS with their
+   immediately enclosing aggregates comprise some 20% of the total
+   number of FIB entries.  Using a slightly stricter criteria where the
+   AS path of the more specific route matches the immediately enclosing
+   aggregate, the number of more specific routes comprises some 14% of
+   the number of FIB entries.
+
+   One protocol mechanism that could be useful in this context is to
+   allow the originator of an advertisement to state some additional
+   qualification on the redistribution of the advertisement, allowing a
+   remote AS to suppress further redistribution under some originator-
+   specified criteria.
+
+   The redistribution qualification condition can be specified either by
+   enumeration or by classification.  Enumeration would encompass the
+   use of a well-known transitive extended community to specify a list
+   of remote AS's where further redistribution is not advised.  The
+   weakness of this approach is that the originating AS would need to
+   constantly revise this enumerated AS list to reflect the changes in
+   inter-AS topology, as, otherwise, the more specific routes would leak
+   beyond the intended redistribution scope.  An approach of
+   classification allows an originating AS to specify the conditions
+   where further redistribution is not advised without having to refer
+   to the particular AS's where a match to such conditions are
+   anticipated.
+
+   The approach described here to specifying the redistribution boundary
+   condition is one based on the type of bilateral inter-AS peering.
+   Where one AS can be considered as a customer, and the other AS can be
+   considered as a contracted agent of the customer, or provider, then
+   the relationship is one where the provider, as an agent of the
+   customer, carries the routes and associated policy associated with
+   the routes.  Where neither AS can be considered as a customer of the
+   other, then the relationship is one of bilateral peering, and neither
+   AS can be considered as an agent of the other in redistributing
+   policies associated with routes.  This latter arrangement is commonly
+   referred to as a "sender keep all peer" relationship, or "peering".
+
+
+
+
+
+Huston                       Informational                      [Page 4]
+
+RFC 3765                         NOPEER                       April 2004
+
+
+   This peer boundary can be regarded as a logical point where the
+   redistribution of additional reachability policy imposed by the
+   origin AS on a route is no longer an imposed requirement.
+
+   This approach allows an originator of a prefix to attach a commonly
+   defined policy to a route prefix, indicate that a route should be
+   re-advertised conditionally, based on the characteristics of the
+   inter-AS connection.
+
+4.  IANA Considerations
+
+   The IANA has registered NOPEER as a well-known community, as defined
+   in [1], as having global significance.
+
+      NOPEER (0xFFFFFF04)
+
+   This is an advisory qualification to readvertisement of a route
+   prefix, permitting an AS not to readvertise the route prefix to all
+   external bilateral peer neighbour AS's.  It is consistent with these
+   semantics that an AS may filter received prefixes that are received
+   across a peering session that the receiver regards as a bilateral
+   peer sessions
+
+5.  Security Considerations
+
+   BGP is an instance of a relaying protocol, where route information is
+   received, processed and forwarded.  BGP contains no specific
+   mechanisms to prevent the unauthorized modification of the
+   information by a forwarding agent, allowing routing information to be
+   modified, deleted or false information to be inserted without the
+   knowledge of the originator of the routing information or any of the
+   recipients.
+
+   The NOPEER community does not alter this overall situation concerning
+   the integrity of BGP as a routing system.
+
+   Use of the NOPEER community has the capability to introduce
+   additional attack mechanisms into BGP by allowing the potential for
+   man-in-the-middle, session-hijacking, or denial of service attacks
+   for an address prefix range being launched by a remote AS.
+
+   Unauthorized addition of this community to a route prefix by a
+   transit provider where there is no covering aggregate route prefix
+   may cause a denial of service attack based on denial of reachability
+   to the prefix.  Even in the case that there is a covering aggregate,
+   if the more specific route has a different origin AS than the
+
+
+
+
+
+Huston                       Informational                      [Page 5]
+
+RFC 3765                         NOPEER                       April 2004
+
+
+   aggregate, the addition of this community by a transit AS may cause a
+   denial of service attack on the origin AS of the more specific
+   prefix.
+
+   BGP is already vulnerable to a denial of service attack based on the
+   injection of false routing information.  It is possible to use this
+   community to limit the redistribution of a false route entry such
+   that its visibility can be limited and detection and rectification of
+   the problem can be more difficult under the circumstances of limited
+   redistribution.
+
+6.  References
+
+6.1.  Normative References
+
+   [1] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities
+       Attribute", RFC 1997, August 1996.
+
+6.2.  Informative References
+
+   [2] Huston, G., "Commentary on Inter-Domain Routing in the Internet",
+       RFC 3221, December 2001.
+
+7.  Author's Address
+
+   Geoff Huston
+   Telstra
+
+   EMail: gih@telstra.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston                       Informational                      [Page 6]
+
+RFC 3765                         NOPEER                       April 2004
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Huston                       Informational                      [Page 7]
+