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

Versions: 00 01 02 03 04 05 RFC 4797

L3VPN Working Group                                           Y. Rekhter
Internet-Draft                                                 R. Bonica
Expires: February 5, 2006                               Juniper Networks
                                                                E. Rosen
                                                     Cisco Systems, Inc.
                                                          August 4, 2005


     Use of PE-PE GRE or IP in BGP/MPLS IP Virtual Private Networks
                    draft-ietf-l3vpn-gre-ip-2547-05

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 February 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This draft describes an implementation strategy for BGP/MPLS IP
   Virtual Private Networks (VPNs) in which the outermost MPLS label
   (i.e., the tunnel label) is replaced with either an IP header or an
   IP header with Generic Routing Encapsulation (GRE).

   The implementation strategy described herein enables the deployment



Rekhter, et al.         Expires February 5, 2006                [Page 1]

Internet-Draft                  L3VPN GRE                    August 2005


   of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS
   and VPN aware, but whose interior devices are not.

Table of Contents

   1.  Conventions Used In This Document  . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Specification  . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1   MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE . . . .  7
     4.2   MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE  . . . .  8
   5.  Implications On Packet Spoofing  . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property and Copyright Statements . . . . . . . . 14

































Rekhter, et al.         Expires February 5, 2006                [Page 2]

Internet-Draft                  L3VPN GRE                    August 2005


1.   Conventions Used In This Document

   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 RFC2119 [1].














































Rekhter, et al.         Expires February 5, 2006                [Page 3]

Internet-Draft                  L3VPN GRE                    August 2005


2.  Introduction

   A "conventional" BGP/MPLS IP VPN [2] is characterized as follows:

      Each Provider Edge (PE) router maintains one or more Virtual
      Routing and Forwarding (VRF) instances.  A VRF instances is a VPN
      specific forwarding table.

      PE routers exchange reachability information with one another
      using BGP [3] with multi-protocol extensions [4].

      MPLS Label Switching Paths (LSPs) [5] connect PE routers one
      another.

   In simple configurations, the VPN service is offered by a single
   Autonomous System (AS).  All service provider routers are contained
   by a single AS and all VPN sites attach to that AS.  When an ingress
   PE router receives a packet from a VPN site, it looks up the packet's
   destination IP address in a VRF that is associated with packet's
   ingress attachment circuit.  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 innermost label in the MPLS label stack is called the VPN route
   label.  The VPN route label is significant and visible to the egress
   PE router only.  It controls forwarding of the packet by the egress
   PE router.

   The outermost label in the MPLS label stack is called the tunnel
   label.  The tunnel label causes the packet to be delivered to the
   egress PE router which understands the VPN route label.
   Specifically, the tunnel label identifies an MPLS LSP that connects
   the ingress PE router to the egress PE router.  In the context of
   BGP/MPLS IP VPNs, this LSP is called a tunnel LSP.

   The tunnel LSP provides a forwarding path between the ingress and
   egress PE routers.  QoS information can be mapped from the VPN packet
   to the tunnel LSP header so that required forwarding behaviors can be
   maintained at each hop along the forwarding path.

   Sections 9 and 10 of reference [2] define more complex configurations
   (i.e., carriers' carrier and multi-AS backbones) in which service
   providers offer L3VPN services across multiple automous systems.  In
   these configurations, VPN route labels can be stitched together
   across AS boundares.  Within each AS, tunnel LSPs carry VPN packets
   from network edge to network edge.



Rekhter, et al.         Expires February 5, 2006                [Page 4]

Internet-Draft                  L3VPN GRE                    August 2005


   In most configurations, tunnel LSPs never traverse AS boundaries.
   The tunnel LSP is always contained within a single AS.  In one
   particular configuration (i.e., Inter-provider Option C), tunnel LSPs
   may traverse AS boundaries.

   This memo describes procedures for creating an MPLS packet which
   carries the VPN route label, but does not carry the tunnel label.
   Then, using either GRE or IP encapsulation, the ingress PE router
   sends the MPLS packet across the network to the egress PE router.

   That is, a GRE or IP tunnel replaces the tunnel LSP that was present
   in "conventional" BGP/MPLS IP VPNs.  Like the tunnel LSP, the GRE/IP
   tunnel provides a forwarding path between the ingress and egress PE
   routers.  QoS information can be copied from the VPN packet to the
   GRE/IP tunnel header so that required forwarding behaviors can be
   maintained at each hop along the forwarding path.  However, because
   the GRE/IP tunnel lacks traffic engineering capabilities, any traffic
   engineering features provided by the tunnel LSP are lost.

































Rekhter, et al.         Expires February 5, 2006                [Page 5]

Internet-Draft                  L3VPN GRE                    August 2005


3.  Motivation

   "Conventional" BGP/MPLS IP VPNs require 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
   need not support MPLS or BGP/MPLS VPNs.































Rekhter, et al.         Expires February 5, 2006                [Page 6]

Internet-Draft                  L3VPN GRE                    August 2005


4.  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 egress PE router, the outermost member of the label stack will
      represent the VPN route label.

      2.  An  MPLS-in-GRE or MPLS-in-IP [6] encapsulation will be used
      to turn the MPLS packet, described above,  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.

   Service providers must protect the above mentioned IP or GRE tunnel
   as recommended in Section 8.2 of reference [6].  As stated in that
   document,

      "If the tunnel lies entirely within a single administrative
      domain, address filtering at the boundaries can be used to ensure
      that no packet with the IP source address of a tunnel endpoint or
      with the IP destination address of a tunnel endpoint can enter the
      domain from outside.

      However, when the tunnel head and the tunnel tail are not in the
      same administrative domain, this may become difficult, and
      filtering based on the destination address can even become
      impossible if the packets must traverse the public Internet.

      Sometimes only source address filtering (but not destination
      address filtering) is done at the boundaries of an administrative
      domain.  If this is the case, the filtering does not provide
      effective protection at all unless the decapsulator of an
      MPLS-in-IP or MPLS-in-GRE validates the IP source address of the
      packet.  This document does not require that the decapsulator
      validate the IP source address of the tunneled packets, but it
      should be understood that failure to do so presupposes that there
      is effective destination-based (or a combination of source-based
      and destination-based) filtering at the boundaries."


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



Rekhter, et al.         Expires February 5, 2006                [Page 7]

Internet-Draft                  L3VPN GRE                    August 2005


   is acceptable.

   When an ingress PE router receives a packet from a CE router, it
   looks up the packet's destination IP address in a VRF that is
   associated with packet's ingress attachment circuit.  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.  QoS
   information can be copied from the VPN packet to the GRE/IP tunnel
   header so that required forwarding behaviors can be maintained at
   each hop along the forwarding path.

   The IP address of the remote tunnel endpoints MAY be inferred from
   the Network Address of the Next Hop field of the MP_REACH_NLRI BGP
   attribute [4].  Note that the set of Next Hop Network Addresses is
   not known in advance, but is learned dynamically via the BGP
   distribution of VPN-IP routes.  Assuming a consistent set of tunnel
   capabilities exist between all the PE's and ASBR's, no apriori
   configuration of the remote tunnel endpoints is needed.  The entire
   set of PE and ASBR routers MUST have the same tunnel capabilities if
   the dynamic creation of IP (or GRE) tunnels is desired.  The
   preference to use an IP (or GRE) tunnel MUST be configured.  A set of
   PE's using two or more tunnel mechanisms (i.e.  LSP, GRE, IP, etc.)
   MUST determine the tunnel type on a per peer basis.  The automatic
   association of tunnel capabilities on a per peer basis is for future
   study.  Note that these tunnels SHOULD NOT be IGP-visible links and
   routing adjacencies SHOULD NOT be supported across these tunnel.

4.2  MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE

   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.

   As stated above, if the service provider deploys source-based
   filtering at network edges to protect the IP/GRE tunnel (instead of
   destination-based filtering), the decapsulator must validate the IP
   source address of the tunneled packets.






Rekhter, et al.         Expires February 5, 2006                [Page 8]

Internet-Draft                  L3VPN GRE                    August 2005


5.  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).

   By contrast, protection against spoofed IP packets requires all SP
   boundary routers to perform filtering; either (a) filtering packets
   from "outside" of the SP which are addressed to PE routers, or (b)
   filtering 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.
   Furthermore, depending upon implementation, these filter lists can be
   performance affecting.  However, such filters may be required for
   reasons other than protection against spoofed 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.






















Rekhter, et al.         Expires February 5, 2006                [Page 9]

Internet-Draft                  L3VPN GRE                    August 2005


6.  Security Considerations

   Security considerations in reference [6]  apply here as well.
   Additional security issues are discussed in the section "Implications
   on packet spoofing" above.














































Rekhter, et al.         Expires February 5, 2006               [Page 10]

Internet-Draft                  L3VPN GRE                    August 2005


7.  IANA Considerations

   No actions for IANA required.
















































Rekhter, et al.         Expires February 5, 2006               [Page 11]

Internet-Draft                  L3VPN GRE                    August 2005


8.  Acknowledgments

   Thanks to Robert Raszuk and Scott Wainner for their contributions to
   this document.

9.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03
        (work in progress), October 2004.

   [3]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
        RFC 1771, March 1995.

   [4]  Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol
        Extensions for BGP-4", RFC 2858, June 2000.

   [5]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
        Switching Architecture", RFC 3031, January 2001.

   [6]  Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in
        IP or Generic Routing Encapsulation (GRE)", RFC 4023,
        March 2005.


Authors' Addresses

   Yakov Rekhter
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: yakov@juniper.net


   Ronald P. Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   US

   Email: rbonica@juniper.net






Rekhter, et al.         Expires February 5, 2006               [Page 12]

Internet-Draft                  L3VPN GRE                    August 2005


   Eric C. Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA  01824
   US

   Email: erosen@cisco.com












































Rekhter, et al.         Expires February 5, 2006               [Page 13]

Internet-Draft                  L3VPN GRE                    August 2005


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@ietf.org.


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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rekhter, et al.         Expires February 5, 2006               [Page 14]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/