summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8086.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8086.txt')
-rw-r--r--doc/rfc/rfc8086.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc8086.txt b/doc/rfc/rfc8086.txt
new file mode 100644
index 0000000..9e7c00c
--- /dev/null
+++ b/doc/rfc/rfc8086.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Yong, Ed.
+Request for Comments: 8086 Huawei Technologies
+Category: Standards Track E. Crabbe
+ISSN: 2070-1721 Oracle
+ X. Xu
+ Huawei Technologies
+ T. Herbert
+ Facebook
+ March 2017
+
+
+ GRE-in-UDP Encapsulation
+
+Abstract
+
+ This document specifies a method of encapsulating network protocol
+ packets within GRE and UDP headers. This GRE-in-UDP encapsulation
+ 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
+ networks using existing Equal-Cost Multipath (ECMP) mechanisms.
+ There are two applicability scenarios for GRE-in-UDP with different
+ requirements: (1) general Internet and (2) a traffic-managed
+ controlled environment. The controlled environment has less
+ restrictive requirements than the general Internet.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc8086.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 1]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 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. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 2]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Terminology ................................................5
+ 1.2. Requirements Language ......................................5
+ 2. Applicability Statement .........................................6
+ 2.1. GRE-in-UDP Tunnel Requirements .............................6
+ 2.1.1. Requirements for Default GRE-in-UDP Tunnel ..........7
+ 2.1.2. Requirements for TMCE GRE-in-UDP Tunnel .............8
+ 3. GRE-in-UDP Encapsulation ........................................9
+ 3.1. IP Header .................................................11
+ 3.2. UDP Header ................................................11
+ 3.2.1. Source Port ........................................11
+ 3.2.2. Destination Port ...................................11
+ 3.2.3. Checksum ...........................................12
+ 3.2.4. Length .............................................12
+ 3.3. GRE Header ................................................12
+ 4. Encapsulation Procedures .......................................13
+ 4.1. MTU and Fragmentation .....................................13
+ 4.2. Differentiated Services and ECN Marking ...................14
+ 5. Use of DTLS ....................................................14
+ 6. UDP Checksum Handling ..........................................15
+ 6.1. UDP Checksum with IPv4 ....................................15
+ 6.2. UDP Checksum with IPv6 ....................................15
+ 7. Middlebox Considerations .......................................18
+ 7.1. Middlebox Considerations for Zero Checksums ...............19
+ 8. Congestion Considerations ......................................19
+ 9. Backward Compatibility .........................................20
+ 10. IANA Considerations ...........................................21
+ 11. Security Considerations .......................................21
+ 12. References ....................................................22
+ 12.1. Normative References .....................................22
+ 12.2. Informative References ...................................23
+ Acknowledgements ..................................................25
+ Contributors ......................................................25
+ Authors' Addresses ................................................27
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 3]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+1. Introduction
+
+ This document specifies a generic GRE-in-UDP encapsulation for
+ tunneling network protocol packets across an IP network based on
+ Generic Routing Encapsulation (GRE) [RFC2784] [RFC7676] and User
+ Datagram Protocol (UDP) [RFC768] headers. The GRE header indicates
+ the payload protocol type via an EtherType [RFC7042] in the protocol
+ type field, and the source port field in the UDP header may be used
+ to provide additional entropy.
+
+ A GRE-in-UDP tunnel offers the possibility of better performance for
+ load-balancing GRE traffic in transit networks using existing Equal-
+ Cost Multipath (ECMP) mechanisms that use a hash of the five-tuple of
+ source IP address, destination IP address, UDP/TCP source port,
+ UDP/TCP destination port, and protocol number. While such hashing
+ distributes UDP and TCP [RFC793] traffic between a common pair of IP
+ addresses across paths, it uses a single path for corresponding GRE
+ traffic because only the two IP addresses and the Protocol or Next
+ Header field participate in the ECMP hash. Encapsulating GRE in UDP
+ enables use of the UDP source port to provide entropy to ECMP
+ hashing.
+
+ In addition, GRE-in-UDP enables extending use of GRE across networks
+ that otherwise disallow it; for example, 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
+ traffic, i.e., tunnel-in-tunnel traffic. In this case, GRE-in-UDP
+ tunnels treat the endpoints of the outer tunnel as the end hosts; the
+ presence of an inner tunnel does not change the outer tunnel's
+ handling of network traffic.
+
+ A GRE-in-UDP tunnel is capable of carrying arbitrary traffic and
+ behaves as a UDP application on an IP network. However, a GRE-in-UDP
+ tunnel carrying certain types of traffic does not satisfy the
+ requirements for UDP applications on the Internet [RFC8085].
+ GRE-in-UDP tunnels that do not satisfy these requirements MUST NOT be
+ deployed to carry such traffic over the Internet. For this reason,
+ this document specifies two deployment scenarios for GRE-in-UDP
+ tunnels with GRE-in-UDP tunnel requirements for each of them: (1)
+ general Internet and (2) a traffic-managed controlled environment
+ (TMCE). Compared to the general Internet scenario, the TMCE scenario
+ has less restrictive technical requirements for the protocol but more
+ restrictive management and operation requirements for the network.
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 4]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ To provide security for traffic carried by a GRE-in-UDP tunnel, this
+ document also specifies Datagram Transport Layer Security (DTLS) for
+ GRE-in-UDP tunnels, which SHOULD be used when security is a concern.
+
+ GRE-in-UDP encapsulation usage requires no changes to the transit IP
+ network. ECMP hash functions in most existing IP routers may utilize
+ and benefit from the additional entropy enabled by GRE-in-UDP tunnels
+ without any change or upgrade to their ECMP implementation. The
+ encapsulation mechanism is applicable to a variety of IP networks
+ including Data Center Networks and Wide Area Networks, as well as
+ both IPv4 and IPv6 networks.
+
+1.1. Terminology
+
+ The terms defined in [RFC768] and [RFC2784] are used in this
+ document. Below are additional terms used in this document.
+
+ Decapsulator: a component performing packet decapsulation at tunnel
+ egress.
+
+ ECMP: Equal-Cost Multipath.
+
+ Encapsulator: a component performing packet encapsulation at tunnel
+ egress.
+
+ Flow Entropy: The information to be derived from traffic or
+ applications and to be used by network devices in the ECMP process
+ [RFC6438].
+
+ Default GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can apply to the
+ general Internet.
+
+ TMCE: A traffic-managed controlled environment, i.e., an IP network
+ that is traffic-engineered and/or otherwise managed (e.g., via use of
+ traffic rate limiters) to avoid congestion, as defined in Section 2.
+
+ 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.
+
+ Tunnel Egress: A tunnel endpoint that performs packet decapsulation.
+
+ Tunnel Ingress: A tunnel endpoint that performs packet encapsulation.
+
+1.2. Requirements Language
+
+ 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 [RFC2119].
+
+
+
+Yong, et al. Standards Track [Page 5]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+2. Applicability Statement
+
+ GRE-in-UDP encapsulation applies to IPv4 and IPv6 networks; in both
+ cases, encapsulated packets are treated as UDP datagrams. Therefore,
+ a GRE-in-UDP tunnel needs to meet the UDP usage requirements
+ specified in [RFC8085]. These requirements depend on both the
+ delivery network and the nature of the encapsulated traffic. For
+ example, the GRE-in-UDP tunnel protocol does not provide any
+ congestion control functionality beyond that of the encapsulated
+ traffic. Therefore, a GRE-in-UDP tunnel MUST be used only with
+ congestion-controlled traffic (e.g., IP unicast traffic) and/or
+ within a network that is traffic managed to avoid congestion.
+
+ [RFC8085] describes two applicability scenarios for UDP applications:
+ (1) general internet and (2) a controlled environment. The
+ controlled environment means a single administrative domain or
+ bilaterally agreed connection between domains. A network forming a
+ controlled environment can be managed/operated to meet certain
+ conditions, while the general Internet cannot be; thus, the
+ requirements for a tunnel protocol operating under a controlled
+ environment can be less restrictive than the requirements in the
+ general Internet.
+
+ For the purpose of this document, a traffic-managed controlled
+ environment (TMCE) is defined as an IP network that is traffic-
+ engineered and/or otherwise managed (e.g., via use of traffic rate
+ limiters) to avoid congestion.
+
+ This document specifies GRE-in-UDP tunnel usage in the general
+ Internet and GRE-in-UDP tunnel usage in a traffic-managed controlled
+ environment and uses "default GRE-in-UDP tunnel" and "TMCE GRE-in-UDP
+ tunnel" terms to refer to each usage.
+
+ NOTE: Although this document specifies two different sets of GRE-in-
+ UDP tunnel requirements based on tunnel usage, the tunnel
+ implementation itself has no ability to detect how and where it is
+ deployed. Therefore, it is the responsibility of the user or
+ operator who deploys a GRE-in-UDP tunnel to ensure that it meets the
+ appropriate requirements.
+
+2.1. GRE-in-UDP Tunnel Requirements
+
+ This section states the requirements for a GRE-in-UDP tunnel.
+ 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
+ describes a set of relaxed requirements for a TMCE GRE-in-UDP tunnel
+ used in a traffic-managed controlled environment. Both Sections
+ 2.1.1 and 2.1.2 are applicable to an IPv4 or IPv6 delivery network.
+
+
+
+Yong, et al. Standards Track [Page 6]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+2.1.1. Requirements for Default GRE-in-UDP Tunnel
+
+ The following is a summary of the default GRE-in-UDP tunnel
+ requirements:
+
+ 1. A UDP checksum SHOULD be used when encapsulating in IPv4.
+
+ 2. A UDP checksum MUST be used when encapsulating in IPv6.
+
+ 3. GRE-in-UDP tunnel MUST NOT be deployed or configured to carry
+ traffic that is not congestion controlled. As stated in
+ [RFC8085], IP-based unicast traffic is generally assumed to be
+ congestion controlled, i.e., it is assumed that the transport
+ protocols generating IP-based traffic at the sender already
+ employ mechanisms that are sufficient to address congestion on
+ the path. A default GRE-in-UDP tunnel is not appropriate for
+ traffic that is not known to be congestion controlled (e.g., most
+ IP multicast traffic).
+
+ 4. UDP source port values that are used as a source of flow entropy
+ SHOULD be chosen from the ephemeral port range (49152-65535)
+ [RFC8085].
+
+ 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
+ disables use of the UDP source port to provide flow entropy).
+ When a single value is set, a random port taken from the
+ ephemeral port range SHOULD be selected in order to minimize the
+ vulnerability to off-path attacks [RFC6056].
+
+ 6. For IPv6 delivery networks, the flow entropy SHOULD also be
+ placed in the flow label field for ECMP per [RFC6438].
+
+ 7. At the tunnel ingress, any fragmentation of the incoming packet
+ (e.g., because the tunnel has a Maximum Transmission Unit (MTU)
+ that is smaller than the packet) SHOULD be performed before
+ encapsulation. In addition, the tunnel ingress MUST apply the
+ UDP checksum to all encapsulated fragments so that the tunnel
+ egress can validate reassembly of the fragments; it MUST set the
+ same Differentiated Services Code Point (DSCP) value as in the
+ Differentiated Services (DS) field of the payload packet in all
+ fragments [RFC2474]. To avoid unwanted forwarding over multiple
+ paths, the same source UDP port value SHOULD be set in all packet
+ fragments.
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 7]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+2.1.2. Requirements for TMCE GRE-in-UDP Tunnel
+
+ The section contains the TMCE GRE-in-UDP tunnel requirements. It
+ lists the changed requirements, compared with a Default GRE-in-UDP
+ tunnel, for a TMCE GRE-in-UDP tunnel, which corresponds to
+ requirements 1-3 listed in Section 2.1.1.
+
+ 1. A UDP checksum SHOULD be used when encapsulating in IPv4. A
+ tunnel endpoint sending GRE-in-UDP MAY disable the UDP checksum,
+ since GRE has been designed to work without a UDP checksum
+ [RFC2784]. However, a checksum also offers protection from
+ misdelivery to another port.
+
+ 2. Use of the UDP checksum MUST be the default when encapsulating in
+ IPv6. This default MAY be overridden via configuration of UDP
+ zero-checksum mode. All usage of UDP zero-checksum mode with
+ IPv6 is subject to the additional requirements specified in
+ Section 6.2.
+
+ 3. A GRE-in-UDP tunnel MAY encapsulate traffic that is not
+ congestion controlled.
+
+ Requirements 4-7 listed in Section 2.1.1 also apply to a TMCE GRE-in-
+ UDP tunnel.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 8]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+3. GRE-in-UDP Encapsulation
+
+ The GRE-in-UDP encapsulation format contains a UDP header [RFC768]
+ and a GRE header [RFC2890]. The format is shown as follows
+ (presented in bit order):
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+ IPv4 Header:
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| IHL |Type of Service| Total Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identification |Flags| Fragment Offset |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time to Live | Prot.=17(UDP) | Header Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source IPv4 Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination IPv4 Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ UDP Header:
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Port = Entropy Value | Dest. Port = 4754/4755 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | UDP Length | UDP Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ GRE Header:
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |C| |K|S| Reserved0 | Ver | Protocol Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Checksum (optional) | Reserved1 (Optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key (optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence Number (optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: UDP + GRE Headers in IPv4
+
+
+
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 9]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+ IPv6 Header:
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| Traffic Class | Flow Label |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Payload Length | NxtHdr=17(UDP)| Hop Limit |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Outer Source IPv6 Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Outer Destination IPv6 Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ UDP Header:
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Port = entropy value | Dest. Port = 4754/4755 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | UDP Length | UDP Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ GRE Header:
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |C| |K|S| Reserved0 | Ver | Protocol Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Checksum (optional) | Reserved1 (Optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key (optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence Number (optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2: UDP + GRE Headers in IPv6
+
+ The contents of the IP, UDP, and GRE headers that are relevant in
+ this encapsulation are described below.
+
+
+
+Yong, et al. Standards Track [Page 10]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+3.1. IP Header
+
+ An encapsulator MUST encode its own IP address as the source IP
+ address and the decapsulator's IP address as the destination IP
+ address. A sufficiently large value is needed in the IPv4 TTL field
+ or IPv6 Hop Count field to allow delivery of the encapsulated packet
+ to the peer of the encapsulation.
+
+3.2. UDP Header
+
+3.2.1. Source Port
+
+ GRE-in-UDP permits the UDP source port value to be used to encode an
+ entropy value. The UDP source port contains a 16-bit entropy value
+ that is generated by the encapsulator to identify a flow for the
+ encapsulated packet. The port value SHOULD be within the ephemeral
+ port range, i.e., 49152 to 65535, where the high-order two bits of
+ the port are set to one. This provides fourteen bits of entropy for
+ the inner flow identifier. In the case that an encapsulator is
+ unable to derive flow entropy from the payload header or the entropy
+ usage has to be disabled to meet operational requirements (see
+ Section 7), to avoid reordering with a packet flow, the encapsulator
+ SHOULD use the same UDP source port value for all packets assigned to
+ a flow, e.g., the result of an algorithm that performs a hash of the
+ tunnel ingress and egress IP address.
+
+ The source port value for a flow set by an encapsulator MAY change
+ over the lifetime of the encapsulated flow. For instance, an
+ encapsulator may change the assignment for Denial-of-Service (DoS)
+ mitigation or as a means to effect routing through the ECMP network.
+ An encapsulator SHOULD NOT change the source port selected for a flow
+ more than once every thirty seconds.
+
+ An IPv6 GRE-in-UDP tunnel endpoint SHOULD copy a flow entropy value
+ in the IPv6 flow label field (requirement 6). This permits network
+ equipment to inspect this value and utilize it during forwarding,
+ e.g., to perform ECMP [RFC6438].
+
+ This document places requirements on the generation of the flow
+ entropy value [RFC8085] but does not specify the algorithm that an
+ implementation should use to derive this value.
+
+3.2.2. Destination Port
+
+ The destination port of the UDP header is set to either GRE-in-UDP
+ (4754) or GRE-UDP-DTLS (4755); see Section 5.
+
+
+
+
+
+Yong, et al. Standards Track [Page 11]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+3.2.3. Checksum
+
+ The UDP checksum is set and processed per [RFC768] and [RFC1122] for
+ IPv4 and per [RFC2460] for IPv6. Requirements for checksum handling
+ and use of zero UDP checksums are detailed in Section 6.
+
+3.2.4. Length
+
+ The usage of this field is in accordance with the current UDP
+ specification in [RFC768]. This length will include the UDP header
+ (eight bytes), GRE header, and the GRE payload (encapsulated packet).
+
+3.3. GRE Header
+
+ An encapsulator sets the protocol type (EtherType) of the packet
+ being encapsulated in the GRE Protocol Type field.
+
+ An encapsulator MAY set the GRE Key Present, Sequence Number Present,
+ and Checksum Present bits and associated fields in the GRE header as
+ defined by [RFC2784] and [RFC2890]. Usage of the reserved bits,
+ i.e., Reserved0, is specified in [RFC2784].
+
+ The GRE checksum MAY be enabled to protect the GRE header and
+ payload. When the UDP checksum is enabled, it protects the GRE
+ payload, resulting in the GRE checksum being mostly redundant.
+ Enabling both checksums may result in unnecessary processing. Since
+ the UDP checksum covers the pseudo-header and the packet payload,
+ including the GRE header and its payload, the UDP checksum SHOULD be
+ used in preference to the GRE checksum.
+
+ An implementation MAY use the GRE Key field to authenticate the
+ encapsulator. (See the Security Considerations section.) In this
+ model, a shared value is either configured or negotiated between an
+ encapsulator and decapsulator. When a decapsulator determines that a
+ presented key is not valid for the source, the packet MUST be
+ dropped.
+
+ Although the GRE-in-UDP encapsulation protocol uses both the UDP
+ header and GRE header, it is one tunnel encapsulation protocol. The
+ GRE and UDP headers MUST be applied and removed as a pair at the
+ encapsulation and decapsulation points. This specification does not
+ support UDP encapsulation of a GRE header where that GRE header is
+ applied or removed at a network node other than the UDP tunnel
+ ingress or egress.
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 12]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+4. Encapsulation Procedures
+
+ The procedures specified in this section apply to both a default GRE-
+ in-UDP tunnel and a TMCE GRE-in-UDP tunnel.
+
+ The GRE-in-UDP encapsulation allows encapsulated packets to be
+ forwarded through "GRE-in-UDP tunnels". The encapsulator MUST set
+ the UDP and GRE headers according to Section 3.
+
+ Intermediate routers, upon receiving these UDP encapsulated packets,
+ could load-balance these packets based on the hash of the five-tuple
+ of UDP packets.
+
+ Upon receiving these UDP encapsulated packets, the decapsulator
+ decapsulates them by removing the UDP and GRE headers and then
+ processes them accordingly.
+
+ GRE-in-UDP can encapsulate traffic with unicast, IPv4 broadcast, or
+ 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 between the
+ encapsulated multicast traffic and the multicast capability in the IP
+ network is transparent and independent of the encapsulation and is
+ otherwise outside the scope of this document.
+
+ To provide entropy for ECMP, GRE-in-UDP does not rely on GRE keep-
+ alive. It is RECOMMENDED not to use GRE keep-alive in the GRE-in-UDP
+ tunnel. This aligns with middlebox traversal guidelines in
+ Section 3.5 of [RFC8085].
+
+4.1. MTU and Fragmentation
+
+ Regarding packet fragmentation, an encapsulator/decapsulator SHOULD
+ perform fragmentation before the encapsulation. The size of
+ fragments SHOULD be less than or equal to the Path MTU (PMTU)
+ associated with the path between the GRE ingress and the GRE egress
+ tunnel endpoints minus the GRE and UDP overhead, assuming the egress
+ MTU for reassembled packets is larger than the PMTU. When applying
+ payload fragmentation, the UDP checksum MUST be used so that the
+ receiving endpoint can validate reassembly of the fragments; the same
+ source UDP port SHOULD be used for all packet fragments to ensure the
+ transit routers will forward the fragments on the same path.
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 13]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ If the operator of the transit network supporting the tunnel is able
+ to control the payload MTU size, the MTU SHOULD be configured to
+ avoid fragmentation, i.e., sufficient for the largest supported size
+ of packet, including all additional bytes introduced by the tunnel
+ overhead [RFC8085].
+
+4.2. Differentiated Services and ECN Marking
+
+ To ensure that tunneled traffic receives the same treatment over the
+ IP network as traffic that is not tunneled, prior to the
+ encapsulation process, an encapsulator processes the tunneled IP
+ packet headers to retrieve appropriate parameters for the
+ encapsulating IP packet header such as Diffserv [RFC2983].
+ Encapsulation endpoints that support Explicit Congestion Notification
+ (ECN) must use the method described in [RFC6040] for ECN marking
+ propagation. The congestion control process is outside of the scope
+ of this document.
+
+ Additional information on IP header processing is provided in
+ Section 3.1.
+
+5. Use of DTLS
+
+ Datagram Transport Layer Security (DTLS) [RFC6347] can be used for
+ application security and can preserve network- and transport-layer
+ protocol information. Specifically, if DTLS is used to secure the
+ GRE-in-UDP tunnel, the destination port of the UDP header MUST be set
+ to the IANA-assigned value (4755) indicating GRE-in-UDP with DTLS,
+ and that UDP port MUST NOT be used for other traffic. The UDP source
+ port field can still be used to add entropy, e.g., for load-sharing
+ purposes. DTLS applies to a default GRE-in-UDP tunnel and a TMCE
+ GRE-in-UDP tunnel.
+
+ Use of DTLS is limited to a single DTLS session for any specific
+ tunnel encapsulator/decapsulator pair (identified by source and
+ destination IP addresses). Both IP addresses MUST be unicast
+ addresses -- multicast traffic is not supported when DTLS is used. A
+ GRE-in-UDP tunnel decapsulator that supports DTLS is expected to be
+ able to establish DTLS sessions with multiple tunnel encapsulators,
+ and likewise a GRE-in-UDP tunnel encapsulator is expected to be able
+ to establish DTLS sessions with multiple decapsulators. Different
+ source and/or destination IP addresses will be involved; see
+ Section 6.2 for discussion of one situation where use of different
+ source IP addresses is important.
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 14]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ When DTLS is used for a GRE-in-UDP tunnel, if a packet is received
+ from the tunnel and that packet is not protected by the DTLS session
+ or part of DTLS negotiation (e.g., a DTLS handshake message
+ [RFC6347]), the tunnel receiver MUST discard that packet and SHOULD
+ log that discard event and information about the discarded packet.
+
+ DTLS SHOULD be used for a GRE-in-UDP tunnel to meet security
+ requirements of the original traffic that is delivered by a GRE-in-
+ UDP tunnel. There are cases where no additional security is
+ required, e.g., the traffic to be encapsulated is already encrypted
+ or the tunnel is deployed within an operationally secured network.
+ Use of DTLS for a GRE-in-UDP tunnel requires both tunnel endpoints to
+ configure use of DTLS.
+
+6. UDP Checksum Handling
+
+6.1. UDP Checksum with IPv4
+
+ For UDP in IPv4, when a non-zero UDP checksum is used, the UDP
+ checksum MUST be processed as specified in [RFC768] and [RFC1122] for
+ both transmit and receive. The IPv4 header includes a checksum that
+ protects against misdelivery of the packet due to corruption of IP
+ addresses. The UDP checksum potentially provides protection against
+ corruption of the UDP header, GRE header, and GRE payload. Disabling
+ the use of checksums is a deployment consideration that should take
+ into account the risk and effects of packet corruption.
+
+ When a decapsulator receives a packet, the UDP checksum field MUST be
+ processed. If the UDP checksum is non-zero, the decapsulator MUST
+ verify the checksum before accepting the packet. By default, a
+ decapsulator SHOULD accept UDP packets with a zero checksum. A node
+ MAY be configured to disallow zero checksums per [RFC1122]; this may
+ be done selectively, for instance, disallowing zero checksums from
+ certain hosts that are known to be sending over paths subject to
+ packet corruption. If verification of a non-zero checksum fails, a
+ decapsulator lacks the capability to verify a non-zero checksum, or a
+ packet with a zero checksum was received and the decapsulator is
+ configured to disallow, the packet MUST be dropped and an event MAY
+ be logged.
+
+6.2. UDP Checksum with IPv6
+
+ For UDP in IPv6, the UDP checksum MUST be processed as specified in
+ [RFC768] and [RFC2460] for both transmit and receive.
+
+ When UDP is used over IPv6, the UDP checksum is relied upon to
+ protect both the IPv6 and UDP headers from corruption. As such, a
+ default GRE-in-UDP tunnel MUST perform UDP checksum; a TMCE GRE-in-
+
+
+
+Yong, et al. Standards Track [Page 15]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ UDP tunnel MAY be configured with UDP zero-checksum mode if the
+ traffic-managed controlled environment or a set of closely
+ cooperating traffic-managed controlled environments (such as by
+ network operators who have agreed to work together in order to
+ jointly provide specific services) meet at least one of the following
+ conditions:
+
+ a. It is known (perhaps through knowledge of equipment types and
+ lower-layer checks) that packet corruption is exceptionally
+ unlikely and where the operator is willing to take the risk of
+ undetected packet corruption.
+
+ b. It is judged through observational measurements (perhaps of
+ historic or current traffic flows that use a non-zero checksum)
+ that the level of packet corruption is tolerably low and where
+ the operator is willing to take the risk of undetected packet
+ corruption.
+
+ c. Carrying applications that are tolerant of misdelivered or
+ corrupted packets (perhaps through higher-layer checksum,
+ validation, and retransmission or transmission redundancy) where
+ the operator is willing to rely on the applications using the
+ tunnel to survive any corrupt packets.
+
+ The following requirements apply to a TMCE GRE-in-UDP tunnel that
+ uses UDP zero-checksum mode:
+
+ a. Use of the UDP checksum with IPv6 MUST be the default
+ configuration of all GRE-in-UDP tunnels.
+
+ b. The GRE-in-UDP tunnel implementation MUST comply with all
+ requirements specified in Section 4 of [RFC6936] and with
+ requirement 1 specified in Section 5 of [RFC6936].
+
+ c. The tunnel decapsulator SHOULD only allow the use of UDP zero-
+ checksum mode for IPv6 on a single received UDP Destination Port,
+ regardless of the encapsulator. The motivation for this
+ requirement is possible corruption of the UDP Destination Port,
+ which may cause packet delivery to the wrong UDP port. If that
+ other UDP port requires the UDP checksum, the misdelivered packet
+ will be discarded.
+
+ d. It is RECOMMENDED that the UDP zero-checksum mode for IPv6 is
+ only enabled for certain selected source addresses. The tunnel
+ decapsulator MUST check that the source and destination IPv6
+ addresses are valid for the GRE-in-UDP tunnel on which the packet
+ was received if that tunnel uses UDP zero-checksum mode and
+ discard any packet for which this check fails.
+
+
+
+Yong, et al. Standards Track [Page 16]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ e. The tunnel encapsulator SHOULD use different IPv6 addresses for
+ each GRE-in-UDP tunnel that uses UDP zero-checksum mode,
+ regardless of the decapsulator, in order to strengthen the
+ decapsulator's check of the IPv6 source address (i.e., the same
+ IPv6 source address SHOULD NOT be used with more than one IPv6
+ destination address, independent of whether that destination
+ address is a unicast or multicast address). When this is not
+ possible, it is RECOMMENDED to use each source IPv6 address for
+ as few GRE-in-UDP tunnels that use UDP zero-checksum mode as is
+ feasible.
+
+ f. When any middlebox exists on the path of a GRE-in-UDP tunnel, it
+ is RECOMMENDED to use the default mode, i.e., use UDP checksum,
+ to reduce the chance that the encapsulated packets will be
+ dropped.
+
+ g. Any middlebox that allows the UDP zero-checksum mode for IPv6
+ MUST comply with requirements 1 and 8-10 in Section 5 of
+ [RFC6936].
+
+ h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP
+ checksums from "escaping" to the general Internet; see Section 8
+ for examples of such measures.
+
+ i. IPv6 traffic with zero UDP checksums MUST be actively monitored
+ for errors by the network operator. For example, the operator
+ may monitor Ethernet-layer packet error rates.
+
+ j. If a packet with a non-zero checksum is received, the checksum
+ MUST be verified before accepting the packet. This is regardless
+ of whether the tunnel encapsulator and decapsulator have been
+ configured with UDP zero-checksum mode.
+
+ The above requirements do not change either the requirements
+ specified in [RFC2460] as modified by [RFC6935] or the requirements
+ specified in [RFC6936].
+
+ The requirement to check the source IPv6 address in addition to the
+ destination IPv6 address and the strong recommendation against reuse
+ of source IPv6 addresses among GRE-in-UDP tunnels collectively
+ provide some mitigation for the absence of UDP checksum coverage of
+ the IPv6 header. A traffic-managed controlled environment that
+ satisfies at least one of three conditions listed at the beginning of
+ this section provides additional assurance.
+
+ A GRE-in-UDP tunnel is suitable for transmission over lower layers in
+ the traffic-managed controlled environments that are allowed by the
+ exceptions stated above, and the rate of corruption of the inner IP
+
+
+
+Yong, et al. Standards Track [Page 17]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ packet on such networks is not expected to increase by comparison to
+ GRE traffic that is not encapsulated in UDP. For these reasons, GRE-
+ in-UDP does not provide an additional integrity check except when GRE
+ checksum is used when UDP zero-checksum mode is used with IPv6, and
+ this design is in accordance with requirements 2, 3, and 5 specified
+ in Section 5 of [RFC6936].
+
+ Generic Router Encapsulation (GRE) does not accumulate incorrect
+ transport-layer state as a consequence of GRE header corruption. A
+ corrupt GRE packet may result in either packet discard or packet
+ forwarding without accumulation of GRE state. Active monitoring of
+ GRE-in-UDP traffic for errors is REQUIRED, as the occurrence of
+ errors will result in some accumulation of error information outside
+ the protocol for operational and management purposes. This design is
+ in accordance with requirement 4 specified in Section 5 of [RFC6936].
+
+ The remaining requirements specified in Section 5 of [RFC6936] are
+ not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply
+ because GRE does not include a control feedback mechanism.
+ Requirements 8-10 are middlebox requirements that do not apply to
+ GRE-in-UDP tunnel endpoints. (See Section 7.1 for further middlebox
+ discussion.)
+
+ It is worth mentioning that the use of a zero UDP checksum should
+ present the equivalent risk of undetected packet corruption when
+ sending a similar packet using GRE-in-IPv6 without UDP [RFC7676] and
+ without GRE checksums.
+
+ In summary, a TMCE GRE-in-UDP tunnel is allowed to use UDP zero-
+ checksum mode for IPv6 when the conditions and requirements stated
+ above are met. Otherwise, the UDP checksum needs to be used for IPv6
+ as specified in [RFC768] and [RFC2460]. Use of GRE checksum is
+ RECOMMENDED when the UDP checksum is not used.
+
+7. Middlebox Considerations
+
+ Many middleboxes read or update UDP port information of the packets
+ that they forward. Network Address Port Translator (NAPT) is the
+ most commonly deployed Network Address Translation (NAT) device
+ [RFC4787]. A NAPT device establishes a NAT session to translate the
+ {private IP address, private source port number} tuple to a {public
+ IP address, public source port number} tuple, and vice versa, for the
+ duration of the UDP session. This provides a UDP application with
+ the "NAT pass-through" function. NAPT allows multiple internal hosts
+ to share a single public IP address. The port number, i.e., the UDP
+ Source Port number, is used as the demultiplexer of the multiple
+
+
+
+
+
+Yong, et al. Standards Track [Page 18]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ internal hosts. However, the above NAPT behaviors conflict with the
+ behavior of a GRE-in-UDP tunnel that is configured to use the UDP
+ source port value to provide entropy.
+
+ A GRE-in-UDP tunnel is unidirectional; the tunnel traffic is not
+ expected to be returned back to the UDP source port values used to
+ generate entropy. However, some middleboxes (e.g., firewalls) assume
+ that bidirectional traffic uses a common pair of UDP ports. This
+ assumption also conflicts with the use of the UDP source port field
+ as entropy.
+
+ 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
+ with a middlebox, the tunnel can be configured either to disable use
+ of the UDP source port for entropy or to enable middleboxes to pass
+ packets with UDP source port entropy.
+
+7.1. Middlebox Considerations for Zero Checksums
+
+ IPv6 datagrams with a zero UDP checksum will not be passed by any
+ middlebox that updates the UDP checksum field or simply validates the
+ checksum based on [RFC2460], such as firewalls. Changing this
+ behavior would require such middleboxes to be updated to correctly
+ handle datagrams with zero UDP checksums. The GRE-in-UDP
+ encapsulation does not provide a mechanism to safely fall back to
+ using a checksum when a path change occurs that redirects a tunnel
+ over 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-holed by that middlebox.
+
+ As such, when any middlebox exists on the path of a GRE-in-UDP
+ tunnel, use of the UDP checksum is RECOMMENDED to increase the
+ probability of successful transmission of GRE-in-UDP packets.
+ Recommended changes to allow firewalls and other middleboxes to
+ support use of an IPv6 zero UDP checksum are described in Section 5
+ of [RFC6936].
+
+8. Congestion Considerations
+
+ Section 3.1.9 of [RFC8085] discusses the congestion considerations
+ for design and use of UDP tunnels; this is important because other
+ flows could share the path with one or more UDP tunnels,
+ necessitating congestion control [RFC2914] to avoid destructive
+ interference.
+
+ Congestion has potential impacts both on the rest of the network
+ containing a UDP tunnel and on the traffic flows using the UDP
+ tunnels. These impacts depend upon what sort of traffic is carried
+
+
+
+Yong, et al. Standards Track [Page 19]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ over the tunnel, as well as the path of the tunnel. The GRE-in-UDP
+ tunnel protocol does not provide any congestion control and GRE-in-
+ UDP packets are regular UDP packets. Therefore, a GRE-in-UDP tunnel
+ MUST NOT be deployed to carry non-congestion-controlled traffic over
+ the Internet [RFC8085].
+
+ Within a TMCE network, GRE-in-UDP tunnels are appropriate for
+ carrying traffic that is not known to be congestion controlled. For
+ example, a GRE-in-UDP tunnel may be used to carry Multiprotocol Label
+ Switching (MPLS) traffic such as pseudowires or VPNs where specific
+ bandwidth guarantees are provided to each pseudowire or VPN. In such
+ cases, operators of TMCE networks avoid congestion by careful
+ provisioning of their networks, rate-limiting of user data traffic,
+ and traffic engineering according to path capacity.
+
+ When a GRE-in-UDP tunnel carries traffic that is not known to be
+ congestion controlled in a TMCE network, the tunnel MUST be deployed
+ entirely within that network, and measures SHOULD be taken to prevent
+ the GRE-in-UDP traffic from "escaping" the network to the general
+ Internet. Examples of such measures are:
+
+ o physical or logical isolation of the links carrying GRE-in-UDP
+ from the general Internet,
+
+ o deployment of packet filters that block the UDP ports assigned for
+ GRE-in-UDP, and
+
+ o imposition of restrictions on GRE-in-UDP traffic by software tools
+ used to set up GRE-in-UDP tunnels between specific end systems (as
+ might be used within a single data center) or by tunnel ingress
+ nodes for tunnels that don't terminate at end systems.
+
+9. Backward Compatibility
+
+ In general, tunnel ingress routers have to be upgraded in order to
+ support the encapsulations described in this document.
+
+ No change is required at transit routers to support forwarding of the
+ encapsulation described in this document.
+
+ If a tunnel endpoint (a host or router) that is intended for use as a
+ decapsulator does not support or enable the GRE-in-UDP encapsulation
+ described in this document, that endpoint will not listen on the
+ destination port assigned to the GRE-encapsulation (4754 and 4755).
+ In these cases, the endpoint will perform normal UDP processing and
+ respond to an encapsulator with an ICMP message indicating "port
+
+
+
+
+
+Yong, et al. Standards Track [Page 20]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ unreachable" according to [RFC792]. Upon receiving this ICMP
+ message, the node MUST NOT continue to use GRE-in-UDP encapsulation
+ toward this peer without management intervention.
+
+10. IANA Considerations
+
+ IANA has allocated the following UDP destination port number for the
+ indication of GRE:
+
+ Service Name: GRE-in-UDP
+ Transport Protocol(s): UDP
+ Assignee: IESG <iesg@ietf.org>
+ Contact: IETF Chair <chair@ietf.org>
+ Description: GRE-in-UDP Encapsulation
+ Reference: RFC 8086
+ Port Number: 4754
+ Service Code: N/A
+ Known Unauthorized Uses: N/A
+ Assignment Notes: N/A
+
+ IANA has allocated the following UDP destination port number for the
+ indication of GRE with DTLS:
+
+ Service Name: GRE-UDP-DTLS
+ Transport Protocol(s): UDP
+ Assignee: IESG <iesg@ietf.org>
+ Contact: IETF Chair <chair@ietf.org>
+ Description: GRE-in-UDP Encapsulation with DTLS
+ Reference: RFC 8086
+ Port Number: 4755
+ Service Code: N/A
+ Known Unauthorized Uses: N/A
+ Assignment Notes: N/A
+
+11. Security Considerations
+
+ GRE-in-UDP encapsulation does not affect security for the payload
+ protocol. The security considerations for GRE apply to GRE-in-UDP;
+ see [RFC2784].
+
+ To secure traffic carried by a GRE-in-UDP tunnel, DTLS SHOULD be used
+ as specified in Section 5.
+
+ In the case that UDP source port for entropy usage is disabled, a
+ random port taken from the ephemeral port range SHOULD be selected in
+ order to minimize the vulnerability to off-path attacks [RFC6056].
+ The random port may also be periodically changed to mitigate certain
+ DoS attacks as mentioned in Section 3.2.1.
+
+
+
+Yong, et al. Standards Track [Page 21]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ Using one standardized value as the UDP destination port to indicate
+ an encapsulation may increase the vulnerability to off-path attacks.
+ To overcome this, an alternate port may be agreed upon to use between
+ an encapsulator and decapsulator [RFC6056]. How the encapsulator
+ endpoints communicate the value is outside the scope of this
+ document.
+
+ This document does not require that a decapsulator validate the IP
+ source address of the tunneled packets (with the exception that the
+ 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
+ presupposes that there is effective destination-based filtering (or a
+ combination of source-based and destination-based filtering) at the
+ boundaries.
+
+ Corruption of GRE headers can cause security concerns for
+ applications that rely on the GRE Key field for traffic separation or
+ segregation. When the GRE Key field is used for this purpose, such
+ as an application of a Network Virtualization Using Generic Routing
+ Encapsulation (NVGRE) [RFC7637], GRE header corruption is a concern.
+ In such situations, at least one of the UDP and GRE checksums MUST be
+ used for both IPv4 and IPv6 GRE-in-UDP tunnels.
+
+12. References
+
+12.1. Normative References
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ DOI 10.17487/RFC0768, August 1980,
+ <http://www.rfc-editor.org/info/rfc768>.
+
+ [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122,
+ DOI 10.17487/RFC1122, October 1989,
+ <http://www.rfc-editor.org/info/rfc1122>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
+ "Definition of the Differentiated Services Field (DS
+ Field) in the IPv4 and IPv6 Headers", RFC 2474,
+ DOI 10.17487/RFC2474, December 1998,
+ <http://www.rfc-editor.org/info/rfc2474>.
+
+
+
+
+
+Yong, et al. Standards Track [Page 22]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+ Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
+ DOI 10.17487/RFC2784, March 2000,
+ <http://www.rfc-editor.org/info/rfc2784>.
+
+ [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
+ RFC 2890, DOI 10.17487/RFC2890, September 2000,
+ <http://www.rfc-editor.org/info/rfc2890>.
+
+ [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
+ Notification", RFC 6040, DOI 10.17487/RFC6040, November
+ 2010, <http://www.rfc-editor.org/info/rfc6040>.
+
+ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
+ January 2012, <http://www.rfc-editor.org/info/rfc6347>.
+
+ [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
+ for Equal Cost Multipath Routing and Link Aggregation in
+ Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
+ <http://www.rfc-editor.org/info/rfc6438>.
+
+ [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
+ UDP Checksums for Tunneled Packets", RFC 6935,
+ DOI 10.17487/RFC6935, April 2013,
+ <http://www.rfc-editor.org/info/rfc6935>.
+
+ [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
+ for the Use of IPv6 UDP Datagrams with Zero Checksums",
+ RFC 6936, DOI 10.17487/RFC6936, April 2013,
+ <http://www.rfc-editor.org/info/rfc6936>.
+
+ [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
+ Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
+ March 2017, <http://www.rfc-editor.org/info/rfc8085>.
+
+12.2. Informative References
+
+ [RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
+ RFC 792, DOI 10.17487/RFC0792, September 1981,
+ <http://www.rfc-editor.org/info/rfc792>.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, DOI 10.17487/RFC0793, September 1981,
+ <http://www.rfc-editor.org/info/rfc793>.
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 23]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+ December 1998, <http://www.rfc-editor.org/info/rfc2460>.
+
+ [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
+ RFC 2914, DOI 10.17487/RFC2914, September 2000,
+ <http://www.rfc-editor.org/info/rfc2914>.
+
+ [RFC2983] Black, D., "Differentiated Services and Tunnels",
+ RFC 2983, DOI 10.17487/RFC2983, October 2000,
+ <http://www.rfc-editor.org/info/rfc2983>.
+
+ [RFC4787] Audet, F., Ed., and C. Jennings, "Network Address
+ Translation (NAT) Behavioral Requirements for Unicast
+ UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
+ 2007, <http://www.rfc-editor.org/info/rfc4787>.
+
+ [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
+ Protocol Port Randomization", BCP 156, RFC 6056,
+ DOI 10.17487/RFC6056, January 2011,
+ <http://www.rfc-editor.org/info/rfc6056>.
+
+ [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
+ IETF Protocol and Documentation Usage for IEEE 802
+ Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
+ October 2013, <http://www.rfc-editor.org/info/rfc7042>.
+
+ [RFC7637] Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network
+ Virtualization Using Generic Routing Encapsulation",
+ RFC 7637, DOI 10.17487/RFC7637, September 2015,
+ <http://www.rfc-editor.org/info/rfc7637>.
+
+ [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
+ for Generic Routing Encapsulation (GRE)", RFC 7676,
+ DOI 10.17487/RFC7676, October 2015,
+ <http://www.rfc-editor.org/info/rfc7676>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 24]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+Acknowledgements
+
+ The authors would like to thank Vivek Kumar, Ron Bonica, Joe Touch,
+ Ruediger Geib, Lars Eggert, Lloyd Wood, Bob Briscoe, Rick Casarez,
+ Jouni Korhonen, Kathleen Moriarty, Ben Campbell, and many others for
+ their reviews and valuable input on this document.
+
+ Thanks to Donald Eastlake, Eliot Lear, Martin Stiemerling, and
+ Spencer Dawkins for their detailed reviews and valuable suggestions
+ during WG Last Call and the IESG process.
+
+ Thanks to the design team led by David Black (members: Ross Callon,
+ Gorry Fairhurst, Xiaohu Xu, and Lucy Yong) for efficiently working
+ out the descriptions for the congestion considerations and IPv6 UDP
+ zero checksum.
+
+ Thanks to David Black and Gorry Fairhurst for their great help in
+ document content and editing.
+
+Contributors
+
+ The following people all contributed significantly to this document
+ and are listed in alphabetical order:
+
+ David Black
+ EMC Corporation
+ 176 South Street
+ Hopkinton, MA 01748
+ United States of America
+
+ Email: david.black@emc.com
+
+
+ Ross Callon
+ Juniper Networks
+ 10 Technology Park Drive
+ Westford, MA 01886
+ United States of America
+
+ Email: rcallon@juniper.net
+
+
+ John E. Drake
+ Juniper Networks
+
+ Email: jdrake@juniper.net
+
+
+
+
+
+Yong, et al. Standards Track [Page 25]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+ Gorry Fairhurst
+ University of Aberdeen
+
+ Email: gorry@erg.abdn.ac.uk
+
+
+ Yongbing Fan
+ China Telecom
+ Guangzhou
+ China
+
+ Email: fanyb@gsta.com
+ Phone: +86 20 38639121
+
+
+ Adrian Farrel
+ Juniper Networks
+
+ Email: adrian@olddog.co.uk
+
+
+ Vishwas Manral
+
+ Email: vishwas@ionosnetworks.com
+
+
+ Carlos Pignataro
+ Cisco Systems
+ 7200-12 Kit Creek Road
+ Research Triangle Park, NC 27709
+ United States of America
+
+ Email: cpignata@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 26]
+
+RFC 8086 GRE-in-UDP Encapsulation March 2017
+
+
+Authors' Addresses
+
+ Lucy Yong
+ Huawei Technologies, USA
+
+ Email: lucy.yong@huawei.com
+
+
+ Edward Crabbe
+ Oracle
+
+ Email: edward.crabbe@gmail.com
+
+
+ Xiaohu Xu
+ Huawei Technologies
+ Beijing, China
+
+ Email: xuxiaohu@huawei.com
+
+
+ Tom Herbert
+ Facebook
+ 1 Hacker Way
+ Menlo Park, CA
+
+ Email: tom@herbertland.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yong, et al. Standards Track [Page 27]
+