draft-ietf-6man-udpzero-12.txt   rfc6936.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force (IETF) G. Fairhurst
Internet-Draft University of Aberdeen Request for Comments: 6936 University of Aberdeen
Intended status: Standards Track M. Westerlund Category: Standards Track M. Westerlund
Expires: August 29, 2013 Ericsson ISSN: 2070-1721 Ericsson
February 25, 2013 April 2013
Applicability Statement for the use of IPv6 UDP Datagrams with Zero Applicability Statement for the Use of IPv6 UDP Datagrams
Checksums with Zero Checksums
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 it 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
deployment on network paths that include middleboxes. An appendix deployment on network paths that include middleboxes. An appendix
presents a summary of the trade-offs that were considered in presents a summary of the trade-offs that were considered in
evaluating the safety of the update to RFC 2460 that updates use of evaluating the safety of the update to RFC 2460 that changes the use
the UDP checksum with IPv6. of the UDP checksum with IPv6.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 29, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6936.
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 18 skipping to change at page 3, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 5 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 5 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 6
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 Costs . . . . . . . . . . . . . . 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 . . . . . . . 10 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. Relationship of Zero UDP Checksum to UDP-Lite and UDP
with Checksum . . . . . . . . . . . . . . . . . . . . . . 11
3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 12 3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 12
3.1. Effect of packet modification in the network . . . . . . . 13 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 Field . . . . 14
3.1.2. Corruption of the source IP address . . . . . . . . . 15 3.1.2. Corruption of the Source IP Address Field . . . . . . 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 . . . . . . . 18
3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 19 3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 20
3.3. Validating the network path . . . . . . . . . . . . . . . 20 3.3. Validating the Network Path . . . . . . . . . . . . . . . 20
3.4. Applicability of method . . . . . . . . . . . . . . . . . 21 3.4. Applicability of the Zero UDP Checksum Method . . . . . . 21
3.5. Impact on non-supporting devices or applications . . . . . 21 3.5. Impact on Non-Supporting Devices or Applications . . . . . 22
4. Constraints on implementation of IPv6 nodes supporting 4. Constraints on Implementation of IPv6 Nodes Supporting
zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 22 Zero Checksum . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Requirements on usage of the zero UDP checksum . . . . . . . . 24 5. Requirements on Usage of the Zero UDP Checksum . . . . . . . . 24
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix A. Evaluation of Proposal to Update RFC 2460 to
Support Zero Checksum . . . . . . . . . . . . . . . . 33
Appendix A. Evaluation of proposal to update RFC 2460 to A.1. Alternatives to the Standard Checksum . . . . . . . . . . 33
support zero checksum . . . . . . . . . . . . . . . . 31 A.2. Comparison of Alternative Methods . . . . . . . . . . . . 34
A.1. Alternatives to the Standard Checksum . . . . . . . . . . 31 A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 34
A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 33 A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 35
A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 33 A.2.3. Ingress and Egress Performance Implications . . . . . 36
A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 34 A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 36
A.2.3. Ingress and Egress Performance Implications . . . . . 34 A.2.5. Corruption Detection Strength . . . . . . . . . . . . 37
A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 34 A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 37
A.2.5. Corruption Detection Strength . . . . . . . . . . . . 35
A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 35
Appendix B. Document Change History . . . . . . . . . . . . . . . 38
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 IPv4 [RFC0791], and it is defined in "Internet Protocol, Version 6
Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The (IPv6)" [RFC2460] for IPv6 hosts and routers. The UDP transport
UDP transport protocol has a minimal set of features. This limited protocol has a minimal set of features. This limited set has enabled
set has enabled a wide range of applications to use UDP, but these a wide range of applications to use UDP, but these applications do
application do need to provide many important transport functions on need to provide many important transport functions on top of UDP.
top of UDP. The UDP Usage Guidelines [RFC5405] provides overall The UDP usage guidelines [RFC5405] provide overall guidance for
guidance for application designers, including the use of UDP to application designers, including the use of UDP to support tunneling.
support tunneling. The key difference between UDP usage with IPv4 The key difference between UDP usage with IPv4 and IPv6 is that RFC
and IPv6 is that RFC 2460 mandates use of a calculated UDP checksum, 2460 mandates use of a calculated UDP checksum, i.e., a non-zero
i.e. a non-zero value, due to the lack of an IPv6 header checksum. value, due to the lack of an IPv6 header checksum. The inclusion of
The inclusion of the pseudo header in the checksum computation the pseudo-header in the checksum computation provides a statistical
provides a statistical check that datagrams have been delivered to check that datagrams have been delivered to the intended IPv6
the intended IPv6 destination node. Algorithms for checksum destination node. Algorithms for checksum computation are described
computation are described in [RFC1071]. in [RFC1071].
The lack of a possibility to use an IPv6 datagram with a zero UDP The inability to use an IPv6 datagram with a zero UDP checksum has
checksum has been observed as a real problem for certain classes of been found to be a real problem for certain classes of application,
application, primarily tunnel applications. This class of primarily tunnel applications. This class of application has been
application has been deployed with a zero UDP checksum using IPv4. deployed with a zero UDP checksum using IPv4. The design of IPv6
The design of IPv6 raises different issues when considering the raises different issues when considering the safety of using a UDP
safety of using a UDP checksum with IPv6. These issues can checksum with IPv6. These issues can significantly affect
significantly affect applications, both when an endpoint is the applications, whether an endpoint is the intended user or an innocent
intended user and when an innocent bystander (when a packet is bystander (i.e., when a packet is received by a different endpoint to
received by a different endpoint to that intended). that intended).
This document examines the issues and an appendix compares the This document identifies a set of issues that must be considered and
strengths and weaknesses of a number of proposed solutions. This mitigated to enable safe deployment of IPv6 applications that use a
identifies a set of issues that must be considered and mitigated to zero UDP checksum. The appendix compares the strengths and
be able to safely deploy IPv6 applications that use a zero UDP weaknesses of a number of proposed solutions. The comparison of
checksum. The provided comparison of methods is expected to also be methods provided in this document is also expected to be useful when
useful when considering applications that have different goals from considering applications that have different goals from the ones
the ones that initiated the writing of this document, especially the whose needs led to the writing of this document, especially
use of already standardized methods. The analysis concludes that applications that can use existing standardized transport protocols.
using a zero UDP checksum is the best method of the proposed The analysis concludes that using a zero UDP checksum is the best
alternatives to meet the goals for certain tunnel applications. method of the proposed alternatives to meet the goals of certain
tunnel applications.
This document defines recommendations and requirements for use of This document defines recommendations and requirements for use of
IPv6 datagrams with a zero UDP checksum. This usage is expected to IPv6 datagrams with a zero UDP checksum. This usage is expected to
have initial deployment issues related to middleboxes, limiting the have initial deployment issues related to middleboxes, limiting the
usability more than desired in the currently deployed Internet. usability more than desired in the currently deployed Internet.
However, this limitation will be largest initially and will reduce as However, this limitation will be largest initially and will decrease
updates are provided in middleboxes that support the zero UDP as updates are provided in middleboxes that support the zero UDP
checksum for IPv6. The document therefore derives a set of checksum for IPv6. Therefore, in this document, we derive a set of
constraints required to ensure safe deployment of a zero UDP constraints required to ensure safe deployment of a zero UDP
checksum. checksum.
Finally, the document also identifies some issues that require future Finally, the document identifies some issues that require future
consideration and possibly additional research. consideration and possibly additional research.
1.1. Document Structure 1.1. Document Structure
Section 1 provides a background to key issues, and introduces the use Section 1 provides a background to key issues and introduces the use
of UDP as a tunnel transport protocol. of UDP as a tunnel transport protocol.
Section 2 describes a set of standards-track datagram transport Section 2 describes a set of standards-track datagram transport
protocols that may be used to support tunnels. protocols that may be used to support tunnels.
Section 3 discusses issues with a zero UDP checksum for IPv6. It Section 3 discusses issues with a zero UDP checksum for IPv6. It
considers the impact of corruption, the need for validation of the considers the impact of corruption, the need for validation of the
path and when it is suitable to use a zero UDP checksum. path, and when it is suitable to use a zero UDP checksum.
Section 4 is an applicability statement that defines requirements and Section 4 is an applicability statement that defines requirements and
recommendations on the implementation of IPv6 nodes that support the recommendations on the implementation of IPv6 nodes that support the
use of a zero UDP checksum. use of a zero UDP checksum.
Section 5 provides an applicability statement that defines Section 5 provides an applicability statement that defines
requirements and recommendations for protocols and tunnel requirements and recommendations for protocols and tunnel
encapsulations that are transported over an IPv6 transport that does encapsulations that are transported over an IPv6 transport that does
not perform a UDP checksum calculation to verify the integrity at the not perform a UDP checksum calculation to verify the integrity at the
transport endpoints. transport endpoints.
Section 6 provides the recommendations for standardization of zero Section 6 provides the recommendations for standardization of zero
UDP checksum with a summary of the findings and notes remaining UDP checksum, with a summary of the findings, and notes the remaining
issues needing future work. issues that need future work.
Appendix A evaluates the set of proposals to update the UDP transport Appendix A evaluates the set of proposals to update the UDP transport
behaviour and other alternatives intended to improve support for behavior and other alternatives intended to improve support for
tunnel protocols. It concludes by assessing the trade-offs of the tunnel protocols. It concludes by assessing the trade-offs of the
various methods, identifying advantages and disadvantages for each various methods and by identifying advantages and disadvantages for
method. each method.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3. Use of UDP Tunnels 1.3. Use of UDP Tunnels
One increasingly popular use of UDP is as a tunneling protocol, where One increasingly popular use of UDP is as a tunneling protocol, where
a tunnel endpoint encapsulates the packets of another protocol inside a tunnel endpoint encapsulates the packets of another protocol inside
UDP datagrams and transmits them to another tunnel endpoint. Using UDP datagrams and transmits them to another tunnel endpoint. Using
UDP as a tunneling protocol is attractive when the payload protocol UDP as a tunneling protocol is attractive when the payload protocol
is not supported by the middleboxes that may exist along the path, is not supported by the middleboxes that may exist along the path,
because many middleboxes support transmission using UDP. In this because many middleboxes support transmission using UDP. In this
use, the receiving endpoint decapsulates the UDP datagrams and use, the receiving endpoint decapsulates the UDP datagrams and
forwards the original packets contained in the payload [RFC5405]. forwards the original packets contained in the payload [RFC5405].
Tunnels establish virtual links that appear to directly connect Tunnels establish virtual links that appear to directly connect
locations that are distant in the physical Internet topology and can locations that are distant in the physical Internet topology, and
be used to create virtual (private) networks. they can be used to create virtual (private) networks.
1.3.1. Motivation for new approaches 1.3.1. Motivation for New Approaches
A number of tunnel encapsulations deployed over IPv4 have used the A number of tunnel encapsulations deployed over IPv4 have used the
UDP transport with a zero checksum. Users of these protocols expect UDP transport with a zero checksum. Users of these protocols expect
a similar solution for IPv6. a similar solution for IPv6.
A number of tunnel protocols are also currently being defined (e.g. A number of tunnel protocols are also currently being defined (e.g.,
Automated Multicast Tunnels, AMT [I-D.ietf-mboned-auto-multicast], Automated Multicast Tunnels [AMT] and Locator/Identifier Separation
and the Locator/Identifier Separation Protocol, LISP [LISP]). These Protocol (LISP) [RFC6830]). These protocols provided several
protocols motivated an update to IPv6 UDP checksum processing to motivations to update IPv6 UDP checksum processing so that it would
benefit from simpler checksum processing for various reasons: benefit from simpler checksum processing, including:
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, because 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). [RFC3828], or TCP checksums [RFC0793]).
o Eliminating a need to access the entire packet when forwarding the o Eliminating the need to access the entire packet when a tunnel
packet by a tunnel endpoint. endpoint forwards the packet.
o Enhancing ability to traverse and function with middleboxes. o Enhancing the ability to traverse and function with middleboxes.
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 Costs
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 or host. The processing cost per tunnel includes
state (memory requirements) and per-packet processing at the tunnel both state (memory requirements) and per-packet processing at the
ingress and egress. tunnel ingress and egress.
Automatic IP Multicast Tunneling, known as AMT Automatic IP Multicast Tunneling, known as AMT [AMT], currently
[I-D.ietf-mboned-auto-multicast] currently specifies UDP as the specifies UDP as the transport protocol for packets carrying tunneled
transport protocol for packets carrying tunneled IP multicast IP multicast packets. The current specification for AMT states that
packets. The current specification for AMT states that the UDP the UDP checksum in the outer packet header should be zero (see
checksum in the outer packet header should be zero (see Section 6.6 Section 6.6 of [AMT]). That section argues that the computation of
of [I-D.ietf-mboned-auto-multicast]). This argues that the an additional checksum is an unwarranted burden on nodes implementing
computation of an additional checksum is an unwarranted burden on lightweight tunneling protocols when an inner packet is already
nodes implementing lightweight tunneling protocols when an inner adequately protected. The AMT protocol needs to replicate a
packet is already adequately protected, . The AMT protocol needs to multicast packet to each gateway tunnel. In this case, the outer IP
replicate a multicast packet to each gateway tunnel. In this case, addresses are different for each tunnel; therefore, a different
the outer IP addresses are different for each tunnel and therefore pseudo-header must be built to form the header for each tunnel egress
require a different pseudo header to be built for each UDP replicated that receives replicated multicast packets.
encapsulation.
The argument concerning redundant processing costs is valid regarding The argument concerning redundant processing costs is valid regarding
the integrity of a tunneled packet. In some architectures (e.g. PC- the integrity of a tunneled packet. In some architectures (e.g., PC-
based routers), other mechanisms may also significantly reduce based routers), other mechanisms may also significantly reduce
checksum processing costs: There are implementations that have checksum processing costs. For example, there are implementations
optimised checksum processing algorithms, including the use of that have optimized checksum processing algorithms, including the use
checksum-offloading. This processing is readily available for IPv4 of checksum offloading. This processing is readily available for
packets at high line rates. Such processing may be anticipated for IPv4 packets at high line rates. Such processing may be anticipated
IPv6 endpoints, allowing receivers to reject corrupted packets for IPv6 endpoints, allowing receivers to reject corrupted packets
without further processing. However, there are certain classes of without further processing. However, for certain classes of tunnel
tunnel end-points where this off-loading is not available and endpoints, this off-loading is not available and is unlikely to
unlikely to become available in the near future. become available in the near future.
1.3.3. Need to inspect the entire packet 1.3.3. Need to Inspect the Entire Packet
The currently-deployed hardware in many routers uses a fast-path The currently deployed hardware in many routers uses a fast-path
processing that only provides the first n bytes of a packet to the processing that provides only the first n bytes of a packet to the
forwarding engine, where typically n <= 128. forwarding engine, where typically n <= 128.
When this design is used to support a tunnel ingress and egress, it When this design is used to support a tunnel ingress and egress, it
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 for 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 off-loading. 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, energy consumption, and cost.
cost.
1.3.4. Interactions with middleboxes 1.3.4. Interactions with Middleboxes
Many paths in the Internet include one or more middleboxes of various Many paths in the Internet include one or more middleboxes of various
types. There exist large classes of middleboxes that will handle types. Large classes of middleboxes will handle zero UDP checksum
zero UDP checksum packets, which would not support UDP-Lite or the packets, but do not support UDP-Lite or the other investigated
other investigated proposals. These middleboxes includes load proposals. These middleboxes include load balancers (see
balancers (see Section 1.3.5) including Equal Cost Multipath Routing, Section 1.3.5) including equal-cost multipath (ECMP) routing, traffic
traffic classifiers and other functions that reads some fields in the classifiers, and other functions that reads some fields in the UDP
UDP headers but does not validate the UDP checksum. headers but does not validate the UDP checksum.
There are also middleboxes that either validates or modify the UDP There are also middleboxes that either validate or modify the UDP
checksum. The two most common classes are Firewalls and NATs. In checksum. The two most common classes are firewalls and NATs. In
IPv4, UDP-encapsulation may be desirable for NAT traversal, since UDP IPv4, UDP encapsulation may be desirable for NAT traversal, because
support is commonly provided. It is also necessary due to the almost UDP support is commonly provided. It is also necessary due to the
ubiquitous deployment of IPv4 NATs. There has also been discussion almost ubiquitous deployment of IPv4 NATs. There has also been
of NAT for IPv6, although not for the same reason as in IPv4. If discussion of NAT for IPv6, although not for the same reason as in
IPv6 NAT becomes a reality they hopefully do not present the same IPv4. If IPv6 NAT becomes a reality, it hopefully will not present
protocol issues as for IPv4. If NAT is defined for IPv6, it should the same protocol issues as for IPv4. If NAT is defined for IPv6, it
take into consideration the use of a zero UDP checksum. 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 becomes 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
regular UDP (RFC 2460). However when implementations follow the regular UDP (RFC 2460). However, when implementations follow the
requirements specified in this document, we expect the traversal requirements specified in this document, we expect the traversal
capabilities to improve over time. We also note that deployment of capabilities to improve over time. We also note that deployment of
IPv6-capable middleboxes is still in its initial phases. Thus, it IPv6-capable middleboxes is still in its initial phases. Thus, it
might be that the number of non-updated boxes quickly become a very might be that the number of non-updated boxes quickly becomes a very
small percentage of the deployed middleboxes. small percentage of the deployed middleboxes.
1.3.5. Support for load balancing 1.3.5. Support for Load Balancing
The UDP port number fields have been used as a basis to design load- The UDP port number fields have been used as a basis to design load-
balancing solutions for IPv4. This approach has also been leveraged balancing solutions for IPv4. This approach has also been leveraged
for IPv6. An alternate method would be to utilise the IPv6 Flow for IPv6. An alternate method would be to utilize the IPv6 flow
Label [RFC6437] as a basis for entropy for load balancing. This label [RFC6437] as a basis for entropy for load balancing. This
would have the desirable effect of releasing IPv6 load-balancing would have the desirable effect of freeing IPv6 load-balancing
devices from the need to assume semantics for the use of the devices from the need to assume semantics for the use of the
transport port field and also works for all type of transport transport port field, and also, it works for all types of transport
protocols. protocols.
This use of the flow-label for load balancing is consistent with the This use of the Flow Label for load balancing is consistent with the
intended use, although further clarity was needed to ensure the field intended use, although further clarity was needed to ensure the field
can be consistently used for this purpose, therefore an updated IPv6 can be consistently used for this purpose. Therefore, an updated
Flow Label [RFC6437] and Equal-Cost Multi-Path routing usage, (ECMP) IPv6 flow label [RFC6437] and ECMP routing [RFC6438] usage were
[RFC6438] was produced. Router vendors could be encouraged to start specified. Router vendors could be encouraged to start using the
using the IPv6 Flow Label as a part of the flow hash, providing IPv6 Flow Label as a part of the flow hash, providing support for
support for ECMP without requiring use of UDP. ECMP without requiring use of UDP.
However, the method for populating the outer IPv6 header with a value However, the method for populating the outer IPv6 header with a value
for the flow label is not trivial: If the inner packet uses IPv6, for the flow label is not trivial. If the inner packet uses IPv6,
then the flow label value could be copied to the outer packet header. the flow label value could be copied to the outer packet header.
However, many current end-points set the flow label to a zero value
(thus no entropy). The ingress of a tunnel seeking to provide good However, many current endpoints set the flow label to a zero value
(thus, no entropy). The ingress of a tunnel seeking to provide good
entropy in the flow label field would therefore need to create a entropy in the flow label field would therefore need to create a
random flow label value and keep corresponding state, so that all random flow label value and keep corresponding state so that all
packets that were associated with a flow would be consistently given packets that were associated with a flow would be consistently given
the same flow label. Although possible, this complexity may not be the same flow label. Although possible, this complexity may not be
desirable in a tunnel ingress. desirable in a tunnel ingress.
The end-to-end use of flow labels for load balancing is a long-term The end-to-end use of flow labels for load balancing is a long-term
solution. Even if the usage of the flow label is clarified, there solution. Even if the usage of the flow label has been clarified,
would be a transition time before a significant proportion of end- there will be a transition time before a significant proportion of
points start to assign a good quality flow label to the flows that endpoints start to assign a good quality flow label to the flows that
they originate, with continued use of load balancing using the they originate. The use of load balancing using the transport header
transport header fields until any widespread deployment is finally fields would continue until any widespread deployment is finally
achieved. achieved.
2. Standards-Track Transports 2. Standards-Track Transports
The IETF has defined a set of transport protocols that may be The IETF has defined a set of transport protocols that may be
applicable for tunnels with IPv6. There are also a set of network applicable for tunnels with IPv6. There is also a set of network-
layer encapsulation tunnels such as IP-in-IP and GRE. These already layer encapsulation tunnels, such as IP-in-IP and Generic Routing
standardized solutions are discussed here prior to the issues, as Encapsulation (GRE). These solutions, which are already
background for the issue description and some comparison of where the standardized, are discussed first, before discussing the issues,
issue may already occur. because they provide background for the description of the issues and
allow some comparison with existing issues.
2.1. UDP with Standard Checksum 2.1. UDP with Standard Checksum
UDP [RFC0768] with standard checksum behaviour, as defined in RFC UDP [RFC0768] with standard checksum behavior, as defined in RFC
2460, has already been discussed. UDP usage guidelines are provided 2460, has already been discussed. UDP usage guidelines are provided
in [RFC5405]. in [RFC5405].
2.2. UDP-Lite 2.2. UDP-Lite
UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as UDP-Lite [RFC3828] offers an alternate transport to UDP and is
a proposed standard, RFC 3828. A MIB is defined in [RFC5097] and specified as a proposed standard, RFC 3828. A MIB is defined in
unicast usage guidelines in [RFC5405]. There is at least one open [RFC5097], and unicast usage guidelines are defined in [RFC5405].
source implementation as a part of the Linux kernel since version There has been at least one open-source implementation of UDP-Lite as
2.6.20. a part of the Linux kernel since version 2.6.20.
UDP-Lite provides a checksum with optional partial coverage. When UDP-Lite provides a checksum with an option for partial coverage.
using this option, a datagram is divided into a sensitive part When using this option, a datagram is divided into a sensitive part
(covered by the checksum) and an insensitive part (not covered by the (covered by the checksum) and an insensitive part (not covered by the
checksum). When the checksum covers the entire packet, UDP-Lite is checksum). When the checksum covers the entire packet, UDP-Lite is
fully equivalent with UDP, with the exception that it uses a fully equivalent with UDP, with the exception that it uses a
different value in the Next Header field in the IPv6 header. Errors/ different value in the Next Header field in the IPv6 header. Errors
corruption in the insensitive part will not cause the datagram to be or corruption in the insensitive part will not cause the datagram to
discarded by the transport layer at the receiving endpoint. A minor be discarded by the transport layer at the receiving endpoint. A
side-effect of using UDP-Lite is that this was specified for damage- minor side effect of using UDP-Lite is that it was specified for
tolerant payloads and some link-layers may employ different link damage-tolerant payloads, and some link layers may employ different
encapsulations when forwarding UDP-Lite segments (e.g. radio access link encapsulations when forwarding UDP-Lite segments (e.g., radio
bearers). Most link-layers will cover the insensitive part with the access bearers). Most link layers will cover the insensitive part
same strong layer 2 frame CRC that covers the sensitive part. with the same strong Layer 2 frame Cyclic Redundancy Check (CRC) that
covers the sensitive part.
2.2.1. Using UDP-Lite as a Tunnel Encapsulation 2.2.1. Using UDP-Lite as a Tunnel Encapsulation
Tunnel encapsulations can use UDP-Lite (e.g. Control And Tunnel encapsulations, such as Control And Provisioning of Wireless
Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP- Access Points (CAPWAP) [RFC5415], can use UDP-Lite, because it
Lite provides a transport-layer checksum, including an IP pseudo provides a transport-layer checksum, including an IP pseudo-header
header checksum, in IPv6, without the need for a router/middlebox to checksum, in IPv6, without the need for a router/middlebox to
traverse the entire packet payload. This provides most of the traverse the entire packet payload. This provides most of the
verification required for delivery and still keeps a low complexity verification required for delivery and still keeps a low complexity
for the checksumming operation. UDP-Lite may set the length of for the checksumming operation. UDP-Lite may set the length of
checksum coverage on a per packet basis. This feature could be used checksum coverage on a per-packet basis. This feature could be used
if a tunnel protocol is designed to only verify delivery of the if a tunnel protocol is designed to verify only delivery of the
tunneled payload and uses a calculated checksum for control tunneled payload and uses a calculated checksum for control
information. information.
There is currently poor support for middlebox traversal using UDP- Currently, support for middlebox traversal using UDP-Lite is poor,
Lite, because UDP-Lite uses a different IPv6 network-layer Next because UDP-Lite uses a different IPv6 network-layer Next Header
Header value to that of UDP, and few middleboxes are able to value than that used for UDP; therefore, few middleboxes are able to
interpret UDP-Lite and take appropriate actions when forwarding the interpret UDP-Lite and take appropriate actions when forwarding the
packet. This makes UDP-Lite less suited to protocols needing general packet. This makes UDP-Lite less suited to protocols needing general
Internet support, until such time that UDP-Lite has achieved better Internet support, until such time as UDP-Lite has achieved better
support in middleboxes and end-points. support in middleboxes and endpoints.
2.3. General Tunnel Encapsulations 2.3. General Tunnel Encapsulations
The IETF has defined a set of tunneling protocols or network layer The IETF has defined a set of tunneling protocols or network-layer
encapsulations, e.g., IP-in-IP and GRE. These either do not include encapsulations, e.g., IP-in-IP and GRE. These either do not include
a checksum or use a checksum that is optional, since tunnel a checksum or use a checksum that is optional, because tunnel
encapsulations are typically layered directly over the Internet layer encapsulations are typically layered directly over the Internet layer
(identified by the upper layer type in the IPv6 Next Header field) (identified by the upper layer type in the IPv6 Next Header field)
and are also not used as endpoint transport protocols. There is and because they are not used as endpoint transport protocols. There
little chance of confusing a tunnel-encapsulated packet with other is little chance of confusing a tunnel-encapsulated packet with other
application data that could result in corruption of application state application data. Such confusion could result in corruption of
or data. application state or data.
From the end-to-end perspective, the principal difference is that the From an end-to-end perspective, the principal difference between an
network-layer Next Header field identifies a separate transport, endpoint transport and a tunnel encapsulation is the value of the
which reduces the probability that corruption could result in the network-layer Next Header field. In the former, it identifies a
packet being delivered to the wrong endpoint or application. transport protocol that supports endpoint applications. In the
Specifically, packets are only delivered to protocol modules that latter, it identifies a tunnel protocol egress. This separation of
process a specific Next Header value. The Next Header field function reduces the probability that corruption of a tunneled packet
therefore provides a first-level check of correct demultiplexing. In could result in the packet being erroneously delivered to an
contrast, the UDP port space is shared by many diverse applications application. Specifically, packets are delivered only to protocol
and therefore UDP demultiplexing relies solely on the port numbers. modules that process a specific Next Header value. The Next Header
field therefore provides a first-level check of correct
demultiplexing. In contrast, the UDP port space is shared by many
diverse applications, and therefore, UDP demultiplexing relies solely
on the port numbers.
2.4. Relation to UDP-Lite and UDP with checksum 2.4. Relationship of Zero UDP Checksum to UDP-Lite and UDP with
Checksum
The operation of IPv6 with UDP with a zero-checksum is not the same The operation of IPv6 with UDP with a zero checksum is not the same
as IPv4 with UDP with a zero-checksum. Protocol designers should not as IPv4 with UDP with a zero checksum. Protocol designers should not
be fooled into thinking the two are the same. The requirements below be fooled into thinking that the two are the same. The requirements
list a set of additional considerations. below list a set of additional considerations for IPv6.
Where possible, existing general tunnel encapsulations, such as GRE, Where possible, existing general tunnel encapsulations, such as GRE
IP-in-IP, should be used. This section assumes that such existing and IP-in-IP, should be used. This section assumes that such
tunnel encapsulations do not offer the functionally required to existing tunnel encapsulations do not offer the functionally required
satisfy the protocol designer's goals. The section considers the to satisfy the protocol designer's goals. This section considers the
standardized alternative solutions, rather than the full set of ideas standardized alternative solutions rather than the full set of ideas
evaluated in Appendix A. The alternatives to UDP with a zero evaluated in Appendix A. The alternatives to UDP with a zero
checksum are UDP with a (calculated) checksum, and UDP-Lite. checksum are UDP with a (calculated) checksum and UDP-Lite.
UDP with a checksum has the advantage of close to universal support UDP with a checksum has the advantage of close to universal support
in both endpoints and middleboxes. It also provides statistical in both endpoints and middleboxes. It also provides statistical
verification of delivery to the intended destination (address and verification of delivery to the intended destination (address and
port). However, some classes of device have limited support for port). However, some classes of device have limited support for
calculation of a checksum that covers a full datagram. For these calculation of a checksum that covers a full datagram. For these
devices, this can incur significant processing cost (e.g. requiring devices, this limited support can incur significant processing costs
processing in the router slow-path) and can hence reduce capacity or (e.g., requiring processing in the router's slow path) and hence can
fail to function. reduce capacity or fail to function.
UDP-Lite has the advantage of using a checksum that is calculated UDP-Lite has the advantage of using a checksum that can be calculated
only over the pseudo header and the UDP header. This provides a only over the pseudo-header and the UDP header. This provides a
statistical verification of delivery to the intended destination statistical verification of delivery to the intended destination
(address and port). The checksum can be calculated without access to (address and port). The checksum can be calculated without access to
the datagram payload, only requiring access to the part to be the datagram payload, requiring access only to the part that is to be
protected. A drawback is that UDP-Lite has currently limited support protected. A drawback is that UDP-Lite currently has limited support
in both end-points (i.e. is not supported on all operating system in both endpoints (i.e., is not supported on all operating system
platforms) and middleboxes (that require support for the UDP-Lite platforms) and middleboxes (which must support the UDP-Lite header
header type). A path verification method is therefore recommended. type). Therefore, using a path verification method is recommended.
IPv6 and UDP with a zero-checksum can also be used by nodes that do IPv6 and UDP with a zero checksum can also be used by nodes that do
not permit calculation of a payload checksum. Many existing classes not permit calculation of a payload checksum. Many existing classes
of middleboxes do not verify or change the transport checksum. For of middleboxes do not verify or change the transport checksum. For
these middleboxes, IPv6 with a zero UDP checksum is expected to these middleboxes, IPv6 with a zero UDP checksum is expected to
function where UDP-Lite would not. However, support for the zero UDP function where UDP-Lite would not. However, support for the zero UDP
checksum in middleboxes that do change or verify the checksum is checksum in middleboxes that do change or verify the checksum is
currently limited, and this may result in datagrams with a zero UDP currently limited, and this may result in datagrams with a zero UDP
checksum being discarded, therefore a path verification method is checksum being discarded. Therefore, using a path verification
recommended. method is recommended.
There are sets of constrains for which no solution exist: A protocol For some sets of constraints, no solution exists. For example, a
designer that needs to originate or receive datagrams on a device protocol designer who needs to originate or receive datagrams on a
that can not efficiently calculate a checksum over a full datagram device that cannot efficiently calculate a checksum over a full
and also needs these packets to pass through a middlebox that datagram and also needs these packets to pass through a middlebox
verifies or changes a UDP checksum, but does not support a zero UDP that verifies or changes a UDP checksum, but that does not support a
checksum, can not use the zero UDP checksum method. Similarly, one zero UDP checksum, cannot use the zero UDP checksum method.
that originates datagrams on a device with UDP-Lite support, but Similarly, a protocol designer who needs to originate datagrams on a
needs the packets to pass through a middlebox that does not support device with UDP-Lite support, but needs the packets to pass through a
UDP-Lite, can not use UDP-Lite. For such cases, there is no optimal middlebox that does not support UDP-Lite, cannot use UDP-Lite. For
solution and the current recommendation is to use or fall-back to such cases, there is no optimal solution. The current recommendation
using UDP with full checksum coverage. is to use or fall back to using UDP with full checksum coverage.
3. Issues Requiring Consideration 3. Issues Requiring Consideration
This informative section evaluates issues around the proposal to This informative section evaluates issues about the proposal to
update IPv6 [RFC2460], to enable the UDP transport checksum to be set update IPv6 [RFC2460] to enable the UDP transport checksum to be set
to zero. Some of the identified issues are shared with other to zero. Some of the identified issues are common to other protocols
protocols already in use. The section also provides background to already in use. This section also provides background to help in
the requirements and recommendations that follow. understanding the requirements and recommendations that follow.
The decision in RFC 2460 to omit an integrity check at the network The decision in RFC 2460 to omit an integrity check at the network
level meant that the IPv6 transport checksum was overloaded with many level meant that the IPv6 transport checksum was overloaded with many
functions, including validating: functions, including validating:
o the endpoint address was not corrupted within a router, i.e., a o That the endpoint address was not corrupted within a router, i.e.,
packet was intended to be received by this destination and a packet was intended to be received by this destination, and that
validate that the packet does not consist of a wrong header the packet does not consist of a wrong header spliced to a
spliced to a different payload; different payload.
o that extension header processing is correctly delimited - i.e., o That extension header processing is correctly delimited, i.e., the
the start of data has not been corrupted. In this case, reception start of data has not been corrupted. In this case, reception of
of a valid Next Header value provides some protection; a valid Next Header value provides some protection.
o reassembly processing, when used; o Reassembly processing, when used.
o the length of the payload; o The length of the payload.
o the port values - i.e., the correct application receives the o The port values, i.e., the correct application receives the
payload (applications should also check the expected use of source payload. (Applications should also check the expected use of
ports/addresses); source ports/addresses.)
o the payload integrity. o The payload integrity.
In IPv4, the first four checks are performed using the IPv4 header In IPv4, the first four of these checks are performed using the IPv4
checksum. header checksum.
In IPv6, these checks occur within the endpoint stack using the UDP In IPv6, these checks occur within the endpoint stack using the UDP
checksum information. An IPv6 node also relies on the header checksum information. An IPv6 node also relies on the header
information to determine whether to send an ICMPv6 error message information to determine whether to send an ICMPv6 error message
[RFC4443] and to determine the node to which this is sent. Corrupted [RFC4443] and to determine the node to which this is sent. Corrupted
information may lead to misdelivery to an unintended application information may lead to misdelivery to an unintended application
socket on an unexpected host. socket on an unexpected host.
3.1. Effect of packet modification in the network 3.1. Effect of Packet Modification in the Network
IP packets may be corrupted as they traverse an Internet path. Older IP packets may be corrupted as they traverse an Internet path. Older
evidence in "When the CRC and TCP Checksum Disagree" [Sigcomm2000] evidence presented in "When the CRC and TCP Checksum Disagree"
show that this was once an issue in year 2000 with IPv4 routers, and [Sigcomm2000] shows that this was an issue with IPv4 routers in the
occasional corruption could result from bad internal router year 2000 and that occasional corruption could result from bad
processing in routers or hosts. These errors are not detected by the internal router processing in routers or hosts. These errors are not
strong frame checksums employed at the link-layer [RFC3819]. During detected by the strong frame checksums employed at the link layer
the development of this document in 2009, individuals provided [RFC3819]. During the development of this document in 2009, a number
reports of observed rates for received UDP datagrams using IPv4 where of individuals provided reports of observed rates for received UDP
the UDP checksum had been detected as corrupt. These rates where as datagrams using IPv4 where the UDP checksum had been detected as
high as 1.39E-4 for some paths, but also close to zero for some other corrupt. These rates were as high as 1.39E-4 for some paths, but
paths. close to zero for other paths.
There is extensive experience of deployment using tunnel protocols in There is extensive experience with deployments using tunnel protocols
well-managed networks (e.g. corporate networks or service provider in well-managed networks (e.g., corporate networks and service
core networks). This has shown the robustness of methods such as PWE provider core networks). This has shown the robustness of methods
and MPLS that do not employ a transport protocol checksum and have such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS that do not
not specified mechanisms to protect from corruption of the employ a transport protocol checksum and that have not specified
unprotected headers (such as the VPN Identifier in MPLS). Reasons mechanisms to protect from corruption of the unprotected headers
for the robustness may include: (such as the VPN Identifier in MPLS). Reasons for the robustness may
include:
o A reduced probability of corruption on paths through well-managed o A reduced probability of corruption on paths through well-managed
networks. networks.
o IP form the majority of the inner traffic carried by these tunnel. o IP forms the majority of the inner traffic carried by these
Hence from a transport perspective, endpoint verification is tunnels. Hence, from a transport perspective, endpoint
already being performed when processing a received IPv4 packet or verification is already being performed when a received IPv4
by the transport pseudo-header for an IPv6 packet. This update to packet is processed or by the transport pseudo-header for an IPv6
UDP does not change this behaviour. packet. This update to UDP does not change this behavior.
o In certain cases, a combination of additional filtering (e.g. o In certain cases, a combination of additional filtering (e.g.,
filter of a MAC destination address in a L2 tunnel) significantly filtering a MAC destination address in a Layer 2 tunnel)
reduces the probability of final mis-delivery to the IP stack. significantly reduces the probability of final misdelivery to the
IP stack.
o The tunnel protocols did not use a UDP transport header, any o The tunnel protocols did not use a UDP transport header.
corruption is therefore unlikely to result in misdelivery to Therefore, any corruption is unlikely to result in misdelivery to
another UDP-based application. This concern is specific to the another UDP-based application. This concern is specific to UDP
use of UDP with IPv6. with IPv6.
While this experience can guide the present recommendations, any While this experience can guide the present recommendations, any
update to UDP must preserve operation in the general Internet. This update to UDP must preserve operation in the general Internet, which
is heterogeneous and can include links and systems of very varying is heterogeneous and can include links and systems of widely varying
characteristics. Transport protocols used by hosts need to be characteristics. Transport protocols used by hosts need to be
designed with this in mind, especially when there is need to traverse designed with this in mind, especially when there is need to traverse
edge networks, where middlebox deployments are common. edge networks, where middlebox deployments are common.
For the general Internet, there is no current evidence that Currently, for the general Internet, there is no evidence that
corruption is rare, nor that this may not be applicable to IPv6. It corruption is rare, nor is there evidence that corruption in IPv6 is
therefore seems prudent not to relax checks on misdelivery . The rare. Therefore, it seems prudent not to relax checks on
emergence of low-end IPv6 routers and the proposed use of NAT with misdelivery. The emergence of low-end IPv6 routers and the proposed
IPv6 further motivate the need to protect from misdelivery. use of NAT with IPv6 provide further motivation to protect from
misdelivery.
Corruption in the network may result in: Corruption in the network may result in:
o A datagram being misdelivered to the wrong host/router or the o A datagram being misdelivered to the wrong host/router or the
wrong transport entity within an endpoint. Such a datagram needs wrong transport entity within an endpoint. Such a datagram needs
to be discarded; to be discarded.
o A datagram payload being corrupted, but still delivered to the o A datagram payload being corrupted, but still delivered to the
intended host/router transport entity. Such a datagram needs to intended host/router transport entity. Such a datagram needs to
be either discarded or correctly processed by an application that be either discarded or correctly processed by an application that
provides its own integrity checks; provides its own integrity checks.
o A datagram payload being truncated by corruption of the length o A datagram payload being truncated by corruption of the length
field. Such a datagram needs to be discarded. field. Such a datagram needs to be discarded.
When a checksum is used, this significantly reduces the impact of Using a checksum significantly reduces the impact of errors, reducing
errors, reducing the probability of undetected corruption of state the probability of undetected corruption of state (and data) on both
(and data) on both the host stack and the applications using the the host stack and the applications using the transport service.
transport service.
The following sections examine the impact of modifying each of these The following sections examine the effect of modifications to the
header fields. destination and source IP address fields, the port fields, and the
fragmentation information.
3.1.1. Corruption of the destination IP address 3.1.1. Corruption of the Destination IP Address Field
An IPv6 endpoint destination address could be modified in the network An IPv6 endpoint destination address could be modified in the
(e.g. corrupted by an error). This is not a concern for IPv4, network; for example, it could be corrupted by an error. This is not
because the IP header checksum will result in this packet being a concern for IPv4, because the IP header checksum will result in
discarded by the receiving IP stack. Such modification in the this packet being discarded by the receiving IP stack. When using
network can not be detected at the network layer when using IPv6. IPv6, however, such modification in the network cannot be detected at
Detection of this corruption by a UDP receiver relies on the IPv6 the network layer. Detection of this corruption by a UDP receiver
pseudo header incorporated in the transport checksum. relies on the IPv6 pseudo-header that is incorporated in the
transport checksum.
There are two possible outcomes: There are two possible outcomes:
o Delivery to a destination address that is not in use (the packet o Delivery to a destination address that is not in use. The packet
will not be delivered, but could result in an error report); will not be delivered, but an error report could be generated.
o Delivery to a different destination address. This modification o Delivery to a different destination address. This modification
will normally be detected by the transport checksum, resulting in will normally be detected by the transport checksum, resulting in
silent discard. Without a computed checksum, the packet would be a silent discard. Without a computed checksum, the packet would
passed to the endpoint port demultiplexing function. If an be passed to the endpoint port demultiplexing function. If an
application is bound to the associated ports, the packet payload application is bound to the associated ports, the packet payload
will be passed to the application (see the subsequent section on will be passed to the application. (See Section 3.1.4 on port
port processing). processing.)
3.1.2. Corruption of the source IP address 3.1.2. Corruption of the Source IP Address Field
This section examines what happens when the source address is This section examines what happens when the source IP address is
corrupted in transit. This is not a concern in IPv4, because the IP corrupted in transit. This is not a concern in IPv4, because the IP
header checksum will normally result in this packet being discarded header checksum will normally result in this packet being discarded
by the receiving IP stack. Detection of this corruption by a UDP by the receiving IP stack. Detection of this corruption by a UDP
receiver relies on the IPv6 pseudo header incorporated in the receiver relies on the IPv6 pseudo-header that is incorporated in the
transport checksum. transport checksum.
Corruption of an IPv6 source address does not result in the IP packet Corruption of an IPv6 source address does not result in the IP packet
being delivered to a different endpoint protocol or destination being delivered to a different endpoint protocol or destination
address. If only the source address is corrupted, the datagram will address. If only the source address is corrupted, the datagram will
likely be processed in the intended context, although with erroneous likely be processed in the intended context, although with erroneous
origin information. When using Unicast Reverse Path Forwarding origin information. When using unicast reverse path forwarding
[RFC2827], a change in address may result in the router discarding [RFC2827], a change in address may result in the router discarding
the packet when the route to the modified source address is different the packet when the route to the modified source address is different
to that of the source address of the original packet. from that of the source address of the original packet.
The result will depend on the application or protocol that processes The result will depend on the application or protocol that processes
the packet. Some examples are: the packet. Some examples are:
o An application that requires a per-established context may o An application that requires a pre-established context may
disregard the datagram as invalid, or could map this to another disregard the datagram as invalid or could map it to another
context (if a context for the modified source address was already context (if a context for the modified source address were already
activated). activated).
o A stateless application will process the datagram outside of any o A stateless application will process the datagram outside of any
context, a simple example is the ECHO server, which will respond context. A simple example is the ECHO server, which will respond
with a datagram directed to the modified source address. This with a datagram directed to the modified source address. This
would create unwanted additional processing load, and generate would create unwanted additional processing load and generate
traffic to the modified endpoint address. traffic to the modified endpoint address.
o Some datagram applications build state using the information from o Some datagram applications build state using the information from
packet headers. A previously unused source address would result packet headers. A previously unused source address would result
in receiver processing and the creation of unnecessary transport- in receiver processing and the creation of unnecessary transport-
layer state at the receiver. For example, Real Time Protocol layer state at the receiver. For example, Real-time Protocol
(RTP) [RFC3550] sessions commonly employ a source independent (RTP) [RFC3550] sessions commonly employ a source-independent
receiver port. State is created for each received flow. receiver port. State is created for each received flow.
Reception of a datagram with a corrupted source address will Therefore, reception of a datagram with a corrupted source address
therefore result in accumulation of unnecessary state in the RTP will result in the accumulation of unnecessary state in the RTP
state machine, including collision detection and response (since state machine, including collision detection and response (since
the same synchronization source, SSRC, value will appear to arrive the same synchronization source (SSRC) value will appear to arrive
from multiple source IP addresses). from multiple source IP addresses).
o ICMP messages relating to a corrupted packet can be misdirected to o ICMP messages relating to a corrupted packet can be misdirected to
the wrong source node. the wrong source node.
In general, the effect of corrupting the source address will depend In general, the effect of corrupting the source address will depend
upon the protocol that processes the packet and its robustness to upon the protocol that processes the packet and its robustness to
this error. For the case where the packet is received by a tunnel this error. For the case where the packet is received by a tunnel
endpoint, the tunnel application is expected to correctly handle a endpoint, the tunnel application is expected to correctly handle a
corrupted source address. corrupted source address.
The impact of source address modification is more difficult to The impact of source address modification is more difficult to
quantify when the receiving application is not that originally quantify when the receiving application is not the one originally
intended and several fields have been modified in transit. intended and several fields have been modified in transit.
3.1.3. Corruption of Port Information 3.1.3. Corruption of Port Information
This section describes what happens if one or both of the UDP port This section describes what happens if one or both of the UDP port
values are corrupted in transit. This can also happen with IPv4 is values are corrupted in transit. This can also happen when IPv4 is
used with a zero UDP checksum, but not when UDP checksums are used with a zero UDP checksum, but not when UDP checksums are
calculated or when UDP-Lite is used. If the ports carried in the calculated or when UDP-Lite is used. If the ports carried in the
transport header of an IPv6 packet were corrupted in transit, packets transport header of an IPv6 packet are corrupted in transit, packets
may be delivered to the wrong application process (on the intended may be delivered to the wrong application process (on the intended
machine) and/or responses or errors sent to the wrong application machine), responses or errors may be sent to the wrong application
process (on the intended machine). process (on the intended machine), or both may occur.
3.1.4. Delivery to an unexpected port 3.1.4. Delivery to an Unexpected Port
If one combines the corruption effects, such as destination address If one combines the corruption effects, such as a corrupted
and ports, there is a number of potential outcomes when traffic destination address and corrupted ports, there are a number of
arrives at an unexpected port. This section discusses these potential outcomes when traffic arrives at an unexpected port. The
possibilities and their outcomes for a packet that does not use the following are the possibilities and their outcomes for a packet that
UDP checksum validation: does not use UDP checksum validation:
o Delivery to a port that is not in use. The packet is discarded, o The packet could be delivered to a port that is not in use. The
but could generate an ICMPv6 message (e.g. port unreachable). packet is discarded, but could generate an ICMPv6 message (e.g.,
port unreachable).
o It could be delivered to a different node that implements the same o The packet could be delivered to a different node that implements
application, where the packet may be accepted, generating side- the same application, so the packet may be accepted, but side
effects or accumulated state. effects could occur or accumulated state could be generated.
o It could be delivered to an application that does not implement o The packet could be delivered to an application that does not
the tunnel protocol, where the packet may be incorrectly parsed, implement the tunnel protocol, so the packet may be incorrectly
and may be misinterpreted, generating side-effects or accumulated parsed and may be misinterpreted, causing side effects or
state. generating accumulated state.
The probability of each outcome depends on the statistical The probability of each outcome depends on the statistical
probability that the address or the port information for the source probability that the address or the port information for the source
or destination becomes corrupt in the datagram such that they match or destination becomes corrupted in the datagram such that they match
those of an existing flow or server port. Unfortunately, such a those of an existing flow or server port. Unfortunately, such a
match may be more likely for UDP than for connection-oriented match may be more likely for UDP than for connection-oriented
transports, because: transports, because:
1. There is no handshake prior to communication and no sequence 1. There is no handshake prior to communication and no sequence
numbers (as in TCP, DCCP, or SCTP). Together, this makes it hard numbers (as in TCP, Datagram Congestion Control Protocol (DCCP),
to verify that an application process is given only the and Stream Control Transmission Protocol (SCTP)). This makes it
hard to verify that an application process is given only the
application data associated with a specific transport session. application data associated with a specific transport session.
2. Applications writers often bind to wild-card values in endpoint 2. Applications writers often bind to wildcard values in endpoint
identifiers and do not always validate correctness of datagrams identifiers and do not always validate the correctness of
they receive (guidance on this topic is provided in [RFC5405]). datagrams they receive. (Guidance on this topic is provided in
[RFC5405].)
While these rules could, in principle, be revised to declare naive While these rules could, in principle, be revised to declare naive
applications as "Historic". This remedy is not realistic: the applications as "historic", this remedy is not realistic. The
transport owes it to the stack to do its best to reject bogus transport owes it to the stack to do its best to reject bogus
datagrams. datagrams.
If checksum coverage is suppressed, the application therefore needs If checksum coverage is suppressed, the application needs to provide
to provide a method to detect and discard the unwanted data. A a method to detect and discard the unwanted data. A tunnel protocol
tunnel protocol would need to perform its own integrity checks on any would need to perform its own integrity checks on any control
control information if transported in datagrams with a zero UDP information if it is transported in datagrams with a zero UDP
checksum. If the tunnel payload is another IP packet, the packets checksum. If the tunnel payload is another IP packet, the packets
requiring checksums can be assumed to have their own checksums requiring checksums can be assumed to have their own checksums,
provided that the rate of corrupted packets is not significantly provided that the rate of corrupted packets is not significantly
larger due to the tunnel encapsulation. If a tunnel transports other larger due to the tunnel encapsulation. If a tunnel transports other
inner payloads that do not use IP, the assumptions of corruption inner payloads that do not use IP, the assumptions of corruption
detection for that particular protocol must be fulfilled, this may detection for that particular protocol must be fulfilled. This may
require an additional checksum/CRC and/or integrity protection of the require an additional checksum/CRC and/or integrity protection of the
payload and tunnel headers. payload and tunnel headers.
A protocol that uses a zero UDP checksum can not assume that it is A protocol that uses a zero UDP checksum cannot assume that it is the
the only protocol using a zero UDP checksum. Therefore, it needs to only protocol using a zero UDP checksum. Therefore, it needs to
gracefully handle misdelivery. It must be robust to reception of handle misdelivery gracefully. It must be robust when malformed
malformed packets received on a listening port and expect that these packets are received on a listening port, and it must expect that
packets may contain corrupted data or data associated with a these packets may contain corrupted data or data associated with a
completely different protocol. completely different protocol.
3.1.5. Corruption of Fragmentation Information 3.1.5. Corruption of Fragmentation Information
The fragmentation information in IPv6 employs a 32-bit identity The fragmentation information in IPv6 employs a 32-bit identity field
field, compared to only a 16-bit field in IPv4, a 13-bit fragment (compared to only a 16-bit field in IPv4), a 13-bit fragment offset,
offset and a 1-bit flag, indicating if there are more fragments. and a 1-bit flag indicating whether there are more fragments.
Corruption of any of these field may result in one of two outcomes: Corruption of any of these fields may result in one of two outcomes:
Reassembly failure: An error in the "More Fragments" field for the o Reassembly failure: An error in the "More Fragments" field for the
last fragment will for example result in the packet never being last fragment will, for example, result in the packet never being
considered complete and will eventually be timed out and considered complete, so it will eventually be timed out and
discarded. A corruption in the ID field will result in the discarded. A corruption in the ID field will result in the
fragment not being delivered to the intended context thus leaving fragment not being delivered to the intended context, thus leaving
the rest incomplete, unless that packet has been duplicated prior the rest of the packet incomplete, unless that packet has been
to corruption. The incomplete packet will eventually be timed out duplicated before the corruption. The incomplete packet will
and discarded. eventually be timed out and discarded.
Erroneous reassembly: The re-assembled packet did not match the o Erroneous reassembly: The reassembled packet did not match the
original packet. This can occur when the ID field of a fragment original packet. This can occur when the ID field of a fragment
is corrupted, resulting in a fragment becoming associated with is corrupted, resulting in a fragment becoming associated with
another packet and taking the place of another fragment. another packet and taking the place of another fragment.
Corruption in the offset information can cause the fragment to be Corruption in the offset information can cause the fragment to be
misaligned in the reassembly buffer, resulting in incorrect misaligned in the reassembly buffer, resulting in incorrect
reassembly. Corruption can cause the packet to become shorter or reassembly. Corruption can cause the packet to become shorter or
longer, however completion of reassembly is much less probable, longer; however, completing the reassembly is much less probable,
since this would require consistent corruption of the IPv6 headers because this would require consistent corruption of the IPv6
payload length field and the offset field. The possibility of header's payload length and offset fields. To prevent erroneous
mis-assembly requires the reassembling stack to provide strong assembly, the reassembling stack must provide strong checks that
checks that detect overlap or missing data, note however that this detect overlap and missing data. Note, however, that this is not
is not guaranteed and has been clarified in "Handling of guaranteed and has been clarified in "Handling of Overlapping IPv6
Overlapping IPv6 Fragments" [RFC5722]. Fragments" [RFC5722].
The erroneous reassembly of packets is a general concern and such The erroneous reassembly of packets is a general concern, and such
packets should be discarded instead of being passed to higher layer packets should be discarded instead of being passed to higher-layer
processes. The primary detector of packet length changes is the IP processes. The primary detector of packet length changes is the IP
payload length field, with a secondary check by the transport payload length field, with a secondary check provided by the
checksum. The Upper-Layer Packet length field included in the pseudo transport checksum. The Upper-Layer Packet length field included in
header assists in verifying correct reassembly, since the Internet the pseudo-header assists in verifying correct reassembly, because
checksum has a low probability of detecting insertion of data or the Internet checksum has a low probability of detecting insertion of
overlap errors (due to misplacement of data). The checksum is also data or overlap errors (due to misplacement of data). The checksum
incapable of detecting insertion or removal of all zero-data that is also incapable of detecting insertion or removal of data that is
occurs in a multiple of a 16-bit chunk. all-zero in a chunk that is a multiple of 16 bits.
The most significant risk of corruption results following mis- The most significant risk of corruption results following mis-
association of a fragment with a different packet. This risk can be association of a fragment with a different packet. This risk can be
significant, since the size of fragments is often the same (e.g. significant, because the size of fragments is often the same (e.g.,
fragments resulting when the path MTU results in fragmentation of a fragments that form when the path MTU results in fragmentation of a
larger packet, common when addition of a tunnel encapsulation header larger packet, which is common when addition of a tunnel
expands the size of a packet). Detection of this type of error encapsulation header increases the size of a packet). Detection of
requires a checksum or other integrity check of the headers and the this type of error requires a checksum or other integrity check of
payload. Such protection is anyway desirable for tunnel the headers and the payload. While such protection is desirable for
encapsulations using IPv4, since the small fragmentation ID can tunnel encapsulations using IPv4, because the small fragmentation ID
easily result in wrap-around [RFC4963], this is especially the case can easily result in wraparound [RFC4963], this is especially
for tunnels that perform flow aggregation [I-D.ietf-intarea-tunnels]. desirable for tunnels that perform flow aggregation [TUNNELS].
Tunnel fragmentation behavior matters. There can be outer or inner Tunnel fragmentation behavior matters. There can be outer or inner
fragmentation "Tunnels in the Internet Architecture" fragmentation tunnels in the Internet Architecture [TUNNELS]. If
[I-D.ietf-intarea-tunnels]. If there is inner fragmentation by the there is inner fragmentation by the tunnel, the outer headers will
tunnel, the outer headers will never be fragmented and thus a zero never be fragmented, and thus, a zero UDP checksum in the outer
UDP checksum in the outer header will not affect the reassembly header will not affect the reassembly process. When a tunnel
process. When a tunnel performs outer header fragmentation, the performs outer header fragmentation, the tunnel egress needs to
tunnel egress needs to perform reassembly of the outer fragments into perform reassembly of the outer fragments into an inner packet. The
an inner packet. The inner packet is either a complete packet or a inner packet is either a complete packet or a fragment. If it is a
fragment. If it is a fragment, the destination endpoint of the fragment, the destination endpoint of the fragment will perform
fragment will perform reassembly of the received fragments. The reassembly of the received fragments. The complete packet or the
complete packet or the reassembled fragments will then be processed reassembled fragments will then be processed according to the packet
according to the packet Next Header field. The receiver may only Next Header field. The receiver may detect reassembly anomalies only
detect reassembly anomalies when it uses a protocol with a checksum. when it uses a protocol with a checksum. The larger the number of
The larger the number of reassembly processes to which a packet has reassembly processes to which a packet has been subjected, the
been subjected, the greater the probability of an error. greater the probability of an error. The following list describes
some tunnel fragmentation behaviors:
o An IP-in-IP tunnel that performs inner fragmentation has similar o An IP-in-IP tunnel that performs inner fragmentation has similar
properties to a UDP tunnel with a zero UDP checksum that also properties to a UDP tunnel with a zero UDP checksum that also
performs inner fragmentation. performs inner fragmentation.
o An IP-in-IP tunnel that performs outer fragmentation has similar o An IP-in-IP tunnel that performs outer fragmentation has similar
properties to a UDP tunnel with a zero UDP checksum that performs properties to a UDP tunnel with a zero UDP checksum that performs
outer fragmentation. outer fragmentation.
o A tunnel that performs outer fragmentation can result in a higher o A tunnel that performs outer fragmentation can result in a higher
level of corruption due to both inner and outer fragmentation, level of corruption due to both inner and outer fragmentation,
enabling more chances for reassembly errors to occur. enabling more chances for reassembly errors to occur.
o Recursive tunneling can result in fragmentation at more than one o Recursive tunneling can result in fragmentation at more than one
header level, even for inner fragmentation unless it goes to the header level, even for fragmentation of the encapsulated packet,
inner-most IP header. unless the fragmentation is performed on the innermost IP header.
o Unless there is verification at each reassembly, the probability o Unless there is verification at each reassembly, the probability
for undetected error will increase with the number of times of undetected errors will increase with the number of times
fragmentation is recursively applied, making IP-in-IP and UDP with fragmentation is recursively applied, making both IP-in-IP and UDP
zero UDP checksum both vulnerable to undetected errors. with zero UDP checksum vulnerable to undetected errors.
In conclusion, fragmentation of datagrams with a zero UDP checksum In conclusion, fragmentation of datagrams with a zero UDP checksum
does not worsen the performance compared to some other commonly used does not worsen the performance compared to some other commonly used
tunnel encapsulations. However, caution is needed for recursive tunnel encapsulations. However, caution is needed for recursive
tunneling without any additional verification at the different tunnel tunneling that offers no additional verification at the different
layers. tunnel layers.
3.2. Where Packet Corruption Occurs 3.2. Where Packet Corruption Occurs
Corruption of IP packets can occur at any point along a network path, Corruption of IP packets can occur at any point along a network path:
during packet generation, during transmission over the link, in the during packet generation, during transmission over the link, in the
process of routing and switching, etc. Some transmission steps process of routing and switching, etc. Some transmission steps
include a checksum or Cyclic Redundancy Check (CRC) that reduces the include a checksum or CRC that reduces the probability for corrupted
probability for corrupted packets being forwarded, but there still packets being forwarded, but there still exists a probability that
exists a probability that errors may propagate undetected. errors may propagate undetected.
Unfortunately the community lacks reliable information to identify
the most common functions or equipment that result in packet
corruption. However, there are indications that the place where
corruption occurs can vary significantly from one path to another.
There is therefore a risk in applying evidence from one domain of Unfortunately, the Internet community lacks reliable information to
usage to infer characteristics for another. Methods intended for identify the most common functions or equipment that results in
general Internet usage must therefore assume that corruption can packet corruption. However, there are indications that the place
occur and deploy mechanisms to mitigate the effect of corruption where corruption occurs can vary significantly from one path to
and/or resulting misdelivery. another. However, there is a risk in taking evidence from one usage
domain and using it to infer characteristics for another. Methods
intended for general Internet usage must therefore assume that
corruption can occur, and mechanisms must be deployed to mitigate the
effects of corruption and any resulting misdelivery.
3.3. Validating the network path 3.3. Validating the Network Path
IP transports designed for use in the general Internet should not IP transports designed for use in the general Internet should not
assume specific path characteristics. Network protocols may reroute assume specific path characteristics. Network protocols may reroute
packets that change the set of routers and middleboxes along a path. packets, thus changing the set of routers and middleboxes along a
Therefore transports such as TCP, SCTP and DCCP have been designed to path. Therefore, transports such as TCP, SCTP, and DCCP have been
negotiate protocol parameters, adapt to different network path designed to negotiate protocol parameters, adapt to different network
characteristics, and receive feedback to verify that the current path path characteristics, and receive feedback to verify that the current
is suited to the intended application. Applications using UDP and path is suited to the intended application. Applications using UDP
UDP-Lite need to provide their own mechanisms to confirm the validity and UDP-Lite need to provide their own mechanisms to confirm the
of the current network path. validity 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 RFC 2460. Thus, it may be expected that any device on the path that
has a reason to look beyond the IP header, for example to validate has a reason to look beyond the IP header, for example, to validate
the UDP checksum, will consider such a packet as erroneous or illegal the UDP checksum, will consider such a packet as erroneous or illegal
and may discard it, unless the device is updated to support the new and may discard it, unless the device is updated to support the new
behavior. Any middlebox that modifies the UDP checksum, for example behavior. Any middlebox that modifies the UDP checksum, for example,
a NAT that changes the values of the IP and UDP header in such a way a NAT that changes the values of the IP and UDP header in such a way
that the checksum over the pseudo header changes value, will need to that the checksum over the pseudo-header changes value, will need to
be updated to support this behavior. Until then, a zero UDP checksum be updated to support this behavior. Until then, a zero UDP checksum
packet is likely to be discarded either directly in the middlebox or 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 at the destination, when a zero UDP checksum has been modified to be
non-zero by an incremental update. non-zero by an incremental update.
A pair of end-points intending to use a new behavior will therefore A pair of endpoints intending to use the new behavior will therefore
not only need to ensure support at each end-point, but also that the need not only to ensure support at each endpoint, but also to ensure
path between them will deliver packets with the new behavior. This that the path between them will deliver packets with the new
may require using negotiation or an explicit mandate to use the new behavior. This may require using negotiation or an explicit mandate
behavior by all nodes that support the new protocol. 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., a firewall or NAT) may enable zero checksum usage
zero checksum usage for a particular range of ports. Note that for a particular range of ports. Note that checksum off-loading and
checksum off-loading and operating system design may result in all operating system design may result in all IPv6 UDP traffic being sent
IPv6 UDP traffic being sent with a calculated checksum. This with a calculated checksum. This requires middleboxes that are
requires middleboxes that are configured to enable a zero UDP configured to enable a zero UDP checksum to continue to work with
checksum to continue to work with bidirectional UDP flows that use a bidirectional UDP flows that use a zero UDP checksum in only one
zero UDP checksum in only one direction, and therefore they must not direction, and therefore, they must not maintain separate state for a
maintain separate state for a UDP flow based on its checksum usage. UDP flow based on its checksum usage.
Support along the path between end points can be guaranteed in Support along the path between endpoints can be guaranteed in limited
limited deployments by appropriate configuration. In general, it can deployments by appropriate configuration. In general, it can be
be expected to take time for deployment of any updated behaviour to expected to take time for deployment of any updated behavior to
become ubiquitous. become ubiquitous.
A sender will need to probe the path to verify the expected behavior. A sender will need to probe the path to verify the expected behavior.
Path characteristics may change, and usage therefore should be robust Path characteristics may change, and usage therefore should be robust
and able to detect a failure of the path under normal usage and re- and able to detect a failure of the path under normal usage, and
negotiate. Note that a bidirectional path does not necessarily should be able to renegotiate. Note that a bidirectional path does
support the same checksum usage in both the forward and return not necessarily support the same checksum usage in both the forward
directions: Receipt of a datagram with a zero UDP checksum, does not and return directions. Receipt of a datagram with a zero UDP
imply that the remote endpoint can also receive a datagram with a checksum does not imply that the remote endpoint can also receive a
zero UDP checksum. This will require periodic validation of the datagram with a zero UDP checksum. This behavior will require
path, adding complexity to any solution using the new behavior. periodic validation of the path, adding complexity to any solution
using the new behavior.
3.4. Applicability of method 3.4. Applicability of the Zero UDP Checksum Method
The update to the IPv6 specification defined in The update to the IPv6 specification defined in [RFC6935] modifies
[I-D.ietf-6man-udpchecksums] only modifies IPv6 nodes that implement only IPv6 nodes that implement specific protocols designed to permit
specific protocols designed to permit omission of a UDP checksum. omission of a UDP checksum. This document provides an applicability
This document therefore provides an applicability statement for the statement for the updated method, indicating when the mechanism can
updated method indicating when the mechanism can (and can not) be (and cannot) be used. Enabling a zero UDP checksum, and ensuring
used. Enabling this, and ensuring correct interactions with the correct interactions with the stack, implies much more than simply
stack, implies much more than simply disabling the checksum algorithm disabling the checksum algorithm for specific packets at the
for specific packets at the transport interface. transport interface.
When the method is widely available, it may be expected to be used by When the zero UDP checksum method is widely available, we expect that
applications that are perceived to gain benefit. Any solution that it will be used by applications that perceive to gain benefit from
uses an end-to-end transport protocol, rather than an IP-in-IP it. Any solution that uses an end-to-end transport protocol rather
encapsulation, needs to minimise the possibility that application than an IP-in-IP encapsulation needs to minimize the possibility that
processes could confuse a corrupted or wrongly delivered UDP datagram application processes could confuse a corrupted or wrongly delivered
with that of data addressed to the application running on their UDP datagram with that of data addressed to the application running
endpoint. on their endpoint.
The protocol or application that uses the zero checksum method must A protocol or application that uses the zero UDP checksum method must
ensure that the lack of checksum does not affect the protocol ensure that the lack of checksum does not affect the protocol
operation. This includes being robust to receiving a unintended operation. This includes being robust to receiving an unintended
packet from another protocol or context following corruption of a packet from another protocol or context following corruption of a
destination or source address and/or port value. It also includes destination or source address and/or port value. It also includes
considering the need for additional implicit protection mechanisms considering the need for additional implicit protection mechanisms
required when using the payload of a UDP packet received with a zero required when using the payload of a UDP packet received with a zero
checksum. checksum.
3.5. Impact on non-supporting devices or applications 3.5. Impact on Non-Supporting Devices or Applications
It is important to consider the potential impact of using a zero UDP It is important to consider the potential impact of using a zero UDP
checksum on end-point devices or applications that are not modified checksum on endpoint devices and applications that are not modified
to support the new behavior or by default or preference, use the to support the new behavior or, by default or preference, do not use
regular behavior. These applications must not be significantly the regular behavior. These applications must not be significantly
impacted by the update. impacted by the update.
To illustrate why this necessary, consider the implications of a node To illustrate why this necessary, consider the implications of a node
that enables use of a zero UDP checksum at the interface level: This that enables use of a zero UDP checksum at the interface level. This
would result in all applications that listen to a UDP socket would result in all applications that listen to a UDP socket
receiving datagrams where the checksum was not verified. This could receiving datagrams where the checksum was not verified. This could
have a significant impact on an application that was not designed have a significant impact on an application that was not designed
with the additional robustness needed to handle received packets with with the additional robustness needed to handle received packets with
corruption, creating state or destroying existing state in the corruption, creating state or destroying existing state in the
application. application.
A zero UDP checksum therefore needs to be enabled only for individual Therefore, a zero UDP checksum needs to be enabled only for
ports using an explicit request by the application. In this case, individual ports using an explicit request by the application. In
applications using other ports would maintain the current IPv6 this case, applications using other ports would maintain the current
behavior, discarding incoming datagrams with a zero UDP checksum. IPv6 behavior, discarding incoming datagrams with a zero UDP
These other applications would not be affected by this changed checksum. These other applications would not be affected by this
behavior. An application that allows the changed behavior should be changed behavior. An application that allows the changed behavior
aware of the risk of corruption and the increased level of should be aware of the risk of corruption and the increased level of
misdirected traffic, and can be designed robustly to handle this misdirected traffic, and can be designed robustly to handle this
risk. risk.
4. Constraints on implementation of IPv6 nodes supporting zero checksum 4. Constraints on Implementation of IPv6 Nodes Supporting Zero Checksum
This section is an applicability statement that defines requirements This section is an applicability statement that defines requirements
and recommendations on the implementation of IPv6 nodes that support and recommendations for the implementation of IPv6 nodes that support
use of a zero value in the checksum field of a UDP datagram. the use of a zero value in the checksum field of a UDP datagram.
All implementations that support this zero UDP checksum method MUST All implementations that support the zero UDP checksum method MUST
conform to the requirements defined below. conform to the requirements defined below:
1. An IPv6 sending node MAY use a calculated RFC 2460 checksum for 1. An IPv6 sending node MAY use a calculated RFC 2460 checksum for
all datagrams that it sends. This explicitly permits an all datagrams that it sends. This explicitly permits an
interface that supports checksum offloading to insert an updated interface that supports checksum off-loading to insert an
UDP checksum value in all UDP datagrams that it forwards, updated UDP checksum value in all UDP datagrams that it
however note that sending a calculated checksum requires the forwards. Note, however, that sending a calculated checksum
receiver to also perform the checksum calculation. Checksum requires the receiver to also perform the checksum calculation.
offloading can normally be switched off for a particular Checksum off-loading can normally be switched off for a
interface to ensure that datagrams are sent with a zero UDP particular interface to ensure that datagrams are sent with a
checksum. zero UDP checksum.
2. IPv6 nodes SHOULD by default NOT allow the zero UDP checksum 2. IPv6 nodes SHOULD, by default, NOT allow the zero UDP checksum
method for transmission. method for transmission.
3. IPv6 nodes MUST provide a way for the application/protocol to 3. IPv6 nodes MUST provide a way for the application/protocol to
indicate the set of ports that will be enabled to send datagrams indicate the set of ports that will be enabled to send datagrams
with a zero UDP checksum. This may be implemented by enabling a with a zero UDP checksum. This may be implemented by enabling a
transport mode using a socket API call when the socket is transport mode using a socket API call when the socket is
established, or a similar mechanism. It may also be implemented established, or by a similar mechanism. It may also be
by enabling the method for a pre-assigned static port used by a implemented by enabling the method for a pre-assigned static
specific tunnel protocol. port used by a specific tunnel protocol.
4. IPv6 nodes MUST provide a method to allow an application/ 4. IPv6 nodes MUST provide a method to allow an application/
protocol to indicate that a particular UDP datagram is required protocol to indicate that a particular UDP datagram is required
to be sent with a UDP checksum. This needs to be allowed by the to be sent with a UDP checksum. This needs to be allowed by the
operating system at any time (e.g. to send keep-alive operating system at any time (e.g., to send keepalive
datagrams), not just when a socket is established in the zero datagrams), not just when a socket is established in zero
checksum mode. checksum mode.
5. The default IPv6 node receiver behaviour MUST discard all IPv6 5. The default IPv6 node receiver behavior MUST be to discard all
packets carrying datagrams with a zero UDP checksum. IPv6 packets carrying datagrams with a zero UDP checksum.
6. IPv6 nodes MUST provide a way for the application/protocol to 6. IPv6 nodes MUST provide a way for the application/protocol to
indicate the set of ports that will be enabled to receive indicate the set of ports that will be enabled to receive
datagrams with a zero UDP checksum. This may be implemented via datagrams with a zero UDP checksum. This may be implemented via
a socket API call, or similar mechanism. It may also be a socket API call or by a similar mechanism. It may also be
implemented by enabling the method for a pre-assigned static implemented by enabling the method for a pre-assigned static
port used by a specific tunnel protocol. port used by a specific tunnel protocol.
7. IPv6 nodes supporting usage of zero UDP checksums MUST also 7. IPv6 nodes supporting usage of zero UDP checksums MUST also
allow reception using a calculated UDP checksum on all ports allow reception using a calculated UDP checksum on all ports
configured to allow zero UDP checksum usage. (The sending configured to allow zero UDP checksum usage. (The sending
endpoint, e.g. encapsulating ingress, may choose to compute the endpoint, e.g., the encapsulating ingress, may choose to compute
UDP checksum, or may calculate this by default.) The receiving the UDP checksum or may calculate it by default.) The receiving
endpoint MUST use the reception method specified in RFC2460 when endpoint MUST use the reception method specified in RFC2460 when
the checksum field is not zero. the checksum field is not zero.
8. RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams 8. RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams
with a zero UDP checksum. This remains the case for any with a zero UDP checksum. This remains the case for any
datagram received on a port that does not explicitly enable datagram received on a port that does not explicitly enable
processing of a zero UDP checksum. A port for which the zero processing of a zero UDP checksum. A port for which the zero
UDP checksum has been enabled MUST NOT log the datagram solely UDP checksum has been enabled MUST NOT log the datagram solely
because the checksum value is zero. because the checksum value is zero.
9. IPv6 nodes MAY separately identify received UDP datagrams that 9. IPv6 nodes MAY separately identify received UDP datagrams that
are discarded with a zero UDP checksum. It SHOULD NOT add these are discarded with a zero UDP checksum. They SHOULD NOT add
to the standard log, since the endpoint has not been verified. these to the standard log, because the endpoint has not been
This may be used to support other functions (such as a security verified. This may be used to support other functions (such as
policy). a security policy).
10. IPv6 nodes that receive ICMPv6 messages that refer to packets 10. IPv6 nodes that receive ICMPv6 messages that refer to packets
with a zero UDP checksum MUST provide appropriate checks with a zero UDP checksum MUST provide appropriate checks
concerning the consistency of the reported packet to verify that concerning the consistency of the reported packet to verify that
the reported packet actually originated from the node, before the reported packet actually originated from the node, before
acting upon the information (e.g. validating the address and acting upon the information (e.g., validating the address and
port numbers in the ICMPv6 message body). port numbers in the ICMPv6 message body).
5. Requirements on usage of the zero UDP checksum 5. Requirements on Usage of the Zero UDP Checksum
This section is an applicability statement that identifies This section is an applicability statement that identifies
requirements and recommendations for protocols and tunnel requirements and recommendations for protocols and tunnel
encapsulations that are transported over an IPv6 transport flow (e.g. encapsulations that are transported over an IPv6 transport flow
tunnel) that does not perform a UDP checksum calculation to verify (e.g., a tunnel) that does not perform a UDP checksum calculation to
the integrity at the transport endpoints. Before deciding to use the verify the integrity at the transport endpoints. Before deciding to
zero UDP checksum and loose the integrity verification provided, a use the zero UDP checksum and lose the integrity verification
protocol developer should seriously consider if they can use provided by non-zero checksumming, a protocol developer should
checksummed UDP packets or UDP-Lite [RFC3828], because IPv6 with a seriously consider if they can use checksummed UDP packets or UDP-
zero UDP checksum is not equivalent in behavior to IPv4 with zero UDP Lite [RFC3828], because IPv6 with a zero UDP checksum is not
checksum. equivalent in behavior to IPv4 with zero UDP checksum.
The requirements and recommendations for protocols and tunnel The requirements and recommendations for protocols and tunnel
encapsulations using an IPv6 transport flow that does not perform a encapsulations using an IPv6 transport flow that does not perform a
UDP checksum calculation to verify the integrity at the transport UDP checksum calculation to verify the integrity at the transport
endpoints are: endpoints are:
1. Transported protocols that enable the use of zero UDP checksum 1. Transported protocols that enable the use of zero UDP checksum
MUST only enable this for a specific port or port-range. This MUST enable this only for a specific port or port range. This
needs to be enabled at the sending and receiving endpoints for a needs to be enabled at the sending and receiving endpoints for a
UDP flow. UDP flow.
2. An integrity mechanism is always RECOMMENDED at the transported 2. An integrity mechanism is always RECOMMENDED at the transported
protocol layer to ensure that corruption rates of the delivered protocol layer to ensure that corruption rates of the delivered
payload is not increased (e.g. the inner-most packet of a UDP payload are not increased (e.g., at the innermost packet of a
tunnel). A mechanism that isolates the causes of corruption UDP tunnel). A mechanism that isolates the causes of corruption
(e.g. identifying misdelivery, IPv6 header corruption, tunnel (e.g., identifying misdelivery, IPv6 header corruption, or
header corruption) is expected to also provide additional tunnel header corruption) is also expected to provide additional
information about the status of the tunnel (e.g. to suggest a information about the status of the tunnel (e.g., to suggest a
security attack). security attack).
3. A transported protocol that encapsulates Internet Protocol (IPv4 3. A transported protocol that encapsulates Internet Protocol (IPv4
or IPv6) packets MAY rely on the inner packet integrity checks, or IPv6) packets MAY rely on the inner packet integrity checks,
provided that the tunnel protocol will not significantly provided that the tunnel protocol will not significantly
increase the rate of corruption of the inner IP packet. If a increase the rate of corruption of the inner IP packet. If a
significantly increased corruption rate can occur, then the significantly increased corruption rate can occur, the tunnel
tunnel protocol MUST provide an additional integrity protocol MUST provide an additional integrity verification
verification mechanism. Early detection is desirable to avoid mechanism. Early detection is desirable to avoid wasting
wasting unnecessary computation, transmission capacity or unnecessary computation, transmission capacity, or storage for
storage for packets that will subsequently be discarded. packets that will subsequently be discarded.
4. A transported protocol that supports use of a zero UDP checksum, 4. A transported protocol that supports the use of a zero UDP
MUST be designed so that corruption of this information does not checksum MUST be designed so that corruption of any header
result in accumulated state for the protocol. information does not result in accumulation of incorrect state
for the protocol.
5. A transported protocol with a non-tunnel payload or one that 5. A transported protocol with a non-tunnel payload or one that
encapsulates non-IP packets MUST have a CRC or other mechanism encapsulates non-IP packets MUST have a CRC or other mechanism
for checking packet integrity, unless the non-IP packet is for checking packet integrity, unless the non-IP packet is
specifically designed for transmission over a lower layer that specifically designed for transmission over a lower layer that
does not provide a packet integrity guarantee. does not provide a packet integrity guarantee.
6. A transported protocol with control feedback SHOULD be robust to 6. A transported protocol with control feedback SHOULD be robust to
changes in the network path, since the set of middleboxes on a changes in the network path, because the set of middleboxes on a
path may vary during the life of an association. The UDP path may vary during the life of an association. The UDP
endpoints need to discover paths with middleboxes that drop endpoints need to discover paths with middleboxes that drop
packets with a zero UDP checksum. Therefore, transported packets with a zero UDP checksum. Therefore, transported
protocols SHOULD send keep-alive messages with a zero UDP protocols SHOULD send keepalive messages with a zero UDP
checksum. An endpoint that discovers an appreciable loss rate checksum. An endpoint that discovers an appreciable loss rate
for keep-alive packets MAY terminate the UDP flow (e.g. tunnel). for keepalive packets MAY terminate the UDP flow (e.g., a
Section 3.1.3 of RFC 5405 describes requirements for congestion tunnel). Section 3.1.3 of RFC 5405 describes requirements for
control when using a UDP-based transport. congestion control when using a UDP-based transport.
7. A protocol with control feedback that can fall-back to using UDP 7. A protocol with control feedback that can fall back to using UDP
with a calculated RFC 2460 checksum is expected to be more with a calculated RFC 2460 checksum is expected to be more
robust to changes in the network path. Therefore, keep-alive robust to changes in the network path. Therefore, keepalive
messages SHOULD include both UDP datagrams with a checksum and messages SHOULD include both UDP datagrams with a checksum and
datagrams with a zero UDP checksum. This will enable the remote datagrams with a zero UDP checksum. This will enable the remote
endpoint to distinguish between a path failure and dropping of endpoint to distinguish between a path failure and the dropping
datagrams with a zero UDP checksum. of datagrams with a zero UDP checksum.
8. A middlebox implementation MUST allow forwarding of an IPv6 UDP 8. A middlebox implementation MUST allow forwarding of an IPv6 UDP
datagram with both a zero and standard UDP checksum using the datagram with both a zero and a standard UDP checksum using the
same UDP port. same UDP port.
9. A middlebox MAY configure a restricted set of specific port 9. A middlebox MAY configure a restricted set of specific port
ranges that forward UDP datagrams with a zero UDP checksum. The ranges that forward UDP datagrams with a zero UDP checksum. The
middlebox MAY drop IPv6 datagrams with a zero UDP checksum that middlebox MAY drop IPv6 datagrams with a zero UDP checksum that
are outside a configured range. are outside a configured range.
10. When a middlebox forwards an IPv6 UDP flow containing datagrams 10. When a middlebox forwards an IPv6 UDP flow containing datagrams
with both a zero and standard UDP checksum, the middlebox MUST with both a zero and a standard UDP checksum, the middlebox MUST
NOT maintain separate state for flows depending on the value of NOT maintain separate state for flows, depending on the value of
their UDP checksum field. (This requirement is necessary to their UDP checksum field. (This requirement is necessary to
enable a sender that always calculates a checksum to communicate enable a sender that always calculates a checksum to communicate
via a middlebox with a remote endpoint that uses a zero UDP via a middlebox with a remote endpoint that uses a zero UDP
checksum.) checksum.)
Special considerations are required when designing a UDP tunnel Special considerations are required when designing a UDP tunnel
protocol, where the tunnel ingress or egress may be a router that may protocol where the tunnel ingress or egress may be a router that may
not have access to the packet payload. When the node is acting as a not have access to the packet payload. When the node is acting as a
host (i.e., sending or receiving a packet addressed to itself), the host (i.e., sending or receiving a packet addressed to itself), the
checksum processing is similar to other hosts. However, when the checksum processing is similar to other hosts. However, when the
node (e.g. a router) is acting as a tunnel ingress or egress that node (e.g., a router) is acting as a tunnel ingress or egress that
forwards a packet to or from a UDP tunnel, there may be restricted forwards a packet to or from a UDP tunnel, there may be restricted
access to the packet payload. This prevents calculating (or access to the packet payload. This prevents calculating (or
verifying) a UDP checksum. In this case, the tunnel protocol may use verifying) a UDP checksum. In this case, the tunnel protocol may use
a zero UDP checksum and must: a zero UDP checksum and must:
o Ensure that tunnel ingress and tunnel egress router are both o Ensure that tunnel ingress and tunnel egress router are both
configured to use a zero UDP checksum. For example, this may configured to use a zero UDP checksum. For example, this may
include ensuring that hardware checksum offloading is disabled. include ensuring that hardware checksum off-loading is disabled.
o The tunnel operator must ensure that middleboxes on the network o The tunnel operator must ensure that middleboxes on the network
path are updated to support use of a zero UDP checksum. path are updated to support use of a zero UDP checksum.
o A tunnel egress should implement appropriate security techniques o A tunnel egress should implement appropriate security techniques
to protect from overload, including source address filtering to to protect from overload, including source address filtering to
prevent traffic injection by an attacker, and rate-limiting of any prevent traffic injection by an attacker and rate-limiting of any
packets that incur additional processing, such as UDP datagrams packets that incur additional processing, such as UDP datagrams
used for control functions that require verification of a used for control functions that require verification of a
calculated checksum to verify the network path. Usage of common calculated checksum to verify the network path. Usage of common
control traffic for multiple tunnels between a pair of nodes can control traffic for multiple tunnels between a pair of nodes can
assist in reducing the number of packets to be processed. assist in reducing the number of packets to be processed.
6. Summary 6. Summary
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. transport checksums with IPv6.
It examines the role of the UDP transport checksum when used with It examines the role of the UDP transport checksum when used with
IPv6 and presents a summary of the trade-offs in evaluating the IPv6 and presents a summary of the trade-offs in evaluating the
safety of updating RFC 2460 to permit an IPv6 endpoint to use a zero safety of updating RFC 2460 to permit an IPv6 endpoint to use a zero
UDP checksum field to indicate that no checksum is present. UDP checksum field to indicate that no checksum is present.
Application designers should first examine whether their transport Application designers should first examine whether their transport
goals may be met using standard UDP (with a calculated checksum) or goals may be met using standard UDP (with a calculated checksum) or
by using UDP-Lite. The use of UDP with a zero UDP checksum has UDP-Lite. The use of UDP with a zero UDP checksum has merits for
merits for some applications, such as tunnel encapsulation, and is some applications, such as tunnel encapsulation, and is widely used
widely used in IPv4. However, there are different dangers for IPv6: in IPv4. However, there are different dangers for IPv6. There is an
There is an increased risk of corruption and misdelivery when using increased risk of corruption and misdelivery when using zero UDP
zero UDP checksum in IPv6 compared to using IPv4 due to the lack of checksum in IPv6 compared to using IPv4 due to the lack of an IPv6
an IPv6 header checksum. Thus, applications need to evaluate the header checksum. Thus, application designers need to evaluate the
risks of enabling use of a zero UDP checksum and consider a solution risks of enabling use of a zero UDP checksum and consider a solution
that at least provides the same delivery protection as for IPv4, for that at least provides the same delivery protection as for IPv4, for
example by utilizing UDP-Lite, or by enabling the UDP checksum. The example, by utilizing UDP-Lite or by enabling the UDP checksum. The
use of checksum off-loading may help alleviate the cost of checksum use of checksum off-loading may help alleviate the cost of checksum
processing and permit use of a checksum using method defined in RFC processing and permit use of a checksum using method defined in RFC
2460. 2460.
Tunnel applications using UDP for encapsulation can in many cases use Tunnel applications using UDP for encapsulation can, in many cases,
a zero UDP checksum without significant impact on the corruption use a zero UDP checksum without significant impact on the corruption
rate. A well-designed tunnel application should include consistency rate. A well-designed tunnel application should include consistency
checks to validate the header information encapsulated with a checks to validate the header information encapsulated with a
received packet. In most cases, tunnels encapsulating IP packets can received packet. In most cases, tunnels encapsulating IP packets can
rely on the integrity protection provided by the transported protocol rely on the integrity protection provided by the transported protocol
(or tunneled inner packet). When correctly implemented, such an (or tunneled inner packet). When correctly implemented, such an
endpoint will not be negatively impacted by omission of the endpoint will not be negatively impacted by the omission of the
transport-layer checksum. Recursive tunneling and fragmentation is a transport-layer checksum. Recursive tunneling and fragmentation are
potential issue that can raise corruption rates significantly, and potential issues that can raise corruption rates significantly, and
requires careful consideration. they require careful consideration.
Other UDP applications at the intended destination node or another Other UDP applications at the intended destination node or another
node can be impacted if they are allowed to receive datagrams that node can be impacted if the nodes are allowed to receive datagrams
have a zero UDP checksum. It is important that already deployed that have a zero UDP checksum. It is important that already deployed
applications are not impacted by a change at the transport layer. If applications are not impacted by a change at the transport layer. If
these applications execute on nodes that implement RFC 2460, they these applications execute on nodes that implement RFC 2460, they
will discard (and log) all datagrams with a zero UDP checksum. This will discard (and log) all datagrams with a zero UDP checksum. This
is not an issue. is not an issue.
In general, UDP-based applications need to employ a mechanism that In general, UDP-based applications need to employ a mechanism that
allows a large percentage of the corrupted packets to be removed allows a large percentage of the corrupted packets to be removed
before they reach an application, both to protect the data stream of before they reach an application, to protect both the data stream of
the application and the control plane of higher layer protocols. the application and the control plane of higher layer protocols.
These checks are currently performed by the UDP checksum for IPv6, or These checks are currently performed by the UDP checksum for IPv6 or
the reduced checksum for UDP-Lite when used with IPv6. by the reduced checksum for UDP-Lite when used with IPv6.
The transport of recursive tunneling and the use of fragmentation The transport of recursive tunneling and the use of fragmentation
pose difficult issues that need to be considered in the design of pose difficult issues that need to be considered in the design of
tunnel protocols. There is an increased risk of an error in the tunnel protocols. There is an increased risk of an error in the
inner-most packet when fragmentation when several layers of tunneling innermost packet when fragmentation occurs across several layers of
and several different reassembly processes are run without tunneling and several different reassembly processes are run without
verification of correctness. This requires extra thought and careful verification of correctness. This requires extra thought and careful
consideration in the design of transported tunnels. consideration in the design of transported tunnels.
Any use of the updated method must consider the implications on Any use of the updated method must consider the implications for
firewalls, NATs and other middleboxes. It is not expected that IPv6 firewalls, NATs, and other middleboxes. It is not expected that IPv6
NATs handle IPv6 UDP datagrams in the same way that they handle IPv4 NATs will handle IPv6 UDP datagrams in the same way that they handle
UDP datagrams. In many deployed cases this will require an update to IPv4 UDP datagrams. In many deployed cases, an update to support an
support an IPv6 zero UDP checksum. Firewalls are intended to be IPv6 zero UDP checksum will be required. Firewalls are intended to
configured, and therefore may need to be explicitly updated to allow be configured, and therefore, they may need to be explicitly updated
new services or protocols. IPv6 middlebox deployment is not yet as to allow new services or protocols. Deployment of IPv6 middleboxes
prolific as it is in IPv4, and therefore new devices are expected to is not yet as prolific as it is in IPv4, and therefore, new devices
follow the methods specified in this document. are expected to follow the methods specified in this document.
Each application should consider the implications of choosing an IPv6 Each application should consider the implications of choosing an IPv6
transport that uses a zero UDP checksum, and consider whether other transport that uses a zero UDP checksum and should consider whether
standard methods may be more appropriate, and may simplify other standard methods may be more appropriate and may simplify
application design. application design.
7. Acknowledgements 7. Security Considerations
Brian Haberman, Brian Carpenter, Margaret Wasserman, Lars Eggert,
others in the TSV directorate. Barry Leiba, Ronald Bonica, Pete
Resnick, and Stewart Bryant are thanked for resulting in a document
with much greater applicability. Thanks to P.F. Chimento for careful
review and editorial corrections.
Thanks also to: Remi Denis-Courmont, Pekka Savola, Glen Turner, and
many others who contributed comments and ideas via the 6man, behave,
lisp and mboned lists.
8. IANA Considerations
This document does not require any actions by IANA.
9. Security Considerations
Transport checksums provide the first stage of protection for the Transport checksums provide the first stage of protection for the
stack, although they can not be considered authentication mechanisms. stack, although they cannot be considered authentication mechanisms.
These checks are also desirable to ensure packet counters correctly These checks are also desirable to ensure that packet counters
log actual activity, and can be used to detect unusual behaviours. correctly log actual activity, and they can be used to detect unusual
behaviors.
Depending on the hardware design, the processing requirements may Depending on the hardware design, the processing requirements may
differ for tunnels that have a zero UDP checksum and those that differ for tunnels that have a zero UDP checksum and those that
calculate a checksum. This processing overhead may need to be calculate a checksum. This processing overhead may need to be
considered when deciding whether to enable a tunnel and to determine considered when deciding whether to enable a tunnel and to determine
an acceptable rate for transmission. This can become a security risk an acceptable rate for transmission. This can become a security risk
for designs that can handle a significantly larger number of packets for designs that can handle a significantly larger number of packets
with zero UDP checksums compared to datagrams with a non-zero with zero UDP checksums compared to datagrams with a non-zero
checksum, such as tunnel egress. An attacker could attempt to inject checksum, such as a tunnel egress. An attacker could attempt to
non-zero checksummed UDP packets into a tunnel forwarding zero inject non-zero checksummed UDP packets into a tunnel that is
checksum UDP packets and cause overload in the processing of the non- forwarding zero checksum UDP packets and cause overload in the
zero checksums, e.g. if this happens in a routers slow path. processing of the non-zero checksums, e.g., if it happens in a
Protection mechanisms should therefore be employed when this threat router's slow path. Protection mechanisms should therefore be
exists. Protection may include source address filtering to prevent employed when this threat exists. Protection may include source-
an attacker injecting traffic, as well as throttling the amount of address filtering to prevent an attacker from injecting traffic, as
non-zero checksum traffic. The latter may impact the function of the well as throttling the amount of non-zero checksum traffic. The
tunnel protocol. latter may impact the functioning of the tunnel protocol.
Transmission of IPv6 packets with a zero UDP checksum could reveal Transmission of IPv6 packets with a zero UDP checksum could reveal
additional information to an on-path attacker to identify the additional information to help an on-path attacker identify the
operating system or configuration of a sending node. There is a need operating system or configuration of a sending node. There is a need
to probe the network path to determine whether the current path to probe the network path to determine whether the current path
supports using IPv6 packets with a zero UDP checksum. The details of supports the use of IPv6 packets with a zero UDP checksum. The
the probing mechanism may differ for different tunnel encapsulations details of the probing mechanism may differ for different tunnel
and if visible in the network (e.g. if not using IPsec in encryption encapsulations, and if they are visible in the network (e.g., if not
mode) could reveal additional information to an on-path attacker to using IPsec in encryption mode), they could reveal additional
identify the type of tunnel being used. information to help an on-path attacker identify the type of tunnel
being used.
IP-in-IP or GRE tunnels offer good traversal of middleboxes that have IP-in-IP or GRE tunnels offer good traversal of middleboxes that have
not been designed for security, e.g. firewalls. However, firewalls not been designed for security, e.g., firewalls. However, firewalls
may be expected to be configured to block general tunnels as they may be expected to be configured to block general tunnels, because
present a large attack surface. This applicability statement they present a large attack surface. This applicability statement
therefore permits this method to be enabled only for specific ranges therefore permits this method to be enabled only for specific port
of ports. ranges.
When the zero UDP checksum mode is enabled for a range of ports, When the zero UDP checksum mode is enabled for a range of ports,
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 8. Acknowledgments
10.1. Normative References We would like to thank Brian Haberman, Brian Carpenter, Margaret
Wasserman, Lars Eggert, and others in the TSV directorate. Barry
Leiba, Ronald Bonica, Pete Resnick, and Stewart Bryant helped to make
this document one with greater applicability. Thanks to P.F.
Chimento for careful review and editorial corrections.
[I-D.ietf-6man-udpchecksums] Thanks also to Remi Denis-Courmont, Pekka Savola, Glen Turner, and
Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and many others who contributed comments and ideas via the 6man, behave,
UDP Checksums for Tunneled Packets", lisp, and mboned lists.
draft-ietf-6man-udpchecksums-08 (work in progress),
February 2013.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 9. References
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 9.1. Normative References
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
Requirement Levels", BCP 14, RFC 2119, March 1997. August 1980.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
(IPv6) Specification", RFC 2460, December 1998. September 1981.
10.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-intarea-tunnels] [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
Touch, J. and M. Townsley, "Tunnels in the Internet 6 (IPv6) Specification", RFC 2460, December 1998.
Architecture", draft-ietf-intarea-tunnels-00 (work in
progress), March 2010.
[I-D.ietf-mboned-auto-multicast] [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
Bumgardner, G., "Automatic Multicast Tunneling", UDP Checksums for Tunneled Packets", RFC 6935,
draft-ietf-mboned-auto-multicast-14 (work in progress), April 2013.
June 2012.
[LISP] D. Farinacci et al, "Locator/ID Separation Protocol 9.2. Informative References
(LISP)", November 2012.
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, [AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work
"Computing the Internet checksum", RFC 1071, in Progress, June 2012.
September 1988.
[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
Internet checksum", RFC 1141, January 1990. RFC 793, September 1981.
[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
Incremental Update", RFC 1624, May 1994. "Computing the Internet checksum", RFC 1071,
September 1988.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of
Defeating Denial of Service Attacks which employ IP Source the Internet checksum", RFC 1141, January 1990.
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum
Jacobson, "RTP: A Transport Protocol for Real-Time via Incremental Update", RFC 1624, May 1994.
Applications", STD 64, RFC 3550, July 2003.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Defeating Denial of Service Attacks which employ IP
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Source Address Spoofing", BCP 38, RFC 2827, May 2000.
RFC 3819, July 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
G. Fairhurst, "The Lightweight User Datagram Protocol Jacobson, "RTP: A Transport Protocol for Real-Time
(UDP-Lite)", RFC 3828, July 2004. Applications", STD 64, RFC 3550, July 2003.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Message Protocol (ICMPv6) for the Internet Protocol Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and
Version 6 (IPv6) Specification", RFC 4443, March 2006. L. Wood, "Advice for Internet Subnetwork Designers",
BCP 89, RFC 3819, July 2004.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
Errors at High Data Rates", RFC 4963, July 2007. and G. Fairhurst, "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
protocol", RFC 5097, January 2008. Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4
for Application Designers", BCP 145, RFC 5405, Reassembly Errors at High Data Rates", RFC 4963,
November 2008. July 2007.
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite
Provisioning of Wireless Access Points (CAPWAP) Protocol protocol", RFC 5097, January 2008.
Specification", RFC 5415, March 2009.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage
RFC 5722, December 2009. Guidelines for Application Designers", BCP 145,
RFC 5405, November 2008.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control
"IPv6 Flow Label Specification", RFC 6437, November 2011. And Provisioning of Wireless Access Points (CAPWAP)
Protocol Specification", RFC 5415, March 2009.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
for Equal Cost Multipath Routing and Link Aggregation in RFC 5722, December 2009.
Tunnels", RFC 6438, November 2011.
[Sigcomm2000] [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J.
Jonathan Stone and Craig Partridge , "When the CRC and TCP Rajahalme, "IPv6 Flow Label Specification", RFC 6437,
Checksum Disagree", 2000. November 2011.
[UDPTT] G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010. [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation
in Tunnels", RFC 6438, November 2011.
Appendix A. Evaluation of proposal to update RFC 2460 to support zero [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
checksum "The Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013.
[Sigcomm2000] Stone, J. and C. Partridge, "When the CRC and TCP
Checksum Disagree", 2000,
<http://conferences.sigcomm.org/sigcomm/2000/conf/
abstract/9-1.htm>.
[TUNNELS] Touch, J. and M. Townsley, "Tunnels in the Internet
Architecture", Work in Progress, March 2010.
[UDPTT] Fairhurst, G., "The UDP Tunnel Transport mode", Work in
Progress, February 2010.
Appendix A. Evaluation of Proposal to Update RFC 2460 to Support Zero
Checksum
This informative appendix documents the evaluation of the proposal to This informative appendix documents the evaluation of the proposal to
update IPv6 [RFC2460], to provide the option that some nodes may update IPv6 [RFC2460] such that it provides the option that some
suppress generation and checking of the UDP transport checksum. It nodes may suppress generation and checking of the UDP transport
also compares the proposal with other alternatives, and notes that checksum. It also compares this proposal with other alternatives,
for a particular application some standard methods may be more and notes that for a particular application, some standard methods
appropriate than using IPv6 with a zero UDP checksum. may be more appropriate than using IPv6 with a zero UDP checksum.
A.1. Alternatives to the Standard Checksum A.1. Alternatives to the Standard Checksum
There are several alternatives to the normal method for calculating There are several alternatives to the normal method for calculating
the UDP Checksum [RFC1071] that do not require a tunnel endpoint to the UDP checksum [RFC1071] that do not require a tunnel endpoint to
inspect the entire packet when computing a checksum. These include inspect the entire packet when computing a checksum. These include:
(in decreasing order of complexity):
o Delta computation of the checksum from an encapsulated checksum o IP-in-IP tunneling. Because this method completely dispenses with
field. Since the checksum is a cumulative sum [RFC1624], an a transport protocol in the outer layer, it has reduced overhead
encapsulating header checksum can be derived from the new pseudo and complexity, but also reduced functionality. There is no outer
header, the inner checksum and the sum of the other network-layer checksum over the packet, and also there are no ports to perform
fields not included in the pseudo header of the encapsulated demultiplexing among different tunnel types. This reduces the
packet, in a manner resembling incremental checksum update available information upon which a load balancer may act.
[RFC1141]. This would not require access to the whole packet, but
does require fields to be collected across the header, and
arithmetic operations on each packet. The method would only work
for packets that contain a 2's complement transport checksum
(i.e., it would not be appropriate for SCTP or when IP
fragmentation is used).
o UDP-Lite with the checksum coverage set to only the header portion o UDP-Lite with the checksum coverage set to only the header portion
of a packet. This requires a pseudo header checksum calculation of a packet. This requires a pseudo-header checksum calculation
only on the encapsulating packet header. The computed checksum only on the encapsulating packet header. The computed checksum
value may be cached (before adding the Length field) for each value may be cached (before adding the Length field) for each
flow/destination and subsequently combined with the Length of each flow/destination and subsequently combined with the Length of each
packet to minimise per-packet processing. This value is combined packet to minimize per-packet processing. This value is combined
with the UDP payload length for the pseudo header, however this with the UDP payload length for the pseudo-header. However, this
length is expected to be known when performing packet forwarding. length is expected to be known when performing packet forwarding.
o The proposed UDP Tunnel Transport [UDPTT] suggested a method where o Delta computation of the checksum from an encapsulated checksum
UDP would be modified to derive the checksum only from the field. Because the checksum is a cumulative sum [RFC1624], an
encapsulating packet protocol header. This value does not change encapsulating header checksum can be derived from the new pseudo-
between packets in a single flow. The value may be cached per header, the inner checksum, and the sum of the other network-layer
flow/destination to minimise per-packet processing. fields not included in the pseudo-header of the encapsulated
packet, in a manner resembling incremental checksum update
[RFC1141]. This would not require access to the whole packet, but
does require fields to be collected across the header and
arithmetic operations to be performed on each packet. The method
would work only for packets that contain a 2's complement
transport checksum (i.e., it would not be appropriate for SCTP or
when IP fragmentation is used).
o UDP has been modified to disable checksum processing (Zero UDP
Checksum) [RFC6935]. This eliminates the need for a checksum
calculation, but would require constraints on appropriate usage
and updates to endpoints and middleboxes.
o The proposed UDP Tunnel Transport [UDPTT] protocol suggested a
method where UDP would be modified to derive the checksum only
from the encapsulating packet protocol header. This value does
not change between packets in a single flow. The value may be
cached per flow/destination to minimize per-packet processing.
o A method has been proposed that uses a new (to-be-defined) IPv6
Destination Options Header to provide an end-to-end validation
check at the network layer. This would allow an endpoint to
verify delivery to an appropriate endpoint, but would also require
IPv6 nodes to correctly handle the additional header and would
require changes to middlebox behavior (e.g., when used with a NAT
that always adjusts the checksum value).
o There has been a proposal to simply ignore the UDP checksum value o There has been a proposal to simply ignore the UDP checksum value
on reception at the tunnel egress, allowing a tunnel ingress to on reception at the tunnel egress, allowing a tunnel ingress to
insert any value correct or false. For tunnel usage, a non insert any value, correct or false. For tunnel usage, a non-
standard checksum value may be used, forcing an RFC 2460 receiver standard checksum value may be used, forcing an RFC 2460 receiver
to drop the packet. The main downside is that it would be to drop the packet. The main downside is that it would be
impossible to identify a UDP datagram (in the network or an impossible to identify a UDP datagram (in the network or an
endpoint) that is treated in this way compared to a packet that endpoint) that is treated in this way compared to a packet that
has actually been corrupted. has actually been corrupted.
o A method has been proposed that uses a new (to be defined) IPv6
Destination Options Header to provide an end-to-end validation
check at the network layer. This would allow an endpoint to
verify delivery to an appropriate end point, but would also
require IPv6 nodes to correctly handle the additional header, and
would require changes to middlebox behavior (e.g. when used with a
NAT that always adjusts the checksum value).
o UDP modified to disable checksum processing
[I-D.ietf-6man-udpchecksums]. This eliminates the need for a
checksum calculation, but would require constraints on appropriate
usage and updates to end-points and middleboxes.
o IP-in-IP tunneling. As this method completely dispenses with a
transport protocol in the outer-layer it has reduced overhead and
complexity, but also reduced functionality. There is no outer
checksum over the packet and also no ports to perform
demultiplexing between different tunnel types. This reduces the
information available upon which a load balancer may act.
These options are compared and discussed further in the following These options are compared and discussed further in the following
sections. sections.
A.2. Comparison A.2. Comparison of Alternative Methods
This section compares the above listed methods to support datagram This section compares the methods listed above to support datagram
tunneling. It includes proposals for updating the behaviour of UDP. tunneling. It includes proposals for updating the behavior of UDP.
While this comparison focuses on applications that are expected to While this comparison focuses on applications that are expected to
execute on routers, the distinction between a router and a host is execute on routers, the distinction between a router and a host is
not always clear, especially at the transport level. Systems (such not always clear, especially at the transport level. Systems (such
as unix-based operating systems) routinely provide both functions. as UNIX-based operating systems) routinely provide both functions.
There is no way to identify the role of the receiving node from a From a received packet, there is no way to identify the role of the
received packet. receiving node.
A.2.1. Middlebox Traversal A.2.1. Middlebox Traversal
Regular UDP with a standard checksum or the delta encoded Regular UDP with a standard checksum or the delta-encoded
optimization for creating correct checksums have the best optimization for creating correct checksums has the best possibility
possibilities for successful traversal of a middlebox. No new for successful traversal of a middlebox. No new support is required.
support is required.
A method that ignores the UDP checksum on reception is expected to A method that ignores the UDP checksum on reception is expected to
have a good probability of traversal, because most middleboxes have a good probability of traversal, because most middleboxes
perform an incremental checksum update. UDPTT would also have been perform an incremental checksum update. UDPTT would also be able to
able to traverse a middlebox with this behaviour. However, a traverse a middlebox with this behavior. However, a middlebox on the
middlebox on the path that attempts to verify a standard checksum path that attempts to verify a standard checksum will not forward
will not forward packets using either of these methods, preventing packets using either of these methods, thus preventing traversal. A
traversal. A method that ignores the checksum has an additional method that ignores the checksum has the additional downside that it
downside in that it prevents improvement of middlebox traversal, prevents improvement of middlebox traversal, because there is no way
because there is no way to identify UDP datagrams that use the to identify UDP datagrams that use the modified checksum behavior.
modified checksum behaviour.
IP-in-IP or GRE tunnels offer good traversal of middleboxes that have IP-in-IP or GRE tunnels offer good traversal of middleboxes that have
not been designed for security, e.g. firewalls. However, firewalls not been designed for security, e.g., firewalls. However, firewalls
may be expected to be configured to block general tunnels as they may be expected to be configured to block general tunnels, because
present a large attack surface. they present a large attack surface.
A new IPv6 Destination Options header will suffer traversal issues A new IPv6 Destination Options header will suffer traversal issues
with middleboxes, especially Firewalls and NATs, and will likely with middleboxes, especially firewalls and NATs, and will likely
require them to be updated before the extension header is passed. require them to be updated before the extension header is passed.
Datagrams with a zero UDP checksum will not be passed by any Datagrams with a zero UDP checksum will not be passed by any
middlebox that validates the checksum using RFC 2460 or updates the middlebox that validates the checksum using RFC 2460 or updates the
checksum field, such as NAT or firewalls. This would require an checksum field, such as NAT or firewalls. This would require an
update to correctly handle a datagram with a zero UDP checksum. update to correctly handle a datagram with a zero UDP checksum.
UDP-Lite will require an update of almost all type of middleboxes, UDP-Lite will require an update of almost all types of middleboxes,
because it requires support for a separate network-layer protocol because it requires support for a separate network-layer protocol
number. Once enabled, the method to support incremental checksum number. Once enabled, the method to support incremental checksum
update would be identical to that for UDP, but different for checksum updates would be identical to that for UDP, but different for
validation. checksum validation.
A.2.2. Load Balancing A.2.2. Load Balancing
The usefulness of solutions for load balancers depends on the The usefulness of solutions for load balancers depends on the
difference in entropy in the headers for different flows that can be difference in entropy in the headers for different flows that can be
included in a hash function. All the proposals that use the UDP included in a hash function. All the proposals that use the UDP
protocol number have equal behavior. UDP-Lite has the potential for protocol number have equal behavior. UDP-Lite has the potential for
equally good behavior as for UDP. However, UDP-Lite is currently behavior that is equally as good as UDP. However, UDP-Lite is
unlikely to be supported by deployed hashing mechanisms, which could currently unlikely to be supported by deployed hashing mechanisms,
cause a load balancer to not use the transport header in the computed which could cause a load balancer not to use the transport header in
hash. A load balancer that only uses the IP header will have low the computed hash. A load balancer that uses only the IP header will
entropy, but could be improved by including the IPv6 the flow label, have low entropy, but this could be improved by including the IPv6
providing that the tunnel ingress ensures that different flow labels the flow label, provided that the tunnel ingress ensures that
are assigned to different flows. However, a transition to the common different flow labels are assigned to different flows. However, a
use of good quality flow labels is likely to take time to deploy. transition to the common use of good quality flow labels is likely to
take time to deploy.
A.2.3. Ingress and Egress Performance Implications A.2.3. Ingress and Egress Performance Implications
IP-in-IP tunnels are often considered efficient, because they IP-in-IP tunnels are often considered efficient, because they
introduce very little processing and low data overhead. The other introduce very little processing and have low data overhead. The
proposals introduce a UDP-like header incurring associated data other proposals introduce a UDP-like header, which incurs an
overhead. Processing is minimised for the method that uses a zero associated data overhead. Processing is minimized for the method
UDP checksum, ignoring the UDP checksum on reception, and only that uses a zero UDP checksum and for the method that ignores the UDP
slightly higher for UDPTT, the extension header and UDP-Lite. The checksum on reception, and processing is only slightly higher for
delta-calculation scheme operates on a few more fields, but also UDPTT, the extension header, and UDP-Lite. The delta calculation
introduces serious failure modes that can result in a need to scheme operates on a few more fields, but also introduces serious
calculate a checksum over the complete datagram. Regular UDP is failure modes that can result in a need to calculate a checksum over
clearly the most costly to process, always requiring checksum the complete datagram. Regular UDP is clearly the most costly to
calculation over the entire datagram. process, always requiring checksum calculation over the entire
datagram.
It is important to note that the zero UDP checksum method, ignoring It is important to note that the zero UDP checksum method, ignoring
checksum on reception, the Option Header, UDPTT and UDP-Lite will checksum on reception, the Option Header, UDPTT, and UDP-Lite will
likely incur additional complexities in the application to likely incur additional complexities in the application to
incorporate a negotiation and validation mechanism. incorporate a negotiation and validation mechanism.
A.2.4. Deployability A.2.4. Deployability
The major factors influencing deployability of these solutions are a The major factors influencing deployability of these solutions are a
need to update both end-points, a need for negotiation and the need need to update both endpoints, a need for negotiation, and the need
to update middleboxes. These are summarised below: to update middleboxes. These are summarized below:
o The solution with the best deployability is regular UDP. This o The solution with the best deployability is regular UDP. This
requires no changes and has good middlebox traversal requires no changes and has good middlebox traversal
characteristics. characteristics.
o The next easiest to deploy is the delta checksum solution. This o The next easiest to deploy is the delta checksum solution. This
does not modify the protocol on the wire and only needs changes in does not modify the protocol on the wire and needs changes only in
tunnel ingress. the tunnel ingress.
o IP-in-IP tunnels should not require changes to the end-points, but o IP-in-IP tunnels should not require changes to the endpoints, but
raise issues when traversing firewalls and other security devices, they raise issues regarding the traversal of firewalls and other
which are expected to require updates. security devices, which are expected to require updates.
o Ignoring the checksum on reception will require changes at both o Ignoring the checksum on reception will require changes at both
end-points. The never ceasing risk of path failure requires endpoints. The never-ceasing risk of path failure requires
additional checks to ensure this solution is robust and will additional checks to ensure that this solution is robust, and it
require changes or additions to the tunnel control protocol to will require changes or additions to the tunnel control protocol
negotiate support and validate the path. to negotiate support and validate the path.
o The remaining solutions (including the zero checksum method) offer o The remaining solutions (including the zero UDP checksum method)
similar deployability. UDP-Lite requires support at both end- offer similar deployability. UDP-Lite requires support at both
points and in middleboxes. UDPTT and the zero UDP checksum method endpoints and in middleboxes. UDPTT and the zero UDP checksum
with or without an extension header require support at both end- method, with or without an extension header, require support at
points and in middleboxes. UDP-Lite, UDPTT, and the zero UDP both endpoints and in middleboxes. UDP-Lite, UDPTT, and the zero
checksum method and use of extension headers may additionally UDP checksum method and the use of extension headers may also
require changes or additions to the tunnel control protocol to require changes or additions to the tunnel control protocol to
negotiate support and path validation. negotiate support and path validation.
A.2.5. Corruption Detection Strength A.2.5. Corruption Detection Strength
The standard UDP checksum and the delta checksum can both provide The standard UDP checksum and the delta checksum can both provide
some verification at the tunnel egress. This can significantly some verification at the tunnel egress. This can significantly
reduce the probability that a corrupted inner packet is forwarded. reduce the probability that a corrupted inner packet is forwarded.
UDP-Lite, UDPTT and the extension header all provide some UDP-Lite, UDPTT, and the extension header all provide some
verification against corruption, but do not verify the inner packet. verification against corruption, but they do not verify the inner
They only provide a strong indication that the delivered packet was packet. They provide only a strong indication that the delivered
intended for the tunnel egress and was correctly delimited. packet was intended for the tunnel egress and was correctly
delimited.
The methods using a zero UDP checksum, ignoring the UDP checksum on The methods using a zero UDP checksum, ignoring the UDP checksum on
reception and IP-and-IP encapsulation all provide no verification reception, and IP-and-IP encapsulation all provide no verification
that a received datagram was intended to be processed by a specific that a received datagram was intended to be processed by a specific
tunnel egress or that the inner encapsulated packet was correct. tunnel egress or that the inner encapsulated packet was correct.
Section 3.1 discusses experience using specific protocols in well- Section 3.1 discusses experience using specific protocols in well-
managed networks. managed networks.
A.2.6. Comparison Summary A.2.6. Comparison Summary
The comparisons above may be summarised as "there is no silver bullet The comparisons above may be summarized as, "there is no silver
that will slay all the issues". One has to select which down side(s) bullet that will slay all the issues". One has to select which
can best be lived with. Focusing on the existing solutions, this can downsides can best be lived with. Focusing on the existing
be summarized as: solutions, they can be summarized as:
Regular UDP: The method defined in RFC 2460 has good middlebox Regular UDP: The method defined in RFC 2460 has good middlebox
traversal and load balancing and multiplexing, requiring a traversal and load balancing and multiplexing, and requires a
checksum in the outer headers covering the whole packet. checksum in the outer headers to cover the whole packet.
IP in IP: A low complexity encapsulation, with limited middlebox IP-in-IP: A low-complexity encapsulation that has limited middlebox
traversal, no multiplexing support, and currently poor load traversal, no multiplexing support, and poor load-balancing
balancing support that could improve over time. support that could improve over time.
UDP-Lite: A medium complexity encapsulation, with good multiplexing UDP-Lite: A medium-complexity encapsulation that has good
support, limited middlebox traversal, but possible to improve over multiplexing support, limited middlebox traversal that may
time, currently poor load balancing support that could improve possibly improve over time, and poor load-balancing support that
over time, in most cases requiring application level negotiation could improve over time, and that, in most cases, requires
to select the protocol and validation to confirm the path forwards application-level negotiation to select the protocol and
UDP-Lite. validation to confirm that the path forwards UDP-Lite.
The delta-checksum is an optimization in the processing of UDP, as Delta computation of a tunnel checksum: The delta checksum is an
such it exhibits some of the drawbacks of using regular UDP. optimization in the processing of UDP, and, as such, it exhibits
some of the drawbacks of using regular UDP.
The remaining proposals may be described in similar terms: The remaining proposals may be described in similar terms:
Zero-Checksum: A low complexity encapsulation, with good Zero Checksum: A low-complexity encapsulation that has good
multiplexing support, limited middlebox traversal that could multiplexing support, limited middlebox traversal that could
improve over time, good load balancing support, in most cases improve over time, and good load-balancing support, and that, in
requiring application level negotiation and validation to confirm most cases, requires application-level negotiation and validation
the path forwards a zero UDP checksum. to confirm that the path forwards a zero UDP checksum.
UDPTT: A medium complexity encapsulation, with good multiplexing UDPTT: A medium-complexity encapsulation that has good multiplexing
support, limited middlebox traversal, but possible to improve over support, limited middlebox traversal that may possibly improve
time, good load balancing support, in most cases requiring over time, and good load-balancing support, and that, in most
application level negotiation to select the transport and cases, requires application-level negotiation to select the
validation to confirm the path forwards UDPTT datagrams. transport and validation to confirm the path forwards UDPTT
datagrams.
IPv6 Destination Option IP in IP tunneling: A medium complexity, IPv6 Destination Option IP-in-IP Tunneling: A medium-complexity
with no multiplexing support, limited middlebox traversal, encapsulation that has no multiplexing support, limited middlebox
currently poor load balancing support that could improve over traversal, and poor load-balancing support that could improve over
time, in most cases requiring negotiation to confirm the option is time, and that, in most cases, requires negotiation to confirm
supported and validation to confirm the path forwards the option. that the option is supported and validation to confirm the path
forwards the option.
IPv6 Destination Option combined with UDP Zero-checksuming: A medium IPv6 Destination Option Combined with Zero UDP Checksum: A medium-
complexity encapsulation, with good multiplexing support, limited complexity encapsulation that has good multiplexing support,
load balancing support that could improve over time, in most cases limited load-balancing support that could improve over time, and
requiring negotiation to confirm the option is supported and that, in most cases, requires negotiation to confirm the option is
validation to confirm the path forwards the option. supported and validation to confirm the path forwards the option.
Ignore the checksum on reception: A low complexity encapsulation, Ignore the Checksum on Reception: A low-complexity encapsulation
with good multiplexing support, medium middlebox traversal that that has good multiplexing support, medium middlebox traversal
never can improve, good load balancing support, in most cases that can never improve, and good load-balancing support, and that,
requiring negotiation to confirm the option is supported by the in most cases, requires negotiation to confirm that the option is
remote endpoint and validation to confirm the path forwards a zero supported by the remote endpoint and validation to confirm the
UDP checksum. path forwards a zero UDP checksum.
There is no clear single optimum solution. If the most important There is no clear single optimum solution. If the most important
need is to traverse middleboxes, then the best choice is to stay with need is to traverse middleboxes, the best choice is to stay with
regular UDP and consider the optimizations that may be required to regular UDP and consider the optimizations that may be required to
perform the checksumming. If one can live with limited middlebox perform the checksumming. If one can live with limited middlebox
traversal, low complexity is necessary and one does not require load traversal, if low complexity is necessary, and one does not require
balancing, then IP-in-IP tunneling is the simplest. If one wants load balancing, IP-in-IP tunneling is the simplest. If one wants
strengthened error detection, but with currently limited middlebox strengthened error detection, but with the currently limited
traversal and load-balancing. UDP-Lite is appropriate. Zero UDP middlebox traversal and load balancing, UDP-Lite is appropriate.
checksum addresses another set of constraints, low complexity and a Zero UDP checksum addresses another set of constraints: low
need for load balancing from the current Internet, providing it can complexity and a need for load balancing from the current Internet,
live with currently limited middlebox traversal. provided that the usage can accept the currently limited support for
middlebox traversal.
Techniques for load balancing and middlebox traversal do continue to Techniques for load balancing and middlebox traversal do continue to
evolve. Over a long time, developments in load balancing have good evolve. Over a long time, developments in load balancing have good
potential to improve. This time horizon is long since it requires potential to improve. This time horizon is long, because it requires
both load balancer and end-point updates to get full benefit. The both load balancer and endpoint updates to get full benefit. The
challenges of middlebox traversal are also expected to change with challenges of middlebox traversal are also expected to change with
time, as device capabilities evolve. Middleboxes are very prolific time as device capabilities evolve. Middleboxes are very prolific,
with a larger proportion of end-user ownership, and therefore may be with a larger proportion of end user ownership, and therefore may be
expected to take long time cycles to evolve. expected to take a long time to evolve.
One potential advantage is that the deployment of IPv6-capable However, we note that the deployment of IPv6-capable middleboxes is
middleboxes are still in its initial phase and the quicker a new still in its initial phase, and if a new method becomes standardized
method becomes standardized, the fewer boxes will be non-compliant. quickly, fewer boxes will be non-compliant.
Thus, the question of whether to permit use of datagrams with a zero Thus, the question of whether to permit use of datagrams with a zero
UDP checksum for IPv6 under reasonable constraints, is therefore best UDP checksum for IPv6 under reasonable constraints is best viewed as
viewed as a trade-off between a number of more subjective questions: a trade-off among a number of more subjective questions:
o Is there sufficient interest in using a zero UDP checksum with the o Is there sufficient interest in using a zero UDP checksum with the
given constraints (summarised below)? given constraints (summarized below)?
o Are there other avenues of change that will resolve the issue in a o Are there other avenues of change that will resolve the issue in a
better way and sufficiently quickly ? better way and sufficiently quickly ?
o Do we accept the complexity cost of having one more solution in o Do we accept the complexity cost of having one more solution in
the future? the future?
The analysis concludes that the IETF should carefully consider The analysis concludes that the IETF should carefully consider
constraints on sanctioning the use of any new transport mode. The constraints on sanctioning the use of any new transport mode. The
6man working group of the IETF has determined that the answer to the 6man working group of the IETF has determined that the answers to the
above questions are sufficient to update IPv6 to standardise use of a above questions are sufficient to update IPv6 to standardize use of a
zero UDP checksum for use by tunnel encapsulations for specific zero UDP checksum for use by tunnel encapsulations for specific
applications. applications.
Each application should consider the implications of choosing an IPv6 Each application should consider the implications of choosing an IPv6
transport that uses a zero UDP checksum. In many cases, standard transport that uses a zero UDP checksum. In many cases, standard
methods may be more appropriate, and may simplify application design. methods may be more appropriate and may simplify application design.
The use of checksum off-loading may help alleviate the checksum The use of checksum off-loading may help alleviate the checksum
processing cost and permit use of a checksum using method defined in processing cost and permit use of a checksum using the method defined
RFC 2460. in RFC 2460.
Appendix B. Document Change History
{RFC EDITOR NOTE: This section must be deleted prior to publication}
Individual Draft 00 This is the first DRAFT of this document - It
contains a compilation of various discussions and contributions
from a variety of IETF WGs, including: mboned, tsv, 6man, lisp,
and behave. This includes contributions from Magnus with text on
RTP, and various updates.
Individual Draft 01
* This version corrects some typos and editorial NiTs and adds
discussion of the need to negotiate and verify operation of a
new mechanism (3.3.4).
Individual Draft 02
* Version -02 corrects some typos and editorial NiTs.
* Added reference to ECMP for tunnels.
* Clarifies the recommendations at the end of the document.
Working Group Draft 00
* Working Group Version -00 corrects some typos and removes much
of rationale for UDPTT. It also adds some discussion of IPv6
extension header.
Working Group Draft 01
* Working Group Version -01 updates the rules and incorporates
off-list feedback. This version is intended for wider review
within the 6man working group.
Working Group Draft 02
* This version is the result of a major rewrite and re-ordering
of the document.
* A new section comparing the results have been added.
* The constraints list has been significantly altered by removing
some and rewording other constraints.
* This contains other significant language updates to clarify the
intent of this draft.
Working Group Draft 03
* Editorial updates
Working Group Draft 04
* Resubmission only updating the AMT and RFC2765 references.
Working Group Draft 05
* Resubmission to correct editorial NiTs - thanks to Bill Atwood
for noting these.Group Draft 05.
Working Group Draft 06
* Resubmission to keep draft alive (spelling updated from 05).
Working Group Draft 07
* Interim Version
* Submission after IESG Feedback Added
* Updates to enable the document to become a PS Applicability
Statement
Working Group Draft 08
* First Version written as a PS Applicability Statement
* Changes to reflect decision to update RFC 2460, rather than
recommend decision
* Updates to requirements for middleboxes
* Inclusion of requirements for security, API, and tunnel
* Move of the rationale for the update to an Annex (former
section 4)
Working Group Draft 09
* Submission after second WGLC (note mistake corrected in -09).
* Clarified role of API for supporting full checksum.
* Clarified that full checksum is required in security
considerations, and therefore noting that full checksum should
not be treated as an attack - consistent with remainder of
document.
* Added mention that API can set a mode in transport stack - to
link to similar statement in RFC 2460 update.
* Fixed typos.
Working Group Draft 10
* Submission to correct unwanted removal of text from section 5
bullets 5-7 by GF.
* Replaced section 5 text with the text from 08, and reapplied
the editorial correction.
* Note to reviewers: Please compare this revision with -08 used
in the IETF LC).
Working Group Draft 11
* Added REF for 5097 (Noted by S.Turner)
* Added text in response to P. Resnick on place where checksum is
calculated.
* Added text to note experience with MPLS/PWE; Appendix updated
to refer to this (S. Bryant)
* Added text in response to P.Resnick's 2nd comments.
* Request to make UDP-Lite more clearly recommended (J Touch,
P.Resnick)
* Added considerations around usage of zero checksum in routers.
* Added text in response to Stewart Bryant's comments on router
requirements.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
Scotland, UK Scotland, UK
Email: gorry@erg.abdn.ac.uk EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry URI: http://www.erg.abdn.ac.uk/users/gorry
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
Stockholm, SE-164 80 Stockholm, SE-164 80
Sweden Sweden
Phone: +46 8 719 0000 Phone: +46 8 719 0000
Email: magnus.westerlund@ericsson.com EMail: magnus.westerlund@ericsson.com
 End of changes. 288 change blocks. 
1076 lines changed or deleted 954 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/