draft-ietf-tsvwg-gre-in-udp-encap-18.txt   draft-ietf-tsvwg-gre-in-udp-encap-19.txt 
Network Working Group Lucy Yong(Ed.) Network Working Group Lucy Yong(Ed.)
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standard Track E. Crabbe Intended status: Standard Track E. Crabbe
Oracle Oracle
X. Xu X. Xu
Huawei Technologies Huawei Technologies
T. Herbert T. Herbert
Facebook Facebook
Expires: February 2017 September 5, 2016 Expires: February 2017 September 30, 2016
GRE-in-UDP Encapsulation GRE-in-UDP Encapsulation
draft-ietf-tsvwg-gre-in-udp-encap-18 draft-ietf-tsvwg-gre-in-udp-encap-19
Abstract Abstract
This document specifies a method of encapsulating network protocol This document specifies a method of encapsulating network protocol
packet within GRE and UDP headers. This GRE-in-UDP encapsulation packet within GRE and UDP headers. This GRE-in-UDP encapsulation
allows the UDP source port field to be used as an entropy field. allows the UDP source port field to be used as an entropy field.
This may be used for load balancing of GRE traffic in transit This may be used for load balancing of GRE traffic in transit
networks using existing ECMP mechanisms. There are two applicability networks using existing ECMP mechanisms. There are two applicability
scenarios for GRE-in-UDP with different requirements: (1) general scenarios for GRE-in-UDP with different requirements: (1) general
Internet; (2) a traffic-managed controlled environment. The Internet; (2) a traffic-managed controlled environment. The
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 5,2017. This Internet-Draft will expire on February 30,2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Terminology...............................................4 1.1. Terminology...............................................4
1.2. Requirements Language.....................................4 1.2. Requirements Language.....................................5
2. Applicability Statement........................................5 2. Applicability Statement........................................5
2.1. GRE-in-UDP Tunnel Requirements............................5 2.1. GRE-in-UDP Tunnel Requirements............................6
2.1.1. Requirements for Default GRE-in-UDP Tunnel...........5 2.1.1. Requirements for Default GRE-in-UDP Tunnel...........6
2.1.2. Requirements for TMCE GRE-in-UDP Tunnel..............6 2.1.2. Requirements for TMCE GRE-in-UDP Tunnel..............7
3. GRE-in-UDP Encapsulation.......................................7 3. GRE-in-UDP Encapsulation.......................................7
3.1. IP Header................................................10 3.1. IP Header................................................10
3.2. UDP Header...............................................10 3.2. UDP Header...............................................10
3.2.1. Source Port.........................................10 3.2.1. Source Port.........................................10
3.2.2. Destination Port....................................11 3.2.2. Destination Port....................................11
3.2.3. Checksum............................................11 3.2.3. Checksum............................................11
3.2.4. Length..............................................11 3.2.4. Length..............................................11
3.3. GRE Header...............................................11 3.3. GRE Header...............................................11
4. Encapsulation Process Procedures..............................12 4. Encapsulation Process Procedures..............................12
4.1. MTU and Fragmentation....................................12 4.1. MTU and Fragmentation....................................12
skipping to change at page 2, line 45 skipping to change at page 2, line 45
5. Use of DTLS...................................................13 5. Use of DTLS...................................................13
6. UDP Checksum Handling.........................................14 6. UDP Checksum Handling.........................................14
6.1. UDP Checksum with IPv4...................................14 6.1. UDP Checksum with IPv4...................................14
6.2. UDP Checksum with IPv6...................................14 6.2. UDP Checksum with IPv6...................................14
7. Middlebox Considerations......................................17 7. Middlebox Considerations......................................17
7.1. Middlebox Considerations for Zero Checksums..............18 7.1. Middlebox Considerations for Zero Checksums..............18
8. Congestion Considerations.....................................18 8. Congestion Considerations.....................................18
9. Backward Compatibility........................................19 9. Backward Compatibility........................................19
10. IANA Considerations..........................................20 10. IANA Considerations..........................................20
11. Security Considerations......................................21 11. Security Considerations......................................21
12. Acknowledgements.............................................22 12. Acknowledgements.............................................21
13. Contributors.................................................22 13. Contributors.................................................22
14. References...................................................23 14. References...................................................23
14.1. Normative References....................................23 14.1. Normative References....................................23
14.2. Informative References..................................24 14.2. Informative References..................................24
15. Authors' Addresses...........................................25 15. Authors' Addresses...........................................25
1. Introduction 1. Introduction
This document specifies a generic GRE-in-UDP encapsulation for This document specifies a generic GRE-in-UDP encapsulation for
tunneling network protocol packets across an IP network based on tunneling network protocol packets across an IP network based on
Generic Routing Encapsulation (GRE) [RFC2784][RFC7676] and User Generic Routing Encapsulation (GRE) [RFC2784][RFC7676] and User
Datagram Protocol(UDP) [RFC768] headers. The GRE header indicates Datagram Protocol(UDP) [RFC768] headers. The GRE header indicates
the payload protocol type via an EtherType [RFC7042] in the protocol 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 type field, and the source port field in the UDP header may be used
to provide additional entropy. to provide additional entropy.
A GRE-in-UDP tunnel offers the possibility of better performance for A GRE-in-UDP tunnel offers the possibility of better performance for
load balancing GRE traffic in transit networks using existing Equal- load balancing GRE traffic in transit networks using existing Equal-
Cost Multi-Path (ECMP) mechanisms that use a hash of the five-tuple Cost Multi-Path (ECMP) mechanisms that use a hash of the five-tuple
of source IP address, destination IP address, UDP/TCP source port, of source IP address, destination IP address, UDP/TCP source port,
UDP/TCP destination port. While such hashing distributes UDP and UDP/TCP destination port. While such hashing distributes UDP and
Transmission Control Protocol (TCP)[RFC793] traffic between a common Transmission Control Protocol (TCP)[RFC793] traffic between a common
pair of IP addresses across paths, it uses a single path for pair of IP addresses across paths, it uses a single path for
corresponding GRE traffic because only the two IP addresses and corresponding GRE traffic because only the two IP addresses and
protocol/next header fields participate in the ECMP hash. protocol/next header fields participate in the ECMP hash.
Encapsulating GRE in UDP enables use of the UDP source port to Encapsulating GRE in UDP enables use of the UDP source port to
provide entropy to ECMP hashing. provide entropy to ECMP hashing.
In addition, GRE-in-UDP enables extending use of GRE across networks 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 that otherwise disallow it; for example, GRE-in-UDP may be used to
bridge two islands where GRE is not supported natively across the bridge two islands where GRE is not supported natively across the
middleboxes. middleboxes.
GRE-in-UDP encapsulation may be used to encapsulate already tunneled GRE-in-UDP encapsulation may be used to encapsulate already tunneled
traffic, i.e., tunnel-in-tunnel. In this case, GRE-in-UDP tunnels traffic, i.e., tunnel-in-tunnel. In this case, GRE-in-UDP tunnels
treat the endpoints of the outer tunnel as the end hosts; the treat the endpoints of the outer tunnel as the end hosts; the
presence of an inner tunnel does not change the outer tunnel's presence of an inner tunnel does not change the outer tunnel's
handling of network traffic. handling of network traffic.
In full generality with the capability to carry arbitrary traffic, A GRE-in-UDP tunnel is capable of carrying arbitrary traffic and
GRE-in-UDP tunnels are not safe for general deployment in the public behaves as a UDP application on an IP network. However, a GRE-in-UDP
Internet. Therefore GRE-in-UDP tunnel deployments are limited to tunnel carrying certain types of traffic does not satisfy the
two applicability scenarios for which requirements are specified in requirements for UDP applications on the Internet [RFC5405bis]. GRE-
this document: (1) general Internet; (2) a traffic-managed in-UDP tunnels that do not satisfy these requirements MUST NOT be
controlled environment. The traffic-managed controlled environment deployed to carry such traffic over the Internet. For this reason,
scenario has less restrictive technical requirements for the this document specifies two deployment scenarios for GRE-in-UDP
protocol but more restrictive management and operation requirements tunnels with GRE-in-UDP tunnel requirements for each of them: (1)
for the network by comparison to the general Internet scenario. general Internet; (2) a traffic-managed controlled environment
(TMCE). The TMCE scenario has less restrictive technical
requirements for the protocol but more restrictive management and
operation requirements for the network by comparison to the general
Internet scenario.
The document also specifies Datagram Transport Layer Security (DTLS) To provide security for traffic carried by a GRE-in-UDP tunnel, this
for GRE-in-UDP tunnels to be used where/when security is a concern. 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 GRE-in-UDP encapsulation usage requires no changes to the transit IP
network. ECMP hash functions in most existing IP routers may utilize network. ECMP hash functions in most existing IP routers may utilize
and benefit from the additional entropy enabled by GRE-in-UDP and benefit from the additional entropy enabled by GRE-in-UDP
tunnels without any change or upgrade to their ECMP implementation. tunnels without any change or upgrade to their ECMP implementation.
The encapsulation mechanism is applicable to a variety of IP The encapsulation mechanism is applicable to a variety of IP
networks including Data Center and Wide Area Networks, as well as networks including Data Center and Wide Area Networks, as well as
both IPv4 and IPv6 networks. both IPv4 and IPv6 networks.
1.1. Terminology 1.1. Terminology
skipping to change at page 5, line 29 skipping to change at page 5, line 35
applications: 1) General Internet and 2) A controlled environment. applications: 1) General Internet and 2) A controlled environment.
The controlled environment means a single administrative domain or The controlled environment means a single administrative domain or
bilaterally agreed connection between domains. A network forming a bilaterally agreed connection between domains. A network forming a
controlled environment can be managed/operated to meet certain controlled environment can be managed/operated to meet certain
conditions while the general Internet cannot be; thus the conditions while the general Internet cannot be; thus the
requirements for a tunnel protocol operating under a controlled requirements for a tunnel protocol operating under a controlled
environment can be less restrictive than the requirements in the environment can be less restrictive than the requirements in the
general Internet. general Internet.
For the purpose of this document, a traffic-managed controlled For the purpose of this document, a traffic-managed controlled
environment is defined as an IP network that is traffic-engineered environment (TMCE) is defined as an IP network that is traffic-
and/or otherwise managed (e.g., via use of traffic rate limiters) to engineered and/or otherwise managed (e.g., via use of traffic rate
avoid congestion. limiters) to avoid congestion.
This document specifies GRE-in-UDP tunnel usage in the general This document specifies GRE-in-UDP tunnel usage in the general
Internet and GRE-in-UDP tunnel usage in a traffic-managed controlled Internet and GRE-in-UDP tunnel usage in a traffic-managed controlled
environment and uses "default GRE-in-UDP tunnel" and "TMCE GRE-in- environment and uses "default GRE-in-UDP tunnel" and "TMCE GRE-in-
UDP tunnel" terms to refer to each usage. UDP tunnel" terms to refer to each usage.
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 2.1. GRE-in-UDP Tunnel Requirements
This section states out the requirements for a GRE-in-UDP tunnel. This section states out the requirements for a GRE-in-UDP tunnel.
Section 2.1.1 describes the requirements for a default GRE-in-UDP Section 2.1.1 describes the requirements for a default GRE-in-UDP
tunnel that is suitable for the general Internet; Section 2.1.2 tunnel that is suitable for the general Internet; Section 2.1.2
describes a set of relaxed requirements for a TMCE GRE-in-UDP tunnel describes a set of relaxed requirements for a TMCE GRE-in-UDP tunnel
used in a traffic-managed controlled environment. Both Sections 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. 2.1.1 and 2.1.2 are applicable to an IPv4 or IPv6 delivery network.
2.1.1. Requirements for Default GRE-in-UDP Tunnel 2.1.1. Requirements for Default GRE-in-UDP Tunnel
skipping to change at page 14, line 5 skipping to change at page 13, line 50
destination IP addresses). Both IP addresses MUST be unicast destination IP addresses). Both IP addresses MUST be unicast
addresses - multicast traffic is not supported when DTLS is used. A addresses - multicast traffic is not supported when DTLS is used. A
GRE-in-UDP tunnel decapsulator that supports DTLS is expected to be GRE-in-UDP tunnel decapsulator that supports DTLS is expected to be
able to establish DTLS sessions with multiple tunnel encapsulators, able to establish DTLS sessions with multiple tunnel encapsulators,
and likewise a GRE-in-UDP tunnel encapsulator is expected to be able and likewise a GRE-in-UDP tunnel encapsulator is expected to be able
to establish DTLS sessions with multiple decapsulators. Different to establish DTLS sessions with multiple decapsulators. Different
source and/or destination IP addresses will be involved (see Section source and/or destination IP addresses will be involved (see Section
6.2) for discussion of one situation where use of different source 6.2) for discussion of one situation where use of different source
IP addresses is important. IP addresses is important.
If the traffic to be encapsulated is already encrypted, it is When DTLS is used for a GRE-in-UDP tunnel, if a packet is received
usually not necessary to encrypt it again. Applying DTLS to GRE-in- from the tunnel and that packet is not protected by the DTLS session
UDP tunnel requires both tunnel end points to configure use of DTLS. 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. UDP Checksum Handling
6.1. UDP Checksum with IPv4 6.1. UDP Checksum with IPv4
For UDP in IPv4, the UDP checksum MUST be processed as specified in For UDP in IPv4, when a non-zero UDP checksum is used, the UDP
[RFC768] and [RFC1122] for both transmit and receive. The IPv4 checksum MUST be processed as specified in [RFC768] and [RFC1122]
header includes a checksum that protects against mis-delivery of the for both transmit and receive. The IPv4 header includes a checksum
packet due to corruption of IP addresses. The UDP checksum that protects against mis-delivery of the packet due to corruption
potentially provides protection against corruption of the UDP header, of IP addresses. The UDP checksum potentially provides protection
GRE header, and GRE payload. Disabling the use of checksums is a against corruption of the UDP header, GRE header, and GRE payload.
deployment consideration that should take into account the risk and Disabling the use of checksums is a deployment consideration that
effects of packet corruption. should take into account the risk and effects of packet corruption.
When a decapsulator receives a packet, the UDP checksum field MUST When a decapsulator receives a packet, the UDP checksum field MUST
be processed. If the UDP checksum is non-zero, the decapsulator MUST be processed. If the UDP checksum is non-zero, the decapsulator MUST
verify the checksum before accepting the packet. By default a verify the checksum before accepting the packet. By default a
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
skipping to change at page 18, line 50 skipping to change at page 18, line 50
Section 3.1.9 of [RFC5405bis] discusses the congestion Section 3.1.9 of [RFC5405bis] discusses the congestion
considerations for design and use of UDP tunnels; this is important considerations for design and use of UDP tunnels; this is important
because other flows could share the path with one or more UDP because other flows could share the path with one or more UDP
tunnels, necessitating congestion control [RFC2914] to avoid tunnels, necessitating congestion control [RFC2914] to avoid
distractive interference. distractive interference.
Congestion has potential impacts both on the rest of the network Congestion has potential impacts both on the rest of the network
containing a UDP tunnel, and on the traffic flows using the UDP containing a UDP tunnel, and on the traffic flows using the UDP
tunnels. These impacts depend upon what sort of traffic is carried tunnels. These impacts depend upon what sort of traffic is carried
over the tunnel, as well as the path of the tunnel. over the tunnel, as well as the path of the tunnel. The GRE-in-UDP
tunnel protocol does not provide any congestion control and GRE-in-
A default GRE-in-UDP tunnel MAY be used to carry IP traffic that is UDP packets are regular UDP packets. Therefore, a GRE-in-UDP tunnel
known to be congestion controlled on the Internet. IP unicast MUST NOT be deployed to carry non-congestion controlled traffic over
traffic is generally assumed to be congestion-controlled. A default the Internet [RFC5405bis].
GRE-in-UDP tunnel is not appropriate for traffic that is not known
to be congestion-controlled.
A TMCE GRE-in-UDP tunnel can be used to carry traffic that is known Within a TMCE network, GRE-in-UDP tunnels are appropriate for
not to be congestion controlled. For example, GRE-in-UDP may be used carrying traffic that is not known to be congestion controlled. For
to carry Multiprotocol Label Switching (MPLS) that carries example, a GRE-in-UDP tunnel may be used to carry Multiprotocol
pseudowire or VPN traffic where specific bandwidth guarantees are Label Switching (MPLS) traffic such as pseudowires or VPNs where
provided to each pseudowire or to each VPN. In such cases, network specific bandwidth guarantees are provided to each pseudowire or VPN.
operators may avoid congestion by careful provisioning of their In such cases, operators of TMCE networks avoid congestion by
networks, by rate limiting of user data traffic, and traffic careful provisioning of their networks, rate limiting of user data
engineering according to path capacity. traffic, and traffic engineering according to path capacity.
When a TMCE GRE-in-UDP tunnel carries traffic that is not known to When a GRE-in-UDP tunnel carries traffic that is not known to be
be congestion controlled, the tunnel MUST be used within a traffic- congestion controlled in a TMCE network, the tunnel MUST be deployed
managed controlled environment (e.g., single operator network that entirely within that network, and measures SHOULD be taken to
utilizes careful provisioning such as rate limiting at the entries prevent the GRE-in-UDP traffic from "escaping" the network to the
of the network while over-provisioning network capacity) to manage general Internet, e.g.:
congestion, or within a limited number of networks whose operators
closely cooperate in order to jointly provide this same careful
provisioning. When a TMCE GRE-in-UDP tunnel is used to carry the
traffic that is not known to be congestion controlled, measures
SHOULD be taken to prevent the GRE-in-UDP traffic from "escaping" to
the 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.
o Imposition of restrictions on GRE-in-UDP traffic by software o Imposition of restrictions on GRE-in-UDP traffic by software
tools used to set up GRE-in-UDP tunnels between specific end tools used to set up GRE-in-UDP tunnels between specific end
systems (as might be used within a single data center) or by systems (as might be used within a single data center) or by
tunnel ingress nodes for tunnels that don't terminate at end tunnel ingress nodes for tunnels that don't terminate at end
systems. systems.
o Use of a "Circuit Breaker" for the tunneled traffic as described
in [CB].
9. Backward Compatibility 9. Backward Compatibility
In general, tunnel ingress routers have to be upgraded in order to In general, tunnel ingress routers have to be upgraded in order 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 tunnel endpoint (a host or router) that is intended for use as 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 a decapsulator does not support or enable the GRE-in-UDP
encapsulation described in this document, that endpoint will not encapsulation described in this document, that endpoint will not
listen on the destination port assigned to the GRE-encapsulation listen on the destination port assigned to the GRE-encapsulation
(TBD1 and TBD2). In these cases, the endpoint will perform normal (TBD1 and TBD2). In these cases, the endpoint will perform normal
UDP processing and respond to an encapsulator with an ICMP message UDP processing and respond to an encapsulator with an ICMP message
indicating "port unreachable" according to [RFC792]. Upon receiving indicating "port unreachable" according to [RFC792]. Upon receiving
this ICMP message, the node MUST NOT continue to use GRE-in-UDP this ICMP message, the node MUST NOT continue to use GRE-in-UDP
encapsulation toward this peer without management intervention. encapsulation toward this peer without management intervention.
10. IANA Considerations 10. IANA Considerations
IANA is requested to make the following allocations: IANA is requested to make the following allocations:
One UDP destination port number for the indication of GRE, One UDP destination port number for the indication of GRE,
Service Name: GRE-in-UDP Service Name: GRE-in-UDP
skipping to change at page 21, line 17 skipping to change at page 21, line 11
Editor Note: replace "TBD2" in section 3, 5, and 9 with IANA Editor Note: replace "TBD2" in section 3, 5, and 9 with IANA
assigned number. assigned number.
11. Security Considerations 11. Security Considerations
GRE-in-UDP encapsulation does not affect security for the payload GRE-in-UDP encapsulation does not affect security for the payload
protocol. The security considerations for GRE apply to GRE-in-UDP, protocol. The security considerations for GRE apply to GRE-in-UDP,
see [RFC2784]. see [RFC2784].
To secure original traffic, DTLS SHOULD be used as specified in To secure traffic carried by a GRE-in-UDP tunnel, DTLS SHOULD be
Section 5. used as specified in Section 5.
In the case that UDP source port for entropy usage is disabled, a In the case that UDP source port for entropy usage is disabled, a
random port SHOULD be selected in order to minimize the random port SHOULD be selected in order to minimize the
vulnerability to off-path attacks [RFC6056]. The random port may vulnerability to off-path attacks [RFC6056]. The random port may
also be periodically changed to mitigate certain denial of service also be periodically changed to mitigate certain denial of service
attacks as mentioned in Section 3.2.1. attacks as mentioned in Section 3.2.1.
Using one standardized value as the UDP destination port to indicate Using one standardized value as the UDP destination port to indicate
an encapsulation may increase the vulnerability of off-path attack. an encapsulation may increase the vulnerability of off-path attack.
To overcome this, an alternate port may be agreed upon to use To overcome this, an alternate port may be agreed upon to use
skipping to change at page 21, line 41 skipping to change at page 21, line 35
this document. this document.
This document does not require that a decapsulator validates the IP This document does not require that a decapsulator validates the IP
source address of the tunneled packets (with the exception that the source address of the tunneled packets (with the exception that the
IPv6 source address MUST be validated when UDP zero-checksum mode is IPv6 source address MUST be validated when UDP zero-checksum mode is
used with IPv6), but it should be understood that failure to do so used with IPv6), but it should be understood that failure to do so
presupposes that there is effective destination-based (or a presupposes that there is effective destination-based (or a
combination of source-based and destination-based) filtering at the combination of source-based and destination-based) filtering at the
boundaries. boundaries.
Corruption of a GRE header can cause a privacy and security concern Corruption of GRE headers can cause security concerns for
for some applications that rely on the key field for traffic applications that rely on the GRE key field for traffic separation
segregation. When the GRE key field is used for privacy and security, or segregation. When the GRE key field is used for this purpose such
either UDP checksum or GRE checksum SHOULD be used for GRE-in-UDP as an application of a Network Virtualization Using Generic Routing
with both IPv4 and IPv6, and in particular, when UDP zero-checksum Encapsulation (NVGRE) [RFC7637], GRE header corruption is a concern.
mode is used, GRE checksum SHOULD be used. 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. Acknowledgements 12. Acknowledgements
Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger
Geib, Lar Edds, Lloyd Wood, Bob Briscoe, Rick Casarez, Jouni Geib, Lars Eggert, Lloyd Wood, Bob Briscoe, Rick Casarez, Jouni
Korhonen, and many others for their review and valuable input on Korhonen, Kathleen Moriarty, Ben Campbell, and many others for their
this draft. review and valuable input on this draft.
Thank Donald Eastlake, Eliot Lear, Martin Stiemerling, and Spencer Thank Donald Eastlake, Eliot Lear, Martin Stiemerling, and Spencer
Dawkins for their detail reviews and valuable suggestions in WGLC Dawkins for their detail reviews and valuable suggestions in WGLC
and IESG process. and IESG process.
Thank the design team led by David Black (members: Ross Callon, Thank the design team led by David Black (members: Ross Callon,
Gorry Fairhurst, Xiaohu Xu, Lucy Yong) to efficiently work out the Gorry Fairhurst, Xiaohu Xu, Lucy Yong) to efficiently work out the
descriptions for the congestion considerations and IPv6 UDP zero descriptions for the congestion considerations and IPv6 UDP zero
checksum. checksum.
skipping to change at page 25, line 5 skipping to change at page 24, line 44
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981. 792, September 1981.
[RFC793] DARPA, "Transmission Control Protocol", RFC793, September [RFC793] DARPA, "Transmission Control Protocol", RFC793, September
1981. 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2914] Floyd, S.,"Congestion Control Principles", RFC2914, [RFC2914] Floyd, S., "Congestion Control Principles", RFC2914,
September 2000. September 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983,
October 2000. October 2000.
[RFC4787] Audet, F., et al, "network Address Translation (NAT) [RFC4787] Audet, F., et al, "network Address Translation (NAT)
Behavioral Requirements for Unicast UDP", RFC4787, January Behavioral Requirements for Unicast UDP", RFC4787, January
2007. 2007.
[RFC6056] Larsen, M. and Gont, F., "Recommendations for Transport- [RFC6056] Larsen, M. and Gont, F., "Recommendations for Transport-
Protocol Port Randomization", RFC6056, January 2011. Protocol Port Randomization", RFC6056, January 2011.
[RFC6438] Carpenter, B., Amante, S., "Using the Ipv6 Flow Label for [RFC6438] Carpenter, B., Amante, S., "Using the Ipv6 Flow Label for
Equal Cost Multipath Routing and Link Aggreation in Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC6438, November 2011. Tunnels", RFC6438, November 2011.
[RFC7042] Eastlake 3rd, D. and Abley, J., "IANA Considerations and [RFC7042] Eastlake 3rd, D. and Abley, J., "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802 IETF Protocol and Documentation Usage for IEEE 802
Parameter", RFC7042, October 2013. Parameter", RFC7042, October 2013.
[RFC7637] Garg, P. and Wang, Y., "NVGRE: Network Virtualization
Using Generic Routing Encapsulation", RFC7637, September
2015.
[RFC7676] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for [RFC7676] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for
Generic Routing Encapsulation (GRE)", RFC7676, October Generic Routing Encapsulation (GRE)", RFC7676, October
2015. 2015.
[CB] Fairhurst, G., "Network Transport Circuit Breakers",
draft-ietf-tsvwg-circuit-breaker-15, work in progress.
15. Authors' Addresses 15. Authors' Addresses
Lucy Yong Lucy Yong
Huawei Technologies, USA Huawei Technologies, USA
Email: lucy.yong@huawei.com Email: lucy.yong@huawei.com
Edward Crabbe Edward Crabbe
Oracle Oracle
 End of changes. 25 change blocks. 
80 lines changed or deleted 93 lines changed or added

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