idnits 2.17.1 draft-ietf-mpls-in-udp-10.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 14, 2015) is 3383 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: July 18, 2015 Juniper Networks 6 L. Yong 7 Huawei USA 8 R. Callon 9 Juniper Networks 10 D. Black 11 EMC Corporation 12 January 14, 2015 14 Encapsulating MPLS in UDP 15 draft-ietf-mpls-in-udp-10 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 July 18, 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 . . . . . . . . . . . . . . . . . . . . . 13 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 10.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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. An 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. An MPLS-in-UDP receiver node SHOULD only allow the use of UDP 314 zero-checksum mode for IPv6 on a single received UDP Destination 315 Port regardless of the sender. 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. An MPLS-in-UDP receiver 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. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for 327 each MPLS-in-UDP tunnel that uses UDP zero-checksum mode 328 regardless of receiver in order to strengthen the receiver's 329 check of the IPv6 source address. When this is not possible, it 330 is RECOMMENDED to use each source IPv6 address for as few UDP 331 zero-checksum mode MPLS-in-UDP tunnels as is feasible. 333 f. Any middlebox support for MPLS-in-UDP with UDP zero-checksum mode 334 for IPv6 MUST comply with requirements 1 and 8-10 in Section 5 of 335 [RFC6936].[RFC6936]. 337 g. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP 338 checksums from "escaping" to the general Internet; see Section 5 339 for examples of such measures. 341 h. IPv6 traffic with zero UDP checksums MUST be actively monitored 342 for errors by the network operator. 344 The above requirements do not change either the requirements 345 specified in [RFC2460] as modified by [RFC6935] or the requirements 346 specified in [RFC6936]. 348 The requirement to check the source IPv6 address in addition to the 349 destination IPv6 address, plus the strong recommendation against 350 reuse of source IPv6 addresses among MPLS-in-UDP tunnels collectively 351 provide some mitigation for the absence of UDP checksum coverage of 352 the IPv6 header. In addition, the MPLS data plane only forwards 353 packets with valid labels (i.e., labels that have been distributed by 354 the tunnel egress LSR), providing some additional opportunity to 355 detect MPLS-in-UDP packet misdelivery when the misdelivered packet 356 contains a label that is not valid for forwarding at the receiving 357 LSR. The expected result for IPv6 UDP zero-checksum mode for MPLS- 358 in-UDP is that corruption of the destination IPv6 address will 359 usually cause packet discard, as offsetting corruptions to the source 360 IPv6 and/or MPLS top label are unlikely. Additional assurance is 361 provided by the restrictions in the above exceptions that limit usage 362 of IPv6 UDP zero-checksum mode to well-managed networks for which 363 MPLS packet corruption has not been a problem in practice. 365 Hence MPLS-in-UDP is suitable for transmission over lower layers in 366 the well-managed networks that are allowed by the exceptions stated 367 above and the rate of corruption of the inner IP packet on such 368 networks is not expected to increase by comparison to MPLS traffic 369 that is not encapsulated in UDP. For these reasons, MPLS-in-UDP does 370 not provide an additional integrity check when UDP zero-checksum mode 371 is used with IPv6, and this design is in accordance with requirements 372 2, 3 and 5 specified in Section 5 of [RFC6936]. 374 MPLS does not accumulate incorrect state as a consequence of label 375 stack corruption. A corrupt MPLS label results in either packet 376 discard or forwarding (and forgetting) of the packet without 377 accumulation of MPLS protocol state. Active monitoring of MPLS-in- 378 UDP traffic for errors is REQUIRED as occurrence of errors will 379 result in some accumulation of error information outside the MPLS 380 protocol for operational and management purposes. This design is in 381 accordance with requirement 4 specified in Section 5 of [RFC6936]. 383 The remaining requirements specified in Section 5 of [RFC6936] are 384 inapplicable to MPLS-in-UDP. Requirements 6 and 7 do not apply 385 because MPLS does not have an MPLS-generic control feedback 386 mechanism. Requirements 8-10 are middlebox requirements that do not 387 apply to MPLS-in-UDP tunnel endpoints, but see Section 3.2 for 388 further middlebox discussion. 390 In summary, UDP zero-checksum mode for IPv6 is allowed to be used 391 with MPLS-in-UDP when one of the three exceptions specified above 392 applies, provided that the additional requirements specified in this 393 section are complied with. Otherwise the UDP checksum MUST be used 394 for IPv6 as specified in [RFC0768] and [RFC2460]. 396 This entire section and its requirements apply only to use of UDP 397 zero-checksum mode for IPv6; they can be avoided by using the UDP 398 checksum as specified in [RFC0768] and [RFC2460]. 400 3.2. Middlebox Considerations for IPv6 UDP Zero Checksums 402 IPv6 datagrams with a zero UDP checksum will not be passed by any 403 middlebox that validates the checksum based on [RFC2460] or that 404 updates the UDP checksum field, such as NATs or firewalls. Changing 405 this behavior would require such middleboxes to be updated to 406 correctly handle datagrams with zero UDP checksums. The MPLS-in-UDP 407 encapsulation does not provide a mechanism to safely fall back to 408 using a checksum when a path change occurs redirecting a tunnel over 409 a path that includes a middlebox that discards IPv6 datagrams with a 410 zero UDP checksum. In this case the MPLS-in-UDP tunnel will be 411 black-holed by that middlebox. Recommended changes to allow 412 firewalls, NATs and other middleboxes to support use of an IPv6 zero 413 UDP checksum are described in Section 5 of [RFC6936]. 415 4. Processing Procedures 417 This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded 418 through "UDP tunnels". When performing MPLS-in-UDP encapsulation by 419 the encapsulator, the entropy value would be generated by the 420 encapsulator and then be filled in the Source Port field of the UDP 421 header. The Destination Port field is set to a value (TBD1) 422 allocated by IANA to indicate that the UDP tunnel payload is an MPLS 423 packet. As for whether the top label in the MPLS label stack is 424 downstream-assigned or upstream-assigned, it SHOULD be determined 425 based on the tunnel destination IP address. That is to say, if the 426 destination IP address is a multicast address, the top label SHOULD 427 be upstream-assigned, otherwise if the destination IP address is a 428 unicast address, it SHOULD be downstream-assigned. Intermediate 429 routers, upon receiving these UDP encapsulated packets, could balance 430 these packets based on the hash of the five-tuple of UDP packets. 431 Upon receiving these UDP encapsulated packets, the decapsulator would 432 decapsulate them by removing the UDP headers and then process them 433 accordingly. For other common processing procedures associated with 434 tunneling encapsulation technologies including but not limited to 435 Maximum Transmission Unit (MTU) and preventing fragmentation and 436 reassembly, Time to Live (TTL) and differentiated services, the 437 corresponding "Common Procedures" defined in [RFC4023] which are 438 applicable for MPLS-in-IP and MPLS-in-GRE encapsulation formats 439 SHOULD be followed. 441 5. Congestion Considerations 443 Section 3.1.3 of [RFC5405] discussed the congestion implications of 444 UDP tunnels. As discussed in [RFC5405], because other flows can 445 share the path with one or more UDP tunnels, congestion control 446 [RFC2914] needs to be considered. 448 A major motivation for encapsulating MPLS in UDP is to improve the 449 use of multipath (such as ECMP) in cases where traffic is to traverse 450 routers which are able to hash on UDP Port and IP address. As such, 451 in many cases this may reduce the occurrence of congestion and 452 improve usage of available network capacity. However, it is also 453 necessary to ensure that the network, including applications that use 454 the network, responds appropriately in more difficult cases, such as 455 when link or equipment failures have reduced the available capacity. 457 The impact of congestion must be considered both in terms of the 458 effect on the rest of the network of a UDP tunnel that is consuming 459 excessive capacity, and in terms of the effect on the flows using the 460 UDP tunnels. The potential impact of congestion from a UDP tunnel 461 depends upon what sort of traffic is carried over the tunnel, as well 462 as the path of the tunnel. 464 MPLS is widely used to carry a wide range of traffic. In many cases 465 MPLS is used to carry IP traffic. IP traffic is generally assumed to 466 be congestion controlled, and thus a tunnel carrying general IP 467 traffic (as might be expected to be carried across the Internet) 468 generally does not need additional congestion control mechanisms. As 469 specified in [RFC5405]: 471 "IP-based traffic is generally assumed to be congestion- 472 controlled, i.e., it is assumed that the transport protocols 473 generating IP-based traffic at the sender already employ 474 mechanisms that are sufficient to address congestion on the path. 475 Consequently, a tunnel carrying IP-based traffic should already 476 interact appropriately with other traffic sharing the path, and 477 specific congestion control mechanisms for the tunnel are not 478 necessary". 480 For this reason, where MPLS-in-UDP tunneling is used to carry IP 481 traffic that is known to be congestion controlled, the UDP tunnels 482 MAY be used within a single network or across multiple networks, with 483 cooperating network operators. Internet IP traffic is generally 484 assumed to be congestion-controlled. Similarly, in general Layer 3 485 VPNs are carrying IP traffic that is similarly assumed to be 486 congestion controlled. 488 Whether or not Layer 2 VPN traffic is congestion controlled may 489 depend upon the specific services being offered and what use is being 490 made of the layer 2 services. 492 However, MPLS is also used in many cases to carry traffic that is not 493 necessarily congestion controlled. For example, MPLS may be used to 494 carry pseudowire or VPN traffic where specific bandwidth guarantees 495 are provided to each pseudowire, or to each VPN. 497 In such cases network operators may avoid congestion by careful 498 provisioning of their networks, by rate limiting of user data 499 traffic, and/or by using MPLS Traffic Engineering (MPLS-TE) to assign 500 specific bandwidth guarantees to each LSP. Where MPLS is carried 501 over UDP over IP, the identity of each individual MPLS flow is in 502 general lost and MPLS-TE cannot be used to guarantee bandwidth to 503 specific flows (since many LSPs may be multiplexed over a single UDP 504 tunnel, and many UDP tunnels may be mixed in an IP network). 506 For this reason, where the MPLS traffic is not congestion controlled, 507 MPLS-in-UDP tunnels MUST only be used within a single operator's 508 network that utilizes careful provisioning (e.g., rate limiting at 509 the entries of the network while over-provisioning network capacity) 510 to ensure against congestion, or within a limited number of networks 511 whose operators closely cooperate in order to jointly provide this 512 same careful provisioning. 514 As such, MPLS-in-UDP MUST NOT be used over the general Internet, or 515 over non-cooperating network operators, to carry traffic that is not 516 congestion-controlled. 518 Measures SHOULD be taken to prevent non-congestion-controlled MPLS- 519 in-UDP traffic from "escaping" to the general Internet, e.g.: 521 a. Physical or logical isolation of the links carrying MPLS-over-UDP 522 from the general Internet. 524 b. Deployment of packet filters that block the UDP Destination Ports 525 used for MPLS-over-UDP. 527 c. Imposition of restrictions on MPLS-in-UDP traffic by software 528 tools used to set up MPLS-in-UDP tunnels between specific end 529 systems (as might be used within a single data center). 531 d. Use of a "Managed Circuit Breaker" for the MPLS traffic as 532 described in [I-D.ietf-tsvwg-circuit-breaker]. 534 6. Security Considerations 536 The security problems faced with the MPLS-in-UDP tunnel are exactly 537 the same as those faced with MPLS-in-IP and MPLS-in-GRE tunnels 538 [RFC4023]. In other words, the MPLS-in-UDP tunnel as defined in this 539 document by itself cannot ensure the integrity and privacy of data 540 packets being transported through the MPLS-in-UDP tunnel and cannot 541 enable the tunnel decapsulator to authenticate the tunnel 542 encapsulator. In the case where any of the above security issues is 543 concerned, the MPLS-in-UDP tunnel SHOULD be secured with IPsec or 544 DTLS. IPsec was designed as a network security mechanism and 545 therefore it resides at the network layer. As such, if the tunnel is 546 secured with IPsec, the UDP header would not be visible to 547 intermediate routers anymore in either IPsec tunnel or transport 548 mode. As a result, the meaning of adopting the MPLS-in-UDP tunnel as 549 an alternative to the MPLS-in-GRE or MPLS-in-IP tunnel is lost. By 550 comparison, DTLS is better suited for application security and can 551 better preserve network and transport layer protocol information. 552 Specifically, if DTLS is used, the destination port of the UDP header 553 will be filled with a value (TBD2) indicating MPLS with DTLS and the 554 source port can still be used as an entropy field for load-sharing 555 purposes. 557 If the tunnel is not secured with IPsec or DTLS, some other method 558 should be used to ensure that packets are decapsulated and forwarded 559 by the tunnel tail only if those packets were encapsulated by the 560 tunnel head. If the tunnel lies entirely within a single 561 administrative domain, address filtering at the boundaries can be 562 used to ensure that no packet with the IP source address of a tunnel 563 endpoint or with the IP destination address of a tunnel endpoint can 564 enter the domain from outside. However, when the tunnel head and the 565 tunnel tail are not in the same administrative domain, this may 566 become difficult, and filtering based on the destination address can 567 even become impossible if the packets must traverse the public 568 Internet. Sometimes only source address filtering (but not 569 destination address filtering) is done at the boundaries of an 570 administrative domain. If this is the case, the filtering does not 571 provide effective protection at all unless the decapsulator of an 572 MPLS-in-UDP validates the IP source address of the packet. 574 This document does not require that the decapsulator validate the IP 575 source address of the tunneled packets (with the exception that the 576 IPv6 source address MUST be validated when UDP zero-checksum mode is 577 used with IPv6), but it should be understood that failure to do so 578 presupposes that there is effective destination-based (or a 579 combination of source-based and destination-based) filtering at the 580 boundaries. MPLS-based VPN services rely on a VPN label in the MPLS 581 label stack to identify the VPN. Corruption of that label could leak 582 traffic across VPN boundaries. Such leakage is highly undesirable 583 when inter-VPN isolation is used for privacy or security reasons. 584 When that is the case, UDP checksums SHOULD be used for MPLS-in-UDP 585 with both IPv4 and IPv6, and in particular, UDP zero-checksum mode 586 SHOULD NOT be used with IPv6. Each UDP checksum covers the VPN 587 label, thereby providing increased assurance of isolation among VPNs. 589 7. IANA Considerations 591 One UDP destination port number indicating MPLS needs to be allocated 592 by IANA: 594 Service Name: MPLS-UDP 596 Transport Protocol(s): UDP 598 Assignee: IESG 600 Contact: IETF Chair . 602 Description: Encapsulate MPLS packets in UDP tunnels. 604 Reference: This document -- draft-ietf-mpls-in-udp (MPLS WG 605 document). 607 Port Number: TBD1 -- To be assigned by IANA. 609 One UDP destination port number indicating MPLS with DTLS needs to be 610 allocated by IANA: 612 Service Name: MPLS-UDP-DTLS 614 Transport Protocol(s): UDP 616 Assignee: IESG 618 Contact: IETF Chair . 620 Description: Encapsulate MPLS packets in UDP tunnels with DTLS. 622 Reference: This document -- draft-ietf-mpls-in-udp (MPLS WG 623 document). 625 Port Number: TBD2 -- To be assigned by IANA. 627 8. Contributors 629 Note that contributors are listed in alphabetical order according to 630 their last names. 632 Yongbing Fan 634 China Telecom 636 Email: fanyb@gsta.com 638 Adrian Farrel 640 Juniper Networks 642 Email: adrian@olddog.co.uk 644 Zhenbin Li 646 Huawei Technologies 648 Email: lizhenbin@huawei.com 650 Carlos Pignataro 652 Cisco Systems 654 Email: cpignata@cisco.com 656 Curtis Villamizar 658 Outer Cape Cod Network Consulting, LLC 659 Email: curtis@occnc.com 661 9. Acknowledgements 663 Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak, 664 Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks, 665 George Swallow, Loa Andersson, Vivek Kumar, Stewart Bryant, Wen 666 Zhang, Joel M. Halpern, Noel Chiappa, Scott Brim, Alia Atlas, 667 Alexander Vainshtein, Joel Jaeggli, Edward Crabbe, Mark Tinka, Lars 668 Eggert, Joe Touch, Lloyd Wood, Gorry Fairhurst, Weiguo Hao, Mark 669 Szczesniak, Zhenxiao Liu and Xing Tong for their valuable comments 670 and suggestions on this document. 672 Special thanks to Alia Atlas for her insightful suggestion of adding 673 an applicability statement. 675 Thanks to Daniel King, Gregory Mirsky and Eric Osborne for their 676 valuable MPLS-RT reviews on this document. Thanks to Charlie Kaufman 677 for his SecDir review of this document. Thanks to Nevil Brownlee for 678 the OPSDir review of this document. Thanks to Roni Even for the Gen- 679 ART review of this document. Thanks to Pearl Liang for the IANA 680 review of this documents. 682 10. References 684 10.1. Normative References 686 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 687 August 1980. 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, March 1997. 692 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 693 (IPv6) Specification", RFC 2460, December 1998. 695 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 696 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 697 Encoding", RFC 3032, January 2001. 699 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 700 Internet Protocol", RFC 4301, December 2005. 702 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 703 for Application Designers", BCP 145, RFC 5405, November 704 2008. 706 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 707 Security Version 1.2", RFC 6347, January 2012. 709 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 710 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 712 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 713 for the Use of IPv6 UDP Datagrams with Zero Checksums", 714 RFC 6936, April 2013. 716 10.2. Informative References 718 [I-D.ietf-tsvwg-circuit-breaker] 719 Fairhurst, G., "Network Transport Circuit Breakers", 720 draft-ietf-tsvwg-circuit-breaker-00 (work in progress), 721 September 2014. 723 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 724 "Definition of the Differentiated Services Field (DS 725 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 726 1998. 728 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 729 2914, September 2000. 731 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 732 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 733 4023, March 2005. 735 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 736 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 737 Protocol Version 3", RFC 4817, March 2007. 739 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 740 Balancing for Mesh Softwires", RFC 5640, August 2009. 742 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 743 for Equal Cost Multipath Routing and Link Aggregation in 744 Tunnels", RFC 6438, November 2011. 746 Authors' Addresses 747 Xiaohu Xu 748 Huawei Technologies 749 No.156 Beiqing Rd 750 Beijing 100095 751 CHINA 753 Phone: +86-10-60610041 754 Email: xuxiaohu@huawei.com 756 Nischal Sheth 757 Juniper Networks 758 1194 N. Mathilda Ave 759 Sunnyvale, CA 94089 760 USA 762 Email: nsheth@juniper.net 764 Lucy Yong 765 Huawei USA 766 5340 Legacy Dr 767 Plano, TX 75025 768 USA 770 Email: Lucy.yong@huawei.com 772 Ross Callon 773 Juniper Networks 774 10 Technology Park Drive 775 Westford, MA 01886 776 USA 778 Email: rcallon@juniper.net 780 David Black 781 EMC Corporation 782 176 South Street 783 Hopkinton, MA 01748 784 USA 786 Email: david.black@emc.com