Internet DRAFT - draft-yong-tsvwg-udp-encap-4-ip-tunneling
draft-yong-tsvwg-udp-encap-4-ip-tunneling
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)[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 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 [RFC2119].
1.2. Terminology
The terms defined in [RFC768] 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 [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 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 [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
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 <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
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
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 <iesg@ietf.org>
Contact : IETF Chair <chair@ietf.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 <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:
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: 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
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
Yong & Xu, et al Expires August 25, 2013 [Page 11]
Internet-Draft UDP Encapsulation for IP Tunneling February 2013
Email: fanyb@gsta.com
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
[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.
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", RFC 5565, 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: lucy.yong@huawei.com
Xiaohu Xu
Huawei Technologies,
Beijing, China
Phone: +86-10-60610041
Email: xuxiaohu@huawei.com
Yong & Xu, et al Expires August 25, 2013 [Page 14]
