draft-ietf-6man-udpzero-10.txt   draft-ietf-6man-udpzero-11.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: July 25, 2013 Ericsson Expires: August 25, 2013 Ericsson
January 21, 2013 February 21, 2013
Applicability Statement for the use of IPv6 UDP Datagrams with Zero Applicability Statement for the use of IPv6 UDP Datagrams with Zero
Checksums Checksums
draft-ietf-6man-udpzero-10 draft-ietf-6man-udpzero-11
Abstract Abstract
This document provides an applicability statement for the use of UDP This document provides an applicability statement for the use of UDP
transport checksums with IPv6. It defines recommendations and transport checksums with IPv6. It defines recommendations and
requirements for the use of IPv6 UDP datagrams with a zero UDP requirements for the use of IPv6 UDP datagrams with a zero UDP
checksum. It describes the issues and design principles that need to checksum. It describes the issues and design principles that need to
be considered when UDP is used with IPv6 to support tunnel be considered when UDP is used with IPv6 to support tunnel
encapsulations and examines the role of the IPv6 UDP transport encapsulations and examines the role of the IPv6 UDP transport
checksum. An appendix presents a summary of the trade-offs that were checksum. The document also identifies issues and constraints for
considered in evaluating the safety of the update to RFC 2460 that deployment on network paths that include middleboxes. An appendix
updates use of the UDP checksum with IPv6. presents a summary of the trade-offs that were considered in
evaluating the safety of the update to RFC 2460 that updates use of
the UDP checksum with IPv6.
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 July 25, 2013. This Internet-Draft will expire on August 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 6 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 6 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Motivation for new approaches . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . 9 1.3.5. Support for load balancing . . . . . . . . . . . . . . 8
2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9
2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 10 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 9
2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . 11 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 10
3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 11 2.4. Relation to UDP-Lite and UDP with checksum . . . . . . . . 10
3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 12
3.1. Effect of packet modification in the network . . . . . . . 12 3.1. Effect of packet modification in the network . . . . . . . 12
3.1.1. Corruption of the destination IP address . . . . . . . 13 3.1.1. Corruption of the destination IP address . . . . . . . 14
3.1.2. Corruption of the source IP address . . . . . . . . . 13 3.1.2. Corruption of the source IP address . . . . . . . . . 14
3.1.3. Corruption of Port Information . . . . . . . . . . . . 14 3.1.3. Corruption of Port Information . . . . . . . . . . . . 16
3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 15 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 16
3.1.5. Corruption of Fragmentation Information . . . . . . . 16 3.1.5. Corruption of Fragmentation Information . . . . . . . 17
3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 18 3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 19
3.3. Validating the network path . . . . . . . . . . . . . . . 18 3.3. Validating the network path . . . . . . . . . . . . . . . 20
3.4. Applicability of method . . . . . . . . . . . . . . . . . 19 3.4. Applicability of method . . . . . . . . . . . . . . . . . 21
3.5. Impact on non-supporting devices or applications . . . . . 20 3.5. Impact on non-supporting devices or applications . . . . . 21
4. Constraints on implementation of IPv6 nodes supporting 4. Constraints on implementation of IPv6 nodes supporting
zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 20 zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Requirements on usage of the zero UDP checksum . . . . . . . . 22 5. Requirements on usage of the zero UDP checksum . . . . . . . . 23
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Evaluation of proposal to update RFC 2460 to Appendix A. Evaluation of proposal to update RFC 2460 to
support zero checksum . . . . . . . . . . . . . . . . 28 support zero checksum . . . . . . . . . . . . . . . . 31
A.1. Alternatives to the Standard Checksum . . . . . . . . . . 28 A.1. Alternatives to the Standard Checksum . . . . . . . . . . 31
A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 30 A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 32
A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 30 A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 33
A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 31 A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 33
A.2.3. Ingress and Egress Performance Implications . . . . . 31 A.2.3. Ingress and Egress Performance Implications . . . . . 34
A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 32 A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 34
A.2.5. Corruption Detection Strength . . . . . . . . . . . . 32 A.2.5. Corruption Detection Strength . . . . . . . . . . . . 35
A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 33 A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 35
Appendix B. Document Change History . . . . . . . . . . . . . . . 35 Appendix B. Document Change History . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
The User Datagram Protocol (UDP) [RFC0768] transport is defined for The User Datagram Protocol (UDP) [RFC0768] transport is defined for
the Internet Protocol (IPv4) [RFC0791] and is defined in "Internet the Internet Protocol (IPv4) [RFC0791] and is defined in "Internet
Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The
UDP transport protocol has a minimal set of features. This limited UDP transport protocol has a minimal set of features. This limited
set has enabled a wide range of applications to use UDP, but these set has enabled a wide range of applications to use UDP, but these
application do need to provide many important transport functions on application do need to provide many important transport functions on
top of UDP. The UDP Usage Guidelines [RFC5405] provides overall top of UDP. The UDP Usage Guidelines [RFC5405] provides overall
guidance for application designers, including the use of UDP to guidance for application designers, including the use of UDP to
support tunneling. The key difference between UDP usage with IPv4 support tunneling. The key difference between UDP usage with IPv4
and IPv6 is that RFC 2460 mandates use of a calculated UDP checksum, and IPv6 is that RFC 2460 mandates use of a calculated UDP checksum,
i.e. a non-zero value, due to the lack of an IPv6 header checksum. i.e. a non-zero value, due to the lack of an IPv6 header checksum.
Algorithms for checksum computation are described in [RFC1071]. The inclusion of the pseudo header in the checksum computation
provides a statistical check that datagrams have been delivered to
the intended IPv6 destination node. Algorithms for checksum
computation are described in [RFC1071].
The lack of a possibility to use an IPv6 datagram with a zero UDP The lack of a possibility to use an IPv6 datagram with a zero UDP
checksum has been observed as a real problem for certain classes of checksum has been observed as a real problem for certain classes of
application, primarily tunnel applications. This class of application, primarily tunnel applications. This class of
application has been deployed with a zero UDP checksum using IPv4. application has been deployed with a zero UDP checksum using IPv4.
The design of IPv6 raises different issues when considering the The design of IPv6 raises different issues when considering the
safety of using a UDP checksum with IPv6. These issues can safety of using a UDP checksum with IPv6. These issues can
significantly affect applications, both when an endpoint is the significantly affect applications, both when an endpoint is the
intended user and when an innocent bystander (when a packet is intended user and when an innocent bystander (when a packet is
received by a different endpoint to that intended). received by a different endpoint to that intended).
skipping to change at page 7, line 31 skipping to change at page 6, line 33
o Reducing forwarding costs, motivated by redundancy present in the o Reducing forwarding costs, motivated by redundancy present in the
encapsulated packet header, since in tunnel encapsulations, encapsulated packet header, since in tunnel encapsulations,
payload integrity and length verification may be provided by payload integrity and length verification may be provided by
higher layer encapsulations (often using the IPv4, UDP, UDP-Lite, higher layer encapsulations (often using the IPv4, UDP, UDP-Lite,
or TCP checksums). or TCP checksums).
o Eliminating a need to access the entire packet when forwarding the o Eliminating a need to access the entire packet when forwarding the
packet by a tunnel endpoint. packet by a tunnel endpoint.
o Enhancing ability to traverse middleboxes, especially Network o Enhancing ability to traverse middleboxes, especially Network
Address Translators, NATs. Address Translators, NATs. However, use of the zero UDP checksum
does not fully fulfill this need, because only certain classes of
middleboxes, (i.e. ones that do not modify or evaluate the UDP
checksum) will support zero UDP checksum traffic, other
middleboxes will require an update to support this traffic.
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. The processing cost per tunnel includes both a single router/host. The processing cost per tunnel includes both
state (memory requirements) and per-packet processing. state (memory requirements) and per-packet processing at the tunnel
ingress and egress.
Automatic IP Multicast Tunneling, known as AMT Automatic IP Multicast Tunneling, known as AMT
[I-D.ietf-mboned-auto-multicast] currently specifies UDP as the [I-D.ietf-mboned-auto-multicast] currently specifies UDP as the
transport protocol for packets carrying tunneled IP multicast transport protocol for packets carrying tunneled IP multicast
packets. The current specification for AMT requires that the UDP packets. The current specification for AMT states that the UDP
checksum in the outer packet header should be zero (see Section 6.6 checksum in the outer packet header should be zero (see Section 6.6
of [I-D.ietf-mboned-auto-multicast]). This argues that the of [I-D.ietf-mboned-auto-multicast]). This argues that the
computation of an additional checksum is an unwarranted burden on computation of an additional checksum is an unwarranted burden on
nodes implementing lightweight tunneling protocols when an inner nodes implementing lightweight tunneling protocols when an inner
packet is already adequately protected, . The AMT protocol needs to packet is already adequately protected, . The AMT protocol needs to
replicate a multicast packet to each gateway tunnel. In this case, replicate a multicast packet to each gateway tunnel. In this case,
the outer IP addresses are different for each tunnel and therefore the outer IP addresses are different for each tunnel and therefore
require a different pseudo header to be built for each UDP replicated require a different pseudo header to be built for each UDP replicated
encapsulation. encapsulation.
skipping to change at page 8, line 22 skipping to change at page 7, line 30
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.
processing of a transport checksum over an entire (large) packet.
Hence the currently defined IPv6 UDP checksum is poorly suited to use When this design is used to support a tunnel ingress and egress, it
within a router that is unable to access the entire packet and does prevents fast processing of a transport checksum over an entire
not provide checksum-offloading. Thus enabling checksum calculation (large) packet. Hence the currently defined IPv6 UDP checksum is
over the complete packet can impact router design, performance poorly suited to use within a router that is unable to access the
improvement, energy consumption and/or cost. entire packet and does not provide checksum-offloading. Thus
enabling checksum calculation over the complete packet can impact
router design, performance improvement, energy consumption and/or
cost.
1.3.4. Interactions with middleboxes 1.3.4. Interactions with middleboxes
In IPv4, UDP-encapsulation may be desirable for NAT traversal, since In IPv4, UDP-encapsulation may be desirable for NAT traversal, since
UDP support is commonly provided. It is also necessary due to the UDP support is commonly provided. It is also necessary due to the
almost ubiquitous deployment of IPv4 NATs. There has also been almost ubiquitous deployment of IPv4 NATs. There has also been
discussion of NAT for IPv6, although not for the same reason as in discussion of NAT for IPv6, although not for the same reason as in
IPv4. If IPv6 NAT becomes a reality they hopefully do not present IPv4. If IPv6 NAT becomes a reality they hopefully do not present
the same protocol issues as for IPv4. If NAT is defined for IPv6, it the same protocol issues as for IPv4. If NAT is defined for IPv6, it
should take into consideration the use of a zero UDP checksum. should take into consideration the use of a zero UDP checksum.
skipping to change at page 9, line 13 skipping to change at page 8, line 24
capabilities to improve over time. We also note that deployment of capabilities to improve over time. We also note that deployment of
IPv6-capable middleboxes is still in its initial phases. Thus, it IPv6-capable middleboxes is still in its initial phases. Thus, it
might be that the number of non-updated boxes quickly become a very might be that the number of non-updated boxes quickly become a very
small percentage of the deployed middleboxes. small percentage of the deployed middleboxes.
1.3.5. Support for load balancing 1.3.5. Support for load balancing
The UDP port number fields have been used as a basis to design load- The UDP port number fields have been used as a basis to design load-
balancing solutions for IPv4. This approach has also been leveraged balancing solutions for IPv4. This approach has also been leveraged
for IPv6. An alternate method would be to utilise the IPv6 Flow for IPv6. An alternate method would be to utilise the IPv6 Flow
Label as a basis for entropy for load balancing. This would have the Label [RFC6437] as a basis for entropy for load balancing. This
desirable effect of releasing IPv6 load-balancing devices from the would have the desirable effect of releasing IPv6 load-balancing
need to assume semantics for the use of the transport port field and devices from the need to assume semantics for the use of the
also works for all type of transport protocols. transport port field and also works for all type of transport
protocols.
This use of the flow-label is consistent with the intended use, This use of the flow-label for load balancing is consistent with the
although further clarity may be needed to ensure the field can be intended use, although further clarity was needed to ensure the field
consistently used for this purpose, (e.g. the updated IPv6 Flow Label can be consistently used for this purpose, therefore an updated IPv6
[RFC6438] and Equal-Cost Multi-Path routing, ECMP [RFC6437]). Router Flow Label [RFC6437] and Equal-Cost Multi-Path routing usage, (ECMP)
vendors could be encouraged to start using the IPv6 Flow Label as a [RFC6438] was produced. Router vendors could be encouraged to start
part of the flow hash, providing support for ECMP without requiring using the IPv6 Flow Label as a part of the flow hash, providing
use of UDP. support for ECMP without requiring use of UDP.
However, the method for populating the outer IPv6 header with a value However, the method for populating the outer IPv6 header with a value
for the flow label is not trivial: If the inner packet uses IPv6, for the flow label is not trivial: If the inner packet uses IPv6,
then the flow label value could be copied to the outer packet header. then the flow label value could be copied to the outer packet header.
However, many current end-points set the flow label to a zero value However, many current end-points set the flow label to a zero value
(thus no entropy). The ingress of a tunnel seeking to provide good (thus no entropy). The ingress of a tunnel seeking to provide good
entropy in the flow label field would therefore need to create a entropy in the flow label field would therefore need to create a
random flow label value and keep corresponding state, so that all random flow label value and keep corresponding state, so that all
packets that were associated with a flow would be consistently given packets that were associated with a flow would be consistently given
the same flow label. Although possible, this complexity may not be the same flow label. Although possible, this complexity may not be
skipping to change at page 10, line 16 skipping to change at page 9, line 27
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 [RFC5097] 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, with the exception that it uses a fully equivalent with UDP, with the exception that it uses a
different value in the Next Header field in the IPv6 header. Errors/ different value in the Next Header field in the IPv6 header. Errors/
skipping to change at page 11, line 31 skipping to change at page 10, line 43
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.
2.4. Relation to UDP-Lite and UDP with checksum
The operation of IPv6 with UDP with a zero-checksum is not the same
as IPv4 with UDP with a zero-checksum. Protocol designers should not
be fooled into thinking the two are the same. The requirements below
list a set of additional considerations.
Where possible, existing general tunnel encapsulations, such as GRE,
IP-in-IP, should be used. This section assumes that such existing
tunnel encapsulations do not offer the functionally required to
satisfy the protocol designer's goals. The section considers the
standardized alternative solutions, rather than the full set of ideas
evaluated in Appendix A. The alternatives to UDP with a zero
checksum are UDP with a (calculated) checksum, and UDP-Lite.
UDP with a checksum has the advantage of close to universal support
in both endpoints and middleboxes. It also provides statistical
verification of delivery to the intended destination (address and
port). However, some classes of device have limited support for
calculation of a checksum that covers a full datagram. For these
devices, this can incur significant processing cost (e.g. requiring
processing in the router slow-path) and can hence reduce capacity or
fail to function.
UDP-Lite has the advantage of using a checksum that is calculated
only over the pseudo header and the UDP header. This provides a
statistical verification of delivery to the intended destination
(address and port). The checksum can be calculated without access to
the datagram payload, only requiring access to the part to be
protected. A drawback is that UDP-Lite has currently limited support
in both end-points (i.e. is not supported on all operating system
platforms) and middleboxes (that require support for the UDP-Lite
header type). A path verification method is therefore recommended.
IPv6 and UDP with a zero-checksum can also be used by nodes that do
not permit calculation of a payload checksum. Many existing classes
of middleboxes do not verify or change the transport checksum. For
these middleboxes, IPv6 with a zero UDP checksum is expected to
function where UDP-Lite would not. However, support for the zero UDP
checksum in middleboxes that do change or verify the checksum is
currently limited, and this may result in datagrams with a zero UDP
checksum being discarded, therefore a path verification method is
recommended.
There are sets of constrains for which no solution exist: A protocol
designer that needs to originate or receive datagrams on a device
that can not efficiently calculate a checksum over a full datagram
and also needs these packets to pass through a middlebox that
verifies or changes a UDP checksum, but does not support a zero UDP
checksum, can not use the zero UDP checksum method. Similarly, one
that originates datagrams on a device with UDP-Lite support, but
needs the packets to pass through a middlebox that does not support
UDP-Lite, can not use UDP-Lite. For such cases, there is no optimal
solution and the current recommendation is to use or fall-back to
using UDP with full checksum coverage.
3. Issues Requiring Consideration 3. Issues Requiring Consideration
This informative section evaluates issues around the proposal to This informative section evaluates issues around the proposal to
update IPv6 [RFC2460], to enable the UDP transport checksum to be set update IPv6 [RFC2460], to enable the UDP transport checksum to be set
to zero. Some of the identified issues are shared with other to zero. Some of the identified issues are shared with other
protocols already in use. The section also provides background to protocols already in use. The section also provides background to
the requirements and recommendations that follow. the requirements and recommendations that follow.
The decision by RFC 2460 to omit an integrity check at the network The decision in RFC 2460 to omit an integrity check at the network
level meant that the IPv6 transport checksum was overloaded with many level meant that the IPv6 transport checksum was overloaded with many
functions, including validating: functions, including validating:
o the endpoint address was not corrupted within a router, i.e., a o the endpoint address was not corrupted within a router, i.e., a
packet was intended to be received by this destination and packet was intended to be received by this destination and
validate that the packet does not consist of a wrong header validate that the packet does not consist of a wrong header
spliced to a different payload; spliced to a different payload;
o that extension header processing is correctly delimited - i.e., o that extension header processing is correctly delimited - i.e.,
the start of data has not been corrupted. In this case, reception the start of data has not been corrupted. In this case, reception
skipping to change at page 12, line 27 skipping to change at page 12, line 48
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. Older
Evidence has been presented [Sigcomm2000] to show that this was once evidence in "When the CRC and TCP Checksum Disagree" [Sigcomm2000]
an issue with IPv4 routers, and occasional corruption could result show that this was once an issue in year 2000 with IPv4 routers, and
from bad internal router processing in routers or hosts. These occasional corruption could result from bad internal router
errors are not detected by the strong frame checksums employed at the processing in routers or hosts. These errors are not detected by the
link-layer [RFC3819]. There is no current evidence that such cases strong frame checksums employed at the link-layer [RFC3819]. During
are rare in the modern Internet, nor that they may not be applicable the development of this document in 2009, individuals provided
to IPv6. It therefore seems prudent not to relax this constraint. reports of observed rates for received UDP datagrams using IPv4 where
The emergence of low-end IPv6 routers and the proposed use of NAT the UDP checksum had been detected as corrupt. These rates where as
with IPv6 further motivate the need to protect from this type of high as 1.39E-4 for some paths, but also close to zero for some other
error. paths.
There is extensive experience of deployment using tunnel protocols in
well-managed networks (e.g. corporate networks or service provider
core networks). This has shown the robustness of methods such as PWE
and MPLS that do not employ a transport protocol checksum and have
not specified mechanisms to protect from corruption of the
unprotected headers (such as the VPN Identifier in MPLS). Reasons
for the robustness may include:
o A reduced probability of corruption on paths through well-managed
networks.
o IP form the majority of the inner traffic carried by these tunnel.
Hence from a transport perspective, endpoint verification is
already being performed when processing a received IPv4 packet or
by the transport pseudo-header for an IPv6 packet. This update to
UDP does not change this behaviour.
o In certain cases, a combination of additional filtering (e.g.
filter of a MAC destination address in a L2 tunnel) significantly
reduces the probability of final mis-delivery to the IP stack.
o The tunnel protocols did not use a UDP transport header, any
corruption is therefore unlikely to result in misdelivery to
another UDP-based application. This concern is specific to the
use of UDP with IPv6.
While this experience can guide the present recommendations, any
update to UDP must preserve operation in the general Internet. This
is heterogeneous and can include links and systems of very varying
characteristics. Transport protocols used by hosts need to be
designed with this in mind, especially when there is need to traverse
edge networks, where middlebox deployments are common.
For the general Internet, there is no current evidence that
corruption is rare, nor that this may not be applicable to IPv6. It
therefore seems prudent not to relax checks on misdelivery . The
emergence of low-end IPv6 routers and the proposed use of NAT with
IPv6 further motivate the need to protect from misdelivery.
Corruption in the network may result in: Corruption in the network may result in:
o A datagram being misdelivered to the wrong host/router or the o A datagram being misdelivered to the wrong host/router or the
wrong transport entity within an endpoint. Such a datagram needs wrong transport entity within an endpoint. Such a datagram needs
to be discarded; to be discarded;
o A datagram payload being corrupted, but still delivered to the o A datagram payload being corrupted, but still delivered to the
intended host/router transport entity. Such a datagram needs to intended host/router transport entity. Such a datagram needs to
be either discarded or correctly processed by an application that be either discarded or correctly processed by an application that
skipping to change at page 13, line 20 skipping to change at page 14, line 32
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 IPv6 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.
Detection of this corruption by a UDP receiver relies on the IPv6
pseudo header incorporated in the transport checksum.
There are two possible outcomes: There are two possible outcomes:
o Delivery to a destination address that is not in use (the packet o Delivery to a destination address that is not in use (the packet
will not be delivered, but could result in an error report); will not be delivered, but 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 a computed checksum, the packet would be silent discard. Without a computed checksum, the packet would be
passed to the endpoint port demultiplexing function. If an passed to the endpoint port demultiplexing function. If an
application is bound to the associated ports, the packet payload application is bound to the associated ports, the packet payload
will be passed to the application (see the subsequent section on will be passed to the application (see the subsequent section on
port 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. Detection of this corruption by a UDP
receiver relies on the IPv6 pseudo header incorporated in the
transport checksum.
Corruption of an IPv6 source address does not result in the IP packet Corruption of an IPv6 source address does not result in the IP packet
being delivered to a different endpoint protocol or destination being delivered to a different endpoint protocol or destination
address. If only the source address is corrupted, the datagram will address. If only the source address is corrupted, the datagram will
likely be processed in the intended context, although with erroneous likely be processed in the intended context, although with erroneous
origin information. When using Unicast Reverse Path Forwarding origin information. When using Unicast Reverse Path Forwarding
[RFC2827], a change in address may result in the router discarding [RFC2827], a change in address may result in the router discarding
the packet when the route to the modified source address is different the packet when the route to the modified source address is different
to that of the source address of the original packet. to that of the source address of the original packet.
skipping to change at page 22, line 31 skipping to change at page 23, line 50
the reported packet actually originated from the node, before the reported packet actually originated from the node, before
acting upon the information (e.g. validating the address and acting upon the information (e.g. validating the address and
port numbers in the ICMPv6 message body). port numbers in the ICMPv6 message body).
5. Requirements on usage of the zero UDP checksum 5. Requirements on usage of the zero UDP checksum
This section is an applicability statement that identifies This section is an applicability statement that identifies
requirements and recommendations for protocols and tunnel requirements and recommendations for protocols and tunnel
encapsulations that are transported over an IPv6 transport flow (e.g. encapsulations that are transported over an IPv6 transport flow (e.g.
tunnel) that does not perform a UDP checksum calculation to verify tunnel) that does not perform a UDP checksum calculation to verify
the integrity at the transport endpoints. the integrity at the transport endpoints. Before deciding to use the
zero UDP checksum and loose the integrity verification provided, a
protocol developer should seriously consider if they can use
checksummed UDP packets or UDP-Lite [RFC3828], because IPv6 with a
zero UDP checksum is not equivalent in behavior to IPv4 with zero UDP
checksum.
The requirements and recommendations for protocols and tunnel
encapsulations using an IPv6 transport flow that does not perform a
UDP checksum calculation to verify the integrity at the transport
endpoints are:
1. Transported protocols that enable the use of zero UDP checksum 1. Transported protocols that enable the use of zero UDP checksum
MUST only enable this for a specific port or port-range. This MUST only enable this for a specific port or port-range. This
needs to be enabled at the sending and receiving endpoints for a needs to be enabled at the sending and receiving endpoints for a
UDP flow. UDP flow.
2. An integrity mechanism is always RECOMMENDED at the transported 2. An integrity mechanism is always RECOMMENDED at the transported
protocol layer to ensure that corruption rates of the delivered protocol layer to ensure that corruption rates of the delivered
payload is not increased (e.g. the inner-most packet of a UDP payload is not increased (e.g. the inner-most packet of a UDP
tunnel). A mechanism that isolates the causes of corruption tunnel). A mechanism that isolates the causes of corruption
skipping to change at page 24, line 7 skipping to change at page 25, line 37
are outside a configured range. are outside a configured range.
10. When a middlebox forwards an IPv6 UDP flow containing datagrams 10. When a middlebox forwards an IPv6 UDP flow containing datagrams
with both a zero and standard UDP checksum, the middlebox MUST with both a zero and standard UDP checksum, the middlebox MUST
NOT maintain separate state for flows depending on the value of NOT maintain separate state for flows depending on the value of
their UDP checksum field. (This requirement is necessary to their UDP checksum field. (This requirement is necessary to
enable a sender that always calculates a checksum to communicate enable a sender that always calculates a checksum to communicate
via a middlebox with a remote endpoint that uses a zero UDP via a middlebox with a remote endpoint that uses a zero UDP
checksum.) checksum.)
Special considerations are required when designing a UDP tunnel
protocol, where the tunnel ingress or egress may be a router that may
not have access to the packet payload. When the node is acting as a
host (i.e., sending or receiving a packet addressed to itself), the
checksum processing is similar to other hosts. However, when the
node (e.g. a router) is acting as a tunnel ingress or egress that
forwards a packet to or from a UDP tunnel, there may be restricted
access to the packet payload. This prevents calculating (or
verifying) a UDP checksum. In this case, the tunnel protocol may use
a zero UDP checksum and must:
o Ensure that tunnel ingress and tunnel egress router are both
configured to use a zero UDP checksum. For example, this may
include ensuring that hardware checksum offloading is disabled.
o The tunnel operator must ensure that middleboxes on the network
path are updated to support use of a zero UDP checksum.
o A tunnel egress should implement appropriate security techniques
to protect from overload, including source address filtering to
prevent traffic injection by an attacker, and rate-limiting of any
packets that incur additional processing, such as UDP datagrams
used for control functions that require verification of a
calculated checksum to verify the network path. Usage of common
control traffic for multiple tunnels between a pair of nodes can
assist in reducing the number of packets to be processed.
6. Summary 6. Summary
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. It presents a summary of the trade-offs in transport checksums with IPv6.
evaluating the safety of updating RFC 2460 to permit an IPv6 endpoint
to use a zero UDP checksum field to indicate that no checksum is
present.
The use of UDP with a zero UDP checksum has merits for some It examines the role of the UDP transport checksum when used with
applications, such as tunnel encapsulation, and is widely used in IPv6 and presents a summary of the trade-offs in evaluating the
IPv4. However, there are different dangers for IPv6: There is an safety of updating RFC 2460 to permit an IPv6 endpoint to use a zero
increased risk of corruption and misdelivery when using zero UDP UDP checksum field to indicate that no checksum is present.
checksum in IPv6 compared to using IPv4 due to the lack of an IPv6
header checksum. Thus, applications need to re-evaluate the risks of Application designers should first examine whether their transport
enabling use of a zero UDP checksum and consider a solution that at goals may be met using standard UDP (with a calculated checksum) or
least provides the same delivery protection as for IPv4, for example by using UDP-Lite. The use of UDP with a zero UDP checksum has
by utilizing UDP-Lite, or by enabling the UDP checksum. The use of merits for some applications, such as tunnel encapsulation, and is
checksum off-loading may help alleviate the checksum processing cost widely used in IPv4. However, there are different dangers for IPv6:
and permit use of a checksum using method defined in RFC 2460. There is an increased risk of corruption and misdelivery when using
zero UDP checksum in IPv6 compared to using IPv4 due to the lack of
an IPv6 header checksum. Thus, applications need to evaluate the
risks of enabling use of a zero UDP checksum and consider a solution
that at least provides the same delivery protection as for IPv4, for
example by utilizing UDP-Lite, or by enabling the UDP checksum. The
use of checksum off-loading may help alleviate the cost of checksum
processing and permit use of a checksum using method defined in RFC
2460.
Tunnel applications using UDP for encapsulation can in many cases use Tunnel applications using UDP for encapsulation can in many cases use
a zero UDP checksum without significant impact on the corruption a zero UDP checksum without significant impact on the corruption
rate. A well-designed tunnel application should include consistency rate. A well-designed tunnel application should include consistency
checks to validate the header information encapsulated with a checks to validate the header information encapsulated with a
received packet. In most cases, tunnels encapsulating IP packets can received packet. In most cases, tunnels encapsulating IP packets can
rely on the integrity protection provided by the transported protocol rely on the integrity protection provided by the transported protocol
(or tunneled inner packet). When correctly implemented, such an (or tunneled inner packet). When correctly implemented, such an
endpoint will not be negatively impacted by omission of the endpoint will not be negatively impacted by omission of the
transport-layer checksum. Recursive tunneling and fragmentation is a transport-layer checksum. Recursive tunneling and fragmentation is a
skipping to change at page 25, line 16 skipping to change at page 27, line 29
the reduced checksum for UDP-Lite when used with IPv6. the reduced checksum for UDP-Lite when used with IPv6.
The transport of recursive tunneling and the use of fragmentation The transport of recursive tunneling and the use of fragmentation
pose difficult issues that need to be considered in the design of pose difficult issues that need to be considered in the design of
tunnel protocols. There is an increased risk of an error in the tunnel protocols. There is an increased risk of an error in the
inner-most packet when fragmentation when several layers of tunneling inner-most packet when fragmentation when several layers of tunneling
and several different reassembly processes are run without and several different reassembly processes are run without
verification of correctness. This requires extra thought and careful verification of correctness. This requires extra thought and careful
consideration in the design of transported tunnels. consideration in the design of transported tunnels.
The use of the updated method must consider the implications on Any use of the updated method must consider the implications on
firewalls, NATs and other middleboxes. It is not expected that IPv6 firewalls, NATs and other middleboxes. It is not expected that IPv6
NATs handle IPv6 UDP datagrams in the same way that they handle IPv4 NATs handle IPv6 UDP datagrams in the same way that they handle IPv4
UDP datagrams. This possibly reduces the need to update the UDP datagrams. In many deployed cases this will require an update to
checksum. Firewalls are intended to be configured, and therefore may support an IPv6 zero UDP checksum. Firewalls are intended to be
need to be explicitly updated to allow new services or protocols. configured, and therefore may need to be explicitly updated to allow
IPv6 middlebox deployment is not yet as prolific as it is in IPv4, new services or protocols. IPv6 middlebox deployment is not yet as
and therefore new devices are expected to follow the methods prolific as it is in IPv4, and therefore new devices are expected to
specified in this document. follow the methods specified in this document.
Each application should consider the implications of choosing an IPv6 Each application should consider the implications of choosing an IPv6
transport that uses a zero UDP checksum, and consider whether other transport that uses a zero UDP checksum, and consider whether other
standard methods may be more appropriate, and may simplify standard methods may be more appropriate, and may simplify
application design. application design.
7. Acknowledgements 7. Acknowledgements
Brian Haberman, Brian Carpenter, Margaret Wasserman, Lars Eggert, Brian Haberman, Brian Carpenter, Margaret Wasserman, Lars Eggert,
others in the TSV directorate. Barry Leiba, Ronald Bonica and others in the TSV directorate. Barry Leiba, Ronald Bonica, Pete
Stewart Bryant are thanked for resulting in a document with much Resnick, and Stewart Bryant are thanked for resulting in a document
greater applicability. Thanks to P.F. Chimento for careful review with much greater applicability. Thanks to P.F. Chimento for careful
and editorial corrections. review and editorial corrections.
Thanks also to: Remi Denis-Courmont, Pekka Savola, Glen Turner, and Thanks also to: Remi Denis-Courmont, Pekka Savola, Glen Turner, and
many others who contributed comments and ideas via the 6man, behave, many others who contributed comments and ideas via the 6man, behave,
lisp and mboned lists. lisp and mboned lists.
8. IANA Considerations 8. IANA Considerations
This document does not require any actions by IANA. This document does not require any actions by IANA.
9. Security Considerations 9. Security Considerations
Transport checksums provide the first stage of protection for the Transport checksums provide the first stage of protection for the
stack, although they can not be considered authentication mechanisms. stack, although they can not be considered authentication mechanisms.
These checks are also desirable to ensure packet counters correctly These checks are also desirable to ensure packet counters correctly
log actual activity, and can be used to detect unusual behaviours. log actual activity, and can be used to detect unusual behaviours.
Depending on the hardware design, the processing requirements may Depending on the hardware design, the processing requirements may
differ for tunnels that have a zero UDP checksum and those that differ for tunnels that have a zero UDP checksum and those that
calculate a checksum. This processing overhead may need to be calculate a checksum. This processing overhead may need to be
considered when deciding whether to enable a tunnel and to determine considered when deciding whether to enable a tunnel and to determine
an acceptable rate for transmission. an acceptable rate for transmission. This can become a security risk
for designs that can handle a significantly larger number of packets
with zero UDP checksums compared to datagrams with a non-zero
checksum, such as tunnel egress. An attacker could attempt to inject
non-zero checksummed UDP packets into a tunnel forwarding zero
checksum UDP packets and cause overload in the processing of the non-
zero checksums, e.g. if this happens in a routers slow path.
Protection mechanisms should therefore be employed when this threat
exists. Protection may include source address filtering to prevent
an attacker injecting traffic, as well as throttling the amount of
non-zero checksum traffic. The latter may impact the function of the
tunnel protocol.
Transmission of IPv6 packets with a zero UDP checksum could reveal Transmission of IPv6 packets with a zero UDP checksum could reveal
additional information to an on-path attacker to identify the additional information to an on-path attacker to identify the
operating system or configuration of a sending node. There is a need operating system or configuration of a sending node. There is a need
to probe the network path to determine whether the path supports to probe the network path to determine whether the current path
using IPv6 packets with a zero UDP checksum. The details of the supports using IPv6 packets with a zero UDP checksum. The details of
probing mechanism may differ for different tunnel encapsulations and the probing mechanism may differ for different tunnel encapsulations
if visible in the network (e.g. if not using IPsec in encryption and if visible in the network (e.g. if not using IPsec in encryption
mode) could reveal additional information to an on-path attacker to mode) could reveal additional information to an on-path attacker to
identify the type of tunnel being used. identify the type of tunnel being used.
IP-in-IP or GRE tunnels offer good traversal of middleboxes that have IP-in-IP or GRE tunnels offer good traversal of middleboxes that have
not been designed for security, e.g. firewalls. However, firewalls not been designed for security, e.g. firewalls. However, firewalls
may be expected to be configured to block general tunnels as they may be expected to be configured to block general tunnels as they
present a large attack surface. This applicability statement present a large attack surface. This applicability statement
therefore permits this method to be enabled only for specific ranges therefore permits this method to be enabled only for specific ranges
of ports. of ports.
When enabled, nodes and middleboxes must forward received UDP When the zero UDP checksum mode is enabled for a range of ports,
datagrams that have either a calculated checksum or a zero checksum. nodes and middleboxes must forward received UDP datagrams that have
either a calculated checksum or a zero checksum.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-6man-udpchecksums] [I-D.ietf-6man-udpchecksums]
Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", UDP Checksums for Tunneled Packets",
draft-ietf-6man-udpchecksums-07 (work in progress), draft-ietf-6man-udpchecksums-07 (work in progress),
January 2013. January 2013.
skipping to change at page 28, line 10 skipping to change at page 30, line 35
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.
[RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite
protocol", RFC 5097, January 2008.
[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, for Application Designers", BCP 145, RFC 5405,
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.
skipping to change at page 32, line 20 skipping to change at page 34, line 45
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 devices,
devices, which are expected to require updates. which are expected to require updates.
o Ignoring the checksum on reception will require changes at both o Ignoring the checksum on reception will require changes at both
end-points. The never ceasing risk of path failure requires end-points. The never ceasing risk of path failure requires
additional checks to ensure this solution is robust and will additional checks to ensure this solution is robust and will
require changes or additions to the tunnel control protocol to require changes or additions to the tunnel control protocol to
negotiate support and validate the path. negotiate support and validate the path.
o The remaining solutions offer similar deployability. UDP-Lite o The remaining solutions (including the zero checksum method) offer
requires support at both end-points and in middleboxes. UDPTT and similar deployability. UDP-Lite requires support at both end-
the zero UDP checksum method with or without an extension header points and in middleboxes. UDPTT and the zero UDP checksum method
require support at both end-points and in middleboxes. UDP-Lite, with or without an extension header require support at both end-
UDPTT, and the zero UDP checksum method and use of extension points and in middleboxes. UDP-Lite, UDPTT, and the zero UDP
headers may additionally require changes or additions to the checksum method and use of extension headers may additionally
tunnel control protocol to negotiate support and path validation. require changes or additions to the tunnel control protocol to
negotiate support and path validation.
A.2.5. Corruption Detection Strength A.2.5. Corruption Detection Strength
The standard UDP checksum and the delta checksum can both provide The standard UDP checksum and the delta checksum can both provide
some verification at the tunnel egress. This can significantly some verification at the tunnel egress. This can significantly
reduce the probability that a corrupted inner packet is forwarded. reduce the probability that a corrupted inner packet is forwarded.
UDP-Lite, UDPTT and the extension header all provide some UDP-Lite, UDPTT and the extension header all provide some
verification against corruption, but do not verify the inner packet. verification against corruption, but do not verify the inner packet.
They only provide a strong indication that the delivered packet was They only provide a strong indication that the delivered packet was
intended for the tunnel egress and was correctly delimited. The intended for the tunnel egress and was correctly delimited.
methods using a zero UDP checksum, ignoring the UDP checksum on
The methods using a zero UDP checksum, ignoring the UDP checksum on
reception and IP-and-IP encapsulation all provide no verification reception and IP-and-IP encapsulation all provide no verification
that a received datagram was intended to be processed by a specific that a received datagram was intended to be processed by a specific
tunnel egress or that the inner encapsulated packet was correct. tunnel egress or that the inner encapsulated packet was correct.
Section 3.1 discusses experience using specific protocols in well-
managed networks.
A.2.6. Comparison Summary A.2.6. Comparison Summary
The comparisons above may be summarised as "there is no silver bullet The comparisons above may be 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: The method defined in RFC 2460 has good middlebox Regular UDP: The method defined in RFC 2460 has good middlebox
traversal and load balancing and multiplexing, requiring a traversal and load balancing and multiplexing, requiring a
skipping to change at page 36, line 45 skipping to change at page 39, line 26
for noting these.Group Draft 05. for noting these.Group Draft 05.
Working Group Draft 06 Working Group Draft 06
* Resubmission to keep draft alive (spelling updated from 05). * Resubmission to keep draft alive (spelling updated from 05).
Working Group Draft 07 Working Group Draft 07
* Interim Version * Interim Version
* Submission after IESG Feedback * Submission after IESG Feedback Added
* Updates to enable the document to become a PS Applicability * Updates to enable the document to become a PS Applicability
Statement Statement
Working Group Draft 08 Working Group Draft 08
* First Version written as a PS Applicability Statement * First Version written as a PS Applicability Statement
* Changes to reflect decision to update RFC 2460, rather than * Changes to reflect decision to update RFC 2460, rather than
recommend decision recommend decision
skipping to change at page 37, line 35 skipping to change at page 40, line 12
* Clarified that full checksum is required in security * Clarified that full checksum is required in security
considerations, and therefore noting that full checksum should considerations, and therefore noting that full checksum should
not be treated as an attack - consistent with remainder of not be treated as an attack - consistent with remainder of
document. document.
* Added mention that API can set a mode in transport stack - to * Added mention that API can set a mode in transport stack - to
link to similar statement in RFC 2460 update. link to similar statement in RFC 2460 update.
* Fixed typos. * Fixed typos.
Working Group Draft 08 Working Group Draft 10
* Submission to correct unwanted removal of text from section 5 * Submission to correct unwanted removal of text from section 5
bullets 5-7 by GF. bullets 5-7 by GF.
* Replaced section 5 text with the text from 08, and reapplied * Replaced section 5 text with the text from 08, and reapplied
the editorial correction. the editorial correction.
* Note to reviewers: Please compare this revision with -08 used * Note to reviewers: Please compare this revision with -08 used
in the IETF LC). in the IETF LC).
Working Group Draft 11
* Added REF for 5097 (Noted by S.Turner)
* Added text in response to P. Resnick on place where checksum is
calculated.
* Added text to note experience with MPLS/PWE; Appendix updated
to refer to this (S. Bryant)
* Added text in response to P.Resnick's 2nd comments.
* Request to make UDP-Lite more clearly recommended (J Touch,
P.Resnick)
* Added considerations around usage of zero checksum in routers.
* Added text in response to Stewart Bryant's comments on router
requirements.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
Scotland, UK Scotland, UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry URI: http://www.erg.abdn.ac.uk/users/gorry
 End of changes. 40 change blocks. 
134 lines changed or deleted 330 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/