draft-ietf-6man-udpzero-00.txt   draft-ietf-6man-udpzero-01.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: November 9, 2010 Ericsson Research Expires: February 9, 2011 Ericsson Research
May 8, 2010 August 12, 2010
IPv6 UDP Checksum Considerations IPv6 UDP Checksum Considerations
draft-ietf-6man-udpzero-00 draft-ietf-6man-udpzero-01
Abstract Abstract
This document examines the role of the transport checksum when used This document examines the role of the transport checksum when used
with IPv6, as defined in RFC2460. It presents a summary of the 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 to an IPv6 UDP endpoint to use a zero value in the checksum field to
indicate that no checksum is present. The document describes issues indicate that no checksum is present. The document describes issues
and design principles that need to be considered and provides and design principles that need to be considered when UDP is used
with IPv6 to support tunnel encapsulations and provides
recommendations. recommendations.
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 November 9, 2010. This Internet-Draft will expire on February 9, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 2, line 23 skipping to change at page 2, line 24
1.2.1. Motivation for new approaches . . . . . . . . . . . . 5 1.2.1. Motivation for new approaches . . . . . . . . . . . . 5
1.2.2. Reducing forwarding cost . . . . . . . . . . . . . . . 6 1.2.2. Reducing forwarding cost . . . . . . . . . . . . . . . 6
1.2.3. Need to inspect the entire packet . . . . . . . . . . 7 1.2.3. Need to inspect the entire packet . . . . . . . . . . 7
1.2.4. Interactions with middleboxes . . . . . . . . . . . . 7 1.2.4. Interactions with middleboxes . . . . . . . . . . . . 7
1.2.5. Support for load balancing . . . . . . . . . . . . . . 7 1.2.5. Support for load balancing . . . . . . . . . . . . . . 7
2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 8 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 8
2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 8 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 8
2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 8 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 8
2.3. IP in IPv6 Tunnel Encapsulations . . . . . . . . . . . . . 9 2.3. IP in IPv6 Tunnel Encapsulations . . . . . . . . . . . . . 9
3. Evaluation of proposal to update to RFC 2460 to support 3. Evaluation of proposal to update RFC 2460 to support zero
zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 9 checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Alternatives to the Standard Checksum . . . . . . . . . . 10 3.1. Alternatives to the Standard Checksum . . . . . . . . . . 10
3.2. Applicability of method . . . . . . . . . . . . . . . . . 11 3.2. Applicability of method . . . . . . . . . . . . . . . . . 11
3.3. Effect of packet modification in the network . . . . . . . 12 3.3. Effect of packet modification in the network . . . . . . . 12
3.3.1. Corruption of the destination IP address . . . . . . . 12 3.3.1. Corruption of the destination IP address . . . . . . . 12
3.3.2. Corruption of the source IP address . . . . . . . . . 13 3.3.2. Corruption of the source IP address . . . . . . . . . 13
3.3.3. Delivery to an unexpected port . . . . . . . . . . . . 14 3.3.3. Delivery to an unexpected port . . . . . . . . . . . . 14
3.3.4. Validating the network path . . . . . . . . . . . . . 15 3.3.4. Validating the network path . . . . . . . . . . . . . 15
3.4. Comparision . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.5. Requirements on the specification of transported
4. Requirements on the specification of transported protocols . . 16 protocols . . . . . . . . . . . . . . . . . . . . . . 16
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. Comparision . . . . . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 4. Requirements on the specification of transported protocols . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 4.1. Constraints required oin usage of a zero checksum . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
Appendix A. Document Change History . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Document Change History . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The User Datagram Protocol (UDP) transport was defined by RFC768 The User Datagram Protocol (UDP) transport was defined by RFC768
[RFC0768] for IPv4 RFC791 [RFC0791] and is defined in RFC2460 [RFC0768] for IPv4 RFC791 [RFC0791] and is defined in RFC2460
[RFC2460] for IPv6 hosts and routers. A UDP transport endpoint may [RFC2460] for IPv6 hosts and routers. A UDP transport endpoint may
be either a host or a router. The UDP Usage Guidelines [RFC5405] be either a host or a router. The UDP Usage Guidelines [RFC5405]
provides overall guidance for application designers, including the provides overall guidance for application designers, including the
use of UDP to support tunneling. These guidelines are applicable to use of UDP to support tunneling. These guidelines are applicable to
this discussion. this discussion.
skipping to change at page 4, line 16 skipping to change at page 4, line 16
Protocol value corresponding to the UDP transport protocol [RFC1071]. Protocol value corresponding to the UDP transport protocol [RFC1071].
The length field verifies that the datagram is not truncated or The length field verifies that the datagram is not truncated or
padded. The checksum therefore protects an application against padded. The checksum therefore protects an application against
receiving corrupted payload data in place of, or in addition to, the receiving corrupted payload data in place of, or in addition to, the
data that was sent. Although the IPv4 UDP [RFC0768] checksum may be data that was sent. Although the IPv4 UDP [RFC0768] checksum may be
disabled, applications are recommended to enable UDP checksums disabled, applications are recommended to enable UDP checksums
[RFC5405]. [RFC5405].
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 Networking Interface Cards (NICs) that automatically There are also Networking Interface Cards (NICs) that automatically
calculate TCP [RFC0793] and UDP checksums on transmission if 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.
The network-layer fields that are validated by a transport checksum The network-layer fields that are validated by a transport checksum
are: are:
o Endpoint IP source address (always included in the pseudo header o Endpoint IP source address (always included in the pseudo header
of the checksum) of the checksum)
o Endpoint IP destination address (always included in the pseudo o Endpoint IP destination address (always included in the pseudo
header of the checksum) header of the checksum)
o Upper Layer Payload type (always included in the pseudo header of o Upper layer payload type (always included in the pseudo header of
the checksum) the checksum)
o IP length of payload (always included in the pseudo header of the o IP length of payload (always included in the pseudo header of the
checksum) checksum)
o Length of the network layer extension headers (i.e. By correct o Length of the network layer extension headers (i.e. by correct
position of the hecksum bytes) position of the checksum bytes)
The transport-layer fields that are validated by a transport checksum The transport-layer fields that are validated by a transport checksum
are: are:
o Transport demultiplexing, i.e. ports (always included in the o Transport demultiplexing, i.e. ports (always included in the
checksum) checksum)
o Transport payload size (always included in 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 (unless the application using the payload of any fragmented datagram (unless the application using the payload
is corruption tolerant, as indicated by UDP-Lite's checksum coverage is corruption tolerant, as indicated by UDP-Lite's checksum coverage
field). For UDP, this is normally provided as a part of the field). For UDP, this is normally provided as a part of the
integrity check. Disabling the IPv4 checksum prevents this check. A integrity check. Disabling the IPv4 checksum prevents this check. A
lack of checksum can lead to issues in a translator or middlebox lack of checksum can lead to issues in a translator or middlebox
(e.g. Many IPv4 Network Address Translators, NATs, rely on port (e.g. Many IPv4 Network Address Translators, NATs, rely on port
numbers to find the mappings, packet fragments do not carry port numbers to find the mappings, packet fragments do not carry port
numbers, so fragments get dropped). RFC2765 [RFC2765] provides some numbers, so fragments get dropped). RFC2765 [RFC2765] provides some
guidance on the processing of fragmented IPv4 UDP datagrams that do guidance on the processing of fragmented IPv4 UDP datagrams that do
not carry a UDP checksum. not carry a UDP checksum.
IPv6 does not provide a network-layer integrity check. The removal IPv6 does not provide a network-layer integrity check. The removal
of the header checksum from the IPv6 specification released routers of the header checksum from the IPv6 specification released routers
from a need to update a network-layer checksum for each router hop as from a need to update a network-layer checksum for each router hop as
the IPv6 Hop Count is changed (comapraed to the checksum update the IPv6 Hop Count is changed (in contrast to the checksum update
needed when an IPv4 router modifies the Time-To-Live (TTL)). needed when an IPv4 router modifies the Time-To-Live (TTL)).
The IP header checksum calculation was seen as redundant for most The IP header checksum calculation was seen as redundant for most
traffic (with UDP or TCP checksums enabled), and people wanted to traffic (with UDP or TCP checksums enabled), and people wanted to
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 would lessen the protection removal of the IP header checksum in IPv6 would lessen the protection
of the source/destination IP addresses and result in a significant (a of the source/destination IP addresses and result in a significant (a
multiplier of ~32,000) increase in the number of times that a UDP multiplier of ~32,000) increase in the number of times that a UDP
packet was accidentally delivered to the wrong destination address packet was accidentally delivered to the wrong destination address
and/or apparently sourced from the wrong source address when the UDP and/or apparently sourced from the wrong source address when the UDP
checksum was set to zero. This would have had implications on the checksum was set to zero. This would have had implications on the
detectability of mis-delivery of a packet to an incorrect endpoint/ detectability of mis-delivery of a packet to an incorrect endpoint/
socket, and the robustness of the Internet infrastructure. The use socket, and the robustness of the Internet infrastructure. The use
of the UDP checksum is therefore required[RFC2460] when applications of the UDP checksum is therefore required [RFC2460] when endpoint
transmit UDP datagrams over IPv6. application s transmit UDP datagrams over IPv6.
1.2. Use of UDP Tunnels 1.2. 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
use, the receiving endpoint decapsulates the UDP datagrams and use, the receiving endpoint decapsulates the UDP datagrams and
forwards the original packets contained in the payload [RFC5405]. forwards the original packets contained in the payload [RFC5405].
Tunnels establish virtual links that appear to directly connect Tunnels establish virtual links that appear to directly connect
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.2.1. Motivation for new approaches 1.2.1. Motivation for new approaches
A number of tunnel encapsulations deployed over IPv4 have used the
UDP transport with a zero checksum. Users of these protocols expect
a similar solution for IPv6.
A number of tunnel protocols are currently being defined (e.g. A number of tunnel protocols are currently being defined (e.g.
Automated Multicast Tunnels, AMT [AMT], and the Locator/Identifier Automated Multicast Tunnels, AMT [AMT], and the Locator/Identifier
Separation Protocol, LISP [LISP]). These protocols have proposed an Separation Protocol, LISP [LISP]). These protocols have proposed an
update to IPv6 UDP checksum processing. These tunnel protocols could update to IPv6 UDP checksum processing. These tunnel protocols could
benefit from simpler checksum processing for various reasons: 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).
skipping to change at page 6, line 12 skipping to change at page 6, line 17
update to IPv6 UDP checksum processing. These tunnel protocols could update to IPv6 UDP checksum processing. These tunnel protocols could
benefit from simpler checksum processing for various reasons: 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. 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.
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.2.2. Reducing forwarding cost 1.2.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 costs per tunnel concern both state a single router/host. Processing per tunnel concerns both state
(memory requirements) and 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 tunneled currently specifies UDP as the transport protocol for packets
packets carrying tunneled IP multicast packets. The current carrying tunneled IP multicast packets. The current specification
specification for AMT requires that the UDP checksum in the outer for AMT requires that the UDP checksum in the outer packet header
packet header should be 0 (see Section 6.6). It argues that the should be 0 (see Section 6.6). It argues that the computation of an
computation of an additional checksum, when an inner packet is additional checksum, when an inner packet is already adequately
already adequately protected, is an unwarranted burden on nodes protected, is an unwarranted burden on nodes implementing lightweight
implementing lightweight tunneling protocols. The AMT protocol needs tunneling protocols. The AMT protocol needs to replicate a multicast
to replicate a multicast packet to each gateway tunnel. In this packet to each gateway tunnel. In this case, the outer IP addresses
case, the outer IP addresses are different for each tunnel and are different for each tunnel and therefore require a different
therefore require a different pseudo header to be built for each UDP pseudo header to be built for each UDP replicated encapsulation.
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 them to reject corrupted packets without IPv6 endpoints, allowing receivers to reject corrupted packets
further processing. Relaxing RFC 2460 to minimise the processing without further processing. Relaxing RFC 2460 to minimise the
impact for existing hardware is a transition policy decision, which processing impact for existing hardware is a transition policy
seems undesirable if at the same time it yields a solution that may decision, which seems undesirable if at the same time it yields a
reduce stability and functionality in future network scenarios. solution that may reduce stability and functionality in future
network scenarios.
1.2.3. Need to inspect the entire packet 1.2.3. Need to inspect the entire packet
The currently-deployed hardware in many routers uses a fast-path The currently-deployed hardware in many routers uses a fast-path
processing that only provides the first n bytes of a packet to the processing that only provides the first n bytes of a packet to the
forwarding engine, where typically n < 128. This prevents fast forwarding engine, where typically n < 128. This prevents fast
processing of a transport checksum over an entire (large) packet. processing of a transport checksum over an entire (large) packet.
Hence the currently defined IPv6 UDP checksum is poorly suited to use Hence the currently defined IPv6 UDP checksum is poorly suited to use
within a router that is unable to access the entire packet and does within a router that is unable to access the entire packet and does
not provide checksum-offloading. not provide checksum-offloading.
1.2.4. Interactions with middleboxes 1.2.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. UDP support is commonly provided.
IPv6 NAT traversal does not necessarily present the same protocol IPv6 NAT traversal does not necessarily present the same protocol
issues as for IPv4. It is not clear that NATs will work the same way issues as for IPv4. It is not clear that NATs will work the same way
for IPv6. Any change to RFC 2460 is going to require rewriting (or for IPv6. Any change to RFC 2460 would also require rewriting (or
defining) IPv6 NAT behaviour to achieve consistent widescale defining) IPv6 NAT behaviour to achieve consistent widescale
deployment. deployment.
The requirements for IPv6 firewall traversal are likely be to be The requirements for IPv6 firewall traversal are likely be to be
similar to those for IPv4. In addition, it can be reasonably similar to those for IPv4. In addition, it can be reasonably
expected that a firewall conforming to RFC 2460 will not regard UDP expected that a firewall conforming to RFC 2460 will not regard UDP
datagrams with a zero checksum as valid packets, and if such a mode datagrams with a zero checksum as valid packets. If an updated IPv6
were to be defined for IPv6, this may also need to be updated. mode were to be defined for IPv6, this may also need firewalla to be
updated.
Key questions in this space include: Key questions in this space include:
o What types of middleboxes does the protocol need to cross o What do IPv6 routers do today with zero-checksum UDP packets?
o What types of middleboxes does the tunnel protocol need to cross
(routers, NAT boxes, firewalls, etc.), and how will those (routers, NAT boxes, firewalls, etc.), and how will those
middleboxes deal with these packets? middleboxes deal with these packets?
o What do IPv6 routers do today with zero-checksum UDP packets?
o What other IPv6 middleboxes exist today, and what would they do? o What other IPv6 middleboxes exist today, and what would they do?
1.2.5. Support for load balancing 1.2.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 could also be leveraged balancing solutions for IPv4. This approach could also be leveraged
for IPv6. However, support for extension headers would increase the for IPv6. However, support for extension headers would increase the
complexity of providing standards-compliant solutions for IPv6. complexity of providing standards-compliant solutions for IPv6.
An alternate method could utilise the IPv6 Flow Label to perform load An alternate method could utilise the IPv6 Flow Label to perform load
balancing. This would release IPv6 load-balancing devices from the balancing. This would release IPv6 load-balancing devices from the
need to assume semantics for the use of the transport port field. need to assume semantics for the use of the transport port field.
This use of the flow-label is consistent with the intended use, This use of the flow-label is consistent with the intended use,
although further clarity may be needed to ensure the field can be although further clarity may be needed to ensure the field can be
consistently used for this purpose, (e.g. ECMP [ECMP]). Router consistently used for this purpose, (e.g. Equal-Cost Multi-Path
vendors could be encouraged to start using the IPv6 Flow Label as a routing, ECMP [ECMP]). Router vendors could be encouraged to start
part of the flow hash. using the IPv6 Flow Label as a part of the flow hash, providing
support for ECMP without requiring use of UDP.
2. Standards-Track Transports 2. Standards-Track Transports
The IETF has defined a set of IPv6 transports that at be used with
IPv6. These are described in the following sections, followed by a
description of standards tunnel encapsulations.
2.1. UDP with Standard Checksum 2.1. UDP with Standard Checksum
UDP with standard checksum behaviour is defined in RFC 2460, and UDP with standard checksum behaviour is defined in RFC 2460, and
should be the default choice. Guidelines are provided in [RFC5405]. should be the default choice. Guidelines are provided in [RFC5405].
2.2. UDP-Lite 2.2. UDP-Lite
UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as
a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and
unicast usage guidelines in [RFC5405]. UDP-Lite has been unicast usage guidelines in [RFC5405].
implemented, e.g. as a part of the Linux kernel since version 2.6.20.
UDP-Lite provides a checksum with an optional partial coverage. When UDP-Lite provides a checksum with an 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). Errors/corruption in the insensitive part will not cause checksum). Errors/corruption in the insensitive part will not cause
the datagram to be discarded by the transport layer at the receiving the datagram to be discarded by the transport layer at the receiving
host. A minor side-effect of using UDP-Lite is that this was endpoint. A minor side-effect of using UDP-Lite is that this was
specified for damage-tolerant payloads, and some link-layers may specified for damage-tolerant payloads, and some link-layers may
employ different link encapsulations when forwarding UDP-Lite employ different link encapsulations when forwarding UDP-Lite
segments (e.g. Over radio access bearers). When the checksum covers segments (e.g. Over radio access bearers). When the checksum covers
the entire packet, which should be the default, UDP-Lite is the entire packet, which should be the default.
semantically identical to UDP and is specified for use with IPv4 and
IPv6. It uses an IP protocol type (or IPv6 next header) with a value
of 136 decimal. This value is different to that used by UDP.
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), since UDP-Lite Provisioning of Wireless Access Points, CAPWAP), since UDP-Lite
provides a transport-layer checksum, including an IP pseudo header provides a transport-layer checksum, including an IP pseudo header
checksum, in IPv6, without the need for a router/middelbox to checksum, in IPv6, without the need for a router/middelbox to
traverse the entire packet payload. traverse the entire packet payload.
In the LISP case, the bytes that would need to be "checksummed" for In the LISP case, the bytes that would need to be "checksummed" for
skipping to change at page 9, line 28 skipping to change at page 9, line 33
with other application data that could result in corruption of with other application data that could result in corruption of
application state or data. application state or data.
From the end-to-end perspective, the principal difference is that the From the end-to-end perspective, the principal difference is that the
network-layer Next Header field identifies a separate transport, network-layer Next Header field identifies a separate transport,
which reduces the probability that corruption could result in the which reduces the probability that corruption could result in the
packet being delivered to the wrong endpoint or application. packet being delivered to the wrong endpoint or application.
Specifically, packets are only delivered to protocol modules that Specifically, packets are only delivered to protocol modules that
process a specific next header value. The next header field process a specific next header value. The next header field
therefore provides a first-level check of correct demultiplexing. In therefore provides a first-level check of correct demultiplexing. In
contrast, the UDP port space is shared by many diverse application contrast, the UDP port space is shared by many diverse applications
and therefore UDP demultiplexing relies solely on the port numbers. and therefore UDP demultiplexing relies solely on the port numbers.
3. Evaluation of proposal to update to RFC 2460 to support zero 3. Evaluation of proposal to update RFC 2460 to support zero checksum
checksum
This section evaluates a proposal to update IPv6 [RFC2460], to This section evaluates a proposal to update IPv6 [RFC2460], to
provide the option that some nodes may suppress generation and provide the option that some nodes may suppress generation and
checking of the UDP transport checksum. The decision to omit an checking of the UDP transport checksum. The decision to omit an
integrity check at the IPv6 level means that the transport check is integrity check at the IPv6 level means that the transport check is
overloaded with many functions including validating: overloaded with many functions including validating:
o the endpoint address was not corrupted within a router - i.e. o the endpoint address was not corrupted within a router - i.e.
This packet was intended to be received by this destination and a This packet was intended to be received by this destination and a
wrong header has not been spliced to a different payload. wrong header has not been spliced to a different payload;
o the extension header processing is correctly delimited - i.e. The o that extension header processing is correctly delimited - i.e.
start of data has not been corrupted. The protocol type field The start of data has not been corrupted. In this case, reception
also provides some protection. of a valid next header value provides some protection;
o reassembly processing, when used. o reassembly processing, when used;
o the length of the payload. o the length of the payload;
o the port values - i.e. The correct application gets the payload o the port values - i.e. The correct application receives the
(applications should also check the expecetd use of source ports/ payload (applications should also check the expected use of source
addresses). ports/addresses);
o the payload integrity. o the payload integrity.
In IPv4, the first 4 checks are performed using the IPv4 header In IPv4, the first four checks are performed using the IPv4 header
checksum. checksum.
In IPv6, these checks occur within the endpoint stack using the UDP In IPv6, these checks occur within the endpoint stack using the UDP
checksum information. An IPv6 node also relies on the header checksum information. An IPv6 node also relies on the header
information to determine whether to send an ICMPv6 error message and information to determine whether to send an ICMPv6 error message
to determine the node to which this is sent. Corrupted information [RFC2463] and to determine the node to which this is sent. Corrupted
may lead to misdelivery to an unintended application socket on an information may lead to misdelivery to an unintended application
unexpected host. socket on an unexpected host.
3.1. Alternatives to the Standard Checksum 3.1. Alternatives to the Standard Checksum
There are several alternatives to the normal method for calculating There are several alternatives to the normal method for calculating
the UDP Checksum that do not require a tunnel endpoint to inspect the the UDP Checksum that do not require a tunnel endpoint to inspect the
entire packet when computing a checksum. These include (in entire packet when computing a checksum. These include (in
decreasing complexity): decreasing order of complexity):
o Delta computation of the checksum from an encapsulated checksum o Delta computation of the checksum from an encapsulated checksum
field. Since the checksum is a cumulative sum (RFC 1624), an field. Since the checksum is a cumulative sum (RFC 1624), an
encapsulating header checksum can be derived from the new pseudo encapsulating header checksum can be derived from the new pseudo
header, the inner checksum and the sum of the other network-layer header, the inner checksum and the sum of the other network-layer
fields not included in the pseudo header of the encapsulated fields not included in the pseudo header of the encapsulated
packet, in maaner resembling incremental checksum update packet, in a manner resembling incremental checksum update
[RFC1141]. This would not require access to the whole packet, but [RFC1141]. This would not require access to the whole packet, but
does require fields to be collected across the header, and does require fields to be collected across the header, and
arithmetic operations on each packet. The method would only work arithmetic operations on each packet. The method would only work
for packets that contain a 2's complement transport checksum (i.e. for packets that contain a 2's complement transport checksum (i.e.
it would not be appropriate for SCTP or when IP fragmentation is it would not be appropriate for SCTP or when IP fragmentation is
used). The process may be easier for IPv4 over IPv6 used). The process may be easier for IPv4 over IPv6
encapsulation, where the encapsulated IPv4 header checksum could encapsulation, where the encapsulated IPv4 header checksum could
be used as a basis. be used as a basis.
o UDP-Lite. Where the checksum coverage may be set to only the o UDP-Lite with the checksum coverage set to only the header portion
header portion of a packet. This requires a pseudo header of a packet. This requires a pseudo header checksum calculation
checksum calculation only on the encapsulating packet header, only on the encapsulating packet header. The computed checksum
which includes extracting the UDP payload length for the pseudo value may be cached (before adding the Length field) for each
header, however this is expected to be also known when performing flow/destination and subsequently combined with the Length of each
packet forwarding. The value may be cached per flow/destination packet to minimise per-packet processing. This value is combined
and subsequently combined only with the Length field to minimise with the UDP payload length for the pseudo header, however this
per-packet processing. length is expected to be known when performing packet forwarding.
o The proposed UDP Tunnel Transport, UDPTT [UDPTT] proposed a method o The proposed UDP Tunnel Transport, UDPTT [UDPTT] suggested a
where UDP is modified to derive the checksum only from the method where UDP would be modified to derive the checksum only
encapsulating packet protocol header. This value does not change from the encapsulating packet protocol header. This value does
between packets in a flow. The value may be cached per flow/ not change between packets in a flow. The value may be cached per
destination to minimise per-packet processing. This proposal is flow/destination to minimise per-packet processing. This proposal
not discussed further in this document. is not discussed further in this document, since function is
nearly the same as for UDP-Lite.
o Use of a new IPv6 Extension Header that provides an end-to-end o Use of a new IPv6 Extension Header that provides an end-to-end
validation check at the network layer. This would allow an validation check at the network layer. This would allow an
endpoint to verfiy delivery to an appropriate end point, but would endpoint to verify delivery to an appropriate end point, but would
also require IPv6 nodes to correctly handle the additional header. also require IPv6 nodes to correctly handle the additional header.
o UDP modified to disable checksum processing[UDPZ] (if progressed). o UDP modified to disable checksum processing[UDPZ] (if progressed).
This requires no checksum calculation. This requires no checksum calculation, but would require
constraints on appropriate usage.
These options are discussed further in later sections. These options are discussed further in the following sections.
3.2. Applicability of method 3.2. Applicability of method
The expectation of the present proposal to permit omission of UDP The expectation of the present proposal defined in [UDPZ] is that
checksums [UDPZ] is that this would apply only to IPv6 router nodes this change would only apply to IPv6 router nodes that implement
that implement specific protocols. However, the distinction between specific protocols which permit omission of UDP checksums. However,
a router and a host is not always clear, especially at the transport the distinction between a router and a host is not always clear,
level. Systems (such as unix-based operating systems) routinely especially at the transport level. Systems (such as unix-based
provide both functions. There is also no way to identify the role of operating systems) routinely provide both functions. There is also
a receiver from a received packet. 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.
There are additional requirements, e.g. fragmentation must not be There are additional requirements, e.g. fragmentation must not be
performed, since correct reassembly can not be verified at the performed, since correct reassembly can not be verified at the
receiver when there is no checksum. Allowing fragmentation would receiver when there is no checksum. Allowing fragmentation would
also open the receiver to a wide range of mis-behaviours. also open the receiver to a wide range of mis-behaviours. Host-based
fragmentation must therefore be disabled. Policing this, and
ensuring correct interactions with the stack, implies much more than
simply disabling the checksum algorithm for specific packets at the
transport interface.
Host-based fragmentation must therefore be dsiabled. Policing this There are also proposals to simply ignore a specific received UDP
and ensuring correct interactions with the stack implies much more checksum value, however this also can result in problems (e.g. when
than simply disabling the checksum algorithm for specific packets at used with a NAT that always adjusts the checksum value).
the transport interface. There are also proposals to simply ignore a
specific received UDP checksum value, however this also can result in
problems (e.g. when used with a NAT that always adjusts the checksum
value).
The IETF should carefully consider constraints on sanctioning the use The IETF should carefully consider constraints on sanctioning the use
of this mode. If this is specified and widely available, it may be of any new transport mode. If this is specified and widely
expected to be used by applications that are perceived to gain available, it may be expected to be used by applications that are
benefit. Any solution that uses an end-to-end transport protocol, perceived to gain benefit. Any solution that uses an end-to-end
rather than an IP in IP encapsulation, also needs to minimise the transport protocol, rather than an IP in IP encapsulation, also needs
possibility that end-hosts could confuse a corrupted or wrongly to minimise the possibility that end-hosts could confuse a corrupted
delivered packet with that of data addressed to an application or wrongly delivered packet with that of data addressed to an
running on their endpoint. application running on their endpoint.
3.3. Effect of packet modification in the network 3.3. Effect of packet modification in the network
IP packets may be corrupted as they traverse an Internet path. IP packets may be corrupted as they traverse an Internet path.
Evidence has been presented [Sigcomm2000] to show that this was once Evidence has been presented [Sigcomm2000] to show that this was once
an issue with IPv4 routers, and occasional corruption could result an issue with IPv4 routers, and occasional corruption could result
from bad internal router processing in routers or hosts. These from bad internal router processing in routers or hosts. These
errors are not detected by the strong frame checksums employed at the errors are not detected by the strong frame checksums employed at the
link-layer (RFC 3819). There is no current evidence that such cases link-layer (RFC 3819). There is no current evidence that such cases
are rare in the modern Internet, nor that they may not be applicable are rare in the modern Internet, nor that they may not be applicable
skipping to change at page 12, line 35 skipping to change at page 12, line 40
to be discarded. to be discarded.
o A datagram payload being corrupted, but still delivered to the o A datagram payload being corrupted, but still delivered to the
intended host/router transport entity. Such a datagram needs to intended host/router transport entity. Such a datagram needs to
be either discarded or correctly processed by an application that be either discarded or correctly processed by an application that
provides its own integrity checks. provides its own integrity checks.
o A datagram payload being truncated by corruption of the length o A datagram payload being truncated by corruption of the length
field. Such a datagram needs to be discarded. field. Such a datagram needs to be discarded.
When a checksum is used with UDP/IPv6, this significantly reduces the When a checksum is used with UDP over IPv6, this significantly
impact of errors, reducing the probability of undetected corruption reduces the impact of errors, reducing the probability of undetected
of state (and data) on both the host stack and the applications using corruption of state (and data) on both the host stack and the
the transport service. applications using the transport service.
The following sections examine the impact of modifying each of these
header fields.
3.3.1. Corruption of the destination IP address 3.3.1. Corruption of the destination IP address
An IP endpoint destination address could be modified in the network An IP 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 when using IPv6. network can not be detected when using IPv6.
There are two possible outcomes: There are two possible outcomes:
skipping to change at page 13, line 20 skipping to change at page 13, line 25
silent discard. Without this checksum, the packet would be passed silent discard. Without this checksum, the packet would be passed
to the endpoint port demultiplexing function. If an application to the endpoint port demultiplexing function. If an application
is bound to the associated ports, the packet payload will be is bound to the associated ports, the packet payload will be
passed to the application (see the subsequent section on port passed to the application (see the subsequent section on port
processing). processing).
3.3.2. Corruption of the source IP address 3.3.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 result in this packet being discarded by the header checksum will normally result in this packet being discarded
receiving IP stack). by the receiving IP stack).
Corruption of an IPv6 source address does not result in the IP packet Corruption of an IPv6 source address does not result in the IP packet
being delivered to a different endpoint protocol or destination being delivered to a different endpoint protocol or destination
address. If only the source address is corrupted, the datagram will address. If only the source address is corrupted, the datagram will
likely be processed in the intended context, although with erroneous likely be processed in the intended context, although with erroneous
origin information. The result will depend on the application or origin information. The result will depend on the application or
protocol that processes the packet. Some examples are: protocol that processes the packet. Some examples are:
o An application that requires pre-established context may disregard o An application that requires a per-established context may
the datagram as invalid, or could map this to another context (if disregard the datagram as invalid, or could map this to another
a context for the modified source address was already activated). context (if a context for the modified source address was already
activated).
o A stateless application will process the datagram outside of any o A stateless application will process the datagram outside of any
context, a simple example is the ECHO server, which will respond context, a simple example is the ECHO server, which will respond
with a datagram directed to the modified source address. This with a datagram directed to the modified source address. This
would create unwanted additional processing load, and generate would create unwanted additional processing load, and generate
traffic to the modified endpoint address. traffic to the modified endpoint address.
o Some applications build state using the information from packet o Some datagram applications build state using the information from
headers. A previously unused source address would result in packet headers. A previously unused source address would result
receiver processing and the creation of unnecessary transport- in receiver processing and the creation of unnecessary transport-
layer state at the receiver. For example, RTP flows commonly layer state at the receiver. For example, Real Time Prottocol
employ a source independent receiver port. State is created for (RTP) flows commonly employ a source independent receiver port.
each received flow. Reception of a datagram with a corrupted State is created for each received flow. Reception of a datagram
source address will therefore result in accumulation of with a corrupted source address will therefore result in
unnecessary state in the RTP state machine, including collision accumulation of unnecessary state in the RTP state machine,
detection and response (since the same synchronization source, including collision detection and response (since the same
SSRC, value will appear to arrive from multiple source IP synchronization source, SSRC, value will appear to arrive from
addresses). 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
endpoint, the tunnel application is expected to correctly handle a endpoint, the tunnel application is expected to correctly handle a
corrupted source address. corrupted source address.
The impact of source address modification is more difficult to The impact of source address modification is more difficult to
quantify when the receiving application is not that originally quantify when the receiving application is not that originally
intended and several fields have been modified in transit. intended and several fields have been modified in transit.
skipping to change at page 14, line 43 skipping to change at page 15, line 4
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 source address and the destination port of the
datagram (the source port is not always used in UDP) match those of datagram (the source port is not always used in UDP) match those of
an existing connection. Unfortunately, such a match may be more an existing connection. Unfortunately, such a match may be more
likely for UDP than for connection-oriented transports, because 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 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. they receive (guidance on this topic is provided in [RFC5405]).
While these ruled could be revised to declare naive applications as While these rules could in principle be revised to declare naive
Historic.This remedy is not realistic - the transport owes it to the applications as "Historic". This remedy is not realistic: the
stack to do its best to reject bogus datagrams. transport owes it to the stack to do its best to reject bogus
datagrams.
If checksum coverage is suppressed, the application needs to provide If checksum coverage is suppressed, the application therefore needs
a method to detect and discard the unwanted data. The encapsulated to provide a method to detect and discard the unwanted data. The
tunnel protocol would need to perform its own integrity checks on any encapsulated tunnel protocol would need to perform its own integrity
control information and ensure an integrity check is applied to the checks on any control information and ensure an integrity check is
tunneled packet. It is not reasonable to assume that it is safe for applied to the tunneled packet. It is not reasonable to assume that
one application to use a zero checksum value and that other it is safe for one application to use a zero checksum value and that
applications will not. It is therefore important to consider the other applications will not. It is therefore important to consider
possibility that a packet will be received by a different node to the possibility that a packet will be received by a different node to
that for which it was intended, or that it will arrive at the correct that for which it was intended, or that it will arrive at the correct
tunnel destination with the wrong source address in the external tunnel destination with the wrong source address in the external
header. header.
3.3.4. Validating the network path 3.3.4. Validating the network path
IP transports designed for use in the general Internet should not IP transports designed for use in the general Internet should not
assume specific characteristics. Network protocols may reroute assume specific characteristics. Network protocols may reroute
packets and change the set of routers and middleboxes along a path. packets and change the set of routers and middleboxes along a path.
Therefore transports such as TCP, SCTP and DCCP are designed to Therefore transports such as TCP, SCTP and DCCP are designed to
negotiate protocol parameters, adapt to different characteristics, negotiate protocol parameters, adapt to different network path
and receive feedback that the current path is suited to the intended characteristics, and receive feedback that the current path is suited
application. Applications using UDP and UDP-Lite need to provide to the intended application. Applications using UDP and UDP-Lite
their own mechanisms to confirm the validity of the current network need to provide their own mechanisms to confirm the validity of the
path. current network path.
Any application/tunnel that seeks to make use of zero checksum must Any application/tunnel that seeks to make use of zero checksum must
include functionality to both negotiate and verify that the zero include functionality to both negotiate and verify that the zero
checksum support is provided by the path and validate that this checksum support is provided by the path and validate that this
continues to work (e.g., in the case of re-routing events) between continues to work (e.g., in the case of re-routing events) between
the intended parties. This increases the complexity of using such a the intended parties. This increases the complexity of using such a
solution. solution.
3.3.5. Requirements on the specification of transported protocols
If the IETF were to revise the standard for UDP using IPv6 for
specific use-cases there are a set of questions that would need to be
answered. These include:
Is there a reason why IP in IP is not a reasonable choice for
encapsulation?
o Examples of arguments for requiring an encapsulation beyond
IP-in-IP include the need for NAT traversal and/or firewall
traversal. However, the use of any new or non-standard transport
protocol or variant would additionally require specific support in
middleboxes.
o Another example is a need to perform port-demultiplexing (e.g. for
load balancing or ECMP). This need could also be met using UDP,
UDP-Lite, or another supported transport, or by utilising the IPv6
flow label.
Is there a reason why UDP-Lite is not a reasonable choice for
encapsulation?
o One argument against using UDP-Lite is that this transport is not
implemented on all endpoints. However, there is at least one open
source implementation as a part of the Linux kernel since version
2.6.20.
o Another argument against using UDP-Lite is that it uses a
different IPv6 Next Header, which is currently not widely
supported in middleboxes.
o It has also been argued that UDP-Lite requires a checksum
computation. The UDP-Lite checksum, for instance includes the
length field, but need not include the UDP-Lite payload, and
therefore would not require access to the full datagram payload by
the tunnel endpoints.
If the IETF needs to revise the rationale for UDP checksums in RFC
2460, should we remove the checksum or replace it with one closer to
UDP-Lite ?
Additional topics to be considered in making this decision:
o In IPv6, a node selects the role of a router or host is selected
on a per interface basis. The role of a router and host are
therefore not fixed, and a consistent method must be specified
that can be used on all nodes. It can not be assumed that a
particular protocol (or transport mode) will only be used on a
specific type of network node (e.g. permitting the UDP checksum to
be disabled only on a router). It is important to note that
protocol changes intended for one specific use are often re-used
for different applications.
o Behaviour of NAT/Middleboxes may need to be updated. This is the
case for a zero UDP checksum and also for use of an IPv6 Extension
Header carrying a transport checksum.
o The method needs to consider the impact of load balancing, and
whether this may be enabled for the chosen transport protocol.
If a zero checksum approach were to be adopted by the IETF, the
specification should consider adding the following constraints on
usage:
1. IPv6 protocol stack implementations should not by default allow
the new method. The default node behaviour must discard all IPv6
packets carrying UDP packets with no checksum. RFC 2460
specifies that IPv6 nodes should log discarded packets.
2. A method must be specified to verify the integrity of the inner
(tunneled) packet for each tunnel application that uses a zero-
checksum. This method must be robust to the use of other
applications that also use a zero-checksum.
3. Non-IP inner (tunneled) packets must have a CRC or other
mechanism for checking packet integrity.
4. If a method proposes selective ignoring of the checksum on
reception, it needs to provide guidance that is appropriate for
all use-cases, including defining how currently standardised
nodes handle any new use.
5. The tunneling protocol must not allow fragmentation of the inner
packets being carried. We suggest the following elaborations of
the above restrictions, if a change in the IPv6 specification
moves forward, the tunnel must not forward an inner (tunneled)
IPv4 packet that also has a UDP checksum equal to 0. This
includes not tunneling other tunneling protocols that also use a
UDP checksum equal to 0, even if more deeply encapsulated packets
have checksums or other integrity checking mechanisms.
6. If a method proposes recursive tunnels, it needs to provide
guidance that is appropriate for all use-cases. Restrictions may
be needed to the use of a tunnel encapsulations and the use of
recursive tunnels (e.g. Necessary when the endpoint is not
verified).
7.
8. The new method should remain restricted to endpoints that
explicitly enable this mode and adopt the above procedures.
3.4. Comparision 3.4. Comparision
This section compares different methods to support datagram This section compares different methods to support datagram
tunneling. This includes a proposal for updating the behaviour of tunneling. This includes a proposal for updating the behaviour of
UDP. This is provided as an example, and does not seek to endorse UDP. This is provided as an example, and does not seek to endorse
any specific method or suggest that these proposals are ready to be any specific method or suggest that these proposals are ready to be
standardised. The final column the expected functions if an standardised. The final column the expected functions if an
additional end-to-end IPv6 extension header were to be required in additional end-to-end IPv6 extension header were to be required in
combination with use of the zero checksum option. combination with use of the zero checksum option.
skipping to change at page 16, line 41 skipping to change at page 19, line 11
If the IETF were to revise the standard for UDP using IPv6 for If the IETF were to revise the standard for UDP using IPv6 for
specific use-cases there are a set of questions that would need to be specific use-cases there are a set of questions that would need to be
answered. These include: answered. These include:
Is there a reason why IP in IP is not a reasonable choice for Is there a reason why IP in IP is not a reasonable choice for
encapsulation? encapsulation?
o Examples of arguments for requiring an encapsulation beyond o Examples of arguments for requiring an encapsulation beyond
IP-in-IP include the need for NAT traversal and/or firewall IP-in-IP include the need for NAT traversal and/or firewall
traversal. However, the use of any new or non-standard transport traversal. However, the use of any new or non-standard transport
protocol or variant would require specific support in middleboxes. protocol or variant would additionally require specific support in
middleboxes.
o Another example is a need to perform port-demultiplexing (e.g. for o Another example is a need to perform port-demultiplexing (e.g. for
load balancing). This need could also be met using UDP, UDP-Lite, load balancing or ECMP). This need could also be met using UDP,
or another supported transport, or by utilising the IPv6 flow UDP-Lite, or another supported transport, or by utilising the IPv6
label. flow label.
Is there a reason why UDP-Lite is not a reasonable choice for Is there a reason why UDP-Lite is not a reasonable choice for
encapsulation? encapsulation?
o One argument against using UDP-Lite is that this transport is not o One argument against using UDP-Lite is that this transport is not
implemented on all endpoints. However, there is at least one open implemented on all endpoints. However, there is at least one open
source implementation. source implementation as a part of the Linux kernel since version
2.6.20.
o Another argument against using UDP-Lite is that it uses a o Another argument against using UDP-Lite is that it uses a
different IPv6 Next Header, which is currently not widely different IPv6 Next Header, which is currently not widely
supported in middleboxes (see previous). supported in middleboxes.
o It has also been argued that UDP-Lite requires a checksum o It has also been argued that UDP-Lite requires a checksum
computation. The UDP-Lite checksum, for instance includes the computation. The UDP-Lite checksum, for instance includes the
length field, but need not include the UDP-Lite payload, and length field, but need not include the UDP-Lite payload, and
therefore would not require access to the full datagram payload by therefore would not require access to the full datagram payload by
the tunnel endpoints. the tunnel endpoints.
If the IETF needs to revise the rationale for UDP checksums in RFC If the IETF needs to revise the rationale for UDP checksums in RFC
2460, should we remove the checksum or replace it with one closer to 2460, should we remove the checksum or replace it with one closer to
UDP-Lite ? UDP-Lite ?
Additional topics to be considered in making this decision: Additional topics to be considered in making this decision:
o The role of a router and host are not fixed, and a consistent o In IPv6, a node selects the role of a router or host is selected
method must be specified that can be used on all nodes. In IPv6, on a per interface basis. The role of a router and host are
a node selects the role of a router or host on a per interface therefore not fixed, and a consistent method must be specified
basis. It can not be assumed that a particular protocol (or that can be used on all nodes. It can not be assumed that a
transport mode) will only be used on a specific type of network particular protocol (or transport mode) will only be used on a
node (e.g. permitting the UDP checksum to be disabled only on a specific type of network node (e.g. permitting the UDP checksum to
router). It is important to note that protocol changes intended be disabled only on a router). It is important to note that
for one specific use are often re-used for different applications. protocol changes intended for one specific use are often re-used
for different applications.
o Behaviour of NAT/Middleboxes may need to be updated. This is the o Behaviour of NAT/Middleboxes may need to be updated. This is the
case for UDP cksum==0 and also for use of an IPv6 Extension Header case for a zero UDP checksum and also for use of an IPv6 Extension
carrying a transport checksum. Header carrying a transport checksum.
o The method needs to consider the impact of load balancing, and o The method needs to consider the impact of load balancing, and
whether this may be enabled for the chosen transport protocol. whether this may be enabled for the chosen transport protocol.
o If a method proposes selective ignoring of the checksum on
reception, it needs to provide guidance that is appropriate for
all use-cases, including defining how currently standardised nodes
handle any new use.
4.1. Constraints required oin usage of a zero checksum
If a zero checksum approach were to be adopted by the IETF, the If a zero checksum approach were to be adopted by the IETF, the
specification should consider adding the following constraints on specification should consider adding the following constraints on
usage: usage:
1. A method must be specified to verify the integrity of the inner 1. IPv6 protocol stack implementations should not by default allow
(tunneled) packet. the new method. The default node receiver behaviour must
discard all IPv6 packets carrying UDP packets with no checksum.
2. Non-IP inner (tunneled) packets must have a CRC or other 2. Implementations must provide a way to signal which ports will be
mechanism for checking packet integrity. enabled to receive UDP datagrams with a zero checksum. An IPv6
node that enables reception of must enable this only for a
specific port or port-range. This may be implemented via a
socket API call, or similar mechanism.
3. If a method proposes selective ignoring of the checksum on 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams with
reception, it needs to provide guidance that is appropriate for a zero checksum. This should remain the case for any datagram
all use-cases, including defining how currently standardised received on a port that does not explicitly enable zero-checksum
nodes handle any new use. processing. A port for which zero-checksum has been enabled
must not log the datagram.
4. The tunneling protocol must not allow fragmentation of the inner 4. (that pass the checksum). A stack may separately identify UDP
packets being carried. We suggest the following elaborations of datagrams that are discarded with a zero checksum. It should
the above restrictions, if a change in the IPv6 specification not add these to the standard log, since the endpoint has not
moves forward: That is a tunnel must not forward an inner been verified.
(tunneled) IPv4 packet that also has a UDP checksum equal to 0.
This includes not tunneling other tunneling protocols that also
use a UDP checksum equal to 0, even if more deeply encapsulated
packets have checksums or other integrity checking mechanisms.
5. Restrictions may be needed to the use of a tunnel encapsulations 5. A method must be specified to verify the integrity of the inner
and the use of recursive tunnels (e.g. Necessary when the (tunneled) packet for each tunnel application that uses a zero-
endpoint is not verified). checksum. This method must be robust to the use of other
applications that also use a zero-checksum.
6. General protocol stack implementations should not by default 6. Non-IP inner (tunneled) packets must have a CRC or other
allow the new method. The new method should remain restricted to mechanism for checking packet integrity.
endpoints that explicitly enable this mode and adopt the above
procedures. 7. UDP applications that support use of a zero-checksum, should not
rely upon correct reception of the IP and UDP protocol
information when decoding and processing the packet payload. In
particular, the application must be designed so that corruption
of this information does not result in accumulated state or
incorrect processing of a tunneled payload.
8. The tunnel must not forward an inner (tunneled) IPv4 packet that
also has a UDP checksum equal to 0. This includes not tunneling
other tunneling protocols that also use a UDP checksum equal to
0, even if more deeply encapsulated packets have checksums or
other integrity checking mechanisms.
9. The tunneling protocol must not allow fragmentation of the inner
packets being carried.
10. If a method proposes recursive tunnels, it needs to provide
guidance that is appropriate for all use-cases. Restrictions
may be needed to the use of a tunnel encapsulations and the use
of recursive tunnels (e.g. Necessary when the endpoint is not
verified).
11. IPv6 nodes that receive ICMPv6 messages that relate to packets
with a zero UDP checksum must provide appropriate checks
concerning the consistency of the reported packet was actually
originated by the node, before acting upon the information (e.g.
validating the address and port numbers in the ICMPv6 message
body).
Deployment of the new method should remain restricted to endpoints
that explicitly enable this mode and adopt the above procedures
5. Summary 5. Summary
This document examines the role of the transport checksum when used This document examines the role of the transport checksum when used
with IPv6, as defined in RFC2460. with IPv6, as defined in RFC2460.
It presents a summary of the trade-offs for evaluating the safety of It presents a summary of the trade-offs for evaluating the safety of
updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value
in the checksum field to indicate that no checksum is present. A in the checksum field to indicate that no checksum is present. A
decision not to include a UDP checksum in received IPv6 datagrams decision not to include a UDP checksum in received IPv6 datagrams
could impact a tunnel application that receives these packets. could impact a tunnel application that receives these packets.
However, a well-designed tunnel application should include However, a well-designed tunnel application should include
consistency checks to validate any header information encapsulated consistency checks to validate any header information encapsulated
with a packet and ensure that a an integrity check is included for with a packet and ensure that an integrity check is included for each
each tunneled packet. When correctly implemented, such a tunnel tunneled packet. When correctly implemented, such a tunnel endpoint
endpoint will not be negatively impacted by omission of the will not be negatively impacted by omission of the transport-layer
transport-layer checksum. However, other applications at the checksum. However, other applications at the intended destination
intended destination node or another IPv6 node can be impacted if node or another IPv6 node can be impacted if they are allowed to
they are allowed to receive datagrams without a transport-layer receive datagrams without a transport-layer checksum.
checksum.
In particular, it is important that already deployed applications are In particular, it is important that already deployed applications are
not impacted by any change at the transport layer. If these not impacted by any change at the transport layer. If these
applications execute on nodes that implement RFC 2460, they will applications execute on nodes that implement RFC 2460, they will
reject all datagrams without a UDP checksum. reject all datagrams without a UDP checksum.
The implications on firewalls, NATs and other middleboxes need to be The implications on firewalls, NATs and other middleboxes need to be
considered. It should not be expected that NATs handle IPv6 UDP considered. It should not be expected that NATs handle IPv6 UDP
datagrams in the same way as they handle IPv4 UDP datagrams. datagrams in the same way as they handle IPv4 UDP datagrams.
Firewalls are intended to be configured, and therefore may need to be Firewalls are intended to be configured, and therefore may need to be
skipping to change at page 20, line 46 skipping to change at page 24, line 8
[LISP] Internet draft, draft-farinacci-lisp-12.txt, "Locator/ID [LISP] Internet draft, draft-farinacci-lisp-12.txt, "Locator/ID
Separation Protocol (LISP)", March 2009. Separation Protocol (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.
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000. (SIIT)", RFC 2765, February 2000.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
skipping to change at page 21, line 48 skipping to change at page 25, line 13
new mechanism (3.3.4). new mechanism (3.3.4).
Individual Draft 02 Individual Draft 02
* Version -02 corrects some typos and editorial NiTs. * Version -02 corrects some typos and editorial NiTs.
* Added reference to ECMP for tunnels. * Added reference to ECMP for tunnels.
* Clarifies the recommendations at the end of the document. * Clarifies the recommendations at the end of the document.
*
Working Group Draft 00 Working Group Draft 00
* Working Group Version -00 corrects some typos and removes much * Working Group Version -00 corrects some typos and removes much
of rationale for UDPTT. It also adds some discussion of IPv6 of rationale for UDPTT. It also adds some discussion of IPv6
extension header extension header.
Working Group Draft 01
* Working Group Version -01 updates the rules and incorporates
off-list feedback. This version is intended for wider review
within the 6man working group.
**TO BE DONE **
* This version requires review from proponents and opponents to
the UDP zero checksum proposal.
* Work still to be done includes:
1. Text on issues with fragmentation needs to be updated to
provide more clarity on issues.
2. Need a recommendation on whether to permit a multicast
destination address with a zero UDP checksum.
3. Is it OK to send ICMPv6 messages in response to non-
delivered UDP datagrams with a zero checksum?
4. The final section may need to be reworked if this document
recommends a specific change to RFC 2460.
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. 76 change blocks. 
208 lines changed or deleted 396 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/