draft-ietf-tsvwg-gre-in-udp-encap-13.txt   draft-ietf-tsvwg-gre-in-udp-encap-14.txt 
Network Working Group Lucy Yong(Ed.) Network Working Group Lucy Yong(Ed.)
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standard Track E. Crabbe Intended status: Standard Track E. Crabbe
Oracle Oracle
X. Xu X. Xu
Huawei Technologies Huawei Technologies
T. Herbert T. Herbert
Facebook Facebook
Expires: January 2017 July 4, 2016 Expires: January 2017 July 17, 2016
GRE-in-UDP Encapsulation GRE-in-UDP Encapsulation
draft-ietf-tsvwg-gre-in-udp-encap-13 draft-ietf-tsvwg-gre-in-udp-encap-14
Abstract Abstract
This document specifies a method of encapsulating network protocol This document specifies a method of encapsulating network protocol
packet within GRE and UDP headers. This GRE-in-UDP encapsulation packet within GRE and UDP headers. This GRE-in-UDP encapsulation
allows the UDP source port field to be used as an entropy field. allows the UDP source port field to be used as an entropy field.
This may be used for load balancing of GRE traffic in transit This may be used for load balancing of GRE traffic in transit
networks using existing ECMP mechanisms. This document also networks using existing ECMP mechanisms. This document also
specifies GRE-in-UDP tunnel requirements for two applicability specifies GRE-in-UDP tunnel requirements for two applicability
scenarios: (1) general Internet; (2) a traffic-managed controlled scenarios: (1) general Internet; (2) a traffic-managed controlled
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4,2017. This Internet-Draft will expire on January 17,2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Terminology...............................................3 1.1. Terminology...............................................4
1.2. Requirements Language.....................................4 1.2. Requirements Language.....................................4
2. Applicability Statement........................................4 2. Applicability Statement........................................4
2.1. GRE-in-UDP Tunnel Requirements............................5 2.1. GRE-in-UDP Tunnel Requirements............................5
2.1.1. Requirements for Default GRE-in-UDP Tunnel...........5 2.1.1. Requirements for Default GRE-in-UDP Tunnel...........5
2.1.2. Requirements for TMCE GRE-in-UDP Tunnel..............6 2.1.2. Requirements for TMCE GRE-in-UDP Tunnel..............6
3. GRE-in-UDP Encapsulation.......................................6 3. GRE-in-UDP Encapsulation.......................................7
3.1. IP Header.................................................9 3.1. IP Header.................................................9
3.2. UDP Header................................................9 3.2. UDP Header................................................9
3.2.1. Source Port..........................................9 3.2.1. Source Port..........................................9
3.2.2. Destination Port....................................10 3.2.2. Destination Port....................................10
3.2.3. Checksum............................................10 3.2.3. Checksum............................................10
3.2.4. Length..............................................10 3.2.4. Length..............................................10
3.3. GRE Header...............................................10 3.3. GRE Header...............................................10
4. Encapsulation Process Procedures..............................11 4. Encapsulation Process Procedures..............................11
4.1. MTU and Fragmentation....................................11 4.1. MTU and Fragmentation....................................11
4.2. Differentiated Services and ECN Marking..................12 4.2. Differentiated Services and ECN Marking..................12
skipping to change at page 3, line 13 skipping to change at page 3, line 13
15. Authors' Addresses...........................................24 15. Authors' Addresses...........................................24
1. Introduction 1. Introduction
This document specifies a generic GRE-in-UDP encapsulation for This document specifies a generic GRE-in-UDP encapsulation for
tunneling network protocol packets across an IP network. This tunneling network protocol packets across an IP network. This
encapsulation uses Generic Routing Encapsulation (GRE) encapsulation uses Generic Routing Encapsulation (GRE)
[RFC2784][RFC7676] and User Datagram Protocol(UDP) [RFC768] headers. [RFC2784][RFC7676] and User Datagram Protocol(UDP) [RFC768] headers.
The GRE header provides payload protocol type as an EtherType in the The GRE header provides payload protocol type as an EtherType in the
protocol type field, and the source port field in the UDP header may protocol type field, and the source port field in the UDP header may
be used to provide additional entropy that may be used for load be used to provide additional entropy.
balancing GRE traffic in transit networks using existing Equal-Cost
Multi-Path (ECMP) mechanisms. Existing ECMP mechanisms, when the IP
payload is a UDP or Transmission Control Protocol (TCP)[RFC793]
packet, frequently use of a hash of the five-tuple of source IP
address, destination IP address, UDP/TCP source port, UDP/TCP
destination port, and protocol/next-header. A GRE-in-UDP tunnel
offers the additional possibility of using GRE across networks that
might otherwise disallow it; for instance GRE-in-UDP may be used to
bridge two islands where GRE is not supported natively across the
middleboxes.
This encapsulation method requires no changes to the transit IP A GRE-in-UDP tunnel offers the possibility of better performance for
network. Hash functions in most existing IP routers may utilize and load balancing GRE traffic in transit networks using existing Equal-
benefit from the use of a GRE-in-UDP tunnel without needing any Cost Multi-Path (ECMP) mechanisms. Existing ECMP mechanisms, when
change or upgrade to their ECMP implementation. The encapsulation the IP payload is a UDP or Transmission Control Protocol
mechanism is applicable to a variety of IP networks including Data (TCP)[RFC793] packet, frequently use of a hash of the five-tuple of
Center and wide area networks. source IP address, destination IP address, UDP/TCP source port,
UDP/TCP destination port, and protocol/next-header.
A GRE-in-UDP tunnel also offers the possibility of using GRE across
networks that might otherwise disallow it; for instance GRE-in-UDP
may be used to bridge two islands where GRE is not supported
natively across the middleboxes.
GRE-in-UDP encapsulation may be used to encapsulate already tunneled GRE-in-UDP encapsulation may be used to encapsulate already tunneled
traffic, i.e. tunnel-in-tunnel. In this case, GRE-in-UDP tunnel do traffic, i.e. tunnel-in-tunnel. In this case, GRE-in-UDP tunnel do
not differentiate such end hosts from other end hosts, i.e., not differentiate such end hosts from other end hosts, i.e.,
applying the same treatment for traffic from hosts and tunnel applying the same treatment for traffic from hosts and tunnel
endpoints. endpoints.
This document specifies GRE-in-UDP tunnel requirements for two This document specifies GRE-in-UDP tunnel requirements for two
applicability scenarios: (1) general Internet; (2) a traffic-managed applicability scenarios: (1) general Internet; (2) a traffic-managed
controlled environment. The controlled environment has less controlled environment. The controlled environment has less
restrictive requirements than the general Internet. restrictive requirements than the general Internet.
The document also specifies Datagram Transport Layer Security (DTLS) The document also specifies Datagram Transport Layer Security (DTLS)
version of GRE-in-UDP tunnel to be used where/when security is a version of GRE-in-UDP tunnel to be used where/when security is a
concern. concern.
GRE-in-UDP encapsulation usage requires no changes to the transit IP
network. Hash functions in most existing IP routers may utilize and
benefit from the use of a GRE-in-UDP tunnel without needing any
change or upgrade to their ECMP implementation. The encapsulation
mechanism is applicable to a variety of IP networks including Data
Center and wide area networks, IPv4 and IPv6 networks.
1.1. Terminology 1.1. Terminology
The terms defined in [RFC768] and [RFC2784] are used in this The terms defined in [RFC768] and [RFC2784] are used in this
document. Following are additional terms used in this draft. document. Following are additional terms used in this draft.
ECMP: Equal-Cost Multi-Path. ECMP: Equal-Cost Multi-Path.
Flow Entropy: The information to be derived from traffic or Flow Entropy: The information to be derived from traffic or
applications and to be used by network devices in ECMP process applications and to be used by network devices in ECMP process
[RFC6438]. [RFC6438].
skipping to change at page 5, line 21 skipping to change at page 5, line 26
Internet and GRE-in-UDP tunnel usage in a traffic-managed controlled Internet and GRE-in-UDP tunnel usage in a traffic-managed controlled
environment and uses "default GRE-in-UDP tunnel" and "TMCE GRE-in- environment and uses "default GRE-in-UDP tunnel" and "TMCE GRE-in-
UDP tunnel" terms to refer to each usage. UDP tunnel" terms to refer to each usage.
2.1. GRE-in-UDP Tunnel Requirements 2.1. GRE-in-UDP Tunnel Requirements
This section states out the requirements for a GRE-in-UDP tunnel. This section states out the requirements for a GRE-in-UDP tunnel.
Section 2.1.1 describes the requirements for a default GRE-in-UDP Section 2.1.1 describes the requirements for a default GRE-in-UDP
tunnel that is suitable for the general Internet; Section 2.1.2 tunnel that is suitable for the general Internet; Section 2.1.2
describes a set of relaxed requirements for a TMCE GRE-in-UDP tunnel describes a set of relaxed requirements for a TMCE GRE-in-UDP tunnel
used in a traffic-managed controlled environment. They are used in a traffic-managed controlled environment. Both Sections
applicable to an IPv4 or IPv6 delivery network. 2.1.1 and 2.1.2 are applicable to an IPv4 or IPv6 delivery network.
2.1.1. Requirements for Default GRE-in-UDP Tunnel 2.1.1. Requirements for Default GRE-in-UDP Tunnel
The following is a summary of the default GRE-in-UDP tunnel The following is a summary of the default GRE-in-UDP tunnel
requirements: requirements:
1. A UDP checksum SHOULD be used when encapsulating in IPv4. 1. A UDP checksum SHOULD be used when encapsulating in IPv4.
2. A UDP checksum MUST be used when encapsulating in IPv6. 2. A UDP checksum MUST be used when encapsulating in IPv6.
skipping to change at page 6, line 9 skipping to change at page 6, line 14
5. The use of the UDP source port MUST be configurable so that a 5. The use of the UDP source port MUST be configurable so that a
single value can be set for all traffic within the tunnel (this single value can be set for all traffic within the tunnel (this
disables use of the UDP source port to provide flow entropy). When a disables use of the UDP source port to provide flow entropy). When a
single value is set, a random port SHOULD be selected in order to single value is set, a random port SHOULD be selected in order to
minimize the vulnerability to off-path attacks [RFC6056]. minimize the vulnerability to off-path attacks [RFC6056].
6. For IPv6 delivery networks, the flow entropy SHOULD also be 6. For IPv6 delivery networks, the flow entropy SHOULD also be
placed in the flow label field for ECMP per [RFC6438]. placed in the flow label field for ECMP per [RFC6438].
7. At the tunnel ingress, any fragmentation of the incoming packet 7. At the tunnel ingress, any fragmentation of the incoming packet
(e.g., because the tunnel has an MTU that is smaller than the packet (e.g., because the tunnel has an MTU that is smaller than the packet)
SHOULD be performed before encapsulation. In addition, the tunnel SHOULD be performed before encapsulation. In addition, the tunnel
ingress MUST apply the UDP checksum to all encapsulated fragments so ingress MUST apply the UDP checksum to all encapsulated fragments so
that the tunnel egress can validate reassembly of the fragments; it that the tunnel egress can validate reassembly of the fragments; it
MUST set the same DSCP value as in the DS field of the payload MUST set the same DSCP value as in the DS field of the payload
packet in all fragments [RFC2474]. To avoid unwanted forwarding over packet in all fragments [RFC2474]. To avoid unwanted forwarding over
multiple paths, the same source UDP port value SHOULD be set in all multiple paths, the same source UDP port value SHOULD be set in all
packet fragments. packet fragments.
2.1.2. Requirements for TMCE GRE-in-UDP Tunnel 2.1.2. Requirements for TMCE GRE-in-UDP Tunnel
skipping to change at page 11, line 45 skipping to change at page 11, line 45
4.1. MTU and Fragmentation 4.1. MTU and Fragmentation
Regarding packet fragmentation, an encapsulator/decapsulator SHOULD Regarding packet fragmentation, an encapsulator/decapsulator SHOULD
perform fragmentation before the encapsulation. The size of perform fragmentation before the encapsulation. The size of
fragments SHOULD be less or equal to the PMTU associated with the fragments SHOULD be less or equal to the PMTU associated with the
path between the GRE ingress and the GRE egress tunnel endpoints path between the GRE ingress and the GRE egress tunnel endpoints
minus the GRE and UDP overhead, assuming the egress resemble MTU is minus the GRE and UDP overhead, assuming the egress resemble MTU is
larger than PMTU. When applying payload fragmentation, the UDP larger than PMTU. When applying payload fragmentation, the UDP
checksum MUST be used so that the receiving endpoint can validate checksum MUST be used so that the receiving endpoint can validate
reassembly of the fragments; the same source UDP port SHOULD be used resemble of the fragments; the same source UDP port SHOULD be used
for all packet fragments to ensure the transit routers will forward for all packet fragments to ensure the transit routers will forward
the fragments on the same path. the fragments on the same path.
If the operator of the transit network supporting the tunnel is able If the operator of the transit network supporting the tunnel is able
to control the payload MTU size, the MTU SHOULD be configured to to control the payload MTU size, the MTU SHOULD be configured to
avoid fragmentation, i.e., sufficient for the largest supported size avoid fragmentation, i.e., sufficient for the largest supported size
of packet, including all additional bytes introduced by the tunnel of packet, including all additional bytes introduced by the tunnel
overhead [RFC5405bis]. overhead [RFC5405bis].
4.2. Differentiated Services and ECN Marking 4.2. Differentiated Services and ECN Marking
skipping to change at page 12, line 47 skipping to change at page 12, line 47
destination IP addresses). Both IP addresses MUST be unicast destination IP addresses). Both IP addresses MUST be unicast
addresses - multicast traffic is not supported when DTLS is used. A addresses - multicast traffic is not supported when DTLS is used. A
GRE-in-UDP tunnel decapsulator that supports DTLS is expected to be GRE-in-UDP tunnel decapsulator that supports DTLS is expected to be
able to establish DTLS sessions with multiple tunnel encapsulators, able to establish DTLS sessions with multiple tunnel encapsulators,
and likewise a GRE-in-UDP tunnel encapsulator is expected to be able and likewise a GRE-in-UDP tunnel encapsulator is expected to be able
to establish DTLS sessions with multiple decapsulators. Different to establish DTLS sessions with multiple decapsulators. Different
source and/or destination IP addresses will be involved (see Section source and/or destination IP addresses will be involved (see Section
6.2) for discussion of one situation where use of different source 6.2) for discussion of one situation where use of different source
IP addresses is important. IP addresses is important.
If an application already performs encryption, no need to encrypt If the traffic to be encapsulated is already encrypted, it is
traffic again. Applying DTLS to a GRE-in-UDP tunnel requires both usually not necessary to encrypt it again. Applying DTLS to GRE-in-
tunnel end points to configure use of DTLS. UDP tunnel requires both tunnel end points to configure use of DTLS.
6. UDP Checksum Handling 6. UDP Checksum Handling
6.1. UDP Checksum with IPv4 6.1. UDP Checksum with IPv4
For UDP in IPv4, the UDP checksum MUST be processed as specified in For UDP in IPv4, the UDP checksum MUST be processed as specified in
[RFC768] and [RFC1122] for both transmit and receive. The IPv4 [RFC768] and [RFC1122] for both transmit and receive. The IPv4
header includes a checksum that protects against mis-delivery of the header includes a checksum that protects against mis-delivery of the
packet due to corruption of IP addresses. The UDP checksum packet due to corruption of IP addresses. The UDP checksum
potentially provides protection against corruption of the UDP header, potentially provides protection against corruption of the UDP header,
skipping to change at page 20, line 8 skipping to change at page 20, line 8
Service Code: N/A Service Code: N/A
Known Unauthorized Uses: N/A Known Unauthorized Uses: N/A
Assignment Notes: N/A Assignment Notes: N/A
Editor Note: replace "TBD2" in section 3, 5, and 9 with IANA Editor Note: replace "TBD2" in section 3, 5, and 9 with IANA
assigned number. assigned number.
11. Security Considerations 11. Security Considerations
GRE-in-UDP encapsulation does not affect security for the payload GRE-in-UDP encapsulation does not affect security for the payload
protocol. When using GRE-in-UDP, Network Security in a network is protocol. The security considerations for GRE apply to GRE-in-UDP,
mostly equivalent to that of a network using GRE. see [RFC2784].
To secure original traffic, DTLS SHOULD be used as specified in To secure original traffic, DTLS SHOULD be used as specified in
Section 5. Section 5.
In the case that UDP source port for entropy usage is disabled, a In the case that UDP source port for entropy usage is disabled, a
random port SHOULD be selected in order to minimize the random port SHOULD be selected in order to minimize the
vulnerability to off-path attacks.[RFC6056] The random port may also vulnerability to off-path attacks.[RFC6056] The random port may also
be periodically changed to mitigate certain denial of service be periodically changed to mitigate certain denial of service
attacks as mentioned in Section 3.2.1. attacks as mentioned in Section 3.2.1.
skipping to change at page 20, line 48 skipping to change at page 21, line 5
ether UDP checksum or GRE checksum SHOULD be used for GRE-in-UDP ether UDP checksum or GRE checksum SHOULD be used for GRE-in-UDP
with both IPv4 and IPv6, and in particular, when UDP zero-checksum with both IPv4 and IPv6, and in particular, when UDP zero-checksum
mode is used, GRE checksum SHOULD be used. mode is used, GRE checksum SHOULD be used.
12. Acknowledgements 12. Acknowledgements
Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger
Geib, Lar Edds, Lloyd Wood, Bob Briscoe, and many others for their Geib, Lar Edds, Lloyd Wood, Bob Briscoe, and many others for their
review and valuable input on this draft. review and valuable input on this draft.
Thank Donald Eastlake, Eliot Lear, and Martin Stiemerling for their Thank Donald Eastlake, Eliot Lear, Martin Stiemerling, and Spencer
detail reviews and valuable suggestions in WGLC process. Dawkins for their detail reviews and valuable suggestions in WGLC
and IESG process.
Thank the design team led by David Black (members: Ross Callon, Thank the design team led by David Black (members: Ross Callon,
Gorry Fairhurst, Xiaohu Xu, Lucy Yong) to efficiently work out the Gorry Fairhurst, Xiaohu Xu, Lucy Yong) to efficiently work out the
descriptions for the congestion considerations and IPv6 UDP zero descriptions for the congestion considerations and IPv6 UDP zero
checksum. checksum.
Thank David Black and Gorry Fairhurst for their great help in Thank David Black and Gorry Fairhurst for their great help in
document content and editing. document content and editing.
13. Contributors 13. Contributors
 End of changes. 14 change blocks. 
33 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/