draft-ietf-6man-udpzero-03.txt   draft-ietf-6man-udpzero-04.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: October 23, 2011 Ericsson Expires: April 27, 2012 Ericsson
April 21, 2011 October 25, 2011
IPv6 UDP Checksum Considerations IPv6 UDP Checksum Considerations
draft-ietf-6man-udpzero-03 draft-ietf-6man-udpzero-04
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 October 23, 2011. This Internet-Draft will expire on April 27, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 6, line 51 skipping to change at page 6, line 51
o Transport payload size (always included in the checksum) o Transport payload size (always included in the checksum)
Transport endpoints also need to verify the correctness of reassembly Transport endpoints also need to verify the correctness of reassembly
of any fragmented datagram. For UDP, this is normally provided as a of any fragmented datagram. For UDP, this is normally provided as a
part of the integrity check. Disabling the IPv4 checksum prevents part of the integrity check. Disabling the IPv4 checksum prevents
this check. A lack of the UDP header and checksum in fragments can this check. A lack of the UDP header and checksum in fragments can
lead to issues in a translator or middlebox. For example, many IPv4 lead to issues in a translator or middlebox. For example, many IPv4
Network Address Translators, NATs, rely on port numbers to find the Network Address Translators, NATs, rely on port numbers to find the
mappings, packet fragments do not carry port numbers, so fragments mappings, packet fragments do not carry port numbers, so fragments
get dropped. RFC2765 [RFC2765] provides some guidance on the get dropped. IP/ICMP Translation Algorithm [RFC6145] provides some
processing of fragmented IPv4 UDP datagrams that do not carry a UDP guidance on the processing of fragmented IPv4 UDP datagrams that do
checksum. not carry a UDP checksum.
IPv4 UDP checksum control is often a kernel-wide configuration IPv4 UDP checksum control is often a kernel-wide configuration
control (e.g. In Linux and BSD), rather than a per socket call. control (e.g. In Linux and BSD), rather than a per socket call.
There are also Networking Interface Cards (NICs) that automatically There are also Networking Interface Cards (NICs) that automatically
calculate TCP [RFC0793] and UDP checksums on transmission when a calculate TCP [RFC0793] and UDP checksums on transmission when a
checksum of zero is sent to the NIC, using a method known as checksum checksum of zero is sent to the NIC, using a method known as checksum
offloading. offloading.
1.2.3. Differences between IPv6 and IPv4 1.2.3. Differences between IPv6 and IPv4
skipping to change at page 8, line 12 skipping to change at page 8, line 12
locations that are distant in the physical Internet topology and can locations that are distant in the physical Internet topology and can
be used to create virtual (private) networks. be used to create virtual (private) networks.
1.3.1. Motivation for new approaches 1.3.1. Motivation for new approaches
A number of tunnel encapsulations deployed over IPv4 have used the A number of tunnel encapsulations deployed over IPv4 have used the
UDP transport with a zero checksum. Users of these protocols expect UDP transport with a zero checksum. Users of these protocols expect
a similar solution for IPv6. a similar solution for IPv6.
A number of tunnel protocols are also currently being defined (e.g. A number of tunnel protocols are also currently being defined (e.g.
Automated Multicast Tunnels, AMT [AMT], and the Locator/Identifier Automated Multicast Tunnels, AMT [I-D.ietf-mboned-auto-multicast],
Separation Protocol, LISP [LISP]). These protocols have proposed an and the Locator/Identifier Separation Protocol, LISP [LISP]). These
update to IPv6 UDP checksum processing. These tunnel protocols could protocols have proposed an update to IPv6 UDP checksum processing.
benefit from simpler checksum processing for various reasons: These tunnel protocols could benefit from simpler checksum processing
for various reasons:
o Reducing forwarding costs, motivated by redundancy present in the o Reducing forwarding costs, motivated by redundancy present in the
encapsulated packet header, since in tunnel encapsulations, encapsulated packet header, since in tunnel encapsulations,
payload integrity and length verification may be provided by payload integrity and length verification may be provided by
higher layer encapsulations (often using the IPv4, UDP, UDP-Lite, higher layer encapsulations (often using the IPv4, UDP, UDP-Lite,
or TCP checksums). or TCP checksums).
o Eliminating a need to access the entire packet when forwarding the o Eliminating a need to access the entire packet when forwarding the
packet by a tunnel endpoint. packet by a tunnel endpoint.
skipping to change at page 8, line 37 skipping to change at page 8, line 38
Address Translators, NATs. Address Translators, NATs.
o A desire to use the port number space to enable load-sharing. o A desire to use the port number space to enable load-sharing.
1.3.2. Reducing forwarding cost 1.3.2. Reducing forwarding cost
It is a common requirement to terminate a large number of tunnels on It is a common requirement to terminate a large number of tunnels on
a single router/host. Processing per tunnel concerns both state a single router/host. Processing per tunnel concerns both state
(memory requirements) and per-packet processing costs. (memory requirements) and per-packet processing costs.
Automatic IP Multicast Without Explicit Tunnels, known as AMT [AMT] Automatic IP Multicast Without Explicit Tunnels, known as AMT
currently specifies UDP as the transport protocol for packets [I-D.ietf-mboned-auto-multicast] currently specifies UDP as the
carrying tunneled IP multicast packets. The current specification transport protocol for packets carrying tunneled IP multicast
for AMT requires that the UDP checksum in the outer packet header packets. The current specification for AMT requires that the UDP
should be 0 (see Section 6.6 of [AMT]). It argues that the checksum in the outer packet header should be 0 (see Section 6.6 of
computation of an additional checksum, when an inner packet is [I-D.ietf-mboned-auto-multicast]). It argues that the computation of
already adequately protected, is an unwarranted burden on nodes an additional checksum, when an inner packet is already adequately
implementing lightweight tunneling protocols. The AMT protocol needs protected, is an unwarranted burden on nodes implementing lightweight
to replicate a multicast packet to each gateway tunnel. In this tunneling protocols. The AMT protocol needs to replicate a multicast
case, the outer IP addresses are different for each tunnel and packet to each gateway tunnel. In this case, the outer IP addresses
therefore require a different pseudo header to be built for each UDP are different for each tunnel and therefore require a different
replicated encapsulation. pseudo header to be built for each UDP replicated encapsulation.
The argument concerning redundant processing costs is valid regarding The argument concerning redundant processing costs is valid regarding
the integrity of a tunneled packet. In some architectures (e.g. PC- the integrity of a tunneled packet. In some architectures (e.g. PC-
based routers), other mechanisms may also significantly reduce based routers), other mechanisms may also significantly reduce
checksum processing costs: There are implementations that have checksum processing costs: There are implementations that have
optimised checksum processing algorithms, including the use of optimised checksum processing algorithms, including the use of
checksum-offloading. This processing is readily available for IPv4 checksum-offloading. This processing is readily available for IPv4
packets at high line rates. Such processing may be anticipated for packets at high line rates. Such processing may be anticipated for
IPv6 endpoints, allowing receivers to reject corrupted packets IPv6 endpoints, allowing receivers to reject corrupted packets
without further processing. However, there are certain classes of without further processing. However, there are certain classes of
skipping to change at page 30, line 40 skipping to change at page 30, line 40
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071, "Computing the Internet checksum", RFC 1071,
September 1988. September 1988.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
10.2. Informative References 10.2. Informative References
[AMT] Internet draft, draft-ietf-mboned-auto-multicast-10,
"Automatic IP Multicast Without Explicit Tunnels (AMT)",
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] [I-D.ietf-6man-udpchecksums]
Eubanks, M., "UDP Checksums for Tunneled Packets", Eubanks, M., "UDP Checksums for Tunneled Packets",
draft-ietf-6man-udpchecksums-00 (work in progress), draft-ietf-6man-udpchecksums-00 (work in progress),
March 2011. 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.
[I-D.ietf-mboned-auto-multicast]
Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L.,
Pusateri, T., and T. Morin, "Automatic IP Multicast
Tunneling", draft-ietf-mboned-auto-multicast-11 (work in
progress), July 2011.
[LISP] D. Farinacci et al, "Locator/ID Separation Protocol [LISP] D. Farinacci et al, "Locator/ID Separation Protocol
(LISP)", March 2009. (LISP)", March 2009.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[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.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. RFC 3819, July 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
skipping to change at page 32, line 10 skipping to change at page 32, line 9
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.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[Sigcomm2000] [Sigcomm2000]
Jonathan Stone and Craig Partridge , "When the CRC and TCP Jonathan Stone and Craig Partridge , "When the CRC and TCP
Checksum Disagree", 2000. Checksum Disagree", 2000.
[UDPTT] G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010. [UDPTT] G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010.
Appendix A. Document Change History Appendix A. Document Change History
{RFC EDITOR NOTE: This section must be deleted prior to publication} {RFC EDITOR NOTE: This section must be deleted prior to publication}
skipping to change at page 33, line 22 skipping to change at page 33, line 28
* 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.
Working Group Draft 03 Working Group Draft 03
* Editorial updates * Editorial updates
Working Group Draft 04
* Resubmission only updating the AMT and RFC2765 references.
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:
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
 End of changes. 11 change blocks. 
30 lines changed or deleted 37 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/