draft-ietf-6man-udpzero-02.txt   draft-ietf-6man-udpzero-03.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: Informational M. Westerlund
Expires: April 27, 2011 Ericsson Expires: October 23, 2011 Ericsson
October 24, 2010 April 21, 2011
IPv6 UDP Checksum Considerations IPv6 UDP Checksum Considerations
draft-ietf-6man-udpzero-02 draft-ietf-6man-udpzero-03
Abstract Abstract
This document examines the role of the UDP transport checksum when This document examines the role of the UDP transport checksum when
used with IPv6, as defined in RFC2460. It presents a summary of the used with IPv6, as defined in RFC2460. It presents a summary of the
trade-offs for evaluating the safety of updating RFC 2460 to permit 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 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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2011. This Internet-Draft will expire on October 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 7 skipping to change at page 4, line 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Document Change History . . . . . . . . . . . . . . . 32 Appendix A. Document Change History . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
The User Datagram Protocol (UDP) transport was defined by RFC768 The User Datagram Protocol (UDP) [RFC0768] transport is defined for
[RFC0768] for IPv4 RFC791 [RFC0791] and is defined in RFC2460 the Internet Protocol (IPv4) [RFC0791] and is defined in Internet
[RFC2460] for IPv6 hosts and routers. The UDP transport protocol has Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The
a minimal set of features. This limited set has enabled a wide range UDP transport protocol has a minimal set of features. This limited
of applications to use UDP, but these application do need to provide set has enabled a wide range of applications to use UDP, but these
many important transport functions on top of UDP. The UDP Usage application do need to provide many important transport functions on
Guidelines [RFC5405] provides overall guidance for application top of UDP. The UDP Usage Guidelines [RFC5405] provides overall
designers, including the use of UDP to support tunneling. The key guidance for application designers, including the use of UDP to
difference between UDP usage with IPv4 and IPv6 is that IPv6 mandates support tunneling. The key difference between UDP usage with IPv4
use of the UDP checksum, i.e. a non-zero value, due to the lack of an and IPv6 is that IPv6 mandates use of the UDP checksum, i.e. a non-
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
skipping to change at page 5, line 23 skipping to change at page 5, line 23
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 assess the trade-offs that would for this use-case with IPv6 and assess the trade-offs that would
arise. arise.
Section 5.1 lists the constraints perceived for safe deployment of Section 5.1 lists the constraints perceived for safe deployment of
zero-checksum. zero-checksum.
Section 6 provides the recommendations for standardization of zero- Section 6 provides the recommendations for standardization of zero-
checksum with a summary of the findings and notes remaining issues checksum with a summary of the findings and notes remaining issues
needing future work . needing future work.
1.2. Background 1.2. Background
This section provides a background on topics relevant to the This section provides a background on topics relevant to the
following discussion. following discussion.
1.2.1. The Role of a Transport Endpoint 1.2.1. The Role of a Transport Endpoint
An Internet transport endpoint should concern itself with the An Internet transport endpoint should concern itself with the
following issues: following issues:
skipping to change at page 7, line 34 skipping to change at page 7, line 34
avoid this extra processing. However, there was concern that the avoid this extra processing. However, there was concern that the
removal of the IP header checksum in IPv6 combined with a UDP removal of the IP header checksum in IPv6 combined with a UDP
checksum set to zero would lessen the protection of the source/ checksum set to zero would lessen the protection of the source/
destination IP addresses and result in a significant (a multiplier of destination IP addresses and result in a significant (a multiplier of
~32,000) increase in the number of times that a UDP packet was ~32,000) increase in the number of times that a UDP packet was
accidentally delivered to the wrong destination address and/or accidentally delivered to the wrong destination address and/or
apparently sourced from the wrong source address. This would have apparently sourced from the wrong source address. This would have
had implications on the detectability of mis-delivery of a packet to had implications on the detectability of mis-delivery of a packet to
an incorrect endpoint/socket, and the robustness of the Internet an incorrect endpoint/socket, and the robustness of the Internet
infrastructure. The use of the UDP checksum is therefore required infrastructure. The use of the UDP checksum is therefore required
[RFC2460] when endpoint application s transmit UDP datagrams over [RFC2460] when endpoint applications transmit UDP datagrams over
IPv6. 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 because many middleboxes support transmission using UDP. In this
skipping to change at page 8, line 41 skipping to change at page 8, line 41
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 Without Explicit Tunnels, known as AMT [AMT] Automatic IP Multicast Without Explicit Tunnels, known as AMT [AMT]
currently specifies UDP as the transport protocol for packets currently specifies UDP as the transport protocol for packets
carrying tunneled IP multicast packets. The current specification carrying tunneled IP multicast packets. The current specification
for AMT requires that the UDP checksum in the outer packet header for AMT requires that the UDP checksum in the outer packet header
should be 0 (see Section 6.6). It argues that the computation of an should be 0 (see Section 6.6 of [AMT]). It argues that the
additional checksum, when an inner packet is already adequately computation of an additional checksum, when an inner packet is
protected, is an unwarranted burden on nodes implementing lightweight already adequately protected, is an unwarranted burden on nodes
tunneling protocols. The AMT protocol needs to replicate a multicast implementing lightweight tunneling protocols. The AMT protocol needs
packet to each gateway tunnel. In this case, the outer IP addresses to replicate a multicast packet to each gateway tunnel. In this
are different for each tunnel and therefore require a different case, the outer IP addresses are different for each tunnel and
pseudo header to be built for each UDP replicated encapsulation. therefore require a different pseudo header to be built for each UDP
replicated encapsulation.
The argument concerning redundant processing costs is valid regarding The argument concerning redundant processing costs is valid regarding
the integrity of a tunneled packet. In some architectures (e.g. PC- the integrity of a tunneled packet. In some architectures (e.g. PC-
based routers), other mechanisms may also significantly reduce based routers), other mechanisms may also significantly reduce
checksum processing costs: There are implementations that have checksum processing costs: There are implementations that have
optimised checksum processing algorithms, including the use of optimised checksum processing algorithms, including the use of
checksum-offloading. This processing is readily available for IPv4 checksum-offloading. This processing is readily available for IPv4
packets at high line rates. Such processing may be anticipated for packets at high line rates. Such processing may be anticipated for
IPv6 endpoints, allowing receivers to reject corrupted packets IPv6 endpoints, allowing receivers to reject corrupted packets
without further processing. However, there are certain classes of without further processing. However, there are certain classes of
skipping to change at page 11, line 25 skipping to change at page 11, line 25
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
also cover the insensitive part by a strong layer 2 frame CRC. cover the insensitive part with the same strong layer 2 frame CRC
that covers the sensitive part.
2.2.1. Using UDP-Lite as a Tunnel Encapsulation 2.2.1. Using UDP-Lite as a Tunnel Encapsulation
Tunnel encapsulations can use UDP-Lite (e.g. Control And Tunnel encapsulations can use UDP-Lite (e.g. Control And
Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP- Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP-
Lite provides a transport-layer checksum, including an IP pseudo Lite provides a transport-layer checksum, including an IP pseudo
header checksum, in IPv6, without the need for a router/middelbox to header checksum, in IPv6, without the need for a router/middelbox to
traverse the entire packet payload. This provides most of the traverse the entire packet payload. This provides most of the
delivery verifications and still keep the complexity of the delivery verifications and still keep the complexity of the
checksumming operation low. UDP-Lite may set the length of checksum checksumming operation low. UDP-Lite may set the length of checksum
skipping to change at page 15, line 6 skipping to change at page 15, line 6
o A stateless application will process the datagram outside of any o A stateless application will process the datagram outside of any
context, a simple example is the ECHO server, which will respond context, a simple example is the ECHO server, which will respond
with a datagram directed to the modified source address. This with a datagram directed to the modified source address. This
would create unwanted additional processing load, and generate would create unwanted additional processing load, and generate
traffic to the modified endpoint address. traffic to the modified endpoint address.
o Some datagram applications build state using the information from o Some datagram applications build state using the information from
packet headers. A previously unused source address would result packet headers. A previously unused source address would result
in receiver processing and the creation of unnecessary transport- in receiver processing and the creation of unnecessary transport-
layer state at the receiver. For example, Real Time Protocol layer state at the receiver. For example, Real Time Protocol
(RTP) [RFC3550] flows commonly employ a source independent (RTP) [RFC3550] sessions commonly employ a source independent
receiver port. State is created for each received flow. receiver port. State is created for each received flow.
Reception of a datagram with a corrupted source address will Reception of a datagram with a corrupted source address will
therefore result in accumulation of unnecessary state in the RTP therefore result in accumulation of unnecessary state in the RTP
state machine, including collision detection and response (since state machine, including collision detection and response (since
the same synchronization source, SSRC, value will appear to arrive the same synchronization source, SSRC, value will appear to arrive
from multiple source IP addresses). from multiple source IP addresses).
In general, the effect of corrupting the source address will depend In general, the effect of corrupting the source address will depend
upon the protocol that processes the packet and its robustness to upon the protocol that processes the packet and its robustness to
this error. For the case where the packet is received by a tunnel this error. For the case where the packet is received by a tunnel
skipping to change at page 15, line 37 skipping to change at page 15, line 37
values are corrupted in transit. This can also happen with IPv4 in values are corrupted in transit. This can also happen with IPv4 in
the zero checksum case, but not when UDP checksums are enabled or the zero checksum case, but not when UDP checksums are enabled or
with UDP-Lite. If the ports carried in the transport header of an with UDP-Lite. If the ports carried in the transport header of an
IPv6 packet were corrupted in transit, packets may be delivered to IPv6 packet were corrupted in transit, packets may be delivered to
the wrong process (on the intended machine) and/or responses or the wrong process (on the intended machine) and/or responses or
errors sent to the wrong application process (on the intended errors sent to the wrong application process (on the intended
machine). machine).
3.1.4. Delivery to an unexpected port 3.1.4. Delivery to an unexpected port
If one combines the corruption effects there is a number of potential If one combines the corruption effects, such as destination address
outcomes when traffic arrives at an unexpected port. This section and ports, there is a number of potential outcomes when traffic
discusses these possibilities and their outcomes for a packet that arrives at an unexpected port. This section discusses these
does not use the UDP checksum validation: possibilities and their outcomes for a packet that does not use the
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 source address and the destination port of the probability that the address or the port information for the source
datagram (the source port is not always used in UDP) match those of or destination becomes corrupt in the datagram such that they match
an existing connection. Unfortunately, such a match may be more those of an existing flow or server port. Unfortunately, such a
likely for UDP than for connection-oriented transports, because: match may be more likely for UDP than for connection-oriented
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]).
skipping to change at page 16, line 36 skipping to change at page 16, line 38
If checksum coverage is suppressed, the application therefore needs If checksum coverage is suppressed, the application therefore needs
to provide a method to detect and discard the unwanted data. A to provide a method to detect and discard the unwanted data. A
tunnel protocol would need to perform its own integrity checks on any tunnel protocol would need to perform its own integrity checks on any
control information if transported in UDP with zero-checksum. If the control information if transported in UDP with zero-checksum. If the
tunnel payload is another IP packet, the packets requiring checksums tunnel payload is another IP packet, the packets requiring checksums
can be assumed to have their own checksums provided that the rate of can be assumed to have their own checksums provided that the rate of
corrupted packets is not significantly larger due to the tunnel corrupted packets is not significantly larger due to the tunnel
encapsulation. If a tunnel transports other inner payloads that do encapsulation. If a tunnel transports other inner payloads that do
not use IP, the assumptions of corruption detection for that not use IP, the assumptions of corruption detection for that
particular protocol must be fulfilled, this may require an additional particular protocol must be fulfilled, this may require an additional
checksum/CRC and/or integrity protection > of the payload and tunnel checksum/CRC and/or integrity protection of the payload and tunnel
headers. headers.
A protocol using UDP zero-checksum can never assume that it is the A protocol using UDP zero-checksum can never assume that it is the
only protocol using a zero checksum. Therefore, it needs to only protocol using a zero checksum. Therefore, it needs to
gracefully handle misdelivery. It must be robust to reception of gracefully handle misdelivery. It must be robust to reception of
malformed packets received on a listening port and expect that these malformed packets received on a listening port and expect that these
packets may contain corrupted data or data associated with a packets may contain corrupted data or data associated with a
completely different protocol. completely different protocol.
3.1.5. Corruption of Fragmentation Information 3.1.5. Corruption of Fragmentation Information
skipping to change at page 17, line 36 skipping to change at page 17, line 38
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
skipping to change at page 19, line 32 skipping to change at page 19, line 35
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 [UDPZ] is that The expectation of the present proposal defined in
this change would only apply to IPv6 router nodes that implement [I-D.ietf-6man-udpchecksums] is that this change would only apply to
specific protocols that permit omission of UDP checksums. However, IPv6 router nodes that implement specific protocols that permit
the distinction between a router and a host is not always clear, omission of UDP checksums. However, the distinction between a router
especially at the transport level. Systems (such as unix-based and a host is not always clear, especially at the transport level.
operating systems) routinely provide both functions. There is also Systems (such as unix-based operating systems) routinely provide both
no way to identify the role of a receiver from a received packet. functions. There is also no way to identify the role of a receiver
from a received packet.
Any new method would therefore need a specific applicability 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
skipping to change at page 21, line 47 skipping to change at page 22, line 5
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 a would require changes to middlebox behavior (e.g. when used with a
NAT that always adjusts the checksum value). NAT that always adjusts the checksum value).
o UDP modified to disable checksum processing[UDPZ]. This requires o UDP modified to disable checksum processing
no checksum calculation, but would require constraints on [I-D.ietf-6man-udpchecksums]. This requires no checksum
appropriate usage and updates to end-points and middleboxes. calculation, but would require constraints on appropriate usage
and updates to end-points and middleboxes.
o IP-in-IP tunneling. As this method completely dispenses with a 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 25, line 16 skipping to change at page 25, line 20
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 Zero-Checksum: A low complexity encapsulation, with good
multiplexing support, limited middlebox traversal that could multiplexing support, limited middlebox traversal that could
improve over time, good load balancing support, in most cases improve over time, good load balancing support, in most cases
requiring application level negotiation and validation. requiring application level negotiation and validation.
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
skipping to change at page 26, line 12 skipping to change at page 26, line 16
balancing, then IP-in-IP tunneling is the simplest. If one wants balancing, then IP-in-IP tunneling is the simplest. If one wants
strengthened error detection, but with currently limited middlebox strengthened error detection, but with currently limited middlebox
traversal and load-balancing. UDP-Lite is appropriate. UDP Zero- traversal and load-balancing. UDP-Lite is appropriate. UDP Zero-
checksum addresses another set of constraints, low complexity and a checksum addresses another set of constraints, low complexity and a
need for load balancing from the current Internet, providing it can need for load balancing from the current Internet, providing it can
live with currently limited middlebox traversal. live with currently limited middlebox traversal.
Techniques for load balancing and middlebox traversal do continue to Techniques for load balancing and middlebox traversal do continue to
evolve. Over a long time, developments in load balancing have good evolve. Over a long time, developments in load balancing have good
potential to improve. This time horizon is long since it requires potential to improve. This time horizon is long since it requires
end-point updates to get full benefit. The challenges of middlebox both load balancer and end-point updates to get full benefit. The
traversal are also expected to change with time, as device challenges of middlebox traversal are also expected to change with
capabilities evolve. Middleboxes are very prolific with a larger time, as device capabilities evolve. Middleboxes are very prolific
proportion of end-user ownership, and therefore may be expected to with a larger proportion of end-user ownership, and therefore may be
take long time cycles to evolve. One potential advantage is that the expected to take long time cycles to evolve. One potential advantage
deployment of IPv6 capable middleboxes are still in its initial phase is that the deployment of IPv6 capable middleboxes are still in its
and the quicker zero-checksum becomes standardized the fewer boxes initial phase and the quicker zero-checksum becomes standardized the
will be non-compliant. fewer boxes will be non-compliant.
Thus, the question of whether to allow UDP with a zero-checksum for Thus, the question of whether to allow UDP with a zero-checksum for
IPv6 under reasonable constraints, is therefore best viewed as a IPv6 under reasonable constraints, is therefore best viewed as a
trade-off between a number of more subjective questions: trade-off between a number of more subjective questions:
o Is there sufficient interest in zero-checksum with the given o Is there sufficient interest in zero-checksum with the given
constraints (summarised below)? constraints (summarised below)?
o Are there other avenues of change that will resolve the issue in a o Are there other avenues of change that will resolve the issue in a
better way and sufficiently quickly ? better way and sufficiently quickly ?
skipping to change at page 30, line 9 skipping to change at page 30, line 12
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 8. IANA Considerations
This document does not require IANA considerations. This document does not require any actions by IANA.
9. Security Considerations 9. Security Considerations
Transport checksums provide the first stage of protection for the Transport checksums provide the first stage of protection for the
stack, although they can not be considered authentication mechanisms. stack, although they can not be considered authentication mechanisms.
These checks are also desirable to ensure packet counters correctly These checks are also desirable to ensure packet counters correctly
log actual activity, and can be used to detect unusual behaviours. log actual activity, and can be used to detect unusual behaviours.
10. References 10. References
skipping to change at page 30, line 44 skipping to change at page 30, line 47
10.2. Informative References 10.2. Informative References
[AMT] Internet draft, draft-ietf-mboned-auto-multicast-10, [AMT] Internet draft, draft-ietf-mboned-auto-multicast-10,
"Automatic IP Multicast Without Explicit Tunnels (AMT)", "Automatic IP Multicast Without Explicit Tunnels (AMT)",
March 2010. March 2010.
[ECMP] "Using the IPv6 flow label for equal cost multipath [ECMP] "Using the IPv6 flow label for equal cost multipath
routing in tunnels (draft-carpenter-flow-ecmp)". routing in tunnels (draft-carpenter-flow-ecmp)".
[I-D.ietf-6man-udpchecksums]
Eubanks, M., "UDP Checksums for Tunneled Packets",
draft-ietf-6man-udpchecksums-00 (work in progress),
March 2011.
[I-D.ietf-intarea-tunnels] [I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "Tunnels in the Internet Touch, J. and M. Townsley, "Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-00 (work in Architecture", draft-ietf-intarea-tunnels-00 (work in
progress), March 2010. progress), March 2010.
[LISP] Internet draft, draft-farinacci-lisp-12.txt, "Locator/ID [LISP] D. Farinacci et al, "Locator/ID Separation Protocol
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.
[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the
Internet checksum", RFC 1141, January 1990. Internet checksum", RFC 1141, January 1990.
[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via
Incremental Update", RFC 1624, May 1994. Incremental Update", RFC 1624, May 1994.
skipping to change at page 31, line 52 skipping to change at page 32, line 11
November 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.
[Sigcomm2000] [Sigcomm2000]
http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/ Jonathan Stone and Craig Partridge , "When the CRC and TCP
9-1.htm, "When the CRC and TCP Checksum Disagree", 2000. Checksum Disagree", 2000.
[UDPTT] "The UDP Tunnel Transport mode", Feb 2010.
[UDPZ] "UDP Checksums for Tunneled Packets", (Oct 2009. [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.
skipping to change at page 33, line 13 skipping to change at page 33, line 18
of the document. of the document.
* A new section comparing the results have been added. * A new section comparing the results have been added.
* The constraints list has been significantly altered by removing * The constraints list has been significantly altered by removing
some and rewording other constraints. some and rewording other constraints.
* This contains other significant language updates to clarify the * This contains other significant language updates to clarify the
intent of this draft. intent of this draft.
**TO BE DONE ** Working Group Draft 03
* This version requires review from proponents and opponents to
the UDP zero checksum proposal.
* * Editorial updates
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: Phone:
 End of changes. 25 change blocks. 
69 lines changed or deleted 75 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/