idnits 2.17.1 draft-xu-intarea-ip-in-udp-08.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 (December 12, 2019) is 1595 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 1981 (Obsoleted by RFC 8201) ** 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) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA Working Group X. Xu 3 Internet-Draft Alibaba Inc 4 Intended status: Standards Track H. Assarpour 5 Expires: June 14, 2020 Broadcom 6 S. Ma 7 Mellanox 8 D. Bernier 9 Canada Bell 10 D. Dukes 11 Cisco 12 S. Hegde 13 Juniper 14 Y. Lee 15 Comcast 16 Y. Fan 17 China Telecom 18 December 12, 2019 20 Encapsulating IP in UDP 21 draft-xu-intarea-ip-in-udp-08 23 Abstract 25 Existing IP-in-IP encapsulation technologies are not adequate for 26 efficient load balancing of IP-in-IP traffic across IP networks. 27 This document specifies additional IP-in-IP encapsulation technology, 28 referred to as IP-in-UDP (User Datagram Protocol), which can 29 facilitate the load balancing of IP-in-IP traffic across IP networks. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on June 14, 2020. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 4 74 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 5 75 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 6 76 6. Applicability Statements . . . . . . . . . . . . . . . . . . 6 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 82 10.2. Informative References . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 To fully utilize the bandwidth available in IP networks and/or 88 facilitate recovery from a link or node failure, load balancing of 89 traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation 90 Group (LAG) across IP networks is widely used. [RFC5640] describes a 91 method for improving the load balancing efficiency in a network 92 carrying IP-in-IP traffic [RFC5565] over Layer Two Tunneling Protocol 93 - Version 3 (L2TPv3) [RFC3931] and Generic Routing Encapsulation 94 (GRE) [RFC2784] encapsulations. However, this method requires core 95 routers to perform hash calculation on the "load- balancing" field 96 contained in tunnel encapsulation headers (i.e., the Session ID field 97 in L2TPv3 headers or the Key field in GRE headers), which is not 98 widely supported by existing core routers. 100 Most existing routers in IP networks are already capable of 101 distributing IP traffic "microflows" [RFC2474] over ECMP paths and/or 102 LAG based on the hash of the five-tuple of User Datagram Protocol 103 (UDP) [RFC0768] and Transmission Control Protocol (TCP) packets 104 (i.e., source IP address, destination IP address, source port, 105 destination port, and protocol). By encapsulating the IP traffic 106 into an UDP tunnel and using the source port of the UDP header as an 107 entropy field, the existing load-balancing capability as mentioned 108 above can be leveraged to provide fine-grained load-balancing of IP- 109 in-IP traffic over IP networks. This is similar to why LISP 110 [RFC6830] , MPLS-in-UDP [RFC7510] and VXLAN [RFC7348] use UDP 111 encapsulation. Therefore, this specification defines an IP-in-UDP 112 encapsulation method which is an alternative encapsulation used in 113 [RFC5565] in addition to L2TPv3 and GRE. 115 IPv6 flow label has been proposed as an entropy field for load 116 balancing in IPv6 network environment [RFC6438]. However, as stated 117 in [RFC6936], the end-to-end use of flow labels for load balancing is 118 a long-term solution and therefore the use of load balancing using 119 the transport header fields would continue until any widespread 120 deployment is finally achieved. As such, IP-in-UDP encapsulation 121 would still have a practical application value in the IPv6 networks 122 during this transition timeframe. Of course, it RECOMMENDED that the 123 IPv6 flow label is filled with an entropy value as well. In this 124 way, core routers could perform load-balancing of IP-in-IP traffic 125 using either the approach as described in [RFC6438] or the UDP five 126 tuple accordingly. 128 Similarly, the IP-in-UDP encapsulation format defined in this 129 document by itself cannot ensure the integrity and privacy of data 130 packets being transported through the IP-in-UDP tunnels and cannot 131 enable the tunnel decapsulators to authenticate the tunnel 132 encapsulator. Therefore, in the case where any of the above security 133 issues is concerned, the IP-in-UDP SHOULD be secured with IPsec 134 [RFC4301] or DTLS [RFC6347]. For more details, please see Section 6 135 of Security Considerations. 137 2. Terminology 139 This memo makes use of the terms defined in [RFC5565]. 141 3. Encapsulation in UDP 143 IP-in-UDP encapsulation format is shown as follows: 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Source Port = Entropy | Dest Port = TBD1 | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | UDP Length | UDP Checksum | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | | 153 ~ IP Packet ~ 154 | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 Figure 1: IP-in-UDP Encapsulation Format 158 Source Port of UDP: 160 This field contains a 16-bit entropy value that is generated by 161 the encapsulator to uniquely identify a flow. What constitutes 162 a flow is locally determined by the encapsulator and therefore 163 is outside the scope of this document. What algorithm is 164 actually used by the encapsulator to generate an entropy value 165 is outside the scope of this document. 167 To ensure that the source port number is always in the range 168 49152 to 65535 (Note that those ports less than 49152 are 169 reserved by IANA to identify specific applications/protocols) 170 which may be required in some cases, instead of calculating a 171 16-bit entropy, the encapsulator SHOULD calculate a 14-bit 172 entropy and use those 14 bits as the least significant bits of 173 the source port field while the most significant two bits 174 SHOULD be set to binary 11. That still conveys 14 bits of 175 entropy information which would be enough as well in practice. 177 Destination Port of UDP: 179 This field is set to a value (TBD1) allocated by IANA to 180 indicate that the UDP tunnel payload is an IP packet. As for 181 whether the encapsulated IP packet is IPv4 or IPv6, it would be 182 determined according to the Version field in the IP header of 183 the encapsulated IP packet. 185 UDP Length: 187 The usage of this field is in accordance with the current UDP 188 specification [RFC0768]. 190 UDP Checksum: 192 For IPv4 UDP encapsulation, this field is RECOMMENDED to be set 193 to zero for performance or implementation reasons because the 194 IPv4 header includes a checksum and use of the UDP checksum is 195 optional with IPv4. For IPv6 UDP encapsulation, the IPv6 196 header does not include a checksum, so this field MUST contain 197 a UDP checksum that MUST be used as specified in [RFC0768] and 198 [RFC2460] unless one of the exceptions that allows use of UDP 199 zero-checksum mode (as specified in [RFC6935]) applies. 201 IP Packet: 203 This field contains one IP packet. 205 4. Processing Procedures 207 This IP-in-UDP encapsulation causes E-IP [RFC5565] packets to be 208 forwarded across an I-IP [RFC5565] transit core via "UDP tunnels". 209 While performing IP-in-UDP encapsulation, an ingress AFBR (e.g. PE 210 router) would generate an entropy value and encode it in the Source 211 Port field of the UDP header. The Destination Port field is set to a 212 value (TBD1) allocated by IANA to indicate that the UDP tunnel 213 payload is an IP packet. Transit routers, upon receiving these UDP 214 encapsulated IP packets, could balance these packets based on the 215 hash of the five-tuple of UDP packets. Egress AFBRs receiving these 216 UDP encapsulated IP packets MUST decapsulate these packets by 217 removing the UDP header and then forward them accordingly (assuming 218 that the Destination Port was set to the reserved value pertaining to 219 IP). 221 Similar to all other IP-in-IP tunneling technologies, IP-in-UDP 222 encapsulation introduces overheads and reduces the effective Maximum 223 Transmission Unit (MTU) size. IP-in-UDP encapsulation may also 224 impact Time-to-Live (TTL) or Hop Count (HC) and Differentiated 225 Services (DSCP). Hence, IP-in-UDP MUST follow the corresponding 226 procedures defined in [RFC2003]. 228 Ingress AFBRs MUST NOT fragment I-IP packets (i.e., UDP encapsulated 229 IP packets), and when the outer IP header is IPv4, ingress AFBRs MUST 230 set the DF bit in the outer IPv4 header. It is strongly RECOMMENDED 231 that I-IP transit core be configured to carry an MTU at least large 232 enough to accommodate the added encapsulation headers. Meanwhile, it 233 is strongly RECOMMENDED that Path MTU Discovery [RFC1191] [RFC1981] 234 or Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] is used 235 to prevent or minimize fragmentation. Once an ingress AFBR needs to 236 perform fragmentation on an E-IP packet before encapsulating, it MUST 237 use the same source UDP port for all fragmented packets so as to 238 ensures these fragmented packets are always forwarded on the same 239 path. Note that fragmentation on E-IP packets is possible only when 240 the E-IP packets are IPv4 packets and the DF bit is not set. 242 5. Congestion Considerations 244 Section 3.1.3 of [RFC5405] discussed the congestion implications of 245 UDP tunnels. As discussed in [RFC5405], because other flows can 246 share the path with one or more UDP tunnels, congestion control 247 [RFC2914] needs to be considered. As specified in [RFC5405]: 249 "IP-based traffic is generally assumed to be congestion- controlled, 250 i.e., it is assumed that the transport protocols generating IP-based 251 traffic at the sender already employ mechanisms that are sufficient 252 to address congestion on the path. Consequently, a tunnel carrying 253 IP-based traffic should already interact appropriately with other 254 traffic sharing the path, and specific congestion control mechanisms 255 for the tunnel are not necessary". 257 Since IP-in-UDP is only used to carry IP traffic which is generally 258 assumed to be congestion controlled by the transport layer, it 259 generally does not need additional congestion control mechanisms. 260 Furthermore, as it is explicitly stated in the Application Statements 261 (Section 1.2), this IP-in-UDP encapsulation method MUST only be used 262 within networks that are well-managed, therefore, congestion control 263 mechanism is not needed. 265 6. Applicability Statements 267 This IP-in-UDP encapsulation technology MUST only be used within 268 networks which are well-managed by a service provider and MUST NOT be 269 used within the Internet. In the well-managed network, traffic is 270 well-managed to avoid congestion and fragmentation on encapsulated 271 packets (i.e., I-IP packets) are not needed. 273 7. Acknowledgements 275 Thanks to Vivek Kumar, Carlos Pignataro and Mark Townsley for their 276 valuable comments on the initial idea of this document. Thanks to 277 Andrew G. Malis, Joe Touch and Brian E Carpenter for their valuable 278 comments on this document. 280 8. IANA Considerations 282 One UDP destination port number indicating IP needs to be allocated 283 by IANA: 285 Service Name: IP-in-UDP Transport Protocol(s):UDP 286 Assignee: IESG 287 Contact: IETF Chair . 288 Description: Encapsulate IP packets in UDP tunnels. 289 Reference: This document. 290 Port Number: TBD1 -- To be assigned by IANA. 292 One UDP destination port number indicating IP with DTLS needs to be 293 allocated by IANA: 295 Service Name: IP-in-UDP-with-DTLS 296 Transport Protocol(s): UDP 297 Assignee: IESG 298 Contact: IETF Chair . 299 Description: Encapsulate IP packets in UDP tunnels with DTLS. 300 Reference: This document. 301 Port Number: TBD2 -- To be assigned by IANA. 303 9. Security Considerations 305 The security problems faced with the IP-in-UDP tunnel are exactly the 306 same as those faced with IP-in-IP [RFC2003] and IP-in-GRE tunnels 307 [RFC2784]. In other words, the IP-in-UDP tunnel as defined in this 308 document by itself cannot ensure the integrity and privacy of data 309 packets being transported through the IP-in-UDP tunnel and cannot 310 enable the tunnel decapsulator to authenticate the tunnel 311 encapsulator. In the case where any of the above security issues is 312 concerned, the IP-in-UDP tunnel SHOULD be secured with IPsec or DTLS. 313 IPsec was designed as a network security mechanism and therefore it 314 resides at the network layer. As such, if the tunnel is secured with 315 IPsec, the UDP header would not be visible to intermediate routers 316 anymore in either IPsec tunnel or transport mode. As a result, the 317 meaning of adopting the IP-in-UDP tunnel as an alternative to the IP- 318 in-GRE or IP-in-IP tunnel is lost. By comparison, DTLS is better 319 suited for application security and can better preserve network and 320 transport layer protocol information. Specifically, if DTLS is used, 321 the destination port of the UDP header will be filled with a value 322 (TBD2) indicating IP with DTLS and the source port can still be used 323 as an entropy field for load-sharing purposes. 325 If the tunnel is not secured with IPsec or DTLS, some other method 326 should be used to ensure that packets are decapsulated and forwarded 327 by the tunnel tail only if those packets were encapsulated by the 328 tunnel head. If the tunnel lies entirely within a single 329 administrative domain, address filtering at the boundaries can be 330 used to ensure that no packet with the IP source address of a tunnel 331 endpoint or with the IP destination address of a tunnel endpoint can 332 enter the domain from outside. However, when the tunnel head and the 333 tunnel tail are not in the same administrative domain, this may 334 become difficult, and filtering based on the destination address can 335 even become impossible if the packets must traverse the public 336 Internet. Sometimes only source address filtering (but not 337 destination address filtering) is done at the boundaries of an 338 administrative domain. If this is the case, the filtering does not 339 provide effective protection at all unless the decapsulator of an IP- 340 in-UDP validates the IP source address of the packet. 342 10. References 344 10.1. Normative References 346 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 347 DOI 10.17487/RFC0768, August 1980, 348 . 350 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 351 DOI 10.17487/RFC1191, November 1990, 352 . 354 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 355 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 356 1996, . 358 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 359 DOI 10.17487/RFC2003, October 1996, 360 . 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, 364 DOI 10.17487/RFC2119, March 1997, 365 . 367 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 368 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 369 December 1998, . 371 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 372 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 373 DOI 10.17487/RFC2784, March 2000, 374 . 376 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 377 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 378 December 2005, . 380 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 381 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 382 . 384 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 385 for Application Designers", RFC 5405, 386 DOI 10.17487/RFC5405, November 2008, 387 . 389 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 390 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 391 January 2012, . 393 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 394 UDP Checksums for Tunneled Packets", RFC 6935, 395 DOI 10.17487/RFC6935, April 2013, 396 . 398 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 399 for the Use of IPv6 UDP Datagrams with Zero Checksums", 400 RFC 6936, DOI 10.17487/RFC6936, April 2013, 401 . 403 10.2. Informative References 405 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 406 "Definition of the Differentiated Services Field (DS 407 Field) in the IPv4 and IPv6 Headers", RFC 2474, 408 DOI 10.17487/RFC2474, December 1998, 409 . 411 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 412 RFC 2914, DOI 10.17487/RFC2914, September 2000, 413 . 415 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 416 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 417 RFC 3931, DOI 10.17487/RFC3931, March 2005, 418 . 420 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 421 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 422 . 424 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 425 Balancing for Mesh Softwires", RFC 5640, 426 DOI 10.17487/RFC5640, August 2009, 427 . 429 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 430 for Equal Cost Multipath Routing and Link Aggregation in 431 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 432 . 434 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 435 Locator/ID Separation Protocol (LISP)", RFC 6830, 436 DOI 10.17487/RFC6830, January 2013, 437 . 439 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 440 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 441 eXtensible Local Area Network (VXLAN): A Framework for 442 Overlaying Virtualized Layer 2 Networks over Layer 3 443 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 444 . 446 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 447 "Encapsulating MPLS in UDP", RFC 7510, 448 DOI 10.17487/RFC7510, April 2015, 449 . 451 Authors' Addresses 453 Xiaohu Xu 454 Alibaba Inc 456 Email: xiaohu.xxh@alibaba-inc.com 458 Hamid Assarpour 459 Broadcom 461 Email: hamid.assarpour@broadcom.com 462 Shaowen Ma 463 Mellanox 465 Email: mashaowen@gmail.com 467 Daniel Bernier 468 Canada Bell 470 Email: daniel.bernier@bell.ca 472 Darren Dukes 473 Cisco 475 Email: ddukes@cisco.com 477 Shraddha Hegde 478 Juniper 480 Email: shraddha@juniper.net 482 Yiu Lee 483 Comcast 485 Email: Yiu_Lee@Cable.Comcast.com 487 Yongbing Fan 488 China Telecom 490 Email: fanyb@gsta.com