[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 4797

Network Working Group                                  Yakov Rekhter
Internet Draft                                      Juniper Networks
Expiration Date: October 2003                             Eric Rosen
Network Working Group                                  Cisco Systems

                 Use of PE-PE GRE or IP in RFC2547 VPNs


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

2. Abstract

   This draft describes a variation of RFC2547 [RFC2547] in which the
   outermost MPLS label of a VPN packet is replaced with either IP or a
   GRE encapsulation. This enables the VPN packets to be carried over
   non-MPLS networks.

draft-ietf-ppvpn-gre-ip-2547-03.txt                             [Page 1]

Internet Draft     draft-ietf-ppvpn-gre-ip-2547-03.txt        April 2003

3. Summary for Sub-IP Area

3.1. Summary

   The base specification for RFC2547 VPNs, i.e., draft-rosen-
   rfc2547bis-03.txt, specifies the procedures for providing a
   particular style of VPN, using MPLS label switched paths between
   Provider Edge (PE) routers. The base specification does not discuss
   other types of tunnels between PE routers.

   This draft extends the base specification by specifying the
   procedures for providing the RFC2547 style of VPN using GRE or IP
   tunnels (rather than MPLS LSPs) between PE routers.

3.2. Where does it fit in the Picture of the Sub-IP Work

   This work fits squarely in the PPVPN box.

3.3. Why is it Targeted at this WG

   The WG is chartered with considering the RFC2547 style of VPN. This
   draft specifies procedures to allow that style of VPN to run on
   networks which do not implement MPLS in the core switches, and/or in
   environments in which increased security is needed.

   Thus the draft allows the RFC2547 style of VPN to meet additional
   requirements that are not met by the base specification.

3.4. Justification

   The WG should consider this document as it extends a style of VPN
   explicitly called out in the charter so that it becomes applicable to
   a wider range of IP-based backbone environments.

draft-ietf-ppvpn-gre-ip-2547-03.txt                             [Page 2]

Internet Draft     draft-ietf-ppvpn-gre-ip-2547-03.txt        April 2003

4. Introduction

   In "conventional" RFC2547 VPNs, when a PE router receives a packet
   from a CE router, it looks up the packet's destination IP address in
   a VRF.  As a result of this lookup, it obtains an MPLS label stack, a
   data link header, 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 on the MPLS label stack is always a label which will
   not be seen until the packet reaches its point of egress from the
   network. This label represents a particular route within the packet's
   VPN. The purpose of the upper labels is to cause the packet to be
   delivered to the router which understands the bottom label.

   What we discuss here are procedures creating an MPLS packet which
   carries ONLY the bottom label, and then using either GRE or IP
   encapsulation to carry that MPLS packet across the network. That is,
   the upper labels are replaced with an IP header, and in the case of
   GRE encapsulation a GRE header as well.

5. Motivations

   "Conventional" RFC2547 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 an RFC2547 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 RFC2547 VPNs to be deployed even when there are
   non-MPLS router along the path between the ingress and egress PE
   routers, it is desirable to have an alternative which allows the
   upper labels to be replaced with either IP or (IP + GRE) header.
   This encapsulating header would encapsulate an MPLS packet containing
   only a bottom label. The encapsulation header would have the address
   of the egress PE in its destination IP address field, and this would
   cause the packet to be delivered to the egress PE.

   In this procedure, the ingress and egress PEs themselves must support
   MPLS, but that is not an issue, as those routers must necessarily
   have RFC2547 VPN support, whereas the transit routers arguably should
   be able to be "vanilla" routers with no special MPLS or VPN support.

draft-ietf-ppvpn-gre-ip-2547-03.txt                             [Page 3]

Internet Draft     draft-ietf-ppvpn-gre-ip-2547-03.txt        April 2003

6. Specification

   In short, the technical approach specified here is:

   1. Continue to use MPLS to identify a VPN-IP route, by continuing to
   add an MPLS label stack to the VPN packets. However, the label stack
   will carry only one label, the current "bottom label."

   2. An MPLS-in-GRE [mpls-over-gre], or MPLS-in-IP [mpls-over-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.

6.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE

   When a PE receives a packet from a CE, it looks up the packet's IP
   destination address in the VRF corresponding to that CE. This enables
   it to find a VPN-IP route. The VPN-IP route will have an associated
   MPLS 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 itself. The IP destination address
   field of the encapsulation header will contain the value of the
   associated BGP Next Hop attribute; this will be an IP address of the
   egress PE.

   (This description is not meant to specify an implementation strategy;
   any implementation procedure which produces the same result is

   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 are NOT IGP-
   visible links, and routing adjacencies are not 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.

draft-ietf-ppvpn-gre-ip-2547-03.txt                             [Page 4]

Internet Draft     draft-ietf-ppvpn-gre-ip-2547-03.txt        April 2003

6.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.

7. Implications on packet spoofing

   It should be noted that if the upper MPLS labels are replaced with an
   unsecured IP encapsulation, like GRE or IP, it becomes more difficult
   to protect the VPNs against spoofed packets. 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).

   Protection against spoofed IP packets requires having all the
   boundary routers perform filtering; either filtering out packets from
   "outside" which are addressed to PE routers, or filtering out packets
   from "outside" which have source addresses that belong "inside" and
   filtering on each PE all packets which have source addresses that
   belong "outside".  The maintenance of these filter lists can be
   management-intensive, and the their use at all border routers can
   affect the performance seen by all traffic entering the SP's network.

   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.

8. Security Considerations

   Some of the security issues are discussed in the section
   "Implications on packet spoofing". The rest of security issues will
   be discussed at a later time.

draft-ietf-ppvpn-gre-ip-2547-03.txt                             [Page 5]

Internet Draft     draft-ietf-ppvpn-gre-ip-2547-03.txt        April 2003

9. Acknowledgments

   Most of the text in this document is "borrowed" almost verbatim from

10. References

   [RFC2547bis] BGP/MPLS VPNs, Rosen et. al., draft-rosen-rfc2547bis-
   03.txt, 2/01.

   [mpls-over-ip] "MPLS Label Stack Encapsulation in IP", Doolan, P.,
   Katsube, Y., Malis, A., Wilder, R., Worster, T.  draft-worster-mpls-

   [mpls-over-gre] "MPLS Label Stack Encapsulation in GRE", Rekhter, Y.,
   Tappan, D., Rosen, E., draft-rekhter-mpls-over-gre-01.txt

11. Authors' Addresses

Yakov Rekhter
Juniper Networks
E-mail: yakov@juniper.net

Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: erosen@cisco.com

draft-ietf-ppvpn-gre-ip-2547-03.txt                             [Page 6]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/