draft-ietf-6man-udpzero-11.txt   draft-ietf-6man-udpzero-12.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: August 25, 2013 Ericsson Expires: August 29, 2013 Ericsson
February 21, 2013 February 25, 2013
Applicability Statement for the use of IPv6 UDP Datagrams with Zero Applicability Statement for the use of IPv6 UDP Datagrams with Zero
Checksums Checksums
draft-ietf-6man-udpzero-11 draft-ietf-6man-udpzero-12
Abstract Abstract
This document provides an applicability statement for the use of UDP This document provides an applicability statement for the use of UDP
transport checksums with IPv6. It defines recommendations and transport checksums with IPv6. It defines recommendations and
requirements for the use of IPv6 UDP datagrams with a zero UDP requirements for the use of IPv6 UDP datagrams with a zero UDP
checksum. It describes the issues and design principles that need to checksum. It describes the issues and design principles that need to
be considered when UDP is used with IPv6 to support tunnel be considered when UDP is used with IPv6 to support tunnel
encapsulations and examines the role of the IPv6 UDP transport encapsulations and examines the role of the IPv6 UDP transport
checksum. The document also identifies issues and constraints for checksum. The document also identifies issues and constraints for
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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 August 25, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 27 skipping to change at page 2, line 27
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 5 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Motivation for new approaches . . . . . . . . . . . . 6 1.3.1. Motivation for new approaches . . . . . . . . . . . . 6
1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 6 1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 6
1.3.3. Need to inspect the entire packet . . . . . . . . . . 7 1.3.3. Need to inspect the entire packet . . . . . . . . . . 7
1.3.4. Interactions with middleboxes . . . . . . . . . . . . 7 1.3.4. Interactions with middleboxes . . . . . . . . . . . . 7
1.3.5. Support for load balancing . . . . . . . . . . . . . . 8 1.3.5. Support for load balancing . . . . . . . . . . . . . . 8
2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9
2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 9 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 9
2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 9 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 10
2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 10 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 10
2.4. Relation to UDP-Lite and UDP with checksum . . . . . . . . 10 2.4. Relation to UDP-Lite and UDP with checksum . . . . . . . . 10
3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 12 3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 12
3.1. Effect of packet modification in the network . . . . . . . 12 3.1. Effect of packet modification in the network . . . . . . . 13
3.1.1. Corruption of the destination IP address . . . . . . . 14 3.1.1. Corruption of the destination IP address . . . . . . . 14
3.1.2. Corruption of the source IP address . . . . . . . . . 14 3.1.2. Corruption of the source IP address . . . . . . . . . 15
3.1.3. Corruption of Port Information . . . . . . . . . . . . 16 3.1.3. Corruption of Port Information . . . . . . . . . . . . 16
3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 16 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 16
3.1.5. Corruption of Fragmentation Information . . . . . . . 17 3.1.5. Corruption of Fragmentation Information . . . . . . . 17
3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 19 3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 19
3.3. Validating the network path . . . . . . . . . . . . . . . 20 3.3. Validating the network path . . . . . . . . . . . . . . . 20
3.4. Applicability of method . . . . . . . . . . . . . . . . . 21 3.4. Applicability of method . . . . . . . . . . . . . . . . . 21
3.5. Impact on non-supporting devices or applications . . . . . 21 3.5. Impact on non-supporting devices or applications . . . . . 21
4. Constraints on implementation of IPv6 nodes supporting 4. Constraints on implementation of IPv6 nodes supporting
zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 22 zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Requirements on usage of the zero UDP checksum . . . . . . . . 23 5. Requirements on usage of the zero UDP checksum . . . . . . . . 24
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Evaluation of proposal to update RFC 2460 to Appendix A. Evaluation of proposal to update RFC 2460 to
support zero checksum . . . . . . . . . . . . . . . . 31 support zero checksum . . . . . . . . . . . . . . . . 31
A.1. Alternatives to the Standard Checksum . . . . . . . . . . 31 A.1. Alternatives to the Standard Checksum . . . . . . . . . . 31
A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 32 A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 33
A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 33 A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 33
A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 33 A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 34
A.2.3. Ingress and Egress Performance Implications . . . . . 34 A.2.3. Ingress and Egress Performance Implications . . . . . 34
A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 34 A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 34
A.2.5. Corruption Detection Strength . . . . . . . . . . . . 35 A.2.5. Corruption Detection Strength . . . . . . . . . . . . 35
A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 35 A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 35
Appendix B. Document Change History . . . . . . . . . . . . . . . 37 Appendix B. Document Change History . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The User Datagram Protocol (UDP) [RFC0768] transport is defined for The User Datagram Protocol (UDP) [RFC0768] transport is defined for
the Internet Protocol (IPv4) [RFC0791] and is defined in "Internet the Internet Protocol (IPv4) [RFC0791] and is defined in "Internet
Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The
UDP transport protocol has a minimal set of features. This limited UDP transport protocol has a minimal set of features. This limited
set has enabled a wide range of applications to use UDP, but these set has enabled a wide range of applications to use UDP, but these
application do need to provide many important transport functions on application do need to provide many important transport functions on
top of UDP. The UDP Usage Guidelines [RFC5405] provides overall top of UDP. The UDP Usage Guidelines [RFC5405] provides overall
skipping to change at page 6, line 32 skipping to change at page 6, line 32
o Reducing forwarding costs, motivated by redundancy present in the o Reducing forwarding costs, motivated by redundancy present in the
encapsulated packet header, since in tunnel encapsulations, encapsulated packet header, since in tunnel encapsulations,
payload integrity and length verification may be provided by payload integrity and length verification may be provided by
higher layer encapsulations (often using the IPv4, UDP, UDP-Lite, higher layer encapsulations (often using the IPv4, UDP, UDP-Lite,
or TCP checksums). or TCP checksums).
o Eliminating a need to access the entire packet when forwarding the o Eliminating a need to access the entire packet when forwarding the
packet by a tunnel endpoint. packet by a tunnel endpoint.
o Enhancing ability to traverse middleboxes, especially Network o Enhancing ability to traverse and function with middleboxes.
Address Translators, NATs. However, use of the zero UDP checksum
does not fully fulfill this need, because only certain classes of
middleboxes, (i.e. ones that do not modify or evaluate the UDP
checksum) will support zero UDP checksum traffic, other
middleboxes will require an update to support this traffic.
o A desire to use the port number space to enable load-sharing. o A desire to use the port number space to enable load-sharing.
1.3.2. Reducing forwarding cost 1.3.2. Reducing forwarding cost
It is a common requirement to terminate a large number of tunnels on It is a common requirement to terminate a large number of tunnels on
a single router/host. The processing cost per tunnel includes both a single router/host. The processing cost per tunnel includes both
state (memory requirements) and per-packet processing at the tunnel state (memory requirements) and per-packet processing at the tunnel
ingress and egress. ingress and egress.
skipping to change at page 7, line 43 skipping to change at page 7, line 38
prevents fast processing of a transport checksum over an entire prevents fast processing of a transport checksum over an entire
(large) packet. Hence the currently defined IPv6 UDP checksum is (large) packet. Hence the currently defined IPv6 UDP checksum is
poorly suited to use within a router that is unable to access the poorly suited to use within a router that is unable to access the
entire packet and does not provide checksum-offloading. Thus entire packet and does not provide checksum-offloading. Thus
enabling checksum calculation over the complete packet can impact enabling checksum calculation over the complete packet can impact
router design, performance improvement, energy consumption and/or router design, performance improvement, energy consumption and/or
cost. cost.
1.3.4. Interactions with middleboxes 1.3.4. Interactions with middleboxes
In IPv4, UDP-encapsulation may be desirable for NAT traversal, since Many paths in the Internet include one or more middleboxes of various
UDP support is commonly provided. It is also necessary due to the types. There exist large classes of middleboxes that will handle
almost ubiquitous deployment of IPv4 NATs. There has also been zero UDP checksum packets, which would not support UDP-Lite or the
discussion of NAT for IPv6, although not for the same reason as in other investigated proposals. These middleboxes includes load
IPv4. If IPv6 NAT becomes a reality they hopefully do not present balancers (see Section 1.3.5) including Equal Cost Multipath Routing,
the same protocol issues as for IPv4. If NAT is defined for IPv6, it traffic classifiers and other functions that reads some fields in the
should take into consideration the use of a zero UDP checksum. UDP headers but does not validate the UDP checksum.
There are also middleboxes that either validates or modify the UDP
checksum. The two most common classes are Firewalls and NATs. In
IPv4, UDP-encapsulation may be desirable for NAT traversal, since UDP
support is commonly provided. It is also necessary due to the almost
ubiquitous deployment of IPv4 NATs. There has also been discussion
of NAT for IPv6, although not for the same reason as in IPv4. If
IPv6 NAT becomes a reality they hopefully do not present the same
protocol issues as for IPv4. If NAT is defined for IPv6, it should
take into consideration the use of a zero UDP checksum.
The requirements for IPv6 firewall traversal are likely be to be The requirements for IPv6 firewall traversal are likely be to be
similar to those for IPv4. In addition, it can be reasonably similar to those for IPv4. In addition, it can be reasonably
expected that a firewall conforming to RFC 2460 will not regard expected that a firewall conforming to RFC 2460 will not regard
datagrams with a zero UDP checksum as valid. Use of a zero UDP datagrams with a zero UDP checksum as valid. Use of a zero UDP
checksum with IPv6 requires firewalls to be updated before the full checksum with IPv6 requires firewalls to be updated before the full
utility of the change is available. utility of the change is available.
It can be expected that datagrams with zero UDP checksum will It can be expected that datagrams with zero UDP checksum will
initially not have the same middlebox traversal characteristics as initially not have the same middlebox traversal characteristics as
skipping to change at page 20, line 22 skipping to change at page 20, line 25
packets that change the set of routers and middleboxes along a path. packets that change the set of routers and middleboxes along a path.
Therefore transports such as TCP, SCTP and DCCP have been designed to Therefore transports such as TCP, SCTP and DCCP have been designed to
negotiate protocol parameters, adapt to different network path negotiate protocol parameters, adapt to different network path
characteristics, and receive feedback to verify that the current path characteristics, and receive feedback to verify that the current path
is suited to the intended application. Applications using UDP and is suited to the intended application. Applications using UDP and
UDP-Lite need to provide their own mechanisms to confirm the validity UDP-Lite need to provide their own mechanisms to confirm the validity
of the current network path. of the current network path.
A zero value in the UDP checksum field is explicitly disallowed in A zero value in the UDP checksum field is explicitly disallowed in
RFC2460. Thus it may be expected that any device on the path that RFC2460. Thus it may be expected that any device on the path that
has a reason to look beyond the IP header will consider such a packet has a reason to look beyond the IP header, for example to validate
as erroneous or illegal and may discard it, unless the device is the UDP checksum, will consider such a packet as erroneous or illegal
updated to support the new behavior. A pair of end-points intending and may discard it, unless the device is updated to support the new
to use a new behavior will therefore not only need to ensure support behavior. Any middlebox that modifies the UDP checksum, for example
at each end-point, but also that the path between them will deliver a NAT that changes the values of the IP and UDP header in such a way
packets with the new behavior. This may require using negotiation or that the checksum over the pseudo header changes value, will need to
an explicit mandate to use the new behavior by all nodes that support be updated to support this behavior. Until then, a zero UDP checksum
the new protocol. packet is likely to be discarded either directly in the middlebox or
at the destination, when a zero UDP checksum has been modified to a
non-zero by an incremental update.
A pair of end-points intending to use a new behavior will therefore
not only need to ensure support at each end-point, but also that the
path between them will deliver packets with the new behavior. This
may require using negotiation or an explicit mandate to use the new
behavior by all nodes that support the new protocol.
Enabling the use of a zero checksum places new requirements on Enabling the use of a zero checksum places new requirements on
equipment deployed within the network, such as middleboxes. A equipment deployed within the network, such as middleboxes. A
middlebox (e.g. Firewalls, Network Address Translators) may enable middlebox (e.g. Firewalls, Network Address Translators) may enable
zero checksum usage for a particular range of ports. Note that zero checksum usage for a particular range of ports. Note that
checksum off-loading and operating system design may result in all checksum off-loading and operating system design may result in all
IPv6 UDP traffic being sent with a calculated checksum. This IPv6 UDP traffic being sent with a calculated checksum. This
requires middleboxes that are configured to enable a zero UDP requires middleboxes that are configured to enable a zero UDP
checksum to continue to work with bidirectional UDP flows that use a checksum to continue to work with bidirectional UDP flows that use a
zero UDP checksum in only one direction, and therefore they must not zero UDP checksum in only one direction, and therefore they must not
skipping to change at page 29, line 18 skipping to change at page 29, line 26
nodes and middleboxes must forward received UDP datagrams that have nodes and middleboxes must forward received UDP datagrams that have
either a calculated checksum or a zero checksum. either a calculated checksum or a zero checksum.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-6man-udpchecksums] [I-D.ietf-6man-udpchecksums]
Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", UDP Checksums for Tunneled Packets",
draft-ietf-6man-udpchecksums-07 (work in progress), draft-ietf-6man-udpchecksums-08 (work in progress),
January 2013. February 2013.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 15 change blocks. 
36 lines changed or deleted 49 lines changed or added

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