idnits 2.17.1 draft-yong-tsvwg-udp-encap-4-ip-tunneling-01.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Note that the UDP header usage described in this document is for the underlying IP network. A firewall in an underlying network SHOULD not inspect the packets and take an action because of the UDP header presence for this purpose. -- The document date (February 25, 2013) is 4068 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 informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Yong 2 Internet Draft X. Xu 3 Category: Standard Track Huawei 5 Expires: August 2013 February 25, 2013 7 Generic UDP Encapsulation for IP Tunneling 8 draft-yong-tsvwg-udp-encap-4-ip-tunneling-01 10 Status of this document 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 25, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. 45 Abstract 47 This document describes a method for encapsulating the layer 48 protocols within UDP at an IP network edge such that the payload 49 protocol can be identified from the destination port value. The 50 mechanism also allows for the source port to be used as the entropy 51 field for the purpose of load balancing in environments such as 52 Equal Cost Multipath (ECMP) in the underlying IP network. 54 Application of this technique is focused on tunneling payload 55 network flows across IP networks in environments where load- 56 balancing is required. No changes to the underlying IP network or 57 the payload networks are required. 59 Table of Contents 61 1. Introduction...................................................3 62 1.1. Conventions used in this document.........................4 63 1.2. Terminology...............................................4 64 2. UDP Encapsulation..............................................5 65 3. Procedures.....................................................5 66 4. Encapsulation Considerations...................................6 67 5. Backward Compatibility.........................................7 68 6. IP Tunneling Applications......................................7 69 7. Security Considerations........................................8 70 8. IANA Considerations............................................8 71 9. Contributors..................................................11 72 10. Acknowledgements.............................................12 73 11. References...................................................12 74 11.1. Normative References....................................12 75 11.2. Informative References..................................13 77 1. Introduction 79 Load balancing is an attempt to balance traffic across a network by 80 allowing the traffic to use multiple paths. The benefits of load 81 balancing are: it eases capacity planning; it can help absorb 82 traffic surges by spreading them across multiple paths; and it 83 allows better resilience by offering alternate paths in the event of 84 a link or node failure. 86 Load balancing of traffic over Equal Cost Multi-Path (ECMP) and/or 87 Link Aggregation Group (LAG) in IP networks is widely used. Most 88 existing routers in IP networks are already capable of distributing 89 IP traffic flows over ECMP paths and/or LAG on the basis of a hash 90 function performed on the key fields of IP packet headers and their 91 payload protocol headers. Specifically, when the IP payload is a 92 User Datagram Protocol (UDP)[RFC768] or Transmission Control 93 Protocol (TCP) packet, the hash operates on the five-tuple of the 94 source IP address, the destination IP address, the source port, the 95 destination port, and the next protocol identifier. 97 IP Tunneling is a technique for allowing a tunneled packet (IP or 98 non-IP) to transit an IP network by encapsulating it within an IP 99 header when it enters the IP network and decapsulating it when it 100 leaves the IP network. Several IP tunneling techniques exist for an 101 IP network to support an IP tunneling application. IP-in-IP [RFC5565] 102 carries IP encapsulated directly in another IP header. Generic 103 Routing Encapsulation (GRE) [RFC2784] provides an encapsulation 104 header to allow any protocol to be carried in an IP tunnel. [RFC4023] 105 describes how to carry MPLS packets in IP or GRE headers. Version 3 106 of the Layer Two Tunneling Protocol (L2TPv3) [RFC3931] defines a 107 control protocol and encapsulation for carrying multiple layer 2 108 connections between two IP nodes. 110 In order to leverage the benefits of multipath environments, it is 111 necessary to ensure that traffic flows are not distributed across 112 multiple paths. When a single IP flow may carry a number of payload 113 traffic flows, this requires that the payload flows can be 114 identified in a way that the hash function will make the right 115 decisions. An example of the way this works can be seen in [RFC6790] 116 that introduced the MPLS Entropy Label, which allows information 117 about the traffic flow with which a given packet is associated to be 118 encoded within a special label within the MPLS label stack and form 119 part of the hash that an MPLS transit node uses when distributing 120 flows over multiple paths. 122 IP in IP is able to encode the payload type, but cannot easily carry 123 the information necessary to achieve load balancing. GRE is able to 124 encode the payload type and carry load balancing information; 125 however, special processing at transit routers is required to 126 understand the load balancing information because the GRE header 127 does not form part of the standard hash function. L2TPv3 has the 128 same capabilities and problems as GRE. Thus, none of the existing 129 mechanisms for tunneling the layer protocols supported at network 130 edge across an IP network provides a way to make good use of 131 multipath environments. 133 This document defines a generic UDP-based encapsulation for 134 tunneling the layer protocols across IP networks. The encapsulation 135 encodes the payload type in the UDP destination port and uses the 136 UDP source port to provide load balancing information in a way that 137 mirrors the entropy label of [RFC6790]. This encapsulation requires 138 no changes to the transit IP network nor to the networks whose 139 traffic is transiting the IP network. In particular, hash functions 140 in existing IP routers will automatically utilize and benefit from 141 this procedure without needing any change or upgrade. The 142 encapsulation mechanism is applicable to a variety of IP networks 143 including Data Centers and Wide Area infrastructure networks. 145 Note that [RFC5405] provides unicast UDP usage guidelines for 146 application designers. The application in that context is about the 147 unicast application above IP network layer and the design 148 considerations are for the upper layer application when it uses the 149 UDP as transport protocol. This document proposes the use of the UDP 150 header to encode the packet type and load balancing information for 151 the IP network in environments of ECMP. In other words, the UDP 152 usage here is not to facilitate the transport of upper layer 153 application data. Therefore RFC5405 design considerations do not 154 apply to the case described in this document. 156 1.1. Conventions used in this document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC-2119 [RFC2119]. 162 1.2. Terminology 164 The terms defined in [RFC768] are used in this document. 166 2. UDP Encapsulation 168 The UDP datagram format is described in [RFC768]. The encapsulation 169 described in this document specifies that: 171 . The destination port of the UDP datagram is set to indicate the 172 payload protocol according to the values assigned by IANA as 173 described in Section 8; 175 . The source port may be set to any value by the sender. Varying 176 the value of the source port according to the payload flow will 177 enable load balancing within the IP network. 179 . Other UDP datagram header fields are to be used as described in 180 [RFC768]. 182 . To simplify the operation at the tunnel egress, it is RECOMMENDED 183 that the UDP checksum field is set to zero. The encapsulation can 184 apply to both IPv4 [RFC791] and IPv6 [RFC2460] tunnel. For further 185 considerations related to relaxation of the mandatory requirement 186 for the use of a UDP checksum in an IPv6 network, please refer to 187 [CKZERO] and [CKSUM]. 189 3. Procedures 191 When a tunnel ingress conforming to this document receives a packet, 192 the ingress MUST encapsulate the packet into a UDP packet as 193 described in Section 2. The ingress MUST insert the payload type in 194 the destination port field. The ingress MAY generate load balancing 195 information and put it in the source port field, otherwise it SHOULD 196 be set to zero. How a tunnel ingress generates the load balancing 197 information from the payload is outside the scope of this document. 198 The tunnel ingress MUST encode its IP address as the source IP 199 address and the egress tunnel endpoint IP address or a group IP 200 address as destination IP address. The TTL field in the IP header 201 MUST be set to a value appropriate for delivery of the encapsulated 202 packet to the tunnel egress endpoint. 204 Transit routers, upon receiving these UDP encapsulated packets, may 205 load-balance these packets based on the hash of the five-tuple of 206 the packet header. Note that this method requires no change on 207 transit routers. 209 When the tunnel egress receives a packet, it removes the UDP header 210 and sends the payload to the entity that will process the payload 211 type indicated in the UDP destination port. Section 5 describes the 212 error handling when this entity is not instantiated at the tunnel 213 egress. When a packet is received with a UDP checksum of zero, it 214 MUST be accepted for decapsulation. Although IPv6 [RFC2460] 215 restricts the processing a packet with the UDP checksum of zero, 216 [CKSUM] and [CKZERO] relax this constraint to allow the zero UDP 217 checksum. Note that 1) the IPv6 tunnel ingress and egress SHOULD 218 follow the node requirements specified in Section 4 of [CKZERO] and 219 the usage requirements specified in Section 5 of [CKZERO]; 2) IPv6 220 transit nodes SHOULD follow the requirements 9, 10, 11 specified in 221 Section 5 of [CKZERO]. 223 Note that the UDP encapsulation specified in this document does not 224 provide a flow control capability; it is the responsibility of 225 tunneled network protocol to support any necessary flow control 226 function. 228 4. Encapsulation Considerations 230 This UDP encapsulation allows the tunneled traffic to be unicast, 231 broadcast, or multicast traffic. The load balancing information may 232 be generated from the header of tunneled unicast or 233 broadcast/multicast packets at a tunnel ingress. The mapping 234 mechanism between the tunneled multicast traffic and the multicast 235 capability in the IP network is transparent and independent to the 236 encapsulation and is outside the scope of this document. 238 UDP encapsulation introduces eight octets overhead, which reduces 239 the effective Maximum Transmission Unit (MTU) size. If a tunnel 240 ingress has to perform fragmentation on a packet before 241 encapsulation, it MUST use the same source UDP port for all packet 242 fragments. This ensures that the transit routers will forward the 243 packet fragments on the same path. An operator should factor in this 244 addition eight octets when considering an MTU size for the payload 245 to reduce the likelihood of fragmentation. 247 To ensure the tunneled traffic gets the same treatment over the IP 248 network, prior to the encapsulation process, a tunnel ingress needs 249 process the payload to get the proper parameters to fill into the IP 250 header such as DiffServ [RFC2983]. Both tunnel ingress and egress 251 SHOULD follow the procedures described in RFC6040 [RFC6040] for ECN 252 marking propagation. This process is outside of the scope of this 253 document. 255 Note that IPv6 header [RFC2460] has a flow label field that may be 256 used for load balancing information in the IPv6 network [RFC6438]. 257 The next header in IPv6 can be used to provide the payload type. 258 However, applying the UDP encapsulation to both IPv4 and IPv6 259 networks provides a unified hardware implementation for load 260 balancing in an IP network. 262 5. Backward Compatibility 264 It is assumed that tunnel ingress routers are upgraded in order to 265 support the function described in this document. 267 No change is required at transit routers to support the process 268 described in this document. 270 If a legacy router that is an intended tunnel egress does not 271 support the UDP encapsulation described in this document, it will 272 not be listening on the destination port. The same will apply if the 273 egress supports the process but not the payload protocol. In these 274 cases, the router will conform to normal UDP processing and respond 275 to the tunnel ingress with an ICMP message indicating "port 276 unreachable" according to [RFC792] and [RFC4884]. Upon receiving 277 this ICMP message, the tunnel ingress MUST NOT continue to use the 278 UDP encapsulation toward this tunnel egress without management 279 intervention. 281 6. IP Tunneling Applications 283 IP tunneling applications such as IP in IP [RFC5565], MPLS Client 284 Layer [EVPN] and L3VPN [RFC4364], GRE [RFC2784], VXLAN [VXLAN], 285 NVGRE [NVGRE], LISP [RFC6830] may be deployed in an IP network. 286 These applications can use the UDP encapsulation described in this 287 document. In fact, VXLAN and LISP are specified to use the UDP 288 header and have exactly the same semantics as specified in this 289 document. 291 The UDP encapsulation uses the destination port to encode the 292 payload type. For data plane interworking, each application MUST 293 have one port number assigned by IANA. An application MAY request 294 more than one port number [MPLS-IN-UDP]. Each application MUST 295 further specify its header format and semantics if not yet. For a 296 network layer virtualization application, its header needs to have a 297 field to sufficiently identify a virtual network. The header format 298 of such application is outside the scope of this document. 300 Some tunneling applications may use of a signal protocol to exchange 301 information between two tunnel end points at the application layer. 302 Such signal protocol can be used for egress to inform its capability 303 in supporting the UDP encapsulation as well. Again, this is outside 304 the scope of this document. 306 7. Security Considerations 308 UDP encapsulation does not provide any additional security for a 309 tunneled layer protocol. In other words, the security concern has no 310 change regarding the use of UDP encapsulation or not. An IP 311 tunneling application either relies on the underlying IP network to 312 provide the security or implement a secured overlay tunnel such as 313 L2TPv3 [RFC3931] to over a non-secured IP network such as Internet. 315 Note that the UDP header usage described in this document is for the 316 underlying IP network. A firewall in an underlying network SHOULD 317 not inspect the packets and take an action because of the UDP header 318 presence for this purpose. 320 8. IANA Considerations 322 This document requests IANA to reserve a block of port numbers from 323 the range designated as User Ports for the payload types that the IP 324 tunnel may carry. IANA is requested to manage that block as a sub- 325 registry of the port numbers registry. 327 Note that the use of a contiguous block of port numbers is not an 328 absolute requirement, however it is believed that the use of such a 329 block will considerably aid implementation. 331 Allocation procedures for port numbers are governed by [RFC6335]. 332 This document does not seek to change those procedures. Instead, it 333 requests that a contiguous block of port numbers be assigned as 334 below, and that a further contiguous block be considered reserved 335 for allocation for similar purposes. 337 IANA is requested to make the following allocations: 339 Service Name : IPv4-UDP-ECMP 340 Transport Protocol(s) : UDP 341 Assignee : IESG 342 Contact : IETF Chair 343 Description : IPv4 encapsulation in UDP for load balancing. 344 Reference : [This.I-D] 345 Port Number : TBD 346 Service Code : N/A 347 Known Unauthorized Uses : N/A 348 Assignment Notes : N/A 350 Service Name : IPv6-UDP-ECMP 351 Transport Protocol(s) : UDP 352 Assignee : IESG 353 Contact : IETF Chair 354 Description : IPv6 encapsulation in UDP for load balancing. 355 Reference : [This.I-D] 356 Port Number : TBD + 1 357 Service Code : N/A 358 Known Unauthorized Uses : N/A 359 Assignment Notes : N/A 361 Service Name : MPLS-up-UDP-ECMP 362 Transport Protocol(s) : UDP 363 Assignee : IESG 364 Contact : IETF Chair 365 Description : MPLS upstream assigned label encapsulation in 366 UDP for load balancing. 367 Reference : [This.I-D] 368 Port Number : TBD + 2 369 Service Code : N/A 370 Known Unauthorized Uses : N/A 371 Assignment Notes : N/A 373 Service Name : MPLS-dn-UDP-ECMP 374 Transport Protocol(s) : UDP 375 Assignee : IESG 376 Contact : IETF Chair 377 Description : MPLS downstream assigned label encapsulation in 378 UDP for load balancing. 379 Reference : [This.I-D] 380 Port Number : TBD + 3 381 Service Code : N/A 382 Known Unauthorized Uses : N/A 383 Assignment Notes : N/A 385 Service Name : VXLAN-UDP-ECMP 386 Transport Protocol(s) : UDP 387 Assignee : IESG 388 Contact : IETF Chair 389 Description : VXLAN encapsulation in UDP for load balancing. 390 Reference : [This.I-D] 391 Port Number : TBD + 4 392 Service Code : N/A 393 Known Unauthorized Uses : N/A 394 Assignment Notes : N/A 396 Service Name : NVGRE-UDP-ECMP 397 Transport Protocol(s) : UDP 398 Assignee : IESG 399 Contact : IETF Chair 400 Description : NVGRE encapsulation in UDP for load balancing. 401 Reference : [This.I-D] 402 Port Number : TBD + 5 403 Service Code : N/A 404 Known Unauthorized Uses : N/A 405 Assignment Notes : N/A 407 Service Name : GRE-UDP-ECMP 408 Transport Protocol(s) : UDP 409 Assignee : IESG 410 Contact : IETF Chair 411 Description : GRE encapsulation in UDP for load balancing. 412 Reference : [This.I-D] 413 Port Number : TBD + 6 414 Service Code : N/A 415 Known Unauthorized Uses : N/A 416 Assignment Notes : N/A 418 IANA is requested to reserve a further nine (9) adjacent port 419 numbers for similar uses. Any future allocation from that reserved 420 block must follow the procedures defined in [RFC6335] and should: 422 - Be for the purpose of tunneling a layer protocol across a 423 multipath-enabled IP network. 424 - Be the result of a Standards Track RFC 425 - Use the service name naming convention of -UDP-ECMP where 426 is an identifier of the tunneled protocol. 428 9. Contributors 430 Edward Crabbe 431 Google, Inc. 432 1600 Amphitheatre Parkway 433 Mountain View, CA 94043 435 Email: edc@google.com 437 John E. Drake 438 Juniper Networks 440 Email: jdrake@juniper.net 442 Adrian Farrel 443 Juniper Networks 445 Email: adrian@olddog.co.uk 447 Vishwas Manral 448 Hewlett-Packard Corp. 449 3000 Hanover St, Palo Alto. 451 Email: vishwas.manral@hp.com 453 Carlos Pignataro 454 Cisco Systems 455 7200-12 Kit Creek Road 456 Research Triangle Park, NC 27709 457 USA 459 EMail: cpignata@cisco.com 461 Yongbing Fan 462 China Telecom 463 Guangzhou, China. 464 Phone: +86 20 38639121 465 Email: fanyb@gsta.com 467 Yiu Lee 468 Comcast 469 One Comcast Center 470 Philadelphia, PA 1903 471 USA 473 Email: Yiu_Lee@Cable.Comcast.com 475 10. Acknowledgements 477 Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger 478 Geib, and Gorry Fairhurst for their review and valuable input on 479 this draft. 481 11. References 483 11.1. Normative References 485 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 486 August 1980. 488 [RFC791] DARPA, "Internet Protocol", RFC791, September 1981 490 [RFC792] Postel, J., "Internet Control Message Protocol", RFC792, 491 September, 1981. 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC2119, March 1997. 496 [RFC2460] Deering, S., and Hinden, R., "Internet Protocol, Version 6 497 (IPv6)", RFC2460, December 1998 499 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 500 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 501 March 2000. 503 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 504 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 506 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 507 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 508 4023, March 2005. 510 [RFC4364] Rosen, E and Y. Rekhter, "BGP/MPLS IP Virtual Private 511 Networks (VPNs)", RFC4364, February 2006. 513 [RFC4884] Conta, A, et al., "Internet Control Message Protocol (ICMP) 514 for the Internet Protocol Version 6 (IPv6) Specification", 515 RFC4884, March, 2006 517 [RFC5405] Eggert, L., "Unicast UDP Usage Guideline for Application 518 Designers", RFC5405, November 2008. 520 [RFC5565] Wu, J., "Softwire Mesh Framework", RFC 5565, June 2009. 522 [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion 523 Notification", RFC6040, November 2010 525 [RFC6335] Cotton, M., etc, "Internet Assigned Numbers Authority 526 IIANA) Procedures for the Management of the Service Name 527 and Transport Protocol Port Number Registry", RFC6335, 528 August 2011 530 [RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for 531 Equal Cost Multipath Routing and Linda Aggregation in 532 tunnels", RFC6438, November, 2011 534 [RFC6790] Kompella, K., et al. "The use of Entropy Label in MPLS 535 forwarding", RFC6790, November 2012 537 11.2. Informative References 539 [CKSUM] Eubanks, M., et al., "IPv6 and UDP Checcksums for Tunneled 540 Packetets", draft-ietf-6man-udpchecksums, work in 541 progress. 543 [CKZERO] G. Fairhurst, G. and Westerlund, M., "Applicability 544 Statement for the use of IPv6 UDP Datagrams with Zero 545 Checksums", draft-ietf-6man-udpzero, work in progress. 547 [EVPN] Sajassi, A., et al., "BGP MPLS based Ethernet VPN", draft- 548 ietf-l2vpn-evpn, work in progress. 550 [MPLS-IN-UDP] Xu, X., et al., "Encapsulating MPLS in UDP", draft- 551 ietf-mpls-in-udp, work in progress. 553 [NVGRE] Sridharan, M., "NVGRE: Network Virtualization using Generic 554 Routing Encapsulation", draft-sridharan-virtualization- 555 nvgre, work in progress. 557 [RFC2983] Black, D. "Diffserv and tunnels", RFC2983, October 2000 559 [RFC6830] Farinacci, D., "Locator/ID Separation Protocol", RFC6830, 560 January 2013. 562 [VXLAN] Mahalingam, M., Dutt, D., et al., "VXLAN: A Framework for 563 Overlaying Virtualized Layer 2 Networks over Layer 3 564 Networks", draft-mahalingam-dutt-dcops-vxlan, work in 565 progress. 567 Authors' Addresses 569 Lucy Yong 570 Huawei USA 571 5340 Legacy Drive 572 Plano, TX 75025 573 U.S.A 575 Phone: 469-277-5837 576 Email: lucy.yong@huawei.com 578 Xiaohu Xu 579 Huawei Technologies, 580 Beijing, China 582 Phone: +86-10-60610041 583 Email: xuxiaohu@huawei.com