7
Network Working Group G. Huston
8
Request for Comments: 3765 Telstra
9
Category: Informational April 2004
12
NOPEER Community for Border Gateway Protocol (BGP)
17
This memo provides information for the Internet community. It does
18
not specify an Internet standard of any kind. Distribution of this
23
Copyright (C) The Internet Society (2004). All Rights Reserved.
27
This document describes the use of a scope control Border Gateway
28
Protocol (BGP) community. This well-known advisory transitive
29
community allows an origin AS to specify the extent to which a
30
specific route should be externally propagated. In particular this
31
community, NOPEER, allows an origin AS to specify that a route with
32
this attribute need not be advertised across bilateral peer
37
BGP today has a limited number of commonly defined mechanisms that
38
allow a route to be propagated across some subset of the routing
39
system. The NOEXPORT community allows a BGP speaker to specify that
40
redistribution should extend only to the neighbouring AS. Providers
41
commonly define a number of communities that allow their neighbours
42
to specify how advertised routes should be re-advertised. Current
43
operational practice is that such communities are defined on as AS by
44
AS basis, and while they allow an AS to influence the re-
45
advertisement behaviour of routes passed from a neighbouring AS, they
46
do not allow this scope definition ability to be passed in a
47
transitive fashion to a remote AS.
49
Advertisement scope specification is of most use in specifying the
50
boundary conditions of route propagation. The specification can take
51
on a number of forms, including as AS transit hop count, a set of
52
target ASs, the presence of a particular route object, or a
53
particular characteristic of the inter-AS connection.
58
Huston Informational [Page 1]
60
RFC 3765 NOPEER April 2004
63
There are a number of motivations for controlling the scope of
64
advertisement of route prefixes, including support of limited transit
65
services where advertisements are restricted to certain transit
66
providers, and various forms of selective transit in a multi-homed
69
This memo does not attempt to address all such motivations of scope
70
control, and addresses in particular the situation of both multi-
71
homing and traffic engineering. The commonly adopted operational
72
technique is that the originating AS advertises an encompassing
73
aggregate route to all multi-home neighbours, and also selectively
74
advertises a collection of more specific routes. This implements a
75
form of destination-based traffic engineering with some level of fail
76
over protection. The more specific routes typically cease to lever
77
any useful traffic engineering outcome beyond a certain radius of
78
redistribution, and a means of advising that such routes need not to
79
be distributed beyond such a point is of some value in moderating one
80
of the factors of continued route table growth.
82
Analysis of the BGP routing tables reveals a significant use of the
83
technique of advertising more specific prefixes in addition to
84
advertising a covering aggregate. In an effort to ameliorate some of
85
the effects of this practice, in terms of overall growth of the BGP
86
routing tables in the Internet and the associated burden of global
87
propagation of dynamic changes in the reachability of such more
88
specific address prefixes, this memo describes the use of a
89
transitive BGP route attribute that allows more specific route tables
90
entries to be discarded from the BGP tables under appropriate
91
conditions. Specifically, this attribute, NOPEER, allows a remote AS
92
not to advertise a route object to a neighbour AS when the two AS's
93
are interconnected under the conditions of some form of sender keep
94
all arrangement, as distinct from some form of provider / customer
99
This memo defines the use a new well-known bgp transitive community,
102
The semantics of this attribute is to allow an AS to interpret the
103
presence of this community as an advisory qualification to
104
readvertisement of a route prefix, permitting an AS not to
105
readvertise the route prefix to all external bilateral peer neighbour
106
AS's. It is consistent with these semantics that an AS may filter
107
received prefixes that are received across a peering session that the
108
receiver regards as a bilateral peer sessions.
114
Huston Informational [Page 2]
116
RFC 3765 NOPEER April 2004
121
The size of the BGP routing table has been increasing at an
122
accelerating rate since late 1998. At the time of publication of
123
this memo the BGP forwarding table contains over 118,000 entries, and
124
the three year growth rate of this table shows a trend rate which can
125
be correlated to a compound growth rate of no less than 10% per year
128
One of the aspects of the current BGP routing table is the widespread
129
use of the technique of advertising both an aggregate and a number of
130
more specific address prefixes. For example, the table may contain a
131
routing entry for the prefix 10.0.0.0/23 and also contain entries for
132
the prefixes 10.0.0.0/24 and 10.0.1.0/24. In this example the
133
specific routes fully cover the aggregate announcement. Sparse
134
coverage of aggregates with more specifics is also observed, where,
135
for example, routing entries for 10.0.0.0/8 and 10.0.1.0/24 both
136
exist in the routing table. In total, these more specific route
137
entries occupy some 51% of the routing table, so that more than one
138
half of the routing table does not add additional address
139
reachability information into the routing system, but instead is used
140
to impose a finer level of detail on existing reachability
143
There are a number of motivations for having both an aggregate route
144
and a number of more specific routes in the routing table, including
145
various forms of multi-homed configurations, where there is a
146
requirement to specify a different reachability policy for a part of
147
the advertised address space.
149
One of the observed common requirements in the multi-homed network
150
configuration is that of undertaking some form of load balancing of
151
incoming traffic across a number of external connections to a number
152
of different neighbouring ASs. If, for example, an AS wishes to use
153
a multi-homed configuration for routing-based load balancing and some
154
form of mutual fail over between the multiple access connections for
155
incoming traffic, then one approach is for the AS to advertise the
156
same aggregate address prefix to a number of its upstream transit
157
providers, and then advertise a number of more specifics to
158
individual upstream providers. In such a case all of the traffic
159
destined to the more specific address prefixes will be received only
160
over those connections where the more specific has been advertised.
161
If the neighbour BGP peering session of the more specific
162
advertisement fails, the more specific will cease to be announced and
163
incoming traffic will then be passed to the originating network based
164
on the path associated with the advertisement of the encompassing
165
aggregate. In this situation the more specific routes are not
166
automatically subsumed by the presence of the aggregate at any remote
170
Huston Informational [Page 3]
172
RFC 3765 NOPEER April 2004
175
AS. Both the aggregate and the associated more specific routes are
176
redistributed across the entire external BGP routing domain. In many
177
cases, particularly those associated with desire to undertake traffic
178
engineering and service resilience, the more specific routes are
179
redistributed well beyond the scope where there is any outcomes in
180
terms of traffic differentiation.
182
To the extent that remote analysis of BGP tables can observe this
183
form of configuration, the number of entries in the BGP forwarding
184
table where more specific entries share a common origin AS with their
185
immediately enclosing aggregates comprise some 20% of the total
186
number of FIB entries. Using a slightly stricter criteria where the
187
AS path of the more specific route matches the immediately enclosing
188
aggregate, the number of more specific routes comprises some 14% of
189
the number of FIB entries.
191
One protocol mechanism that could be useful in this context is to
192
allow the originator of an advertisement to state some additional
193
qualification on the redistribution of the advertisement, allowing a
194
remote AS to suppress further redistribution under some originator-
197
The redistribution qualification condition can be specified either by
198
enumeration or by classification. Enumeration would encompass the
199
use of a well-known transitive extended community to specify a list
200
of remote AS's where further redistribution is not advised. The
201
weakness of this approach is that the originating AS would need to
202
constantly revise this enumerated AS list to reflect the changes in
203
inter-AS topology, as, otherwise, the more specific routes would leak
204
beyond the intended redistribution scope. An approach of
205
classification allows an originating AS to specify the conditions
206
where further redistribution is not advised without having to refer
207
to the particular AS's where a match to such conditions are
210
The approach described here to specifying the redistribution boundary
211
condition is one based on the type of bilateral inter-AS peering.
212
Where one AS can be considered as a customer, and the other AS can be
213
considered as a contracted agent of the customer, or provider, then
214
the relationship is one where the provider, as an agent of the
215
customer, carries the routes and associated policy associated with
216
the routes. Where neither AS can be considered as a customer of the
217
other, then the relationship is one of bilateral peering, and neither
218
AS can be considered as an agent of the other in redistributing
219
policies associated with routes. This latter arrangement is commonly
220
referred to as a "sender keep all peer" relationship, or "peering".
226
Huston Informational [Page 4]
228
RFC 3765 NOPEER April 2004
231
This peer boundary can be regarded as a logical point where the
232
redistribution of additional reachability policy imposed by the
233
origin AS on a route is no longer an imposed requirement.
235
This approach allows an originator of a prefix to attach a commonly
236
defined policy to a route prefix, indicate that a route should be
237
re-advertised conditionally, based on the characteristics of the
240
4. IANA Considerations
242
The IANA has registered NOPEER as a well-known community, as defined
243
in [1], as having global significance.
247
This is an advisory qualification to readvertisement of a route
248
prefix, permitting an AS not to readvertise the route prefix to all
249
external bilateral peer neighbour AS's. It is consistent with these
250
semantics that an AS may filter received prefixes that are received
251
across a peering session that the receiver regards as a bilateral
254
5. Security Considerations
256
BGP is an instance of a relaying protocol, where route information is
257
received, processed and forwarded. BGP contains no specific
258
mechanisms to prevent the unauthorized modification of the
259
information by a forwarding agent, allowing routing information to be
260
modified, deleted or false information to be inserted without the
261
knowledge of the originator of the routing information or any of the
264
The NOPEER community does not alter this overall situation concerning
265
the integrity of BGP as a routing system.
267
Use of the NOPEER community has the capability to introduce
268
additional attack mechanisms into BGP by allowing the potential for
269
man-in-the-middle, session-hijacking, or denial of service attacks
270
for an address prefix range being launched by a remote AS.
272
Unauthorized addition of this community to a route prefix by a
273
transit provider where there is no covering aggregate route prefix
274
may cause a denial of service attack based on denial of reachability
275
to the prefix. Even in the case that there is a covering aggregate,
276
if the more specific route has a different origin AS than the
282
Huston Informational [Page 5]
284
RFC 3765 NOPEER April 2004
287
aggregate, the addition of this community by a transit AS may cause a
288
denial of service attack on the origin AS of the more specific
291
BGP is already vulnerable to a denial of service attack based on the
292
injection of false routing information. It is possible to use this
293
community to limit the redistribution of a false route entry such
294
that its visibility can be limited and detection and rectification of
295
the problem can be more difficult under the circumstances of limited
300
6.1. Normative References
302
[1] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities
303
Attribute", RFC 1997, August 1996.
305
6.2. Informative References
307
[2] Huston, G., "Commentary on Inter-Domain Routing in the Internet",
308
RFC 3221, December 2001.
315
EMail: gih@telstra.net
338
Huston Informational [Page 6]
340
RFC 3765 NOPEER April 2004
343
8. Full Copyright Statement
345
Copyright (C) The Internet Society (2004). This document is subject
346
to the rights, licenses and restrictions contained in BCP 78 and
347
except as set forth therein, the authors retain all their rights.
349
This document and the information contained herein are provided on an
350
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
351
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
352
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
353
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
354
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
355
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
357
Intellectual Property
359
The IETF takes no position regarding the validity or scope of any
360
Intellectual Property Rights or other rights that might be claimed to
361
pertain to the implementation or use of the technology described in
362
this document or the extent to which any license under such rights
363
might or might not be available; nor does it represent that it has
364
made any independent effort to identify any such rights. Information
365
on the procedures with respect to rights in RFC documents can be
366
found in BCP 78 and BCP 79.
368
Copies of IPR disclosures made to the IETF Secretariat and any
369
assurances of licenses to be made available, or the result of an
370
attempt made to obtain a general license or permission for the use of
371
such proprietary rights by implementers or users of this
372
specification can be obtained from the IETF on-line IPR repository at
373
http://www.ietf.org/ipr.
375
The IETF invites any interested party to bring to its attention any
376
copyrights, patents or patent applications, or other proprietary
377
rights that may cover technology that may be required to implement
378
this standard. Please address the information to the IETF at ietf-
383
Funding for the RFC Editor function is currently provided by the
394
Huston Informational [Page 7]
added
removed
dev/RFC/rfc3765.txt
