doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc4797.txt b/doc/rfc/rfc4797.txt
new file mode 100644
index 0000000..b47091d
--- /dev/null
+++ b/doc/rfc/rfc4797.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         Y. Rekhter
+Request for Comments: 4797                                     R. Bonica
+Category: Informational                                 Juniper Networks
+                                                                E. Rosen
+                                                     Cisco Systems, Inc.
+                                                            January 2007
+
+
+             Use of Provider Edge to Provider Edge (PE-PE)
+               Generic Routing Encapsulation (GRE) or IP
+                in BGP/MPLS IP Virtual Private Networks
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+IESG Note
+
+   This document proposes an automated mechanism for establishing
+   tunnels between provider-edge routers in a VPN, but does not provide
+   an automated mechanism for establishing security associations for
+   these tunnels.  Without such a mechanism, this document is not
+   appropriate for publication on the Internet standards track.
+
+Abstract
+
+   This document 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
+   of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS
+   and VPN aware, but whose interior devices are not.
+
+
+
+
+
+
+
+
+
+
+
+Rekhter, et al.              Informational                      [Page 1]
+
+RFC 4797                       L3VPN GRE                    January 2007
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 4
+   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+   4.  Specification . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     4.1.  MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE  . . . . 5
+     4.2.  MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE . . . . . 6
+   5.  Implications on Packet Spoofing . . . . . . . . . . . . . . . . 7
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
+   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
+   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter, et al.              Informational                      [Page 2]
+
+RFC 4797                       L3VPN GRE                    January 2007
+
+
+1.  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 to 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 the 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 that 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.  Quality of service (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 autonomous systems.
+   In these configurations, VPN route labels can be stitched together
+
+
+
+
+Rekhter, et al.              Informational                      [Page 3]
+
+RFC 4797                       L3VPN GRE                    January 2007
+
+
+   across AS boundaries.  Within each AS, tunnel LSPs carry VPN packets
+   from network edge to network edge.
+
+   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 that
+   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.
+
+2.   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 RFC 2119 [1].
+
+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 that 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 an 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.              Informational                      [Page 4]
+
+RFC 4797                       L3VPN GRE                    January 2007
+
+
+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 that produces the same result
+   is acceptable.
+
+
+
+Rekhter, et al.              Informational                      [Page 5]
+
+RFC 4797                       L3VPN GRE                    January 2007
+
+
+   When an ingress PE router receives a packet from a Customer Edge (CE)
+   router, it looks up the packet's destination IP address in a VRF that
+   is associated with the 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 PEs and Autonomous System Border
+   Routers (ASBRs), no a priori configuration of the remote tunnel
+   endpoints is needed.  The entire set of PE and ASBRs 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 PEs 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.              Informational                      [Page 6]
+
+RFC 4797                       L3VPN GRE                    January 2007
+
+
+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 that 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" the SP, which are addressed to PE routers, or (b)
+   filtering packets from "outside" the SP, which have source addresses
+   that belong "inside" and, in addition, filtering on each PE all
+   packets that have source addresses that belong "outside" 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.
+
+6.  Security Considerations
+
+   Security considerations in reference [6] apply here as well.
+   Additional security issues are discussed in the previous section
+   "Implications on Packet Spoofing".
+
+7.  Acknowledgments
+
+   Thanks to Robert Raszuk and Scott Wainner for their contributions to
+   this document.
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter, et al.              Informational                      [Page 7]
+
+RFC 4797                       L3VPN GRE                    January 2007
+
+
+8.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
+        (VPNs)", RFC 4364, February 2006.
+
+   [3]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
+        (BGP-4)", RFC 4271, January 2006.
+
+   [4]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol
+        Extensions for BGP-4", RFC 4760, January 2007.
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter, et al.              Informational                      [Page 8]
+
+RFC 4797                       L3VPN GRE                    January 2007
+
+
+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
+
+
+   Eric C. Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA  01719
+   US
+
+   EMail: erosen@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter, et al.              Informational                      [Page 9]
+
+RFC 4797                       L3VPN GRE                    January 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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 currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Rekhter, et al.              Informational                     [Page 10]
+