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