draft-ietf-6man-udpzero-07.txt   draft-ietf-6man-udpzero-08.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: April 25, 2013 Ericsson Expires: June 14, 2013 Ericsson
October 22, 2012 December 11, 2012
Applicability Statement for the use of IPv6 UDP Datagrams with Zero Applicability Statement for the use of IPv6 UDP Datagrams with Zero
Checksums Checksums
draft-ietf-6man-udpzero-07 draft-ietf-6man-udpzero-08
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 when used with IPv6. This defines transport checksums with IPv6. It defines recommendations and
recommendations and requirements for use of IPv6 UDP datagrams with a requirements for the use of IPv6 UDP datagrams with a zero UDP
zero checksum. It examines the role of the IPv6 UDP transport checksum. It describes the issues and design principles that need to
checksum, as defined in RFC2460 and presents a summary of the trade- be considered when UDP is used with IPv6 to support tunnel
offs for evaluating the safety of updating RFC 2460 to permit an IPv6 encapsulations and examines the role of the IPv6 UDP transport
UDP endpoint to use a zero value in the checksum field as an checksum. An appendix presents a summary of the trade-offs that were
indication that no checksum is present. This method is compared with considered in evaluating the safety of the update to RFC 2460 that
some other possibilities. The document also describes the issues and updates use of the UDP checksum with IPv6.
design principles that need to be considered when UDP is used with
IPv6 to support tunnel encapsulations.
XXX NOTE - This revision is a partial response to comments received
during IESG review. There are additional comments to be incorporated
- and updates anticipated to the related PS that updates IPv6. This
is therefore an interim version. XXX
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on June 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 4 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 6
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . 7
1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 6 1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 7
1.3.3. Need to inspect the entire packet . . . . . . . . . . 7 1.3.3. Need to inspect the entire packet . . . . . . . . . . 8
1.3.4. Interactions with middleboxes . . . . . . . . . . . . 7 1.3.4. Interactions with middleboxes . . . . . . . . . . . . 8
1.3.5. Support for load balancing . . . . . . . . . . . . . . 8 1.3.5. Support for load balancing . . . . . . . . . . . . . . 9
2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 8 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9
2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 8 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 10
2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 9 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 10
2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 9 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 11
3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 10 3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 11
3.1. Effect of packet modification in the network . . . . . . . 11 3.1. Effect of packet modification in the network . . . . . . . 12
3.1.1. Corruption of the destination IP address . . . . . . . 12 3.1.1. Corruption of the destination IP address . . . . . . . 13
3.1.2. Corruption of the source IP address . . . . . . . . . 12 3.1.2. Corruption of the source IP address . . . . . . . . . 13
3.1.3. Corruption of Port Information . . . . . . . . . . . . 13 3.1.3. Corruption of Port Information . . . . . . . . . . . . 14
3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 13 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 15
3.1.5. Corruption of Fragmentation Information . . . . . . . 15 3.1.5. Corruption of Fragmentation Information . . . . . . . 16
3.2. Validating the network path . . . . . . . . . . . . . . . 17 3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 18
3.3. Applicability of method . . . . . . . . . . . . . . . . . 17 3.3. Validating the network path . . . . . . . . . . . . . . . 18
3.4. Impact on non-supporting devices or applications . . . . . 18 3.4. Applicability of method . . . . . . . . . . . . . . . . . 19
4. Evaluation of proposal to update RFC 2460 to support zero 3.5. Impact on non-supporting devices or applications . . . . . 20
checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Constraints on implementation of IPv6 nodes supporting
4.1. Alternatives to the Standard Checksum . . . . . . . . . . 19 zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Requirements on the usage of zero UDP checksum . . . . . . . . 22
4.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 20 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.3. Ingress and Egress Performance Implications . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
4.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
4.2.5. Corruption Detection Strength . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
5. Constraints on implementation of IPv6 nodes supporting 10.2. Informative References . . . . . . . . . . . . . . . . . . 27
zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Evaluation of proposal to update RFC 2460 to
6. Requirements on the specification of transported protocols . . 25 support zero checksum . . . . . . . . . . . . . . . . 28
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.1. Alternatives to the Standard Checksum . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 A.2.3. Ingress and Egress Performance Implications . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . . 29 A.2.5. Corruption Detection Strength . . . . . . . . . . . . 32
Appendix A. Document Change History . . . . . . . . . . . . . . . 31 A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix B. Document Change History . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
The User Datagram Protocol (UDP) [RFC0768] transport is defined for The User Datagram Protocol (UDP) [RFC0768] transport is defined for
the Internet Protocol (IPv4) [RFC0791] and is defined in Internet the Internet Protocol (IPv4) [RFC0791] and is defined in Internet
Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The
UDP transport protocol has a minimal set of features. This limited UDP transport protocol has a minimal set of features. This limited
set has enabled a wide range of applications to use UDP, but these set has enabled a wide range of applications to use UDP, but these
application do need to provide many important transport functions on application do need to provide many important transport functions on
top of UDP. The UDP Usage Guidelines [RFC5405] provides overall top of UDP. The UDP Usage Guidelines [RFC5405] provides overall
guidance for application designers, including the use of UDP to guidance for application designers, including the use of UDP to
support tunneling. The key difference between UDP usage with IPv4 support tunneling. The key difference between UDP usage with IPv4
and IPv6 is that IPv6 mandates use of the UDP checksum, i.e. a non- and IPv6 is that RFC 2460 mandates use of a calculated UDP checksum,
zero value, due to the lack of an IPv6 header checksum. i.e. a non-zero value, due to the lack of an IPv6 header checksum.
The lack of a possibility to use UDP with a zero-checksum in IPv6 has The lack of a possibility to use an IPv6 datagram with a zero UDP
been observed as a real problem for certain classes of application, checksum has been observed as a real problem for certain classes of
primarily tunnel applications. This class of application has been application, primarily tunnel applications. This class of
deployed with a zero checksum using IPv4. The design of IPv6 raises application has been deployed with a zero UDP checksum using IPv4.
different issues when considering the safety of using a zero checksum The design of IPv6 raises different issues when considering the
for UDP with IPv6. These issues can significantly affect safety of using a UDP checksum with IPv6. These issues can
applications, both when an endpoint is the intended user and when an significantly affect applications, both when an endpoint is the
innocent bystander (received by a different endpoint to that intended user and when an innocent bystander (i.e. a packet received
intended). The document examines these issues and compares the by a different endpoint to that intended).
This document examines the issues and an appendix compares the
strengths and weaknesses of a number of proposed solutions. This strengths and weaknesses of a number of proposed solutions. This
analysis presents a set of issues that must be considered and identifies a set of issues that must be considered and mitigated to
mitigated to be able to safely deploy UDP with a zero checksum over be able to safely deploy IPv6 applications that use a zero UDP
IPv6. The provided comparison of methods is expected to also be checksum. The provided comparison of methods is expected to also be
useful when considering applications that have different goals from useful when considering applications that have different goals from
the ones that initiated the writing of this document, especially the the ones that initiated the writing of this document, especially the
use of already standardized methods. use of already standardized methods. The analysis concludes that
using a zero UDP checksum is the best method of several proposed
alternatives to meet the goals for certain tunnel applications.
The analysis concludes that using UDP with a zero checksum is the This document defines recommendations and requirements for use of
best method of the proposed alternatives to meet the goals for IPv6 datagrams with a zero UDP checksum. This usage is expected to
certain tunnel applications. Unfortunately, this usage is expected have initial deployment issues related to middleboxes, limiting the
to have some 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 reduce as
updates for support of UDP zero checksum for IPv6 are provided to updates are provided in middleboxes that support the zero UDP
middleboxes. The document therefore derives a set of constraints checksum for IPv6. The document therefore derives a set of
required to ensure safe deployment of zero checksum in UDP. It also constraints required to ensure safe deployment of a zero UDP
identifies some issues that require future consideration and possibly checksum.
additional research.
Finally, the document also identifies some issues that require future
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 checksum in UDP 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 checksum. path and when it is suitable to use a zero UDP checksum.
Section 4 evaluates a set of proposals to update the UDP transport
behaviour and other alternatives intended to improve support for
tunnel protocols. It focuses on a proposal to allow a zero checksum
for this use-case with IPv6 and assesses the trade-offs that would
arise.
Section 5 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 UDP zero value in the checksum of a UDP datagram. use of a zero UDP checksum.
Section 6 provides an applicability statement that identifies 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 connection encapsulations that are transported over an IPv6 transport flow that
that does not perform a UDP checksum calculation to verify the does not perform a UDP checksum calculation to verify the integrity
integrity at the transport endpoints. at the transport endpoints.
Section 7 provides the recommendations for standardization of zero- Section 6 provides the recommendations for standardization of zero
checksum with a summary of the findings and notes remaining issues UDP checksum with a summary of the findings and notes remaining
needing future work. issues needing future work.
Appendix A evaluates the set of proposals to update the UDP transport
behaviour and other alternatives intended to improve support for
tunnel protocols. It concludes by assessing the trade-offs of the
various methods identifying advantages and disadvantages for 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
skipping to change at page 6, line 13 skipping to change at page 7, line 17
be used to create virtual (private) networks. 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 [I-D.ietf-mboned-auto-multicast],
and the Locator/Identifier Separation Protocol, LISP [LISP]). These and the Locator/Identifier Separation Protocol, LISP
protocols have proposed an update to IPv6 UDP checksum processing. [I-D.ietf-lisp]). These protocols motivated an update to IPv6 UDP
These tunnel protocols could benefit from simpler checksum processing checksum processing to benefit from simpler checksum processing for
for various reasons: various reasons:
o Reducing forwarding costs, motivated by redundancy present in the o Reducing forwarding costs, motivated by redundancy present in the
encapsulated packet header, since in tunnel encapsulations, encapsulated packet header, since in tunnel encapsulations,
payload integrity and length verification may be provided by payload integrity and length verification may be provided by
higher layer encapsulations (often using the IPv4, UDP, UDP-Lite, higher layer encapsulations (often using the IPv4, UDP, UDP-Lite,
or TCP checksums). or TCP checksums).
o Eliminating a need to access the entire packet when forwarding the o Eliminating a need to access the entire packet when forwarding the
packet by a tunnel endpoint. packet by a tunnel endpoint.
o Enhancing ability to traverse middleboxes, especially Network o Enhancing ability to traverse middleboxes, especially Network
Address Translators, NATs. Address Translators, NATs.
o A desire to use the port number space to enable load-sharing. o A desire to use the port number space to enable load-sharing.
1.3.2. Reducing forwarding cost 1.3.2. Reducing forwarding cost
It is a common requirement to terminate a large number of tunnels on It is a common requirement to terminate a large number of tunnels on
a single router/host. Processing per tunnel concerns both state a single router/host. The processing cost per tunnel includes both
(memory requirements) and per-packet processing costs. state (memory requirements) and per-packet processing.
Automatic IP Multicast Tunneling, known as AMT Automatic IP Multicast Tunneling, known as AMT
[I-D.ietf-mboned-auto-multicast] currently specifies UDP as the [I-D.ietf-mboned-auto-multicast] currently specifies UDP as the
transport protocol for packets carrying tunneled IP multicast transport protocol for packets carrying tunneled IP multicast
packets. The current specification for AMT requires that the UDP packets. The current specification for AMT requires that the UDP
checksum in the outer packet header should be 0 (see Section 6.6 of checksum in the outer packet header should be 0 (see Section 6.6 of
[I-D.ietf-mboned-auto-multicast]). It argues that the computation of [I-D.ietf-mboned-auto-multicast]). This argues that the computation
an additional checksum, when an inner packet is already adequately of an additional checksum is an unwarranted burden on nodes
protected, is an unwarranted burden on nodes implementing lightweight implementing lightweight tunneling protocols when an inner packet is
tunneling protocols. The AMT protocol needs to replicate a multicast already adequately protected, . The AMT protocol needs to replicate
packet to each gateway tunnel. In this case, the outer IP addresses a multicast packet to each gateway tunnel. In this case, the outer
are different for each tunnel and therefore require a different IP addresses are different for each tunnel and therefore require a
pseudo header to be built for each UDP replicated encapsulation. different pseudo header to be built for each UDP replicated
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: There are implementations that have
optimised checksum processing algorithms, including the use of optimised checksum processing algorithms, including the use of
checksum-offloading. This processing is readily available for IPv4 checksum-offloading. This processing is readily available for IPv4
packets at high line rates. Such processing may be anticipated for packets at high line rates. Such processing may be anticipated for
IPv6 endpoints, allowing receivers to reject corrupted packets IPv6 endpoints, allowing receivers to reject corrupted packets
without further processing. However, there are certain classes of without further processing. However, there are certain classes of
skipping to change at page 7, line 34 skipping to change at page 8, line 39
improvement, energy consumption and/or cost. improvement, energy consumption and/or cost.
1.3.4. Interactions with middleboxes 1.3.4. Interactions with middleboxes
In IPv4, UDP-encapsulation may be desirable for NAT traversal, since In IPv4, UDP-encapsulation may be desirable for NAT traversal, since
UDP support is commonly provided. It is also necessary due to the UDP support is commonly provided. It is also necessary due to the
almost ubiquitous deployment of IPv4 NATs. There has also been almost ubiquitous deployment of IPv4 NATs. There has also been
discussion of NAT for IPv6, although not for the same reason as in discussion of NAT for IPv6, although not for the same reason as in
IPv4. If IPv6 NAT becomes a reality they hopefully do not present IPv4. If IPv6 NAT becomes a reality they hopefully do not present
the same protocol issues as for IPv4. If NAT is defined for IPv6, it the same protocol issues as for IPv4. If NAT is defined for IPv6, it
should take UDP zero checksum into consideration. 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 UDP expected that a firewall conforming to RFC 2460 will not regard
datagrams with a zero checksum as valid packets. If a zero-checksum datagrams with a zero UDP checksum as valid. Use of a zero UDP
for UDP were to be allowed for IPv6, this would need firewalls to be checksum with IPv6 requires firewalls to be updated before the full
updated before full utility of the change is available. utility of the change is available.
It can be expected that UDP with zero-checksum will initially not It can be expected that datagrams with zero UDP checksum will
have the same middlebox traversal characteristics as regular UDP. initially not have the same middlebox traversal characteristics as
However, if standardized we can expect an improvement over time of regular UDP (RFC 2460). However when implementations follow the
the traversal capabilities. We also note that deployment of IPv6- requirements specified in this document, we expect the traversal
capable middleboxes is still in its initial phases. Thus, it might capabilities to improve over time. We also note that deployment of
be that the number of non-updated boxes quickly become a very small IPv6-capable middleboxes is still in its initial phases. Thus, it
percentage of the deployed middleboxes. might be that the number of non-updated boxes quickly become a very
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 utilise the IPv6 Flow
Label as basis for entropy for the load balancing. This would have Label as a basis for entropy for load balancing. This would have the
the desirable effect of releasing IPv6 load-balancing devices from desirable effect of releasing IPv6 load-balancing devices from the
the need to assume semantics for the use of the transport port field need to assume semantics for the use of the transport port field and
and also works for all type of transport protocols. This use of the also works for all type of transport protocols.
flow-label is consistent with the intended use, although further
clarity may be needed to ensure the field can be consistently used
for this purpose, (e.g. Equal-Cost Multi-Path routing, ECMP [ECMP]).
Router vendors could be encouraged to start using the IPv6 Flow Label This use of the flow-label is consistent with the intended use,
as a part of the flow hash, providing support for ECMP without although further clarity may be needed to ensure the field can be
requiring use of UDP. However, the method for populating the outer consistently used for this purpose, (e.g. the updated IPv6 Flow Label
IPv6 header with a value for the flow label is not trivial: If the Specification [RFC6437] and Equal-Cost Multi-Path routing, ECMP
inner packet uses IPv6, then the flow label value could be copied to [RFC6438]). Router vendors could be encouraged to start using the
the outer packet header. However, many current end-points set the IPv6 Flow Label as a part of the flow hash, providing support for
flow label to a zero value (thus no entropy). The ingress of a ECMP without requiring use of UDP.
tunnel seeking to provide good entropy in the flow label field would
therefore need to create a random flow label value and keep However, the method for populating the outer IPv6 header with a value
corresponding state, so that all packets that were associated with a for the flow label is not trivial: If the inner packet uses IPv6,
flow would be consistently given the same flow label. Although then the flow label value could be copied to the outer packet header.
possible, this complexity may not be desirable in a tunnel ingress. 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
entropy in the flow label field would therefore need to create a
random flow label value and keep corresponding state, so that all
packets that were associated with a flow would be consistently given
the same flow label. Although possible, this complexity may not be
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 is clarified, there
would be a transition time before a significant proportion of end- would be a transition time before a significant proportion of end-
points start to assign a good quality flow label to the flows that points start to assign a good quality flow label to the flows that
they originate, with continued use of load balancing using the they originate, with continued use of load balancing using the
transport header fields until any widespread deployment is finally transport header fields until any widespread deployment is finally
achieved. achieved.
2. Standards-Track Transports 2. Standards-Track Transports
skipping to change at page 9, line 18 skipping to change at page 10, line 26
UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as
a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and
unicast usage guidelines in [RFC5405]. There is at least one open unicast usage guidelines in [RFC5405]. There is at least one open
source implementation as a part of the Linux kernel since version source implementation as a part of the Linux kernel since version
2.6.20. 2.6.20.
UDP-Lite provides a checksum with optional partial coverage. When UDP-Lite provides a checksum with optional partial coverage. When
using this option, a datagram is divided into a sensitive part 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. Errors/corruption in the insensitive part fully equivalent with UDP, with the exception that it uses a
will not cause the datagram to be discarded by the transport layer at different value in the Next Header field in the IPv6 header. Errors/
the receiving endpoint. A minor side-effect of using UDP-Lite is corruption in the insensitive part will not cause the datagram to be
that this was specified for damage-tolerant payloads, and some link- discarded by the transport layer at the receiving endpoint. A minor
layers may employ different link encapsulations when forwarding UDP- side-effect of using UDP-Lite is that this was specified for damage-
Lite segments (e.g. radio access bearers). Most link-layers will tolerant payloads and some link-layers may employ different link
cover the insensitive part with the same strong layer 2 frame CRC encapsulations when forwarding UDP-Lite segments (e.g. radio access
that covers the sensitive part. bearers). Most link-layers will cover the insensitive part with the
same strong layer 2 frame 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 can use UDP-Lite (e.g. Control And
Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP- Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP-
Lite provides a transport-layer checksum, including an IP pseudo Lite provides a transport-layer checksum, including an IP pseudo
header checksum, in IPv6, without the need for a router/middelbox to header 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 the complexity of verification required for delivery and still keeps the complexity of
the checksumming operation low. UDP-Lite may set the length of the checksumming operation low. 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 only verify delivery of the
tunneled payload and uses full checksumming for control information. tunneled payload and uses full checksumming for control information.
There is currently poor support for middlebox traversal using UDP- There is currently poor support for middlebox traversal using UDP-
Lite, because UDP-Lite uses a different IPv6 network-layer Next Lite, because UDP-Lite uses a different IPv6 network-layer Next
Header value to that of UDP, and few middleboxes are able to Header value to that of UDP, and few middleboxes are able to
skipping to change at page 10, line 17 skipping to change at page 11, line 26
and are also not used as endpoint transport protocols. There is and are also not used as endpoint transport protocols. There is
little chance of confusing a tunnel-encapsulated packet with other little chance of confusing a tunnel-encapsulated packet with other
application data that could result in corruption of application state application data that could result in corruption of application state
or data. or data.
From the end-to-end perspective, the principal difference is that the From the end-to-end perspective, the principal difference is that the
network-layer Next Header field identifies a separate transport, network-layer Next Header field identifies a separate transport,
which reduces the probability that corruption could result in the which reduces the probability that corruption could result in the
packet being delivered to the wrong endpoint or application. packet being delivered to the wrong endpoint or application.
Specifically, packets are only delivered to protocol modules that Specifically, packets are only delivered to protocol modules that
process a specific next header value. The next header field process a specific Next Header value. The Next Header field
therefore provides a first-level check of correct demultiplexing. In therefore provides a first-level check of correct demultiplexing. In
contrast, the UDP port space is shared by many diverse applications contrast, the UDP port space is shared by many diverse applications
and therefore UDP demultiplexing relies solely on the port numbers. and therefore UDP demultiplexing relies solely on the port numbers.
3. Issues Requiring Consideration 3. Issues Requiring Consideration
This informative section evaluates issues around the proposal to This informative section evaluates issues around the proposal to
update IPv6 [RFC2460], to provide the option of using a UDP transport update IPv6 [RFC2460], to enable the UDP transport checksum to be set
checksum set to zero. Some of the identified issues are shared with to zero. Some of the identified issues are shared with other
other protocols already in use. protocols already in use. The section also provides background to
the requirements and recommendations that follow.
The decision by IPv6 to omit an integrity check at the network level The decision by RFC 2460 to omit an integrity check at the network
has meant that the transport check 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 the endpoint address was not corrupted within a router, i.e., a
packet was intended to be received by this destination and packet was intended to be received by this destination and
validate that the packet does not consist of a wrong header validate that the packet does not consist of a wrong header
spliced to a different payload; spliced to a different payload;
o that extension header processing is correctly delimited - i.e., o that extension header processing is correctly delimited - i.e.,
the start of data has not been corrupted. In this case, reception the start of data has not been corrupted. In this case, reception
of a valid next header value provides some protection; of 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 source
ports/addresses); 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 checks are performed using the IPv4 header
checksum. 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 mis-delivery 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. IP packets may be corrupted as they traverse an Internet path.
Evidence has been presented [Sigcomm2000] to show that this was once Evidence has been presented [Sigcomm2000] to show that this was once
an issue with IPv4 routers, and occasional corruption could result an issue with IPv4 routers, and occasional corruption could result
from bad internal router processing in routers or hosts. These from bad internal router processing in routers or hosts. These
errors are not detected by the strong frame checksums employed at the errors are not detected by the strong frame checksums employed at the
link-layer [RFC3819]. There is no current evidence that such cases link-layer [RFC3819]. There is no current evidence that such cases
skipping to change at page 12, line 45 skipping to change at page 14, line 5
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. to 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 this to another
context (if a context for the modified source address was already context (if a context for the modified source address was 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.
skipping to change at page 13, line 19 skipping to change at page 14, line 28
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 Reception of a datagram with a corrupted source address will
therefore result in accumulation of unnecessary state in the RTP therefore result in 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 Also, as noted above, ICMP messages relating to the corrupted
packet will be misdirected to the wrong source.
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 that 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 in values are corrupted in transit. This can also happen with IPv4 when
the zero checksum case, but not when UDP checksums are enabled or used with a zero UDP checksum, but not when UDP checksums are
with UDP-Lite. If the ports carried in the transport header of an calculated or with UDP-Lite. If the ports carried in the transport
IPv6 packet were corrupted in transit, packets may be delivered to header of an IPv6 packet were corrupted in transit, packets may be
the wrong process (on the intended machine) and/or responses or delivered to the wrong application process (on the intended machine)
errors sent to the wrong application process (on the intended and/or responses or errors sent to the wrong application process (on
machine). the intended machine).
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 destination address
and ports, there is a number of potential outcomes when traffic and ports, there is a number of potential outcomes when traffic
arrives at an unexpected port. This section discusses these arrives at an unexpected port. This section discusses these
possibilities and their outcomes for a packet that does not use the possibilities and their outcomes for a packet that does not use the
UDP checksum validation: UDP checksum validation:
o Delivery to a port that is not in use. The packet is discarded, o Delivery to a port that is not in use. The packet is discarded,
skipping to change at page 14, line 23 skipping to change at page 15, line 34
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 corrupt 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, DCCP, or SCTP). Together, this makes it hard
to verify that an application is given only the data associated to verify that an application process is given only the
with a 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 wild-card values in endpoint
identifiers and do not always validate correctness of datagrams identifiers and do not always validate correctness of datagrams
they receive (guidance on this topic is provided in [RFC5405]). 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 therefore needs
to provide a method to detect and discard the unwanted data. A to provide a method to detect and discard the unwanted data. A
tunnel protocol would need to perform its own integrity checks on any tunnel protocol would need to perform its own integrity checks on any
control information if transported in UDP with zero-checksum. If the control information if transported in datagrams with a zero UDP
tunnel payload is another IP packet, the packets requiring checksums checksum. If the tunnel payload is another IP packet, the packets
can be assumed to have their own checksums provided that the rate of requiring checksums can be assumed to have their own checksums
corrupted packets is not significantly larger due to the tunnel provided that the rate of corrupted packets is not significantly
encapsulation. If a tunnel transports other inner payloads that do larger due to the tunnel encapsulation. If a tunnel transports other
not use IP, the assumptions of corruption detection for that inner payloads that do not use IP, the assumptions of corruption
particular protocol must be fulfilled, this may require an additional detection for that particular protocol must be fulfilled, this may
checksum/CRC and/or integrity protection of the payload and tunnel require an additional checksum/CRC and/or integrity protection of the
headers. payload and tunnel headers.
A protocol using UDP zero-checksum can never assume that it is the A protocol that uses a zero UDP checksum can not assume that it is
only protocol using a zero checksum. Therefore, it needs to the only protocol using a zero UDP checksum. Therefore, it needs to
gracefully handle misdelivery. It must be robust to reception of gracefully handle mis-delivery. It must be robust to reception of
malformed packets received on a listening port and expect that these malformed packets received on a listening port and expect that these
packets may contain corrupted data or data associated with a 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, compared to only a 16-bit field in IPv4, a 13-bit fragment field, compared to only a 16-bit field in IPv4, a 13-bit fragment
offset and a 1-bit flag, indicating if there are more fragments. offset and a 1-bit flag, indicating if there are more fragments.
Corruption of any of these field may result in one of two outcomes: Corruption of any of these field may result in one of two outcomes:
skipping to change at page 15, line 30 skipping to change at page 16, line 41
and discarded. and discarded.
Erroneous reassembly: The re-assemblied packet did not match the Erroneous reassembly: The re-assemblied 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 completion of reassembly is much less probable,
since this would requires consistent corruption of the IPv6 since this would require consistent corruption of the IPv6 headers
headers payload length field and the offset field. The payload length field and the offset field. The possibility of
possibility of mis-assembly requires the reassembling stack to mis-assembly requires the reassembling stack to provide strong
provide strong checks that detect overlap or missing data, note checks that detect overlap or missing data, note however that this
however that this is not guaranteed and has recently been is not guaranteed and has recently been clarified in "Handling of
clarified in "Handling of Overlapping IPv6 Fragments" [RFC5722]. Overlapping IPv6 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 by the transport
checksum. The Upper-Layer Packet length field included in the pseudo checksum. The Upper-Layer Packet length field included in the pseudo
header assists in verifying correct reassembly, since the Internet header assists in verifying correct reassembly, since the Internet
checksum has a low probability of detecting insertion of data or checksum has a low probability of detecting insertion of data or
overlap errors (due to misplacement of data). The checksum is also overlap errors (due to misplacement of data). The checksum is also
incapable of detecting insertion or removal of all zero-data that incapable of detecting insertion or removal of all zero-data that
skipping to change at page 16, line 15 skipping to change at page 17, line 26
expands the size of a packet). Detection of this type of error expands the size of a packet). Detection of this type of error
requires a checksum or other integrity check of the headers and the requires a checksum or other integrity check of the headers and the
payload. Such protection is anyway desirable for tunnel payload. Such protection is anyway desirable for tunnel
encapsulations using IPv4, since the small fragmentation ID can encapsulations using IPv4, since the small fragmentation ID can
easily result in wrap-around [RFC4963], this is especially the case easily result in wrap-around [RFC4963], this is especially the case
for tunnels that perform flow aggregation [I-D.ietf-intarea-tunnels]. for tunnels that perform flow aggregation [I-D.ietf-intarea-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"
[I-D.ietf-intarea-tunnels]. If there is inner fragmentation by the [I-D.ietf-intarea-tunnels]. If there is inner fragmentation by the
tunnel, the outer headers will never be fragmented and thus a zero- tunnel, the outer headers will never be fragmented and thus a zero
checksum in the outer header will not affect the reassembly process. UDP checksum in the outer header will not affect the reassembly
When a tunnel performs outer header fragmentation, the tunnel egress process. When a tunnel performs outer header fragmentation, the
needs to perform reassembly of the outer fragments into an inner tunnel egress needs to perform reassembly of the outer fragments into
packet. The inner packet is either a complete packet or a fragment. an inner packet. The inner packet is either a complete packet or a
If it is a fragment, the destination endpoint of the fragment will fragment. If it is a fragment, the destination endpoint of the
perform reassembly of the received fragments. The complete packet or fragment will perform reassembly of the received fragments. The
the reassembled fragments will then be processed according to the complete packet or the reassembled fragments will then be processed
packet next header field. The receiver may only detect reassembly according to the packet Next Header field. The receiver may only
anomalies when it uses a protocol with a checksum. The larger the detect reassembly anomalies when it uses a protocol with a checksum.
number of reassembly processes to which a packet has been subjected, The larger the number of reassembly processes to which a packet has
the greater the probability of an error. been subjected, the greater the probability of an error.
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-checksum that also performs properties to a UDP tunnel with a zero UDP checksum that also
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 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 inner fragmentation unless it goes to the
inner most IP header. inner-most 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 for undetected error will increase with the number of times
fragmentation is recursively applied, making IP-in-IP and UDP with fragmentation is recursively applied, making IP-in-IP and UDP with
zero checksum both vulnerable to undetected errors. zero UDP checksum both vulnerable to undetected errors.
In conclusion fragmentation of packets with a zero-checksum does not In conclusion, fragmentation of datagrams with a zero UDP checksum
worsen the situation compared to some other commonly used tunnel does not worsen the performance compared to some other commonly used
encapsulations. However, caution is needed for recursive tunneling tunnel encapsulations. However, caution is needed for recursive
without any additional verification at the different tunnel layers. tunneling without any additional verification at the different tunnel
layers.
3.2. Validating the network path 3.2. Where Packet Corruption Occurs
Corruption of IP packets can occur at any point in the transmission
chain, during packet generation, in the transmission link, in the
process of routing and switching, etc. Some steps have checksum or
Cyclic Redundancy Check (CRC), which reduces the probability for
erroneous packets being used, but there still exists some probability
for errors to propagate undetected. Unfortunately we lack solid
information about what the most common functions or equipment that
generate packet corruption are. However we have indications that
there are significant variations in where corruption may occur. Thus
there is a risk in applying evidence from one domain of usage onto
another. Anyone intending general Internet usage must unfortunately
assume that corruption will occur and cope with it.
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 that change the set of routers and middleboxes along a path.
Therefore transports such as TCP, SCTP and DCCP have been designed to Therefore transports such as TCP, SCTP and DCCP have been designed to
negotiate protocol parameters, adapt to different network path negotiate protocol parameters, adapt to different network path
characteristics, and receive feedback to verify that the current path characteristics, and receive feedback to verify that the current path
is suited to the intended application. Applications using UDP and is suited to the intended application. Applications using UDP and
UDP-Lite need to provide their own mechanisms to confirm the validity UDP-Lite need to provide their own mechanisms to confirm the validity
of the current network path. of the current network path.
The zero-checksum in UDP is explicitly disallowed in RFC2460. Thus A zero value in the UDP checksum field is explicitly disallowed in
it may be expected that any device on the path that has a reason to RFC2460. Thus it may be expected that any device on the path that
look beyond the IP header will consider such a packet as erroneous or has a reason to look beyond the IP header will consider such a packet
illegal and may likely discard it, unless the device is updated to as erroneous or illegal and may discard it, unless the device is
support a new behavior. A pair of end-points intending to use a new updated to support the new behavior. A pair of end-points intending
behavior will therefore not only need to ensure support at each end- to use a new behavior will therefore not only need to ensure support
point, but also that the path between them will deliver packets with at each end-point, but also that the path between them will deliver
the new behavior. This may require negotiation or an explicit packets with the new behavior. This may require negotiation or an
mandate to use the new behavior by all nodes intended to use a new explicit mandate to use the new behavior by all nodes needed to
protocol. support the use of a new protocol.
Support along the path between end points may be guaranteed in Enabling the use of a zero checksum places new requirements on
equipment deployed within the network, such as middleboxes. A
middlebox (e.g. Firewalls, Network Address and Port Translation
(NAPT)) may enable zero checksum usage for a particular range of
ports. Note that checksum off-loading and operating system design
may result in all IPv6 UDP traffic being sent with a calculated
checksum. This requires middleboxes that are configured to enable a
zero UDP checksum to continue to work with bidirectional UDP flows
that use a zero UDP checksum in only one direction, and therefore
they must not maintain separate state for a UDP flow based on its
checksum usage.
Support along the path between end points can be guaranteed in
limited deployments by appropriate configuration. In general, it can limited deployments by appropriate configuration. In general, it can
be expected to take time for deployment of any updated behaviour to be expected to take time for deployment of any updated behaviour to
become ubiquitous. A sender will need to probe the path to verify become ubiquitous.
the expected behavior. Path characteristics may change, and usage
therefore should be robust and able to detect a failure of the path
under normal usage and re-negotiate. This will require periodic
validation of the path, adding complexity to any solution using the
new behavior.
3.3. Applicability of method A sender will need to probe the path to verify the expected behavior.
Path characteristics may change, and usage therefore should be robust
and able to detect a failure of the path under normal usage and re-
negotiate. Note that a bidirectional path does not necessarily
support the same checksum usage in both the forward and return
directions: Receipt of a datagram with a zero UDP checksum, does not
imply that the remote endpoint can also receive a datagram with a
zero UDP checksum. This will require periodic validation of the
path, adding complexity to any solution using the new behavior.
The expectation of the present proposal defined in 3.4. Applicability of method
[I-D.ietf-6man-udpchecksums] is that this change would only apply to
IPv6 router nodes that implement specific protocols that permit
omission of UDP checksums. However, the distinction between a router
and a host is not always clear, especially at the transport level.
Systems (such as unix-based operating systems) routinely provide both
functions. There is also no way to identify the role of a receiver
from a received packet.
Any new method would therefore need a specific applicability The IPv6 specification update defined in [I-D.ietf-6man-udpchecksums]
statement indicating when the mechanism can (and can not) be used. only modifies IPv6 nodes that implement specific protocols designed
to permit omission of a UDP checksum. This document therefore
provides an applicability statement for the updated method indicating
when the mechanism can (and can not) be used. Enabling this, and
ensuring correct interactions with the stack, implies much more than
simply disabling the checksum algorithm for specific packets at the
transport interface.
Enabling this, and ensuring correct interactions with the stack, When the method is widely available, it may be expected to be used by
implies much more than simply disabling the checksum algorithm for applications that are perceived to gain benefit. Any solution that
specific packets at the transport interface. uses an end-to-end transport protocol, rather than an IP-in-IP
encapsulation, needs to minimise the possibility that application
processes could confuse a corrupted or wrongly delivered UDP datagram
with that of data addressed to the application running on their
endpoint.
The IETF should carefully consider constraints on sanctioning the use First of all the using protocol or application must ensure that this
of any new transport mode. If this is specified and widely doesn't significantly affect themselves. That includes receiving
available, it may be expected to be used by applications that are packets from other protocols or contexts as an effect of the
perceived to gain benefit. Any solution that uses an end-to-end corruption of destination or source address and port values. That
transport protocol, rather than an IP-in-IP encapsulation, needs to also includes considering what additional implicit protection
minimise the possibility that end-hosts could confuse a corrupted or mechanisms that exist due to the usage the payload of the UDP packet
wrongly delivered packet with that of data addressed to an with a zero checksum have.
application running on their endpoint unless they accept that
behavior.
3.4. Impact on non-supporting devices or applications 3.5. Impact on non-supporting devices or applications
It is important to consider what potential impact the zero-checksum It is important to consider the potential impact of using a zero UDP
behavior may have on end-points, devices or applications that are not checksum on end-point devices or applications that are not modified
modified to support the new behavior or by default or preference, use to support the new behavior or by default or preference, use the
the regular behavior. These applications must not be significantly regular behavior. These applications must not be significantly
impacted by the changes. impacted by the update.
To illustrate a potential issue, consider the implications of a node To illustrate why this necessary, consider the implications of a node
that were to enable use of a zero-checksum at the interface level: enabling the use of a zero UDP checksum at the interface level: This
This would result in all applications that listen to a UDP socket would result in all applications that listen to a UDP socket
receiving datagram 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.
In contrast, the use of a zero-checksum could be enabled only for The use of a zero UDP checksum therefore needs to be enabled only for
individual ports using an explicit request by the application. In individual ports by an explicit request by the application. In this
this case, applications using other ports would maintain the current case, applications using other ports would maintain the current IPv6
IPv6 behavior, discarding incoming UDP datagrams with a zero- behavior, discarding incoming datagrams with a zero UDP checksum.
checksum. These other applications would not be effected by this These other applications would not be affected by this changed
changed behavior. An application that allows the changed behavior behavior. An application that allows the changed behavior should be
should be aware of the risk for corruption and the increased level of 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. Evaluation of proposal to update RFC 2460 to support zero checksum 4. Constraints on implementation of IPv6 nodes supporting zero checksum
This informative section evaluates the proposal to update IPv6 This section is an applicability statement that defines requirements
[RFC2460], to provide the option that some nodes may suppress and recommendations on the implementation of IPv6 nodes that support
generation and checking of the UDP transport checksum. It also use of a zero value in the checksum field of a UDP datagram.
compares the proposal with other alternatives.
4.1. Alternatives to the Standard Checksum All implementations that support this zero UDP checksum method MUST
conform to the requirements defined below.
1. An IPv6 sending node MAY use a calculated RFC 2460 checksum for
all datagrams that it sends. This explicitly permits an
interface that supports checksum offloading to insert an updated
UDP checksum value in all UDP datagrams that it forwards,
however note that sending a calculated checksum requires the
receiver to also perform the checksum calculation. Checksum
offloading can normally be switched off for a particular
interface to ensure that the datagrams are sent with a zero UDP
checksum.
2. IPv6 nodes SHOULD by default NOT allow the zero UDP checksum
method for transmission.
3. IPv6 nodes MUST provide a way for the application/protocol to
indicate the set of ports that will be enabled to send datagrams
with a zero UDP checksum. This may be implemented via a socket
API call, or similar mechanism. It may also be implemented by
enabling the method for a pre-assigned static port used by a
specific tunnel protocol.
4. IPv6 nodes MUST provide a method to allow an application/
protocol to indicate that a particular UDP datagram requires a
UDP checksum. This needs to be allowed by the operating system
at any time (e.g. to send keep-alive datagrams), not just when a
socket is established.
5. The default IPv6 node receiver behaviour MUST discard all IPv6
packets carrying datagrams with a zero UDP checksum.
6. IPv6 nodes MUST provide a way for the application/protocol to
indicate the set of ports that will be enabled to receive
datagrams with a zero UDP checksum. This may be implemented via
a socket API call, or similar mechanism. It may also be
implemented by enabling the method for a pre-assigned static
port used by a specific tunnel protocol.
7. IPv6 nodes supporting usage of zero UDP checksums MUST allow
reception using a calculated UDP checksum, also on ports
configured to allow zero UDP checksum usage. The sending
endpoint, e.g. encapsulating ingress, may choose to compute the
UDP checksum, or may calculate this by default. In either case,
the endpoint MUST use the reception method specified in RFC2460
when the checksum field is not zero.
8. RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams
with a zero UDP checksum. This remains the case for any
datagram received on a port that does not explicitly enable
processing of a zero UDP checksum. A port for which the zero
UDP checksum has been enabled MUST NOT log the datagram solely
because the checksum value is zero.
9. IPv6 nodes MAY separately identify received UDP datagrams that
are discarded with a zero UDP checksum. It SHOULD NOT add these
to the standard log, since the endpoint has not been verified.
This may be used to support other functions (such as a security
policy).
10. IPv6 nodes that receive ICMPv6 messages that refer to packets
with a zero UDP checksum MUST provide appropriate checks
concerning the consistency of the reported packet to verify that
the reported packet actually originated from the node, before
acting upon the information (e.g. validating the address and
port numbers in the ICMPv6 message body).
5. Requirements on the usage of zero UDP checksum
This section is an applicability statement that identifies
requirements and recommendations for protocols and tunnel
encapsulations that are transported over an IPv6 transport flow that
does not perform a UDP checksum calculation to verify the integrity
at the transport endpoints.
1. Protocols that enable the use of zero UDP checksum MUST only
enable this for a specific port or port-range. This needs to be
enabled at the sending and receiving endpoints for a UDP flow.
2. An integrity mechanism is always RECOMMENDED at the protocol
layer to ensure that corruption rates of delivered payloads or
encapsulated packets are not increased. A mechanism that
isolates the causes of corruption (e.g. identifying mis-
delivery, IPv6 header corruption, tunnel header corruption) is
expected to also provide additional information about the status
of the tunnel (e.g. to suggest a security attack).
3. A protocol that encapsulates Internet Protocol (IPv4 or IPv6)
packets MAY rely on the inner packet integrity checks, provided
that the tunnel protocol will not significantly increase the
rate of corruption of the inner IP packet. If a significantly
increased corruption rate can occur, then the protocol MUST
provide an additional integrity verification mechanism. Early
detection is desirable to avoid wasting unnecessary computation/
transmission capacity/storage for packets that will subsequently
be discarded.
4. A protocol that supports use of a zero UDP checksum MUST be
designed so that corruption of the protocol header information
does not result in accumulated state for the protocol.
5. A UDP based protocol with an non-tunnel payload or that
encapsulate non-IP packets MUST have a CRC or other mechanism
for checking packet integrity, unless the non-IP packet is
specifically designed for transmission over lower layers that do
not provide a packet integrity guarantee.
6. A protocol with control feedback SHOULD be robust to changes in
the network path. The set of middleboxes on a path may vary
during the life of an association. Endpoints need to discover
paths with middleboxes that drop packets with a zero UDP
checksum. Therefore protocols SHOULD send keep-alive messages
with a zero UDP checksum. An endpoint that discovers an
appreciable loss rate for keep-alive packets MAY terminate the
tunnel. Section 3.1.3 of RFC 5405 describes requirements for
congestion control when using UDP-based transport.
7. A protocol with control feedback that can fall-back to using UDP
with a calculated RFC 2460 checksum are expected to be more
robust to changes in the network path. Therefore keep-alive
messages SHOULD include both UDP datagrams with a checksum and
datagrams with a zero UDP checksum. This will enable the remote
endpoint to distinguish between a path failure and dropping of
datagrams with a zero UDP checksum.
8. Middlebox implementations MUST allow forwarding of IPv6 UDP
datagram with both a zero and standard UDP checksum.
9. A middlebox MAY configure a restricted set of specific port
ranges that forward UDP datagrams with a zero UDP checksum. The
middlebox MAY drop IPv6 datagrams with a zero UDP checksum that
are outside a configured range.
10. When a middlebox forwards IPv6 UDP datagram flows containing
datagrams with both zero and standard UDP checksum, the
middlebox MUST NOT maintain separate state for the flow
depending on the value of the UDP checksum field. This
requirement is necessary to enable a sender that always
calculates a checksum to communicate via a middlebox with a
remote endpoint that uses a zero UDP checksum.
6. Summary
This document examines the role of the UDP transport checksum when
used with IPv6. It presents a summary of the trade-offs in
evaluating the safety of updating RFC 2460 to permit an IPv6 endpoint
to use a zero UDP checksum field to indicate that no checksum is
present.
The use of UDP with a zero UDP checksum has merits for some
applications, such as tunnel encapsulation, and is widely used in
IPv4. However, there are different dangers for IPv6: There is an
increased risk of corruption and mis-delivery when using zero UDP
checksum in IPv6 compared to IPv4, due to the lack of an IPv6 header
checksum. Thus, applications need to re-evaluate the 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 example
by utilizing UDP-Lite, or by enabling the UDP checksum. The use of
checksum off-loading may help alleviate the checksum processing cost
and permit use of a checksum using method defined in RFC 2460.
Tunnel applications using UDP for encapsulation can in many cases use
a zero UDP checksum without significant impact on the corruption
rate. A well-designed tunnel application should include consistency
checks to validate the header information encapsulated with a
received packet. In most cases, tunnels encapsulating IP packets can
rely on the inner packets' own integrity protection. When correctly
implemented, such a tunnel endpoint will not be negatively impacted
by omission of the transport-layer checksum. Recursive tunneling and
fragmentation is a potential issue that can raise corruption rates
significantly, and requires careful consideration.
Other UDP applications at the intended destination node or another
node can be impacted if they are allowed to receive datagrams that
have a zero UDP checksum. It is important that already deployed
applications are not impacted by a change at the transport layer. If
these applications execute on nodes that implement RFC 2460, they
will discard (and log) all datagrams with a zero UDP checksum. This
is not an issue.
In general, UDP-based applications need to employ a mechanism that
allows a large percentage of the corrupted packets to be removed
before they reach an application, both to protect the data stream of
the application and the control plane of higher layer protocols.
These checks are currently performed by the UDP checksum for IPv6, or
the reduced checksum for UDP-Lite when used with IPv6.
Recursive tunneling and fragmentation is a difficult issue relating
to tunnels in general. There is an increased risk of an error in the
inner-most packet when fragmentation results from several layers of
tunneling and several different reassembly processes are run without
verification of correctness. This issue requires extra thought and
careful consideration.
The use of the updated method must consider the implications on
firewalls, NATs and other middleboxes. It is not expected that IPv6
NATs handle IPv6 UDP datagrams in the same way that they handle IPv4
UDP datagrams. This possibly reduces the need to update the
checksum. Firewalls are intended to be configured, and therefore may
need to be explicitly updated to allow new services or protocols.
IPv6 middlebox deployment is not yet as prolific as it is in IPv4,
and therefore new devices are expected to follow the methods
specified in this document.
Each application should consider the implications of choosing an IPv6
transport that uses a zero UDP checksum, and consider whether other
standard methods may be more appropriate, and may simplify
application design.
7. Acknowledgements
Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert,
others in the TSV directorate.
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.
Barry Leiba, Ronald Bonica and Stewart Bryant are thanked for
resulting in a document with much greater applicability.
A Special thanks to P.F. Chimento for review and editorial
corrections.
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
stack, although they can not be considered authentication mechanisms.
These checks are also desirable to ensure packet counters correctly
log actual activity, and can be used to detect unusual behaviours.
Depending on the hardware design, the processing requirements may
differ for tunnels that have a zero UDP checksum and those that
calculate a checksum. This processing overhead may need to be
considered when deciding whether to enable a tunnel and to determine
an acceptable rate for transmission.
Transmission of IPv6 packets with a zero UDP checksum could reveal
additional information to an on-path attacker to identify the
operating system or configuration of a sending node. There is a need
to probe the network path to determine whether the path supports
using IPv6 packets with a zero UDP checksum. The details of the
probing mechanism may differ for different tunnel encapsulations and
if visible in the network (e.g. if not using IPsec in encryption
mode) could reveal additional information to an on-path attacker to
identify the type of tunnel being used.
IP-in-IP or GRE tunnels offer good traversal of middleboxes that have
not been designed for security, e.g. firewalls. However, firewalls
may be expected to be configured to block general tunnels as they
present a large attack surface. This applicability statement
therefore permits this method to be enabled only for specific ranges
of ports.
10. References
10.1. Normative References
[I-D.ietf-6man-udpchecksums]
Eubanks, M., Chimento, P., and M. Westerlund, "UDP
Checksums for Tunneled Packets",
draft-ietf-6man-udpchecksums-05 (work in progress),
October 2012.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
10.2. Informative References
[I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-00 (work in
progress), March 2010.
[I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-24 (work in progress), November 2012.
[I-D.ietf-mboned-auto-multicast]
Bumgardner, G., "Automatic Multicast Tunneling",
draft-ietf-mboned-auto-multicast-14 (work in progress),
June 2012.
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071,
September 1988.
[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the
Internet checksum", RFC 1141, January 1990.
[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via
Incremental Update", RFC 1624, May 1994.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, July 2007.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification", RFC 5415, March 2009.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, November 2011.
[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.
[Sigcomm2000]
Jonathan Stone and Craig Partridge , "When the CRC and TCP
Checksum Disagree", 2000.
[UDPTT] G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010.
Appendix A. Evaluation of proposal to update RFC 2460 to support zero
checksum
This informative appendix documents the evaluation of the proposal to
update IPv6 [RFC2460], to provide the option that some nodes may
suppress generation and checking of the UDP transport checksum. It
also compares the proposal with other alternatives, and notes that
for a particular application some standard methods may be more
appropriate than using IPv6 with a zero UDP 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): (in decreasing order of complexity):
o Delta computation of the checksum from an encapsulated checksum o Delta computation of the checksum from an encapsulated checksum
field. Since the checksum is a cumulative sum [RFC1624], an field. Since the checksum is a cumulative sum [RFC1624], an
encapsulating header checksum can be derived from the new pseudo encapsulating header checksum can be derived from the new pseudo
header, the inner checksum and the sum of the other network-layer header, the inner checksum and the sum of the other network-layer
fields not included in the pseudo header of the encapsulated fields not included in the pseudo header of the encapsulated
packet, in a manner resembling incremental checksum update packet, in a manner resembling incremental checksum update
[RFC1141]. This would not require access to the whole packet, but [RFC1141]. This would not require access to the whole packet, but
skipping to change at page 20, line 9 skipping to change at page 29, line 47
o A method has been proposed that uses a new (to be defined) IPv6 o A method has been proposed that uses a new (to be defined) IPv6
Destination Options Header to provide an end-to-end validation Destination Options Header to provide an end-to-end validation
check at the network layer. This would allow an endpoint to check at the network layer. This would allow an endpoint to
verify delivery to an appropriate end point, but would also verify delivery to an appropriate end point, but would also
require IPv6 nodes to correctly handle the additional header, and require IPv6 nodes to correctly handle the additional header, and
would require changes to middlebox behavior (e.g. when used with a would require changes to middlebox behavior (e.g. when used with a
NAT that always adjusts the checksum value). NAT that always adjusts the checksum value).
o UDP modified to disable checksum processing o UDP modified to disable checksum processing
[I-D.ietf-6man-udpchecksums]. This requires no checksum [I-D.ietf-6man-udpchecksums]. This eliminates the need for a
calculation, but would require constraints on appropriate usage checksum calculation, but would require constraints on appropriate
and updates to end-points and middleboxes. usage and updates to end-points and middleboxes.
o IP-in-IP tunneling. As this method completely dispenses with a o IP-in-IP tunneling. As this method completely dispenses with a
transport protocol in the outer-layer it has reduced overhead and transport protocol in the outer-layer it has reduced overhead and
complexity, but also reduced functionality. There is no outer complexity, but also reduced functionality. There is no outer
checksum over the packet and also no ports to perform checksum over the packet and also no ports to perform
demultiplexing between different tunnel types. This reduces the demultiplexing between different tunnel types. This reduces the
information available upon which a load balancer may act. 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.
4.2. Comparison A.2. Comparison
This section compares the above listed methods to support datagram This section compares the above listed methods to support datagram
tunneling. It includes proposals for updating the behaviour of UDP. tunneling. It includes proposals for updating the behaviour of UDP.
4.2.1. Middlebox Traversal While this comparison focuses on applications that are expected to
execute on routers, the distinction between a router and a host is
not always clear, especially at the transport level. Systems (such
as unix-based operating systems) routinely provide both functions.
There is no way to identify the role of the receiving node from a
received packet.
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 have the best
possibilities for successful traversal of a middlebox. No new possibilities 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 may also traverse a perform an incremental checksum update. UDPTT may also traverse a
middlebox with this behaviour. However, a middlebox on the path that middlebox with this behaviour. However, a middlebox on the path that
attempts to verify a standard checksum will not forward packets using attempts to verify a standard checksum will not forward packets using
either of these methods, preventing traversal. A method that ignores either of these methods, preventing traversal. A method that ignores
the checksum has an additional downside in that it prevents the checksum has an additional downside in that it prevents
improvement of middlebox traversal, because there is no way to improvement of middlebox traversal, because there is no way to
identify packets that use the modified checksum behaviour. identify UDP datagrams that use the 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 as they
present a large attack surface. 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.
Packets using UDP with a zero 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 the zero checksum packets. 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 type 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 update would be identical to that for UDP, but different for checksum
validation. validation.
4.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 equally good behavior as for UDP. However, UDP-Lite is currently
likely to not be supported by deployed hashing mechanisms, which may unlikely to be supported by deployed hashing mechanisms, which may
cause a load balancer to not use the transport header in the computed cause a load balancer to not use the transport header in the computed
hash. A load balancer that only uses the IP header will have low hash. A load balancer that only uses the IP header will have low
entropy, but could be improved by including the IPv6 the flow label, entropy, but could be improved by including the IPv6 the flow label,
providing that the tunnel ingress ensures that different flow labels providing that the tunnel ingress ensures that different flow labels
are assigned to different flows. However, a transition to the common are assigned to different flows. However, a transition to the common
use of good quality flow labels is likely to take time to deploy. use of good quality flow labels is likely to take time to deploy.
4.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 low data overhead. The other
proposals introduce a UDP-like header incurring associated data proposals introduce a UDP-like header incurring associated data
overhead. Processing is minimised for the zero-checksum method, overhead. Processing is minimised for the method that uses a zero
ignoring the checksum on reception, and only slightly higher for UDP checksum, ignoring the UDP checksum on reception, and only
UDPTT, the extension header and UDP-Lite. The delta-calculation slightly higher for UDPTT, the extension header and UDP-Lite. The
scheme operates on a few more fields, but also introduces serious delta-calculation scheme operates on a few more fields, but also
failure modes that can result in a need to calculate a checksum over introduces serious failure modes that can result in a need to
the complete packet. Regular UDP is clearly the most costly to calculate a checksum over the complete datagram. Regular UDP is
process, always requiring checksum calculation over the entire clearly the most costly to process, always requiring checksum
packet. calculation over the entire datagram.
It is important to note that the zero-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.
4.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 end-points, a need for negotiation and the need
to update middleboxes. These are summarised below: to update middleboxes. These are summarised 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
skipping to change at page 22, line 31 skipping to change at page 32, line 31
devices, which are expected to require updates. 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 end-points. The never ceasing risk of path failure requires
additional checks to ensure this solution is robust and will additional checks to ensure this solution is robust and will
require changes or additions to the tunneling control protocol to require changes or additions to the tunneling control protocol to
negotiate support and validate the path. negotiate support and validate the path.
o The remaining solutions offer similar deployability. UDP-Lite o The remaining solutions offer similar deployability. UDP-Lite
requires support at both end-points and in middleboxes. UDPTT and requires support at both end-points and in middleboxes. UDPTT and
Zero-checksum with or without an Extension header require support the zero UDP checksum method with or without an extension header
at both end-points and in middleboxes. UDP-Lite, UDPTT, and Zero- require support at both end-points and in middleboxes. UDP-Lite,
checksum and Extension header may additionally require changes or UDPTT, and the zero UDP checksum method and use of extension
additions to the tunneling control protocol to negotiate support headers may additionally require changes or additions to the
and path validation. tunneling control protocol to negotiate support and path
validation.
4.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 do not verify the inner packet.
They only provide a strong indication that the delivered packet was They only provide a strong indication that the delivered packet was
intended for the tunnel egress and was correctly delimited. The intended for the tunnel egress and was correctly delimited. The
Zero-checksum, ignoring the checksum on reception and IP-and-IP methods using a zero UDP checksum, ignoring the UDP checksum on
encapsulation provide no verification that a received packet was reception and IP-and-IP encapsulation all provide no verification
intended to be processed by a specific tunnel egress or that the that a received datagram was intended to be processed by a specific
inner packet was correct. tunnel egress or that the inner encapsulated packet was correct.
4.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 summarised as "there is no silver bullet
that will slay all the issues". One has to select which down side(s) that will slay all the issues". One has to select which down side(s)
can best be lived with. Focusing on the existing solutions, this can can best be lived with. Focusing on the existing solutions, this can
be summarized as: be summarized as:
Regular UDP: Good middlebox traversal and load balancing and Regular UDP: The method defined in RFC 2460 has good middlebox
multiplexing, requiring a checksum in the outer headers covering traversal and load balancing and multiplexing, requiring a
the whole packet. checksum in the outer headers covering the whole packet.
IP in IP: A low complexity encapsulation, with limited middlebox IP in IP: A low complexity encapsulation, with limited middlebox
traversal, no multiplexing support, and currently poor load traversal, no multiplexing support, and currently poor load
balancing support that could improve over time. balancing support that could improve over time.
UDP-Lite: A medium complexity encapsulation, with good multiplexing UDP-Lite: A medium complexity encapsulation, with good multiplexing
support, limited middlebox traversal, but possible to improve over support, limited middlebox traversal, but possible to improve over
time, currently poor load balancing support that could improve time, currently poor load balancing support that could improve
over time, in most cases requiring application level negotiation over time, in most cases requiring application level negotiation
and validation. to select the protocol and validation to confirm the path forwards
UDP-Lite.
The delta-checksum is an optimization in the processing of UDP, as The delta-checksum is an optimization in the processing of UDP, as
such it exhibits some of the drawbacks of using regular UDP. 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, with 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, good load balancing support, in most cases
requiring application level negotiation and validation. requiring application level negotiation and validation to confirm
the path forwards a zero UDP checksum.
UDPTT: A medium complexity encapsulation, with good multiplexing UDPTT: A medium complexity encapsulation, with good multiplexing
support, limited middlebox traversal, but possible to improve over support, limited middlebox traversal, but possible to improve over
time, good load balancing support, in most cases requiring time, good load balancing support, in most cases requiring
application level negotiation and validation. application level negotiation to select the 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, with no multiplexing support, limited middlebox traversal,
currently poor load balancing support that could improve over currently poor load balancing support that could improve over
time, in most cases requiring application level negotiation and time, in most cases requiring negotiation to confirm the option is
validation. 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 UDP Zero-checksuming: A medium
complexity encapsulation, with good multiplexing support, limited complexity encapsulation, with good multiplexing support, limited
load balancing support that could improve over time, in most cases load balancing support that could improve over time, in most cases
requiring application level negotiation and validation. requiring negotiation to confirm the option is 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 with good multiplexing support, medium middlebox traversal that
never can improve, good load balancing support, in most cases never can improve, good load balancing support, in most cases
requiring application level negotiation and validation. requiring negotiation to confirm the option is supported by the
remote endpoint and validation to confirm the 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, then 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, low complexity is necessary and one does not require load
balancing, then IP-in-IP tunneling is the simplest. If one wants balancing, then IP-in-IP tunneling is the simplest. If one wants
strengthened error detection, but with currently limited middlebox strengthened error detection, but with currently limited middlebox
traversal and load-balancing. UDP-Lite is appropriate. UDP Zero- traversal and load-balancing. UDP-Lite is appropriate. Zero UDP
checksum addresses another set of constraints, low complexity and a checksum addresses another set of constraints, low complexity and a
need for load balancing from the current Internet, providing it can need for load balancing from the current Internet, providing it can
live with currently limited middlebox traversal. live with currently limited 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 since it requires
both load balancer and end-point updates to get full benefit. The both load balancer and end-point 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. One potential advantage expected to take long time cycles to evolve.
is that the deployment of IPv6 capable middleboxes are still in its
initial phase and the quicker zero-checksum becomes standardized the
fewer boxes will be non-compliant.
Thus, the question of whether to allow UDP with a zero-checksum for One potential advantage is that the deployment of IPv6-capable
IPv6 under reasonable constraints, is therefore best viewed as a middleboxes are still in its initial phase and the quicker a new
trade-off between a number of more subjective questions: method becomes standardized, the fewer boxes will be non-compliant.
o Is there sufficient interest in zero-checksum with the given Thus, the question of whether to permit use of datagrams with a zero
constraints (summarised below)? UDP checksum for IPv6 under reasonable constraints, is therefore best
viewed as a trade-off between a number of more subjective questions:
o Is there sufficient interest in using a zero UDP checksum with the
given constraints (summarised 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 authors do think the answer to the above questions are such that The analysis concludes that the IETF should carefully consider
zero-checksum should be standardized for use by tunnel constraints on sanctioning the use of any new transport mode. The
encapsulations. 6man working group of the IETF has determined that the answer to the
above questions are sufficient to update IPv6 to standardise use of a
5. Constraints on implementation of IPv6 nodes supporting zero checksum zero UDP checksum for use by tunnel encapsulations for specific
applications.
This section is an applicability statement that defines requirements
and recommendations on the implementation of IPv6 nodes that support
the use of a UDP zero value in the checksum of a UDP datagram.
1. IPv6 nodes SHOULD by default NOT allow the zero checksum method
for transmission or reception.
2. The default node receiver behaviour MUST discard all IPv6 packets
carrying UDP datagrams with a zero checksum. IPv6 nodes MUST
provide a way for the application/protocol to indicate the set of
ports that will be enabled to send UDP datagrams with a zero
checksum. This may be implemented via a socket API call, or
similar mechanism. It may also be implemented by enabling the
method for a pre-assigned static port used by a specific tunnel
protocol.
3. IPv6 nodes MUST provide a way for the application/protocol to
indicate the set of ports that will be enabled to receive UDP
datagrams with a zero checksum.
4. RFC 2460 specifies that IPv6 nodes SHOULD log received UDP
datagrams with a zero-checksum. This should remain the case for
any datagram received on a port that does not explicitly enable
zero-checksum processing. A port for which zero-checksum has
been enabled MUST NOT log the datagram solely because the
checksum is zero, but MAY log this to support other functions
(such as a security policy).
5. IPv6 nodes MAY separately identify received UDP datagrams that
are discarded with a zero checksum. It SHOULD NOT add these to
the standard log, since the endpoint has not been verified.
6. IPv6 nodes that receive ICMPv6 messages that refer to packets
with a zero UDP checksum MUST provide appropriate checks
concerning the consistency of the reported packet to verify that
the reported packet actually originated from the node, before
acting upon the information (e.g. validating the address and port
numbers in the ICMPv6 message body).
6. Requirements on the specification of transported protocols
This section is an applicability statement that identifies
requirements and recommendations for protocols and tunnel
encapsulations that are transported over an IPv6 transport connection
that does not perform a UDP checksum calculation to verify the
integrity at the transport endpoints.
1. UDP Tunnels that enable the use of zero checksum MUST only enable
this only for a specific port or port-range.
2. UDP Tunnels that encapsulate IP MAY rely on the inner packet
integrity checks provided that the tunnel will not significantly
increase the rate of corruption of the inner IP packet. If a
significantly increased corruption rate can occur, then the
tunnel MUST provide an additional integrity verification
mechanism. Early detection is desirable to avoid wasting
unneccessary computation/storage for packets that will
subsequently be discarded.
3. An integrity mechanisms is always RECOMMENDED at the tunnel layer
to ensure that corruption rates of the inner-most packet are not
increased. A mechanism that isolates the causes of corruption
(e.g. identifying mis-delivery, IPv6 header corruption, tunnel
header corruption) is expected to also provide additional
information about the status of the tunnel (e.g. to suggest a
security attack).
4. UDP Tunnels that encapsulate non-IP packets MUST have a CRC or
other mechanism for checking packet integrity, unless the non-IP
packet specifically is designed for transmission over lower
layers that do not provide any packet integrity guarantee. In
particular, the tunnel endpoint MUST be designed so that
corruption of this information does not result in accumulated
state or incorrect processing of a tunneled payload.
5. UDP Tunnels that support use of a zero-checksum, SHOULD NOT rely
upon correct reception of the IP and UDP protocol information
(including the length of the packet) when decoding and processing
the packet payload. In particular, the application MUST be
designed so that corruption of this information does not result
in accumulated state or incorrect processing of a tunneled
payload.
6. A UDP Tunnel egress that supports a zero UDP checksum MUST also
allow reception using a standard UDP checksum. The encapsulating
endpoint may choose to compute the UDP checksum, or the sending
endpoint IPv6 stack may enable this by default. In either case,
the remote endpoint uses the reception method specified in
RFC2460.
7. UDP Tunnels with control feedback need to be robust to changes in
network path. The set of middleboxes on a path may vary during
the life of an association. Endpoints need to discover paths
with middleboxes that drop packets with a zero UDP checksum.
Therefore keep-alive messages SHOULD include both UDP datagrams
with a checksum and UDP datagrams with a zero checksum. This
will enable the remote endpoint to distinguish between a path
failure and dropping of UDP datagrams with a zero checksum. Note
that path validation need only be performed for each pair of
tunnel endpoints, not for each tunnel context.
8. Middleboxes implementations MUST allow IPv6 packets forward both
a zero and standard UDP checksum. A middlebox MAY configure
specific port ranges that forward UDP datagrams with a zero UDP
checksum. These middleboxes MUST forward both standard and zero
checksum UDP datagrams within the configured range, but may drop
IPv6 UDP datagrams with a zero checksum that are outside the
configured ranges.
7. Summary
This document examines the role of the transport checksum when used
with IPv6, as defined in RFC2460.
It presents a summary of the trade-offs for evaluating the safety of
updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value
in the checksum field to indicate that no checksum is present. A
decision not to include a UDP checksum in received IPv6 datagrams
could impact a tunnel application that receives these packets.
However, a well-designed tunnel application should include
consistency checks to validate any header information encapsulated
with a packet. In most cases tunnels encapsulating IP packets can
rely on the inner packets own integrity protection. When correctly
implemented, such a tunnel endpoint will not be negatively impacted
by omission of the transport-layer checksum. Recursive tunneling and
fragmentation is a potential issue that can raise corruption rates
significantly, and requires careful consideration.
Other applications at the intended destination node or another IPv6
node can be impacted if they are allowed to receive datagrams that do
not have a transport-layer checksum. It is particularly important
that already deployed applications are not impacted by any change at
the transport layer. If these applications execute on nodes that
implement RFC 2460, they will reject all datagrams with a zero UDP
checksum, thus this is not an issue. For nodes that implement
support for zero-checksum it is important to ensure that only UDP
applications that desire zero-checksum can receive and originate
zero-checksum packets. Thus, the enabling of zero-checksum needs to
be at a port level, not for the entire host or for all use of an
interface.
The implications on firewalls, NATs and other middleboxes need to be
considered. It is not expected that IPv6 NATs handle IPv6 UDP
datagrams in the same way that they handle IPv4 UDP datagrams. This
possibly reduces the need to update the checksum. Firewalls are
intended to be configured, and therefore may need to be explicitly
updated to allow new services or protocols. IPv6 middlebox
deployment is not yet as prolific as it is in IPv4. Thus, relatively
few current middleboxes may actually block IPv6 UDP with a zero
checksum.
In general, UDP-based applications need to employ a mechanism that
allows a large percentage of the corrupted packets to be removed
before they reach an application, both to protect the data stream of
the application and the control plane of higher layer protocols.
These checks are currently performed by the UDP checksum for IPv6, or
the reduced checksum for UDP-Lite when used with IPv6.
The use of UDP with no checksum has merits for some applications,
such as tunnel encapsulation, and is widely used in IPv4. However,
there are dangers for IPv6: There is a bigger risk of corruption and
miss-delivery when using zero-checksum in IPv6 compared to IPv4 due
to the removed IP header checksum. Thus, applications need to make a
new evaluation of the risks of enabling a zero-checksum. Some
applications will need to re-consider their usage of zero-checksum,
and possibly consider a solution that at least provides the same
delivery protection as for IPv4, for example by utilizing UDP-Lite,
or by enabling the UDP checksum. Tunnel applications using UDP for
encapsulation can in many case use zero-checksum without significant
impact on the corruption rate. In some cases, the use of checksum
off-loading may help alleviate the checksum processing cost.
Recursive tunneling and fragmentation is a difficult issue relating
to tunnels in general. There is an increased risk of an error in the
inner-most packet when fragmentation when several layers of tunneling
and several different reassembly processes are run without
verification of correctness. This issue requires future thought and
consideration.
The conclusion is that UDP zero checksum in IPv6 should be
standardized, as it satisfies usage requirements that are currently
difficult to address. We do note that a safe deployment of zero-
checksum will need to follow a set of constraints listed in
Section 5.
8. Acknowledgements
Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert,
others in the TSV directorate.
Thanks also to: Remi Denis-Courmont, Pekka Savola and many others who
contributed comments and ideas via the 6man, behave, lisp and mboned
lists.
9. IANA Considerations
This document does not require any actions by IANA.
10. Security Considerations
Transport checksums provide the first stage of protection for the
stack, although they can not be considered authentication mechanisms.
These checks are also desirable to ensure packet counters correctly
log actual activity, and can be used to detect unusual behaviours.
11. References
11.1. Normative References
[I-D.ietf-6man-udpchecksums]
Eubanks, M., Chimento, P., and M. Westerlund, "UDP
Checksums for Tunneled Packets",
draft-ietf-6man-udpchecksums-04 (work in progress),
September 2012.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
11.2. Informative References
[ECMP] "Using the IPv6 flow label for equal cost multipath
routing in tunnels (draft-carpenter-flow-ecmp)".
[I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-00 (work in
progress), March 2010.
[I-D.ietf-mboned-auto-multicast]
Bumgardner, G., "Automatic Multicast Tunneling",
draft-ietf-mboned-auto-multicast-14 (work in progress),
June 2012.
[LISP] D. Farinacci et al, "Locator/ID Separation Protocol
(LISP)", March 2009.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071,
September 1988.
[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the
Internet checksum", RFC 1141, January 1990.
[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via
Incremental Update", RFC 1624, May 1994.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, July 2007.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification", RFC 5415, March 2009.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[Sigcomm2000]
Jonathan Stone and Craig Partridge , "When the CRC and TCP
Checksum Disagree", 2000.
[UDPTT] G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010. Each application should consider the implications of choosing an IPv6
transport that uses a zero UDP checksum. In many cases, standard
methods may be more appropriate, and may simplify application design.
The use of checksum off-loading may help alleviate the checksum
processing cost and permit use of a checksum using method defined in
RFC 2460.
Appendix A. Document Change History Appendix B. Document Change History
{RFC EDITOR NOTE: This section must be deleted prior to publication} {RFC EDITOR NOTE: This section must be deleted prior to publication}
Individual Draft 00 This is the first DRAFT of this document - It Individual Draft 00 This is the first DRAFT of this document - It
contains a compilation of various discussions and contributions contains a compilation of various discussions and contributions
from a variety of IETF WGs, including: mboned, tsv, 6man, lisp, from a variety of IETF WGs, including: mboned, tsv, 6man, lisp,
and behave. This includes contributions from Magnus with text on and behave. This includes contributions from Magnus with text on
RTP, and various updates. RTP, and various updates.
Individual Draft 01 Individual Draft 01
skipping to change at page 32, line 47 skipping to change at page 36, line 41
Working Group Draft 05 Working Group Draft 05
* Resubmission to correct editorial NiTs - thanks to Bill Atwood * Resubmission to correct editorial NiTs - thanks to Bill Atwood
for noting these.Group Draft 05. for noting these.Group Draft 05.
Working Group Draft 06 Working Group Draft 06
* Resubmission to keep draft alive (spelling updated from 05). * Resubmission to keep draft alive (spelling updated from 05).
WoIt that UDP with a zero checksum in IPv6 can safely be used for Working Group Draft 07
this purpose, provided that this usage is governed by a set of
constraints.rking Group Draft 07 * Interim Version
* Resubmission after IESG Feedback * Resubmission after IESG Feedback
* This document becomes a PS Applicability Statement
* 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)
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
Phone:
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
Fax:
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
URI:
 End of changes. 101 change blocks. 
648 lines changed or deleted 789 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/