Generic UDP Encapsulation for IP Tunneling
draft-yong-tsvwg-udp-encap-4-ip-tunneling-00

Network Working Group                                          L. Yong
Internet Draft                                                   X. Xu
Category: Standard Track                                         Huawei

Expires: August 2013                                  February 12, 2013

                Generic UDP Encapsulation for IP Tunneling
               draft-yong-tsvwg-udp-encap-4-ip-tunneling-00

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 12, 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 12, 2013                 [Page 1]
Internet-Draft    UDP Encapsulation for Network Overlay   February 2013

Abstract

   This document describes a method for encapsulating network layer
   protocols within UDP 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 network
   protocol 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..................................................10
   10. Acknowledgements.............................................12
   11. References...................................................12
      11.1. Normative References....................................12
      11.2. Informative References..................................13

Yong & Xu, et al       Expires August 12, 2013                 [Page 2]
Internet-Draft    UDP Encapsulation for Network Overlay   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)[RFC768] 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 12, 2013                 [Page 3]
Internet-Draft    UDP Encapsulation for Network Overlay   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 a network layer protocol across an IP
   network provides a way to make good use of multipath environments.

   This document defines a generic UDP-based encapsulation for
   tunneling network 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 [RFC2119].

  1.2. Terminology

   The terms defined in [RFC768] are used in this document.

Yong & Xu, et al       Expires August 12, 2013                 [Page 4]
Internet-Draft    UDP Encapsulation for Network Overlay   February 2013

2. UDP Encapsulation

   The UDP datagram format is described in [RFC768]. 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
     [RFC768].

   .  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 [RFC791] 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 12, 2013                 [Page 5]
Internet-Draft    UDP Encapsulation for Network Overlay   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.

   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]. 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

Yong & Xu, et al       Expires August 12, 2013                 [Page 6]
Internet-Draft    UDP Encapsulation for Network Overlay   February 2013

   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 [RFC792] 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
   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

Yong & Xu, et al       Expires August 12, 2013                 [Page 7]
Internet-Draft    UDP Encapsulation for Network Overlay   February 2013

   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 network 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.

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:

         Service Name : IPv4-UDP-ECMP
         Transport Protocol(s) : UDP
         Assignee : IESG <iesg@ietf.org>
         Contact : IETF Chair <chair@ietf.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

Yong & Xu, et al       Expires August 12, 2013                 [Page 8]
Internet-Draft    UDP Encapsulation for Network Overlay   February 2013

         Service Name : IPv6-UDP-ECMP
         Transport Protocol(s) : UDP
         Assignee : IESG <iesg@ietf.org>
         Contact : IETF Chair <chair@ietf.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 <iesg@ietf.org>
         Contact : IETF Chair <chair@ietf.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 <iesg@ietf.org>
         Contact : IETF Chair <chair@ietf.org>
         Description : MPLS downstream assigned label encapsulation in
   UDP for load balancing.
         Reference : [This.I-D]
         Port Number : TBD + 3
         Service Code : N/A
         Known Unauthorized Uses : N/A
         Assignment Notes : N/A

         Service Name : VXLAN-UDP-ECMP
         Transport Protocol(s) : UDP
         Assignee : IESG <iesg@ietf.org>
         Contact : IETF Chair <chair@ietf.org>
         Description : VXLAN encapsulation in UDP for load balancing.
         Reference : [This.I-D]

Yong & Xu, et al       Expires August 12, 2013                 [Page 9]
Internet-Draft    UDP Encapsulation for Network Overlay   February 2013

         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 <iesg@ietf.org>
         Contact : IETF Chair <chair@ietf.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 <iesg@ietf.org>
         Contact : IETF Chair <chair@ietf.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:

   - Be for the purpose of tunneling a network 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

Yong & Xu, et al       Expires August 12, 2013                [Page 10]
Internet-Draft    UDP Encapsulation for Network Overlay   February 2013

   Email: edc@google.com

   John E. Drake
   Juniper Networks

   Email: jdrake@juniper.net

   Adrian Farrel
   Juniper Networks

   Email: adrian@olddog.co.uk

   Vishwas Manral
   Hewlett-Packard Corp.
   3000 Hanover St, Palo Alto.

   Email: vishwas.manral@hp.com

   Nischal Sheth
   Contrail Systems

   Email: nsheth@contrailsystems.com

   Carlos Pignataro
   Cisco Systems
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   USA

   EMail: cpignata@cisco.com

   Yongbing Fan
   China Telecom
   Guangzhou, China.
   Phone: +86 20 38639121

   Email: fanyb@gsta.com

   Yiu Lee
   Comcast
   One Comcast Center
   Philadelphia, PA 1903
   USA

Yong & Xu, et al       Expires August 12, 2013                [Page 11]
Internet-Draft    UDP Encapsulation for Network Overlay   February 2013

   Email: Yiu_Lee@Cable.Comcast.com

10. Acknowledgements

   Authors like to thank Vivek Kumar and Ron Bonica for their review
   and valuable input on this draft.

11. References

  11.1. Normative References

   [RFC768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
             August 1980.

   [RFC791]  DARPA, "Internet Protocol", RFC791, September 1981

   [RFC792]  Postel, J., "Internet Control Message Protocol", RFC792,
             September, 1981.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC2119, 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)", RFC 2784,
             March 2000.

   [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
             Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

   [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
             MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
             4023, March 2005.

   [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.

Yong & Xu, et al       Expires August 12, 2013                [Page 12]
Internet-Draft    UDP Encapsulation for Network Overlay   February 2013

   [RFC5565] Wu, J., "Softwire Mesh Framework", RFC 5565, June 2009.

   [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.

   [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

Yong & Xu, et al       Expires August 12, 2013                [Page 13]
Internet-Draft    UDP Encapsulation for Network Overlay   February 2013

   Lucy Yong
   Huawei USA
   5340 Legacy Drive
   Plano, TX  75025
   U.S.A

   Phone:  469-277-5837
   Email: lucy.yong@huawei.com

   Xiaohu Xu
   Huawei Technologies,
   Beijing, China

   Phone: +86-10-60610041
   Email: xuxiaohu@huawei.com

Yong & Xu, et al       Expires August 12, 2013                [Page 14]