BGP/MPLS IP Virtual Private Networks (VPNs)
RFC 4364
| Document | Type |
RFC
- Proposed Standard
(February 2006)
Errata
IPR
Obsoletes RFC 2547
|
|
|---|---|---|---|
| Authors | Yakov Rekhter , Eric C. Rosen | ||
| Last updated | 2020-01-21 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Dr. Thomas Narten | |
| Send notices to | (None) |
RFC 4364
#x27;s ingress PE to its egress PE.
11. Accessing the Internet from a VPN
Many VPN sites will need to be able to access the public Internet, as
well as to access other VPN sites. The following describes some of
the alternative ways of doing this.
1. In some VPNs, one or more of the sites will obtain Internet
access by means of an "Internet gateway" (perhaps a firewall)
attached to a non-VRF interface to an ISP. The ISP may or may
not be the same organization as the SP that is providing the
VPN service. Traffic to/from the Internet gateway would then
be routed according to the PE router's default forwarding
table.
In this case, the sites that have Internet access may be
distributing a default route to their PEs, which in turn
redistribute it to other PEs and hence into other sites of the
VPN. This provides Internet access for all of the VPN's sites.
In order to properly handle traffic from the Internet, the ISP
must distribute, to the Internet, routes leading to addresses
that are within the VPN. This is completely independent of any
of the route distribution procedures described in this
document. The internal structure of the VPN will in general
not be visible from the Internet; such routes would simply lead
to the non-VRF interface that attaches to the VPN's Internet
gateway.
In this model, there is no exchange of routes between a PE
router's default forwarding table and any of its VRFs. VPN
route distribution procedures and Internet route distribution
procedures are completely independent.
Note that although some sites of the VPN use a VRF interface to
communicate with the Internet, ultimately all packets to/from
the Internet traverse a non-VRF interface before
leaving/entering the VPN, so we refer to this as "non-VRF
Internet access".
Note that the PE router to which the non-VRF interface attaches
does not necessarily need to maintain all the Internet routes
in its default forwarding table. The default forwarding table
could have as few as one route, "default", which leads to
Rosen & Rekhter Standards Track [Page 34]
RFC 4364 BGP/MPLS IP VPNs February 2006
another router (probably an adjacent one) that has the Internet
routes. A variation of this scheme is to tunnel packets
received over the non-VRF interface from the PE router to
another router, where this other router maintains the full set
of Internet routes.
2. Some VPNs may obtain Internet access via a VRF interface ("VRF
Internet access"). If a packet is received by a PE over a VRF
interface, and if the packet's destination address does not
match any route in the VRF, then it may be matched against the
PE's default forwarding table. If a match is made there, the
packet can be forwarded natively through the backbone to the
Internet, instead of being forwarded by MPLS.
In order for traffic to flow natively in the opposite direction
(from Internet to VRF interface), some of the routes from the
VRF must be exported to the Internet forwarding table.
Needless to say, any such routes must correspond to globally
unique addresses.
In this scheme, the default forwarding table might have the
full set of Internet routes, or it might have as little as a
single default route leading to another router that does have
the full set of Internet routes in its default forwarding
table.
3. Suppose the PE has the capability to store "non-VPN routes" in
a VRF. If a packet's destination address matches a "non-VPN
route", then the packet is transmitted natively, rather than
being transmitted via MPLS. If the VRF contains a non-VPN
default route, all packets for the public Internet will match
it, and be forwarded natively to the default route's next hop.
At that next hop, the packets' destination addresses will be
looked up in the default forwarding table, and may match more
specific routes.
This technique would only be available if none of the CE
routers is distributing a default route.
4. It is also possible to obtain Internet access via a VRF
interface by having the VRF contain the Internet routes.
Compared with model 2, this eliminates the second lookup, but
it has the disadvantage of requiring the Internet routes to be
replicated in each such VRF.
If this technique is used, the SP may want to make its
interface to the Internet be a VRF interface, and to use the
Rosen & Rekhter Standards Track [Page 35]
RFC 4364 BGP/MPLS IP VPNs February 2006
techniques of Section 4 to distribute Internet routes, as VPN-
IPv4 routes, to other VRFs.
It should be clearly understood that by default, there is no exchange
of routes between a VRF and the default forwarding table. This is
done ONLY upon agreement between a customer and an SP, and only if it
suits the customer's policies.
12. Management VPNs
This specification does not require that the sub-interface connecting
a PE router and a CE router be a "numbered" interface. If it is a
numbered interface, this specification allows the addresses assigned
to the interface to come from either the address space of the VPN or
the address space of the SP.
If a CE router is being managed by the Service Provider, then the
Service Provider will likely have a network management system that
needs to be able to communicate with the CE router. In this case,
the addresses assigned to the sub-interface connecting the CE and PE
routers should come from the SP's address space, and should be unique
within that space. The network management system should itself
connect to a PE router (more precisely, be at a site that connects to
a PE router) via a VRF interface. The address of the network
management system will be exported to all VRFs that are associated
with interfaces to CE routers that are managed by the SP. The
addresses of the CE routers will be exported to the VRF associated
with the network management system, but not to any other VRFs.
This allows communication between the CE and network management
system, but does not allow any undesired communication to or among
the CE routers.
One way to ensure that the proper route import/exports are done is to
use two Route Targets; call them T1 and T2. If a particular VRF
interface attaches to a CE router that is managed by the SP, then
that VRF is configured to:
- import routes that have T1 attached to them, and
- attach T2 to addresses assigned to each end of its VRF
interfaces.
If a particular VRF interface attaches to the SP's network management
system, then that VRF is configured to attach T1 to the address of
that system, and to import routes that have T2 attached to them.
Rosen & Rekhter Standards Track [Page 36]
RFC 4364 BGP/MPLS IP VPNs February 2006
13. Security Considerations
13.1. Data Plane
By security in the "data plane", we mean protection against the
following possibilities:
- Packets from within a VPN travel to a site outside the VPN, other
than in a manner consistent with the policies of the VPN.
- Packets from outside a VPN enter one of the VPN's sites, other
than in a manner consistent with the policies of the VPN.
Under the following conditions:
1. a backbone router does not accept labeled packets over a
particular data link, unless it is known that that data link
attaches only to trusted systems, or unless it is known that
such packets will leave the backbone before the IP header or
any labels lower in the stack will be inspected, and
2. labeled VPN-IPv4 routes are not accepted from untrusted or
unreliable routing peers,
3. no successful attacks have been mounted on the control plane,
the data plane security provided by this architecture is virtually
identical to that provided to VPNs by Frame Relay or ATM backbones.
If the devices under the control of the SP are properly configured,
data will not enter or leave a VPN unless authorized to do so.
Condition 1 above can be stated more precisely. One should discard a
labeled packet received from a particular neighbor unless one of the
following two conditions holds:
- the packet's top label has a label value that the receiving
system has distributed to that neighbor, or
- the packet's top label has a label value that the receiving
system has distributed to a system beyond that neighbor (i.e.,
when it is known that the path from the system to which the label
was distributed to the receiving system may be via that
neighbor).
Rosen & Rekhter Standards Track [Page 37]
RFC 4364 BGP/MPLS IP VPNs February 2006
Condition 2 above is of most interest in the case of inter-provider
VPNs (see Section 10). For inter-provider VPNs constructed according
to scheme b) of Section 10, condition 2 is easily checked. (The
issue of security when scheme (c) of Section 10 is used is for
further study.)
It is worth noting that the use of MPLS makes it much simpler to
provide data plane security than might be possible if one attempted
to use some form of IP tunneling in place of the MPLS outer label.
It is a simple matter to have one's border routers refuse to accept a
labeled packet unless the first of the above conditions applies to
it. It is rather more difficult to configure a router to refuse to
accept an IP packet if that packet is an IP tunneled packet whose
destination address is that of a PE router; certainly, this is not
impossible to do, but it has both management and performance
implications.
MPLS-in-IP and MPLS-in-GRE tunneling are specified in
[MPLS-in-IP-GRE]. If it is desired to use such tunnels to carry VPN
packets, then the security considerations described in Section 8 of
that document must be fully understood. Any implementation of
BGP/MPLS IP VPNs that allows VPN packets to be tunneled as described
in that document MUST contain an implementation of IPsec that can be
used as therein described. If the tunnel is not secured by IPsec,
then the technique of IP address filtering at the border routers,
described in Section 8.2 of that document, is the only means of
ensuring that a packet that exits the tunnel at a particular egress
PE was actually placed in the tunnel by the proper tunnel head node
(i.e., that the packet does not have a spoofed source address).
Since border routers frequently filter only source addresses, packet
filtering may not be effective unless the egress PE can check the IP
source address of any tunneled packet it receives, and compare it to
a list of IP addresses that are valid tunnel head addresses. Any
implementation that allows MPLS-in-IP and/or MPLS-in-GRE tunneling to
be used without IPsec MUST allow the egress PE to validate in this
manner the IP source address of any tunneled packet that it receives.
In the case where a number of CE routers attach to a PE router via a
LAN interface, to ensure proper security, one of the following
conditions must hold:
1. All the CE routers on the LAN belong to the same VPN, or
2. A trusted and secured LAN switch divides the LAN into multiple
VLANs, with each VLAN containing only systems of a single VPN;
in this case, the switch will attach the appropriate VLAN tag
to any packet before forwarding it to the PE router.
Rosen & Rekhter Standards Track [Page 38]
RFC 4364 BGP/MPLS IP VPNs February 2006
Cryptographic privacy is not provided by this architecture, nor by
Frame Relay or ATM VPNs. These architectures are all compatible with
the use of cryptography on a CE-CE basis, if that is desired.
The use of cryptography on a PE-PE basis is for further study.
13.2. Control Plane
The data plane security of the previous section depends on the
security of the control plane. To ensure security, neither BGP nor
LDP connections should be made with untrusted peers. The TCP/IP MD5
authentication option [TCP-MD5] should be used with both these
protocols. The routing protocol within the SP's network should also
be secured in a similar manner.
13.3. Security of P and PE Devices
If the physical security of these devices is compromised, data plane
security may also be compromised.
The usual steps should be taken to ensure that IP traffic from the
public Internet cannot be used to modify the configuration of these
devices, or to mount Denial of Service attacks on them.
14. Quality of Service
Although not the focus of this paper, Quality of Service is a key
component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS
capabilities can be applied to labeled packets through the use of the
"experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM
is used as the backbone, through the use of ATM QoS capabilities.
The traffic engineering work discussed in [MPLS-RSVP] is also
directly applicable to MPLS/BGP VPNs. Traffic engineering could even
be used to establish label switched paths with particular QoS
characteristics between particular pairs of sites, if that is
desirable. Where an MPLS/BGP VPN spans multiple SPs, the
architecture described in [PASTE] may be useful. An SP may apply
either intserv (Integrated Services) or diffserv (Differentiated
Services) capabilities to a particular VPN, as appropriate.
Rosen & Rekhter Standards Track [Page 39]
RFC 4364 BGP/MPLS IP VPNs February 2006
15. Scalability
We have discussed scalability issues throughout this paper. In this
section, we briefly summarize the main characteristics of our model
with respect to scalability.
The Service Provider backbone network consists of (a) PE routers, (b)
BGP Route Reflectors, (c) P routers (that are neither PE routers nor
Route Reflectors), and, in the case of multi-provider VPNs, (d)
ASBRs.
P routers do not maintain any VPN routes. In order to properly
forward VPN traffic, the P routers need only maintain routes to the
PE routers and the ASBRs. The use of two levels of labeling is what
makes it possible to keep the VPN routes out of the P routers.
A PE router maintains VPN routes, but only for those VPNs to which it
is directly attached.
Route reflectors can be partitioned among VPNs so that each partition
carries routes for only a subset of the VPNs supported by the Service
Provider. Thus, no single route reflector is required to maintain
routes for all VPNs.
For inter-provider VPNs, if the ASBRs maintain and distribute VPN-
IPv4 routes, then the ASBRs can be partitioned among VPNs in a
similar manner, with the result that no single ASBR is required to
maintain routes for all the inter-provider VPNs. If multi-hop EBGP
is used, then the ASBRs need not maintain and distribute VPN-IPv4
routes at all.
As a result, no single component within the Service Provider network
has to maintain all the routes for all the VPNs. So the total
capacity of the network to support increasing numbers of VPNs is not
limited by the capacity of any individual component.
16. IANA Considerations
The Internet Assigned Numbers Authority (IANA) has created a new
registry for the "Route Distinguisher Type Field" (see Section 4.2).
This is a two-byte field. Types 0, 1, and 2 are defined by this
document. Additional Route Distinguisher Type Field values with a
high-order bit of 0 may be allocated by IANA on a "First Come, First
Served" basis [IANA]. Values with a high-order bit of 1 may be
allocated by IANA based on "IETF consensus" [IANA].
Rosen & Rekhter Standards Track [Page 40]
RFC 4364 BGP/MPLS IP VPNs February 2006
This document specifies (see Section 4.3.4) the use of the BGP
Address Family Identifier (AFI) value 1, along with the BGP
Subsequent Address Family Identifier (SAFI) value 128, to represent
the address family "VPN-IPv4 Labeled Addresses", which is defined in
this document.
The use of AFI value 1 for IP is as currently specified in the IANA
registry "Address Family Identifier", so IANA need take no action
with respect to it.
The SAFI value 128 was originally specified as "Private Use" in the
IANA "Subsequent Address Family Identifier" registry. IANA has
changed the SAFI value 128 from "private use" to "MPLS-labeled VPN
address".
17. Acknowledgements
The full list of contributors can be found in Section 18.
Significant contributions to this work have also been made by Ravi
Chandra, Dan Tappan, and Bob Thomas.
We also wish to thank Shantam Biswas for his review and
contributions.
18. Contributors
Tony Bogovic
Telcordia Technologies
445 South Street, Room 1A264B
Morristown, NJ 07960
EMail: tjb@research.telcordia.com
Stephen John Brannon
Swisscom AG
Postfach 1570
CH-8301
Glattzentrum (Zuerich), Switzerland
EMail: stephen.brannon@swisscom.com
Rosen & Rekhter Standards Track [Page 41]
RFC 4364 BGP/MPLS IP VPNs February 2006
Marco Carugi
Nortel Networks S.A.
Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - FRANCE
EMail: marco.carugi@nortelnetworks.com
Christopher J. Chase
AT&T
200 Laurel Ave
Middletown, NJ 07748
USA
EMail: chase@att.com
Ting Wo Chung
Bell Nexxia
181 Bay Street
Suite 350
Toronto, Ontario
M5J2T3
EMail: ting_wo.chung@bellnexxia.com
Eric Dean
Jeremy De Clercq
Alcatel Network Strategy Group
Francis Wellesplein 1
2018 Antwerp, Belgium
EMail: jeremy.de_clercq@alcatel.be
Luyuan Fang
AT&T
IP Backbone Architecture
200 Laurel Ave.
Middletown, NJ 07748
EMail: luyuanfang@att.com
Rosen & Rekhter Standards Track [Page 42]
RFC 4364 BGP/MPLS IP VPNs February 2006
Paul Hitchen
BT
BT Adastral Park
Martlesham Heath,
Ipswich IP5 3RE
UK
EMail: paul.hitchen@bt.com
Manoj Leelanivas
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043 USA
EMail: manoj@juniper.net
Dave Marshall
Worldcom
901 International Parkway
Richardson, Texas 75081
EMail: dave.marshall@wcom.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
EMail: lmartini@cisco.com
Monique Jeanne Morrow
Cisco Systems, Inc.
Glatt-com, 2nd floor
CH-8301
Glattzentrum, Switzerland
EMail: mmorrow@cisco.com
Rosen & Rekhter Standards Track [Page 43]
RFC 4364 BGP/MPLS IP VPNs February 2006
Ravichander Vaidyanathan
Telcordia Technologies
445 South Street, Room 1C258B
Morristown, NJ 07960
EMail: vravi@research.telcordia.com
Adrian Smith
BT
BT Adastral Park
Martlesham Heath,
Ipswich IP5 3RE
UK
EMail: adrian.ca.smith@bt.com
Vijay Srinivasan
1200 Bridge Parkway
Redwood City, CA 94065
EMail: vsriniva@cosinecom.com
Alain Vedrenne
Equant
Heraklion, 1041 route des Dolines, BP347
06906 Sophia Antipolis, Cedex, France
EMail: Alain.Vedrenne@equant.com
19. Normative References
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006.
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858,
June 2000.
[BGP-EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP
Extended Communities Attribute", RFC 4360, February
2006.
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
Rosen & Rekhter Standards Track [Page 44]
RFC 4364 BGP/MPLS IP VPNs February 2006
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label
Information in BGP-4", RFC 3107, May 2001.
[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001.
20. Informative References
[BGP-AS4] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
AS Number Space", Work in Progress, March 2004.
[BGP-ORF] Chen, E. and Y. Rekhter, "Cooperative Route
Filtering Capability for BGP-4", Work in Progress,
March 2004.
[BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC
2918, September 2000.
[BGP-RR] Bates, T., Chandra, R., and E. Chen, "BGP Route
Reflection - An Alternative to Full Mesh IBGP", RFC
2796, April 2000.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Swallow, G., Rekhter, Y., and P. Doolan, "MPLS
using LDP and ATM VC Switching", RFC 3035, January
2001.
[MPLS/BGP-IPsec] Rosen, E., De Clercq, J., Paridaens, O., T'Joens,
Y., and C. Sargor, "Architecture for the Use of
PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Work in
Progress, March 2004.
[MPLS-FR] Conta, A., Doolan, P., and A. Malis, "Use of Label
Switching on Frame Relay Networks Specification",
RFC 3034, January 2001.
[MPLS-in-IP-GRE] Worster, T., Rekhter, Y., and E. Rosen,
"Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", RFC 4023, March 2005.
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette,
A., and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
Rosen & Rekhter Standards Track [Page 45]
RFC 4364 BGP/MPLS IP VPNs February 2006
[MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., and G. Swallow, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[PASTE] Li, T. and Y. Rekhter, "A Provider Architecture for
Differentiated Services and Traffic Engineering
(PASTE)", RFC 2430, October 1998.
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[OSPF-2547-DNBIT] Rosen, E., Psenak, P., and P. Pillay-Esnault,
"Using an LSA Options Bit to Prevent Looping in
BGP/MPLS IP VPNs", Work in Progress, March 2004.
[TCP-MD5] Heffernan, A., "Protection of BGP Sessions via the
TCP MD5 Signature Option", RFC 2385, August 1998.
[VPN-MCAST] Rosen, E., Cai, Y., and J. Wijsnands, "Multicast in
MPLS/BGP VPNs", Work in Progress, May 2004.
[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF
as the PE/CE Protocol in BGP/MPLS VPNs", Work in
Progress, February 2004.
Authors' Addresses
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.com
Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
EMail: yakov@juniper.net
Rosen & Rekhter Standards Track [Page 46]
RFC 4364 BGP/MPLS IP VPNs February 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 provided by the IETF
Administrative Support Activity (IASA).
Rosen & Rekhter Standards Track [Page 47]