draft-ietf-tsvwg-gre-in-udp-encap-05.txt   draft-ietf-tsvwg-gre-in-udp-encap-06.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: September 2015 March 6, 2015 Expires: September 2015 March 9, 2015
GRE-in-UDP Encapsulation GRE-in-UDP Encapsulation
draft-ietf-tsvwg-gre-in-udp-encap-05 draft-ietf-tsvwg-gre-in-udp-encap-06
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. Usage restrictions payload is identified by the GRE Protocol Type. Usage restrictions
apply to GRE-in-UDP usage for traffic that is not congestion apply to GRE-in-UDP usage for traffic that is not congestion
controlled and to UDP zero checksum usage with IPv6. controlled and to UDP zero checksum usage with IPv6.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 September 6, 2015. This Internet-Draft will expire on September 9, 2015.
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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
5.2. UDP Checksum with IPv6...................................10 5.2. UDP Checksum with IPv6...................................10
5.2.1. Middlebox Considerations ...........................14 5.2.1. Middlebox Considerations ...........................14
6. Congestion Considerations.....................................14 6. Congestion Considerations.....................................14
7. Backward Compatibility........................................16 7. Backward Compatibility........................................16
8. IANA Considerations...........................................16 8. IANA Considerations...........................................16
9. Security Considerations.......................................17 9. Security Considerations.......................................17
10. Acknowledgements.............................................18 10. Acknowledgements.............................................18
11. Contributors.................................................18 11. Contributors.................................................18
12. References...................................................20 12. References...................................................20
12.1. Normative References....................................20 12.1. Normative References....................................20
12.2. Informative References..................................20 12.2. Informative References..................................21
13. Authors' Addresses...........................................21 13. Authors' Addresses...........................................21
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
skipping to change at page 3, line 31 skipping to change at page 3, line 31
such as Generic Routing Encapsulation (GRE) [RFC2784], MPLS such as Generic Routing Encapsulation (GRE) [RFC2784], MPLS
[RFC4023] and L2TPv3 [RFC3931]. GRE is an increasingly popular [RFC4023] and L2TPv3 [RFC3931]. GRE is an increasingly popular
encapsulation choice. Unfortunately, use of common GRE endpoints may encapsulation choice. Unfortunately, use of common GRE endpoints may
reduce the entropy available for use in load balancing, especially reduce the entropy available for use in load balancing, especially
in environments where the GRE Key field [RFC2890] is not readily in environments where the GRE Key field [RFC2890] is not readily
available for use as entropy in forwarding decisions. 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], and the UDP header provides
additional entropy by way of its source port. additional entropy by way of its source port.
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 1.1. Applicability Statement
skipping to change at page 10, line 29 skipping to change at page 10, line 29
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. An [RFC768] and [RFC1122] for both transmit and receive. An
encapsulator MAY set the UDP checksum to zero for performance or encapsulator MAY set the UDP checksum to zero for performance or
implementation considerations. The IPv4 header includes a checksum implementation considerations. The IPv4 header includes a checksum
which protects against mis-delivery of the packet due to corruption which protects against mis-delivery of the packet due to corruption
of IP addresses. The UDP checksum potentially provides protection of IP addresses. The UDP checksum potentially provides protection
against corruption of the UDP header, GRE header, and GRE payload. against corruption of the UDP header, GRE header, and GRE payload.
Enabling or disabling the use of checksums is a deployment Enabling or disabling the use of checksums is a deployment
consideration that should take into account the risk and effects of consideration that should take into account the risk and effects of
packet corruption, and whether the packets in the network are packet corruption, and whether the packets in the network are
already adequately protected by other, possibly stronger mechanisms protected by other, possibly stronger mechanisms such as the
such as the Ethernet CRC. Ethernet CRC.
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
decapsularor SHOULD accept UDP packets with a zero checksum. A node decapsularor 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 13, line 47 skipping to change at page 13, line 47
It is worth to mention that the use of a zero UDP checksum should It is worth to mention 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 and without GRE sending similar packet using GRE-in-IPv6 without UDP and without GRE
checksums. checksums.
In summary, UDP zero-checksum mode for IPv6 is allowed to be used In summary, UDP zero-checksum mode for IPv6 is allowed to be used
with GRE-in-UDP when one of the three exceptions specified above with GRE-in-UDP when one of the three exceptions specified above
applies, provided that additional requirements stated above are applies, provided that additional requirements stated above are
complied with. Otherwise the UDP checksum MUST be used for IPv6 as complied with. Otherwise the UDP checksum MUST be used for IPv6 as
specified in [RFC768] and [RFC2460]. specified in [RFC768] and [RFC2460]. Use of GRE checksum favors non-
use of the UDP checksum.
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
skipping to change at page 17, line 34 skipping to change at page 17, line 34
add entropy, e.g., for load-sharing purposes. DTLS usage is limited add entropy, e.g., for load-sharing purposes. DTLS usage is limited
to a single DTLS session for any specific tunnel encapsulator/ to a single DTLS session for any specific tunnel encapsulator/
decapsulator pair (identified by source and destination IP decapsulator pair (identified by source and destination IP
addresses). Both IP addresses MUST be unicast addresses - multicast addresses). Both IP addresses MUST be unicast addresses - multicast
traffic is not supported when DTLS is used. A GRE-in-UDP tunnel traffic is not supported when DTLS is used. A GRE-in-UDP tunnel
decapsulator implementation that supports DTLS is expected to be decapsulator implementation 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 an GRE-in-UDP tunnel encapsulator implementation is and likewise an GRE-in-UDP tunnel encapsulator implementation is
expected to be able to establish DTLS sessions with multiple expected to be able to establish DTLS sessions with multiple
decapsulators (although different source and/or destination IP decapsulators (although different source and/or destination IP
addresses may be involved -see Section 4.2 for discussion of one addresses may be involved -see Section 5.2 for discussion of one
situation where use of different source IP addresses is important). situation where use of different source IP addresses is important).
Use of ICMP for signaling of the GRE-in-UDP encapsulation capability Use of ICMP for signaling of the GRE-in-UDP encapsulation capability
adds a security concern. Upon receiving an ICMP message and before adds a security concern. Upon receiving an ICMP message and before
taking an action on it, the ingress MUST validate the IP address taking an action on it, the ingress MUST validate the IP address
originating against tunnel egress address and MUST evaluate the originating against tunnel egress address and MUST evaluate the
packet header returned in the ICMP payload to ensure the source port packet header returned in the ICMP payload to ensure the source port
is the one used for this tunnel. The mechanism for performing this is the one used for this tunnel. The mechanism for performing this
validation is out of the scope of this document. validation is out of the scope of this document.
skipping to change at page 18, line 22 skipping to change at page 18, line 22
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
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 GRE header can cause a privacy and security concern
for some applications that rely on the key field for traffic
segregation. When GRE key field is used for privacy and security,
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
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, and many others for their review and valuable
input on this draft. 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.
skipping to change at page 21, line 24 skipping to change at page 21, line 29
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)", RFC MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
4023, March 2005. 4023, March 2005.
[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.
[GREIPV6] Pignataro, C., el al, "IPv6 Support for Generic Routing
Encapsulation (GRE)", draft-ietf-intarea-gre-ipv6-02, work
in progress.
[GREMTU] Bonica, R., "A Fragmentation Strategy for Generic Routing [GREMTU] Bonica, R., "A Fragmentation Strategy for Generic Routing
Encapsulation (GRE)", draft-ietf-intarea-gre-mtu, work in Encapsulation (GRE)", draft-ietf-intarea-gre-mtu, work in
progress. progress.
[CB] Fairhurst, G., "Network Transport Circuit Breakers", [CB] Fairhurst, G., "Network Transport Circuit Breakers",
draft-fairhurst-tsvwg-circuit-breaker-01, work in draft-fairhurst-tsvwg-circuit-breaker-01, work in
progress. progress.
13. Authors' Addresses 13. Authors' Addresses
skipping to change at page 21, line 50 skipping to change at page 22, line 4
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
Xiaohu Xu Xiaohu Xu
Huawei Technologies, Huawei Technologies,
Beijing, China Beijing, China
Email: xuxiaohu@huawei.com Email: xuxiaohu@huawei.com
Tom Herbert Tom Herbert
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA Mountain View, CA
Email : therbert@google.com Email : tom@herbertland.com
 End of changes. 13 change blocks. 
14 lines changed or deleted 18 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/