idnits 2.17.1 draft-ietf-mpls-in-ip-or-gre-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2003) is 7552 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2460' is mentioned on line 116, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tom Worster 3 Internet Draft 4 Expiration Date: February 2004 5 Yakov Rekhter 6 Juniper Networks, Inc. 8 Eric C. Rosen, editor 9 Cisco Systems, Inc. 11 August 2003 13 Encapsulating MPLS in IP or GRE 15 draft-ietf-mpls-in-ip-or-gre-02.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 In various applications of MPLS, label stacks with multiple entries 40 are used. In some cases, it is possible to replace the top label of 41 the stack with an IP-based encapsulation, thereby enabling the 42 application to run over networks which do not have MPLS enabled in 43 their core routers. This draft specifies two IP-based 44 encapsulations, MPLS-in-IP, and MPLS-in-GRE. Each of these is 45 applicable in some circumstances. 47 Table of Contents 49 1 Specification of Requirements .......................... 2 50 2 Motivation ............................................. 2 51 3 Encapsulation in IP .................................... 3 52 4 Encapsulation in GRE ................................... 4 53 5 Common Procedures ...................................... 4 54 5.1 Fragmentation, Reassembly, and MTU ..................... 5 55 5.2 TTL .................................................... 5 56 5.3 EXP and DSCP fields .................................... 6 57 6 Applicability .......................................... 6 58 7 IANA Considerations .................................... 6 59 8 Security Considerations ................................ 7 60 9 Acknowledgments ........................................ 7 61 10 References ............................................. 7 62 11 Author Information ..................................... 8 64 1. Specification of Requirements 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119. 70 2. Motivation 72 In many applications of MPLS, packets traversing an MPLS backbone 73 carry label stacks with more than one label. As described in 74 [RFC3031], section 3.15, each label represents a Label Switched Path 75 (LSP). For each such LSP, there is a Label Switching Router (LSR) 76 which is the "LSP Ingress", and an LSR which is the "LSP Egress". If 77 LSRs A and B are the Ingress and Egress, respectively, of the LSP 78 corresponding to a packet's top label, then A and B are adjacent LSRs 79 on the LSP corresponding to the packet's second label (i.e., the 80 label immediately beneath the top label) 82 The purpose (or one of the purposes) of the top label is to get the 83 packet delivered from A to B, so that B can further process the 84 packet based on the second label. In this sense, the top label 85 serves as an encapsulation header for the rest of the packet. In 86 some cases the top label can be replaced, without loss of 87 functionality, by other sorts of encapsulation headers. For example, 88 the top label could be replaced by an IP header or a GRE header. As 89 the encapsulated packet would still be an MPLS packet, the result is 90 an MPLS-in-IP or MPLS-in-GRE encapsulation. 92 With these encapsulations, it is possible for two LSRs that are 93 adjacent on an LSP to be separated by an IP network, even if that IP 94 network does not provide MPLS. 96 3. Encapsulation in IP 98 MPLS-in-IP messages have the following format: 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | | 102 | IP Header | 103 | | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | | 106 | MPLS Label Stack | 107 | | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | | 110 | Message Body | 111 | | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 IP Header 115 This field contains an IPv4 or an IPv6 datagram header 116 as defined in [RFC791] and [RFC2460] respectively. The 117 source and destination addresses are set to addresses 118 of the encapsulating and decapsulating LSRs respectively. 120 MPLS Label Stack 121 This field contains an MPLS Label Stack as defined in 122 [RFC3032]. 124 Message Body 125 This field contains one MPLS message body. 127 The Protocol Number field in an IPv4 header and the Next Header field 128 in an IPv6 are set as follows: 130 - [value to be assigned by IANA] indicates an MPLS unicast packet, 132 - [value to be assigned by IANA] indicates an MPLS multicast 133 packet. (The use of the MPLS-in-IP encapsulation for MPLS 134 multicast packets is for further study.) 136 Following the IP header is an MPLS packet, as specified in [RFC3032]. 137 This encapsulation causes MPLS packets to be sent through "IP 138 tunnels". When a packet is received by the tunnel's receive 139 endpoint, the receive endpoint decapsulates the MPLS packet by 140 removing the IP header. The packet is then processed as a received 141 MPLS packet whose "incoming label" [RFC3031] is the topmost label of 142 the decapsulated packet. 144 4. Encapsulation in GRE 146 The MPLS-in-GRE encapsulation encapsulates an MPLS packet in GRE 147 [RFC2784]. The packet then consists of an IP header followed by a 148 GRE header followed by an MPLS label stack as specified in [RFC3032]. 149 The protocol type field in the GRE header MUST be set to the 150 Ethertype value for MPLS Unicast (0x8847) or Multicast (0x8848). The 151 optional GRE checksum, key [RFC2890] and sequence number [RFC2890] 152 fields MUST NOT be used. 154 This encapsulation causes MPLS packets to be sent through "GRE 155 tunnels". When a packet is received by the tunnel's receive endpoint, 156 the receive endpoint decapsulates the MPLS packet by removing the IP 157 header and the GRE header. The packet is then processed as a 158 received MPLS packet whose "incoming label" [RFC3031] is the topmost 159 label of the decapsulated packet. 161 5. Common Procedures 163 Certain procedures are common to both the MPLS-in-IP and the MPLS- 164 in-GRE encapsulations. In the following, the encapsulator, whose 165 address appears in the IP source address field of the encapsulating 166 IP header, is known as the "tunnel head". The decapsulator, whose 167 address appears in the IP destination address field of the 168 decapsulating IP header, is known as the "tunnel tail". 170 5.1. Fragmentation, Reassembly, and MTU 172 If an MPLS-in-IP or MPLS-in-GRE packet were to get fragmented (due to 173 "ordinary" IP fragmentation), it would have to be be reassembled by 174 the tunnel tail before the contained MPLS packet could be 175 decapsulated. To avoid the need for the tunnel tail to perform 176 reassembly, the tunnel head MUST set the Don't Fragment flag of the 177 encapsulating IPv4 header. 179 The tunnel head SHOULD perform Path MTU Discovery [RFC1191] over each 180 MPLS-in-IP and MPLS-in-GRE tunnel. 182 The tunnel head MUST maintain a Tunnel MTU value for each MPLS-in-IP 183 or MPLS-in-GRE tunnel. This is the minimum of (a) an administratively 184 configured value, and, if known, (b) the discovered Path MTU value 185 minus the encapsulation overhead. 187 If the tunnel head receives, for encapsulation, an MPLS packet whose 188 size exceeds the Tunnel MTU, that packet MUST be discarded. 190 In some cases, the tunnel head receives, for encapsulation, an IP 191 packet, which it first encapsulates in MPLS and then encapsulates in 192 MPLS-in-IP or MPLS-in-GRE. If the source of the IP packet is 193 reachable from the tunnel head, and if the result of encapsulating 194 the packet in MPLS would be a packet whose size exceeds the Tunnel 195 MTU, then the value which the tunnel head SHOULD use for the purposes 196 of fragmentation and PMTU discovery outside the tunnel is the Tunnel 197 MTU value minus the size of the MPLS sencapsulation. 199 5.2. TTL 201 The tunnel head MAY place the TTL from the MPLS label stack into the 202 encapsulating IP header. The tunnel tail MAY place the TTL from the 203 encapsulating IP header into the MPLS header, but only if that does 204 not cause the TTL value in the MPLS header to become larger. 206 Whether such modifications are made, and the details of how they are 207 made, will depend on the configuration of the tunnel tail and the 208 tunnel head. 210 5.3. EXP and DSCP fields 212 The tunnel head MAY consider the EXP field of the encapsulated MPLS 213 packet when setting the DSCP field of the encapsulating IP header. 214 The tunnel tail MAY modify the EXP field of the encapsulated MPLS 215 packet, based on consideration of the DSCP field of the encapsulating 216 IP header. 218 Whether such modifications are made, and the details of how they are 219 made, will depend on the configuration of the tunnel tail and the 220 tunnel head. 222 6. Applicability 224 The MPLS-in-IP encapsulation is the more efficient, and would 225 generally be regarded as preferable, other things being equal. There 226 are however some situations in which the MPLS-in-GRE encapsulation 227 may be used: 229 - Two routers are "adjacent" over a GRE tunnel that exists for some 230 reason that is outside the scope of this document, and those two 231 routers need to send MPLS packets over that adjacency. As all 232 packets sent over this adjacency must have a GRE encapsulation, 233 the MPLS-in-GRE encapsulation is more efficient than the 234 alternative, which would be an MPLS-in-IP encapsulation which is 235 then encapsulated in GRE. 237 - Implementation considerations may dictate the use of MPLS-in-GRE. 238 For example, some hardware device might only be able to handle 239 GRE encapsulations in its fastpath. 241 7. IANA Considerations 243 The MPLS-in-IP encapsulation requires that IANA allocate two IP 244 Protocol Numbers, as described in section 3. No future IANA actions 245 will be required. The MPLS-in-GRE encapsulation does not require any 246 IANA action. 248 8. Security Considerations 250 MPLS-in-IP or MPLS-in-GRE tunnels may be secured using IPsec. When 251 using IPsec, the tunnel head and the tunnel tail should be treated as 252 the endpoints of a Security Association. The MPLS-in-IP or MPLS- 253 in-GRE encapsulated packets should be considered as originating at 254 the tunnel head and as being destined for the tunnel tail; IPsec 255 transport mode should thus be used. Key distribution may be done 256 either manually or automatically. 258 If the tunnels are not secured using IPsec, then some other method 259 should be used to ensure that packets are decapsulated and forwarded 260 by the tunnel tail only if those packets were encapsulated by the 261 tunnel head. This can be done by address filtering at the boundaries 262 of an administrative domain. When the tunnel head and the tunnel 263 tail are not in the same domain, this may become difficult, and it 264 can even become impossible if the packets must traverse the public 265 Internet. 267 9. Acknowledgments 269 This draft is a combination of two previous drafts: 271 - draft-worster-mpls-in-ip, by Tom Worster, Paul Doolan, Yasuhiro 272 Katsube, Tom K. Johnson, Andrew G. Malis, and Rick Wilder 274 - draft-rekhter-mpls-over-gre, by Yakov Rekhter, Daniel Tappan, and 275 Eric Rosen 277 The current authors wish to thank all these authors for their 278 contribution. We also think Mark Duffy and Scott Bradner for their 279 comments. 281 10. References 283 [RFC791] "Internet Protocol," J. Postel, Sep 1981 285 [RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S. 286 Deering and R. Hinden, RFC 2460,Dec 1998 288 [RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November 289 1990 291 [RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li, 292 S. Hanks, D. Meyer, P. Traina, March 2000 294 [RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety, 295 August 2000 297 [RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A. 298 Viswanathan, R. Callon, January 2001 300 [RFC3032] "MPLS Label Stack Encoding", E. Rosen, D. Tappan, G. 301 Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001 303 11. Author Information 305 Tom Worster 306 Email: fsb@thefsb.org 308 Yakov Rekhter 309 Juniper Networks, Inc. 310 1194 N. Mathilda Ave. 311 Sunnyvale, CA 94089 312 Email: yakov@juniper.net 314 Eric Rosen 315 Cisco Systems, Inc. 316 1414 Massachusetts Avenue 317 Boxborough, MA 01719 318 Email: erosen@cisco.com