idnits 2.17.1 draft-ietf-mpls-in-udp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 24, 2014) is 3744 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) == Unused Reference: 'RFC6830' is defined on line 437, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group X. Xu 2 Internet Draft Huawei 3 Category: Standard Track N. Sheth 4 Juniper 5 L. Yong 6 Huawei 7 C. Pignataro 8 Cisco 9 Y. Fan 10 China Telecom 12 Expires: July 2014 January 24, 2014 14 Encapsulating MPLS in UDP 16 draft-ietf-mpls-in-udp-05 18 Abstract 20 This document specifies an IP-based encapsulation for MPLS, called 21 MPLS-in-UDP (User Datagram Protocol). Note that the MPLS-in-UDP 22 encapsulation technology MUST only be deployed within a service 23 provider network or networks of an adjacent set of co-operating 24 service providers where the congestion control is not a concern. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 24, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ................................................ 3 61 1.1. Existing Encapsulations ................................ 3 62 1.2. Motivations for MPLS-in-UDP Encapsulation .............. 4 63 1.3. Application Statements ................................. 4 64 2. Terminology ................................................. 4 65 3. Encapsulation in UDP ........................................ 4 66 4. Processing Procedures ....................................... 6 67 5. Congestion Considerations ................................... 7 68 6. Security Considerations ..................................... 7 69 7. IANA Considerations ......................................... 8 70 8. Contributors ................................................ 9 71 9. Acknowledgements ............................................ 9 72 10. References ................................................. 9 73 10.1. Normative References .................................. 9 74 10.2. Informative References ............................... 10 75 Authors' Addresses ............................................ 11 77 1. Introduction 79 This document specifies an IP-based encapsulation for MPLS, i.e. 80 MPLS-in-UDP (User Datagram Protocol), which is applicable in some 81 circumstances where IP-based encapsulation for MPLS is required and 82 further fine-grained load balancing of MPLS packets over IP 83 networks over Equal Cost Multi-Path (ECMP) and/or Link Aggregation 84 Groups (LAG) is required as well. There are already IP-based 85 encapsulations for MPLS that allow for fine-grained load balancing 86 by using some special field in the encapsulation header as an 87 entropy field. However, MPLS-in-UDP can be advantageous since some 88 networks have used the UDP port number fields as a basis for load- 89 balancing solutions for some time. This is similar to why LISP [RFC 90 6830] uses UDP encapsulation. 92 Like other IP-based encapsulation methods for MPLS, this 93 encapsulation allows for two Label Switching Routers (LSR) to be 94 adjacent on a Label Switched Path (LSP), while separated by an IP 95 network. In order to support this encapsulation, each LSR needs to 96 know the capability to decapsulate MPLS-in-UDP by the remote LSRs. 97 This specification defines only the data plane encapsulation and 98 does not concern itself with how the knowledge to use this 99 encapsulation is conveyed. Specifically, this capability can be 100 either manually configured on each LSR or be dynamically advertised 101 in manners that are outside the scope of this document. 103 Similarly, the MPLS-in-UDP encapsulation format defined in this 104 document by itself cannot ensure the integrity and privacy of data 105 packets being transported through the MPLS-in-UDP tunnels and 106 cannot enable the tunnel decapsulators to authenticate the tunnel 107 encapsulator. Therefore, in the case where any of the above 108 security issues is concerned, the MPLS-in-UDP SHOULD be secured 109 with IPsec [RFC4301] or DTLS [RFC6347]. For more details, please 110 see Section 6 of Security Considerations. 112 1.1. Existing Encapsulations 114 Currently, there are several IP-based encapsulations for MPLS such 115 as MPLS-in-IP, MPLS-in-GRE (Generic Routing Encapsulation) 116 [RFC4023], and MPLS-in-L2TPv3 (Layer Two Tunneling Protocol - 117 Version 3) [RFC4817]. In all these methods, the IP addresses can be 118 varied to achieve load-balancing. 120 All these IP-based encapsulations for MPLS are specified for both 121 IPv4 and IPv6. In the case of IPv6-based encapsulations, the IPv6 122 Flow Label can be used for ECMP and LAGs [RFC6438]. However, there 123 is no such entropy field in the IPv4 header. 125 For MPLS-in-GRE as well as MPLS-in-L2TPv3, protocol fields (the GRE 126 Key and the L2TPv3 Session ID respectively) can be used as the 127 load-balancing key as described in [RFC5640]. For this, 128 intermediate routers need to understand these fields in the context 129 of being used as load-balancing keys. 131 1.2. Motivations for MPLS-in-UDP Encapsulation 133 Currently, most existing routers in IP networks are already capable 134 of distributing IP traffic "microflows" [RFC2474] over ECMPs and/or 135 LAG based on the hash of the five-tuple of User Datagram Protocol 136 (UDP)[RFC768] and Transmission Control Protocol (TCP) packets (i.e., 137 source IP address, destination IP address, source port, destination 138 port, and protocol). By encapsulating the MPLS packets into an UDP 139 tunnel and using the source port of the UDP header as an entropy 140 field, the existing load-balancing capability as mentioned above 141 can be leveraged to provide fine-grained load-balancing of MPLS 142 traffic over IP networks. 144 1.3. Application Statements 146 The MPLS-in-UDP encapsulation technology MUST only be deployed 147 within a Service Provider (SP) network or networks of an adjacent 148 set of co-operating SPs where the congestion control is not a 149 concern, rather than over the Internet where the congestion control 150 is a must. Furthermore, packet filters should be added so as to 151 prevent MPLS-in-UDP packets from escaping from the service provider 152 networks due to misconfiguation or packet errors. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 158 this document are to be interpreted as described in RFC-2119 159 [RFC2119]. 161 3. Encapsulation in UDP 163 MPLS-in-UDP encapsulation format is shown as follows: 165 0 1 2 3 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Source Port = Entropy | Dest Port = MPLS | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | UDP Length | UDP Checksum | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 ~ MPLS Label Stack ~ 174 | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | | 177 ~ Message Body ~ 178 | | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Source Port of UDP 183 This field contains a 16-bit entropy value that is 184 generated by the encapsulator to uniquely identify a 185 flow. What constitutes a flow is locally determined by 186 the encapsulator and therefore is outside the scope of 187 this document. What algorithm is actually used by the 188 encapsulator to generate an entropy value is outside 189 the scope of this document as well. In the case where 190 the tunnel does not need entropy, this field of all 191 packets belonging to a given flow SHOULD be set to a 192 randomly selected constant value so as to avoid packet 193 reordering. 195 Destination Port of UDP 197 This field is set to a value (TBD1) allocated by IANA 198 to indicate that the UDP tunnel payload is an MPLS 199 packet. 201 UDP Length 203 The usage of this field is in accordance with the 204 current UDP specification [RFC768]. 206 UDP Checksum 208 The usage of this field is in accordance with the 209 current UDP specification [RFC768]. In the IPv4 UDP 210 encapsulation case, this field is RECOMMENDED to be set 211 to zero. In the IPv6 UDP encapsulation case, this field 212 SHOULD NOT be set to zero. If the UDP checksum needs to 213 be disabled for performance or implementation reasons, 214 the considerations described in [RFC6935] [RFC6936] 215 MUST be examined. 217 MPLS Label Stack 219 This field contains an MPLS Label Stack as defined in 220 [RFC3032]. 222 Message Body 224 This field contains one MPLS message body. 226 4. Processing Procedures 228 This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded 229 through "UDP tunnels". When performing MPLS-in-UDP encapsulation by 230 the encapsulator, the entropy value would be generated by the 231 encapsulator and then be filled in the Source Port field of the UDP 232 header. The Destination Port field is set to a value (TBD1) 233 allocated by IANA to indicate that the UDP tunnel payload is an 234 MPLS packet. As for whether the top label in the MPLS label stack 235 is downstream-assigned or upstream-assigned, it SHOULD be 236 determined based on the tunnel destination IP address. That is to 237 say, if the destination IP address is a multicast address, the top 238 label SHOULD be upstream-assigned, otherwise if the destination IP 239 address is a unicast address, it SHOULD be downstream-assigned. 241 As such, intermediate routers, upon receiving these UDP 242 encapsulated packets, could balance these packets based on the hash 243 of the five-tuple of UDP packets. 245 Upon receiving these UDP encapsulated packets, the decapsulator 246 would decapsulate them by removing the UDP headers and then process 247 them accordingly. 249 As for other common processing procedures associated with tunneling 250 encapsulation technologies including but not limited to Maximum 251 Transmission Unit (MTU) and preventing fragmentation and reassembly, 252 Time to Live (TTL) and differentiated services, the corresponding 253 "Common Procedures" defined in [RFC4023] which are applicable for 254 MPLS-in-IP and MPLS-in-GRE encapsulation formats SHOULD be followed. 256 5. Congestion Considerations 258 Since the MPLS-in-UDP encapsulation causes MPLS packets to be 259 forwarded through "UDP tunnels", the congestion control guidelines 260 for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be 261 followed. Specifically, as stated in Section 3.1.3 of [RFC5405], 262 "some bulk transfer applications may choose not to implement any 263 congestion control mechanism and instead rely on transmitting 264 across reserved path capacity. This might be an acceptable choice 265 for a subset of restricted networking environments, but is by no 266 means a safe practice for operation in the Internet."Given the 267 fact that the MPLS-in-GRE and MPLS-in-IP [RFC4023] encapsulation 268 technologies have been successfully deployed within a SP network or 269 networks of an adjacent set of co-operating SPs which is a 270 restricted network environment without any congestion control 271 mechanism and the fact that the current MPLS technology couldn't 272 provide congestion control without major changes, the MPLS-in-UDP 273 encapsulation MUST only be deployed within a SP network or networks 274 of an adjacent set of co-operating SPs as well. 276 6. Security Considerations 278 The security problems faced with the MPLS-in-UDP tunnel are exactly 279 the same as those faced with MPLS-in-IP and MPLS-in-GRE tunnels 280 [RFC4023]. In other words,, the MPLS-in-UDP tunnel as defined in 281 this document by itself cannot ensure the integrity and privacy of 282 data packets being transported through the MPLS-in-UDP tunnel and 283 cannot enable the tunnel decapsulator to authenticate the tunnel 284 encapsulator. In the case where any of the above security issues is 285 concerned, the MPLS-in-UDP tunnel SHOULD be secured with IPsec or 286 DTLS. IPsec was designed as a network security mechanism and 287 therefore it resides at the network layer. As such, if the tunnel 288 is secured with IPsec, the UDP header would not be visible to 289 intermediate routers anymore in either IPsec tunnel or transport 290 mode. As a result, the meaning of adopting the MPLS-in-UDP tunnel 291 as an alternative to the MPLS-in-GRE or MPLS-in-IP tunnel is lost. 292 By comparison, DTLS is better suited for application security and 293 can better preserve network and transport layer protocol 294 information. Specifically, if DTLS is used, the destination port of 295 the UDP header will be filled with a value (TBD2) indicating MPLS 296 with DTLS and the source port can still be used as an entropy field 297 for load-sharing purposes. 299 If the tunnel is not secured with IPsec or DTLS, some other method 300 should be used to ensure that packets are decapsulated and 301 forwarded by the tunnel tail only if those packets were 302 encapsulated by the tunnel head. If the tunnel lies entirely within 303 a single administrative domain, address filtering at the boundaries 304 can be used to ensure that no packet with the IP source address of 305 a tunnel endpoint or with the IP destination address of a tunnel 306 endpoint can enter the domain from outside. However, when the 307 tunnel head and the tunnel tail are not in the same administrative 308 domain, this may become difficult, and filtering based on the 309 destination address can even become impossible if the packets must 310 traverse the public Internet. Sometimes only source address 311 filtering (but not destination address filtering) is done at the 312 boundaries of an administrative domain. If this is the case, the 313 filtering does not provide effective protection at all unless the 314 decapsulator of an MPLS-in-UDP validates the IP source address of 315 the packet. This document does not require that the decapsulator 316 validate the IP source address of the tunneled packets, but it 317 should be understood that failure to do so presupposes that there 318 is effective destination-based (or a combination of source-based 319 and destination-based) filtering at the boundaries. 321 7. IANA Considerations 323 One UDP destination port number indicating MPLS needs to be 324 allocated by IANA. 326 Service Name : MPLS-in-UDP 328 Transport Protocol(s) : UDP 330 Assignee: IESG 332 Contact : IETF Chair . 334 Description : Encapsulate MPLS packets in UDP tunnels. 336 Reference : This document -- draft-ietf-mpls-in-udp (MPLS WG 337 document). 339 Port Number : TBD1 -- To be assigned by IANA. 341 One UDP destination port number indicating MPLS with DTLS needs to 342 be allocated by IANA. 344 Service Name : MPLS-in-UDP-with-DTLS 346 Transport Protocol(s) : UDP 348 Assignee: IESG 349 Contact : IETF Chair . 351 Description : Encapsulate MPLS packets in UDP tunnels with DTLS. 353 Reference : This document -- draft-ietf-mpls-in-udp (MPLS WG 354 document). 356 Port Number : TBD2 -- To be assigned by IANA. 358 8. Contributors 360 Zhenbin Li 361 Huawei Technologies, 362 Beijing, China 363 Phone: +86-10-60613676 364 Email: lizhenbin@huawei.com 366 9. Acknowledgements 368 Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak, 369 Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks, 370 George Swallow, Loa Andersson, Ross Callon, Vivek Kumar, Stewart 371 Bryant, Wen Zhang, Curtis Villamizar, Joel M. Halpern, Scott Brim, 372 Alia Atlas, Alexander Vainshtein, Joel Jaeggli, Edward Crabbe, Lars 373 Eggert, Joe Touch, Lloyd Wood, Weiguo Hao, Mark Szczesniak, 374 Zhenxiao Liu and Xing Tong for their valuable comments and 375 suggestions on this document. Thanks to Daniel King, Gregory Mirsky 376 and Eric Osborne for their valuable MPLS-RT reviews on this 377 document. Special thanks to Adrian Farrel for his conscientious AD 378 review and insightful suggestion of using DTLS for securing the 379 MPLS-in-UDP tunnels. Thanks to Charlie Kaufman for his SecDir 380 review of this document. Thanks to Nevil Brownlee for the OPSDir 381 review of this document. Thanks to Roni Even for the Gen-ART review 382 of this document. Thanks to Pearl Liang for the IANA review of this 383 documents. 385 10. References 387 10.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, March 1997. 392 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 393 August 1980. 395 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 396 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 397 Encoding", RFC 3032, January 2001. 399 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 400 MPLS in IP or GRE", RFC4023, March 2005. 402 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 403 Internet Protocol", RFC 4301, December 2005. 405 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 406 Security Version 1.2", RFC 6347, January 2012. 408 10.2. Informative References 410 [RFC4817] M. Townsley, C. Pignataro, S. Wainner, T. Seely and J. 411 Young, "Encapsulation of MPLS over Layer 2 Tunneling 412 Protocol Version 3", RFC4817, March 2007. 414 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 415 Balancing for Mesh Softwires", RFC 5640, August 2009. 417 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "UDP 418 Checksums for Tunneled Packets", RFC6935, Feburary 2013. 420 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 421 for the use of IPv6 UDP Datagrams with Zero Checksums", 422 RFC6936, Feburary 2013. 424 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage 425 Guidelines for Application Designers", RFC 5405, November 426 2008. 428 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 429 "Definition of the Differentiated Services Field (DS 430 Field) in the IPv4 and IPv6 Headers", RFC2474, December 431 1998. 433 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 434 for Equal Cost Multipath Routing and Link Aggregation 435 in Tunnels", RFC 6438, November 2011. 437 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 438 Locator/ID Separation Protocol (LISP)", RFC 6830, 439 January 2013. 441 Authors' Addresses 443 Xiaohu Xu 444 Huawei Technologies 445 Beijing, China 446 Phone: +86-10-60610041 447 Email: xuxiaohu@huawei.com 449 Nischal Sheth 450 Juniper Networks 451 1194 N. Mathilda Ave 452 Sunnyvale, CA 94089 453 Email: nsheth@juniper.net 455 Lucy Yong 456 Huawei USA 457 5340 Legacy Dr. 458 Plano TX75025 459 Phone: 469-277-5837 460 Email: Lucy.yong@huawei.com 462 Carlos Pignataro 463 Cisco Systems 464 7200-12 Kit Creek Road 465 Research Triangle Park, NC 27709 466 USA 467 Email: cpignata@cisco.com 469 Yongbing Fan 470 China Telecom 471 Guangzhou, China. 472 Phone: +86 20 38639121 473 Email: fanyb@gsta.com