draft-ietf-tsvwg-gre-in-udp-encap-06.txt   draft-ietf-tsvwg-gre-in-udp-encap-07.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 9, 2015 Expires: January 2015 July 4, 2015
GRE-in-UDP Encapsulation GRE-in-UDP Encapsulation
draft-ietf-tsvwg-gre-in-udp-encap-06 draft-ietf-tsvwg-gre-in-udp-encap-07
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 9, 2015. This Internet-Draft will expire on January 4, 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 35 skipping to change at page 2, line 35
3.2.2. Destination Port.....................................7 3.2.2. Destination Port.....................................7
3.2.3. Checksum.............................................7 3.2.3. Checksum.............................................7
3.2.4. Length...............................................8 3.2.4. Length...............................................8
3.3. GRE Header................................................8 3.3. GRE Header................................................8
4. Encapsulation Process Procedures...............................8 4. Encapsulation Process Procedures...............................8
4.1. MTU and Fragmentation.....................................9 4.1. MTU and Fragmentation.....................................9
4.2. Differentiated Services..................................10 4.2. Differentiated Services..................................10
5. UDP Checksum Handling.........................................10 5. UDP Checksum Handling.........................................10
5.1. UDP Checksum with IPv4...................................10 5.1. UDP Checksum with IPv4...................................10
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..................................21 12.2. Informative References..................................21
13. Authors' Addresses...........................................21 13. Authors' Addresses...........................................21
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], and the UDP header provides protocol type field [RFC2784][GREIPV6], and the UDP header provides
additional entropy by way of its source port. additional entropy by way of its source port. GRE-in-UDP offers the
additional possibility of using GRE across networks that might
otherwise disallow it; for instance GRE-in-UDP may be used to bridge
two islands where GRE is 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 1.1. Applicability Statement
GRE encapsulation is widely used for many applications. For example, GRE encapsulation is widely used for many applications. For example,
to redirect IP traffic to traverse a different path instead of the to redirect IP traffic to traverse a different path instead of the
default path in an operator network, to tunnel private network default path in an operator network, to tunnel private network
traffic over a public network by use of public IP network addresses, traffic over a public network by use of public IP network addresses,
to tunnel IPv6 traffic over an IPv4 network, and etc. to tunnel IPv6 traffic over an IPv4 network, tunnel Ethernet traffic
over IP networks, and etc.
When using GRE-in-UDP encapsulation, encapsulated traffic will be When using GRE-in-UDP encapsulation, encapsulated traffic will be
treated as a UDP application, not as a GRE application, in an IP treated as a UDP application in an IP network. Thus GRE-in-UDP
network. Thus GRE-in-UDP tunnel needs to meet UDP application tunnel needs to meet UDP application guidelines specified in
guidelines specified in [RFC5405bis], which can constrain GRE-in-UDP [RFC5405bis], which constrains GRE-in-UDP tunnel usage. The concerns
tunnel usage to certain applications and/or environments. of GRE-in-UDP as a UDP application are addressed in Section 5 and 6.
As a result, GRE-in-UDP encapsulation MUST be used when one of
Here is the list of the UDP application guidelines in [RFC5405bis] following conditions is true:
and corresponding Sections to cover it in this document.
o Congestion Control: GRE-in-UDP does not have congestion control
mechanism. The usage restrictions for traffic that is not
congestion control is specified in Section 6.
o Message Size: Address in Section 4.1
o Reliability: not applicable to a GRE-in-UDP tunnel. GRE-in-UDP
tunnel does not provide any reliable transport.
o Checksum: Address in Section 5. 1) Within a single operator network or networks of an adjacent set
of cooperating network operators where traffic is managed to
avoid congestion.
o Middlebox Traversal: Section 5.2.1. 2) The payload type is IP or a type of network protocol that has
congestion control capability when the encapsulated traffic is
over the Internet.
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. The tunneled traffic may use GRE-in- 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 UDP or other tunnel encapsulation. In this case, GRE-in-UDP tunnel
end points treat other tunnel endpoints as of the end hosts for the end points treat other tunnel endpoints as of the end hosts for the
traffic and do not differentiate such end hosts from other end hosts. 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.
skipping to change at page 8, line 29 skipping to change at page 8, line 29
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. checksum.
An implementation MAY use the GRE keyid to authenticate the An implementation MAY use the GRE keyid to authenticate the
encapsulator. In this model, a shared value is either configured or encapsulator. In this model, a shared value is either configured or
negotiated between an encapsulator and decapsulator. When a GRE-in- negotiated between an encapsulator and decapsulator. When a
UDP packet is received with the keyid present, it is checked to see encapsulated packet is received with the keyid present, it is
if it is valid for the source to have set for the tunnel packet was checked to see if it is valid for the source to have set for the
sent on. An implementation MAY enforce that a keyid be used for tunnel packet was sent on. An implementation MAY enforce that a
source authentication on selected tunnels. When a decapsulator keyid be used for source authentication on selected tunnels. When a
determines a presented keyid is not valid for the source to send or decapsulator determines a presented keyid is not valid for the
the keyid is absent and is considered required for authenticating source to send or the keyid is absent and is considered required for
the encapsulator for a tunnel, the packet MUST be dropped. authenticating the encapsulator for a tunnel, the packet MUST be
dropped.
4. Encapsulation Process Procedures 4. Encapsulation Process Procedures
The GRE-in-UDP encapsulation allows encapsulated packets to be The GRE-in-UDP encapsulation allows encapsulated packets to be
forwarded through "GRE-UDP tunnels". When performing GRE-in-UDP forwarded through "GRE-UDP tunnels". When performing GRE-in-UDP
encapsulation by the encapsulator, the entropy value would be encapsulation by the encapsulator, the entropy value would be
generated by the encapsulator and then be filled in the Source Port generated by the encapsulator and then be filled in the Source Port
field of the UDP header. The Destination Port field is set to a field of the UDP header. The Destination Port field is set to a
value (TBD) allocated by IANA to indicate that the UDP tunnel value (TBD) allocated by IANA to indicate that the UDP tunnel
payload is a GRE packet. The Protocol Type header field in GRE payload is a GRE packet. The Protocol Type header field in GRE
skipping to change at page 10, line 35 skipping to change at page 10, line 35
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
protected by other, possibly stronger mechanisms such as the protected by other, possibly stronger mechanisms 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 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.
5.2. UDP Checksum with IPv6 5.2. UDP Checksum with IPv6
skipping to change at page 13, line 36 skipping to change at page 13, line 36
occurrence of errors will result in some accumulation of error occurrence of errors will result in some accumulation of error
information outside the protocol for operational and management information outside the protocol for operational and management
purposes. This design is in accordance with requirement 4 specified purposes. This design is in accordance with requirement 4 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
middlebox discussion. middle box discussion.
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
skipping to change at page 17, line 18 skipping to change at page 17, line 18
Service Code: N/A Service Code: N/A
Known Unauthorized Uses: N/A Known Unauthorized Uses: N/A
Assignment Notes: N/A Assignment Notes: N/A
9. Security Considerations 9. Security Considerations
UDP and GRE encapsulation does not effect security for the payload UDP and GRE encapsulation does not effect security for the payload
protocol. When using GRE-in-UDP, Network Security in a network is protocol. When using GRE-in-UDP, Network Security in a network is
mostly equivalent to that of a network using GRE. mostly equivalent to that of a network using GRE.
DTLS [RFC6347] can be used for application security and can preserve Datagram Transport Layer Security (DTLS) [RFC6347] can be used for
network and transport layer protocol information. Specifically, if application security and can preserve network and transport layer
DTLS is used to secure the GRE-in-UDP tunnel, the destination port protocol information. Specifically, if DTLS is used to secure the
of the UDP header MUST be set to an IANA-assigned value (TBD2) GRE-in-UDP tunnel, the destination port of the UDP header MUST be
indicating GRE-in-UDP with DTLS, and that UDP port MUST NOT be used set to an IANA-assigned value (TBD2) indicating GRE-in-UDP with DTLS,
for other traffic. The UDP source port field can still be used to and that UDP port MUST NOT be used for other traffic. The UDP
add entropy, e.g., for load-sharing purposes. DTLS usage is limited source port field can still be used to add entropy, e.g., for load-
to a single DTLS session for any specific tunnel encapsulator/ sharing purposes. DTLS usage is limited to a single DTLS session
decapsulator pair (identified by source and destination IP for any specific tunnel encapsulator/ decapsulator pair (identified
addresses). Both IP addresses MUST be unicast addresses - multicast by source and destination IP addresses). Both IP addresses MUST be
traffic is not supported when DTLS is used. A GRE-in-UDP tunnel unicast addresses - multicast traffic is not supported when DTLS is
decapsulator implementation that supports DTLS is expected to be used. A GRE-in-UDP tunnel decapsulator implementation that supports
able to establish DTLS sessions with multiple tunnel encapsulators, DTLS is expected to be able to establish DTLS sessions with multiple
and likewise an GRE-in-UDP tunnel encapsulator implementation is tunnel encapsulators, and likewise an GRE-in-UDP tunnel encapsulator
expected to be able to establish DTLS sessions with multiple implementation is expected to be able to establish DTLS sessions
decapsulators (although different source and/or destination IP with multiple decapsulators (although different source and/or
addresses may be involved -see Section 5.2 for discussion of one destination IP addresses may be involved -see Section 5.2 for
situation where use of different source IP addresses is important). discussion of one 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.
In an instance where the UDP source port is not set based on the In an instance where the UDP source port is not set based on the
skipping to change at page 20, line 39 skipping to change at page 20, line 39
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983,
October 2000. October 2000.
[RFC5405bis] Eggert, L., "Unicast UDP Usage Guideline for [RFC5405bis] Eggert, L., "Unicast UDP Usage Guideline for
Application Designers", draft-ietf-tsvwg-rfc5405bis, work Application Designers", draft-ietf-tsvwg-rfc5405bis, work
in progress. in progress.
[RFC6040] Briscoe, B., "Tunneling of Explicit Congestion [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion
Notification", RFC6040, November 2010. Notification", RFC6040, November 2010.
[RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer
Security Version 1.2", RFC6347, 2012.
[RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for [RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for
Equal Cost Multipath Routing and Link Aggregation in Equal Cost Multipath Routing and Link Aggregation in
tunnels", RFC6438, November, 2011. tunnels", RFC6438, November, 2011.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, April 2013. UDP Checksums for Tunneled Packets", RFC 6935, April 2013.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, April 2013. RFC 6936, April 2013.
skipping to change at page 21, line 37 skipping to change at page 21, line 41
Protocol Port Randomization", RFC6056, January 2011. Protocol Port Randomization", RFC6056, January 2011.
[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.
[GREIPV6] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for
Generic Routing Encapsulation (GRE)", draft-ietf-intarea-
gre-ipv6, 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. 15 change blocks. 
53 lines changed or deleted 60 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/