Generic UDP Encapsulation for IP Tunneling
Author(s): KuiKe Building, Lucy Yong
This document describes a method for encapsulating the layer protocols within UDP at an IP network edge such that the payload protocol can be identified from the destination port value. The mechanism also allows for the source port...
Network Working Group L. Yong Internet Draft X. Xu Category: Standard Track Huawei Expires: August 2013 February 25, 2013 Generic UDP Encapsulation for IP Tunneling draft-yong-tsvwg-udp-encap-4-ip-tunneling-01 Status of this document This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 25, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Yong & Xu Expires August 25, 2013 [Page 1] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 Abstract This document describes a method for encapsulating the layer protocols within UDP at an IP network edge such that the payload protocol can be identified from the destination port value. The mechanism also allows for the source port to be used as the entropy field for the purpose of load balancing in environments such as Equal Cost Multipath (ECMP) in the underlying IP network. Application of this technique is focused on tunneling payload network flows across IP networks in environments where load- balancing is required. No changes to the underlying IP network or the payload networks are required. Table of Contents 1. Introduction...................................................3 1.1. Conventions used in this document.........................4 1.2. Terminology...............................................4 2. UDP Encapsulation..............................................5 3. Procedures.....................................................5 4. Encapsulation Considerations...................................6 5. Backward Compatibility.........................................7 6. IP Tunneling Applications......................................7 7. Security Considerations........................................8 8. IANA Considerations............................................8 9. Contributors..................................................11 10. Acknowledgements.............................................12 11. References...................................................12 11.1. Normative References....................................12 11.2. Informative References..................................13 Yong & Xu, et al Expires August 25, 2013 [Page 2] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 1. Introduction Load balancing is an attempt to balance traffic across a network by allowing the traffic to use multiple paths. The benefits of load balancing are: it eases capacity planning; it can help absorb traffic surges by spreading them across multiple paths; and it allows better resilience by offering alternate paths in the event of a link or node failure. Load balancing of traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) in IP networks is widely used. Most existing routers in IP networks are already capable of distributing IP traffic flows over ECMP paths and/or LAG on the basis of a hash function performed on the key fields of IP packet headers and their payload protocol headers. Specifically, when the IP payload is a User Datagram Protocol (UDP)[RFC 0768] or Transmission Control Protocol (TCP) packet, the hash operates on the five-tuple of the source IP address, the destination IP address, the source port, the destination port, and the next protocol identifier. IP Tunneling is a technique for allowing a tunneled packet (IP or non-IP) to transit an IP network by encapsulating it within an IP header when it enters the IP network and decapsulating it when it leaves the IP network. Several IP tunneling techniques exist for an IP network to support an IP tunneling application. IP-in-IP [RFC5565] carries IP encapsulated directly in another IP header. Generic Routing Encapsulation (GRE) [RFC2784] provides an encapsulation header to allow any protocol to be carried in an IP tunnel. [RFC4023] describes how to carry MPLS packets in IP or GRE headers. Version 3 of the Layer Two Tunneling Protocol (L2TPv3) [RFC3931] defines a control protocol and encapsulation for carrying multiple layer 2 connections between two IP nodes. In order to leverage the benefits of multipath environments, it is necessary to ensure that traffic flows are not distributed across multiple paths. When a single IP flow may carry a number of payload traffic flows, this requires that the payload flows can be identified in a way that the hash function will make the right decisions. An example of the way this works can be seen in [RFC6790] that introduced the MPLS Entropy Label, which allows information about the traffic flow with which a given packet is associated to be encoded within a special label within the MPLS label stack and form part of the hash that an MPLS transit node uses when distributing flows over multiple paths. Yong & Xu, et al Expires August 25, 2013 [Page 3] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 IP in IP is able to encode the payload type, but cannot easily carry the information necessary to achieve load balancing. GRE is able to encode the payload type and carry load balancing information; however, special processing at transit routers is required to understand the load balancing information because the GRE header does not form part of the standard hash function. L2TPv3 has the same capabilities and problems as GRE. Thus, none of the existing mechanisms for tunneling the layer protocols supported at network edge across an IP network provides a way to make good use of multipath environments. This document defines a generic UDP-based encapsulation for tunneling the layer protocols across IP networks. The encapsulation encodes the payload type in the UDP destination port and uses the UDP source port to provide load balancing information in a way that mirrors the entropy label of [RFC6790]. This encapsulation requires no changes to the transit IP network nor to the networks whose traffic is transiting the IP network. In particular, hash functions in existing IP routers will automatically utilize and benefit from this procedure without needing any change or upgrade. The encapsulation mechanism is applicable to a variety of IP networks including Data Centers and Wide Area infrastructure networks. Note that [RFC5405] provides unicast UDP usage guidelines for application designers. The application in that context is about the unicast application above IP network layer and the design considerations are for the upper layer application when it uses the UDP as transport protocol. This document proposes the use of the UDP header to encode the packet type and load balancing information for the IP network in environments of ECMP. In other words, the UDP usage here is not to facilitate the transport of upper layer application data. Therefore RFC5405 design considerations do not apply to the case described in this document. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. 1.2. Terminology The terms defined in [RFC 0768] are used in this document. Yong & Xu, et al Expires August 25, 2013 [Page 4] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 2. UDP Encapsulation The UDP datagram format is described in [RFC 0768]. The encapsulation described in this document specifies that: . The destination port of the UDP datagram is set to indicate the payload protocol according to the values assigned by IANA as described in Section 8; . The source port may be set to any value by the sender. Varying the value of the source port according to the payload flow will enable load balancing within the IP network. . Other UDP datagram header fields are to be used as described in [RFC 0768]. . To simplify the operation at the tunnel egress, it is RECOMMENDED that the UDP checksum field is set to zero. The encapsulation can apply to both IPv4 [RFC 0791] and IPv6 [RFC2460] tunnel. For further considerations related to relaxation of the mandatory requirement for the use of a UDP checksum in an IPv6 network, please refer to [CKZERO] and [CKSUM]. 3. Procedures When a tunnel ingress conforming to this document receives a packet, the ingress MUST encapsulate the packet into a UDP packet as described in Section 2. The ingress MUST insert the payload type in the destination port field. The ingress MAY generate load balancing information and put it in the source port field, otherwise it SHOULD be set to zero. How a tunnel ingress generates the load balancing information from the payload is outside the scope of this document. The tunnel ingress MUST encode its IP address as the source IP address and the egress tunnel endpoint IP address or a group IP address as destination IP address. The TTL field in the IP header MUST be set to a value appropriate for delivery of the encapsulated packet to the tunnel egress endpoint. Transit routers, upon receiving these UDP encapsulated packets, may load-balance these packets based on the hash of the five-tuple of the packet header. Note that this method requires no change on transit routers. When the tunnel egress receives a packet, it removes the UDP header and sends the payload to the entity that will process the payload Yong & Xu, et al Expires August 25, 2013 [Page 5] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 type indicated in the UDP destination port. Section 5 describes the error handling when this entity is not instantiated at the tunnel egress. When a packet is received with a UDP checksum of zero, it MUST be accepted for decapsulation. Although IPv6 [RFC2460] restricts the processing a packet with the UDP checksum of zero, [CKSUM] and [CKZERO] relax this constraint to allow the zero UDP checksum. Note that 1) the IPv6 tunnel ingress and egress SHOULD follow the node requirements specified in Section 4 of [CKZERO] and the usage requirements specified in Section 5 of [CKZERO]; 2) IPv6 transit nodes SHOULD follow the requirements 9, 10, 11 specified in Section 5 of [CKZERO]. Note that the UDP encapsulation specified in this document does not provide a flow control capability; it is the responsibility of tunneled network protocol to support any necessary flow control function. 4. Encapsulation Considerations This UDP encapsulation allows the tunneled traffic to be unicast, broadcast, or multicast traffic. The load balancing information may be generated from the header of tunneled unicast or broadcast/multicast packets at a tunnel ingress. The mapping mechanism between the tunneled multicast traffic and the multicast capability in the IP network is transparent and independent to the encapsulation and is outside the scope of this document. UDP encapsulation introduces eight octets overhead, which reduces the effective Maximum Transmission Unit (MTU) size. If a tunnel ingress has to perform fragmentation on a packet before encapsulation, it MUST use the same source UDP port for all packet fragments. This ensures that the transit routers will forward the packet fragments on the same path. An operator should factor in this addition eight octets when considering an MTU size for the payload to reduce the likelihood of fragmentation. To ensure the tunneled traffic gets the same treatment over the IP network, prior to the encapsulation process, a tunnel ingress needs process the payload to get the proper parameters to fill into the IP header such as DiffServ [RFC2983]. Both tunnel ingress and egress SHOULD follow the procedures described in RFC6040 [RFC6040] for ECN Yong & Xu, et al Expires August 25, 2013 [Page 6] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 marking propagation. This process is outside of the scope of this document. Note that IPv6 header [RFC2460] has a flow label field that may be used for load balancing information in the IPv6 network [RFC6438]. The next header in IPv6 can be used to provide the payload type. However, applying the UDP encapsulation to both IPv4 and IPv6 networks provides a unified hardware implementation for load balancing in an IP network. 5. Backward Compatibility It is assumed that tunnel ingress routers are upgraded in order to support the function described in this document. No change is required at transit routers to support the process described in this document. If a legacy router that is an intended tunnel egress does not support the UDP encapsulation described in this document, it will not be listening on the destination port. The same will apply if the egress supports the process but not the payload protocol. In these cases, the router will conform to normal UDP processing and respond to the tunnel ingress with an ICMP message indicating "port unreachable" according to [RFC 0792] and [RFC4884]. Upon receiving this ICMP message, the tunnel ingress MUST NOT continue to use the UDP encapsulation toward this tunnel egress without management intervention. 6. IP Tunneling Applications IP tunneling applications such as IP in IP [RFC5565], MPLS Client Layer [EVPN] and L3VPN [RFC4364], GRE [RFC2784], VXLAN [VXLAN], NVGRE [NVGRE], LISP [RFC6830] may be deployed in an IP network. These applications can use the UDP encapsulation described in this document. In fact, VXLAN and LISP are specified to use the UDP header and have exactly the same semantics as specified in this document. The UDP encapsulation uses the destination port to encode the payload type. For data plane interworking, each application MUST have one port number assigned by IANA. An application MAY request more than one port number [MPLS-IN-UDP]. Each application MUST further specify its header format and semantics if not yet. For a Yong & Xu, et al Expires August 25, 2013 [Page 7] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 network layer virtualization application, its header needs to have a field to sufficiently identify a virtual network. The header format of such application is outside the scope of this document. Some tunneling applications may use of a signal protocol to exchange information between two tunnel end points at the application layer. Such signal protocol can be used for egress to inform its capability in supporting the UDP encapsulation as well. Again, this is outside the scope of this document. 7. Security Considerations UDP encapsulation does not provide any additional security for a tunneled layer protocol. In other words, the security concern has no change regarding the use of UDP encapsulation or not. An IP tunneling application either relies on the underlying IP network to provide the security or implement a secured overlay tunnel such as L2TPv3 [RFC3931] to over a non-secured IP network such as Internet. 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. 8. IANA Considerations This document requests IANA to reserve a block of port numbers from the range designated as User Ports for the payload types that the IP tunnel may carry. IANA is requested to manage that block as a sub- registry of the port numbers registry. Note that the use of a contiguous block of port numbers is not an absolute requirement, however it is believed that the use of such a block will considerably aid implementation. Allocation procedures for port numbers are governed by [RFC6335]. This document does not seek to change those procedures. Instead, it requests that a contiguous block of port numbers be assigned as below, and that a further contiguous block be considered reserved for allocation for similar purposes. IANA is requested to make the following allocations: Yong & Xu, et al Expires August 25, 2013 [Page 8] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 Service Name : IPv4-UDP-ECMP Transport Protocol(s) : UDP Assignee : IESG <email@example.com> Contact : IETF Chair <firstname.lastname@example.org> Description : IPv4 encapsulation in UDP for load balancing. Reference : [This.I-D] Port Number : TBD Service Code : N/A Known Unauthorized Uses : N/A Assignment Notes : N/A Service Name : IPv6-UDP-ECMP Transport Protocol(s) : UDP Assignee : IESG <email@example.com> Contact : IETF Chair <firstname.lastname@example.org> Description : IPv6 encapsulation in UDP for load balancing. Reference : [This.I-D] Port Number : TBD + 1 Service Code : N/A Known Unauthorized Uses : N/A Assignment Notes : N/A Service Name : MPLS-up-UDP-ECMP Transport Protocol(s) : UDP Assignee : IESG <email@example.com> Contact : IETF Chair <firstname.lastname@example.org> Description : MPLS upstream assigned label encapsulation in UDP for load balancing. Reference : [This.I-D] Port Number : TBD + 2 Service Code : N/A Known Unauthorized Uses : N/A Assignment Notes : N/A Service Name : MPLS-dn-UDP-ECMP Transport Protocol(s) : UDP Assignee : IESG <email@example.com> Contact : IETF Chair <firstname.lastname@example.org> Description : MPLS downstream assigned label encapsulation in UDP for load balancing. Reference : [This.I-D] Port Number : TBD + 3 Yong & Xu, et al Expires August 25, 2013 [Page 9] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 Service Code : N/A Known Unauthorized Uses : N/A Assignment Notes : N/A Service Name : VXLAN-UDP-ECMP Transport Protocol(s) : UDP Assignee : IESG <email@example.com> Contact : IETF Chair <firstname.lastname@example.org> Description : VXLAN encapsulation in UDP for load balancing. Reference : [This.I-D] Port Number : TBD + 4 Service Code : N/A Known Unauthorized Uses : N/A Assignment Notes : N/A Service Name : NVGRE-UDP-ECMP Transport Protocol(s) : UDP Assignee : IESG <email@example.com> Contact : IETF Chair <firstname.lastname@example.org> Description : NVGRE encapsulation in UDP for load balancing. Reference : [This.I-D] Port Number : TBD + 5 Service Code : N/A Known Unauthorized Uses : N/A Assignment Notes : N/A Service Name : GRE-UDP-ECMP Transport Protocol(s) : UDP Assignee : IESG <email@example.com> Contact : IETF Chair <firstname.lastname@example.org> Description : GRE encapsulation in UDP for load balancing. Reference : [This.I-D] Port Number : TBD + 6 Service Code : N/A Known Unauthorized Uses : N/A Assignment Notes : N/A IANA is requested to reserve a further nine (9) adjacent port numbers for similar uses. Any future allocation from that reserved block must follow the procedures defined in [RFC6335] and should: Yong & Xu, et al Expires August 25, 2013 [Page 10] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 - Be for the purpose of tunneling a layer protocol across a multipath-enabled IP network. - Be the result of a Standards Track RFC - Use the service name naming convention of <foo>-UDP-ECMP where <foo> is an identifier of the tunneled protocol. 9. Contributors Edward Crabbe Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 Email: email@example.com John E. Drake Juniper Networks Email: firstname.lastname@example.org Adrian Farrel Juniper Networks Email: email@example.com Vishwas Manral Hewlett-Packard Corp. 3000 Hanover St, Palo Alto. Email: firstname.lastname@example.org Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA EMail: email@example.com Yongbing Fan China Telecom Guangzhou, China. Phone: +86 20 38639121 Yong & Xu, et al Expires August 25, 2013 [Page 11] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 Email: firstname.lastname@example.org Yiu Lee Comcast One Comcast Center Philadelphia, PA 1903 USA Email: Yiu_Lee@Cable.Comcast.com 10. Acknowledgements Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger Geib, and Gorry Fairhurst for their review and valuable input on this draft. 11. References 11.1. Normative References [RFC 0768] Postel, J., "User Datagram Protocol", STD 6, RFC 0768, August 1980. [RFC 0791] DARPA, "Internet Protocol", RFC 0791, September 1981 [RFC 0792] Postel, J., "Internet Control Message Protocol", RFC 0792, September, 1981. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S., and Hinden, R., "Internet Protocol, Version 6 (IPv6)", RFC2460, December 1998 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC2784, March 2000. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC3931, March 2005. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. Yong & Xu, et al Expires August 25, 2013 [Page 12] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 [RFC4364] Rosen, E and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC4364, February 2006. [RFC4884] Conta, A, et al., "Internet Control Message Protocol (ICMP) for the Internet Protocol Version 6 (IPv6) Specification", RFC4884, March, 2006 [RFC5405] Eggert, L., "Unicast UDP Usage Guideline for Application Designers", RFC5405, November 2008. [RFC5565] Wu, J., "Softwire Mesh Framework", RFC5565, June 2009. [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion Notification", RFC6040, November 2010 [RFC6335] Cotton, M., etc, "Internet Assigned Numbers Authority IIANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", RFC6335, August 2011 [RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Linda Aggregation in tunnels", RFC6438, November, 2011 [RFC6790] Kompella, K., et al. "The use of Entropy Label in MPLS forwarding", RFC6790, November 2012 11.2. Informative References [CKSUM] Eubanks, M., et al., "IPv6 and UDP Checcksums for Tunneled Packetets", draft-ietf-6man-udpchecksums, work in progress. [CKZERO] G. Fairhurst, G. and Westerlund, M., "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums", draft-ietf-6man-udpzero, work in progress. [EVPN] Sajassi, A., et al., "BGP MPLS based Ethernet VPN", draft- ietf-l2vpn-evpn, work in progress. [MPLS-IN-UDP] Xu, X., et al., "Encapsulating MPLS in UDP", draft- ietf-mpls-in-udp, work in progress. [NVGRE] Sridharan, M., "NVGRE: Network Virtualization using Generic Routing Encapsulation", draft-sridharan-virtualization- nvgre, work in progress. Yong & Xu, et al Expires August 25, 2013 [Page 13] Internet-Draft UDP Encapsulation for IP Tunneling February 2013 [RFC2983] Black, D. "Diffserv and tunnels", RFC2983, October 2000 [RFC6830] Farinacci, D., "Locator/ID Separation Protocol", RFC6830, January 2013. [VXLAN] Mahalingam, M., Dutt, D., et al., "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan, work in progress. Authors' Addresses Lucy Yong Huawei USA 5340 Legacy Drive Plano, TX 75025 U.S.A Phone: 469-277-5837 Email: email@example.com Xiaohu Xu Huawei Technologies, Beijing, China Phone: +86-10-60610041 Email: firstname.lastname@example.org Yong & Xu, et al Expires August 25, 2013 [Page 14]