Network Working Group Yakov Rekhter
Internet Draft Juniper Networks
Expiration Date: April 2005 Eric Rosen
Network Working Group Cisco Systems
Use of PE-PE GRE or IP in BGP/MPLS IP Virtual Private Networks
draft-ietf-l3vpn-gre-ip-2547-03.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 2, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
draft-ietf-l3vpn-gre-ip-2547-03.txt [Page 1]
Internet Draft draft-ietf-l3vpn-gre-ip-2547-03.txt October 2004
1. Abstract
This draft describes a variation of BGP/MPLS IP Virtual Private
Networks (VPNs) in which the outermost MPLS label of a VPN packet
(the tunnel label) is replaced with either IP or a Generic Routing
Encapsulation (GRE). This enables the VPN packets to be carried over
non-MPLS networks.
2. Specification of Requirements
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].
3. Introduction
In "conventional" BGP/MPLS IP VPNs ([BGP-MPLS-VPN]), when an ingress
PE router receives a packet from a CE router, it looks up the
packet's destination IP address, or in the case of Carriers' Carriers
the packet's top MPLS label in a VRF (the VRF is chosen based on the
packet's ingress attachment circuit ([BGP-MPLS-VPN])). As a result of
this lookup, the (ingress) PE router determines an MPLS label stack,
a data link header, and an output interface. The label stack is
prepended to the packet, the data link header is prepended to that,
and the resulting frame is queued for the output interface.
The bottom label in the MPLS label stack prepended to the packet is
called the VPN route label ([BGP-MPLS-VPN]). The VPN route label will
not be seen until the packet reaches the egress PE router. This label
controls forwarding of the packet by the egress PE router. The upper
label in the MPLS label stack is called the tunnel label ([BGP-MPLS-
VPN]). The purpose of the tunnel label is to cause the packet to be
delivered to the egress PE router which understands the VPN route
label.
What we discuss here are procedures for creating an MPLS packet which
carries the VPN route label, but does not carry the tunnel label, and
then using either GRE or IP encapsulation to carry that MPLS packet
across the network. That is, the tunnel label is replaced with an IP
header, and in the case of GRE encapsulation a GRE header as well.
draft-ietf-l3vpn-gre-ip-2547-03.txt [Page 2]
Internet Draft draft-ietf-l3vpn-gre-ip-2547-03.txt October 2004
4. Motivations
"Conventional" BGP/MPLS IP VPNs require that there be an MPLS Label
Switched Path (LSP) between a packet's ingress PE router and its
egress PE router. This means that a BGP/MPLS IP VPN cannot be
implemented if there is a part of the path between the ingress and
egress PE routers which does not support MPLS.
In order to enable BGP/MPLS IP VPNs to be deployed even when there
are non-MPLS routers along the path between the ingress and egress PE
routers, it is desirable to have an alternative which allows the
tunnel label to be replaced with either IP or (IP + GRE) header. The
encapsulation header would have the address of the egress PE router
in its destination IP address field, and this would cause the packet
to be delivered to the egress PE router.
In this procedure, the ingress and egress PE routers themselves MUST
support MPLS, but that is not an issue, as those routers MUST
necessarily have BGP/MPLS IP VPN support, whereas the transit routers
arguably should be able to be "vanilla" routers with no special MPLS
or VPN support.
5. Specification
In short, the technical approach specified here is:
1. Continue to use MPLS to identify a VPN route, by continuing to
add an MPLS label stack to the VPN packets. Between the ingress
and the egress PE router the top label of the label stack will
contain that label (the top label will be the VPN route label).
2. An MPLS-in-GRE or MPLS-in-IP [MPLS-GRE-IP] encapsulation will
be used to turn the above MPLS packet back into an IP packet. This
in effect creates a GRE or an IP tunnel between the ingress PE
router and the egress PE router.
The net effect is that an MPLS packet gets sent through a GRE or an
IP tunnel.
5.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE
The following description is not meant to specify an implementation
strategy; any implementation procedure which produces the same result
is acceptable.
When an (ingress) PE router receives a packet from a CE router, it
draft-ietf-l3vpn-gre-ip-2547-03.txt [Page 3]
Internet Draft draft-ietf-l3vpn-gre-ip-2547-03.txt October 2004
looks up the packet's destination IP address, or in the case of
Carriers' Carriers the packet's top MPLS label in a VRF (the VRF is
chosen based on the packet's ingress attachment circuit ([BGP-MPLS-
VPN])). This enables the (ingress) PE router to find a VPN-IP route.
The VPN-IP route will have an associated VPN route label and an
associated BGP Next Hop. The label is pushed on the packet. Then an
IP (or IP+GRE) encapsulation header is prepended to the packet,
creating an MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. The IP
source address field of the encapsulation header will be an address
of the ingress PE router itself. The IP destination address field of
the encapsulation header will contain the value of the associated BGP
Next Hop; this will be an IP address of the egress PE router.
The effect is to dynamically create an IP (or GRE) tunnel between the
ingress and egress PE routers. No apriori configuration of the remote
tunnel endpoints is needed. Note that these tunnels SHOULD NOT be
IGP-visible links, and routing adjacencies SHOULD NOT be supported
across these tunnel. Note also that the set of remote tunnel
endpoints is not known in advance, but is learned dynamically via the
BGP distribution of VPN-IP routes ([BGP-MPLS-VPN]). The IP address of
the remote tunnel endpoints is carried in the Network Address of the
Next Hop field of the MP_REACH_NLRI BGP attribute ([RFC2858]).
5.2. MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE
We assume that every egress PE is also an ingress PE, and hence has
the ability to decapsulate MPLS-in-IP (or MPLS-in-GRE) packets.
After decapsulation, the packets SHOULD be delivered to the routing
function for ordinary MPLS switching.
6. Implications on packet spoofing
It should be noted that if the tunnel MPLS labels are replaced with
an unsecured IP encapsulation, like GRE or IP, it becomes more
difficult to protect the VPNs against spoofed packets. This is
because a Service Provider (SP) can protect against spoofed MPLS
packets by the simple expedient of not accepting MPLS packets from
outside its own boundaries (or more generally by keeping track of
which labels are validly received over which interfaces, and
discarding packets which arrive with labels that are not valid for
their incoming interfaces).
In contrast to protection against spoofed MPLS packets, protection
against spoofed IP packets requires having all the boundary routers
of the SP to perform filtering; either (a) filtering out packets from
"outside" of the SP which are addressed to PE routers, or (b)
draft-ietf-l3vpn-gre-ip-2547-03.txt [Page 4]
Internet Draft draft-ietf-l3vpn-gre-ip-2547-03.txt October 2004
filtering out packets from "outside" of the SP which have source
addresses that belong "inside" and, in addition, filtering on each PE
all packets which have source addresses that belong "outside" of the
SP. The maintenance of these filter lists can be management-
intensive, and, depending on the implementation, their use at all
boundary routers may affect the performance seen by all traffic
entering the SP's network. However, such filters may be required for
reasons other than protection against spoofing of VPN packets, in
which case the additional maintenance overhead of these filters to
protect (among other things) against spoofing of VPN packets may be
of no practical significance. Note that allocating IP addresses used
for GRE or IP tunnels out of a single (or a small number of) IP block
could simplify maintenance of the filters.
The filtering described in the previous paragraph works only within a
single SP network. It is not clear whether (and how) this filtering
could be extended to support multiple SP networks. That makes the
scheme described in this document fairly problematic in the multi-
provider environment.
7. Security Considerations
Security considerations in [MPLS-GRE-IP] apply here as well.
Additional security issues are discussed in the section "Implications
on packet spoofing" above.
8. IANA Considerations
No actions for IANA required.
draft-ietf-l3vpn-gre-ip-2547-03.txt [Page 5]
Internet Draft draft-ietf-l3vpn-gre-ip-2547-03.txt October 2004
9. Intellectual Property Statement
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 at ietf.org.
10. Disclaimer of Validity
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.
draft-ietf-l3vpn-gre-ip-2547-03.txt [Page 6]
Internet Draft draft-ietf-l3vpn-gre-ip-2547-03.txt October 2004
11. 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.
12. Acknowledgment
Most of the text in this document is "borrowed" almost verbatim from
draft-rosen-ppvpn-ipsec-2547-00.txt.
Funding for the RFC Editor function is currently provided by the
Internet Society.
13. Normative References
[BGP-MPLS-VPN] "BGP/MPLS IP VPNs", Rosen E., Rekhter, Y., draft-ietf-
l3vpn-rfc2547bis-01.txt
[MPLS-GRE-IP] "Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", Rekhter, Y., Rosen, E., draft-ietf-mpls-in-ip-
or-gre-06.txt
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2858] "Multiprotocol Extensions for BGP-4", Rekhter, Y., Chandra,
R., Katz, D., RFC2858, June 2000
14. Authors' Addresses
Yakov Rekhter
Juniper Networks
E-mail: yakov@juniper.net
Eric C. Rosen
Cisco Systems, Inc.
E-mail: erosen@cisco.com
draft-ietf-l3vpn-gre-ip-2547-03.txt [Page 7]
