Network Working Group Tom Worster Internet Draft Expiration Date: February 2004 Yakov Rekhter Juniper Networks, Inc. Eric C. Rosen, editor Cisco Systems, Inc. August 2003 Encapsulating MPLS in IP or GRE draft-ietf-mpls-in-ip-or-gre-02.txt 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-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. Abstract In various applications of MPLS, label stacks with multiple entries are used. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks which do not have MPLS enabled in their core routers. This draft specifies two IP-based encapsulations, MPLS-in-IP, and MPLS-in-GRE. Each of these is applicable in some circumstances. Worster, et al. [Page 1] Internet Draft draft-ietf-mpls-in-ip-or-gre-02.txt August 2003 Table of Contents 1 Specification of Requirements .......................... 2 2 Motivation ............................................. 2 3 Encapsulation in IP .................................... 3 4 Encapsulation in GRE ................................... 4 5 Common Procedures ...................................... 4 5.1 Fragmentation, Reassembly, and MTU ..................... 5 5.2 TTL .................................................... 5 5.3 EXP and DSCP fields .................................... 6 6 Applicability .......................................... 6 7 IANA Considerations .................................... 6 8 Security Considerations ................................ 7 9 Acknowledgments ........................................ 7 10 References ............................................. 7 11 Author Information ..................................... 8 1. 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. 2. Motivation In many applications of MPLS, packets traversing an MPLS backbone carry label stacks with more than one label. As described in [RFC3031], section 3.15, each label represents a Label Switched Path (LSP). For each such LSP, there is a Label Switching Router (LSR) which is the "LSP Ingress", and an LSR which is the "LSP Egress". If LSRs A and B are the Ingress and Egress, respectively, of the LSP corresponding to a packet's top label, then A and B are adjacent LSRs on the LSP corresponding to the packet's second label (i.e., the label immediately beneath the top label) The purpose (or one of the purposes) of the top label is to get the packet delivered from A to B, so that B can further process the packet based on the second label. In this sense, the top label serves as an encapsulation header for the rest of the packet. In some cases the top label can be replaced, without loss of Worster, et al. [Page 2] Internet Draft draft-ietf-mpls-in-ip-or-gre-02.txt August 2003 functionality, by other sorts of encapsulation headers. For example, the top label could be replaced by an IP header or a GRE header. As the encapsulated packet would still be an MPLS packet, the result is an MPLS-in-IP or MPLS-in-GRE encapsulation. With these encapsulations, it is possible for two LSRs that are adjacent on an LSP to be separated by an IP network, even if that IP network does not provide MPLS. 3. Encapsulation in IP MPLS-in-IP messages have the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IP Header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MPLS Label Stack | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Body | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Header This field contains an IPv4 or an IPv6 datagram header as defined in [RFC791] and [RFC2460] respectively. The source and destination addresses are set to addresses of the encapsulating and decapsulating LSRs respectively. MPLS Label Stack This field contains an MPLS Label Stack as defined in [RFC3032]. Message Body This field contains one MPLS message body. The Protocol Number field in an IPv4 header and the Next Header field in an IPv6 are set as follows: Worster, et al. [Page 3] Internet Draft draft-ietf-mpls-in-ip-or-gre-02.txt August 2003 - [value to be assigned by IANA] indicates an MPLS unicast packet, - [value to be assigned by IANA] indicates an MPLS multicast packet. (The use of the MPLS-in-IP encapsulation for MPLS multicast packets is for further study.) Following the IP header is an MPLS packet, as specified in [RFC3032]. This encapsulation causes MPLS packets to be sent through "IP tunnels". When a packet is received by the tunnel's receive endpoint, the receive endpoint decapsulates the MPLS packet by removing the IP header. The packet is then processed as a received MPLS packet whose "incoming label" [RFC3031] is the topmost label of the decapsulated packet. 4. Encapsulation in GRE The MPLS-in-GRE encapsulation encapsulates an MPLS packet in GRE [RFC2784]. The packet then consists of an IP header followed by a GRE header followed by an MPLS label stack as specified in [RFC3032]. The protocol type field in the GRE header MUST be set to the Ethertype value for MPLS Unicast (0x8847) or Multicast (0x8848). The optional GRE checksum, key [RFC2890] and sequence number [RFC2890] fields MUST NOT be used. This encapsulation causes MPLS packets to be sent through "GRE tunnels". When a packet is received by the tunnel's receive endpoint, the receive endpoint decapsulates the MPLS packet by removing the IP header and the GRE header. The packet is then processed as a received MPLS packet whose "incoming label" [RFC3031] is the topmost label of the decapsulated packet. 5. Common Procedures Certain procedures are common to both the MPLS-in-IP and the MPLS- in-GRE encapsulations. In the following, the encapsulator, whose address appears in the IP source address field of the encapsulating IP header, is known as the "tunnel head". The decapsulator, whose address appears in the IP destination address field of the decapsulating IP header, is known as the "tunnel tail". Worster, et al. [Page 4] Internet Draft draft-ietf-mpls-in-ip-or-gre-02.txt August 2003 5.1. Fragmentation, Reassembly, and MTU If an MPLS-in-IP or MPLS-in-GRE packet were to get fragmented (due to "ordinary" IP fragmentation), it would have to be be reassembled by the tunnel tail before the contained MPLS packet could be decapsulated. To avoid the need for the tunnel tail to perform reassembly, the tunnel head MUST set the Don't Fragment flag of the encapsulating IPv4 header. The tunnel head SHOULD perform Path MTU Discovery [RFC1191] over each MPLS-in-IP and MPLS-in-GRE tunnel. The tunnel head MUST maintain a Tunnel MTU value for each MPLS-in-IP or MPLS-in-GRE tunnel. This is the minimum of (a) an administratively configured value, and, if known, (b) the discovered Path MTU value minus the encapsulation overhead. If the tunnel head receives, for encapsulation, an MPLS packet whose size exceeds the Tunnel MTU, that packet MUST be discarded. In some cases, the tunnel head receives, for encapsulation, an IP packet, which it first encapsulates in MPLS and then encapsulates in MPLS-in-IP or MPLS-in-GRE. If the source of the IP packet is reachable from the tunnel head, and if the result of encapsulating the packet in MPLS would be a packet whose size exceeds the Tunnel MTU, then the value which the tunnel head SHOULD use for the purposes of fragmentation and PMTU discovery outside the tunnel is the Tunnel MTU value minus the size of the MPLS sencapsulation. 5.2. TTL The tunnel head MAY place the TTL from the MPLS label stack into the encapsulating IP header. The tunnel tail MAY place the TTL from the encapsulating IP header into the MPLS header, but only if that does not cause the TTL value in the MPLS header to become larger. Whether such modifications are made, and the details of how they are made, will depend on the configuration of the tunnel tail and the tunnel head. Worster, et al. [Page 5] Internet Draft draft-ietf-mpls-in-ip-or-gre-02.txt August 2003 5.3. EXP and DSCP fields The tunnel head MAY consider the EXP field of the encapsulated MPLS packet when setting the DSCP field of the encapsulating IP header. The tunnel tail MAY modify the EXP field of the encapsulated MPLS packet, based on consideration of the DSCP field of the encapsulating IP header. Whether such modifications are made, and the details of how they are made, will depend on the configuration of the tunnel tail and the tunnel head. 6. Applicability The MPLS-in-IP encapsulation is the more efficient, and would generally be regarded as preferable, other things being equal. There are however some situations in which the MPLS-in-GRE encapsulation may be used: - Two routers are "adjacent" over a GRE tunnel that exists for some reason that is outside the scope of this document, and those two routers need to send MPLS packets over that adjacency. As all packets sent over this adjacency must have a GRE encapsulation, the MPLS-in-GRE encapsulation is more efficient than the alternative, which would be an MPLS-in-IP encapsulation which is then encapsulated in GRE. - Implementation considerations may dictate the use of MPLS-in-GRE. For example, some hardware device might only be able to handle GRE encapsulations in its fastpath. 7. IANA Considerations The MPLS-in-IP encapsulation requires that IANA allocate two IP Protocol Numbers, as described in section 3. No future IANA actions will be required. The MPLS-in-GRE encapsulation does not require any IANA action. Worster, et al. [Page 6] Internet Draft draft-ietf-mpls-in-ip-or-gre-02.txt August 2003 8. Security Considerations MPLS-in-IP or MPLS-in-GRE tunnels may be secured using IPsec. When using IPsec, the tunnel head and the tunnel tail should be treated as the endpoints of a Security Association. The MPLS-in-IP or MPLS- in-GRE encapsulated packets should be considered as originating at the tunnel head and as being destined for the tunnel tail; IPsec transport mode should thus be used. Key distribution may be done either manually or automatically. If the tunnels are not secured using IPsec, then some other method should be used to ensure that packets are decapsulated and forwarded by the tunnel tail only if those packets were encapsulated by the tunnel head. This can be done by address filtering at the boundaries of an administrative domain. When the tunnel head and the tunnel tail are not in the same domain, this may become difficult, and it can even become impossible if the packets must traverse the public Internet. 9. Acknowledgments This draft is a combination of two previous drafts: - draft-worster-mpls-in-ip, by Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew G. Malis, and Rick Wilder - draft-rekhter-mpls-over-gre, by Yakov Rekhter, Daniel Tappan, and Eric Rosen The current authors wish to thank all these authors for their contribution. We also think Mark Duffy and Scott Bradner for their comments. 10. References [RFC791] "Internet Protocol," J. Postel, Sep 1981 [RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S. Deering and R. Hinden, RFC 2460,Dec 1998 [RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November 1990 [RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, March 2000 Worster, et al. [Page 7] Internet Draft draft-ietf-mpls-in-ip-or-gre-02.txt August 2003 [RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety, August 2000 [RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A. Viswanathan, R. Callon, January 2001 [RFC3032] "MPLS Label Stack Encoding", E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001 11. Author Information Tom Worster Email: fsb@thefsb.org Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 Email: yakov@juniper.net Eric Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 Email: erosen@cisco.com Worster, et al. [Page 8]