BGP ACCEPT_OWN Community Attribute
A BGP community that lets a router accept a route it originated itself, so a route reflector can steer routes between VRFs on the same router.
Uttaro, J., Mohapatra, P., Smith, D., Raszuk, R., and J. Scudder, "BGP ACCEPT_OWN Community Attribute", RFC 7611, DOI 10.17487/RFC7611, August 2015, <https://www.rfc-editor.org/info/rfc7611>.
@misc{rfc7611,
series = {Request for Comments},
number = 7611,
howpublished = {RFC 7611},
publisher = {RFC Editor},
doi = {10.17487/RFC7611},
url = {https://www.rfc-editor.org/info/rfc7611},
author = {J. Uttaro and P. Mohapatra and D. Smith and R. Raszuk and J. Scudder},
title = {{BGP ACCEPT_OWN Community Attribute}},
pagetotal = 8,
year = 2015,
month = aug,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Uttaro
Request for Comments: 7611 AT&T
Category: Standards Track P. Mohapatra
ISSN: 2070-1721 Sproute Networks
D. Smith
Cisco Systems
R. Raszuk
Mirantis Inc.
J. Scudder
Juniper Networks
August 2015
BGP ACCEPT_OWN Community Attribute
Abstract
Under certain conditions, it is desirable for a Border Gateway
Protocol (BGP) route reflector to be able to modify the Route Target
(RT) list of a Virtual Private Network (VPN) route that the route
reflector distributes, enabling the route reflector to control how a
route originated within one VPN Routing and Forwarding table (VRF) is
imported into other VRFs. This technique works effectively as long
as the VRF that exports the route is not on the same Provider Edge
(PE) router as the VRF(s) that imports the route. However, due to
the constraints of BGP, it does not work if the two are on the same
PE. This document describes a modification to BGP allowing this
technique to work when the VRFs are on the same PE and to be used in
a standard manner throughout an autonomous system.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7611.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. ACCEPT_OWN Community . . . . . . . . . . . . . . . . . . . . 3
2.1. Route Acceptance . . . . . . . . . . . . . . . . . . . . 3
2.2. Propagating ACCEPT_OWN between Address Families . . . . . 4
2.3. Configuration Control . . . . . . . . . . . . . . . . . . 4
3. Decision Process . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
5. Other Applications . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Local Extranet Application (Non-normative) . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In certain scenarios, a BGP speaker may maintain multiple VRFs
[RFC4364]. Under certain conditions, it is desirable for a route
reflector to be able to modify the RT list of a VPN route that the
route reflector distributes, enabling the route reflector to control
how a route originated within one VRF is imported into other VRFs.
Though it is possible to perform such control directly on the
originator, it may be operationally cumbersome in an autonomous
system with a large number of border routers having complex BGP
policies.
The technique of the route reflector modifying the RT list works
effectively as long as the VRF that exports the route is not on the
same PE as the VRF(s) that imports the route. However, due to
constraints of BGP, it does not work if the two are on the same PE.
This is because, per the BGP specification [RFC4271], a BGP speaker
rejects received prefix advertisements that were originated by
itself. In an autonomous system with route reflectors, the route
reflector attaches the ORIGINATOR_ID attribute to the UPDATE messages
so that if such prefix advertisements reach the originator, the
originator can reject them by simply checking the ORIGINATOR_ID
attribute. The BGP specification also mandates that a route should
not be accepted from a peer when the NEXT_HOP attribute matches the
receiver's own IP address.
This document proposes a modification to BGP's behavior by defining a
new community [RFC1997] value, in order to allow the technique of RT
list modification by the route reflector to be used in a standard
manner throughout an autonomous system, irrespective of whether or
not the VRFs are on the same or different PEs.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. ACCEPT_OWN Community
This memo defines ACCEPT_OWN, a new well-known BGP community in the
First Come First Served [RFC5226] range, whose value as assigned by
IANA is 0xFFFF0001. Processing of the ACCEPT_OWN community SHOULD be
controlled by configuration. The functionality SHOULD default to
being disabled, as further specified in Section 2.3.
2.1. Route Acceptance
A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value
matches that of the receiving speaker if all of the following are
true:
o Processing of the ACCEPT_OWN community is enabled by
configuration.
o The route in question carries the ACCEPT_OWN community.
o The route in question originated from a source VRF on the router.
The source VRF is a VRF on the router whose configured Route
Distinguisher is equal to the Route Distinguisher carried in the
route.
o The route in question is targeted to one or more destination VRFs
on the router (as determined by inspecting the Route Target(s)).
o At least one destination VRF is different from the source VRF.
A route MUST NOT ever be accepted back into its source VRF, even if
it carries one or more RTs that match that VRF.
2.2. Propagating ACCEPT_OWN between Address Families
The ACCEPT_OWN community controls propagation of routes that can be
associated with a source VRF by inspection of their Route
Distinguisher and with a target VRF by inspection of their Route
Target list (for example, VPN routes with a Subsequent Address Family
Identifier (SAFI) of 128). As such, it SHOULD NOT be attached to any
routes that cannot be associated with a source VRF. This implies
that when propagating routes into a VRF, the ACCEPT_OWN community
SHOULD NOT be propagated. Likewise, if a route carrying the
ACCEPT_OWN community is received in an address family that does not
allow the source VRF to be looked up, the ACCEPT_OWN community MUST
be discarded. An OPTIONAL message may be logged in this case.
2.3. Configuration Control
ACCEPT_OWN handling SHOULD be controlled by configuration, and if
controlled by configuration, it MUST default to being disabled. When
ACCEPT_OWN is disabled by configuration (either explicitly or by
default), the router MUST NOT apply the special route acceptance
rules detailed in Section 2.1. The router SHOULD still apply the
propagation rules detailed in Section 2.2.
3. Decision Process
If a BGP speaker supports ACCEPT_OWN and is configured for the
extensions defined in this document, the following step is inserted
after the LOCAL_PREF comparison step in the BGP decision process:
When comparing a pair of routes for a BGP destination, the route
with the ACCEPT_OWN community attached is preferred over the route
that does not have the community.
In all other respects, the decision process remains unchanged. This
extra step MUST only be invoked during the best path selection
process of VPN-IP routes [RFC4364] (i.e., it MUST NOT be invoked for
the best path selection of imported IP routes in a VRF). The purpose
of this extra step is to allow the paths advertised by the route
reflector with ACCEPT_OWN community to be selected as best over other
paths that the BGP speaker may have received, hence enabling the
applications ACCEPT_OWN is designed for.
4. Deployment Considerations
The ACCEPT_OWN community as described in this document is useful
within a single autonomous system that uses a single layer of route
reflectors. Its use with hierarchical route reflectors would require
further specification and is out of the scope of this document.
Likewise, its use across multiple autonomous systems is out of the
scope of this document.
5. Other Applications
This approach may also be relevant in other scenarios where a BGP
speaker maintains multiple routing contexts using an approach
different from that of [RFC4364], as long as the specific approach in
use has the property that the BGP speaker originates and receives
routes within a particular context. In such a case, "VRF" in this
document should be understood to mean whatever construct provides a
routing context in the specific technology under consideration.
Likewise, "Route Distinguisher" should be understood to mean whatever
construct allows a route's originator to associate that route with
its source context, and "Route Target" should be understood to mean
whatever construct allows a route to be targeted for import into a
context other than its source.
6. Security Considerations
ACCEPT_OWN as described in this document permits a router's own route
prefix to be advertised to a different VRF on that router. In this
respect, such a route is similar to any other BGP route and shares
the same set of security vulnerabilities and concerns. This
extension does not change the underlying security issues inherent in
BGP VPN [RFC4364].
7. IANA Considerations
IANA has assigned the value 0xFFFF0001 in the "BGP Well-known
Communities" registry for the ACCEPT_OWN community.
8. References
8.1. Normative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
8.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
Appendix A. Local Extranet Application (Non-normative)
One of the applications for the BGP well-known community described in
this document is auto-configuration of extranets within MPLS VPN
networks. Consider the following topology:
CE1 --------+
|
(VRF 1, RD 1, RT 1)
PE1 ................... RR
(VRF 2, RD 2, RT 2)
|
CE2 --------+
Figure 1: Extranet Application
Within this topology, PE1 receives a prefix X from CE1. Prefix X is
installed in VRF 1 and is advertised to the route reflector (RR) with
Route Distinguisher (RD) 1 and Route Target (RT) 1 as configured on
PE1. The requirement is to import prefix X into VRF 2 and advertise
it to CE2 in support of extranet VPN connectivity between CE1/VRF1
and CE2/VRF2. Current BGP mechanisms for MPLS VPNs [RFC4364] require
changing the import RT value and/or import policy for VRF 2 on PE1.
This is operationally cumbersome in a network with a large number of
border routers having complex BGP policies.
Alternatively, using the new ACCEPT_OWN community value, the route
reflector can simply re-advertise prefix X back to PE1 with RT 2
appended. In this way, PE1 will accept prefix X despite its
ORIGINATOR_ID or NEXT_HOP value, import it into VRF 2 as a result of
the presence of RT 2 in the route's Extended Community path
attribute, and then determine the correct adjacency rewrite within
VRF 1 based on the RD value and the prefix. Note that the presence
of RT 1 in the route's Extended Community path attribute will simply
be ignored since RT 1 is associated with the source VRF 1. The same
operation also needs to happen in the reverse direction (VRF 1
learning a route from VRF 2) to achieve establishment of an extranet
VPN strictly via the route reflector without changing the BGP policy
of PE1 in any way.
A router performing such an extranet application can accept a route
with its own ORIGINATOR_ID or NEXT_HOP value only if the VRF in which
the router originated the route is different from the VRF in which
the router accepts the re-advertised route.
Acknowledgments
The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence
Filsfils, John Mullooly, Jeff Haas, Pranav Mehta, and Tamas Mondal
for their valuable comments and suggestions. The decision process
changes were suggested by Pranav Mehta to solve the remote extranet
problem.
Authors' Addresses
James Uttaro
AT&T
200 S. Laurel Avenue
Middletown, NJ 07748
United States
Email: uttaro@att.com
Pradosh Mohapatra
Sproute Networks
Email: mpradosh@yahoo.com
David J. Smith
Cisco Systems
111 Wood Avenue South
Iselin, NJ 08830
United States
Email: djsmith@cisco.com
Robert Raszuk
Mirantis Inc.
615 National Ave. #100
Mountain View, CA 94043
United States
Email: robert@raszuk.net
John Scudder
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States
Email: jgs@juniper.net
AI ELI5
On this page
§1The Problem
A BGP speaker may maintain several VRFs (VPN Routing and Forwarding tables, see RFC 4364). Sometimes a route reflector should change the Route Target (RT) list of a VPN route it distributes, so that it controls how a route originated in one VRF is imported into others. Doing this on the originating router is possible, but may be operationally cumbersome in an autonomous system with many border routers and complex BGP policies.
The technique works as long as the exporting VRF is not on the same Provider Edge (PE) router as the importing VRF. If they share a PE it fails, because under RFC 4271 a BGP speaker rejects advertisements that it originated. The route reflector attaches an ORIGINATOR_ID so the originator can spot such routes, and a route should not be accepted from a peer whose NEXT_HOP equals the receiver's own address.
A router normally ignores its own mail when it comes back. That is a problem if the mail was meant for another desk in the same office.
§2The ACCEPT_OWN Community
The RFC defines ACCEPT_OWN, a new well-known BGP community (RFC 1997) in the First Come First Served range, with the value 0xFFFF0001 assigned by IANA. Processing it SHOULD be controlled by configuration and SHOULD default to disabled.
The goal is to let the RT-list technique be used in a standard way throughout an autonomous system, whether or not the VRFs are on the same PE.
The sticker has a fixed shape everywhere, so every router reads it the same way. It is off until someone turns it on.
§2.1When a Router May Accept Its Own Route
A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP matches its own, but only if all of these are true:
- ACCEPT_OWN processing is enabled by configuration.
- The route carries the ACCEPT_OWN community.
- The route originated from a source VRF on the router, meaning a VRF whose configured Route Distinguisher equals the one in the route.
- The route targets one or more destination VRFs on the router, found by inspecting its Route Targets.
- At least one destination VRF differs from the source VRF.
A route MUST NOT ever be accepted back into its source VRF, even if it carries RTs that match that VRF.
The router checks the sticker, checks the mail really came from one of its own rooms, and checks it is going to a different room. Only then does it keep it.
§2.2Propagation and Configuration Control
ACCEPT_OWN only makes sense for routes that can be tied to a source VRF through the Route Distinguisher and to a target VRF through the Route Target list, such as VPN routes with SAFI 128. So it SHOULD NOT be attached to routes that cannot be associated with a source VRF, and it SHOULD NOT be propagated when routes are propagated into a VRF. If a route carrying it arrives in an address family where the source VRF cannot be looked up, the community MUST be discarded, and a message MAY be logged.
If ACCEPT_OWN is controlled by configuration, it MUST default to disabled. When disabled, the router MUST NOT apply the special acceptance rules, but SHOULD still apply the propagation rules.
The sticker only belongs on the right kind of mail. If it turns up on the wrong kind, the router peels it off. And by default the router ignores the sticker entirely.
§3Change to the Decision Process
If a speaker supports ACCEPT_OWN and is configured for it, one step is added to the BGP decision process, right after the LOCAL_PREF comparison: when comparing two routes for a destination, the route with the ACCEPT_OWN community is preferred.
Everything else in the decision process is unchanged. The step MUST only be used when choosing the best path among VPN-IP routes, and MUST NOT be used for imported IP routes inside a VRF. Its purpose is to let the paths re-advertised by the route reflector with ACCEPT_OWN win over other paths the speaker may have received.
When two routes compete, the one with the sticker wins, so the reflector's version is the one the router uses.
§7Example: Local Extranet
The non-normative appendix shows an extranet. PE1 has VRF 1 (RD 1, RT 1) facing CE1 and VRF 2 (RD 2, RT 2) facing CE2, and connects to a route reflector (RR). PE1 learns prefix X from CE1 and advertises it to the RR with RD 1 and RT 1. The goal is to import X into VRF 2 and advertise it to CE2.
Without ACCEPT_OWN, PE1 would need its VRF 2 import RT or import policy changed, which is cumbersome in a large network. With it, the RR re-advertises X back to PE1 with RT 2 appended. PE1 accepts it, imports it into VRF 2 because of RT 2, and works out the adjacency rewrite within VRF 1 from the RD and prefix. RT 1 is ignored because it belongs to the source VRF. The same must happen in the other direction, all without changing PE1's BGP policy.
Two classrooms in one school want to share a note. Instead of rewriting each room's rules, the office stamps the note with the second room's name and sends it back.
- prefix XInstalled in VRF 1.
- X with RD 1, RT 1
- X with RT 2 and ACCEPT_OWNPE1 accepts it and imports it into VRF 2.
§6Scope, Security and IANA
ACCEPT_OWN is useful within a single autonomous system with a single layer of route reflectors. Use with hierarchical route reflectors or across autonomous systems needs further specification and is out of scope. The approach may also fit other technologies that give a speaker multiple routing contexts, with VRF, Route Distinguisher and Route Target read as the equivalent constructs.
On security, the extension lets a router's own prefix be advertised into a different VRF on that router. The RFC says such a route is like any other BGP route, shares its vulnerabilities, and does not change the underlying security issues of BGP VPN. IANA assigned 0xFFFF0001 in the BGP Well-known Communities registry.
This trick works for one network with one layer of helpers. It does not add new dangers beyond what BGP VPNs already have.