draft-ietf-tsvwg-gre-in-udp-encap-16.txt   draft-ietf-tsvwg-gre-in-udp-encap-17.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 18, 2016 Expires: February 2017 September 5, 2016
GRE-in-UDP Encapsulation GRE-in-UDP Encapsulation
draft-ietf-tsvwg-gre-in-udp-encap-16 draft-ietf-tsvwg-gre-in-udp-encap-17
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. There are two applicability
specifies GRE-in-UDP tunnel requirements for two applicability scenarios for GRE-in-UDP with different requirements: (1) general
scenarios: (1) general Internet; (2) a traffic-managed controlled Internet; (2) a traffic-managed controlled environment. The
environment. The controlled environment has less restrictive controlled environment has less restrictive requirements than the
requirements than the general Internet. general Internet.
Status of This Document Status of This Document
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 18,2017. This Internet-Draft will expire on February 5,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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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...............................................4 1.1. Terminology...............................................4
1.2. Requirements Language.....................................4 1.2. Requirements Language.....................................4
2. Applicability Statement........................................4 2. Applicability Statement........................................5
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.......................................7 3. GRE-in-UDP Encapsulation.......................................7
3.1. IP Header.................................................9 3.1. IP Header................................................10
3.2. UDP Header................................................9 3.2. UDP Header...............................................10
3.2.1. Source Port..........................................9 3.2.1. Source Port.........................................10
3.2.2. Destination Port....................................10 3.2.2. Destination Port....................................11
3.2.3. Checksum............................................10 3.2.3. Checksum............................................11
3.2.4. Length..............................................10 3.2.4. Length..............................................11
3.3. GRE Header...............................................10 3.3. GRE Header...............................................11
4. Encapsulation Process Procedures..............................11 4. Encapsulation Process Procedures..............................12
4.1. MTU and Fragmentation....................................11 4.1. MTU and Fragmentation....................................12
4.2. Differentiated Services and ECN Marking..................12 4.2. Differentiated Services and ECN Marking..................13
5. Use of DTLS...................................................12 5. Use of DTLS...................................................13
6. UDP Checksum Handling.........................................13 6. UDP Checksum Handling.........................................14
6.1. UDP Checksum with IPv4...................................13 6.1. UDP Checksum with IPv4...................................14
6.2. UDP Checksum with IPv6...................................13 6.2. UDP Checksum with IPv6...................................14
7. Middlebox Considerations......................................16 7. Middlebox Considerations......................................17
7.1. Middlebox Considerations for Zero Checksums..............17 7.1. Middlebox Considerations for Zero Checksums..............18
8. Congestion Considerations.....................................17 8. Congestion Considerations.....................................18
9. Backward Compatibility........................................18 9. Backward Compatibility........................................19
10. IANA Considerations..........................................19 10. IANA Considerations..........................................20
11. Security Considerations......................................20 11. Security Considerations......................................21
12. Acknowledgements.............................................20 12. Acknowledgements.............................................22
13. Contributors.................................................21 13. Contributors.................................................22
14. References...................................................22 14. References...................................................23
14.1. Normative References....................................22 14.1. Normative References....................................23
14.2. Informative References..................................23 14.2. Informative References..................................24
15. Authors' Addresses...........................................24 15. Authors' Addresses...........................................25
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 based on
encapsulation uses Generic Routing Encapsulation (GRE) Generic Routing Encapsulation (GRE) [RFC2784][RFC7676] and User
[RFC2784][RFC7676] and User Datagram Protocol(UDP) [RFC768] headers. Datagram Protocol(UDP) [RFC768] headers. The GRE header indicates
The GRE header provides payload protocol type as an EtherType in the the payload protocol type via an EtherType [RFC7042] in the protocol
protocol type field, and the source port field in the UDP header may type field, and the source port field in the UDP header may be used
be used to provide additional entropy. to provide additional entropy.
A GRE-in-UDP tunnel offers the possibility of better performance for A GRE-in-UDP tunnel offers the possibility of better performance for
load balancing GRE traffic in transit networks using existing Equal- load balancing GRE traffic in transit networks using existing Equal-
Cost Multi-Path (ECMP) mechanisms. Deployed ECMP mechanisms Cost Multi-Path (ECMP) mechanisms that use a hash of the five-tuple
frequently use a hash of the five-tuple of source IP address, of source IP address, destination IP address, UDP/TCP source port,
destination IP address, UDP/TCP source port, UDP/TCP destination UDP/TCP destination port. While such hashing distributes UDP and
port; this hashing distributes UDP and Transmission Control Protocol Transmission Control Protocol (TCP)[RFC793] traffic between a common
(TCP)[RFC793] traffic between a common pair of IP addresses across pair of IP addresses across paths, it uses a single path for
paths, but uses a single path for corresponding GRE traffic because corresponding GRE traffic because only the two IP addresses and
only the two IP addresses and protocol/next header fields protocol/next header fields participate in the ECMP hash.
participate in the ECMP hash. Encapsulating GRE in UDP enables use Encapsulating GRE in UDP enables use of the UDP source port to
of the UDP source port to provide entropy to ECMP hashing. provide entropy to ECMP hashing.
A GRE-in-UDP tunnel also offers the possibility of using GRE across In addition, GRE-in-UDP enables extending use of GRE across networks
networks that might otherwise disallow it; for instance GRE-in-UDP that otherwise disallow it; for example, GRE-in-UDP may be used to
may be used to bridge two islands where GRE is not supported bridge two islands where GRE is not supported natively across the
natively across the middleboxes. 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 tunnels
not differentiate such end hosts from other end hosts, i.e., treat the endpoints of the outer tunnel as the end hosts; the
applying the same treatment for traffic from hosts and tunnel presence of an inner tunnel does not change the outer tunnel's
endpoints. handling of network traffic.
This document specifies GRE-in-UDP tunnel requirements for two In full generality with the capability to carry arbitrary traffic,
applicability scenarios: (1) general Internet; (2) a traffic-managed GRE-in-UDP tunnels are not safe for general deployment in the public
controlled environment. The controlled environment has less Internet. Therefore GRE-in-UDP tunnel deployments are limited to
restrictive requirements than the general Internet. two applicability scenarios for which requirements are specified in
this document: (1) general Internet; (2) a traffic-managed
controlled environment. The traffic-managed controlled environment
scenario has less restrictive technical requirements for the
protocol but more restrictive management and operation requirements
for the network by comparison to the general Internet scenario.
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 for GRE-in-UDP tunnels to be used where/when security is a concern.
concern.
GRE-in-UDP encapsulation usage requires no changes to the transit IP GRE-in-UDP encapsulation usage requires no changes to the transit IP
network. Hash functions in most existing IP routers may utilize and network. ECMP hash functions in most existing IP routers may utilize
benefit from the use of a GRE-in-UDP tunnel without needing any and benefit from the additional entropy enabled by GRE-in-UDP
change or upgrade to their ECMP implementation. The encapsulation tunnels without any change or upgrade to their ECMP implementation.
mechanism is applicable to a variety of IP networks including Data The encapsulation mechanism is applicable to a variety of IP
Center and wide area networks, IPv4 and IPv6 networks. networks including Data Center and Wide Area Networks, as well as
both 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.
Decapsulator: a component performing packet decapsulation at tunnel
egress.
ECMP: Equal-Cost Multi-Path. ECMP: Equal-Cost Multi-Path.
Encapsulator: a component performing packet encapsulation at tunnel
egress.
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].
Default GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can apply to the Default GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can apply to the
general Internet. general Internet.
TMCE: A Traffic-managed controlled environment, i.e. an IP network TMCE: A Traffic-managed controlled environment, i.e. an IP network
that is traffic-engineered and/or otherwise managed (e.g., via use that is traffic-engineered and/or otherwise managed (e.g., via use
of traffic rate limiters) to avoid congestion, as defined in Section of traffic rate limiters) to avoid congestion, as defined in Section
2. 2.
TMCE GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can only apply to a TMCE GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can only apply to a
traffic-managed controlled environment that is defined in Section 2. traffic-managed controlled environment that is defined in Section 2.
Tunnel Egress: A tunnel end point that performs packet decapsulation.
Tunnel Ingress: A tunnel end point that performs packet
encapsulation.
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Applicability Statement 2. Applicability Statement
GRE-in-UDP encapsulation as specified herein applies to IPv4 and GRE-in-UDP encapsulation applies to IPv4 and IPv6 networks; in both
IPv6 networks. When using GRE-in-UDP encapsulation, packets so cases, encapsulated packets are treated as UDP datagrams. Therefore,
encapsulated are treated as UDP datagrams by an IP network. As such, a GRE-in-UDP tunnel needs to meet the UDP usage requirements
a GRE-in-UDP tunnel needs to meet the UDP requirements specified in specified in [RFC5405bis]. These requirements depend on both the
[RFC5405bis], which imposes requirements on GRE-in-UDP tunnel usage. delivery network and the nature of the encapsulated traffic. For
These requirements depend on both the delivery network and the example, the GRE-in-UDP tunnel protocol does not provide any
nature of the encapsulated traffic. For example, the GRE-in-UDP congestion control functionality beyond that of the encapsulated
tunnel protocol does not provide any congestion control traffic. Therefore, a GRE-in-UDP tunnel MUST be used only with
functionality beyond that of the encapsulated traffic. Therefore, a congestion controlled traffic (e.g., IP unicast traffic) and/or
GRE-in-UDP tunnel MUST be used only with congestion controlled within a network that is traffic-managed to avoid congestion.
traffic (e.g., IP unicast traffic) and/or within a network that has
traffic management capability to avoid congestion.
[RFC5405bis] considers two types of IETF UDP applications: 1) [RFC5405bis] describes two applicability scenarios for UDP
General Internet and 2) A controlled environment. The controlled applications: 1) General Internet and 2) A controlled environment.
environment means a single administrative domain or bilaterally The controlled environment means a single administrative domain or
agreed connection between domains. A network forming a controlled bilaterally agreed connection between domains. A network forming a
environment can be managed/operated to meet certain conditions while controlled environment can be managed/operated to meet certain
the general Internet cannot be; thus the requirements for a tunnel conditions while the general Internet cannot be; thus the
protocol operating under a controlled environment can be less requirements for a tunnel protocol operating under a controlled
restrictive than the requirements in the general Internet. environment can be less restrictive than the requirements in the
general Internet.
For the purpose of this document, a traffic-managed controlled For the purpose of this document, a traffic-managed controlled
environment is defined as an IP network that is traffic-engineered environment is defined as an IP network that is traffic-engineered
and/or otherwise managed (e.g., via use of traffic rate limiters) to and/or otherwise managed (e.g., via use of traffic rate limiters) to
avoid congestion. avoid congestion.
This document specifies GRE-in-UDP tunnel usage in the general This document specifies GRE-in-UDP tunnel usage in the general
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. Both Setions 2.1.1 used in a traffic-managed controlled environment. Both Sections
and 2.1.2 are 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.
3. GRE-in-UDP tunnel MUST NOT be used for traffic that does not 3. GRE-in-UDP tunnel MUST NOT be deployed or configured to carry
implement congestion control. As stated in [RFC5405bis], IP-based traffic that is not congestion controlled. As stated in [RFC5405bis],
unicast traffic is generally assumed to be congestion-controlled, IP-based unicast traffic is generally assumed to be congestion-
i.e., it is assumed that the transport protocols generating IP-based controlled, i.e., it is assumed that the transport protocols
traffic at the sender already employ mechanisms that are sufficient generating IP-based traffic at the sender already employ mechanisms
to address congestion on the path. GRE-in-UDP tunnels are not that are sufficient to address congestion on the path. A default
appropriate for traffic that is not known to be congestion- GRE-in-UDP tunnel is not appropriate for traffic that is not known
controlled (e.g., IP multicast traffic). to be congestion-controlled (e.g., most IP multicast traffic).
4. UDP source port values that are used as a source of flow entropy 4. UDP source port values that are used as a source of flow entropy
SHOULD be chosen from the ephemeral port range (49152- SHOULD be chosen from the ephemeral port range (49152-65535)
65535).[RFC5405bis] [RFC5405bis].
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 a Maximum Transmission Unit (MTU) that
SHOULD be performed before encapsulation. In addition, the tunnel is smaller than the packet) SHOULD be performed before encapsulation.
ingress MUST apply the UDP checksum to all encapsulated fragments so In addition, the tunnel ingress MUST apply the UDP checksum to all
that the tunnel egress can validate reassembly of the fragments; it encapsulated fragments so that the tunnel egress can validate
MUST set the same DSCP value as in the DS field of the payload reassembly of the fragments; it MUST set the same Differentiated
packet in all fragments [RFC2474]. To avoid unwanted forwarding over Services Code Point (DSCP) value as in the Differentiated Services
multiple paths, the same source UDP port value SHOULD be set in all (DS) field of the payload packet in all fragments [RFC2474]. To
packet fragments. avoid unwanted forwarding over multiple paths, the same source UDP
port value SHOULD be set in all packet fragments.
2.1.2. Requirements for TMCE GRE-in-UDP Tunnel 2.1.2. Requirements for TMCE GRE-in-UDP Tunnel
The section contains the TMCE GRE-in-UDP tunnel requirements. It The section contains the TMCE GRE-in-UDP tunnel requirements. It
lists the changed requirements, compared with a Default GRE-in-UDP lists the changed requirements, compared with a Default GRE-in-UDP
Tunnel, for a TMCE GRE-in-UDP Tunnel, which corresponds to the Tunnel, for a TMCE GRE-in-UDP Tunnel, which corresponds to the
requirements 1-3 listed in Section 2.1.1. requirements 1-3 listed in Section 2.1.1.
1. A UDP checksum SHOULD be used when encapsulating in IPv4. A 1. A UDP checksum SHOULD be used when encapsulating in IPv4. A
tunnel endpoint sending GRE-in-UDP MAY disable the UDP checksum, tunnel endpoint sending GRE-in-UDP MAY disable the UDP checksum,
skipping to change at page 9, line 41 skipping to change at page 10, line 41
to a flow e.g., the result of an algorithm that perform a hash of to a flow e.g., the result of an algorithm that perform a hash of
the tunnel ingress and egress IP address. the tunnel ingress and egress IP address.
The source port value for a flow set by an encapsulator MAY change The source port value for a flow set by an encapsulator MAY change
over the lifetime of the encapsulated flow. For instance, an over the lifetime of the encapsulated flow. For instance, an
encapsulator may change the assignment for Denial of Service (DOS) encapsulator may change the assignment for Denial of Service (DOS)
mitigation or as a means to effect routing through the ECMP network. mitigation or as a means to effect routing through the ECMP network.
An encapsulator SHOULD NOT change the source port selected for a An encapsulator SHOULD NOT change the source port selected for a
flow more than once every thirty seconds. flow more than once every thirty seconds.
An IPv6 GRE-in-UDP tunnel endpoint should copy a flow entropy value An IPv6 GRE-in-UDP tunnel endpoint SHOULD copy a flow entropy value
in the IPv6 flow label field (requirement 6). This permits network in the IPv6 flow label field (requirement 6). This permits network
equipment to inspect this value and utilize it during forwarding, equipment to inspect this value and utilize it during forwarding,
e.g. to perform ECMP [RFC6438]. e.g. to perform ECMP [RFC6438].
This document places requirements on the generation of the flow This document places requirements on the generation of the flow
entropy value [RFC5405bis] but does not specify the algorithm that entropy value [RFC5405bis] but does not specify the algorithm that
an implementation should use to derive this value. an implementation should use to derive this value.
3.2.2. Destination Port 3.2.2. Destination Port
skipping to change at page 11, line 24 skipping to change at page 12, line 24
the UDP and GRE header according to Section 3. the UDP and GRE header according to Section 3.
Intermediate routers, upon receiving these UDP encapsulated packets, Intermediate routers, upon receiving these UDP encapsulated packets,
could load balance these packets based on the hash of the five-tuple could load balance these packets based on the hash of the five-tuple
of UDP packets. of UDP packets.
Upon receiving these UDP encapsulated packets, the decapsulator Upon receiving these UDP encapsulated packets, the decapsulator
decapsulates them by removing the UDP and GRE headers and then decapsulates them by removing the UDP and GRE headers and then
processes them accordingly. processes them accordingly.
GRE-in-UDP allows encapsulation of unicast, IPv4 broadcast, or GRE-in-UDP can encapsulate traffic with unicast, IPv4 broadcast, or
multicast traffic. Entropy may be generated from the header of multicast (see requirement 3 in Section 2.1.1). However a default
GRE-in-UDP tunnel MUST NOT be deployed or configured to carry
traffic that is not congestion-controlled (See requirement 3 in
Section 2.1.1). Entropy may be generated from the header of
encapsulated packets at an encapsulator. The mapping mechanism encapsulated packets at an encapsulator. The mapping mechanism
between the encapsulated multicast traffic and the multicast between the encapsulated multicast traffic and the multicast
capability in the IP network is transparent and independent of the capability in the IP network is transparent and independent of the
encapsulation and is otherwise outside the scope of this document. encapsulation and is otherwise outside the scope of this document.
To provide entropy for ECMP, GRE-in-UDP does not rely on GRE keep- To provide entropy for ECMP, GRE-in-UDP does not rely on GRE keep-
alive. It is RECOMMENED not to use GRE keep-alive in the GRE-in-UDP alive. It is RECOMMENED not to use GRE keep-alive in the GRE-in-UDP
tunnel. This aligns with middlebox traversal guidelines in Section tunnel. This aligns with middlebox traversal guidelines in Section
3.5 of [RFC5405bis]. 3.5 of [RFC5405bis].
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 Path MTU (PMTU) associated
path between the GRE ingress and the GRE egress tunnel endpoints with the path between the GRE ingress and the GRE egress tunnel
minus the GRE and UDP overhead, assuming the egress MTU for endpoints minus the GRE and UDP overhead, assuming the egress MTU
reassembled packets is larger than PMTU. When applying payload for reassembled packets is larger than PMTU. When applying payload
fragmentation, the UDP checksum MUST be used so that the receiving fragmentation, the UDP checksum MUST be used so that the receiving
endpoint can validate reassembly of the fragments; the same source endpoint can validate reassembly of the fragments; the same source
UDP port SHOULD be used for all packet fragments to ensure the UDP port SHOULD be used for all packet fragments to ensure the
transit routers will forward the fragments on the same path. transit routers will forward 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].
skipping to change at page 16, line 11 skipping to change at page 17, line 21
Generic Router Encapsulation (GRE) does not accumulate incorrect Generic Router Encapsulation (GRE) does not accumulate incorrect
transport layer state as a consequence of GRE header corruption. A transport layer state as a consequence of GRE header corruption. A
corrupt GRE packet may result in either packet discard or forwarding corrupt GRE packet may result in either packet discard or forwarding
of the packet without accumulation of GRE state. Active monitoring of the packet without accumulation of GRE state. Active monitoring
of GRE-in-UDP traffic for errors is REQUIRED as occurrence of errors of GRE-in-UDP traffic for errors is REQUIRED as occurrence of errors
will result in some accumulation of error information outside the will result in some accumulation of error information outside the
protocol for operational and management purposes. This design is in protocol for operational and management purposes. This design is in
accordance with requirement 4 specified in Section 5 of [RFC6936]. accordance with requirement 4 specified in Section 5 of [RFC6936].
The remaining requirements specified in Section 5 of [RFC6936] are The remaining requirements specified in Section 5 of [RFC6936] are
not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply
because GRE does not include a control feedback mechanism. because GRE does not include a control feedback mechanism.
Requirements 8-10 are middlebox requirements that do not apply to Requirements 8-10 are middlebox requirements that do not apply to
GRE-in-UDP tunnel endpoints (see Section 7.1 for further middlebox GRE-in-UDP tunnel endpoints (see Section 7.1 for further middlebox
discussion). discussion).
It is worth mentioning that the use of a zero UDP checksum should It is worth mentioning that the use of a zero UDP checksum should
present the equivalent risk of undetected packet corruption when present the equivalent risk of undetected packet corruption when
sending similar packet using GRE-in-IPv6 without UDP [RFC7676] and sending similar packet using GRE-in-IPv6 without UDP [RFC7676] and
without GRE checksums. without GRE checksums.
skipping to change at page 17, line 14 skipping to change at page 18, line 23
Hence, use of the UDP source port for entropy may impact middleboxes Hence, use of the UDP source port for entropy may impact middleboxes
behavior. If a GRE-in-UDP tunnel is expected to be used on a path behavior. If a GRE-in-UDP tunnel is expected to be used on a path
with a middlebox, the tunnel can be configured to either disable use with a middlebox, the tunnel can be configured to either disable use
of the UDP source port for entropy or to configure middleboxes to of the UDP source port for entropy or to configure middleboxes to
pass packets with UDP source port entropy. pass packets with UDP source port entropy.
7.1. Middlebox Considerations for Zero Checksums 7.1. Middlebox Considerations for Zero Checksums
IPv6 datagrams with a zero UDP checksum will not be passed by any IPv6 datagrams with a zero UDP checksum will not be passed by any
middlebox that validates the checksum based on [RFC2460] or that middlebox that updates the UDP checksum field or simply validates
updates the UDP checksum field, such as NATs or firewalls. Changing the checksum based on [RFC2460], such as firewalls. Changing this
this behavior would require such middleboxes to be updated to behavior would require such middleboxes to be updated to correctly
correctly handle datagrams with zero UDP checksums. The GRE-in-UDP handle datagrams with zero UDP checksums. The GRE-in-UDP
encapsulation does not provide a mechanism to safely fall back to encapsulation does not provide a mechanism to safely fall back to
using a checksum when a path change occurs redirecting a tunnel over using a checksum when a path change occurs redirecting a tunnel over
a path that includes a middlebox that discards IPv6 datagrams with a a path that includes a middlebox that discards IPv6 datagrams with a
zero UDP checksum. In this case the GRE-in-UDP tunnel will be black- zero UDP checksum. In this case the GRE-in-UDP tunnel will be black-
holed by that middlebox. holed by that middlebox.
As such, when any middlebox exists on the path of GRE-in-UDP tunnel, As such, when any middlebox exists on the path of GRE-in-UDP tunnel,
use of the UDP checksum is RECOMMENDED to increase the probability use of the UDP checksum is RECOMMENDED to increase the probability
of successful transmission of GRE-in-UDP packets. Recommended of successful transmission of GRE-in-UDP packets. Recommended
changes to allow firewalls, NATs and other middleboxes to support changes to allow firewalls and other middleboxes to support use of
use of an IPv6 zero UDP checksum are described in Section 5 of an IPv6 zero UDP checksum are described in Section 5 of [RFC6936].
[RFC6936].
8. Congestion Considerations 8. Congestion Considerations
Section 3.1.9 of [RFC5405bis] discusses the congestion Section 3.1.9 of [RFC5405bis] discusses the congestion
considerations for design and use of UDP tunnels; this is important considerations for design and use of UDP tunnels; this is important
because other flows could share the path with one or more UDP because other flows could share the path with one or more UDP
tunnels, necessitating congestion control [RFC2914] to avoid tunnels, necessitating congestion control [RFC2914] to avoid
distractive interference. distractive interference.
Congestion has potential impacts both on the rest of the network Congestion has potential impacts both on the rest of the network
containing a UDP tunnel, and on the traffic flows using the UDP containing a UDP tunnel, and on the traffic flows using the UDP
tunnels. These impacts depend upon what sort of traffic is carried tunnels. These impacts depend upon what sort of traffic is carried
over the tunnel, as well as the path of the tunnel. over the tunnel, as well as the path of the tunnel.
A default GRE-in-UDP tunnel MAY be used to carry IP traffic that is A default GRE-in-UDP tunnel MAY be used to carry IP traffic that is
known to be congestion controlled on the Internet. IP unicast known to be congestion controlled on the Internet. IP unicast
traffic is generally assumed to be congestion-controlled. A default traffic is generally assumed to be congestion-controlled. A default
GRE-in-UDP tunnel MUST NOT be used to carry traffic that is not GRE-in-UDP tunnel is not appropriate for traffic that is not known
known to be congestion-controlled. to be congestion-controlled.
A TMCE GRE-in-UDP tunnel can be used to carry traffic that is known A TMCE GRE-in-UDP tunnel can be used to carry traffic that is known
not to be congestion controlled. For example, GRE-in-UDP may be used not to be congestion controlled. For example, GRE-in-UDP may be used
to carry MPLS that carries pseudowire or VPN traffic where specific to carry Multiprotocol Label Switching (MPLS) that carries
bandwidth guarantees are provided to each pseudowire or to each VPN. pseudowire or VPN traffic where specific bandwidth guarantees are
In such cases, network operators may avoid congestion by careful provided to each pseudowire or to each VPN. In such cases, network
provisioning of their networks, by rate limiting of user data operators may avoid congestion by careful provisioning of their
traffic, and traffic engineering according to path capacity. networks, by rate limiting of user data traffic, and traffic
engineering according to path capacity.
When a TMCE GRE-in-UDP tunnel carries traffic that is not known to When a TMCE GRE-in-UDP tunnel carries traffic that is not known to
be congestion controlled, the tunnel MUST be used within a traffic- be congestion controlled, the tunnel MUST be used within a traffic-
managed controlled environment (e.g., single operator network that managed controlled environment (e.g., single operator network that
utilizes careful provisioning such as rate limiting at the entries utilizes careful provisioning such as rate limiting at the entries
of the network while over-provisioning network capacity) to manage of the network while over-provisioning network capacity) to manage
congestion, or within a limited number of networks whose operators congestion, or within a limited number of networks whose operators
closely cooperate in order to jointly provide this same careful closely cooperate in order to jointly provide this same careful
provisioning. When a TMCE GRE-in-UDP tunnel is used to carry the provisioning. When a TMCE GRE-in-UDP tunnel is used to carry the
traffic that is not known to be congestion controlled, measures traffic that is not known to be congestion controlled, measures
skipping to change at page 20, line 16 skipping to change at page 21, line 22
GRE-in-UDP encapsulation does not affect security for the payload GRE-in-UDP encapsulation does not affect security for the payload
protocol. The security considerations for GRE apply to GRE-in-UDP, protocol. The security considerations for GRE apply to GRE-in-UDP,
see [RFC2784]. 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
be periodically changed to mitigate certain denial of service also 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.
Using one standardized value as the UDP destination port to indicate Using one standardized value as the UDP destination port to indicate
an encapsulation may increase the vulnerability of off-path attack. an encapsulation may increase the vulnerability of off-path attack.
To overcome this, an alternate port may be agreed upon to use To overcome this, an alternate port may be agreed upon to use
between an encapsulator and decapsulator [RFC6056]. How the between an encapsulator and decapsulator [RFC6056]. How the
encapsulator end points communicate the value is outside scope of encapsulator end points communicate the value is outside scope of
this document. this document.
This document does not require that a decapsulator validates the IP This document does not require that a decapsulator validates the IP
source address of the tunneled packets (with the exception that the source address of the tunneled packets (with the exception that the
IPv6 source address MUST be validated when UDP zero-checksum mode is IPv6 source address MUST be validated when UDP zero-checksum mode is
used with IPv6), but it should be understood that failure to do so used with IPv6), but it should be understood that failure to do so
presupposes that there is effective destination-based (or a presupposes that there is effective destination-based (or a
combination of source-based and destination-based) filtering at the combination of source-based and destination-based) filtering at the
boundaries. boundaries.
Corruption of a GRE header can cause a privacy and security concern Corruption of a GRE header can cause a privacy and security concern
for some applications that rely on the key field for traffic for some applications that rely on the key field for traffic
segregation. When the GRE key field is used for privacy and security, segregation. When the GRE key field is used for privacy and security,
ether UDP checksum or GRE checksum SHOULD be used for GRE-in-UDP either 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, Rick Casarez, Jouni
review and valuable input on this draft. Korhonen, and many others for their review and valuable input on
this draft.
Thank Donald Eastlake, Eliot Lear, Martin Stiemerling, and Spencer Thank Donald Eastlake, Eliot Lear, Martin Stiemerling, and Spencer
Dawkins for their detail reviews and valuable suggestions in WGLC Dawkins for their detail reviews and valuable suggestions in WGLC
and IESG process. 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.
skipping to change at page 22, line 27 skipping to change at page 23, line 34
Hewlett-Packard Corp. Hewlett-Packard Corp.
3000 Hanover St, Palo Alto. 3000 Hanover St, Palo Alto.
Email: vishwas.manral@hp.com Email: vishwas.manral@hp.com
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 USA Research Triangle Park, NC 27709 USA
EMail: cpignata@cisco.com Email: cpignata@cisco.com
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC1122] Braden, R., "Requirements for Internet Hosts -- [RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", RFC1122, October 1989. Communication Layers", RFC1122, October 1989.
skipping to change at page 23, line 26 skipping to change at page 24, line 33
[RFC6040] Briscoe, B., "Tunneling of Explicit Congestion [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion
Notification", RFC6040, November 2010. Notification", RFC6040, November 2010.
[RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer
Security Version 1.2", RFC6347, 2012. Security Version 1.2", RFC6347, 2012.
[RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for [RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for
Equal Cost Multipath Routing and Link Aggregation in Equal Cost Multipath Routing and Link Aggregation in
tunnels", RFC6438, November, 2011. tunnels", RFC6438, November, 2011.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, April 2013. UDP Checksums for Tunneled Packets", RFC 6935, April 2013.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, April 2013. RFC 6936, April 2013.
14.2. Informative References 14.2. Informative References
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981. 792, September 1981.
[RFC793] DARPA, "Transmission Control Protocol", RFC793, September [RFC793] DARPA, "Transmission Control Protocol", RFC793, September
1981. 1981.
skipping to change at page 24, line 15 skipping to change at page 25, line 21
[RFC4787] Audet, F., et al, "network Address Translation (NAT) [RFC4787] Audet, F., et al, "network Address Translation (NAT)
Behavioral Requirements for Unicast UDP", RFC4787, January Behavioral Requirements for Unicast UDP", RFC4787, January
2007. 2007.
[RFC6056] Larsen, M. and Gont, F., "Recommendations for Transport- [RFC6056] Larsen, M. and Gont, F., "Recommendations for Transport-
Protocol Port Randomization", RFC6056, January 2011. Protocol Port Randomization", RFC6056, January 2011.
[RFC6438] Carpenter, B., Amante, S., "Using the Ipv6 Flow Label for [RFC6438] Carpenter, B., Amante, S., "Using the Ipv6 Flow Label for
Equal Cost Multipath Routing and Link Aggreation in Equal Cost Multipath Routing and Link Aggreation in
Tunnels", RFC6438, November 2011. Tunnels", RFC6438, November 2011.
rd [RFC7042] Eastlake 3 , D. and Abley, J., "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802
Parameter", RFC7042, October 2013.
[RFC7676] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for [RFC7676] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for
Generic Routing Encapsulation (GRE)", RFC7676, October Generic Routing Encapsulation (GRE)", RFC7676, October
2015. 2015.
[CB] Fairhurst, G., "Network Transport Circuit Breakers", [CB] Fairhurst, G., "Network Transport Circuit Breakers",
draft-ietf-tsvwg-circuit-breaker-15, work in progress. draft-ietf-tsvwg-circuit-breaker-15, work in progress.
15. Authors' Addresses 15. Authors' Addresses
 End of changes. 37 change blocks. 
139 lines changed or deleted 162 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/