draft-ietf-tsvwg-gre-in-udp-encap-08.txt   draft-ietf-tsvwg-gre-in-udp-encap-09.txt 
Network Working Group E. Crabbe Network Working Group E. Crabbe
Internet-Draft Internet-Draft
Intended status: Standard Track L. Yong Intended status: Standard Track L. Yong
Huawei USA Huawei USA
X. Xu X. Xu
Huawei Technologies Huawei Technologies
T. Herbert T. Herbert
Google Google
Expires: April 2016 October 16, 2015 Expires: July 2016 January 26, 2016
GRE-in-UDP Encapsulation GRE-in-UDP Encapsulation
draft-ietf-tsvwg-gre-in-udp-encap-08 draft-ietf-tsvwg-gre-in-udp-encap-09
Abstract Abstract
This document describes a method of encapsulating network protocol This document describes a method of encapsulating network protocol
packets within GRE and UDP headers. In this encapsulation, the packets within GRE and UDP headers. In this encapsulation, the
source UDP port can be used as an entropy field for purposes of load source UDP port can be used as an entropy field for purposes of load
balancing, while the protocol of the encapsulated packet in the GRE balancing, while the protocol of the encapsulated packet in the GRE
payload is identified by the GRE Protocol Type. This encapsulation payload is identified by the GRE Protocol Type. This document
protocol can apply to IPv4 and IPv6 networks including the Internet. specifies requirements for two applicability scenarios for this
When applying it to a well-managed operator network, the tunnel encapsulation: (1) General Internet and (2) well-managed operator
implementation and usage can be less restrictive. The document networks; less restrictive requirements apply to the latter scenario
specifies the tunnel implementations under both network scenarios. by comparison to the former.
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 April 16,2016. This Internet-Draft will expire on July 26,2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ........................................... 3 1. Introduction...................................................3
1.1. Applicability Statement .............................. 3 1.1. Applicability Statement...................................4
1.1.1. Requirements for Default GRE-in-UDP Tunnel 1.2. GRE-in-UDP Tunnel Usage Requirements......................4
Implementation over the Internet........................ 5 1.2.1. Requirements for Default GRE-in-UDP Tunnel...........5
1.1.2. Requirements for Conditional GRE-in-UDP Tunnel 1.2.2. Requirements Changes for WMON GRE-in-UDP Tunnel......5
Implementation over a Well-Managed Operator Network..... 6 2. Terminology....................................................6
2. Terminology ............................................... 7 2.1. Requirements Language.....................................6
2.1. Requirements Language................................. 7 3. Encapsulation in UDP...........................................6
3. Encapsulation in UDP ...................................... 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.....................................9
3.2.2. Destination Port ............................... 10 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 ......................... 11 4.1. MTU and Fragmentation....................................11
4.1. MTU and Fragmentation ............................... 12 4.2. Middlebox Considerations.................................12
4.2. Differentiated Services ............................. 13 4.3. Differentiated Services and ECN Marking..................12
5. UDP Checksum Handling ................................... 13 5. UDP Checksum Handling.........................................13
5.1. UDP Checksum with IPv4 .............................. 13 5.1. UDP Checksum with IPv4...................................13
5.2. UDP Checksum with IPv6 .............................. 14 5.2. UDP Checksum with IPv6...................................13
5.2.1. Middlebox Considerations ....................... 17 5.2.1. Middlebox Considerations............................16
6. Congestion Considerations ................................ 17 6. Congestion Considerations.....................................17
7. Backward Compatibility .................................. 18 7. Backward Compatibility........................................18
8. IANA Considerations ...................................... 19 8. IANA Considerations...........................................19
9. Security Considerations .................................. 19 9. Security Considerations.......................................19
10. Acknowledgements ...................................... 21 10. Acknowledgements.............................................20
11. Contributors ......................................... 21 11. Contributors.................................................21
12. References .............................................. 22 12. References...................................................22
12.1. Normative References ............................... 22 12.1. Normative References....................................22
12.2. Informative References ............................. 23 12.2. Informative References..................................23
13. Authors' Addresses ...................................... 24 13. Authors' Addresses...........................................24
1. Introduction 1. Introduction
Load balancing, or more specifically statistical multiplexing of Load balancing, or more specifically statistical multiplexing of
traffic using Equal Cost Multi-Path (ECMP) and/or Link Aggregation traffic using Equal Cost Multi-Path (ECMP) and/or Link Aggregation
Groups (LAGs) in IP networks is a widely used technique for creating Groups (LAGs) in IP networks is a widely used technique for creating
higher capacity networks out of lower capacity links. Most existing higher capacity networks out of lower capacity links. Most existing
routers in IP networks are already capable of distributing IP routers in IP networks are already capable of distributing IP
traffic flows over ECMP paths and/or LAGs on the basis of a hash traffic flows over ECMP paths and/or LAGs on the basis of a hash
function performed on flow invariant fields in IP packet headers and function performed on flow invariant fields in IP packet headers and
their payload protocol headers. Specifically, when the IP payload is their payload protocol headers. Specifically, when the IP payload is
a User Datagram Protocol (UDP)[RFC768] or Transmission Control a User Datagram Protocol (UDP)[RFC768] or Transmission Control
Protocol (TCP) [RFC793] packet, router hash functions frequently Protocol (TCP) [RFC793] packet, router hash functions frequently
operate on the five-tuple of source IP address, destination IP operate on the five-tuple of source IP address, destination IP
address, source port, destination port, and protocol/next-header address, source port, destination port, and protocol/next-header
Several encapsulation techniques are commonly used in IP networks, GRE encapsulation has been widely used for many applications. For
such as Generic Routing Encapsulation (GRE) [RFC2784], MPLS example, to redirect IP traffic to traverse a different path instead
[RFC4023] and L2TPv3 [RFC3931]. GRE is an increasingly popular of the default path in an operator network, to tunnel private
encapsulation choice. Unfortunately, use of common GRE endpoints may network traffic over a public network by use of public IP network
reduce the entropy available for use in load balancing, especially addresses, to tunnel IPv6 traffic over an IPv4 network, tunnel
in environments where the GRE Key field [RFC2890] is not readily Ethernet traffic over IP networks [RFC7637], etc. Unfortunately, use
available for use as entropy in forwarding decisions. of common GRE endpoints may reduce the entropy available for use in
load balancing, especially in environments where the GRE Key field
[RFC2890] is not readily available for use as entropy in forwarding
decisions.
This document defines a generic GRE-in-UDP encapsulation for This document defines a generic GRE-in-UDP encapsulation for
tunneling network protocol packets across an IP network. The GRE tunneling network protocol packets across an IP network. The GRE
header provides payload protocol type as an EtherType in the header provides payload protocol type as an EtherType in the
protocol type field [RFC2784][GREIPV6], and the UDP header provides protocol type field [RFC2784][GREIPV6], and the UDP header provides
additional entropy by way of its source port. GRE-in-UDP offers the additional entropy by way of its source port. GRE-in-UDP offers the
additional possibility of using GRE across networks that might additional possibility of using GRE across networks that might
otherwise disallow it; for instance GRE-in-UDP may be used to bridge otherwise disallow it; for instance GRE-in-UDP may be used to bridge
two islands where GRE is used natively across the Internet. two islands where GRE is not used natively across the Internet.
This encapsulation method requires no changes to the transit IP This encapsulation method requires no changes to the transit IP
network. Hash functions in most existing IP routers may utilize and network. Hash functions in most existing IP routers may utilize and
benefit from the use of a GRE-in-UDP tunnel without needing any benefit from the use of a GRE-in-UDP tunnel without needing any
change or upgrade to their ECMP implementation. The encapsulation change or upgrade to their ECMP implementation. The encapsulation
mechanism is applicable to a variety of IP networks including Data mechanism is applicable to a variety of IP networks including Data
Center and wide area networks. Center and wide area networks.
1.1. Applicability Statement GRE-in-UDP encapsulation may be used to encapsulate already tunneled
traffic, i.e. tunnel-in-tunnel. The tunneled traffic may use GRE-in-
UDP or other tunnel encapsulation. In this case, GRE-in-UDP tunnel
endpoints treat other tunnel endpoints as of the end hosts for the
traffic and do not differentiate such end hosts from other end
hosts.
GRE encapsulation has been widely used for many applications. For 1.1. Applicability Statement
example, to redirect IP traffic to traverse a different path instead
of the default path in an operator network, to tunnel private
network traffic over a public network by use of public IP network
addresses, to tunnel IPv6 traffic over an IPv4 network, tunnel
Ethernet traffic over IP networks [RFC7637], etc.
GRE-in-UDP encapsulation applies to IPv4 and IPv6 networks including GRE-in-UDP encapsulation applies to IPv4 and IPv6 networks including
the Internet. When using GRE-in-UDP encapsulation, encapsulated the Internet. When using GRE-in-UDP encapsulation, encapsulated
traffic will be treated as a UDP application in an IP network. As traffic will be treated as a UDP application in an IP network. As
such, GRE-in-UDP tunnel needs to meet UDP application requirements such, GRE-in-UDP tunnel needs to meet UDP requirements specified in
specified in [RFC5405bis], which requires additional tunnel [RFC5405bis], which imposes limits on GRE-in-UDP tunnel usage. These
functions besides the packet encapsulation/decapsulation at the limits may depend on both the network and the nature of the
tunnel endpoints. The required additional functions may be encapsulated traffic. For example, the GRE-in-UDP tunnel protocol
simplified according to the network operation condition. For does not provide any congestion control functionality beyond that of
example, if a GRE-in-UDP tunnel is used to carry IP payload only, the encapsulated traffic. Therefore, GRE-in-UDP MUST be used only
tunnel congestion control function is not necessary. with congestion controlled traffic (e.g., IP traffic) and/or within
a network that has the congestion management.
This document considers two network scenarios: 1) Use of GRE-in-UDP
in a general IP network including the Internet, where a default GRE-
in-UDP tunnel implementation specified in this draft can apply; 2)
Use of GRE-in-UDP in a well-managed operator IP network, where a
GRE-in-UDP tunnel implementation can be less restrictive than the
default implementation. The implementation for a well-managed
operator IP network is specified in this draft too and is referred
to as conditional GRE-in-UDP tunnel implementation in the remaining
document.
A well-managed operator IP network (referred to Operator Network in
the rest) is an IP network that meets at least one of following
conditions:
a. Under single administrative control (such as within a single
operator's network) where 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. Under single administrative control (such as within a single
operator's network) where 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 mis-delivered 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.
As a result, use of GRE-in-UDP within a well-managed operator
network, UDP zero-checksum in IPv6 may be used (see Section 5.2).
Another characteristic that a well-managed operator network often
has is a congestion control, i.e. the network is traffic-engineered
and/or operated to avoid congestion.
GRE-in-UDP tunnel implementation, either default or conditional,
does not have congestion control capability. Therefore, it limits
its usage for either tunneled traffic having congestion control
and/or a well-managed operator network that provides traffic-
engineering to avoid congestion.
As a result, default GRE-in-UDP tunnel implementation MUST NOT apply
to traffic that has no congestion control over the Internet;
conditional GRE-in-UDP tunnel implementation can apply to a well-
managed operator network that provides congestion control. (See
Section 6)
The following two sections summarize the requirements of GRE-in-UDP
tunnel implementation for a generic IP network including the
Internet and a well-managed operator network, respectively. The
networks can be IPv4 or Ipv6.
1.1.1. Requirements for Default GRE-in-UDP Tunnel Implementation [RFC5405bis] considers two types of applicability where IETF
over the Internet applications utilize UDP: 1) General Internet and 2) Controlled
Environment. The controlled environment means within a single
administrative domain or bilaterally agreed connection between
domains. A network under controlled environment can be
managed/operated to meet certain condition(s), which the general
Internet can't. Tunnel protocol requirements under controlled
environment can be less restrictive than the requirements in the
general Internet. This document specifies GRE-in-UDP tunnel usage in
the general Internet and GRE-in-UDP tunnel usage in the well-managed
operator network that is an example of controlled environment.
The following are the requirements for default GRE-in-UDP tunnel For the purpose of this document, a well-managed operator network is
implementation that can apply to an IP network including Internet. defined as an IP network that is traffic-engineered and/or otherwise
managed (e.g., via use of traffic rate limiters) to avoid
congestion.
1. SHOULD perform UDP checksum when over an IPv4 network. This document refers to the GRE-in-UDP tunnel usage in the general
Internet as Default GRE-in-UDP Tunnel; the GRE-in-UDP tunnel usage
in a well-managed operator network as WMON GRE-in-UDP Tunnel.
2. MUST perform UDP checksum when over an IPv6 network. 1.2. GRE-in-UDP Tunnel Usage Requirements
3. IP-traffic can be assumed to be congestion-controlled; other The section summarizes GRE-in-UDP tunnel requirements. The
tunneled protocol/payload SHOULD implement an appropriate congestion requirements for Default GRE-in-UDP tunnel are listed in Section
control method because the GRE/UDP tunnel does not itself provide 1.2.1, which applies to a GRE-in-UDP tunnel over the general
any congestion control. If GRE-in-UDP tunnel MUST NOT to traffic Internet; the relaxed requirements for WMON GRE-in-UDP Tunnel are
that has no congestion control over the general Internet. listed in Section 1.2.2, which applies to a GRE-in-UDP tunnel within
a well-managed operator network. These networks can be IPv4 or IPv6.
4. UDP src port that is used for flow entropy SHOULD be set to a UDP 1.2.1. Requirements for Default GRE-in-UDP Tunnel
ephemeral port (49152-65535).
5. For IPv6 delivery network, if IPv6 flow label load balancing is The following is a summary of the GRE-in-UDP requirements for use
supported [RFC4638], the flow entropy SHOULD also be placed in the over the general Internet:
flow label field.
6. If a tunnel ingress fragments the incoming packet (before 1. UDP checksum SHOULD be used when encapsulating in IPv4.
encapsulation), the UDP checksum MUST be used so that the receiving
endpoint can validate reassembly of the fragments, and the same src
UDP port SHOULD be used for all packet fragments to ensure that the
transit routers will forward the packet fragments on the same path.
7. If the incoming packet needs to be fragmented, it SHOULD be done 2. UDP checksum MUST be used when encapsulating in IPv6.
before the encapsulation [RFC7588] and calculate the size of
fragments based on the MTU and including the size of the UDP header.
1.1.2. Requirements for Conditional GRE-in-UDP Tunnel Implementation 3. GRE-in-UDP tunnel MUST NOT be used for traffic that has no
over a Well-Managed Operator Network congestion control. IP-traffic can be assumed to be congestion-
controlled. GRE-in-UDP tunnels are not appropriate for other traffic
that does not use congestion control.
The following are the requirements for conditional GRE-in-UDP tunnel 4. UDP source port that is used for flow entropy SHOULD be set to a
implementation that can apply to a well-managed IP network described UDP ephemeral port (49152-65535).
above.
1. When over an IPv4 network, SHOULD set UDP zero-checksum to 5. UDP source port usage MUST be configurable so that a single value
improve the tunnel performance. is used for all traffic in the tunnel (this disables use of the UDP
source port to provide flow entropy).
2. When over an IPv6 network, MUST perform UDP checksum as default 6. For IPv6 delivery networks, the flow entropy SHOULD also be
but MAY be configured with UDP zero-checksum with additional placed in the flow label field.
implementation requirements that are specified in Section 5.2.
3. A tunnel may encapsulate a protocol/payload that does not provide 7. At the tunnel ingress, any fragmentation of the incoming packet
congestion control if the delivery network is traffic-engineered (e.g., because the tunnel has an MTU that is smaller than the packet
and/or operated by the network operator to avoid congestion, e.g. SHOULD be performed before encapsulation [RFC7588]. In addition, the
use of pre-provision capacity or utilize a circuit breaker [CK]. tunnel ingress MUST apply the UDP checksum to all encapsulated
fragments so that the tunnel egress can validate reassembly of the
fragments, and SHOULD use the same source UDP port for all packet
fragments to ensure the packet fragments traversing on the same path.
4. UDP src port that is used for flow entropy SHOULD be set to a UDP 1.2.2. Requirements Changes for WMON GRE-in-UDP Tunnel
ephemeral port (49152-65535).
5. For IPv6 delivery network, if IPv6 flow label load balancing is The following lists the changed requirements for WMON GRE-in-UDP
supported [RFC4638], the flow entropy SHOULD also be placed in the Tunnel that is used in a well-managed operator network; they replace
flow label field. requirements 1-3 listed in section 1.2.1. The requirements 4-8 in
that section are unchanged for WMON GRE-in-UDP Tunnel.
6. If a tunnel ingress fragments the incoming packet (before 1. UDP checksum MAY be used when encapsulating in IPv4.
encapsulation), the UDP checksum MUST be used so that the receiving
endpoint can validate reassembly of the fragments, and the same src
UDP port SHOULD be used for all packet fragments to ensure that the
transit routers will forward the packet fragments on the same path.
7. If the incoming packet needs to be fragmented, it SHOULD be done 2. Use of UDP checksum MUST be the default when encapsulating in
before the encapsulation [RFC7588] and calculate the size of IPv6. This default MAY be overridden via configuration of UDP zero-
fragments based on the MTU and including the size of the UDP header. checksum mode. All usage of UDP zero-checksum mode with IPv6 is
subject to the additional requirements specified in Section 5.2.
GRE-in-UDP encapsulation may be used to encapsulate already tunneled 3. GRE-in-UDP tunnel MAY encapsulate traffic that is not congestion
traffic, i.e. tunnel-in-tunnel. The tunneled traffic may use GRE-in- controlled.
UDP or other tunnel encapsulation. In this case, GRE-in-UDP tunnel
endpoints treat other tunnel endpoints as of the end hosts for the
traffic and do not differentiate such end hosts from other end hosts.
2. Terminology 2. Terminology
The terms defined in [RFC768][RFC2784] are used in this document. The terms defined in [RFC768][RFC2784] are used in this document.
Default GRE-in-UDP tunnel implementation: GRE-in-UDP tunnel Default GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can apply to the
implementation that can apply to an IP network including the general Internet.
Internet.
Conditional GRE-in-UDP tunnel implementation: GRE-in-UDP tunnel WMON GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can only apply to a
implementation that can only apply to a well-managed operator well-managed operator network that is defined in Section 1.1.
network that is defined in Section 1.1.
2.1. Requirements Language 2.1. 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].
3. Encapsulation in UDP 3. Encapsulation in UDP
GRE-in-UDP encapsulation format is shown as follows: GRE-in-UDP encapsulation format is shown as follows:
skipping to change at page 10, line 12 skipping to change at page 9, line 12
Figure 2 UDP+GRE Headers in IPv6 Figure 2 UDP+GRE Headers in IPv6
The contents of the IP, UDP, and GRE headers that are relevant in The contents of the IP, UDP, and GRE headers that are relevant in
this encapsulation are described below. this encapsulation are described below.
3.1. IP Header 3.1. IP Header
An encapsulator MUST encode its own IP address as the source IP An encapsulator MUST encode its own IP address as the source IP
address and the decapsulator's IP address as the destination IP address and the decapsulator's IP address as the destination IP
address. The TTL field in the IP header MUST be set to a value address. The TTL field in the IP header MUST be set to a value
appropriate for delivery of the encapsulated packet to the peer of appropriate for delivery of the encapsulated packet to the peer of
the encapsulation. the encapsulation.
3.2. UDP Header 3.2. UDP Header
3.2.1. Source Port 3.2.1. Source Port
The UDP source port contains a 16-bit entropy value that is The UDP source port contains a 16-bit entropy value that is
generated by the encapsulator to identify a flow for the generated by the encapsulator to identify a flow for the
encapsulated packet. The port value SHOULD be within the ephemeral encapsulated packet. The port value SHOULD be within the ephemeral
port range. IANA suggests this range to be 49152 to 65535, where the port range, i.e., 49152 to 65535, where the high order two bits of
high order two bits of the port are set to one. This provides the port are set to one. This provides fourteen bits of entropy for
fourteen bits of entropy for the inner flow identifier. In the case the inner flow identifier. In the case that an encapsulator is
that an encapsulator is unable to derive flow entropy from the unable to derive flow entropy from the payload header or the entropy
payload header, it SHOULD set a randomly selected constant value for usage has to be disabled for a purpose (see section 4.2), it SHOULD
UDP source port to avoid payload packet flow reordering, e.g. use of set a randomly selected constant value for UDP source port to avoid
the system time to yield a value that is the range of entropy values. payload packet flow reordering, e.g., use of the system time to
yield a value that is the range of entropy values.
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.
For IPv6 delivery network, if IPv6 flow label load balancing is For IPv6 delivery network, if IPv6 flow label load balancing is
supported [RFC6438], the flow entropy SHOULD also be placed in the supported [RFC6438], the flow entropy SHOULD also be placed in the
flow label field. flow label field.
How an encapsulator generates flow entropy from the payload is How an encapsulator generates flow entropy from the payload is
outside the scope of this document. outside the scope of this document.
3.2.2. Destination Port 3.2.2. Destination Port
The destination port of the UDP header is set the GRE-in-UDP port or The destination port of the UDP header is set the GRE-in-UDP port or
GRE-UDP-DTLS (TBD) (see Section 8). GRE-UDP-DTLS (TBD) (see Section 8).
3.2.3. Checksum 3.2.3. Checksum
The UDP checksum is set and processed per [RFC768] and [RFC1122] for The UDP checksum is set and processed per [RFC768] and [RFC1122] for
IPv4, and [RFC2460] for IPv6. Requirements for checksum handling and IPv4, and [RFC2460] for IPv6. Requirements for checksum handling and
use of zero UDP checksums are detailed in Section 5. use of zero UDP checksums are detailed in Section 5.
3.2.4. Length 3.2.4. Length
The usage of this field is in accordance with the current UDP The usage of this field is in accordance with the current UDP
specification in [RFC768]. This length will include the UDP header specification in [RFC768]. This length will include the UDP header
(eight bytes), GRE header, and the GRE payload (encapsulated packet). (eight bytes), GRE header, and the GRE payload (encapsulated packet).
3.3. GRE Header 3.3. GRE Header
An encapsulator sets the protocol type (EtherType) of the packet An encapsulator sets the protocol type (EtherType) of the packet
being encapsulated in the GRE Protocol Type field. being encapsulated in the GRE Protocol Type field.
An encapsulator may set the GRE Key Present, Sequence Number Present, An encapsulator may set the GRE Key Present, Sequence Number Present,
and Checksum Present bits and associated fields in the GRE header as and Checksum Present bits and associated fields in the GRE header as
defined by [RFC2784] and [RFC2890]. defined by [RFC2784] and [RFC2890]. The reserved bits, i.e.,
Reserved0, SHOULD be set zero.
The GRE checksum MAY be enabled to protect the GRE header and The GRE checksum MAY be enabled to protect the GRE header and
payload. An encapsulator SHOULD NOT enable both the GRE checksum and payload. An encapsulator SHOULD NOT enable both the GRE checksum and
UDP checksum simultaneously as this would be mostly redundant. Since UDP checksum simultaneously as this would be mostly redundant. Since
the UDP checksum covers more of the packet including the GRE header the UDP checksum covers more of the packet including the GRE header
and payload, the UDP checksum SHOULD have preference to using GRE and payload, the UDP checksum SHOULD have preference to using GRE
checksum. The GRE checksum SHOULD be used for the payload integrity checksum. The GRE checksum SHOULD be used for the payload integrity
check when use of UDP zero-checksum. check when use of UDP zero-checksum.
An implementation MAY use the GRE keyid to authenticate the An implementation MAY use the GRE keyid to authenticate the
skipping to change at page 11, line 50 skipping to change at page 11, line 7
Although GRE-in-UDP encapsulation protocol uses both UDP header and Although GRE-in-UDP encapsulation protocol uses both UDP header and
GRE header, it is one tunnel encapsulation protocol. GRE and UDP GRE header, it is one tunnel encapsulation protocol. GRE and UDP
headers MUST be applied and removed as a pair at the encapsulation headers MUST be applied and removed as a pair at the encapsulation
and decapsulation points. This specification does not support UDP and decapsulation points. This specification does not support UDP
encapsulation of a GRE header where that GRE header is applied or encapsulation of a GRE header where that GRE header is applied or
removed at a network node other than the UDP tunnel ingress or removed at a network node other than the UDP tunnel ingress or
egress. egress.
4. Encapsulation Process Procedures 4. Encapsulation Process Procedures
The procedures specified in this section apply to both Default GRE-
in-UDP tunnel and WMON GRE-in-UDP tunnel.
The GRE-in-UDP encapsulation allows encapsulated packets to be The GRE-in-UDP encapsulation allows encapsulated packets to be
forwarded through "GRE-in-UDP tunnels". When performing GRE-in-UDP forwarded through "GRE-in-UDP tunnels". When performing GRE-in-UDP
encapsulation by the encapsulator, the entropy value is generated by encapsulation by the encapsulator, the entropy value is generated by
the encapsulator and then be filled in the Source Port field of the the encapsulator and then be filled in the Source Port field of the
UDP header. The Destination Port field is set to a value (TBD) UDP header. The Destination Port field is set to a value (TBD) to
allocated by IANA to indicate that the UDP tunnel payload is a GRE indicate that the UDP tunnel payload is a GRE packet. The Protocol
packet. The Protocol Type header field in GRE header is set to the Type header field in GRE header is set to the EtherType value
EtherType value corresponding to the protocol of the encapsulated corresponding to the protocol of the encapsulated packet.
packet.
Intermediate routers, upon receiving these UDP encapsulated packets, Intermediate routers, upon receiving these UDP encapsulated packets,
could balance these packets based on the hash of the five-tuple of could balance these packets based on the hash of the five-tuple of
UDP packets. UDP packets.
Upon receiving these UDP encapsulated packets, the decapsulator Upon receiving these UDP encapsulated packets, the decapsulator
would decapsulate them by removing the UDP and GRE headers and then decapsulates them by removing the UDP and GRE headers and then
process them accordingly. processes them accordingly.
Note: Each UDP tunnel is unidirectional, as GRE-in-UDP traffic is
sent to the IANA-allocated UDP Destination Port, and in particular,
is never sent back to any port used as a UDP Source Port (which
serves solely as a source of entropy). This is at odds with a common
middlebox (e.g., firewall) assumption that bidirectional traffic
uses a common pair of UDP ports. As a result, arranging to pass
bidirectional GRE-in-UDP traffic through middleboxes may require
separate configuration for each direction of traffic.
GRE-in-UDP allows encapsulation of unicast, broadcast, or multicast GRE-in-UDP allows encapsulation of unicast, broadcast, or multicast
traffic. Entropy may be generated from the header of encapsulated traffic. Entropy may be generated from the header of encapsulated
unicast or broadcast/multicast packets at an encapsulator. The unicast or broadcast/multicast packets at an encapsulator. The
mapping mechanism between the encapsulated multicast traffic and the mapping mechanism between the encapsulated multicast traffic and the
multicast capability in the IP network is transparent and multicast capability in the IP network is transparent and
independent to the encapsulation and is otherwise outside the scope independent to the encapsulation and is otherwise outside the scope
of this document. 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 no use of GRE keep-alive in the GRE-in-UDP alive. It is RECOMMENED no use of 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].
The procedures specified in this section apply to default GRE-in-UDP
tunnel implementation and conditional GRE-in-UDP tunnel
implementation.
4.1. MTU and Fragmentation 4.1. MTU and Fragmentation
Regarding packet fragmentation, an encapsulator/decapsulator SHOULD Regarding packet fragmentation, an encapsulator/decapsulator SHOULD
be compliant with [RFC7588]. For this case, the MTU is equal to the be compliant with [RFC7588] and the encapsulator MUST fragment the
PMTU associated with the path between the GRE ingress and the GRE packet before the encapsulation. For this case, the MTU for the
egress nodes minus the GRE and UDP overhead. When applying payload payload SHOULD be less or equal to the PMTU associated with the path
fragment, the UDP checksum MUST be used so that the receiving between the GRE ingress and the GRE egress nodes minus the GRE and
endpoint can validate reassembly of the fragments; the same src UDP UDP overhead, assuming the egress resemble MTU is larger than PMTU.
port SHOULD be used for all packet fragments to ensure the transit When applying payload fragment, the UDP checksum MUST be used so
routers will forward the fragments on the same path. An operator that the receiving endpoint can validate reassembly of the fragments;
should factor in the additional bytes of overhead when considering the same src UDP port SHOULD be used for all packet fragments to
an MTU size for the payload to avoid the likelihood of fragmentation. ensure the transit routers will forward the fragments on the same
path.
4.2. Differentiated Services If a tunnel operator is able to control the payload MTU size, the
tunnel operator SHOULD factor in the additional bytes of tunnel
overhead when considering the MTU size to avoid the likelihood of
fragmentation.
4.2. Middlebox Considerations
The Source Port number of the UDP header is pertinent to the
middlebox behavior. Network Address/Port Translator (NAPT) is the
most commonly deployed Network Address Translation (NAT) device
[RFC4787]. An 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 internal hosts. However, the above NAPT behaviors conflict
with the behavior that the UDP source port number is used as entropy
in GRE-in-UDP tunnel.
Each UDP tunnel is unidirectional, as GRE-in-UDP traffic is sent to
the GRE-in-UDP Destination Port (TBD), and in particular, is never
sent back to any port used as a UDP Source Port (which serves solely
as a source of entropy). It is common that a middlebox (e.g.,
firewall) assume that bidirectional traffic uses a common pair of
UDP ports. This assumption also conflicts with the use of the UDP
source port number as entropy.
Hence, use UDP src port for entropy may impact middlebox behavior.
If a GRE-in-UDP tunnel is expected to pass a middlebox, to avoid the
impact, the operator either disable UDP source port for entropy or
configure the middlebox to deal with the UDP source port variation.
4.3. Differentiated Services and ECN Marking
To ensure that tunneled traffic gets the same treatment over the IP To ensure that tunneled traffic gets the same treatment over the IP
network, prior to the encapsulation process, an encapsulator should network, prior to the encapsulation process, an encapsulator should
process the payload to get the proper parameters to fill into the IP process the payload to get the proper parameters to fill into the IP
header such as DiffServ [RFC2983]. Encapsulation end points that header such as DiffServ [RFC2983]. Encapsulation end points that
support ECN must use the method described in [RFC6040] for ECN support Explicit Congestion Notification (ECN) must use the method
marking propagation. This process is outside of the scope of this described in [RFC6040] for ECN marking propagation. The congestion
document. control process is outside of the scope of this document.
5. UDP Checksum Handling 5. UDP Checksum Handling
5.1. UDP Checksum with IPv4 5.1. UDP Checksum with IPv4
Default GRE-in-UDP Tunnel SHOULD perform UDP checksum. WMON GRE-in-
UDP Tunnel MAY perform UDP checksum.
For UDP in IPv4, the UDP checksum MUST be processed as specified in For UDP in IPv4, the UDP checksum MUST be processed as specified in
[RFC768] and [RFC1122] for both transmit and receive. The IPv4 [RFC768] and [RFC1122] for both transmit and receive. The IPv4
header includes a checksum which protects against mis-delivery of header includes a checksum which protects against mis-delivery of
the packet due to corruption of IP addresses. The UDP checksum the packet due to corruption of IP addresses. The UDP checksum
potentially provides protection against corruption of the UDP header, potentially provides protection against corruption of the UDP header,
GRE header, and GRE payload. Enabling or disabling the use of GRE header, and GRE payload. Enabling or disabling the use of
checksums is a deployment consideration that should take into checksums is a deployment consideration that should take into
account the risk and effects of packet corruption, and whether the account the risk and effects of packet corruption, and whether the
packets in the network are protected by other, possibly stronger packets in the network are protected by other, possibly stronger
mechanisms such as the Ethernet CRC. mechanisms such as the Ethernet CRC.
skipping to change at page 14, line 5 skipping to change at page 13, line 36
decapsulator SHOULD accept UDP packets with a zero checksum. A node decapsulator SHOULD accept UDP packets with a zero checksum. A node
MAY be configured to disallow zero checksums per [RFC1122]; this may MAY be configured to disallow zero checksums per [RFC1122]; this may
be done selectively, for instance disallowing zero checksums from be done selectively, for instance disallowing zero checksums from
certain hosts that are known to be sending over paths subject to certain hosts that are known to be sending over paths subject to
packet corruption. If verification of a non-zero checksum fails, a packet corruption. If verification of a non-zero checksum fails, a
decapsulator lacks the capability to verify a non-zero checksum, or decapsulator lacks the capability to verify a non-zero checksum, or
a packet with a zero-checksum was received and the decapsulator is a packet with a zero-checksum was received and the decapsulator is
configured to disallow, the packet MUST be dropped and an event MAY configured to disallow, the packet MUST be dropped and an event MAY
be logged. be logged.
Default GRE-in-UDP tunnel implementation SHOULD perform UDP checksum.
Conditional GRE-in-UDP tunnel implementation MAY set UDP zero-
checksum.
5.2. UDP Checksum with IPv6 5.2. UDP Checksum with IPv6
For UDP in IPv6, the UDP checksum MUST be processed as specified in For UDP in IPv6, the UDP checksum MUST be processed as specified in
[RFC768] and [RFC2460] for both transmit and receive. [RFC768] and [RFC2460] for both transmit and receive.
When UDP is used over IPv6, the UDP checksum is relied upon to When UDP is used over IPv6, the UDP checksum is relied upon to
protect both the IPv6 and UDP headers from corruption. As such, protect both the IPv6 and UDP headers from corruption. As such,
default GRE-in-UDP tunnel implementation MUST perform UDP checksum; Default GRE-in-UDP Tunnel MUST perform UDP checksum; WMON GRE-in-UDP
conditional GRE-in-UDP tunnel implementation MAY be configured with Tunnel MAY be configured with the UDP zero-checksum mode if the
the UDP zero-checksum mode when the tunnel is used in a well-managed well-managed operator network meets at least one of following
operator network and/or within a set of closely cooperating network conditions and/or within a set of closely cooperating well-managed
administrations (such as network operators who have agreed to work operator network administrations (such as network operators who have
together in order to jointly provide specific services). agreed to work together in order to jointly provide specific
services).
As such, for IPv6, the UDP checksum for GRE-in-UDP MUST be used as a. Under single administrative control where it is known (perhaps
specified in [RFC768] and [RFC2460] for tunnels that span multiple through knowledge of equipment types and lower layer checks) that
networks whose network administrations do not cooperate closely, packet corruption is exceptionally unlikely and where the
even if each non-cooperating network administration independently operator is willing to take the risk of undetected packet
satisfies the condition for UDP zero-checksum mode usage with GRE- corruption.
in-UDP over IPv6.
The use of the UDP zero-checksum mode must meet the requirements b. Under single administrative control (such as within a single
specified in [RFC6935] and [RFC6936], which conducts the following operator's network) where it is judged through observational
additional requirements for GRE-in-UDP tunnel implementation and use measurements (perhaps of historic or current traffic flows that
of UDP zero-checksum mode for GRE-in-UDP over IPv6: 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 mis-delivered 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.
As such, Default GRE-in-UDP tunnel MUST perform UDP checksum; WMON
GRE-in-UDP Tunnel MUST perform UDP checksum by default, this default
MAY be overridden via configuration of UDP zero-checksum mode
subject to the additional requirements specified below.
The following additional requirements apply to WMON GRE-in-UDP
Tunnel that use UDP zero-checksum mode:
a. Use of the UDP checksum with IPv6 MUST be the default a. Use of the UDP checksum with IPv6 MUST be the default
configuration of all GRE-in-UDP implementations. configuration of all GRE-in-UDP tunnels.
b. The GRE-in-UDP implementation MUST comply with all requirements b. The GRE-in-UDP tunnel implementation MUST comply with all
specified in Section 4 of [RFC6936] and with requirement 1 requirements specified in Section 4 of [RFC6936] and with
specified in Section 5 of [RFC6936]. requirement 1 specified in Section 5 of [RFC6936].
c. The tunnel decapsulator SHOULD only allow the use of UDP zero- c. The tunnel decapsulator SHOULD only allow the use of UDP zero-
checksum mode for IPv6 on a single received UDP Destination checksum mode for IPv6 on a single received UDP Destination
Port regardless of the encapsulator. The motivation for this Port regardless of the encapsulator. The motivation for this
requirement is possible corruption of the UDP Destination Port, requirement is possible corruption of the UDP Destination Port,
which may cause packet delivery to the wrong UDP port. If that which may cause packet delivery to the wrong UDP port. If that
other UDP port requires the UDP checksum, the mis-delivered other UDP port requires the UDP checksum, the mis-delivered
packet will be discarded packet will be discarded.
d. It is RECOMMENDED that UDP zero-checksum selectively be enabled d. It is RECOMMENDED that UDP zero-checksum selectively be enabled
for certain source addresses. The tunnel decapsulator MUST for certain source addresses. The tunnel decapsulator MUST
check that the source and destination IPv6 addresses are valid check that the source and destination IPv6 addresses are valid
for the GRE-in-UDP tunnel on which the packet was received if for the GRE-in-UDP tunnel on which the packet was received if
that tunnel uses UDP zero-checksum mode and discard any packet that tunnel uses UDP zero-checksum mode and discard any packet
for which this check fails. for which this check fails.
e. The tunnel encapsulator SHOULD use different IPv6 addresses for e. The tunnel encapsulator SHOULD use different IPv6 addresses for
each GRE-in-UDP tunnel that uses UDP zero-checksum mode each GRE-in-UDP tunnel that uses UDP zero-checksum mode
skipping to change at page 15, line 30 skipping to change at page 15, line 30
as few UDP zero-checksum mode GRE-in-UDP tunnels as is feasible. as few UDP zero-checksum mode GRE-in-UDP tunnels as is feasible.
Note that if UDP checksum is used, such restriction is not Note that if UDP checksum is used, such restriction is not
necessary. necessary.
f. When any middlebox exists on the path of GRE-in-UDP tunnel, it f. When any middlebox exists on the path of GRE-in-UDP tunnel, it
is RECOMMENDED to use the default mode, i.e. use UDP checksum, is RECOMMENDED to use the default mode, i.e. use UDP checksum,
to reduce the chance that the encapsulated packets to be to reduce the chance that the encapsulated packets to be
dropped. dropped.
g. Any middlebox for UDP zero-checksum mode for IPv6 MUST comply g. Any middlebox for UDP zero-checksum mode for IPv6 MUST comply
with requirement 1 and 8-10 in Section 5 of [RFC6936] with requirement 1 and 8-10 in Section 5 of [RFC6936].
h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP
checksums from "escaping" to the general Internet; see Section checksums from "escaping" to the general Internet; see Section
6 for examples of such measures. 6 for examples of such measures.
i. IPv6 traffic with zero UDP checksums MUST be actively monitored i. IPv6 traffic with zero UDP checksums MUST be actively monitored
for errors by the network operator. For example, Ethernet layer for errors by the network operator. For example, the operator
packet error rate or probe packet error rate. may monitor Ethernet layer packet error rates.
j. If a packet with a non-zero checksum is received, the checksum j. If a packet with a non-zero checksum is received, the checksum
MUST be verified before accepting the packet. This is MUST be verified before accepting the packet. This is
regardless of whether the tunnel encapsulator and decapsulator regardless of whether the tunnel encapsulator and decapsulator
have been configured with UDP zero-checksum mode. have been configured with UDP zero-checksum mode.
The above requirements do not change either the requirements The above requirements do not change either the requirements
specified in [RFC2460] as modified by [RFC6935] or the requirements specified in [RFC2460] as modified by [RFC6935] or the requirements
specified in [RFC6936]. specified in [RFC6936].
The requirement to check the source IPv6 address in addition to the The requirement to check the source IPv6 address in addition to the
destination IPv6 address, plus the strong recommendation against destination IPv6 address, plus the strong recommendation against
reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively
provide some mitigation for the absence of UDP checksum coverage of provide some mitigation for the absence of UDP checksum coverage of
the IPv6 header. Additional assurance is provided by the the IPv6 header. Additional assurance is provided by the well-
restrictions in the above exceptions that limit usage of IPv6 UDP managed operator network that satisfies at least one of three
zero-checksum mode to well-managed networks for which GRE conditions listed in this section (beginning).
encapsulated packet corruption has not been a problem in practice.
Hence GRE-in-UDP is suitable for transmission over lower layers in Hence GRE-in-UDP is suitable for transmission over lower layers in
the well-managed networks that are allowed by the exceptions stated the well-managed operator networks that are allowed by the
above and the rate of corruption of the inner IP packet on such exceptions stated above and the rate of corruption of the inner IP
networks is not expected to increase by comparison to GRE traffic packet on such networks is not expected to increase by comparison to
that is not encapsulated in UDP. For these reasons, GRE-in-UDP does GRE traffic that is not encapsulated in UDP. For these reasons,
not provide an additional integrity check except when GRE checksum GRE-in-UDP does not provide an additional integrity check except
is used when UDP zero-checksum mode is used with IPv6, and this when GRE checksum is used when UDP zero-checksum mode is used with
design is in accordance with requirements 2, 3 and 5 specified in IPv6, and this design is in accordance with requirements 2, 3 and 5
Section 5 of [RFC6936]. specified in Section 5 of [RFC6936].
GRE does not accumulate incorrect state as a consequence of GRE GRE does not accumulate incorrect state as a consequence of GRE
header corruption. A corrupt GRE results in either packet discard or header corruption. A corrupt GRE packet may result in either packet
forwarding of the packet without accumulation of GRE state. GRE discard or forwarding of the packet without accumulation of GRE
checksum MAY be used for protecting GRE header and payload. Active state. Active monitoring of GRE-in-UDP traffic for errors is
monitoring of GRE-in-UDP traffic for errors is REQUIRED as REQUIRED as occurrence of errors will result in some accumulation of
occurrence of errors will result in some accumulation of error error information outside the protocol for operational and
information outside the protocol for operational and management management purposes. This design is in accordance with requirement 4
purposes. This design is in accordance with requirement 4 specified specified in Section 5 of [RFC6936].
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
inapplicable to GRE-in-UDP. Requirements 6 and 7 do not apply inapplicable to GRE-in-UDP. Requirements 6 and 7 do not apply
because GRE does not have a GRE-generic control feedback mechanism. because GRE does not have a GRE-generic 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, but see Section 5.2.1 for further GRE-in-UDP tunnel endpoints, but see Section 5.2.1 for further
middle box discussion. middle box 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 [GREIPV6] and sending similar packet using GRE-in-IPv6 without UDP [GREIPV6] and
without GRE checksums. without GRE checksums.
In summary, conditional GRE-in-UDP tunnel implementation is allowed In summary, WMON GRE-in-UDP Tunnel is allowed to use UDP-zero-
to use UDP-zero-checksum mode for IPv6, when additional checksum mode for IPv6, when additional requirements stated above
implementation requirements stated above are provided. Otherwise the are provided. Otherwise the UDP checksum MUST be used for IPv6 as
UDP checksum MUST be used for IPv6 as specified in [RFC768] and specified in [RFC768] and [RFC2460]. Use of GRE checksum favors when
[RFC2460]. Use of GRE checksum favors non-use of the UDP checksum. the UDP checksum is not used.
5.2.1. Middlebox Considerations 5.2.1. Middlebox Considerations
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 validates the checksum based on [RFC2460] or that
updates the UDP checksum field, such as NATs or firewalls. Changing updates the UDP checksum field, such as NATs or firewalls. Changing
this behavior would require such middleboxes to be updated to this behavior would require such middleboxes to be updated to
correctly handle datagrams with zero UDP checksums. The GRE-in-UDP correctly 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 middle box exists on the path of GRE-in-UDP tunnel, As such, when any middlebox exists on the path of GRE-in-UDP tunnel,
it is RECOMMENDED to use the UDP checksum to reduce the chance that it is RECOMMENDED to use the UDP checksum to reduce the chance that
the encapsulated packets to be dropped. Recommended changes to allow the encapsulated packets to be dropped. Recommended changes to allow
firewalls, NATs and other middleboxes to support use of an IPv6 zero firewalls, NATs and other middleboxes to support use of an IPv6 zero
UDP checksum are described in Section 5 of [RFC6936]. UDP checksum are described in Section 5 of [RFC6936].
6. Congestion Considerations 6. Congestion Considerations
Section 3.1.3 of [RFC5405] discussed the congestion implications of Section 3.1.3 of [RFC5405] discussed the congestion implications of
UDP tunnels. As discussed in [RFC5405], because other flows can UDP tunnels. As discussed in [RFC5405], because other flows can
share the path with one or more UDP tunnels, congestion control share the path with one or more UDP tunnels, congestion control
skipping to change at page 18, line 10 skipping to change at page 18, line 5
avoid congestion by careful provisioning of their networks, by rate avoid congestion by careful provisioning of their networks, by rate
limiting of user data traffic, and traffic engineer according to limiting of user data traffic, and traffic engineer according to
path capacity. For this reason, GRE-in-UDP tunnel MUST be used path capacity. For this reason, GRE-in-UDP tunnel MUST be used
within a single operator's network that utilizes careful within a single operator's network that utilizes careful
provisioning (e.g., rate limiting at the entries of the network provisioning (e.g., rate limiting at the entries of the network
while over-provisioning network capacity) to ensure against while over-provisioning network capacity) to ensure against
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. provisioning.
Default GRE-in-UDP tunnel implementation can be used to carry IP The default GRE-in-UDP tunnel can be used to carry IP traffic that
traffic that is known to be congestion controlled on the Internet. is known to be congestion controlled on the Internet. Internet IP
Internet IP traffic is generally assumed to be congestion-controlled. traffic is generally assumed to be congestion-controlled. The
GRE-in-UDP MUST NOT be used over the general Internet, or over non- default GRE-in-UDP tunnel MUST NOT be used over the general Internet,
cooperating network operators, to carry traffic that is not or over non-cooperating network operators, to carry traffic that is
congestion-controlled. not congestion-controlled.
Conditional GRE-in-UDP tunnel implementation can be used within a WMON GRE-in-UDP Tunnel is used within a well-managed operator
well-managed operator network to carry traffic that is not necessary network so that it can carry the traffic that is not necessary
congestion controlled. Measures SHOULD be taken to prevent non- congestion controlled. Measures SHOULD be taken to prevent non-
congestion-controlled GRE-in-UDP traffic from "escaping" to the congestion-controlled GRE-in-UDP traffic from "escaping" to the
general Internet, e.g.: general Internet, e.g.:
o Physical or logical isolation of the links carrying GRE-in-UDP o Physical or logical isolation of the links carrying GRE-in-UDP
from the general Internet. from the general Internet.
o Deployment of packet filters that block the UDP ports assigned o Deployment of packet filters that block the UDP ports assigned
for GRE-in-UDP. for GRE-in-UDP.
skipping to change at page 18, line 42 skipping to change at page 18, line 37
examples, a GRE-in-UDP tunnel only carries IP traffic or a GRE- examples, a GRE-in-UDP tunnel only carries IP traffic or a GRE-
in-UDP tunnel supports NVEGRE encapsulation only (Although the in-UDP tunnel supports NVEGRE encapsulation only (Although the
payload type is Ethernet in NVGRE, NVGRE protocol mandates that payload type is Ethernet in NVGRE, NVGRE protocol mandates that
the payload of Ethernet is IP). the payload of Ethernet is IP).
o Use of a "Circuit Breaker" for the tunneled traffic as described o Use of a "Circuit Breaker" for the tunneled traffic as described
in [CB]. in [CB].
7. Backward Compatibility 7. Backward Compatibility
It is assumed that tunnel ingress routers must be upgraded in order In general, tunnel ingress routers have to be upgraded in order to
to support the encapsulations described in this document. support the encapsulations described in this document.
No change is required at transit routers to support forwarding of No change is required at transit routers to support forwarding of
the encapsulation described in this document. the encapsulation described in this document.
If a router that is intended for use as a decapsulator does not If a router that is intended for use as a decapsulator does not
support or enable GRE-in-UDP encapsulation described in this support or enable GRE-in-UDP encapsulation described in this
document, it will not be listening on the destination port (TBD). document, it will not be listening on the destination port (TBD).
In these cases, the router will conform to normal UDP processing and In these cases, the router will conform to normal UDP processing and
respond to an encapsulator with an ICMP message indicating "port respond to an encapsulator with an ICMP message indicating "port
unreachable" according to [RFC792]. Upon receiving this ICMP unreachable" according to [RFC792]. Upon receiving this ICMP
skipping to change at page 20, line 16 skipping to change at page 20, line 9
application security and can preserve network and transport layer application security and can preserve network and transport layer
protocol information. Specifically, if DTLS is used to secure the protocol information. Specifically, if DTLS is used to secure the
GRE-in-UDP tunnel, the destination port of the UDP header MUST be GRE-in-UDP tunnel, the destination port of the UDP header MUST be
set to an IANA-assigned value (TBD2) indicating GRE-in-UDP with DTLS, set to an IANA-assigned value (TBD2) indicating GRE-in-UDP with DTLS,
and that UDP port MUST NOT be used for other traffic. The UDP 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- source port field can still be used to add entropy, e.g., for load-
sharing purposes. DTLS usage is limited to a single DTLS session sharing purposes. DTLS usage is limited to a single DTLS session
for any specific tunnel encapsulator/ decapsulator pair (identified for any specific tunnel encapsulator/ decapsulator pair (identified
by source and destination IP addresses). Both IP addresses MUST be by source and destination IP addresses). Both IP addresses MUST be
unicast addresses - multicast traffic is not supported when DTLS is unicast addresses - multicast traffic is not supported when DTLS is
used. A GRE-in-UDP tunnel decapsulator implementation that supports used. A GRE-in-UDP tunnel decapsulator that supports DTLS is
DTLS is expected to be able to establish DTLS sessions with multiple expected to be able to establish DTLS sessions with multiple tunnel
tunnel encapsulators, and likewise an GRE-in-UDP tunnel encapsulator encapsulators, and likewise an GRE-in-UDP tunnel encapsulator is
implementation is expected to be able to establish DTLS sessions expected to be able to establish DTLS sessions with multiple
with multiple decapsulators (although different source and/or decapsulators (although different source and/or destination IP
destination IP addresses may be involved -see Section 5.2 for addresses may be involved -see Section 5.2 for discussion of one
discussion of one situation where use of different source IP situation where use of different source IP addresses is important).
addresses is important).
Use of ICMP for signaling of the GRE-in-UDP encapsulation capability
adds a security concern. Upon receiving an ICMP message and before
taking an action on it, the ingress MUST validate the IP address
originating against tunnel egress address and MUST evaluate the
packet header returned in the ICMP payload to ensure the source port
is the one used for this tunnel. The mechanism for performing this
validation is out of the scope of this document.
In an instance where the UDP source port is not set based on the In the case that UDP source port for entropy usage is disabled, a
flow invariant fields from the payload header, a random port SHOULD random port SHOULD be selected in order to minimize the
be selected in order to minimize the vulnerability to off-path vulnerability to off-path attacks.[RFC6056] The random port may also
attacks. [RFC6056]. The random port may also be periodically changed be periodically changed to mitigate certain denial of service
to mitigate certain denial of service attacks. How the source port attacks as mentioned in Section 3.2.
randomization occurs is outside scope of this document.
Using one standardized value in UDP destination port for an Using one standardized value in UDP destination port for an
encapsulation indication may increase the vulnerability of off-path encapsulation indication may increase the vulnerability of off-path
attack. To overcome this, an alternate port may be agreed upon to attack. To overcome this, an alternate port may be agreed upon to
use between an encapsulator and decapsulator [RFC6056]. How the use 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 decapsulator validates the IP This document does not require that 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
skipping to change at page 21, line 18 skipping to change at page 20, line 48
Corruption of GRE header can cause a privacy and security concern Corruption of 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 GRE key field is used for privacy and security, segregation. When GRE key field is used for privacy and security,
ether UDP checksum or GRE checksum SHOULD be used for GRE-in-UDP ether UDP checksum or GRE checksum SHOULD be used for GRE-in-UDP
with both IPv4 and IPv6, and in particular, when UDP zero-checksum with both IPv4 and IPv6, and in particular, when UDP zero-checksum
mode is used, GRE checksum SHOULD be used. mode is used, GRE checksum SHOULD be used.
10. Acknowledgements 10. 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, and many others for their review and valuable Geib, Lar Edds, Lloyd Wood, Bob Briscoe, and many others for their
input on this draft. review and valuable input on this draft.
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.
11. Contributors 11. Contributors
The following people all contributed significantly to this document The following people all contributed significantly to this document
and are listed below in alphabetical order: and are listed below in alphabetical order:
skipping to change at page 24, line 36 skipping to change at page 24, line 19
Using Generic Routing Encapsulation", RFC7637, September Using Generic Routing Encapsulation", RFC7637, September
2015. 2015.
[CB] Fairhurst, G., "Network Transport Circuit Breakers", [CB] Fairhurst, G., "Network Transport Circuit Breakers",
draft-ietf-tsvwg-circuit-breaker-04, work in progress. draft-ietf-tsvwg-circuit-breaker-04, work in progress.
[GREIPV6] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for [GREIPV6] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for
Generic Routing Encapsulation (GRE)", draft-ietf-intarea- Generic Routing Encapsulation (GRE)", draft-ietf-intarea-
gre-ipv6, work in progress. gre-ipv6, work in progress.
[TUNNEL] Touch, J. and Townsley, M., "IP Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-01.txt, work in
progress.
13. Authors' Addresses 13. Authors' Addresses
Edward Crabbe Edward Crabbe
Email: edward.crabbe@gmail.com Email: edward.crabbe@gmail.com
Lucy Yong Lucy Yong
Huawei Technologies, USA Huawei Technologies, USA
Email: lucy.yong@huawei.com Email: lucy.yong@huawei.com
 End of changes. 68 change blocks. 
317 lines changed or deleted 299 lines changed or added

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