draft-ietf-6man-udpzero-06.txt   draft-ietf-6man-udpzero-07.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: Informational M. Westerlund Intended status: Standards Track M. Westerlund
Expires: December 20, 2012 Ericsson Expires: April 25, 2013 Ericsson
June 20, 2012 October 22, 2012
IPv6 UDP Checksum Considerations Applicability Statement for the use of IPv6 UDP Datagrams with Zero
draft-ietf-6man-udpzero-06 Checksums
draft-ietf-6man-udpzero-07
Abstract Abstract
This document examines the role of the UDP transport checksum when This document provides an applicability statement for the use of UDP
used with IPv6, as defined in RFC2460. It presents a summary of the transport checksums when used with IPv6. This defines
trade-offs for evaluating the safety of updating RFC 2460 to permit recommendations and requirements for use of IPv6 UDP datagrams with a
an IPv6 UDP endpoint to use a zero value in the checksum field as an zero checksum. It examines the role of the IPv6 UDP transport
checksum, as defined in RFC2460 and presents a summary of the trade-
offs for evaluating the safety of updating RFC 2460 to permit an IPv6
UDP endpoint to use a zero value in the checksum field as an
indication that no checksum is present. This method is compared with indication that no checksum is present. This method is compared with
some other possibilities. The document also describes the issues and some other possibilities. The document also describes the issues and
design principles that need to be considered when UDP is used with design principles that need to be considered when UDP is used with
IPv6 to support tunnel encapsulations. It concludes that UDP with a IPv6 to support tunnel encapsulations.
zero checksum in IPv6 can safely be used for this purpose, provided
that this usage is governed by a set of constraints. XXX NOTE - This revision is a partial response to comments received
during IESG review. There are additional comments to be incorporated
- and updates anticipated to the related PS that updates IPv6. This
is therefore an interim version. XXX
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 20, 2012. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 3 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 4
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. The Role of a Transport Endpoint . . . . . . . . . . . 4 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 5
1.2.2. The UDP Checksum . . . . . . . . . . . . . . . . . . . 4
1.2.3. Differences between IPv6 and IPv4 . . . . . . . . . . 6
1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Motivation for new approaches . . . . . . . . . . . . 6 1.3.1. Motivation for new approaches . . . . . . . . . . . . 6
1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 7 1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 6
1.3.3. Need to inspect the entire packet . . . . . . . . . . 8 1.3.3. Need to inspect the entire packet . . . . . . . . . . 7
1.3.4. Interactions with middleboxes . . . . . . . . . . . . 8 1.3.4. Interactions with middleboxes . . . . . . . . . . . . 7
1.3.5. Support for load balancing . . . . . . . . . . . . . . 8 1.3.5. Support for load balancing . . . . . . . . . . . . . . 8
2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 8
2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 9 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 8
2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 10 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 9
2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 10 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 9
3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 11 3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 10
3.1. Effect of packet modification in the network . . . . . . . 11 3.1. Effect of packet modification in the network . . . . . . . 11
3.1.1. Corruption of the destination IP address . . . . . . . 12 3.1.1. Corruption of the destination IP address . . . . . . . 12
3.1.2. Corruption of the source IP address . . . . . . . . . 13 3.1.2. Corruption of the source IP address . . . . . . . . . 12
3.1.3. Corruption of Port Information . . . . . . . . . . . . 14 3.1.3. Corruption of Port Information . . . . . . . . . . . . 13
3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 14 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 13
3.1.5. Corruption of Fragmentation Information . . . . . . . 15 3.1.5. Corruption of Fragmentation Information . . . . . . . 15
3.2. Validating the network path . . . . . . . . . . . . . . . 17 3.2. Validating the network path . . . . . . . . . . . . . . . 17
3.3. Applicability of method . . . . . . . . . . . . . . . . . 18 3.3. Applicability of method . . . . . . . . . . . . . . . . . 17
3.4. Impact on non-supporting devices or applications . . . . . 19 3.4. Impact on non-supporting devices or applications . . . . . 18
4. Evaluation of proposal to update RFC 2460 to support zero 4. Evaluation of proposal to update RFC 2460 to support zero
checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Alternatives to the Standard Checksum . . . . . . . . . . 19 4.1. Alternatives to the Standard Checksum . . . . . . . . . . 19
4.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 21 4.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 20
4.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 22 4.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 21
4.2.3. Ingress and Egress Performance Implications . . . . . 22 4.2.3. Ingress and Egress Performance Implications . . . . . 21
4.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 22 4.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 22
4.2.5. Corruption Detection Strength . . . . . . . . . . . . 23 4.2.5. Corruption Detection Strength . . . . . . . . . . . . 22
4.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 23 4.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 23
5. Requirements on the specification of transported protocols . . 25 5. Constraints on implementation of IPv6 nodes supporting
5.1. Constraints required on usage of a zero checksum . . . . . 25 zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Requirements on the specification of transported protocols . . 25
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
Appendix A. Document Change History . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Document Change History . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
The User Datagram Protocol (UDP) [RFC0768] transport is defined for The User Datagram Protocol (UDP) [RFC0768] transport is defined for
the Internet Protocol (IPv4) [RFC0791] and is defined in Internet the Internet Protocol (IPv4) [RFC0791] and is defined in Internet
Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The
UDP transport protocol has a minimal set of features. This limited UDP transport protocol has a minimal set of features. This limited
set has enabled a wide range of applications to use UDP, but these set has enabled a wide range of applications to use UDP, but these
application do need to provide many important transport functions on application do need to provide many important transport functions on
top of UDP. The UDP Usage Guidelines [RFC5405] provides overall top of UDP. The UDP Usage Guidelines [RFC5405] provides overall
guidance for application designers, including the use of UDP to guidance for application designers, including the use of UDP to
support tunneling. The key difference between UDP usage with IPv4 support tunneling. The key difference between UDP usage with IPv4
and IPv6 is that IPv6 mandates use of the UDP checksum, i.e. a non- and IPv6 is that IPv6 mandates use of the UDP checksum, i.e. a non-
zero value, due to the lack of an IPv6 header checksum. zero value, due to the lack of an IPv6 header checksum.
The lack of a possibility to use UDP with a zero-checksum in IPv6 has The lack of a possibility to use UDP with a zero-checksum in IPv6 has
been observed as a real problem for certain classes of application, been observed as a real problem for certain classes of application,
primarily tunnel applications. This class of application has been primarily tunnel applications. This class of application has been
deployed with a zero checksum using IPv4. The design of IPv6 raises deployed with a zero checksum using IPv4. The design of IPv6 raises
different issues when considering the safety of using a zero checksum different issues when considering the safety of using a zero checksum
for UDP with IPv6. These issues can significantly affect for UDP with IPv6. These issues can significantly affect
applications, both when an endpoint is the intended user and when an applications, both when an endpoint is the intended user and when an
innocent bystander (received by a different endpoint to that innocent bystander (received by a different endpoint to that
intended). The document examines these issues and compares the intended). The document examines these issues and compares the
strengths and weaknesses of a number of proposed solutions. This strengths and weaknesses of a number of proposed solutions. This
analysis presents a set of issues that must be considered and analysis presents a set of issues that must be considered and
mitigated to be able to safely deploy UDP with a zero checksum over mitigated to be able to safely deploy UDP with a zero checksum over
IPv6. The provided comparison of methods is expected to also be IPv6. The provided comparison of methods is expected to also be
useful when considering applications that have different goals from useful when considering applications that have different goals from
the ones that initiated the writing of this document, especially the the ones that initiated the writing of this document, especially the
use of already standardized methods. use of already standardized methods.
The analysis concludes that using UDP with a zero checksum is the The analysis concludes that using UDP with a zero checksum is the
best method of the proposed alternatives to meet the goals for best method of the proposed alternatives to meet the goals for
certain tunnel applications. Unfortunately, this usage is expected certain tunnel applications. Unfortunately, this usage is expected
to have some deployment issues related to middleboxes, limiting the to have some deployment issues related to middleboxes, limiting the
usability more than desired in the currently deployed internet. usability more than desired in the currently deployed internet.
However, this limitation will be largest initially and will reduce as However, this limitation will be largest initially and will reduce as
updates for support of UDP zero checksum for IPv6 are provided to updates for support of UDP zero checksum for IPv6 are provided to
middleboxes. The document therefore derives a set of constraints middleboxes. The document therefore derives a set of constraints
required to ensure safe deployment of zero checksum in UDP. It also required to ensure safe deployment of zero checksum in UDP. It also
identifies some issues that require future consideration and possibly identifies some issues that require future consideration and possibly
additional research. additional research.
1.1. Document Structure 1.1. Document Structure
Section 1 provides a background to key issues, and introduces the use Section 1 provides a background to key issues, and introduces the use
of UDP as a tunnel transport protocol. of UDP as a tunnel transport protocol.
Section 2 describes a set of standards-track datagram transport Section 2 describes a set of standards-track datagram transport
protocols that may be used to support tunnels. protocols that may be used to support tunnels.
Section 3 discusses issues with a zero checksum in UDP for IPv6. It Section 3 discusses issues with a zero checksum in UDP for IPv6. It
considers the impact of corruption, the need for validation of the considers the impact of corruption, the need for validation of the
path and when it is suitable to use a zero checksum. path and when it is suitable to use a zero checksum.
Section 4 evaluates a set of proposals to update the UDP transport Section 4 evaluates a 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 focuses on a proposal to allow a zero checksum tunnel protocols. It focuses on a proposal to allow a zero checksum
for this use-case with IPv6 and assesses the trade-offs that would for this use-case with IPv6 and assesses the trade-offs that would
arise. arise.
Section 5.1 lists the constraints perceived for safe deployment of Section 5 is an applicability statement that defines requirements and
zero-checksum. recommendations on the implementation of IPv6 nodes that support the
use of a UDP zero value in the checksum of a UDP datagram.
Section 6 provides the recommendations for standardization of zero- Section 6 provides an applicability statement that identifies
requirements and recommendations for protocols and tunnel
encapsulations that are transported over an IPv6 transport connection
that does not perform a UDP checksum calculation to verify the
integrity at the transport endpoints.
Section 7 provides the recommendations for standardization of zero-
checksum with a summary of the findings and notes remaining issues checksum with a summary of the findings and notes remaining issues
needing future work. needing future work.
1.2. Background 1.2. Terminology
This section provides a background on topics relevant to the
following discussion.
1.2.1. The Role of a Transport Endpoint
An Internet transport endpoint should concern itself with the
following issues:
o Protection of the endpoint transport state from unnecessary extra
state (e.g. Invalid state from rogue packets).
o Protection of the endpoint transport state from corruption of
internal state.
o Pre-filtering by the endpoint of erroneous data, to protect the
transport from unnecessary processing and from corruption that it
can not itself reject.
o Pre-filtering of incorrectly addressed destination packets, before
responding to a source address.
1.2.2. The UDP Checksum
UDP, as defined in [RFC0768], supports two checksum behaviours when
used with IPv4. The normal behaviour is for the sender to calculate a
checksum over a block of data that includes a pseudo header and the
UDP datagram payload. The UDP header includes a 16-bit one's
complement checksum that provides a statistical guarantee that the
payload was not corrupted in transit. This also allows a receiver to
verify that the endpoint was the intended destination of the
datagram, because the transport pseudo header covers the IP
addresses, port numbers, transport payload length, and Next Header/
Protocol value corresponding to the UDP transport protocol [RFC1071].
The length field verifies that the datagram is not truncated or
padded. The checksum therefore protects an application against
receiving corrupted payload data in place of, or in addition to, the
data that were sent. Although the IPv4 UDP [RFC0768] checksum may be
disabled, applications are recommended to enable UDP checksums
[RFC5405].
The network-layer fields that are validated by a transport checksum
are:
o Endpoint IP source address (always included in the pseudo header
of the checksum)
o Endpoint IP destination address (always included in the pseudo
header of the checksum)
o Upper layer payload type (always included in the pseudo header of
the checksum)
o IP length of payload (always included in the pseudo header of the
checksum)
o Length of the network layer extension headers (i.e. by correct
position of the checksum bytes)
The transport-layer fields that are validated by a transport checksum
are:
o Transport demultiplexing, i.e. ports (always included in the
checksum)
o Transport payload size (always included in the checksum)
Transport endpoints also need to verify the correctness of reassembly
of any fragmented datagram. For UDP, this is normally provided as a
part of the integrity check. Disabling the IPv4 checksum prevents
this check. A lack of the UDP header and checksum in fragments can
lead to issues in a translator or middlebox. For example, many IPv4
Network Address Translators, NATs, rely on port numbers to find the
mappings, packet fragments do not carry port numbers, so fragments
get dropped. IP/ICMP Translation Algorithm [RFC6145] provides some
guidance on the processing of fragmented IPv4 UDP datagrams that do
not carry a UDP checksum.
IPv4 UDP checksum control is often a kernel-wide configuration
control (e.g. In Linux and BSD), rather than a per socket call.
There are also Networking Interface Cards (NICs) that automatically
calculate TCP [RFC0793] and UDP checksums on transmission when a
checksum of zero is sent to the NIC, using a method known as checksum
offloading.
1.2.3. Differences between IPv6 and IPv4
IPv6 does not provide a network-layer integrity check. The removal
of the header checksum from the IPv6 specification released routers
from a need to update a network-layer checksum for each router hop as
the IPv6 Hop Count is changed (in contrast to the checksum update
needed when an IPv4 router modifies the Time-To-Live (TTL)).
The IP header checksum calculation was seen as redundant for most The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
traffic (with UDP or TCP checksums enabled), and people wanted to "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
avoid this extra processing. However, there was concern that the document are to be interpreted as described in [RFC2119].
removal of the IP header checksum in IPv6 combined with a UDP
checksum set to zero would lessen the protection of the source/
destination IP addresses and result in a significant (a multiplier of
~32,000) increase in the number of times that a UDP packet was
accidentally delivered to the wrong destination address and/or
apparently sourced from the wrong source address. This would have
had implications on the detectability of mis-delivery of a packet to
an incorrect endpoint/socket, and the robustness of the Internet
infrastructure. The use of the UDP checksum is therefore required
[RFC2460] when endpoint applications transmit UDP datagrams over
IPv6.
1.3. Use of UDP Tunnels 1.3. Use of UDP Tunnels
One increasingly popular use of UDP is as a tunneling protocol, where One increasingly popular use of UDP is as a tunneling protocol, where
a tunnel endpoint encapsulates the packets of another protocol inside a tunnel endpoint encapsulates the packets of another protocol inside
UDP datagrams and transmits them to another tunnel endpoint. Using UDP datagrams and transmits them to another tunnel endpoint. Using
UDP as a tunneling protocol is attractive when the payload protocol UDP as a tunneling protocol is attractive when the payload protocol
is not supported by the middleboxes that may exist along the path, is not supported by the middleboxes that may exist along the path,
because many middleboxes support transmission using UDP. In this use, because many middleboxes support transmission using UDP. In this
the receiving endpoint decapsulates the UDP datagrams and forwards use, the receiving endpoint decapsulates the UDP datagrams and
the original packets contained in the payload [RFC5405]. Tunnels forwards the original packets contained in the payload [RFC5405].
establish virtual links that appear to directly connect locations Tunnels establish virtual links that appear to directly connect
that are distant in the physical Internet topology and can be used to locations that are distant in the physical Internet topology and can
create virtual (private) networks. be used to create virtual (private) networks.
1.3.1. Motivation for new approaches 1.3.1. Motivation for new approaches
A number of tunnel encapsulations deployed over IPv4 have used the A number of tunnel encapsulations deployed over IPv4 have used the
UDP transport with a zero checksum. Users of these protocols expect UDP transport with a zero checksum. Users of these protocols expect
a similar solution for IPv6. a similar solution for IPv6.
A number of tunnel protocols are also currently being defined (e.g. A number of tunnel protocols are also currently being defined (e.g.
Automated Multicast Tunnels, AMT [I-D.ietf-mboned-auto-multicast], Automated Multicast Tunnels, AMT [I-D.ietf-mboned-auto-multicast],
and the Locator/Identifier Separation Protocol, LISP [LISP]). These and the Locator/Identifier Separation Protocol, LISP [LISP]). These
protocols have proposed an update to IPv6 UDP checksum processing. protocols have proposed an update to IPv6 UDP checksum processing.
These tunnel protocols could benefit from simpler checksum processing These tunnel protocols could benefit from simpler checksum processing
for various reasons: for 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).
skipping to change at page 7, line 32 skipping to change at page 6, line 38
Address Translators, NATs. Address Translators, NATs.
o A desire to use the port number space to enable load-sharing. o A desire to use the port number space to enable load-sharing.
1.3.2. Reducing forwarding cost 1.3.2. Reducing forwarding cost
It is a common requirement to terminate a large number of tunnels on It is a common requirement to terminate a large number of tunnels on
a single router/host. Processing per tunnel concerns both state a single router/host. Processing per tunnel concerns both state
(memory requirements) and per-packet processing costs. (memory requirements) and per-packet processing costs.
Automatic IP Multicast Tunneling, known as AMT [I-D.ietf-mboned-auto- Automatic IP Multicast Tunneling, known as AMT
multicast] currently specifies UDP as the transport protocol for [I-D.ietf-mboned-auto-multicast] currently specifies UDP as the
packets carrying tunneled IP multicast packets. The current transport protocol for packets carrying tunneled IP multicast
specification for AMT requires that the UDP checksum in the outer packets. The current specification for AMT requires that the UDP
packet header should be 0 (see Section 6.6 of [I-D.ietf-mboned-auto- checksum in the outer packet header should be 0 (see Section 6.6 of
multicast]). It argues that the computation of an additional [I-D.ietf-mboned-auto-multicast]). It argues that the computation of
checksum, when an inner packet is already adequately protected, is an an additional checksum, when an inner packet is already adequately
unwarranted burden on nodes implementing lightweight tunneling protected, is an unwarranted burden on nodes implementing lightweight
protocols. The AMT protocol needs to replicate a multicast packet to tunneling protocols. The AMT protocol needs to replicate a multicast
each gateway tunnel. In this case, the outer IP addresses are packet to each gateway tunnel. In this case, the outer IP addresses
different for each tunnel and therefore require a different pseudo are different for each tunnel and therefore require a different
header to be built for each UDP replicated encapsulation. pseudo header to be built for each UDP replicated encapsulation.
The argument concerning redundant processing costs is valid regarding The argument concerning redundant processing costs is valid regarding
the integrity of a tunneled packet. In some architectures (e.g. PC- the integrity of a tunneled packet. In some architectures (e.g. PC-
based routers), other mechanisms may also significantly reduce based routers), other mechanisms may also significantly reduce
checksum processing costs: There are implementations that have checksum processing costs: There are implementations that have
optimised checksum processing algorithms, including the use of optimised checksum processing algorithms, including the use of
checksum-offloading. This processing is readily available for IPv4 checksum-offloading. This processing is readily available for IPv4
packets at high line rates. Such processing may be anticipated for packets at high line rates. Such processing may be anticipated for
IPv6 endpoints, allowing receivers to reject corrupted packets IPv6 endpoints, allowing receivers to reject corrupted packets
without further processing. However, there are certain classes of without further processing. However, there are certain classes of
tunnel end-points where this off-loading is not available and tunnel end-points where this off-loading is not available and
unlikely to become available in the near future. unlikely to become available in the near future.
1.3.3. Need to inspect the entire packet 1.3.3. Need to inspect the entire packet
The currently-deployed hardware in many routers uses a fast-path The currently-deployed hardware in many routers uses a fast-path
processing that only provides the first n bytes of a packet to the processing that only provides the first n bytes of a packet to the
forwarding engine, where typically n <= 128. This prevents fast forwarding engine, where typically n <= 128. This prevents fast
processing of a transport checksum over an entire (large) packet. processing of a transport checksum over an entire (large) packet.
Hence the currently defined IPv6 UDP checksum is poorly suited to use Hence the currently defined IPv6 UDP checksum is poorly suited to use
within a router that is unable to access the entire packet and does within a router that is unable to access the entire packet and does
not provide checksum-offloading. Thus enabling checksum calculation not provide checksum-offloading. Thus enabling checksum calculation
over the complete packet can impact router design, performance over the complete packet can impact router design, performance
improvement, energy consumption and/or cost. improvement, energy consumption and/or cost.
1.3.4. Interactions with middleboxes 1.3.4. Interactions with middleboxes
In IPv4, UDP-encapsulation may be desirable for NAT traversal, since In IPv4, UDP-encapsulation may be desirable for NAT traversal, since
UDP support is commonly provided. It is also necessary due to the UDP support is commonly provided. It is also necessary due to the
almost ubiquitous deployment of IPv4 NATs. There has also been almost ubiquitous deployment of IPv4 NATs. There has also been
discussion of NAT for IPv6, although not for the same reason as in discussion of NAT for IPv6, although not for the same reason as in
IPv4. If IPv6 NAT becomes a reality they hopefully do not present the IPv4. If IPv6 NAT becomes a reality they hopefully do not present
same protocol issues as for IPv4. If NAT is defined for IPv6, it the same protocol issues as for IPv4. If NAT is defined for IPv6, it
should take UDP zero checksum into consideration. should take UDP zero checksum into consideration.
The requirements for IPv6 firewall traversal are likely be to be The requirements for IPv6 firewall traversal are likely be to be
similar to those for IPv4. In addition, it can be reasonably expected similar to those for IPv4. In addition, it can be reasonably
that a firewall conforming to RFC 2460 will not regard UDP datagrams expected that a firewall conforming to RFC 2460 will not regard UDP
with a zero checksum as valid packets. If a zero-checksum for UDP datagrams with a zero checksum as valid packets. If a zero-checksum
were to be allowed for IPv6, this would need firewalls to be updated for UDP were to be allowed for IPv6, this would need firewalls to be
before full utility of the change is available. updated before full utility of the change is available.
It can be expected that UDP with zero-checksum will initially not It can be expected that UDP with zero-checksum will initially not
have the same middlebox traversal characteristics as regular UDP. have the same middlebox traversal characteristics as regular UDP.
However, if standardized we can expect an improvement over time of However, if standardized we can expect an improvement over time of
the traversal capabilities. We also note that deployment of the traversal capabilities. We also note that deployment of IPv6-
IPv6-capable middleboxes is still in its initial phases. Thus, it capable middleboxes is still in its initial phases. Thus, it might
might be that the number of non-updated boxes quickly become a very be that the number of non-updated boxes quickly become a very small
small percentage of the deployed middleboxes. percentage of the deployed middleboxes.
1.3.5. Support for load balancing 1.3.5. Support for load balancing
The UDP port number fields have been used as a basis to design load- The UDP port number fields have been used as a basis to design load-
balancing solutions for IPv4. This approach has also been leveraged balancing solutions for IPv4. This approach has also been leveraged
for IPv6. An alternate method would be to utilise the IPv6 Flow Label for IPv6. An alternate method would be to utilise the IPv6 Flow
as basis for entropy for the load balancing. This would have the Label as basis for entropy for the load balancing. This would have
desirable effect of releasing IPv6 load-balancing devices from the the desirable effect of releasing IPv6 load-balancing devices from
need to assume semantics for the use of the transport port field and the need to assume semantics for the use of the transport port field
also works for all type of transport protocols. This use of the and also works for all type of transport protocols. This use of the
flow-label is consistent with the intended use, although further flow-label is consistent with the intended use, although further
clarity may be needed to ensure the field can be consistently used clarity may be needed to ensure the field can be consistently used
for this purpose, (e.g. Equal-Cost Multi-Path routing, ECMP [ECMP]). for this purpose, (e.g. Equal-Cost Multi-Path routing, ECMP [ECMP]).
Router vendors could be encouraged to start using the IPv6 Flow Label Router vendors could be encouraged to start using the IPv6 Flow Label
as a part of the flow hash, providing support for ECMP without as a part of the flow hash, providing support for ECMP without
requiring use of UDP. However, the method for populating the outer requiring use of UDP. However, the method for populating the outer
IPv6 header with a value for the flow label is not trivial: If the IPv6 header with a value for the flow label is not trivial: If the
inner packet uses IPv6, then the flow label value could be copied to inner packet uses IPv6, then the flow label value could be copied to
the outer packet header. However, many current end-points set the the outer packet header. However, many current end-points set the
flow label to a zero value (thus no entropy). The ingress of a tunnel flow label to a zero value (thus no entropy). The ingress of a
seeking to provide good entropy in the flow label field would tunnel seeking to provide good entropy in the flow label field would
therefore need to create a random flow label value and keep therefore need to create a random flow label value and keep
corresponding state, so that all packets that were associated with a corresponding state, so that all packets that were associated with a
flow would be consistently given the same flow label. Although flow would be consistently given the same flow label. Although
possible, this complexity may not be desirable in a tunnel ingress. possible, this complexity may not be desirable in a tunnel ingress.
The end-to-end use of flow labels for load balancing is a long-term The end-to-end use of flow labels for load balancing is a long-term
solution. Even if the usage of the flow label is clarified, there solution. Even if the usage of the flow label is clarified, there
would be a transition time before a significant proportion of end- would be a transition time before a significant proportion of end-
points start to assign a good quality flow label to the flows that points start to assign a good quality flow label to the flows that
they originate, with continued use of load balancing using the they originate, with continued use of load balancing using the
transport header fields until any widespread deployment is finally transport header fields until any widespread deployment is finally
achieved. achieved.
2. Standards-Track Transports 2. Standards-Track Transports
The IETF has defined a set of transport protocols that may be The IETF has defined a set of transport protocols that may be
applicable for tunnels with IPv6. There are also a set of network applicable for tunnels with IPv6. There are also a set of network
layer encapsulation tunnels such as IP-in-IP and GRE. These already layer encapsulation tunnels such as IP-in-IP and GRE. These already
standardized solutions are discussed here prior to the issues, as standardized solutions are discussed here prior to the issues, as
background for the issue description and some comparison of where the background for the issue description and some comparison of where the
issue may already occur. issue may already occur.
2.1. UDP with Standard Checksum 2.1. UDP with Standard Checksum
UDP [RFC0768] with standard checksum behaviour, as defined in RFC UDP [RFC0768] with standard checksum behaviour, as defined in RFC
2460, has already been discussed. UDP usage guidelines are provided 2460, has already been discussed. UDP usage guidelines are provided
in [RFC5405]. in [RFC5405].
2.2. UDP-Lite 2.2. UDP-Lite
UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as
a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and
unicast usage guidelines in [RFC5405]. There is at least one open unicast usage guidelines in [RFC5405]. There is at least one open
source implementation as a part of the Linux kernel since version source implementation as a part of the Linux kernel since version
2.6.20. 2.6.20.
UDP-Lite provides a checksum with optional partial coverage. When UDP-Lite provides a checksum with optional partial coverage. When
using this option, a datagram is divided into a sensitive part using this option, a datagram is divided into a sensitive part
(covered by the checksum) and an insensitive part (not covered by the (covered by the checksum) and an insensitive part (not covered by the
checksum). When the checksum covers the entire packet, UDP-Lite is checksum). When the checksum covers the entire packet, UDP-Lite is
fully equivalent with UDP. Errors/corruption in the insensitive part fully equivalent with UDP. Errors/corruption in the insensitive part
will not cause the datagram to be discarded by the transport layer at will not cause the datagram to be discarded by the transport layer at
the receiving endpoint. A minor side-effect of using UDP-Lite is the receiving endpoint. A minor side-effect of using UDP-Lite is
that this was specified for damage-tolerant payloads, and some link- that this was specified for damage-tolerant payloads, and some link-
layers may employ different link encapsulations when forwarding UDP- layers may employ different link encapsulations when forwarding UDP-
Lite segments (e.g. radio access bearers). Most link-layers will Lite segments (e.g. radio access bearers). Most link-layers will
cover the insensitive part with the same strong layer 2 frame CRC cover the insensitive part with the same strong layer 2 frame CRC
that covers the sensitive part. that covers the sensitive part.
2.2.1. Using UDP-Lite as a Tunnel Encapsulation 2.2.1. Using UDP-Lite as a Tunnel Encapsulation
Tunnel encapsulations can use UDP-Lite (e.g. Control And Tunnel encapsulations can use UDP-Lite (e.g. Control And
Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP- Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP-
Lite provides a transport-layer checksum, including an IP pseudo Lite provides a transport-layer checksum, including an IP pseudo
header checksum, in IPv6, without the need for a router/middelbox to header checksum, in IPv6, without the need for a router/middelbox to
traverse the entire packet payload. This provides most of the traverse the entire packet payload. This provides most of the
skipping to change at page 10, line 42 skipping to change at page 9, line 51
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
The IETF has defined a set of tunneling protocols or network layer The IETF has defined a set of tunneling protocols or network layer
encapsulations, e.g., IP-in-IP and GRE. These either do not include a encapsulations, e.g., IP-in-IP and GRE. These either do not include
checksum or use a checksum that is optional, since tunnel a checksum or use a checksum that is optional, since tunnel
encapsulations are typically layered directly over the Internet layer encapsulations are typically layered directly over the Internet layer
(identified by the upper layer type in the IPv6 Next Header field) (identified by the upper layer type in the IPv6 Next Header field)
and are also not used as endpoint transport protocols. There is and are also not used as endpoint transport protocols. There is
little chance of confusing a tunnel-encapsulated packet with other little chance of confusing a tunnel-encapsulated packet with other
application data that could result in corruption of application state application data that could result in corruption of application state
or data. or data.
From the end-to-end perspective, the principal difference is that the From the end-to-end perspective, the principal difference is that the
network-layer Next Header field identifies a separate transport, network-layer Next Header field identifies a separate transport,
which reduces the probability that corruption could result in the which reduces the probability that corruption could result in the
packet being delivered to the wrong endpoint or application. packet being delivered to the wrong endpoint or application.
Specifically, packets are only delivered to protocol modules that Specifically, packets are only delivered to protocol modules that
process a specific next header value. The next header field process a specific next header value. The next header field
therefore provides a first-level check of correct demultiplexing. In therefore provides a first-level check of correct demultiplexing. In
contrast, the UDP port space is shared by many diverse applications contrast, the UDP port space is shared by many diverse applications
and therefore UDP demultiplexing relies solely on the port numbers. and therefore UDP demultiplexing relies solely on the port numbers.
3. Issues Requiring Consideration 3. Issues Requiring Consideration
This section evaluates issues around the proposal to update IPv6 This informative section evaluates issues around the proposal to
[RFC2460], to provide the option of using a UDP transport checksum update IPv6 [RFC2460], to provide the option of using a UDP transport
set to zero. Some of the identified issues are shared with other checksum set to zero. Some of the identified issues are shared with
protocols already in use. other protocols already in use.
The decision by IPv6 to omit an integrity check at the network level The decision by IPv6 to omit an integrity check at the network level
has meant that the transport check was overloaded with many has meant that the transport check was overloaded with many
functions, including validating: functions, including validating:
o the endpoint address was not corrupted within a router, i.e., a o the endpoint address was not corrupted within a router, i.e., a
packet was intended to be received by this destination and packet was intended to be received by this destination and
validate that the packet does not consist of a wrong header validate that the packet does not consist of a wrong header
spliced to a different payload; spliced to a different payload;
skipping to change at page 12, line 4 skipping to change at page 11, line 18
checksum. checksum.
In IPv6, these checks occur within the endpoint stack using the UDP In IPv6, these checks occur within the endpoint stack using the UDP
checksum information. An IPv6 node also relies on the header checksum information. An IPv6 node also relies on the header
information to determine whether to send an ICMPv6 error message information to determine whether to send an ICMPv6 error message
[RFC4443] and to determine the node to which this is sent. Corrupted [RFC4443] and to determine the node to which this is sent. Corrupted
information may lead to misdelivery to an unintended application information may lead to 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 mis-delivered 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;
skipping to change at page 12, line 40 skipping to change at page 12, line 7
When a checksum is used, this significantly reduces the impact of When a checksum is used, this significantly reduces the impact of
errors, reducing the probability of undetected corruption of state errors, reducing the probability of undetected corruption of state
(and data) on both the host stack and the applications using the (and data) on both the host stack and the applications using the
transport service. transport service.
The following sections examine the impact of modifying each of these The following sections examine the impact of modifying each of these
header fields. header fields.
3.1.1. Corruption of the destination IP address 3.1.1. Corruption of the destination IP address
An IP endpoint destination address could be modified in the network An IPv6 endpoint destination address could be modified in the network
(e.g. corrupted by an error). This is not a concern for IPv4, (e.g. corrupted by an error). This is not a concern for IPv4,
because the IP header checksum will result in this packet being because the IP header checksum will result in this packet being
discarded by the receiving IP stack. Such modification in the discarded by the receiving IP stack. Such modification in the
network can not be detected at the network layer when using IPv6. network can not be detected at the network layer when using IPv6.
There are two possible outcomes: There are two possible outcomes:
o Delivery to a destination address that is not in use (the packet o Delivery to a destination address that is not in use (the packet
will not be delivered, but could result in an error report); will not be delivered, but could result in an error report);
o Delivery to a different destination address. This modification o Delivery to a different destination address. This modification
will normally be detected by the transport checksum, resulting in will normally be detected by the transport checksum, resulting in
silent discard. Without this checksum, the packet would be passed silent discard. Without a computed checksum, the packet would be
to the endpoint port demultiplexing function. If an application passed to the endpoint port demultiplexing function. If an
is bound to the associated ports, the packet payload will be application is bound to the associated ports, the packet payload
passed to the application (see the subsequent section on port will be passed to the application (see the subsequent section on
processing). port processing).
3.1.2. Corruption of the source IP address 3.1.2. Corruption of the source IP address
This section examines what happens when the source address is This section examines what happens when the source address is
corrupted in transit. This is not a concern in IPv4, because the IP corrupted in transit. This is not a concern in IPv4, because the IP
header checksum will normally result in this packet being discarded header checksum will normally result in this packet being discarded
by the receiving IP stack. by the receiving IP stack.
Corruption of an IPv6 source address does not result in the IP packet Corruption of an IPv6 source address does not result in the IP packet
being delivered to a different endpoint protocol or destination being delivered to a different endpoint protocol or destination
address. If only the source address is corrupted, the datagram will address. If only the source address is corrupted, the datagram will
likely be processed in the intended context, although with erroneous likely be processed in the intended context, although with erroneous
origin information. The result will depend on the application or origin information. When using Unicast Reverse Path Forwarding
protocol that processes the packet. Some examples are: [RFC2827], a change in address may result in the router discarding
the packet when the route to the modified source address is different
to that of the source address of the original packet.
The result will depend on the application or protocol that processes
the packet. Some examples are:
o An application that requires a per-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
skipping to change at page 14, line 41 skipping to change at page 13, line 49
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,
but could generate an ICMPv6 message (e.g. port unreachable). but could generate an ICMPv6 message (e.g. port unreachable).
o It could be delivered to a different node that implements the same o It could be delivered to a different node that implements the same
application, where the packet may be accepted, generating side- application, where the packet may be accepted, generating side-
effects or accumulated state. effects or accumulated state.
o It could be delivered to an application that does not implement o It could be delivered to an application that does not implement
the tunnel protocol, where the packet may be incorrectly parsed, the tunnel protocol, where the packet may be incorrectly parsed,
and may be misinterpreted, generating side-effects or accumulated and may be misinterpreted, generating side-effects or accumulated
state. state.
The probability of each outcome depends on the statistical The probability of each outcome depends on the statistical
probability that the address or the port information for the source probability that the address or the port information for the source
or destination becomes corrupt in the datagram such that they match or destination becomes corrupt in the datagram such that they match
those of an existing flow or server port. Unfortunately, such a those of an existing flow or server port. Unfortunately, such a
match may be more likely for UDP than for connection-oriented match may be more likely for UDP than for connection-oriented
transports, because: transports, because:
1. There is no handshake prior to communication and no sequence 1. There is no handshake prior to communication and no sequence
numbers (as in TCP, DCCP, or SCTP). Together, this makes it hard numbers (as in TCP, DCCP, or SCTP). Together, this makes it hard
to verify that an application is given only the data associated to verify that an application is given only the data associated
with a transport session. with a transport session.
2. Applications writers often bind to wild-card values in endpoint 2. Applications writers often bind to wild-card values in endpoint
identifiers and do not always validate correctness of datagrams identifiers and do not always validate correctness of datagrams
they receive (guidance on this topic is provided in [RFC5405]). they receive (guidance on this topic is provided in [RFC5405]).
While these rules could, in principle, be revised to declare naive While these rules could, in principle, be revised to declare naive
applications as "Historic". This remedy is not realistic: the applications as "Historic". This remedy is not realistic: the
transport owes it to the stack to do its best to reject bogus transport owes it to the stack to do its best to reject bogus
skipping to change at page 15, line 46 skipping to change at page 15, line 13
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:
Reassembly failure: An error in the "More Fragments" field for the Reassembly failure: An error in the "More Fragments" field for the
last fragment will for example result in the packet never being last fragment will for example result in the packet never being
considered complete and will eventually be timed out and considered complete and will eventually be timed out and
discarded. A corruption in the ID field will result in the discarded. A corruption in the ID field will result in the
fragment not being delivered to the intended context thus leaving fragment not being delivered to the intended context thus leaving
the rest incomplete, unless that packet has been duplicated prior the rest incomplete, unless that packet has been duplicated prior
to corruption. The incomplete packet will eventually be timed out to corruption. The incomplete packet will eventually be timed out
and discarded. and discarded.
Erroneous reassembly: The re-assemblied packet did not match the Erroneous reassembly: The re-assemblied packet did not match the
original packet. This can occur when the ID field of a fragment original packet. This can occur when the ID field of a fragment
is corrupted, resulting in a fragment becoming associated with is corrupted, resulting in a fragment becoming associated with
another packet and taking the place of another fragment. another packet and taking the place of another fragment.
Corruption in the offset information can cause the fragment to be Corruption in the offset information can cause the fragment to be
misaligned in the reassembly buffer, resulting in incorrect misaligned in the reassembly buffer, resulting in incorrect
reassembly. Corruption can cause the packet to become shorter or reassembly. Corruption can cause the packet to become shorter or
longer, however completion of reassembly is much less probable, longer, however completion of reassembly is much less probable,
since this would requires consistent corruption of the IPv6 since this would requires consistent corruption of the IPv6
headers payload length field and the offset field. The headers payload length field and the offset field. The
possibility of mis-assembly requires the reassembling stack to possibility of mis-assembly requires the reassembling stack to
skipping to change at page 16, line 29 skipping to change at page 15, line 44
however that this is not guaranteed and has recently been however that this is not guaranteed and has recently been
clarified in "Handling of Overlapping IPv6 Fragments" [RFC5722]. clarified in "Handling of Overlapping IPv6 Fragments" [RFC5722].
The erroneous reassembly of packets is a general concern and such The erroneous reassembly of packets is a general concern and such
packets should be discarded instead of being passed to higher layer packets should be discarded instead of being passed to higher layer
processes. The primary detector of packet length changes is the IP processes. The primary detector of packet length changes is the IP
payload length field, with a secondary check by the transport payload length field, with a secondary check by the transport
checksum. The Upper-Layer Packet length field included in the pseudo checksum. The Upper-Layer Packet length field included in the pseudo
header assists in verifying correct reassembly, since the Internet header assists in verifying correct reassembly, since the Internet
checksum has a low probability of detecting insertion of data or checksum has a low probability of detecting insertion of data or
overlap errors (due to misplacement of data). The checksum is also overlap errors (due to misplacement of data). The checksum is also
incapable of detecting insertion or removal of all zero-data that incapable of detecting insertion or removal of all zero-data that
occurs in a multiple of a 16-bit chunk. occurs in a multiple of a 16-bit chunk.
The most significant risk of corruption results following mis- The most significant risk of corruption results following mis-
association of a fragment with a different packet. This risk can be association of a fragment with a different packet. This risk can be
significant, since the size of fragments is often the same (e.g. significant, since the size of fragments is often the same (e.g.
fragments resulting when the path MTU results in fragmentation of a fragments resulting when the path MTU results in fragmentation of a
larger packet, common when addition of a tunnel encapsulation header larger packet, common when addition of a tunnel encapsulation header
expands the size of a packet). Detection of this type of error expands the size of a packet). Detection of this type of error
requires a checksum or other integrity check of the headers and the requires a checksum or other integrity check of the headers and the
payload. Such protection is anyway desirable for tunnel payload. Such protection is anyway desirable for tunnel
encapsulations using IPv4, since the small fragmentation ID can encapsulations using IPv4, since the small fragmentation ID can
easily result in wrap-around [RFC4963], this is especially the case easily result in wrap-around [RFC4963], this is especially the case
for tunnels that perform flow aggregation [I-D.ietf-intarea-tunnels]. for tunnels that perform flow aggregation [I-D.ietf-intarea-tunnels].
Tunnel fragmentation behavior matters. There can be outer or inner Tunnel fragmentation behavior matters. There can be outer or inner
fragmentation "Tunnels in the Internet Architecture" [I-D.ietf- fragmentation "Tunnels in the Internet Architecture"
intarea-tunnels]. If there is inner fragmentation by the tunnel, the [I-D.ietf-intarea-tunnels]. If there is inner fragmentation by the
outer headers will never be fragmented and thus a zero-checksum in tunnel, the outer headers will never be fragmented and thus a zero-
the outer header will not affect the reassembly process. When a checksum in the outer header will not affect the reassembly process.
tunnel performs outer header fragmentation, the tunnel egress needs When a tunnel performs outer header fragmentation, the tunnel egress
to perform reassembly of the outer fragments into an inner packet. needs to perform reassembly of the outer fragments into an inner
The inner packet is either a complete packet or a fragment. If it is packet. The inner packet is either a complete packet or a fragment.
a fragment, the destination endpoint of the fragment will perform If it is a fragment, the destination endpoint of the fragment will
reassembly of the received fragments. The complete packet or the perform reassembly of the received fragments. The complete packet or
reassembled fragments will then be processed according to the packet the reassembled fragments will then be processed according to the
next header field. The receiver may only detect reassembly anomalies packet next header field. The receiver may only detect reassembly
when it uses a protocol with a checksum. The larger the number of anomalies when it uses a protocol with a checksum. The larger the
reassembly processes to which a packet has been subjected, the number of reassembly processes to which a packet has been subjected,
greater the probability of an error. the greater the probability of an error.
o An IP-in-IP tunnel that performs inner fragmentation has similar o An IP-in-IP tunnel that performs inner fragmentation has similar
properties to a UDP tunnel with a zero-checksum that also performs properties to a UDP tunnel with a zero-checksum that also performs
inner fragmentation. inner fragmentation.
o An IP-in-IP tunnel that performs outer fragmentation has similar o An IP-in-IP tunnel that performs outer fragmentation has similar
properties to a UDP tunnel with a zero checksum that performs properties to a UDP tunnel with a zero checksum that performs
outer fragmentation. outer fragmentation.
o A tunnel that performs outer fragmentation can result in a higher o A tunnel that performs outer fragmentation can result in a higher
skipping to change at page 18, line 7 skipping to change at page 17, line 18
IP transports designed for use in the general Internet should not IP transports designed for use in the general Internet should not
assume specific path characteristics. Network protocols may reroute assume specific path characteristics. Network protocols may reroute
packets that change the set of routers and middleboxes along a path. packets that change the set of routers and middleboxes along a path.
Therefore transports such as TCP, SCTP and DCCP have been designed to Therefore transports such as TCP, SCTP and DCCP have been designed to
negotiate protocol parameters, adapt to different network path negotiate protocol parameters, adapt to different network path
characteristics, and receive feedback to verify that the current path characteristics, and receive feedback to verify that the current path
is suited to the intended application. Applications using UDP and is suited to the intended application. Applications using UDP and
UDP-Lite need to provide their own mechanisms to confirm the validity UDP-Lite need to provide their own mechanisms to confirm the validity
of the current network path. of the current network path.
The zero-checksum in UDP is explicitly disallowed in RFC2460. Thus it The zero-checksum in UDP is explicitly disallowed in RFC2460. Thus
may be expected that any device on the path that has a reason to look it may be expected that any device on the path that has a reason to
beyond the IP header will consider such a packet as erroneous or look beyond the IP header will consider such a packet as erroneous or
illegal and may likely discard it, unless the device is updated to illegal and may likely discard it, unless the device is updated to
support a new behavior. A pair of end-points intending to use a new support a new behavior. A pair of end-points intending to use a new
behavior will therefore not only need to ensure support at each end- behavior will therefore not only need to ensure support at each end-
point, but also that the path between them will deliver packets with point, but also that the path between them will deliver packets with
the new behavior. This may require negotiation or an explicit the new behavior. This may require negotiation or an explicit
mandate to use the new behavior by all nodes intended to use a new mandate to use the new behavior by all nodes intended to use a new
protocol. protocol.
Support along the path between end points may be guaranteed in Support along the path between end points may be guaranteed in
limited deployments by appropriate configuration. In general, it can limited deployments by appropriate configuration. In general, it can
be expected to take time for deployment of any updated behaviour to be expected to take time for deployment of any updated behaviour to
become ubiquitous. A sender will need to probe the path to verify become ubiquitous. A sender will need to probe the path to verify
the expected behavior. Path characteristics may change, and usage the expected behavior. Path characteristics may change, and usage
therefore should be robust and able to detect a failure of the path therefore should be robust and able to detect a failure of the path
under normal usage and re-negotiate. This will require periodic under normal usage and re-negotiate. This will require periodic
validation of the path, adding complexity to any solution using the validation of the path, adding complexity to any solution using the
new behavior. new behavior.
3.3. Applicability of method 3.3. Applicability of method
The expectation of the present proposal defined in [I-D.ietf-6man- The expectation of the present proposal defined in
udpchecksums] is that this change would only apply to IPv6 router [I-D.ietf-6man-udpchecksums] is that this change would only apply to
nodes that implement specific protocols that permit omission of UDP IPv6 router nodes that implement specific protocols that permit
checksums. However, the distinction between a router and a host is omission of UDP checksums. However, the distinction between a router
not always clear, especially at the transport level. Systems (such and a host is not always clear, especially at the transport level.
as unix-based operating systems) routinely provide both functions. Systems (such as unix-based operating systems) routinely provide both
There is also no way to identify the role of a receiver from a functions. There is also no way to identify the role of a receiver
received packet. from a received packet.
Any new method would therefore need a specific applicability Any new method would therefore need a specific applicability
statement indicating when the mechanism can (and can not) be used. statement indicating when the mechanism can (and can not) be used.
Enabling this, and ensuring correct interactions with the stack, Enabling this, and ensuring correct interactions with the stack,
implies much more than simply disabling the checksum algorithm for implies much more than simply disabling the checksum algorithm for
specific packets at the transport interface. specific packets at the transport interface.
The IETF should carefully consider constraints on sanctioning the use The IETF should carefully consider constraints on sanctioning the use
of any new transport mode. If this is specified and widely of any new transport mode. If this is specified and widely
available, it may be expected to be used by applications that are available, it may be expected to be used by applications that are
perceived to gain benefit. Any solution that uses an end-to-end perceived to gain benefit. Any solution that uses an end-to-end
transport protocol, rather than an IP-in-IP encapsulation, needs to transport protocol, rather than an IP-in-IP encapsulation, needs to
minimise the possibility that end-hosts could confuse a corrupted or minimise the possibility that end-hosts could confuse a corrupted or
skipping to change at page 19, line 38 skipping to change at page 18, line 48
this case, applications using other ports would maintain the current this case, applications using other ports would maintain the current
IPv6 behavior, discarding incoming UDP datagrams with a zero- IPv6 behavior, discarding incoming UDP datagrams with a zero-
checksum. These other applications would not be effected by this checksum. These other applications would not be effected by this
changed behavior. An application that allows the changed behavior changed behavior. An application that allows the changed behavior
should be aware of the risk for corruption and the increased level of should be aware of the risk for corruption and the increased level of
misdirected traffic, and can be designed robustly to handle this misdirected traffic, and can be designed robustly to handle this
risk. risk.
4. Evaluation of proposal to update RFC 2460 to support zero checksum 4. Evaluation of proposal to update RFC 2460 to support zero checksum
This section evaluates the proposal to update IPv6 [RFC2460], to This informative section evaluates the proposal to update IPv6
provide the option that some nodes may suppress generation and [RFC2460], to provide the option that some nodes may suppress
checking of the UDP transport checksum. It also compares the generation and checking of the UDP transport checksum. It also
proposal with other alternatives. compares the proposal with other alternatives.
4.1. Alternatives to the Standard Checksum 4.1. Alternatives to the Standard Checksum
There are several alternatives to the normal method for calculating There are several alternatives to the normal method for calculating
the UDP Checksum that do not require a tunnel endpoint to inspect the the UDP Checksum [RFC1071]that do not require a tunnel endpoint to
entire packet when computing a checksum. These include (in inspect the entire packet when computing a checksum. These include
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 (i.e.
it would not be appropriate for SCTP or when IP fragmentation is it would not be appropriate for SCTP or when IP fragmentation is
used). 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 flow value may be cached (before adding the Length field) for each
/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 [UDPTT] suggested a
method where UDP would be modified to derive the checksum only method where UDP would be modified to derive the checksum only
from the encapsulating packet protocol header. This value does from the encapsulating packet protocol header. This value does
not change between packets in a single flow. The value may be not change between packets in a single flow. The value may be
cached per flow/destination to minimise per-packet processing. cached per 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 packet (in the network or an impossible to identify a UDP datagram (in the network or an
endpoint) that is treated in this way compared to a packet that endpoint) that is treated in this way compared to a packet that
has actually been corrupted. has actually been corrupted.
o A method has been proposed that uses a new (to be defined) IPv6 o A method has been proposed that uses a new (to be defined) IPv6
Destination Options Header to provide an end-to-end validation Destination Options Header to provide an end-to-end validation
check at the network layer. This would allow an endpoint to check at the network layer. This would allow an endpoint to
verify delivery to an appropriate end point, but would also verify delivery to an appropriate end point, but would also
require IPv6 nodes to correctly handle the additional header, and require IPv6 nodes to correctly handle the additional header, and
would require changes to middlebox behavior (e.g. when used with would require changes to middlebox behavior (e.g. when used with a
a NAT that always adjusts the checksum value). NAT that always adjusts the checksum value).
o UDP modified to disable checksum processing [I-D.ietf-6man- o UDP modified to disable checksum processing
udpchecksums]. This requires no checksum calculation, but would [I-D.ietf-6man-udpchecksums]. This requires no checksum
require constraints on appropriate usage and updates to end-points calculation, but would require constraints on appropriate usage
and middleboxes. and updates to end-points and middleboxes.
o IP-in-IP tunneling. As this method completely dispenses with a o IP-in-IP tunneling. As this method completely dispenses with a
transport protocol in the outer-layer it has reduced overhead and transport protocol in the outer-layer it has reduced overhead and
complexity, but also reduced functionality. There is no outer complexity, but also reduced functionality. There is no outer
checksum over the packet and also no ports to perform checksum over the packet and also no ports to perform
demultiplexing between different tunnel types. This reduces the demultiplexing between different tunnel types. This reduces the
information available upon which a load balancer may act. information available upon which a load balancer may act.
These options are compared and discussed further in the following These options are compared and discussed further in the following
sections. sections.
skipping to change at page 21, line 32 skipping to change at page 20, line 40
Regular UDP with a standard checksum or the delta encoded Regular UDP with a standard checksum or the delta encoded
optimization for creating correct checksums have the best optimization for creating correct checksums have the best
possibilities for successful traversal of a middlebox. No new possibilities for successful traversal of a middlebox. No new
support is required. support is required.
A method that ignores the UDP checksum on reception is expected to A method that ignores the UDP checksum on reception is expected to
have a good probability of traversal, because most middleboxes have a good probability of traversal, because most middleboxes
perform an incremental checksum update. UDPTT may also traverse a perform an incremental checksum update. UDPTT may also traverse a
middlebox with this behaviour. However, a middlebox on the path that middlebox with this behaviour. However, a middlebox on the path that
attempts to verify a standard checksum will not forward packets using attempts to verify a standard checksum will not forward packets using
either of these methods, preventing traversal. The methods that either of these methods, preventing traversal. A method that ignores
ignores the checksum has an additional downside in that middlebox the checksum has an additional downside in that it prevents
traversal can not be improved, because there is no way to identify improvement of middlebox traversal, because there is no way to
which packets use the modified checksum behaviour. identify packets that use the modified checksum behaviour.
IP-in-IP or GRE tunnels offer good traversal of middleboxes that have IP-in-IP or GRE tunnels offer good traversal of middleboxes that have
not been designed for security, e.g. firewalls. However, firewalls not been designed for security, e.g. firewalls. However, firewalls
may be expected to be configured to block general tunnels as they may be expected to be configured to block general tunnels as they
present a large attack surface. present a large attack surface.
A new IPv6 Destination Options header will suffer traversal issues A new IPv6 Destination Options header will suffer traversal issues
with middleboxes, especially Firewalls and NATs, and will likely with middleboxes, especially Firewalls and NATs, and will likely
require them to be updated before the extension header is passed. require them to be updated before the extension header is passed.
Packets using UDP with a zero checksum will not be passed by any Packets using UDP with a zero checksum will not be passed by any
middlebox that validates the checksum using RFC 2460 or updates the middlebox that validates the checksum using RFC 2460 or updates the
checksum field, such as NAT or firewalls. This would require an checksum field, such as NAT or firewalls. This would require an
skipping to change at page 22, line 12 skipping to change at page 21, line 23
number. Once enabled, the method to support incremental checksum number. Once enabled, the method to support incremental checksum
update would be identical to that for UDP, but different for checksum update would be identical to that for UDP, but different for checksum
validation. validation.
4.2.2. Load Balancing 4.2.2. Load Balancing
The usefulness of solutions for load balancers depends on the The usefulness of solutions for load balancers depends on the
difference in entropy in the headers for different flows that can be difference in entropy in the headers for different flows that can be
included in a hash function. All the proposals that use the UDP included in a hash function. All the proposals that use the UDP
protocol number have equal behavior. UDP-Lite has the potential for protocol number have equal behavior. UDP-Lite has the potential for
equally good behavior as for UDP. However, UDP-Lite is currently equally good behavior as for UDP. However, UDP-Lite is currently
likely to not be supported by deployed hashing mechanisms, which may likely to not be supported by deployed hashing mechanisms, which may
cause a load balancer to not use the transport header in the computed cause a load balancer to not use the transport header in the computed
hash. A load balancer that only uses the IP header will have low hash. A load balancer that only uses the IP header will have low
entropy, but could be improved by including the IPv6 the flow label, entropy, but could be improved by including the IPv6 the flow label,
providing that the tunnel ingress ensures that different flow labels providing that the tunnel ingress ensures that different flow labels
are assigned to different flows. However, a transition to the common are assigned to different flows. However, a transition to the common
use of good quality flow labels is likely to take time to deploy. use of good quality flow labels is likely to take time to deploy.
4.2.3. Ingress and Egress Performance Implications 4.2.3. Ingress and Egress Performance Implications
skipping to change at page 22, line 46 skipping to change at page 22, line 11
checksum on reception, the Option Header, UDPTT and UDP-Lite will checksum on reception, the Option Header, UDPTT and UDP-Lite will
likely incur additional complexities in the application to likely incur additional complexities in the application to
incorporate a negotiation and validation mechanism. incorporate a negotiation and validation mechanism.
4.2.4. Deployability 4.2.4. Deployability
The major factors influencing deployability of these solutions are a The major factors influencing deployability of these solutions are a
need to update both end-points, a need for negotiation and the need need to update both end-points, a need for negotiation and the need
to update middleboxes. These are summarised below: to update middleboxes. These are summarised below:
o The solution with the best deployability is regular UDP. This o The solution with the best deployability is regular UDP. This
requires no changes and has good middlebox traversal requires no changes and has good middlebox traversal
characteristics. characteristics.
o The next easiest to deploy is the delta checksum solution. This o The next easiest to deploy is the delta checksum solution. This
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.
skipping to change at page 23, line 42 skipping to change at page 23, line 12
intended to be processed by a specific tunnel egress or that the intended to be processed by a specific tunnel egress or that the
inner packet was correct. inner packet was correct.
4.2.6. Comparison Summary 4.2.6. Comparison Summary
The comparisons above may be summarised as "there is no silver bullet The comparisons above may be summarised as "there is no silver bullet
that will slay all the issues". One has to select which down side(s) that will slay all the issues". One has to select which down side(s)
can best be lived with. Focusing on the existing solutions, this can can best be lived with. Focusing on the existing solutions, this can
be summarized as: be summarized as:
Regular UDP: Good middlebox traversal and load balancing and Regular UDP: Good middlebox traversal and load balancing and
multiplexing, requiring a checksum in the outer headers covering multiplexing, requiring a checksum in the outer headers covering
the whole packet. the whole packet.
IP in IP: A low complexity encapsulation, with limited middlebox IP in IP: A low complexity encapsulation, with limited middlebox
traversal, no multiplexing support, and currently poor load traversal, no multiplexing support, and currently poor load
balancing support that could improve over time. balancing support that could improve over time.
UDP-Lite: A medium complexity encapsulation, with good multiplexing UDP-Lite: A medium complexity encapsulation, with good multiplexing
support, limited middlebox traversal, but possible to improve over support, limited middlebox traversal, but possible to improve over
time, currently poor load balancing support that could improve time, currently poor load balancing support that could improve
over time, in most cases requiring application level negotiation over time, in most cases requiring application level negotiation
and validation. and validation.
The delta-checksum is an optimization in the processing of UDP, as The delta-checksum is an optimization in the processing of UDP, as
such it exhibits some of the drawbacks of using regular UDP. such it exhibits some of the drawbacks of using regular UDP.
The remaining proposals may be described in similar terms: The remaining proposals may be described in similar terms:
Zero-Checksum: A low complexity encapsulation, with good multiplexing Zero-Checksum: A low complexity encapsulation, with good
support, limited middlebox traversal that could improve over time, multiplexing support, limited middlebox traversal that could
good load balancing support, in most cases requiring application improve over time, good load balancing support, in most cases
level negotiation and validation. requiring application level negotiation and validation.
UDPTT: A medium complexity encapsulation, with good multiplexing UDPTT: A medium complexity encapsulation, with good multiplexing
support, limited middlebox traversal, but possible to improve over support, limited middlebox traversal, but possible to improve over
time, good load balancing support, in most cases requiring time, good load balancing support, in most cases requiring
application level negotiation and validation. application level negotiation and validation.
IPv6 Destination Option IP in IP tunneling: A medium complexity, with IPv6 Destination Option IP in IP tunneling: A medium complexity,
no multiplexing support, limited middlebox traversal, currently with no multiplexing support, limited middlebox traversal,
poor load balancing support that could improve over time, in most currently poor load balancing support that could improve over
cases requiring application level negotiation and validation. time, in most cases requiring application level negotiation and
validation.
IPv6 Destination Option combined with UDP Zero-checksuming: A medium IPv6 Destination Option combined with UDP Zero-checksuming: A medium
complexity encapsulation, with good multiplexing support, limited complexity encapsulation, with good multiplexing support, limited
load balancing support that could improve over time, in most cases load balancing support that could improve over time, in most cases
requiring application level negotiation and validation. requiring application level negotiation and validation.
Ignore the checksum on reception: A low complexity encapsulation, Ignore the checksum on reception: A low complexity encapsulation,
with good multiplexing support, medium middlebox traversal that with good multiplexing support, medium middlebox traversal that
never can improve, good load balancing support, in most cases never can improve, good load balancing support, in most cases
requiring application level negotiation and validation. requiring application level negotiation and validation.
There is no clear single optimum solution. If the most important There is no clear single optimum solution. If the most important
need is to traverse middleboxes, then the best choice is to stay with need is to traverse middleboxes, then the best choice is to stay with
regular UDP and consider the optimizations that may be required to regular UDP and consider the optimizations that may be required to
perform the checksumming. If one can live with limited middlebox perform the checksumming. If one can live with limited middlebox
traversal, low complexity is necessary and one does not require load traversal, low complexity is necessary and one does not require load
balancing, then IP-in-IP tunneling is the simplest. If one wants balancing, then IP-in-IP tunneling is the simplest. If one wants
skipping to change at page 25, line 34 skipping to change at page 25, line 5
o Are there other avenues of change that will resolve the issue in a o Are there other avenues of change that will resolve the issue in a
better way and sufficiently quickly ? better way and sufficiently quickly ?
o Do we accept the complexity cost of having one more solution in o Do we accept the complexity cost of having one more solution in
the future? the future?
The authors do think the answer to the above questions are such that The authors do think the answer to the above questions are such that
zero-checksum should be standardized for use by tunnel zero-checksum should be standardized for use by tunnel
encapsulations. encapsulations.
5. Requirements on the specification of transported protocols 5. Constraints on implementation of IPv6 nodes supporting zero checksum
This section identifies requirements for the protocols that are This section is an applicability statement that defines requirements
transported over a transport connection that does not perform a UDP and recommendations on the implementation of IPv6 nodes that support
checksum calculation to verify the integrity at the transport the use of a UDP zero value in the checksum of a UDP datagram.
endpoints.
5.1. Constraints required on usage of a zero checksum 1. IPv6 nodes SHOULD by default NOT allow the zero checksum method
for transmission or reception.
If a zero checksum approach were to be adopted by the IETF, the 2. The default node receiver behaviour MUST discard all IPv6 packets
specification should consider adding the following constraints on carrying UDP datagrams with a zero checksum. IPv6 nodes MUST
usage: provide a way for the application/protocol to indicate the set of
ports that will be enabled to send UDP datagrams with a zero
checksum. This may be implemented via a socket API call, or
similar mechanism. It may also be implemented by enabling the
method for a pre-assigned static port used by a specific tunnel
protocol.
1. IPv6 protocol stack implementations should not by default allow 3. IPv6 nodes MUST provide a way for the application/protocol to
the new method. The default node receiver behaviour must discard indicate the set of ports that will be enabled to receive UDP
all IPv6 packets carrying UDP packets with a zero checksum. datagrams with a zero checksum.
2. Implementations must provide a way to signal the set of ports 4. RFC 2460 specifies that IPv6 nodes SHOULD log received UDP
that will be enabled to receive UDP datagrams with a zero datagrams with a zero-checksum. This should remain the case for
checksum. An IPv6 node that enables reception of UDP packets any datagram received on a port that does not explicitly enable
with a zero-checksum, must enable this only for a specific port zero-checksum processing. A port for which zero-checksum has
or port-range. This may be implemented via a socket API call, or been enabled MUST NOT log the datagram solely because the
similar mechanism. checksum is zero, but MAY log this to support other functions
(such as a security policy).
3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams with 5. IPv6 nodes MAY separately identify received UDP datagrams that
a zero-checksum. This should remain the case for any datagram are discarded with a zero checksum. It SHOULD NOT add these to
received on a port that does not explicitly enable zero-checksum the standard log, since the endpoint has not been verified.
processing. A port for which zero-checksum has been enabled must
not log the datagram.
4. A stack may separately identify UDP datagrams that are discarded 6. IPv6 nodes that receive ICMPv6 messages that refer to packets
with a zero checksum. It should not add these to the standard with a zero UDP checksum MUST provide appropriate checks
log, since the endpoint has not been verified. concerning the consistency of the reported packet to verify that
the reported packet actually originated from the node, before
acting upon the information (e.g. validating the address and port
numbers in the ICMPv6 message body).
5. Tunnels that encapsulate IP may rely on the inner packet 6. Requirements on the specification of transported protocols
This section is an applicability statement that identifies
requirements and recommendations for protocols and tunnel
encapsulations that are transported over an IPv6 transport connection
that does not perform a UDP checksum calculation to verify the
integrity at the transport endpoints.
1. UDP Tunnels that enable the use of zero checksum MUST only enable
this only for a specific port or port-range.
2. UDP Tunnels that encapsulate IP MAY rely on the inner packet
integrity checks provided that the tunnel will not significantly integrity checks provided that the tunnel will not significantly
increase the rate of corruption of the inner IP packet. If a increase the rate of corruption of the inner IP packet. If a
significantly increased corruption rate can occur, then the significantly increased corruption rate can occur, then the
tunnel must provide an additional integrity verification tunnel MUST provide an additional integrity verification
mechanism. An integrity mechanisms is always recommended at the mechanism. Early detection is desirable to avoid wasting
tunnel layer to ensure that corruption rates of the inner most unneccessary computation/storage for packets that will
packet are not increased. subsequently be discarded.
6. Tunnels that encapsulate Non-IP packets must have a CRC or other 3. An integrity mechanisms is always RECOMMENDED at the tunnel layer
mechanism for checking packet integrity, unless the Non-IP packet to ensure that corruption rates of the inner-most packet are not
specifically is designed for transmission over lower layers that increased. A mechanism that isolates the causes of corruption
do not provide any packet integrity guarantee. In particular, (e.g. identifying mis-delivery, IPv6 header corruption, tunnel
the application must be designed so that corruption of this header corruption) is expected to also provide additional
information does not result in accumulated state or incorrect information about the status of the tunnel (e.g. to suggest a
processing of a tunneled payload. security attack).
7. UDP applications that support use of a zero-checksum, should not 4. UDP Tunnels that encapsulate non-IP packets MUST have a CRC or
rely upon correct reception of the IP and UDP protocol other mechanism for checking packet integrity, unless the non-IP
information (including the length of the packet) when decoding packet specifically is designed for transmission over lower
and processing the packet payload. In particular, the layers that do not provide any packet integrity guarantee. In
application must be designed so that corruption of this particular, the tunnel endpoint MUST be designed so that
information does not result in accumulated state or incorrect corruption of this information does not result in accumulated
processing of a tunneled payload. state or incorrect processing of a tunneled payload.
8. If a method proposes recursive tunnels, it needs to provide 5. UDP Tunnels that support use of a zero-checksum, SHOULD NOT rely
guidance that is appropriate for all use-cases. Restrictions may upon correct reception of the IP and UDP protocol information
be needed to the use of a tunnel encapsulations and the use of (including the length of the packet) when decoding and processing
recursive tunnels (e.g. Necessary when the endpoint is not the packet payload. In particular, the application MUST be
verified). designed so that corruption of this information does not result
in accumulated state or incorrect processing of a tunneled
payload.
9. IPv6 nodes that receive ICMPv6 messages that refer to packets 6. A UDP Tunnel egress that supports a zero UDP checksum MUST also
with a zero UDP checksum must provide appropriate checks allow reception using a standard UDP checksum. The encapsulating
concerning the consistency of the reported packet to verify that endpoint may choose to compute the UDP checksum, or the sending
the reported packet actually originated from the node, before endpoint IPv6 stack may enable this by default. In either case,
acting upon the information (e.g. validating the address and the remote endpoint uses the reception method specified in
port numbers in the ICMPv6 message body). RFC2460.
Deployment of the new method needs to remain restricted to endpoints 7. UDP Tunnels with control feedback need to be robust to changes in
that explicitly enable this mode and adopt the above procedures. Any network path. The set of middleboxes on a path may vary during
middlebox that examines or interacts with the UDP header over IPv6 the life of an association. Endpoints need to discover paths
should support the new method. with middleboxes that drop packets with a zero UDP checksum.
Therefore keep-alive messages SHOULD include both UDP datagrams
with a checksum and UDP datagrams with a zero checksum. This
will enable the remote endpoint to distinguish between a path
failure and dropping of UDP datagrams with a zero checksum. Note
that path validation need only be performed for each pair of
tunnel endpoints, not for each tunnel context.
6. Summary 8. Middleboxes implementations MUST allow IPv6 packets forward both
a zero and standard UDP checksum. A middlebox MAY configure
specific port ranges that forward UDP datagrams with a zero UDP
checksum. These middleboxes MUST forward both standard and zero
checksum UDP datagrams within the configured range, but may drop
IPv6 UDP datagrams with a zero checksum that are outside the
configured ranges.
7. Summary
This document examines the role of the transport checksum when used This document examines the role of the transport checksum when used
with IPv6, as defined in RFC2460. with IPv6, as defined in RFC2460.
It presents a summary of the trade-offs for evaluating the safety of It presents a summary of the trade-offs for evaluating the safety of
updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value
in the checksum field to indicate that no checksum is present. A in the checksum field to indicate that no checksum is present. A
decision not to include a UDP checksum in received IPv6 datagrams decision not to include a UDP checksum in received IPv6 datagrams
could impact a tunnel application that receives these packets. could impact a tunnel application that receives these packets.
However, a well-designed tunnel application should include However, a well-designed tunnel application should include
consistency checks to validate any header information encapsulated consistency checks to validate any header information encapsulated
with a packet. In most cases tunnels encapsulating IP packets can with a packet. In most cases tunnels encapsulating IP packets can
rely on the inner packets own integrity protection. When correctly rely on the inner packets own integrity protection. When correctly
implemented, such a tunnel endpoint will not be negatively impacted implemented, such a tunnel endpoint will not be negatively impacted
by omission of the transport-layer checksum. Recursive tunneling and by omission of the transport-layer checksum. Recursive tunneling and
fragmentation is a potential issue that can raise corruption rates fragmentation is a potential issue that can raise corruption rates
significantly, and requires careful consideration. significantly, and requires careful consideration.
Other applications at the intended destination node or another IPv6 Other applications at the intended destination node or another IPv6
node can be impacted if they are allowed to receive datagrams without node can be impacted if they are allowed to receive datagrams that do
a transport-layer checksum. It is particularly important that not have a transport-layer checksum. It is particularly important
already deployed applications are not impacted by any change at the that already deployed applications are not impacted by any change at
transport layer. If these applications execute on nodes that the transport layer. If these applications execute on nodes that
implement RFC 2460, they will reject all datagrams with a zero UDP implement RFC 2460, they will reject all datagrams with a zero UDP
checksum, thus this is not an issue. For nodes that implement checksum, thus this is not an issue. For nodes that implement
support for zero-checksum it is important to ensure that only UDP support for zero-checksum it is important to ensure that only UDP
applications that desire zero-checksum can receive and originate applications that desire zero-checksum can receive and originate
zero-checksum packets. Thus, the enabling of zero-checksum needs to zero-checksum packets. Thus, the enabling of zero-checksum needs to
be at a port level, not for the entire host or for all use of an be at a port level, not for the entire host or for all use of an
interface. interface.
The implications on firewalls, NATs and other middleboxes need to be The implications on firewalls, NATs and other middleboxes need to be
considered. It is not expected that IPv6 NATs handle IPv6 UDP considered. It is not expected that IPv6 NATs handle IPv6 UDP
datagrams in the same way that they handle IPv4 UDP datagrams. This datagrams in the same way that they handle IPv4 UDP datagrams. This
possibly reduces the need to update the checksum. Firewalls are possibly reduces the need to update the checksum. Firewalls are
intended to be configured, and therefore may need to be explicitly intended to be configured, and therefore may need to be explicitly
updated to allow new services or protocols. IPv6 middlebox updated to allow new services or protocols. IPv6 middlebox
deployment is not yet as prolific as it is in IPv4. Thus, relatively deployment is not yet as prolific as it is in IPv4. Thus, relatively
few current middleboxes may actually block IPv6 UDP with a zero few current middleboxes may actually block IPv6 UDP with a zero
checksum. checksum.
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.
The use of UDP with no checksum has merits for some applications, The use of UDP with no checksum has merits for some applications,
such as tunnel encapsulation, and is widely used in IPv4. However, such as tunnel encapsulation, and is widely used in IPv4. However,
there are dangers for IPv6: There is a bigger risk of corruption and there are dangers for IPv6: There is a bigger risk of corruption and
miss-delivery when using zero-checksum in IPv6 compared to IPv4 due miss-delivery when using zero-checksum in IPv6 compared to IPv4 due
to the removed IP header checksum. Thus, applications need to make a to the removed IP header checksum. Thus, applications need to make a
new evaluation of the risks of enabling a zero-checksum. Some new evaluation of the risks of enabling a zero-checksum. Some
applications will need to re-consider their usage of zero-checksum, applications will need to re-consider their usage of zero-checksum,
and possibly consider a solution that at least provides the same and possibly consider a solution that at least provides the same
delivery protection as for IPv4, for example by utilizing UDP-Lite, delivery protection as for IPv4, for example by utilizing UDP-Lite,
or by enabling the UDP checksum. Tunnel applications using UDP for or by enabling the UDP checksum. Tunnel applications using UDP for
encapsulation can in many case use zero-checksum without significant encapsulation can in many case use zero-checksum without significant
impact on the corruption rate. In some cases, the use of checksum impact on the corruption rate. In some cases, the use of checksum
off-loading may help alleviate the checksum processing cost. off-loading may help alleviate the checksum processing cost.
Recursive tunneling and fragmentation is a difficult issue relating Recursive tunneling and fragmentation is a difficult issue relating
to tunnels in general. There is an increased risk of an error in the to tunnels in general. There is an increased risk of an error in the
inner-most packet when fragmentation when several layers of tunneling inner-most packet when fragmentation when several layers of tunneling
and several different reassembly processes are run without any and several different reassembly processes are run without
verification of correctness. This issue requires future thought and verification of correctness. This issue requires future thought and
consideration. consideration.
The conclusion is that UDP zero checksum in IPv6 should be The conclusion is that UDP zero checksum in IPv6 should be
standardized, as it satisfies usage requirements that are currently standardized, as it satisfies usage requirements that are currently
difficult to address. We do note that a safe deployment of zero- difficult to address. We do note that a safe deployment of zero-
checksum will need to follow a set of constraints listed in Section checksum will need to follow a set of constraints listed in
5.1. Section 5.
7. Acknowledgements 8. Acknowledgements
Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert, Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert,
others in the TSV directorate. others in the TSV directorate.
Thanks also to: Remi Denis-Courmont, Pekka Savola and many others who Thanks also to: Remi Denis-Courmont, Pekka Savola and many others who
contributed comments and ideas via the 6man, behave, lisp and mboned contributed comments and ideas via the 6man, behave, lisp and mboned
lists. lists.
8. IANA Considerations 9. IANA Considerations
This document does not require any actions by IANA. This document does not require any actions by IANA.
9. Security Considerations 10. 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.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [I-D.ietf-6man-udpchecksums]
1981. Eubanks, M., Chimento, P., and M. Westerlund, "UDP
Checksums for Tunneled Packets",
draft-ietf-6man-udpchecksums-04 (work in progress),
September 2012.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
793, September 1981. September 1981.
[RFC1071] Braden, R., Borman, D., Partridge, C. and W. Plummer, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
"Computing the Internet checksum", RFC 1071, September RFC 793, September 1981.
1988.
[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
6 (IPv6) Specification", RFC 2460, December 1998. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[ECMP] "Using the IPv6 flow label for equal cost multipath 11.2. Informative References
routing in tunnels (draft-carpenter-flow-ecmp)", .
[I-D.ietf-6man-udpchecksums] [ECMP] "Using the IPv6 flow label for equal cost multipath
Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled routing in tunnels (draft-carpenter-flow-ecmp)".
Packets", Internet-Draft draft-ietf-6man-udpchecksums-02,
March 2012.
[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", Internet-Draft draft-ietf-intarea- Architecture", draft-ietf-intarea-tunnels-00 (work in
tunnels-00, March 2010. progress), March 2010.
[I-D.ietf-mboned-auto-multicast] [I-D.ietf-mboned-auto-multicast]
Bumgardner, G., "Automatic Multicast Tunneling", Internet- Bumgardner, G., "Automatic Multicast Tunneling",
Draft draft-ietf-mboned-auto-multicast-14, June 2012. draft-ietf-mboned-auto-multicast-14 (work in progress),
June 2012.
[LISP] D. Farinacci et al, , "Locator/ID Separation Protocol [LISP] D. Farinacci et al, "Locator/ID Separation Protocol
(LISP)", March 2009. (LISP)", March 2009.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071,
September 1988.
[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the [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.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. RFC 3819, July 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E. and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC4443] Conta, A., Deering, S. and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4963] Heffner, J., Mathis, M. and B. Chandler, "IPv4 Reassembly [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, July 2007. Errors at High Data Rates", RFC 4963, July 2007.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, November for Application Designers", BCP 145, RFC 5405,
2008. November 2008.
[RFC5415] Calhoun, P., Montemurro, M. and D. Stanley, "Control And [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
Provisioning of Wireless Access Points (CAPWAP) Protocol Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification", RFC 5415, March 2009. Specification", RFC 5415, March 2009.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009. RFC 5722, December 2009.
[RFC6145] Li, X., Bao, C. and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
[Sigcomm2000] [Sigcomm2000]
Jonathan Stone and Craig Partridge , , "When the CRC and Jonathan Stone and Craig Partridge , "When the CRC and TCP
TCP Checksum Disagree", 2000. Checksum Disagree", 2000.
[UDPTT] G Fairhurst, , "The UDP Tunnel Transport mode", Feb 2010. [UDPTT] G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010.
Appendix A. Document Change History Appendix A. Document Change History
{RFC EDITOR NOTE: This section must be deleted prior to publication} {RFC EDITOR NOTE: This section must be deleted prior to publication}
Individual Draft 00 This is the first DRAFT of this document - It Individual Draft 00 This is the first DRAFT of this document - It
contains a compilation of various discussions and contributions contains a compilation of various discussions and contributions
from a variety of IETF WGs, including: mboned, tsv, 6man, lisp, from a variety of IETF WGs, including: mboned, tsv, 6man, lisp,
and behave. This includes contributions from Magnus with text on and behave. This includes contributions from Magnus with text on
RTP, and various updates. RTP, and various updates.
Individual Draft 01 Individual Draft 01
* This version corrects some typos and editorial NiTs and adds * This version corrects some typos and editorial NiTs and adds
discussion of the need to negotiate and verify operation of a discussion of the need to negotiate and verify operation of a
new mechanism (3.3.4). new mechanism (3.3.4).
skipping to change at page 31, line 4 skipping to change at page 32, line 6
Individual Draft 02 Individual Draft 02
* Version -02 corrects some typos and editorial NiTs. * Version -02 corrects some typos and editorial NiTs.
* Added reference to ECMP for tunnels. * Added reference to ECMP for tunnels.
* Clarifies the recommendations at the end of the document. * Clarifies the recommendations at the end of the document.
Working Group Draft 00 Working Group Draft 00
* Working Group Version -00 corrects some typos and removes much * Working Group Version -00 corrects some typos and removes much
of rationale for UDPTT. It also adds some discussion of IPv6 of rationale for UDPTT. It also adds some discussion of IPv6
extension header. extension header.
Working Group Draft 01 Working Group Draft 01
* Working Group Version -01 updates the rules and incorporates * Working Group Version -01 updates the rules and incorporates
off-list feedback. This version is intended for wider review off-list feedback. This version is intended for wider review
within the 6man working group. within the 6man working group.
Working Group Draft 02 Working Group Draft 02
skipping to change at page 31, line 44 skipping to change at page 32, line 47
Working Group Draft 05 Working Group Draft 05
* Resubmission to correct editorial NiTs - thanks to Bill Atwood * Resubmission to correct editorial NiTs - thanks to Bill Atwood
for noting these.Group Draft 05. for noting these.Group Draft 05.
Working Group Draft 06 Working Group Draft 06
* Resubmission to keep draft alive (spelling updated from 05). * Resubmission to keep draft alive (spelling updated from 05).
WoIt that UDP with a zero checksum in IPv6 can safely be used for
this purpose, provided that this usage is governed by a set of
constraints.rking Group Draft 07
* Resubmission after IESG Feedback
* This document becomes a PS Applicability Statement
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Aberdeen, AB24 3UE, Aberdeen, AB24 3UE,
Scotland, UK Scotland, UK
Phone:
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry URI: http://www.erg.abdn.ac.uk/users/gorry
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
Stockholm, SE-164 80 Stockholm, SE-164 80
Sweden Sweden
Phone: +46 8 719 0000 Phone: +46 8 719 0000
Fax:
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
URI:
 End of changes. 134 change blocks. 
416 lines changed or deleted 388 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/