idnits 2.17.1 draft-ietf-mpls-in-udp-11.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 121 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 31, 2015) is 3367 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-15) exists of draft-ietf-tsvwg-circuit-breaker-00 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track N. Sheth 5 Expires: August 4, 2015 Juniper Networks 6 L. Yong 7 Huawei USA 8 R. Callon 9 Juniper Networks 10 D. Black 11 EMC Corporation 12 January 31, 2015 14 Encapsulating MPLS in UDP 15 draft-ietf-mpls-in-udp-11 17 Abstract 19 This document specifies an IP-based encapsulation for MPLS, called 20 MPLS-in-UDP (User Datagram Protocol) for situations where UDP 21 encapsulation is preferred to direct use of MPLS, e.g., to enable 22 UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation. The 23 MPLS-in-UDP encapsulation technology must only be deployed within a 24 single network (with a single network operator) or networks of an 25 adjacent set of co-operating network operators where traffic is 26 managed to avoid congestion, rather than over the Internet where 27 congestion control is required. Usage restrictions apply to MPLS-in- 28 UDP usage for traffic that is not congestion controlled and to UDP 29 zero checksum usage with IPv6. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 4, 2015. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Existing Encapsulations . . . . . . . . . . . . . . . . . 3 67 1.2. Motivations for MPLS-in-UDP Encapsulation . . . . . . . . 3 68 1.3. Applicability Statements . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 4 71 3.1. UDP Checksum Usage with IPv6 . . . . . . . . . . . . . . 6 72 3.2. Middlebox Considerations for IPv6 UDP Zero Checksums . . 9 73 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 9 74 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 10 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 10.2. Informative References . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 This document specifies an IP-based encapsulation for MPLS, i.e. 87 MPLS-in-UDP (User Datagram Protocol), which is applicable in some 88 circumstances where IP-based encapsulation for MPLS is required and 89 further fine-grained load balancing of MPLS packets over IP networks 90 over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Groups 91 (LAG) is required as well. There are already IP-based encapsulations 92 for MPLS that allow for fine-grained load balancing by using some 93 special field in the encapsulation header as an entropy field. 94 However, MPLS-in-UDP can be advantageous since networks have used the 95 UDP port number fields as a basis for load-balancing solutions for 96 some time. 98 Like other IP-based encapsulation methods for MPLS, this 99 encapsulation allows for two Label Switching Routers (LSR) to be 100 adjacent on a Label Switched Path (LSP), while separated by an IP 101 network. In order to support this encapsulation, each LSR needs to 102 know the capability to decapsulate MPLS-in-UDP by the remote LSRs. 103 This specification defines only the data plane encapsulation and does 104 not concern itself with how the knowledge to use this encapsulation 105 is conveyed. Specifically, this capability can be either manually 106 configured on each LSR or be dynamically advertised in manners that 107 are outside the scope of this document. 109 Similarly, the MPLS-in-UDP encapsulation format defined in this 110 document by itself cannot ensure the integrity and privacy of data 111 packets being transported through the MPLS-in-UDP tunnels and cannot 112 enable the tunnel decapsulators to authenticate the tunnel 113 encapsulator. Therefore, in the case where any of the above security 114 issues is concerned, the MPLS-in-UDP SHOULD be secured with IPsec 115 [RFC4301] or DTLS [RFC6347]. For more details, please see Section 6 116 of Security Considerations. 118 1.1. Existing Encapsulations 120 Currently, there are several IP-based encapsulations for MPLS such as 121 MPLS-in-IP, MPLS-in-GRE (Generic Routing Encapsulation) [RFC4023], 122 and MPLS-in-L2TPv3 (Layer Two Tunneling Protocol - Version 3) 123 [RFC4817]. In all these methods, the IP addresses can be varied to 124 achieve load-balancing. 126 All these IP-based encapsulations for MPLS are specified for both 127 IPv4 and IPv6. In the case of IPv6-based encapsulations, the IPv6 128 Flow Label can be used for ECMP and LAGs [RFC6438]. However, there 129 is no such entropy field in the IPv4 header. 131 For MPLS-in-GRE as well as MPLS-in-L2TPv3, protocol fields (the GRE 132 Key and the L2TPv3 Session ID respectively) can be used as the load- 133 balancing key as described in [RFC5640]. For this, intermediate 134 routers need to understand these fields in the context of being used 135 as load-balancing keys. 137 1.2. Motivations for MPLS-in-UDP Encapsulation 139 Most existing routers in IP networks are already capable of 140 distributing IP traffic "microflows" [RFC2474] over ECMPs and/or LAG 141 based on the hash of the five-tuple of User Datagram Protocol (UDP) 142 [RFC0768] and Transmission Control Protocol (TCP) packets (i.e., 143 source IP address, destination IP address, source port, destination 144 port, and protocol). By encapsulating the MPLS packets into an UDP 145 tunnel and using the source port of the UDP header as an entropy 146 field, the existing load-balancing capability as mentioned above can 147 be leveraged to provide fine-grained load-balancing of MPLS traffic 148 over IP networks. 150 1.3. Applicability Statements 152 The MPLS-in-UDP encapsulation technology MUST only be deployed within 153 a single network (with a single network operator) or networks of an 154 adjacent set of co-operating network operators where traffic is 155 managed to avoid congestion, rather than over the Internet where 156 congestion control is required. Furthermore, packet filters SHOULD 157 be added to prevent MPLS-in-UDP packets from escaping from the 158 network due to misconfiguation or packet errors. 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 3. Encapsulation in UDP 168 MPLS-in-UDP encapsulation format is shown as follows: 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Source Port = Entropy | Dest Port = MPLS | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | UDP Length | UDP Checksum | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | 178 ~ MPLS Label Stack ~ 179 | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 181 ~ Message Body ~ 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Source Port of UDP 187 This field contains a 16-bit entropy value that is generated by 188 the encapsulator to uniquely identify a flow. What constitutes 189 a flow is locally determined by the encapsulator and therefore 190 is outside the scope of this document. What algorithm is 191 actually used by the encapsulator to generate an entropy value 192 is outside the scope of this document. 194 In case the tunnel does not need entropy, this field of all 195 packets belonging to a given flow SHOULD be set to a randomly 196 selected constant value so as to avoid packet reordering. 198 To ensure that the source port number is always in the range 199 49152 to 65535 (Note that those ports less than 49152 are 200 reserved by IANA to identify specific applications/protocols) 201 which may be required in some cases, instead of calculating a 202 16-bit hash, the encapsulator SHOULD calculate a 14-bit hash 203 and use those 14 bits as the least significant bits of the 204 source port field while the most significant two bits SHOULD be 205 set to binary 11. That still conveys 14 bits of entropy 206 information which would be enough as well in practice. 208 Destination Port of UDP 210 This field is set to a value (TBD1) allocated by IANA to 211 indicate that the UDP tunnel payload is an MPLS packet. 213 UDP Length 215 The usage of this field is in accordance with the current UDP 216 specification [RFC0768]. 218 UDP Checksum 220 For IPv4 UDP encapsulation, this field is RECOMMENDED to be set 221 to zero for performance or implementation reasons because the 222 IPv4 header includes a checksum and use of the UDP checksum is 223 optional with IPv4, unless checksum protection of VPN labels is 224 important (See Section 6). For IPv6 UDP encapsulation, the 225 IPv6 header does not include a checksum, so this field MUST 226 contain a UDP checksum that MUST be used as specified in 227 [RFC0768] and [RFC2460] unless one of the exceptions that 228 allows use of UDP zero-checksum mode (as specified in 229 [RFC6935]) applies. See Section 3.1 for specification of these 230 exceptions and additional requirements that apply when UDP 231 zero-checksum mode is used for MPLS-in-UDP traffic over IPv6. 233 MPLS Label Stack 235 This field contains an MPLS Label Stack as defined in 236 [RFC3032]. 238 Message Body 239 This field contains one MPLS message body. 241 3.1. UDP Checksum Usage with IPv6 243 When UDP is used over IPv6, the UDP checksum is relied upon to 244 protect both the IPv6 and UDP headers from corruption, and MUST be 245 used unless the requirements in [RFC6935] and [RFC6936] for use of 246 UDP zero-checksum mode with a tunnel protocol are satisfied. MPLS- 247 in-UDP is a tunnel protocol, and there is significant successful 248 deployment of MPLS-in-IPv6 without UDP (i.e., without a checksum that 249 covers the IPv6 header or the MPLS label stack), as described in 250 Section 3.1 of [RFC6936]: 252 "There is extensive experience with deployments using tunnel 253 protocols in well-managed networks (e.g., corporate networks and 254 service provider core networks). This has shown the robustness of 255 methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS 256 that do not employ a transport protocol checksum and that have not 257 specified mechanisms to protect from corruption of the unprotected 258 headers(such as the VPN Identifier in MPLS)". 260 The UDP checksum MUST be implemented and MUST be used in accordance 261 with [RFC0768] and [RFC2460] for MPLS-in-UDP traffic over IPv6 unless 262 one or more of the following exceptions applies and the additional 263 requirements stated below are also complied with. There are three 264 exceptions that allow use of UDP zero-checksum mode for IPv6 with 265 MPLS-in-UDP, subject to the additional requirements stated below in 266 this section. The three exceptions are: 268 a. Use of MPLS-in-UDP in networks under single administrative 269 control (such as within a single operator's network) where it is 270 known (perhaps through knowledge of equipment types and lower 271 layer checks) that packet corruption is exceptionally unlikely 272 and where the operator is willing to take the risk of undetected 273 packet corruption. 275 b. Use of MPLS-in-UDP in networks under single administrative 276 control (such as within a single operator's network) where it is 277 judged through observational measurements (perhaps of historic or 278 current traffic flows that use a non-zero checksum) that the 279 level of packet corruption is tolerably low and where the 280 operator is willing to take the risk of undetected packet 281 corruption. 283 c. Use of MPLS-in-UDP for traffic delivery for applications that are 284 tolerant of misdelivered or corrupted packets (perhaps through 285 higher layer checksum, validation, and retransmission or 286 transmission redundancy) where the operator is willing to rely on 287 the applications using the tunnel to survive any corrupt packets. 289 These exceptions may also be extended to the use of MPLS-in-UDP 290 within a set of closely cooperating network administrations (such as 291 network operators who have agreed to work together in order to 292 jointly provide specific services). Even when one of the above 293 exceptions applies, use of UDP checksums may be appropriate when VPN 294 services are provided over MPLS-in-UDP, see Section 6. 296 As such, for IPv6, the UDP checksum for MPLS-in-UDP MUST be used as 297 specified in [RFC0768] and [RFC2460] for tunnels that span multiple 298 networks whose network administrations do not cooperate closely, even 299 if each non-cooperating network administration independently 300 satisfies one or more of the exceptions for UDP zero-checksum mode 301 usage with MPLS-in-UDP over IPv6. 303 The following additional requirements apply to implementation and use 304 of UDP zero-checksum mode for MPLS-in-UDP over IPv6: 306 a. Use of the UDP checksum with IPv6 MUST be the default 307 configuration of all MPLS-in-UDP implementations. 309 b. The MPLS-in-UDP implementation MUST comply with all requirements 310 specified in Section 4 of [RFC6936] and with requirement 1 311 specified in Section 5 of [RFC6936]. 313 c. The tunnel decapsulator SHOULD only allow the use of UDP zero- 314 checksum mode for IPv6 on a single received UDP Destination Port 315 regardless of the encapsulator. The motivation for this 316 requirement is possible corruption of the UDP destination port, 317 which may cause packet delivery to the wrong UDP port. If that 318 other UDP port requires the UDP checksum, the misdelivered packet 319 will be discarded 321 d. The tunnel decapsulator MUST check that the source and 322 destination IPv6 addresses are valid for the MPLS-in-UDP tunnel 323 on which the packet was received if that tunnel uses UDP zero- 324 checksum mode and discard any packet for which this check fails. 326 e. The tunnel encapsulator SHOULD use different IPv6 addresses for 327 each MPLS-in-UDP tunnel that uses UDP zero-checksum mode 328 regardless of decapsulator in order to strengthen the 329 decapsulator's check of the IPv6 source address (i.e., the same 330 IPv6 source address SHOULD NOT be used with more than one IPv6 331 destination address, independent of whether that destination 332 address is a unicast or multicast address). When this is not 333 possible, it is RECOMMENDED to use each source IPv6 address for 334 as few UDP zero-checksum mode MPLS-in-UDP tunnels (i.e., with as 335 few destination IPv6 addresses) as is feasible. 337 f. Any middlebox support for MPLS-in-UDP with UDP zero-checksum mode 338 for IPv6 MUST comply with requirements 1 and 8-10 in Section 5 of 339 [RFC6936]. 341 g. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP 342 checksums from "escaping" to the general Internet; see Section 5 343 for examples of such measures. 345 h. IPv6 traffic with zero UDP checksums MUST be actively monitored 346 for errors by the network operator. 348 The above requirements do not change either the requirements 349 specified in [RFC2460] as modified by [RFC6935] or the requirements 350 specified in [RFC6936]. 352 The requirement to check the source IPv6 address in addition to the 353 destination IPv6 address, plus the strong recommendation against 354 reuse of source IPv6 addresses among MPLS-in-UDP tunnels collectively 355 provide some mitigation for the absence of UDP checksum coverage of 356 the IPv6 header. In addition, the MPLS data plane only forwards 357 packets with valid labels (i.e., labels that have been distributed by 358 the tunnel egress LSR), providing some additional opportunity to 359 detect MPLS-in-UDP packet misdelivery when the misdelivered packet 360 contains a label that is not valid for forwarding at the receiving 361 LSR. The expected result for IPv6 UDP zero-checksum mode for MPLS- 362 in-UDP is that corruption of the destination IPv6 address will 363 usually cause packet discard, as offsetting corruptions to the source 364 IPv6 and/or MPLS top label are unlikely. Additional assurance is 365 provided by the restrictions in the above exceptions that limit usage 366 of IPv6 UDP zero-checksum mode to well-managed networks for which 367 MPLS packet corruption has not been a problem in practice. 369 Hence MPLS-in-UDP is suitable for transmission over lower layers in 370 the well-managed networks that are allowed by the exceptions stated 371 above and the rate of corruption of the inner IP packet on such 372 networks is not expected to increase by comparison to MPLS traffic 373 that is not encapsulated in UDP. For these reasons, MPLS-in-UDP does 374 not provide an additional integrity check when UDP zero-checksum mode 375 is used with IPv6, and this design is in accordance with requirements 376 2, 3 and 5 specified in Section 5 of [RFC6936]. 378 MPLS does not accumulate incorrect state as a consequence of label 379 stack corruption. A corrupt MPLS label results in either packet 380 discard or forwarding (and forgetting) of the packet without 381 accumulation of MPLS protocol state. Active monitoring of MPLS-in- 382 UDP traffic for errors is REQUIRED as occurrence of errors will 383 result in some accumulation of error information outside the MPLS 384 protocol for operational and management purposes. This design is in 385 accordance with requirement 4 specified in Section 5 of [RFC6936]. 387 The remaining requirements specified in Section 5 of [RFC6936] are 388 inapplicable to MPLS-in-UDP. Requirements 6 and 7 do not apply 389 because MPLS does not have an MPLS-generic control feedback 390 mechanism. Requirements 8-10 are middlebox requirements that do not 391 apply to MPLS-in-UDP tunnel endpoints, but see Section 3.2 for 392 further middlebox discussion. 394 In summary, UDP zero-checksum mode for IPv6 is allowed to be used 395 with MPLS-in-UDP when one of the three exceptions specified above 396 applies, provided that the additional requirements specified in this 397 section are complied with. Otherwise the UDP checksum MUST be used 398 for IPv6 as specified in [RFC0768] and [RFC2460]. 400 This entire section and its requirements apply only to use of UDP 401 zero-checksum mode for IPv6; they can be avoided by using the UDP 402 checksum as specified in [RFC0768] and [RFC2460]. 404 3.2. Middlebox Considerations for IPv6 UDP Zero Checksums 406 IPv6 datagrams with a zero UDP checksum will not be passed by any 407 middlebox that validates the checksum based on [RFC2460] or that 408 updates the UDP checksum field, such as NATs or firewalls. Changing 409 this behavior would require such middleboxes to be updated to 410 correctly handle datagrams with zero UDP checksums. The MPLS-in-UDP 411 encapsulation does not provide a mechanism to safely fall back to 412 using a checksum when a path change occurs redirecting a tunnel over 413 a path that includes a middlebox that discards IPv6 datagrams with a 414 zero UDP checksum. In this case the MPLS-in-UDP tunnel will be 415 black-holed by that middlebox. Recommended changes to allow 416 firewalls, NATs and other middleboxes to support use of an IPv6 zero 417 UDP checksum are described in Section 5 of [RFC6936]. 419 4. Processing Procedures 421 This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded 422 through "UDP tunnels". When performing MPLS-in-UDP encapsulation by 423 the encapsulator, the entropy value would be generated by the 424 encapsulator and then be filled in the Source Port field of the UDP 425 header. The Destination Port field is set to a value (TBD1) 426 allocated by IANA to indicate that the UDP tunnel payload is an MPLS 427 packet. As for whether the top label of the encapsulated MPLS packet 428 is downstream-assigned or upstream-assigned, it is determined 429 according to the following criteria which are compatible with 430 [RFC5332]: 432 a. If the tunnel destination IP address is a unicast address, the 433 top label MUST be downstream-assigned; 435 b. If the tunnel destination IP address is an IP multicast address, 436 either all encapsulated MPLS packets in the particular tunnel 437 have a downstream-assigned label at the top of the stack, or all 438 encapsulated MPLS packets in that tunnel have an upstream- 439 assigned label at the top of the stack. The means by which this 440 is determined for a particular tunnel is outside the scope of 441 this specification. In the absence of any knowledge about a 442 specific tunnel, the label SHOULD be presumed to be upstream- 443 assigned. 445 Intermediate routers, upon receiving these UDP encapsulated packets, 446 could balance these packets based on the hash of the five-tuple of 447 UDP packets. Upon receiving these UDP encapsulated packets, the 448 decapsulator would decapsulate them by removing the UDP headers and 449 then process them accordingly. For other common processing 450 procedures associated with tunneling encapsulation technologies 451 including but not limited to Maximum Transmission Unit (MTU) and 452 preventing fragmentation and reassembly, Time to Live (TTL) and 453 differentiated services, the corresponding "Common Procedures" 454 defined in [RFC4023] which are applicable for MPLS-in-IP and MPLS-in- 455 GRE encapsulation formats SHOULD be followed. 457 Note: Each UDP tunnel is unidirectional, as MPLS-in-UDP traffic is 458 sent to the IANA-allocated UDP Destination Port, and in particular, 459 is never sent back to any port used as a UDP Source Port (which 460 serves solely as a source of entropy). This is at odds with a common 461 middlebox (e.g., firewall) assumption that bidirectional traffic uses 462 a common pair of UDP ports. As a result, arranging to pass 463 bidirectional MPLS-in-UDP traffic through middleboxes may require 464 separate configuration for each direction of traffic. 466 5. Congestion Considerations 468 Section 3.1.3 of [RFC5405] discussed the congestion implications of 469 UDP tunnels. As discussed in [RFC5405], because other flows can 470 share the path with one or more UDP tunnels, congestion control 471 [RFC2914] needs to be considered. 473 A major motivation for encapsulating MPLS in UDP is to improve the 474 use of multipath (such as ECMP) in cases where traffic is to traverse 475 routers which are able to hash on UDP Port and IP address. As such, 476 in many cases this may reduce the occurrence of congestion and 477 improve usage of available network capacity. However, it is also 478 necessary to ensure that the network, including applications that use 479 the network, responds appropriately in more difficult cases, such as 480 when link or equipment failures have reduced the available capacity. 482 The impact of congestion must be considered both in terms of the 483 effect on the rest of the network of a UDP tunnel that is consuming 484 excessive capacity, and in terms of the effect on the flows using the 485 UDP tunnels. The potential impact of congestion from a UDP tunnel 486 depends upon what sort of traffic is carried over the tunnel, as well 487 as the path of the tunnel. 489 MPLS is widely used to carry a wide range of traffic. In many cases 490 MPLS is used to carry IP traffic. IP traffic is generally assumed to 491 be congestion controlled, and thus a tunnel carrying general IP 492 traffic (as might be expected to be carried across the Internet) 493 generally does not need additional congestion control mechanisms. As 494 specified in [RFC5405]: 496 "IP-based traffic is generally assumed to be congestion- 497 controlled, i.e., it is assumed that the transport protocols 498 generating IP-based traffic at the sender already employ 499 mechanisms that are sufficient to address congestion on the path. 500 Consequently, a tunnel carrying IP-based traffic should already 501 interact appropriately with other traffic sharing the path, and 502 specific congestion control mechanisms for the tunnel are not 503 necessary". 505 For this reason, where MPLS-in-UDP tunneling is used to carry IP 506 traffic that is known to be congestion controlled, the UDP tunnels 507 MAY be used within a single network or across multiple networks, with 508 cooperating network operators. Internet IP traffic is generally 509 assumed to be congestion-controlled. Similarly, in general Layer 3 510 VPNs are carrying IP traffic that is similarly assumed to be 511 congestion controlled. 513 Whether or not Layer 2 VPN traffic is congestion controlled may 514 depend upon the specific services being offered and what use is being 515 made of the layer 2 services. 517 However, MPLS is also used in many cases to carry traffic that is not 518 necessarily congestion controlled. For example, MPLS may be used to 519 carry pseudowire or VPN traffic where specific bandwidth guarantees 520 are provided to each pseudowire, or to each VPN. 522 In such cases network operators may avoid congestion by careful 523 provisioning of their networks, by rate limiting of user data 524 traffic, and/or by using MPLS Traffic Engineering (MPLS-TE) to assign 525 specific bandwidth guarantees to each LSP. Where MPLS is carried 526 over UDP over IP, the identity of each individual MPLS flow is in 527 general lost and MPLS-TE cannot be used to guarantee bandwidth to 528 specific flows (since many LSPs may be multiplexed over a single UDP 529 tunnel, and many UDP tunnels may be mixed in an IP network). 531 For this reason, where the MPLS traffic is not congestion controlled, 532 MPLS-in-UDP tunnels MUST only be used within a single operator's 533 network that utilizes careful provisioning (e.g., rate limiting at 534 the entries of the network while over-provisioning network capacity) 535 to ensure against congestion, or within a limited number of networks 536 whose operators closely cooperate in order to jointly provide this 537 same careful provisioning. 539 As such, MPLS-in-UDP MUST NOT be used over the general Internet, or 540 over non-cooperating network operators, to carry traffic that is not 541 congestion-controlled. 543 Measures SHOULD be taken to prevent non-congestion-controlled MPLS- 544 in-UDP traffic from "escaping" to the general Internet, e.g.: 546 a. Physical or logical isolation of the links carrying MPLS-over-UDP 547 from the general Internet. 549 b. Deployment of packet filters that block the UDP Destination Ports 550 used for MPLS-over-UDP. 552 c. Imposition of restrictions on MPLS-in-UDP traffic by software 553 tools used to set up MPLS-in-UDP tunnels between specific end 554 systems (as might be used within a single data center). 556 d. Use of a "Managed Circuit Breaker" for the MPLS traffic as 557 described in [I-D.ietf-tsvwg-circuit-breaker]. 559 6. Security Considerations 561 The security problems faced with the MPLS-in-UDP tunnel are exactly 562 the same as those faced with MPLS-in-IP and MPLS-in-GRE tunnels 563 [RFC4023]. In other words, the MPLS-in-UDP tunnel as defined in this 564 document by itself cannot ensure the integrity and privacy of data 565 packets being transported through the MPLS-in-UDP tunnel and cannot 566 enable the tunnel decapsulator to authenticate the tunnel 567 encapsulator. In the case where any of the above security issues is 568 concerned, the MPLS-in-UDP tunnel SHOULD be secured with IPsec or 569 DTLS. IPsec was designed as a network security mechanism and 570 therefore it resides at the network layer. As such, if the tunnel is 571 secured with IPsec, the UDP header would not be visible to 572 intermediate routers anymore in either IPsec tunnel or transport 573 mode. As a result, the meaning of adopting the MPLS-in-UDP tunnel as 574 an alternative to the MPLS-in-GRE or MPLS-in-IP tunnel is lost. By 575 comparison, DTLS is better suited for application security and can 576 better preserve network and transport layer protocol information. 577 Specifically, if DTLS is used, the destination port of the UDP header 578 MUST be set to an IANA-assigned value (TBD2) indicating MPLS-in-UDP 579 with DTLS, and that UDP port MUST NOT be used for other traffic. The 580 UDP source port field can still be used to add entropy, e.g., for 581 load-sharing purposes. DTLS usage is limited to a single DTLS 582 session for any specific tunnel encapsulator/ decapsulator pair 583 (identified by source and destination IP addresses). Both IP 584 addresses MUST be unicast addresses - multicast traffic is not 585 supported when DTLS is used. An MPLS-in-UDP tunnel decapsulator 586 implementation that supports DTLS is expected to be able to establish 587 DTLS sessions with multiple tunnel encapsulators, and likewise an 588 MPLS-in-UDP tunnel encapsulator implementation is expected to be able 589 to establish DTLS sessions with multiple decapsulators (although 590 different source and/or destination IP addresses may be involved - 591 see Section 3.1 for discussion of one situation where use of 592 different source IP addresses is important). 594 If the tunnel is not secured with IPsec or DTLS, some other method 595 should be used to ensure that packets are decapsulated and forwarded 596 by the tunnel tail only if those packets were encapsulated by the 597 tunnel head. If the tunnel lies entirely within a single 598 administrative domain, address filtering at the boundaries can be 599 used to ensure that no packet with the IP source address of a tunnel 600 endpoint or with the IP destination address of a tunnel endpoint can 601 enter the domain from outside. However, when the tunnel head and the 602 tunnel tail are not in the same administrative domain, this may 603 become difficult, and filtering based on the destination address can 604 even become impossible if the packets must traverse the public 605 Internet. Sometimes only source address filtering (but not 606 destination address filtering) is done at the boundaries of an 607 administrative domain. If this is the case, the filtering does not 608 provide effective protection at all unless the decapsulator of an 609 MPLS-in-UDP validates the IP source address of the packet. 611 This document does not require that the decapsulator validate the IP 612 source address of the tunneled packets (with the exception that the 613 IPv6 source address MUST be validated when UDP zero-checksum mode is 614 used with IPv6), but it should be understood that failure to do so 615 presupposes that there is effective destination-based (or a 616 combination of source-based and destination-based) filtering at the 617 boundaries. MPLS-based VPN services rely on a VPN label in the MPLS 618 label stack to identify the VPN. Corruption of that label could leak 619 traffic across VPN boundaries. Such leakage is highly undesirable 620 when inter-VPN isolation is used for privacy or security reasons. 622 When that is the case, UDP checksums SHOULD be used for MPLS-in-UDP 623 with both IPv4 and IPv6, and in particular, UDP zero-checksum mode 624 SHOULD NOT be used with IPv6. Each UDP checksum covers the VPN 625 label, thereby providing increased assurance of isolation among VPNs. 627 7. IANA Considerations 629 One UDP destination port number indicating MPLS needs to be allocated 630 by IANA: 632 Service Name: MPLS-UDP 634 Transport Protocol(s): UDP 636 Assignee: IESG 638 Contact: IETF Chair . 640 Description: Encapsulate MPLS packets in UDP tunnels. 642 Reference: This document -- draft-ietf-mpls-in-udp (MPLS WG 643 document). 645 Port Number: TBD1 -- To be assigned by IANA. 647 One UDP destination port number indicating MPLS with DTLS needs to be 648 allocated by IANA: 650 Service Name: MPLS-UDP-DTLS 652 Transport Protocol(s): UDP 654 Assignee: IESG 656 Contact: IETF Chair . 658 Description: Encapsulate MPLS packets in UDP tunnels with DTLS. 660 Reference: This document -- draft-ietf-mpls-in-udp (MPLS WG 661 document). 663 Port Number: TBD2 -- To be assigned by IANA. 665 8. Contributors 667 Note that contributors are listed in alphabetical order according to 668 their last names. 670 Yongbing Fan 672 China Telecom 674 Email: fanyb@gsta.com 676 Adrian Farrel 678 Juniper Networks 680 Email: adrian@olddog.co.uk 682 Zhenbin Li 684 Huawei Technologies 686 Email: lizhenbin@huawei.com 688 Carlos Pignataro 690 Cisco Systems 692 Email: cpignata@cisco.com 694 Curtis Villamizar 696 Outer Cape Cod Network Consulting, LLC 698 Email: curtis@occnc.com 700 9. Acknowledgements 702 Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak, 703 Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks, 704 George Swallow, Loa Andersson, Vivek Kumar, Stewart Bryant, Wen 705 Zhang, Joel M. Halpern, Noel Chiappa, Scott Brim, Alia Atlas, 706 Alexander Vainshtein, Joel Jaeggli, Edward Crabbe, Mark Tinka, Lars 707 Eggert, Joe Touch, Lloyd Wood, Gorry Fairhurst, Weiguo Hao, Mark 708 Szczesniak, Stephen Farrell, Zhenxiao Liu and Xing Tong for their 709 valuable comments and suggestions on this document. 711 Special thanks to Alia Atlas for her insightful suggestion of adding 712 an applicability statement. 714 Thanks to Daniel King, Gregory Mirsky and Eric Osborne for their 715 valuable MPLS-RT reviews on this document. Thanks to Charlie Kaufman 716 for his SecDir review of this document. Thanks to Nevil Brownlee for 717 the OPSDir review of this document. Thanks to Roni Even for the Gen- 718 ART review of this document. Thanks to Pearl Liang for the IANA 719 review of this documents. 721 10. References 723 10.1. Normative References 725 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 726 August 1980. 728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 729 Requirement Levels", BCP 14, RFC 2119, March 1997. 731 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 732 (IPv6) Specification", RFC 2460, December 1998. 734 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 735 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 736 Encoding", RFC 3032, January 2001. 738 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 739 Internet Protocol", RFC 4301, December 2005. 741 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 742 Multicast Encapsulations", RFC 5332, August 2008. 744 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 745 for Application Designers", BCP 145, RFC 5405, November 746 2008. 748 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 749 Security Version 1.2", RFC 6347, January 2012. 751 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 752 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 754 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 755 for the Use of IPv6 UDP Datagrams with Zero Checksums", 756 RFC 6936, April 2013. 758 10.2. Informative References 760 [I-D.ietf-tsvwg-circuit-breaker] 761 Fairhurst, G., "Network Transport Circuit Breakers", 762 draft-ietf-tsvwg-circuit-breaker-00 (work in progress), 763 September 2014. 765 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 766 "Definition of the Differentiated Services Field (DS 767 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 768 1998. 770 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 771 2914, September 2000. 773 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 774 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 775 4023, March 2005. 777 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 778 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 779 Protocol Version 3", RFC 4817, March 2007. 781 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 782 Balancing for Mesh Softwires", RFC 5640, August 2009. 784 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 785 for Equal Cost Multipath Routing and Link Aggregation in 786 Tunnels", RFC 6438, November 2011. 788 Authors' Addresses 790 Xiaohu Xu 791 Huawei Technologies 792 No.156 Beiqing Rd 793 Beijing 100095 794 CHINA 796 Phone: +86-10-60610041 797 Email: xuxiaohu@huawei.com 798 Nischal Sheth 799 Juniper Networks 800 1194 N. Mathilda Ave 801 Sunnyvale, CA 94089 802 USA 804 Email: nsheth@juniper.net 806 Lucy Yong 807 Huawei USA 808 5340 Legacy Dr 809 Plano, TX 75025 810 USA 812 Email: Lucy.yong@huawei.com 814 Ross Callon 815 Juniper Networks 816 10 Technology Park Drive 817 Westford, MA 01886 818 USA 820 Email: rcallon@juniper.net 822 David Black 823 EMC Corporation 824 176 South Street 825 Hopkinton, MA 01748 826 USA 828 Email: david.black@emc.com