idnits 2.17.1 draft-ietf-mpls-in-ip-or-gre-03.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. ** 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 (September 2003) is 7527 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 120, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 4 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: March 2004 5 Yakov Rekhter 6 Juniper Networks, Inc. 8 Eric C. Rosen, editor 9 Cisco Systems, Inc. 11 September 2003 13 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) 15 draft-ietf-mpls-in-ip-or-gre-03.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 (Generic Routing 45 Encapsulation). Each of these is 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 Intellectual Property Notice ........................... 7 61 10 Copyright Notice ....................................... 8 62 11 Acknowledgments ........................................ 8 63 12 Normative References ................................... 8 64 13 Informative References ................................. 9 65 14 Author Information ..................................... 9 67 1. Specification of Requirements 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119. 73 2. Motivation 75 In many applications of MPLS, packets traversing an MPLS backbone 76 carry label stacks with more than one label. As described in 77 [RFC3031], section 3.15, each label represents a Label Switched Path 78 (LSP). For each such LSP, there is a Label Switching Router (LSR) 79 which is the "LSP Ingress", and an LSR which is the "LSP Egress". If 80 LSRs A and B are the Ingress and Egress, respectively, of the LSP 81 corresponding to a packet's top label, then A and B are adjacent LSRs 82 on the LSP corresponding to the packet's second label (i.e., the 83 label immediately beneath the top label) 85 The purpose (or one of the purposes) of the top label is to get the 86 packet delivered from A to B, so that B can further process the 87 packet based on the second label. In this sense, the top label 88 serves as an encapsulation header for the rest of the packet. In 89 some cases the top label can be replaced, without loss of 90 functionality, by other sorts of encapsulation headers. For example, 91 the top label could be replaced by an IP header or a Generic Routing 92 Encapsulation (GRE) header. As the encapsulated packet would still 93 be an MPLS packet, the result is an MPLS-in-IP or MPLS-in-GRE 94 encapsulation. 96 With these encapsulations, it is possible for two LSRs that are 97 adjacent on an LSP to be separated by an IP network, even if that IP 98 network does not provide MPLS. 100 3. Encapsulation in IP 102 MPLS-in-IP messages have the following format: 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | | 106 | IP Header | 107 | | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | | 110 | MPLS Label Stack | 111 | | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | | 114 | Message Body | 115 | | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 IP Header 119 This field contains an IPv4 or an IPv6 datagram header 120 as defined in [RFC791] and [RFC2460] respectively. The 121 source and destination addresses are set to addresses 122 of the encapsulating and decapsulating LSRs respectively. 124 MPLS Label Stack 125 This field contains an MPLS Label Stack as defined in 126 [RFC3032]. 128 Message Body 129 This field contains one MPLS message body. 131 The Protocol Number field in an IPv4 header and the Next Header field 132 in an IPv6 are set as follows: 134 - [value to be assigned by IANA] indicates an MPLS unicast packet, 136 - [value to be assigned by IANA] indicates an MPLS multicast 137 packet. (The use of the MPLS-in-IP encapsulation for MPLS 138 multicast packets is for further study.) 140 Following the IP header is an MPLS packet, as specified in [RFC3032]. 141 This encapsulation causes MPLS packets to be sent through "IP 142 tunnels". When a packet is received by the tunnel's receive 143 endpoint, the receive endpoint decapsulates the MPLS packet by 144 removing the IP header. The packet is then processed as a received 145 MPLS packet whose "incoming label" [RFC3031] is the topmost label of 146 the decapsulated packet. 148 4. Encapsulation in GRE 150 The MPLS-in-GRE encapsulation encapsulates an MPLS packet in GRE 151 [RFC2784]. The packet then consists of an IP header followed by a 152 GRE header followed by an MPLS label stack as specified in [RFC3032]. 153 The protocol type field in the GRE header MUST be set to the 154 Ethertype value for MPLS Unicast (0x8847) or Multicast (0x8848). The 155 optional GRE checksum, key [RFC2890] and sequence number [RFC2890] 156 fields MUST NOT be used. 158 This encapsulation causes MPLS packets to be sent through "GRE 159 tunnels". When a packet is received by the tunnel's receive endpoint, 160 the receive endpoint decapsulates the MPLS packet by removing the IP 161 header and the GRE header. The packet is then processed as a 162 received MPLS packet whose "incoming label" [RFC3031] is the topmost 163 label of the decapsulated packet. 165 5. Common Procedures 167 Certain procedures are common to both the MPLS-in-IP and the MPLS- 168 in-GRE encapsulations. In the following, the encapsulator, whose 169 address appears in the IP source address field of the encapsulating 170 IP header, is known as the "tunnel head". The decapsulator, whose 171 address appears in the IP destination address field of the 172 decapsulating IP header, is known as the "tunnel tail". 174 5.1. Fragmentation, Reassembly, and MTU 176 If an MPLS-in-IP or MPLS-in-GRE packet were to get fragmented (due to 177 "ordinary" IP fragmentation), it would have to be be reassembled by 178 the tunnel tail before the contained MPLS packet could be 179 decapsulated. To avoid the need for the tunnel tail to perform 180 reassembly, the tunnel head MUST set the Don't Fragment flag of the 181 encapsulating IPv4 header. 183 The tunnel head SHOULD perform Path MTU Discovery [RFC1191] over each 184 MPLS-in-IP and MPLS-in-GRE tunnel. 186 The tunnel head MUST maintain a Tunnel MTU value for each MPLS-in-IP 187 or MPLS-in-GRE tunnel. This is the minimum of (a) an administratively 188 configured value, and, if known, (b) the discovered Path MTU value 189 minus the encapsulation overhead. 191 If the tunnel head receives, for encapsulation, an MPLS packet whose 192 size exceeds the Tunnel MTU, that packet MUST be discarded. 194 In some cases, the tunnel head receives, for encapsulation, an IP 195 packet, which it first encapsulates in MPLS and then encapsulates in 196 MPLS-in-IP or MPLS-in-GRE. If the source of the IP packet is 197 reachable from the tunnel head, and if the result of encapsulating 198 the packet in MPLS would be a packet whose size exceeds the Tunnel 199 MTU, then the value which the tunnel head SHOULD use for the purposes 200 of fragmentation and PMTU discovery outside the tunnel is the Tunnel 201 MTU value minus the size of the MPLS sencapsulation. 203 5.2. TTL 205 The tunnel head MAY place the TTL from the MPLS label stack into the 206 encapsulating IP header. The tunnel tail MAY place the TTL from the 207 encapsulating IP header into the MPLS header, but only if that does 208 not cause the TTL value in the MPLS header to become larger. 210 Whether such modifications are made, and the details of how they are 211 made, will depend on the configuration of the tunnel tail and the 212 tunnel head. 214 5.3. EXP and DSCP fields 216 The tunnel head MAY consider the EXP field of the encapsulated MPLS 217 packet when setting the DSCP field of the encapsulating IP header. 218 The tunnel tail MAY modify the EXP field of the encapsulated MPLS 219 packet, based on consideration of the DSCP field of the encapsulating 220 IP header. 222 Whether such modifications are made, and the details of how they are 223 made, will depend on the configuration of the tunnel tail and the 224 tunnel head. 226 6. Applicability 228 The MPLS-in-IP encapsulation is the more efficient, and would 229 generally be regarded as preferable, other things being equal. There 230 are however some situations in which the MPLS-in-GRE encapsulation 231 may be used: 233 - Two routers are "adjacent" over a GRE tunnel that exists for some 234 reason that is outside the scope of this document, and those two 235 routers need to send MPLS packets over that adjacency. As all 236 packets sent over this adjacency must have a GRE encapsulation, 237 the MPLS-in-GRE encapsulation is more efficient than the 238 alternative, which would be an MPLS-in-IP encapsulation which is 239 then encapsulated in GRE. 241 - Implementation considerations may dictate the use of MPLS-in-GRE. 242 For example, some hardware device might only be able to handle 243 GRE encapsulations in its fastpath. 245 7. IANA Considerations 247 The MPLS-in-IP encapsulation requires that IANA allocate two IP 248 Protocol Numbers, as described in section 3. No future IANA actions 249 will be required. The MPLS-in-GRE encapsulation does not require any 250 IANA action. 252 8. Security Considerations 254 MPLS-in-IP or MPLS-in-GRE tunnels may be secured using IPsec. When 255 using IPsec, the tunnel head and the tunnel tail should be treated as 256 the endpoints of a Security Association. The MPLS-in-IP or MPLS- 257 in-GRE encapsulated packets should be considered as originating at 258 the tunnel head and as being destined for the tunnel tail; IPsec 259 transport mode should thus be used. Key distribution may be done 260 either manually or automatically. 262 If the tunnels are not secured using IPsec, then some other method 263 should be used to ensure that packets are decapsulated and forwarded 264 by the tunnel tail only if those packets were encapsulated by the 265 tunnel head. This can be done by address filtering at the boundaries 266 of an administrative domain. When the tunnel head and the tunnel 267 tail are not in the same domain, this may become difficult, and it 268 can even become impossible if the packets must traverse the public 269 Internet. 271 9. Intellectual Property Notice 273 The IETF takes no position regarding the validity or scope of any 274 intellectual property or other rights that might be claimed to 275 pertain to the implementation or use of the technology described in 276 this document or the extent to which any license under such rights 277 might or might not be available; neither does it represent that it 278 has made any effort to identify any such rights. Information on the 279 IETF's procedures with respect to rights in standards-track and 280 standards-related documentation can be found in BCP-11. Copies of 281 claims of rights made available for publication and any assurances of 282 licenses to be made available, or the result of an attempt made to 283 obtain a general license or permission for the use of such 284 proprietary rights by implementors or users of this specification can 285 be obtained from the IETF Secretariat. 287 The IETF invites any interested party to bring to its attention any 288 copyrights, patents or patent applications, or other proprietary 289 rights which may cover technology that may be required to practice 290 this standard. Please address the information to the IETF Executive 291 Director. 293 10. Copyright Notice 295 "Copyright (C) The Internet Society (date). All Rights Reserved. 297 This document and translations of it may be copied and furnished to 298 others, and derivative works that comment on or otherwise explain it 299 or assist in its implementation may be prepared, copied, published 300 and distributed, in whole or in part, without restriction of any 301 kind, provided that the above copyright notice and this paragraph are 302 included on all such copies and derivative works. However, this 303 document itself may not be modified in any way, such as by removing 304 the copyright notice or references to the Internet Society or other 305 Internet organizations, except as needed for the purpose of 306 developing Internet standards in which case the procedures for 307 copyrights defined in the Internet Standards process must be 308 followed, or as required to translate it into languages other than 309 English. 311 The limited permissions granted above are perpetual and will not be 312 revoked by the Internet Society or its successors or assigns. 314 This document and the information contained herein is provided on an 315 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 316 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 317 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 318 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 319 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 321 11. Acknowledgments 323 This specification combines a draft on encapsulating MPLS in IP, by 324 Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew G. 325 Malis, and Rick Wilder, with a draft on encapsulating MPLS in GRE, by 326 Yakov Rekhter, Daniel Tappan, and Eric Rosen. The current authors 327 wish to thank all these authors for their contribution. We also 328 think Mark Duffy and Scott Bradner for their comments. 330 12. Normative References 332 [RFC791] "Internet Protocol," J. Postel, Sep 1981 334 [RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November 335 1990 337 [RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li, 338 S. Hanks, D. Meyer, P. Traina, March 2000 340 [RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A. 341 Viswanathan, R. Callon, January 2001 343 [RFC3032] "MPLS Label Stack Encoding", E. Rosen, D. Tappan, G. 344 Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001 346 13. Informative References 348 [RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S. 349 Deering and R. Hinden, RFC 2460,Dec 1998 351 [RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety, 352 August 2000 354 14. Author Information 356 Tom Worster 357 Email: fsb@thefsb.org 359 Yakov Rekhter 360 Juniper Networks, Inc. 361 1194 N. Mathilda Ave. 362 Sunnyvale, CA 94089 363 Email: yakov@juniper.net 365 Eric Rosen 366 Cisco Systems, Inc. 367 1414 Massachusetts Avenue 368 Boxborough, MA 01719 369 Email: erosen@cisco.com