draft-ietf-6man-udpzero-08.txt   draft-ietf-6man-udpzero-09.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: June 14, 2013 Ericsson Expires: July 23, 2013 Ericsson
December 11, 2012 January 19, 2013
Applicability Statement for the use of IPv6 UDP Datagrams with Zero Applicability Statement for the use of IPv6 UDP Datagrams with Zero
Checksums Checksums
draft-ietf-6man-udpzero-08 draft-ietf-6man-udpzero-09
Abstract Abstract
This document provides an applicability statement for the use of UDP This document provides an applicability statement for the use of UDP
transport checksums with IPv6. It defines recommendations and transport checksums with IPv6. It defines recommendations and
requirements for the use of IPv6 UDP datagrams with a zero UDP requirements for the use of IPv6 UDP datagrams with a zero UDP
checksum. It describes the issues and design principles that need to checksum. It describes the issues and design principles that need to
be considered when UDP is used with IPv6 to support tunnel be considered when UDP is used with IPv6 to support tunnel
encapsulations and examines the role of the IPv6 UDP transport encapsulations and examines the role of the IPv6 UDP transport
checksum. An appendix presents a summary of the trade-offs that were checksum. An appendix presents a summary of the trade-offs that were
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 June 14, 2013. This Internet-Draft will expire on July 23, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 3, line 34 skipping to change at page 3, line 34
3.1.2. Corruption of the source IP address . . . . . . . . . 13 3.1.2. Corruption of the source IP address . . . . . . . . . 13
3.1.3. Corruption of Port Information . . . . . . . . . . . . 14 3.1.3. Corruption of Port Information . . . . . . . . . . . . 14
3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 15 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 15
3.1.5. Corruption of Fragmentation Information . . . . . . . 16 3.1.5. Corruption of Fragmentation Information . . . . . . . 16
3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 18 3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 18
3.3. Validating the network path . . . . . . . . . . . . . . . 18 3.3. Validating the network path . . . . . . . . . . . . . . . 18
3.4. Applicability of method . . . . . . . . . . . . . . . . . 19 3.4. Applicability of method . . . . . . . . . . . . . . . . . 19
3.5. Impact on non-supporting devices or applications . . . . . 20 3.5. Impact on non-supporting devices or applications . . . . . 20
4. Constraints on implementation of IPv6 nodes supporting 4. Constraints on implementation of IPv6 nodes supporting
zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 20 zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Requirements on the usage of zero UDP checksum . . . . . . . . 22 5. Requirements on usage of the zero UDP checksum . . . . . . . . 22
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Evaluation of proposal to update RFC 2460 to Appendix A. Evaluation of proposal to update RFC 2460 to
support zero checksum . . . . . . . . . . . . . . . . 28 support zero checksum . . . . . . . . . . . . . . . . 28
A.1. Alternatives to the Standard Checksum . . . . . . . . . . 28 A.1. Alternatives to the Standard Checksum . . . . . . . . . . 28
A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 30 A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 30
A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 30 A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 30
A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 31 A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 31
A.2.3. Ingress and Egress Performance Implications . . . . . 31 A.2.3. Ingress and Egress Performance Implications . . . . . 31
A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 32 A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 31
A.2.5. Corruption Detection Strength . . . . . . . . . . . . 32 A.2.5. Corruption Detection Strength . . . . . . . . . . . . 32
A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 33 A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 32
Appendix B. Document Change History . . . . . . . . . . . . . . . 35 Appendix B. Document Change History . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 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 RFC 2460 mandates use of a calculated UDP checksum, and IPv6 is that RFC 2460 mandates use of a calculated UDP checksum,
i.e. a non-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.
Algorithms for checksum computation are described in [RFC1071].
The lack of a possibility to use an IPv6 datagram with a zero UDP The lack of a possibility to use an IPv6 datagram with a zero UDP
checksum has been observed as a real problem for certain classes of checksum has been observed as a real problem for certain classes of
application, primarily tunnel applications. This class of application, primarily tunnel applications. This class of
application has been deployed with a zero UDP checksum using IPv4. application has been deployed with a zero UDP checksum using IPv4.
The design of IPv6 raises different issues when considering the The design of IPv6 raises different issues when considering the
safety of using a UDP checksum with IPv6. These issues can safety of using a UDP checksum with IPv6. These issues can
significantly affect applications, both when an endpoint is the significantly affect applications, both when an endpoint is the
intended user and when an innocent bystander (i.e. a packet received intended user and when an innocent bystander (when a packet is
by a different endpoint to that intended). received by a different endpoint to that intended).
This document examines the issues and an appendix compares the 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
identifies a set of issues that must be considered and mitigated to identifies a set of issues that must be considered and mitigated to
be able to safely deploy IPv6 applications that use a zero UDP be able to safely deploy IPv6 applications that use a zero UDP
checksum. 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. The analysis concludes that use of already standardized methods. The analysis concludes that
using a zero UDP checksum is the best method of several proposed using a zero UDP checksum is the best method of the proposed
alternatives to meet the goals for certain tunnel applications. alternatives to meet the goals for certain tunnel applications.
This document defines recommendations and requirements for use of This document defines recommendations and requirements for use of
IPv6 datagrams with a zero UDP checksum. This usage is expected to IPv6 datagrams with a zero UDP checksum. This usage is expected to
have initial deployment issues related to middleboxes, limiting the have initial deployment issues related to middleboxes, limiting the
usability more than desired in the currently deployed internet. usability more than desired in the currently deployed internet.
However, this limitation will be largest initially and will reduce as However, this limitation will be largest initially and will reduce as
updates are provided in middleboxes that support the zero UDP updates are provided in middleboxes that support the zero UDP
checksum for IPv6. The document therefore derives a set of checksum for IPv6. The document therefore derives a set of
constraints required to ensure safe deployment of a zero UDP constraints required to ensure safe deployment of a zero UDP
skipping to change at page 6, line 23 skipping to change at page 6, line 23
Section 3 discusses issues with a zero UDP checksum for IPv6. It Section 3 discusses issues with a zero UDP checksum for IPv6. It
considers the impact of corruption, the need for validation of the considers the impact of corruption, the need for validation of the
path and when it is suitable to use a zero UDP checksum. path and when it is suitable to use a zero UDP checksum.
Section 4 is an applicability statement that defines requirements and Section 4 is an applicability statement that defines requirements and
recommendations on the implementation of IPv6 nodes that support the recommendations on the implementation of IPv6 nodes that support the
use of a zero UDP checksum. use of a zero UDP checksum.
Section 5 provides an applicability statement that defines Section 5 provides an applicability statement that defines
requirements and recommendations for protocols and tunnel requirements and recommendations for protocols and tunnel
encapsulations that are transported over an IPv6 transport flow that encapsulations that are transported over an IPv6 transport that does
does not perform a UDP checksum calculation to verify the integrity not perform a UDP checksum calculation to verify the integrity at the
at the transport endpoints. transport endpoints.
Section 6 provides the recommendations for standardization of zero Section 6 provides the recommendations for standardization of zero
UDP checksum with a summary of the findings and notes remaining UDP checksum with a summary of the findings and notes remaining
issues needing future work. issues needing future work.
Appendix A evaluates the set of proposals to update the UDP transport Appendix A evaluates the set of proposals to update the UDP transport
behaviour and other alternatives intended to improve support for behaviour and other alternatives intended to improve support for
tunnel protocols. It concludes by assessing the trade-offs of the tunnel protocols. It concludes by assessing the trade-offs of the
various methods identifying advantages and disadvantages for each various methods, identifying advantages and disadvantages for each
method. 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
skipping to change at page 7, line 17 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 and the Locator/Identifier Separation Protocol, LISP [LISP]). These
[I-D.ietf-lisp]). These protocols motivated an update to IPv6 UDP protocols motivated an update to IPv6 UDP checksum processing to
checksum processing to benefit from simpler checksum processing for benefit from simpler checksum processing 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.
skipping to change at page 7, line 46 skipping to change at page 7, line 45
1.3.2. Reducing forwarding cost 1.3.2. Reducing forwarding cost
It is a common requirement to terminate a large number of tunnels on It is a common requirement to terminate a large number of tunnels on
a single router/host. The processing cost per tunnel includes both a single router/host. The processing cost per tunnel includes both
state (memory requirements) and per-packet processing. 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 zero (see Section 6.6
[I-D.ietf-mboned-auto-multicast]). This argues that the computation of [I-D.ietf-mboned-auto-multicast]). This argues that the
of an additional checksum is an unwarranted burden on nodes computation of an additional checksum is an unwarranted burden on
implementing lightweight tunneling protocols when an inner packet is nodes implementing lightweight tunneling protocols when an inner
already adequately protected, . The AMT protocol needs to replicate packet is already adequately protected, . The AMT protocol needs to
a multicast packet to each gateway tunnel. In this case, the outer replicate a multicast packet to each gateway tunnel. In this case,
IP addresses are different for each tunnel and therefore require a the outer IP addresses are different for each tunnel and therefore
different pseudo header to be built for each UDP replicated require a different pseudo header to be built for each UDP replicated
encapsulation. 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
skipping to change at page 9, line 22 skipping to change at page 9, line 21
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 a basis for entropy for load balancing. This would have the Label as a basis for entropy for load balancing. This would have the
desirable effect of releasing IPv6 load-balancing devices from the desirable effect of releasing IPv6 load-balancing devices from the
need to assume semantics for the use of the transport port field and need to assume semantics for the use of the transport port field and
also works for all type of transport protocols. also works for all type of transport protocols.
This use of the flow-label is consistent with the intended use, This use of the flow-label is consistent with the intended use,
although further clarity may be needed to ensure the field can be although further clarity may be needed to ensure the field can be
consistently used for this purpose, (e.g. the updated IPv6 Flow Label consistently used for this purpose, (e.g. the updated IPv6 Flow Label
Specification [RFC6437] and Equal-Cost Multi-Path routing, ECMP [RFC6438] and Equal-Cost Multi-Path routing, ECMP [RFC6437]). Router
[RFC6438]). Router vendors could be encouraged to start using the vendors could be encouraged to start using the IPv6 Flow Label as a
IPv6 Flow Label as a part of the flow hash, providing support for part of the flow hash, providing support for ECMP without requiring
ECMP without requiring use of UDP. use of UDP.
However, the method for populating the outer IPv6 header with a value However, the method for populating the outer IPv6 header with a value
for the flow label is not trivial: If the inner packet uses IPv6, for the flow label is not trivial: If the inner packet uses IPv6,
then the flow label value could be copied to the outer packet header. then the flow label value could be copied to the outer packet header.
However, many current end-points set the flow label to a zero value 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 (thus no entropy). The ingress of a tunnel seeking to provide good
entropy in the flow label field would therefore need to create a entropy in the flow label field would therefore need to create a
random flow label value and keep corresponding state, so that all random flow label value and keep corresponding state, so that all
packets that were associated with a flow would be consistently given packets that were associated with a flow would be consistently given
the same flow label. Although possible, this complexity may not be the same flow label. Although possible, this complexity may not be
skipping to change at page 10, line 43 skipping to change at page 10, line 42
bearers). Most link-layers will cover the insensitive part with the bearers). Most link-layers will cover the insensitive part with the
same strong layer 2 frame CRC that covers the sensitive part. 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/middlebox 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 a low complexity
the checksumming operation low. UDP-Lite may set the length of for the checksumming operation. UDP-Lite may set the length of
checksum coverage on a per packet basis. This feature could be used checksum coverage on a per packet basis. This feature could be used
if a tunnel protocol is designed to only verify delivery of the if a tunnel protocol is designed to only verify delivery of the
tunneled payload and uses full checksumming for control information. tunneled payload and uses a calcuated checksum 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
interpret UDP-Lite and take appropriate actions when forwarding the interpret UDP-Lite and take appropriate actions when forwarding the
packet. This makes UDP-Lite less suited to protocols needing general packet. This makes UDP-Lite less suited to protocols needing general
Internet support, until such time that UDP-Lite has achieved better Internet support, until such time that UDP-Lite has achieved better
support in middleboxes and end-points. support in middleboxes and end-points.
2.3. General Tunnel Encapsulations 2.3. General Tunnel Encapsulations
skipping to change at page 12, line 22 skipping to change at page 12, line 22
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 mis-delivery to an unintended application information may lead to misdelivery to an unintended application
socket on an unexpected host. socket on an unexpected host.
3.1. Effect of packet modification in the network 3.1. Effect of packet modification in the network
IP packets may be corrupted as they traverse an Internet path. 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
are rare in the modern Internet, nor that they may not be applicable are rare in the modern Internet, nor that they may not be applicable
to IPv6. It therefore seems prudent not to relax this constraint. to IPv6. It therefore seems prudent not to relax this constraint.
The emergence of low-end IPv6 routers and the proposed use of NAT The emergence of low-end IPv6 routers and the proposed use of NAT
with IPv6 further motivate the need to protect from this type of with IPv6 further motivate the need to protect from this type of
error. error.
Corruption in the network may result in: Corruption in the network may result in:
o A datagram being mis-delivered to the wrong host/router or the o A datagram being misdelivered to the wrong host/router or the
wrong transport entity within an endpoint. Such a datagram needs wrong transport entity within an endpoint. Such a datagram needs
to be discarded; to be discarded;
o A datagram payload being corrupted, but still delivered to the o A datagram payload being corrupted, but still delivered to the
intended host/router transport entity. Such a datagram needs to intended host/router transport entity. Such a datagram needs to
be either discarded or correctly processed by an application that be either discarded or correctly processed by an application that
provides its own integrity checks; provides its own integrity checks;
o A datagram payload being truncated by corruption of the length o A datagram payload being truncated by corruption of the length
field. Such a datagram needs to be discarded. field. Such a datagram needs to be discarded.
skipping to change at page 14, line 5 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 pre-established context may o An application that requires a per-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 14, line 28 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 o ICMP messages relating to a corrupted packet can be misdirected to
packet will be misdirected to the wrong source. the wrong source node.
In general, the effect of corrupting the source address will depend In general, the effect of corrupting the source address will depend
upon the protocol that processes the packet and its robustness to upon the protocol that processes the packet and its robustness to
this error. For the case where the packet is received by a tunnel this error. For the case where the packet is received by a tunnel
endpoint, the tunnel application is expected to correctly handle a endpoint, the tunnel application is expected to correctly handle a
corrupted source address. corrupted source address.
The impact of source address modification is more difficult to The impact of source address modification is more difficult to
quantify when the receiving application is not that originally quantify when the receiving application is not 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 when values are corrupted in transit. This can also happen with IPv4 is
used with a zero UDP checksum, but not when UDP checksums are used with a zero UDP checksum, but not when UDP checksums are
calculated or with UDP-Lite. If the ports carried in the transport calculated or when UDP-Lite is used. If the ports carried in the
header of an IPv6 packet were corrupted in transit, packets may be transport header of an IPv6 packet were corrupted in transit, packets
delivered to the wrong application process (on the intended machine) may be delivered to the wrong application process (on the intended
and/or responses or errors sent to the wrong application process (on machine) and/or responses or errors sent to the wrong application
the intended machine). process (on 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 16, line 12 skipping to change at page 16, line 12
requiring checksums can be assumed to have their own checksums requiring checksums can be assumed to have their own checksums
provided that the rate of corrupted packets is not significantly provided that the rate of corrupted packets is not significantly
larger due to the tunnel encapsulation. If a tunnel transports other larger due to the tunnel encapsulation. If a tunnel transports other
inner payloads that do not use IP, the assumptions of corruption inner payloads that do not use IP, the assumptions of corruption
detection for that particular protocol must be fulfilled, this may detection for that particular protocol must be fulfilled, this may
require an additional checksum/CRC and/or integrity protection of the require an additional checksum/CRC and/or integrity protection of the
payload and tunnel headers. payload and tunnel headers.
A protocol that uses a zero UDP checksum can not assume that it is A protocol that uses a zero UDP checksum can not assume that it is
the only protocol using a zero UDP checksum. Therefore, it needs to the only protocol using a zero UDP checksum. Therefore, it needs to
gracefully handle mis-delivery. It must be robust to reception of gracefully handle misdelivery. 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 16, line 45 skipping to change at page 16, line 45
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 require consistent corruption of the IPv6 headers since this would require consistent corruption of the IPv6 headers
payload length field and the offset field. The possibility of payload length field and the offset field. The possibility of
mis-assembly requires the reassembling stack to provide strong mis-assembly requires the reassembling stack to provide strong
checks that detect overlap or missing data, note however that this checks that detect overlap or missing data, note however that this
is not guaranteed and has recently been clarified in "Handling of is not guaranteed and has been 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
skipping to change at page 18, line 22 skipping to change at page 18, line 22
zero UDP checksum both vulnerable to undetected errors. zero UDP checksum both vulnerable to undetected errors.
In conclusion, fragmentation of datagrams with a zero UDP checksum In conclusion, fragmentation of datagrams with a zero UDP checksum
does not worsen the performance compared to some other commonly used does not worsen the performance compared to some other commonly used
tunnel encapsulations. However, caution is needed for recursive tunnel encapsulations. However, caution is needed for recursive
tunneling without any additional verification at the different tunnel tunneling without any additional verification at the different tunnel
layers. layers.
3.2. Where Packet Corruption Occurs 3.2. Where Packet Corruption Occurs
Corruption of IP packets can occur at any point in the transmission Corruption of IP packets can occur at any point along a network path,
chain, during packet generation, in the transmission link, in the during packet generation, during transmission over the link, in the
process of routing and switching, etc. Some steps have checksum or process of routing and switching, etc. Some transmission steps
Cyclic Redundancy Check (CRC), which reduces the probability for include a checksum or Cyclic Redundancy Check (CRC) that reduces the
erroneous packets being used, but there still exists some probability probability for corrupted packets being forwarded, but there still
for errors to propagate undetected. Unfortunately we lack solid exists a probability that errors may propagate undetected.
information about what the most common functions or equipment that Unfortunately the community lacks reliable information to identify
generate packet corruption are. However we have indications that the most common functions or equipment that result in packet
there are significant variations in where corruption may occur. Thus corruption. However, there are indications that the place where
there is a risk in applying evidence from one domain of usage onto corruption occurs can vary significantly from one path to another.
another. Anyone intending general Internet usage must unfortunately There is therefore a risk in applying evidence from one domain of
assume that corruption will occur and cope with it. usage to infer characteristics for another. Methods intended for
general Internet usage must therefore assume that corruption can
occur and deploy mechanisms to mitigate the effect of corruption
and/or resulting misdelivery.
3.3. Validating the network path 3.3. Validating the network path
IP transports designed for use in the general Internet should not IP transports designed for use in the general Internet should not
assume specific path characteristics. Network protocols may reroute assume specific path characteristics. Network protocols may reroute
packets that change the set of routers and middleboxes along a path. packets that change the set of routers and middleboxes along a path.
Therefore transports such as TCP, SCTP and DCCP have been designed to Therefore transports such as TCP, SCTP and DCCP have been designed to
negotiate protocol parameters, adapt to different network path negotiate protocol parameters, adapt to different network path
characteristics, and receive feedback to verify that the current path characteristics, and receive feedback to verify that the current path
is suited to the intended application. Applications using UDP and is suited to the intended application. Applications using UDP and
UDP-Lite need to provide their own mechanisms to confirm the validity UDP-Lite need to provide their own mechanisms to confirm the validity
of the current network path. of the current network path.
A zero value in the UDP checksum field is explicitly disallowed in A zero value in the UDP checksum field is explicitly disallowed in
RFC2460. Thus it may be expected that any device on the path that RFC2460. Thus it may be expected that any device on the path that
has a reason to look beyond the IP header will consider such a packet has a reason to look beyond the IP header will consider such a packet
as erroneous or illegal and may discard it, unless the device is as erroneous or illegal and may discard it, unless the device is
updated to support the new behavior. A pair of end-points intending updated to support the new behavior. A pair of end-points intending
to use a new behavior will therefore not only need to ensure support to use a new behavior will therefore not only need to ensure support
at each end-point, but also that the path between them will deliver at each end-point, but also that the path between them will deliver
packets with the new behavior. This may require negotiation or an packets with the new behavior. This may require using negotiation or
explicit mandate to use the new behavior by all nodes needed to an explicit mandate to use the new behavior by all nodes that support
support the use of a new protocol. the new protocol.
Enabling the use of a zero checksum places new requirements on Enabling the use of a zero checksum places new requirements on
equipment deployed within the network, such as middleboxes. A equipment deployed within the network, such as middleboxes. A
middlebox (e.g. Firewalls, Network Address and Port Translation middlebox (e.g. Firewalls, Network Address Translators) may enable
(NAPT)) may enable zero checksum usage for a particular range of zero checksum usage for a particular range of ports. Note that
ports. Note that checksum off-loading and operating system design checksum off-loading and operating system design may result in all
may result in all IPv6 UDP traffic being sent with a calculated IPv6 UDP traffic being sent with a calculated checksum. This
checksum. This requires middleboxes that are configured to enable a requires middleboxes that are configured to enable a zero UDP
zero UDP checksum to continue to work with bidirectional UDP flows checksum to continue to work with bidirectional UDP flows that use a
that use a zero UDP checksum in only one direction, and therefore zero UDP checksum in only one direction, and therefore they must not
they must not maintain separate state for a UDP flow based on its maintain separate state for a UDP flow based on its checksum usage.
checksum usage.
Support along the path between end points can be guaranteed in 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. become ubiquitous.
A sender will need to probe the path to verify the expected behavior. A sender will need to probe the path to verify the expected behavior.
Path characteristics may change, and usage therefore should be robust Path characteristics may change, and usage therefore should be robust
and able to detect a failure of the path under normal usage and re- and able to detect a failure of the path under normal usage and re-
negotiate. Note that a bidirectional path does not necessarily negotiate. Note that a bidirectional path does not necessarily
support the same checksum usage in both the forward and return support the same checksum usage in both the forward and return
directions: Receipt of a datagram with a zero UDP checksum, does not directions: Receipt of a datagram with a zero UDP checksum, does not
imply that the remote endpoint can also receive a datagram with a imply that the remote endpoint can also receive a datagram with a
zero UDP checksum. This will require periodic validation of the zero UDP checksum. This will require periodic validation of the
path, adding complexity to any solution using the new behavior. path, adding complexity to any solution using the new behavior.
3.4. Applicability of method 3.4. Applicability of method
The IPv6 specification update defined in [I-D.ietf-6man-udpchecksums] The update to the IPv6 specification defined in
only modifies IPv6 nodes that implement specific protocols designed [I-D.ietf-6man-udpchecksums] only modifies IPv6 nodes that implement
to permit omission of a UDP checksum. This document therefore specific protocols designed to permit omission of a UDP checksum.
provides an applicability statement for the updated method indicating This document therefore provides an applicability statement for the
when the mechanism can (and can not) be used. Enabling this, and updated method indicating when the mechanism can (and can not) be
ensuring correct interactions with the stack, implies much more than used. Enabling this, and ensuring correct interactions with the
simply disabling the checksum algorithm for specific packets at the stack, implies much more than simply disabling the checksum algorithm
transport interface. for specific packets at the transport interface.
When the method is widely available, it may be expected to be used by When the method is widely available, it may be expected to be used by
applications that are perceived to gain benefit. Any solution that applications that are perceived to gain benefit. Any solution that
uses an end-to-end transport protocol, rather than an IP-in-IP uses an end-to-end transport protocol, rather than an IP-in-IP
encapsulation, needs to minimise the possibility that application encapsulation, needs to minimise the possibility that application
processes could confuse a corrupted or wrongly delivered UDP datagram processes could confuse a corrupted or wrongly delivered UDP datagram
with that of data addressed to the application running on their with that of data addressed to the application running on their
endpoint. endpoint.
First of all the using protocol or application must ensure that this The protocol or application that uses the zero checksum method must
doesn't significantly affect themselves. That includes receiving ensure that the lack of checksum does not affect the protocol
packets from other protocols or contexts as an effect of the operation. This includes being robust to receiving a unintended
corruption of destination or source address and port values. That packet from another protocol or context following corruption of a
also includes considering what additional implicit protection destination or source address and/or port value. It also includes
mechanisms that exist due to the usage the payload of the UDP packet considering the need for additional implicit protection mechanisms
with a zero checksum have. required when using the payload of a UDP packet received with a zero
checksum.
3.5. Impact on non-supporting devices or applications 3.5. Impact on non-supporting devices or applications
It is important to consider the potential impact of using a zero UDP It is important to consider the potential impact of using a zero UDP
checksum on end-point devices or applications that are not modified checksum on end-point devices or applications that are not modified
to support the new behavior or by default or preference, use the to support the new behavior or by default or preference, use the
regular behavior. These applications must not be significantly regular behavior. These applications must not be significantly
impacted by the update. impacted by the update.
To illustrate why this necessary, consider the implications of a node To illustrate why this necessary, consider the implications of a node
enabling the use of a zero UDP checksum at the interface level: This that enables use of a zero UDP checksum at the interface level: This
would result in all applications that listen to a UDP socket would result in all applications that listen to a UDP socket
receiving datagrams where the checksum was not verified. This could receiving datagrams where the checksum was not verified. This could
have a significant impact on an application that was not designed have a significant impact on an application that was not designed
with the additional robustness needed to handle received packets with with the additional robustness needed to handle received packets with
corruption, creating state or destroying existing state in the corruption, creating state or destroying existing state in the
application. application.
The use of a zero UDP checksum therefore needs to be enabled only for A zero UDP checksum therefore needs to be enabled only for individual
individual ports by an explicit request by the application. In this ports using an explicit request by the application. In this case,
case, applications using other ports would maintain the current IPv6 applications using other ports would maintain the current IPv6
behavior, discarding incoming datagrams with a zero UDP checksum. behavior, discarding incoming datagrams with a zero UDP checksum.
These other applications would not be affected by this changed These other applications would not be affected by this changed
behavior. An application that allows the changed behavior should be behavior. An application that allows the changed behavior should be
aware of the risk of 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. Constraints on implementation of IPv6 nodes supporting zero checksum 4. Constraints on implementation of IPv6 nodes supporting zero checksum
This section is an applicability statement that defines requirements This section is an applicability statement that defines requirements
skipping to change at page 21, line 12 skipping to change at page 21, line 15
All implementations that support this zero UDP checksum method MUST All implementations that support this zero UDP checksum method MUST
conform to the requirements defined below. conform to the requirements defined below.
1. An IPv6 sending node MAY use a calculated RFC 2460 checksum for 1. An IPv6 sending node MAY use a calculated RFC 2460 checksum for
all datagrams that it sends. This explicitly permits an all datagrams that it sends. This explicitly permits an
interface that supports checksum offloading to insert an updated interface that supports checksum offloading to insert an updated
UDP checksum value in all UDP datagrams that it forwards, UDP checksum value in all UDP datagrams that it forwards,
however note that sending a calculated checksum requires the however note that sending a calculated checksum requires the
receiver to also perform the checksum calculation. Checksum receiver to also perform the checksum calculation. Checksum
offloading can normally be switched off for a particular offloading can normally be switched off for a particular
interface to ensure that the datagrams are sent with a zero UDP interface to ensure that datagrams are sent with a zero UDP
checksum. checksum.
2. IPv6 nodes SHOULD by default NOT allow the zero UDP checksum 2. IPv6 nodes SHOULD by default NOT allow the zero UDP checksum
method for transmission. method for transmission.
3. IPv6 nodes MUST provide a way for the application/protocol to 3. IPv6 nodes MUST provide a way for the application/protocol to
indicate the set of ports that will be enabled to send datagrams indicate the set of ports that will be enabled to send datagrams
with a zero UDP checksum. This may be implemented via a socket with a zero UDP checksum. This may be implemented by enabling a
API call, or similar mechanism. It may also be implemented by transport mode using a socket API call when the socket is
enabling the method for a pre-assigned static port used by a established, or a similar mechanism. It may also be implemented
by enabling the method for a pre-assigned static port used by a
specific tunnel protocol. specific tunnel protocol.
4. IPv6 nodes MUST provide a method to allow an application/ 4. IPv6 nodes MUST provide a method to allow an application/
protocol to indicate that a particular UDP datagram requires a protocol to indicate that a particular UDP datagram is required
UDP checksum. This needs to be allowed by the operating system to be sent with a UDP checksum. This needs to be allowed by the
at any time (e.g. to send keep-alive datagrams), not just when a operating system at any time (e.g. to send keep-alive
socket is established. datagrams), not just when a socket is established in the zero
checksum mode.
5. The default IPv6 node receiver behaviour MUST discard all IPv6 5. The default IPv6 node receiver behaviour MUST discard all IPv6
packets carrying datagrams with a zero UDP checksum. packets carrying datagrams with a zero UDP checksum.
6. IPv6 nodes MUST provide a way for the application/protocol to 6. IPv6 nodes MUST provide a way for the application/protocol to
indicate the set of ports that will be enabled to receive indicate the set of ports that will be enabled to receive
datagrams with a zero UDP checksum. This may be implemented via datagrams with a zero UDP checksum. This may be implemented via
a socket API call, or similar mechanism. It may also be a socket API call, or similar mechanism. It may also be
implemented by enabling the method for a pre-assigned static implemented by enabling the method for a pre-assigned static
port used by a specific tunnel protocol. port used by a specific tunnel protocol.
7. IPv6 nodes supporting usage of zero UDP checksums MUST allow 7. IPv6 nodes supporting usage of zero UDP checksums MUST also
reception using a calculated UDP checksum, also on ports allow reception using a calculated UDP checksum on all ports
configured to allow zero UDP checksum usage. The sending configured to allow zero UDP checksum usage. (The sending
endpoint, e.g. encapsulating ingress, may choose to compute the endpoint, e.g. encapsulating ingress, may choose to compute the
UDP checksum, or may calculate this by default. In either case, UDP checksum, or may calculate this by default.) The receving
the endpoint MUST use the reception method specified in RFC2460 endpoint MUST use the reception method specified in RFC2460 when
when the checksum field is not zero. the checksum field is not zero.
8. RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams 8. RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams
with a zero UDP checksum. This remains the case for any with a zero UDP checksum. This remains the case for any
datagram received on a port that does not explicitly enable datagram received on a port that does not explicitly enable
processing of a zero UDP checksum. A port for which the zero processing of a zero UDP checksum. A port for which the zero
UDP checksum has been enabled MUST NOT log the datagram solely UDP checksum has been enabled MUST NOT log the datagram solely
because the checksum value is zero. because the checksum value is zero.
9. IPv6 nodes MAY separately identify received UDP datagrams that 9. IPv6 nodes MAY separately identify received UDP datagrams that
are discarded with a zero UDP checksum. It SHOULD NOT add these are discarded with a zero UDP checksum. It SHOULD NOT add these
skipping to change at page 22, line 20 skipping to change at page 22, line 25
This may be used to support other functions (such as a security This may be used to support other functions (such as a security
policy). policy).
10. IPv6 nodes that receive ICMPv6 messages that refer to packets 10. IPv6 nodes that receive ICMPv6 messages that refer to packets
with a zero UDP checksum MUST provide appropriate checks with a zero UDP checksum MUST provide appropriate checks
concerning the consistency of the reported packet to verify that concerning the consistency of the reported packet to verify that
the reported packet actually originated from the node, before the reported packet actually originated from the node, before
acting upon the information (e.g. validating the address and acting upon the information (e.g. validating the address and
port numbers in the ICMPv6 message body). port numbers in the ICMPv6 message body).
5. Requirements on the usage of zero UDP checksum 5. Requirements on usage of the zero UDP checksum
This section is an applicability statement that identifies This section is an applicability statement that identifies
requirements and recommendations for protocols and tunnel requirements and recommendations for protocols and tunnel
encapsulations that are transported over an IPv6 transport flow that encapsulations that are transported over an IPv6 transport flow (e.g.
does not perform a UDP checksum calculation to verify the integrity tunnel) that does not perform a UDP checksum calculation to verify
at the transport endpoints. 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 1. Transported potocols that enable the use of zero UDP checksum
layer to ensure that corruption rates of delivered payloads or MUST only enable this for a specific port or port-range. This
encapsulated packets are not increased. A mechanism that needs to be enabled at the sending and receibing ednpoints for a
isolates the causes of corruption (e.g. identifying mis- UDP flow.
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) 2. An integrity mechanism is always RECOMMENDED at the transported
packets MAY rely on the inner packet integrity checks, provided protocol layer to ensure that corruption rates of the delivered
that the tunnel protocol will not significantly increase the payload is not increased (e.g. the inner-most packet of a UDP
rate of corruption of the inner IP packet. If a significantly tunnel). A mechanism that isolates the causes of corruption
increased corruption rate can occur, then the protocol MUST (e.g. identifying misdelivery, IPv6 header corruption, tunnel
provide an additional integrity verification mechanism. Early header corruption) is expected to also provide additional
detection is desirable to avoid wasting unnecessary computation/ information about the status of the tunnel (e.g. to suggest a
transmission capacity/storage for packets that will subsequently security attack).
be discarded.
4. A protocol that supports use of a zero UDP checksum MUST be 3. A transported protocol that encapsulates Internet Protocol (IPv4
designed so that corruption of the protocol header information or IPv6) packets MAY rely on the inner packet integrity checks,
does not result in accumulated state for the protocol. 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
tunnel protocol MUST provide an additional integrity
verification mechanism. Early detection is desirable to avoid
wasting unnecessary computation, transmission capacity or
storage for packets that will subsequently be discarded.
5. A UDP based protocol with an non-tunnel payload or that 4. A transported protocol that supports use of a zero UDP checksum,
encapsulate non-IP packets MUST have a CRC or other mechanism MUST be designed so that corruption of this information does not
for checking packet integrity, unless the non-IP packet is result in accumulated state for the protocol.
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 5. A transported protocol that encapsulates a payload that is not
the network path. The set of middleboxes on a path may vary an IP packet flow MUST verify a CRC or other mechanism to check
during the life of an association. Endpoints need to discover packet integrity, unless the payload is specifically designed
paths with middleboxes that drop packets with a zero UDP for transmission over lower layers that do not provide a packet
checksum. Therefore protocols SHOULD send keep-alive messages integrity guarantee.
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 6. A transported protocol with control feedback SHOULD be robust to
with a calculated RFC 2460 checksum are expected to be more changes in the network path, since the set of middleboxes on a
robust to changes in the network path. Therefore keep-alive path may vary during the life of an association. Senders
messages SHOULD include both UDP datagrams with a checksum and therefore need a method to discover paths with middleboxes that
datagrams with a zero UDP checksum. This will enable the remote drop packets with a zero UDP checksum. Therefore keep-alive
endpoint to distinguish between a path failure and dropping of messages SHOULD send datagrams with a zero UDP checksum. This
datagrams with a zero UDP checksum. 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 7. A middlebox implementation MUST allow forwarding of IPv6 UDP
datagram with both a zero and standard UDP checksum. datagram with both a zero and standard UDP checksum using the
same UDP port.
9. A middlebox MAY configure a restricted set of specific port 8. A middlebox MAY configure a restricted set of specific port
ranges that forward UDP datagrams with a zero UDP checksum. The ranges that forward UDP datagrams with a zero UDP checksum. The
middlebox MAY drop IPv6 datagrams with a zero UDP checksum that middlebox MAY drop IPv6 datagrams with a zero UDP checksum that
are outside a configured range. are outside a configured range.
10. When a middlebox forwards IPv6 UDP datagram flows containing 9. When a middlebox forwards an IPv6 UDP flow containg datagrams
datagrams with both zero and standard UDP checksum, the with both a zero and standard UDP checksum, the middlebox MUST
middlebox MUST NOT maintain separate state for the flow NOT maintain separate state for flows depending on the value of
depending on the value of the UDP checksum field. This their UDP checksum field. (This requirement is necessary to
requirement is necessary to enable a sender that always enable a sender that always calculates a checksum to communicate
calculates a checksum to communicate via a middlebox with a via a middlebox with a remote endpoint that uses a zero UDP
remote endpoint that uses a zero UDP checksum. checksum.)
10. Section 3.1.3 of RFC 5405 describes requirements for congestion
control for apllications using UDP.
6. Summary 6. Summary
This document examines the role of the UDP transport checksum when This document examines the role of the UDP transport checksum when
used with IPv6. It presents a summary of the trade-offs in used with IPv6. It presents a summary of the trade-offs in
evaluating the safety of updating RFC 2460 to permit an IPv6 endpoint 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 to use a zero UDP checksum field to indicate that no checksum is
present. present.
The use of UDP with a zero UDP checksum has merits for some The use of UDP with a zero UDP checksum has merits for some
applications, such as tunnel encapsulation, and is widely used in applications, such as tunnel encapsulation, and is widely used in
IPv4. However, there are different dangers for IPv6: There is an IPv4. However, there are different dangers for IPv6: There is an
increased risk of corruption and mis-delivery when using zero UDP increased risk of corruption and misdelivery when using zero UDP
checksum in IPv6 compared to IPv4, due to the lack of an IPv6 header checksum in IPv6 compared to using IPv4 due to the lack of an IPv6
checksum. Thus, applications need to re-evaluate the risks of header checksum. Thus, applications need to re-evaluate the risks of
enabling use of a zero UDP checksum and consider a solution that at enabling use of a zero UDP checksum and consider a solution that at
least provides the same delivery protection as for IPv4, for example least provides the same delivery protection as for IPv4, for example
by utilizing UDP-Lite, or by enabling the UDP checksum. The use of by utilizing UDP-Lite, or by enabling the UDP checksum. The use of
checksum off-loading may help alleviate the checksum processing cost checksum off-loading may help alleviate the checksum processing cost
and permit use of a checksum using method defined in RFC 2460. and permit use of a checksum using method defined in RFC 2460.
Tunnel applications using UDP for encapsulation can in many cases use Tunnel applications using UDP for encapsulation can in many cases use
a zero UDP checksum without significant impact on the corruption a zero UDP checksum without significant impact on the corruption
rate. A well-designed tunnel application should include consistency rate. A well-designed tunnel application should include consistency
checks to validate the header information encapsulated with a checks to validate the header information encapsulated with a
received packet. In most cases, tunnels encapsulating IP packets can received packet. In most cases, tunnels encapsulating IP packets can
rely on the inner packets' own integrity protection. When correctly rely on the integrity protection provided by the transported protocol
implemented, such a tunnel endpoint will not be negatively impacted (or tunneled inner packet). When correctly implemented, such an
by omission of the transport-layer checksum. Recursive tunneling and endpoint will not be negatively impacted by omission of the
fragmentation is a potential issue that can raise corruption rates transport-layer checksum. Recursive tunneling and fragmentation is a
significantly, and requires careful consideration. potential issue that can raise corruption rates significantly, and
requires careful consideration.
Other UDP applications at the intended destination node or another Other UDP applications at the intended destination node or another
node can be impacted if they are allowed to receive datagrams that node can be impacted if they are allowed to receive datagrams that
have a zero UDP checksum. It is important that already deployed have a zero UDP checksum. It is important that already deployed
applications are not impacted by a change at the transport layer. If applications are not impacted by a change at the transport layer. If
these applications execute on nodes that implement RFC 2460, they these applications execute on nodes that implement RFC 2460, they
will discard (and log) all datagrams with a zero UDP checksum. This will discard (and log) all datagrams with a zero UDP checksum. This
is not an issue. is not an issue.
In general, UDP-based applications need to employ a mechanism that In general, UDP-based applications need to employ a mechanism that
allows a large percentage of the corrupted packets to be removed allows a large percentage of the corrupted packets to be removed
before they reach an application, both to protect the data stream of before they reach an application, both to protect the data stream of
the application and the control plane of higher layer protocols. the application and the control plane of higher layer protocols.
These checks are currently performed by the UDP checksum for IPv6, or These checks are currently performed by the UDP checksum for IPv6, or
the reduced checksum for UDP-Lite when used with IPv6. the reduced checksum for UDP-Lite when used with IPv6.
Recursive tunneling and fragmentation is a difficult issue relating The transport of recursive tunneling and the use of fragmentation
to tunnels in general. There is an increased risk of an error in the pose difficult issues that need to be considered in the design of
inner-most packet when fragmentation results from several layers of tunnel protocols. There is an increased risk of an error in the
tunneling and several different reassembly processes are run without inner-most packet when fragmentation when several layers of tunneling
verification of correctness. This issue requires extra thought and and several different reassembly processes are run without
careful consideration. verification of correctness. This requires extra thought and careful
consideration in the design of transported tunnels.
The use of the updated method must consider the implications on The use of the updated method must consider the implications on
firewalls, NATs and other middleboxes. It is not expected that IPv6 firewalls, NATs and other middleboxes. It is not expected that IPv6
NATs handle IPv6 UDP datagrams in the same way that they handle IPv4 NATs handle IPv6 UDP datagrams in the same way that they handle IPv4
UDP datagrams. This possibly reduces the need to update the UDP datagrams. This possibly reduces the need to update the
checksum. Firewalls are intended to be configured, and therefore may checksum. Firewalls are intended to be configured, and therefore may
need to be explicitly updated to allow new services or protocols. need to be explicitly updated to allow new services or protocols.
IPv6 middlebox deployment is not yet as prolific as it is in IPv4, IPv6 middlebox deployment is not yet as prolific as it is in IPv4,
and therefore new devices are expected to follow the methods and therefore new devices are expected to follow the methods
specified in this document. specified in this document.
Each application should consider the implications of choosing an IPv6 Each application should consider the implications of choosing an IPv6
transport that uses a zero UDP checksum, and consider whether other transport that uses a zero UDP checksum, and consider whether other
standard methods may be more appropriate, and may simplify standard methods may be more appropriate, and may simplify
application design. application design.
7. Acknowledgements 7. Acknowledgements
Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert, Brian Haberman, Brian Carpenter, Margaret Wasserman, Lars Eggert,
others in the TSV directorate. others in the TSV directorate. Barry Leiba, Ronald Bonica and
Stewart Bryant are thanked for resulting in a document with much
greater applicability. Thanks to P.F. Chimento for careful review
and editorial corrections.
Thanks also to: Remi Denis-Courmont, Pekka Savola, Glen Turner, and Thanks also to: Remi Denis-Courmont, Pekka Savola, Glen Turner, and
many others who contributed comments and ideas via the 6man, behave, many others who contributed comments and ideas via the 6man, behave,
lisp and mboned lists. 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 8. IANA Considerations
This document does not require any actions by IANA. This document does not require any actions by IANA.
9. Security Considerations 9. Security Considerations
Transport checksums provide the first stage of protection for the Transport checksums provide the first stage of protection for the
stack, although they can not be considered authentication mechanisms. stack, although they can not be considered authentication mechanisms.
These checks are also desirable to ensure packet counters correctly These checks are also desirable to ensure packet counters correctly
log actual activity, and can be used to detect unusual behaviours. log actual activity, and can be used to detect unusual behaviours.
skipping to change at page 26, line 28 skipping to change at page 26, line 28
mode) could reveal additional information to an on-path attacker to mode) could reveal additional information to an on-path attacker to
identify the type of tunnel being used. identify the type of tunnel being used.
IP-in-IP or GRE tunnels offer good traversal of middleboxes that have IP-in-IP or GRE tunnels offer good traversal of middleboxes that have
not been designed for security, e.g. firewalls. However, firewalls not been designed for security, e.g. firewalls. However, firewalls
may be expected to be configured to block general tunnels as they may be expected to be configured to block general tunnels as they
present a large attack surface. This applicability statement present a large attack surface. This applicability statement
therefore permits this method to be enabled only for specific ranges therefore permits this method to be enabled only for specific ranges
of ports. of ports.
When enabled, nodes and middleboxes must forward received UDP
datagrams that have either a calculated checksum or a zero checksum.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-6man-udpchecksums] [I-D.ietf-6man-udpchecksums]
Eubanks, M., Chimento, P., and M. Westerlund, "UDP Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
Checksums for Tunneled Packets", UDP Checksums for Tunneled Packets",
draft-ietf-6man-udpchecksums-05 (work in progress), draft-ietf-6man-udpchecksums-07 (work in progress),
October 2012. January 2013.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
10.2. Informative References 10.2. Informative References
[I-D.ietf-intarea-tunnels] [I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "Tunnels in the Internet Touch, J. and M. Townsley, "Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-00 (work in Architecture", draft-ietf-intarea-tunnels-00 (work in
progress), March 2010. 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] [I-D.ietf-mboned-auto-multicast]
Bumgardner, G., "Automatic Multicast Tunneling", Bumgardner, G., "Automatic Multicast Tunneling",
draft-ietf-mboned-auto-multicast-14 (work in progress), draft-ietf-mboned-auto-multicast-14 (work in progress),
June 2012. June 2012.
[LISP] D. Farinacci et al, "Locator/ID Separation Protocol
(LISP)", November 2012.
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071, "Computing the Internet checksum", RFC 1071,
September 1988. September 1988.
[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the
Internet checksum", RFC 1141, January 1990. Internet checksum", RFC 1141, January 1990.
[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via
Incremental Update", RFC 1624, May 1994. Incremental Update", RFC 1624, May 1994.
skipping to change at page 29, line 7 skipping to change at page 29, line 4
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
does require fields to be collected across the header, and does require fields to be collected across the header, and
arithmetic operations on each packet. The method would only work arithmetic operations on each packet. The method would only work
for packets that contain a 2's complement transport checksum (i.e. for packets that contain a 2's complement transport checksum
it would not be appropriate for SCTP or when IP fragmentation is (i.e., it would not be appropriate for SCTP or when IP
used). fragmentation is used).
o UDP-Lite with the checksum coverage set to only the header portion o UDP-Lite with the checksum coverage set to only the header portion
of a packet. This requires a pseudo header checksum calculation of a packet. This requires a pseudo header checksum calculation
only on the encapsulating packet header. The computed checksum only on the encapsulating packet header. The computed checksum
value may be cached (before adding the Length field) for each value may be cached (before adding the Length field) for each
flow/destination and subsequently combined with the Length of each flow/destination and subsequently combined with the Length of each
packet to minimise per-packet processing. This value is combined packet to minimise per-packet processing. This value is combined
with the UDP payload length for the pseudo header, however this with the UDP payload length for the pseudo header, however this
length is expected to be known when performing packet forwarding. length is expected to be known when performing packet forwarding.
o The proposed UDP Tunnel Transport, UDPTT [UDPTT] suggested a o The proposed UDP Tunnel Transport [UDPTT] suggested a method where
method where UDP would be modified to derive the checksum only UDP would be modified to derive the checksum only from the
from the encapsulating packet protocol header. This value does encapsulating packet protocol header. This value does not change
not change between packets in a single flow. The value may be between packets in a single flow. The value may be cached per
cached per flow/destination to minimise per-packet processing. flow/destination to minimise per-packet processing.
o There has been a proposal to simply ignore the UDP checksum value o There has been a proposal to simply ignore the UDP checksum value
on reception at the tunnel egress, allowing a tunnel ingress to on reception at the tunnel egress, allowing a tunnel ingress to
insert any value correct or false. For tunnel usage, a non insert any value correct or false. For tunnel usage, a non
standard checksum value may be used, forcing an RFC 2460 receiver standard checksum value may be used, forcing an RFC 2460 receiver
to drop the packet. The main downside is that it would be to drop the packet. The main downside is that it would be
impossible to identify a UDP datagram (in the network or an impossible to identify a UDP datagram (in the network or an
endpoint) that is treated in this way compared to a packet that endpoint) that is treated in this way compared to a packet that
has actually been corrupted. has actually been corrupted.
skipping to change at page 30, line 36 skipping to change at page 30, line 31
A.2.1. Middlebox Traversal A.2.1. Middlebox Traversal
Regular UDP with a standard checksum or the delta encoded Regular UDP with a standard checksum or the delta encoded
optimization for creating correct checksums have the best optimization for creating correct checksums 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 would also have been
middlebox with this behaviour. However, a middlebox on the path that able to traverse a middlebox with this behaviour. However, a
attempts to verify a standard checksum will not forward packets using middlebox on the path that attempts to verify a standard checksum
either of these methods, preventing traversal. A method that ignores will not forward packets using either of these methods, preventing
the checksum has an additional downside in that it prevents traversal. A method that ignores the checksum has an additional
improvement of middlebox traversal, because there is no way to downside in that it prevents improvement of middlebox traversal,
identify UDP datagrams that use the modified checksum behaviour. because there is no way to 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.
skipping to change at page 31, line 23 skipping to change at page 31, line 19
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.
A.2.2. Load Balancing A.2.2. Load Balancing
The usefulness of solutions for load balancers depends on the The usefulness of solutions for load balancers depends on the
difference in entropy in the headers for different flows that can be difference in entropy in the headers for different flows that can be
included in a hash function. All the proposals that use the UDP included in a hash function. All the proposals that use the UDP
protocol number have equal behavior. UDP-Lite has the potential for protocol number have equal behavior. UDP-Lite has the potential for
equally good behavior as for UDP. However, UDP-Lite is currently equally good behavior as for UDP. However, UDP-Lite is currently
unlikely to be supported by deployed hashing mechanisms, which may unlikely to be supported by deployed hashing mechanisms, which could
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.
A.2.3. Ingress and Egress Performance Implications A.2.3. Ingress and Egress Performance Implications
IP-in-IP tunnels are often considered efficient, because they IP-in-IP tunnels are often considered efficient, because they
skipping to change at page 32, line 26 skipping to change at page 32, line 20
does not modify the protocol on the wire and only needs changes in does not modify the protocol on the wire and only needs changes in
tunnel ingress. tunnel ingress.
o IP-in-IP tunnels should not require changes to the end-points, but o IP-in-IP tunnels should not require changes to the end-points, but
raise issues when traversing firewalls and other security-type raise issues when traversing firewalls and other security-type
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 tunnel 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
the zero UDP checksum method with or without an extension header the zero UDP checksum method with or without an extension header
require support at both end-points and in middleboxes. UDP-Lite, require support at both end-points and in middleboxes. UDP-Lite,
UDPTT, and the zero UDP checksum method and use of extension UDPTT, and the zero UDP checksum method and use of extension
headers may additionally require changes or additions to the headers may additionally require changes or additions to the
tunneling control protocol to negotiate support and path tunnel control protocol to negotiate support and path validation.
validation.
A.2.5. Corruption Detection Strength A.2.5. Corruption Detection Strength
The standard UDP checksum and the delta checksum can both provide The standard UDP checksum and the delta checksum can both provide
some verification at the tunnel egress. This can significantly some verification at the tunnel egress. This can significantly
reduce the probability that a corrupted inner packet is forwarded. reduce the probability that a corrupted inner packet is forwarded.
UDP-Lite, UDPTT and the extension header all provide some UDP-Lite, UDPTT and the extension header all provide some
verification against corruption, but do not verify the inner packet. verification against corruption, but 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
skipping to change at page 36, line 45 skipping to change at page 36, line 39
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).
Working Group Draft 07 Working Group Draft 07
* Interim Version * Interim Version
* Resubmission after IESG Feedback * Submission after IESG Feedback
* Updates to enable the document to become a PS Applicability * Updates to enable the document to become a PS Applicability
Statement Statement
Working Group Draft 08 Working Group Draft 08
* First Version written as a PS Applicability Statement * Submission for second WGLC as an Applicability Statement
* Changes to reflect decision to update RFC 2460, rather than * Submission after second WGLC
recommend decision
* Updates to requirements for middleboxes * Clarified role of API for supporting full checksum.
* Inclusion of requirements for security, API, and tunnel * Clarified that full checksum is required in security
considerations, and therefore noting that full checksum should
not be treated as an attack - consistent with remainder of
document.
* Move of the rationale for the update to an Annex (former * Added mention that API can set a mode in transport stack - to
section 4) link to similar statement in RFC 2460 update.
* Fixed typos.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
Scotland, UK Scotland, UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry URI: http://www.erg.abdn.ac.uk/users/gorry
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
Stockholm SE-164 80 Stockholm, SE-164 80
Sweden Sweden
Phone: +46 8 719 0000 Phone: +46 8 719 0000
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
 End of changes. 72 change blocks. 
222 lines changed or deleted 230 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/