IPv6 UDP Checksum Considerations
draft-6man-udpzero-00

Abstract

This document examines the role of the transport checksum when 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 an IPv6 UDP endpoint to use a zero value in the checksum field to indicate that no checksum is present. The document describes issues and design principles that need to be considered and provides recommendations.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on November 9, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Background
    1.2.  Use of UDP Tunnels
        1.2.1.  Motivation for new approaches
        1.2.2.  Reducing forwarding cost
        1.2.3.  Need to inspect the entire packet
        1.2.4.  Interactions with middleboxes
        1.2.5.  Support for load balancing
2.  Standards-Track Transports
    2.1.  UDP with Standard Checksum
    2.2.  UDP-Lite
        2.2.1.  Using UDP-Lite as a Tunnel Encapsulation
    2.3.  IP in IPv6 Tunnel Encapsulations
3.  Evaluation of proposal to update to RFC 2460 to support zero checksum
    3.1.  Alternatives to the Standard Checksum
    3.2.  Applicability of method
    3.3.  Effect of packet modification in the network
        3.3.1.  Corruption of the destination IP address
        3.3.2.  Corruption of the source IP address
        3.3.3.  Delivery to an unexpected port
        3.3.4.  Validating the network path
    3.4.  Comparision
4.  Requirements on the specification of transported protocols
5.  Summary
6.  Acknowledgements
7.  IANA Considerations
8.  Security Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Document Change History
§  Authors' Addresses

1.  Introduction

The User Datagram Protocol (UDP) transport was defined by RFC768 (Postel, J., “User Datagram Protocol,” August 1980.) [RFC0768] for IPv4 RFC791 (Postel, J., “Internet Protocol,” September 1981.) [RFC0791] and is defined in RFC2460 (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) [RFC2460] for IPv6 hosts and routers. A UDP transport endpoint may be either a host or a router. The UDP Usage Guidelines (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.) [RFC5405] provides overall guidance for application designers, including the use of UDP to support tunneling. These guidelines are applicable to this discussion.

This section provides a background to key issues, and introduces the use of UDP as a tunnel transport protocol.

Section 2 describes a set of standards-track datagram transport protocols that may be used to support tunnels.

Section 3 evaluates proposals to update the UDP transport behaviour to allow for better support of tunnel protocols. It focuses on a proposal to eliminate the checksum for this use-case with IPv6 and assess the trade-offs that would arise.

Section 4 reviews the trade offs and provides recommendations.

1.1.  Background

An Internet transport endpoint should concern itself with the following issues:

• Protection of the endpoint transport state from unnecessary extra state (i.e. Invalid state from rogue packets).
• Protection of the endpoint transport state from corruption of internal state.
• Pre-filtering by the endpoint of erroneous data, to protect the transport from unnecessary processing and from corruption that it can not itself reject.
• Pre-filter of incorrectly addressed destination packets, before responding to a source address.

UDP, as defined in [RFC0768] (Postel, J., “User Datagram Protocol,” August 1980.), supports two checksum behaviours when used with IPv4. The normal behaviour is for the sender to calculate a checksum over a block of data that includes a pseudo header and the UDP datagram payload. The UDP header includes a 16-bit one's complement checksum that provides a statistical guarantee that the payload was not corrupted in transit. This also allows a receiver to verify that the endpoint was the intended destination of the datagram, because the transport pseudo header covers the IP addresses, port numbers, transport payload length, and Next Header/Protocol value corresponding to the UDP transport protocol [RFC1071] (Braden, R., Borman, D., Partridge, C., and W. Plummer, “Computing the Internet checksum,” September 1988.). The length field verifies that the datagram is not truncated or padded. The checksum therefore protects an application against receiving corrupted payload data in place of, or in addition to, the data that was sent. Although the IPv4 UDP (Postel, J., “User Datagram Protocol,” August 1980.) [RFC0768] checksum may be disabled, applications are recommended to enable UDP checksums [RFC5405] (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.).

IPv4 UDP checksum control is often a kernel-wide configuration control (e.g. In Linux and BSD), rather than a per socket call. There are Networking Interface Cards (NICs) that automatically calculate TCP (Postel, J., “Transmission Control Protocol,” September 1981.) [RFC0793] and UDP checksums on transmission if a checksum of zero is sent to the NIC, using a method known as checksum offloading.

The network-layer fields that are validated by a transport checksum are:

• Endpoint IP source address (always included in the pseudo header of the checksum)
• Endpoint IP destination address (always included in the pseudo header of the checksum)
• Upper Layer Payload type (always included in the pseudo header of the checksum)
• IP length of payload (always included in the pseudo header of the checksum)
• Length of the network layer extension headers (i.e. By correct position of the hecksum bytes)

The transport-layer fields that are validated by a transport checksum are:

• Transport demultiplexing, i.e. ports (always included in the checksum)
• Transport payload size (always included in checksum)

Transport endpoints also need to verify the correctness of reassembly of any fragmented datagram (unless the application using the payload is corruption tolerant, as indicated by UDP-Lite's checksum coverage field). For UDP, this is normally provided as a part of the integrity check. Disabling the IPv4 checksum prevents this check. A lack of checksum can lead to issues in a translator or middlebox (e.g. Many IPv4 Network Address Translators, NATs, rely on port numbers to find the mappings, packet fragments do not carry port numbers, so fragments get dropped). RFC2765 (Nordmark, E., “Stateless IP/ICMP Translation Algorithm (SIIT),” February 2000.) [RFC2765] provides some guidance on the processing of fragmented IPv4 UDP datagrams that do not carry a UDP checksum.

IPv6 does not provide a network-layer integrity check. The removal of the header checksum from the IPv6 specification released routers from a need to update a network-layer checksum for each router hop as the IPv6 Hop Count is changed (comapraed to the checksum update needed when an IPv4 router modifies the Time-To-Live (TTL)).

The IP header checksum calculation was seen as redundant for most traffic (with UDP or TCP checksums enabled), and people wanted to avoid this extra processing. However, there was concern that the removal of the IP header checksum in IPv6 would lessen the protection of the source/destination IP addresses and result in a significant (a multiplier of ~32,000) increase in the number of times that a UDP packet was accidentally delivered to the wrong destination address and/or apparently sourced from the wrong source address when the UDP checksum was set to zero. This would have had implications on the detectability of mis-delivery of a packet to an incorrect endpoint/socket, and the robustness of the Internet infrastructure. The use of the UDP checksum is therefore required[RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) when applications transmit UDP datagrams over IPv6.

1.2.  Use of UDP Tunnels

One increasingly popular use of UDP is as a tunneling protocol, where a tunnel endpoint encapsulates the packets of another protocol inside UDP datagrams and transmits them to another tunnel endpoint. Using UDP as a tunneling protocol is attractive when the payload protocol is not supported by the middleboxes that may exist along the path, because many middleboxes support transmission using UDP. In this use, the receiving endpoint decapsulates the UDP datagrams and forwards the original packets contained in the payload [RFC5405] (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.). Tunnels establish virtual links that appear to directly connect locations that are distant in the physical Internet topology and can be used to create virtual (private) networks.

1.2.1.  Motivation for new approaches

A number of tunnel protocols are currently being defined (e.g. Automated Multicast Tunnels, AMT (Internet draft, draft-ietf-mboned-auto-multicast-10, “Automatic IP Multicast Without Explicit Tunnels (AMT),” March 2010.) [AMT], and the Locator/Identifier Separation Protocol, LISP (Internet draft, draft-farinacci-lisp-12.txt, “Locator/ID Separation Protocol (LISP),” March 2009.) [LISP]). These protocols have proposed an update to IPv6 UDP checksum processing. These tunnel protocols could benefit from simpler checksum processing for various reasons:

• Reducing forwarding costs, motivated by redundancy present in the encapsulated packet header, since in tunnel encapsulations, payload integrity and length verification may be provided by higher layer encapsulations (often using the IPv4, UDP, UDP-Lite, or TCP checksums).
• Eliminating a need to access the entire packet when forwarding the packet.
• Enhancing ability to traverse middleboxes, especially Network Address Translators, NATs.
• A desire to use the port number space to enable load-sharing.

1.2.2.  Reducing forwarding cost

It is a common requirement to terminate a large number of tunnels on a single router/host. Processing costs per tunnel concern both state (memory requirements) and processing costs.

Automatic IP Multicast Without Explicit Tunnels, known as AMT (Internet draft, draft-ietf-mboned-auto-multicast-10, “Automatic IP Multicast Without Explicit Tunnels (AMT),” March 2010.) [AMT] currently specifies UDP as the transport protocol for tunneled packets carrying tunneled IP multicast packets. The current specification for AMT requires that the UDP checksum in the outer packet header should be 0 (see Section 6.6). It argues that the computation of an additional checksum, when an inner packet is already adequately protected, is an unwarranted burden on nodes implementing lightweight tunneling protocols. The AMT protocol needs to replicate a multicast packet to each gateway tunnel. In this case, the outer IP addresses are different for each tunnel and therefore require a different pseudo header to be built for each UDP replicated encapsulation.

The argument concerning redundant processing costs is valid regarding the integrity of a tunneled packet. In some architectures (e.g. PC-based routers), other mechanisms may also significantly reduce checksum processing costs: There are implementations that have optimised checksum processing algorithms, including the use of checksum-offloading. This processing is readily available for IPv4 packets at high line rates. Such processing may be anticipated for IPv6 endpoints, allowing them to reject corrupted packets without further processing. Relaxing RFC 2460 to minimise the processing impact for existing hardware is a transition policy decision, which seems undesirable if at the same time it yields a solution that may reduce stability and functionality in future network scenarios.

1.2.3.  Need to inspect the entire packet

The currently-deployed hardware in many routers uses a fast-path processing that only provides the first n bytes of a packet to the forwarding engine, where typically n < 128. This prevents fast processing of a transport checksum over an entire (large) packet. 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 not provide checksum-offloading.

1.2.4.  Interactions with middleboxes

In IPv4, UDP-encapsulation may be desirable for NAT traversal, since UDP support is commonly provided.

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 for IPv6. Any change to RFC 2460 is going to require rewriting (or defining) IPv6 NAT behaviour to achieve consistent widescale deployment.

The requirements for IPv6 firewall traversal are likely be to be similar to those for IPv4. In addition, it can be reasonably 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 were to be defined for IPv6, this may also need to be updated.

Key questions in this space include:

• What types of middleboxes does the protocol need to cross (routers, NAT boxes, firewalls, etc.), and how will those middleboxes deal with these packets?
• What do IPv6 routers do today with zero-checksum UDP packets?
• What other IPv6 middleboxes exist today, and what would they do?

1.2.5.  Support for load balancing

The UDP port number fields have been used as a basis to design load-balancing solutions for IPv4. This approach could also be leveraged for IPv6. However, support for extension headers would increase the complexity of providing standards-compliant solutions for IPv6.

An alternate method could utilise the IPv6 Flow Label to perform load balancing. This would release IPv6 load-balancing devices from the need to assume semantics for the use of the transport port field. This use of the flow-label is consistent with the intended use, although further clarity may be needed to ensure the field can be consistently used for this purpose, (e.g. ECMP [ECMP] (, “Using the IPv6 flow label for equal cost multipath routing in tunnels (draft-carpenter-flow-ecmp),” .)). Router vendors could be encouraged to start using the IPv6 Flow Label as a part of the flow hash.

2.  Standards-Track Transports

2.1.  UDP with Standard Checksum

UDP with standard checksum behaviour is defined in RFC 2460, and should be the default choice. Guidelines are provided in [RFC5405] (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.).

2.2.  UDP-Lite

UDP-Lite [RFC3828] (Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, “The Lightweight User Datagram Protocol (UDP-Lite),” July 2004.) offers an alternate transport to UDP, specified as a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and unicast usage guidelines in [RFC5405] (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.). UDP-Lite has been 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 using this option, a datagram is divided into a sensitive part (covered by the checksum) and an insensitive part (not covered by the checksum). Errors/corruption in the insensitive part will not cause 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 specified for damage-tolerant payloads, and some link-layers may employ different link encapsulations when forwarding UDP-Lite segments (e.g. Over radio access bearers). When the checksum covers the entire packet, which should be the default, UDP-Lite is 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

Tunnel encapsulations can use UDP-Lite (e.g. Control And Provisioning of Wireless Access Points, CAPWAP), since UDP-Lite provides a transport-layer checksum, including an IP pseudo header checksum, in IPv6, without the need for a router/middelbox to traverse the entire packet payload.

In the LISP case, the bytes that would need to be "checksummed" for UDP-Lite would be the set of bytes that are added to the packet by the LISP encapsulating router. When an IPv4/UDP header is per-pended by a LISP router, the LISP ETR needs to calculate the IP header checksum over 20 bytes (the IP header). If an IPv6/UDP-Lite header were per-pended by a LISP router, the ETR would need to calculate an IP header checksum over 48 bytes (the IP pseudo header and the UDP header). This results in an increase in the number of bytes to be the checksummed for IPv6 (48 bytes rather than 20), but this is not thought to be a major additional processing overhead for a well-optimized implementation where the pre-pended header bytes are already in memory.

2.3.  IP in IPv6 Tunnel Encapsulations

The IETF has defined a set of tunneling protocols. These do not include a checksum, since tunnel encapsulations are typically layered directly over the Internet layer (identified by the upper layer type field) and are also not used as endpoint transport protocols. That is, there is little chance of confusing a tunnel-encapsulated packet with other application data that could result in corruption of application state or data.

From the end-to-end perspective, the principal difference is that the network-layer Next Header field identifies a separate transport, which reduces the probability that corruption could result in the packet being delivered to the wrong endpoint or application. Specifically, packets are only delivered to protocol modules that process a specific next header value. The next header field therefore provides a first-level check of correct demultiplexing. In contrast, the UDP port space is shared by many diverse application and therefore UDP demultiplexing relies solely on the port numbers.

3.  Evaluation of proposal to update to RFC 2460 to support zero checksum

This section evaluates a proposal to update IPv6 [RFC2460], to provide the option that some nodes may suppress generation and checking of the UDP transport checksum. The decision to omit an integrity check at the IPv6 level means that the transport check is overloaded with many functions including validating:

• the endpoint address was not corrupted within a router - i.e. This packet was intended to be received by this destination and a wrong header has not been spliced to a different payload.
• the extension header processing is correctly delimited - i.e. The start of data has not been corrupted. The protocol type field also provides some protection.
• reassembly processing, when used.
• the length of the payload.
• the port values - i.e. The correct application gets the payload (applications should also check the expecetd use of source ports/addresses).
• the payload integrity.

In IPv4, the first 4 checks are performed using the IPv4 header checksum.

In IPv6, these checks occur within the endpoint stack using the UDP checksum information. An IPv6 node also relies on the header information to determine whether to send an ICMPv6 error message and to determine the node to which this is sent. Corrupted information may lead to misdelivery to an unintended application socket on an unexpected host.

3.1.  Alternatives to the Standard Checksum

There are several alternatives to the normal method for calculating the UDP Checksum that do not require a tunnel endpoint to inspect the entire packet when computing a checksum. These include (in decreasing complexity):

• Delta computation of the checksum from an encapsulated checksum field. Since the checksum is a cumulative sum (RFC 1624), an encapsulating header checksum can be derived from the new pseudo header, the inner checksum and the sum of the other network-layer fields not included in the pseudo header of the encapsulated packet, in maaner resembling incremental checksum update [RFC1141] (Mallory, T. and A. Kullberg, “Incremental updating of the Internet checksum,” January 1990.). This would not require access to the whole packet, but does require fields to be collected across the header, and arithmetic operations on each packet. The method would only work for packets that contain a 2's complement transport checksum (i.e. it would not be appropriate for SCTP or when IP fragmentation is used). The process may be easier for IPv4 over IPv6 encapsulation, where the encapsulated IPv4 header checksum could be used as a basis.
• UDP-Lite. Where the checksum coverage may be set to only the header portion of a packet. This requires a pseudo header checksum calculation only on the encapsulating packet header, which includes extracting the UDP payload length for the pseudo header, however this is expected to be also known when performing packet forwarding. The value may be cached per flow/destination and subsequently combined only with the Length field to minimise per-packet processing.
• The proposed UDP Tunnel Transport, UDPTT [UDPTT] (, “The UDP Tunnel Transport mode,” Feb 2010.) proposed a method where UDP is modified to derive the checksum only from the encapsulating packet protocol header. This value does not change between packets in a flow. The value may be cached per flow/destination to minimise per-packet processing. This proposal is not discussed further in this document.
• Use of a new IPv6 Extension Header that provides an end-to-end validation check at the network layer. This would allow an endpoint to verfiy delivery to an appropriate end point, but would also require IPv6 nodes to correctly handle the additional header.
• UDP modified to disable checksum processing[UDPZ] (, “UDP Checksums for Tunneled Packets,” (Oct 2009.) (if progressed). This requires no checksum calculation.

These options are discussed further in later sections.

3.2.  Applicability of method

The expectation of the present proposal to permit omission of UDP checksums [UDPZ] (, “UDP Checksums for Tunneled Packets,” (Oct 2009.) is that this would apply only to IPv6 router nodes that implement specific protocols. However, the distinction between a router and a host is not always clear, especially at the transport level. Systems (such as unix-based operating systems) routinely provide both functions. There is also no way to identify the role of a receiver from a received packet.

Any new method would therefore need a specific applicability statement indicating when the mechanism can (and can not) be used. There are additional requirements, e.g. fragmentation must not be performed, since correct reassembly can not be verified at the receiver when there is no checksum. Allowing fragmentation would also open the receiver to a wide range of mis-behaviours.

Host-based fragmentation must therefore be dsiabled. 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. 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 of this mode. If this is specified and widely available, it may be expected to be used by applications that are perceived to gain benefit. Any solution that uses an end-to-end transport protocol, rather than an IP in IP encapsulation, also needs to minimise the possibility that end-hosts could confuse a corrupted or wrongly delivered packet with that of data addressed to an application running on their endpoint.

3.3.  Effect of packet modification in the network

IP packets may be corrupted as they traverse an Internet path. Evidence has been presented [Sigcomm2000] (http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/9-1.htm, “When the CRC and TCP Checksum Disagree,” 2000.) to show that this was once an issue with IPv4 routers, and occasional corruption could result from bad internal router processing in routers or hosts. These errors are not detected by the strong frame checksums employed at the 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 to IPv6. It therefore seems prudent not to relax this constraint. The emergence of low-end IPv6 routers and the proposed use of NAT with IPv6 further motivate the need to protect from this type of error.

Corruption in the network may result in:

• A datagram being mis-delivered to the wrong host/router or the wrong transport entity within an endpoint. Such a datagram needs to be discarded.
• A datagram payload being corrupted, but still delivered to the intended host/router transport entity. Such a datagram needs to be either discarded or correctly processed by an application that provides its own integrity checks.
• A datagram payload being truncated by corruption of the length field. Such a datagram needs to be discarded.

When a checksum is used with UDP/IPv6, this significantly reduces the impact of errors, reducing the probability of undetected corruption of state (and data) on both the host stack and the applications using the transport service.

3.3.1.  Corruption of the destination IP address

An IP endpoint destination address could be modified in the network (e.g. corrupted by an error). This is not a concern for IPv4, because the IP header checksum will result in this packet being discarded by the receiving IP stack. Such modification in the network can not be detected when using IPv6.

There are two possible outcomes:

• Delivery to a destination address that is not in use (the packet will not be delivered, but could result in an error report).
• Delivery to a different destination address. This modification will normally be detected by the transport checksum, resulting in silent discard. Without this checksum, the packet would be passed to the endpoint port demultiplexing function. If an application is bound to the associated ports, the packet payload will be passed to the application (see the subsequent section on port processing).

3.3.2.  Corruption of the source IP address

This section examines what happens when the source address is corrupted in transit. (This is not a concern in IPv4, because the IP header checksum will result in this packet being discarded by the receiving IP stack).

Corruption of an IPv6 source address does not result in the IP packet being delivered to a different endpoint protocol or destination address. If only the source address is corrupted, the datagram will likely be processed in the intended context, although with erroneous origin information. The result will depend on the application or protocol that processes the packet. Some examples are:

• An application that requires pre-established context may disregard the datagram as invalid, or could map this to another context (if a context for the modified source address was already activated).
• A stateless application will process the datagram outside of any context, a simple example is the ECHO server, which will respond with a datagram directed to the modified source address. This would create unwanted additional processing load, and generate traffic to the modified endpoint address.
• Some applications build state using the information from packet headers. A previously unused source address would result in receiver processing and the creation of unnecessary transport-layer state at the receiver. For example, RTP flows commonly employ a source independent receiver port. State is created for each received flow. Reception of a datagram with a corrupted source address will therefore result in accumulation of unnecessary state in the RTP state machine, including collision detection and response (since the same synchronization source, SSRC, value will appear to arrive from multiple source IP addresses).

In general, the effect of corrupting the source address will depend upon the protocol that processes the packet and its robustness to this error. For the case where the packet is received by a tunnel endpoint, the tunnel application is expected to correctly handle a corrupted source address.

The impact of source address modification is more difficult to quantify when the receiving application is not that originally intended and several fields have been modified in transit.

3.3.3.  Delivery to an unexpected port

This section considers what happens if one or both of the UDP port values are corrupted in transit. (This can also happen with IPv4 in the zero checksum case, but not when UDP checksums are enabled or with UDP-Lite). If the ports were corrupted in transit, packets may be delivered to the wrong process (on the intended machine) and/or responses or errors sent to the wrong application process (on the intended machine).

There are several possible outcomes for a packet that passes and does not use the UDP checksum validation:

• Delivery to a port that is not in use. The packet is discarded, but could generate an ICMPv6 message (e.g. port unreachable).
• It could be delivered to a different node that implements the same application, where the packet may be accepted, generating side-effects or accumulated state.
• It could be delivered to an application that does not implement the tunnel protocol, where the packet may be incorrectly parsed, and may be misinterpreted, generating side-effects or accumulated state.

The probability of each outcome depends on the statistical probability that the source address and the destination port of the datagram (the source port is not always used in UDP) match those of an existing connection. Unfortunately, such a match may be more likely for UDP than for connection-oriented transports, because

1. There is no handshake prior to communication and no sequence numbers (as in TCP, DCCP, or SCTP). Together, this makes it hard to verify that an application is given only the data associated with a session.
2. Applications writers often bind to wild-card values in endpoint identifiers and do not always validate correctness of datagrams they receive.

While these ruled could be revised to declare naive applications as Historic.This remedy is not realistic - the transport owes it to the stack to do its best to reject bogus datagrams.

If checksum coverage is suppressed, the application needs to provide a method to detect and discard the unwanted data. The encapsulated tunnel protocol would need to perform its own integrity checks on any control information and ensure an integrity check is applied to the tunneled packet. It is not reasonable to assume that it is safe for one application to use a zero checksum value and that other applications will not. It is therefore important to consider 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 tunnel destination with the wrong source address in the external header.

3.3.4.  Validating the network path

IP transports designed for use in the general Internet should not assume specific characteristics. Network protocols may reroute packets and change the set of routers and middleboxes along a path. Therefore transports such as TCP, SCTP and DCCP are designed to negotiate protocol parameters, adapt to different characteristics, and receive feedback that the current path is suited to the intended application. Applications using UDP and UDP-Lite need to provide their own mechanisms to confirm the validity of the current network path.

Any application/tunnel that seeks to make use of zero checksum must include functionality to both negotiate and verify that the zero checksum support is provided by the path and validate that this continues to work (e.g., in the case of re-routing events) between the intended parties. This increases the complexity of using such a solution.

3.4.  Comparision

This section compares different methods to support datagram tunneling. This includes a proposal for updating the behaviour of 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 standardised. The final column the expected functions if an additional end-to-end IPv6 extension header were to be required in combination with use of the zero checksum option.

Comparison of functions for selected methods

                            UDP UDPv4 UDPL IP   IP  UDPv6 UDPv6 UPv6
                                 zero      in   in         zero  EH
                                           IPv4 IPv6

Incremental cksum update?    X    -     X  N/A   N/A  X     -    ?
Verification of IP length?   X    X     X  X     X    X     X    X
Detect dest addr corruption? X    X     X  X     -    X     -    X
Detect NH addr corruption?   -    -     -  X     -    -     -    X
Flow demux fields present?   X    X     X  -     X    X     X    -
Detect port corruption?      X    -     X  N/A   N/A  X     -    -
Detect illegal pay length?   X    X     -  N/A   N/A  X     X    X
Detect pay corruption?       X    -     ?  N/A   N/A  X     -    -
Static cksum per flow?       -    X     -  N/A   N/A  -     X    X
Partial/full midbox support? X    *     ?  ?     ?    X     ?    ?
Restricted tunnel behaviour  X    *     X  X     ?    X     -    -


X   = Provided/supported
-   = Not provided/supported
N/A = Not applicable
?   = Partial support
*   = Supports a subset of functions (i.e. not all combinations)

Table 1

4.  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?

• 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 require specific support in middleboxes.
• Another example is a need to perform port-demultiplexing (e.g. for load balancing). 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?

• 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.
• Another argument against using UDP-Lite is that it uses a different IPv6 Next Header, which is currently not widely supported in middleboxes (see previous).
• 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:

• The role of a router and host are not fixed, and a consistent method must be specified that can be used on all nodes. In IPv6, a node selects the role of a router or host on a per interface basis. 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.
• 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 carrying a transport checksum.
• 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. A method must be specified to verify the integrity of the inner (tunneled) packet.
2. Non-IP inner (tunneled) packets must have a CRC or other mechanism for checking packet integrity.
3. 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. 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: That is a 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.
5. 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).
6. General protocol stack implementations should not by default allow the new method. The new method should remain restricted to endpoints that explicitly enable this mode and adopt the above procedures.

5.  Summary

This document examines the role of the transport checksum when 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 an IPv6 UDP endpoint to use a zero value in the checksum field to indicate that no checksum is present. A decision not to include a UDP checksum in received IPv6 datagrams could impact a tunnel application that receives these packets. However, a well-designed tunnel application should include consistency checks to validate any header information encapsulated with a packet and ensure that a an integrity check is included for each tunneled packet. When correctly implemented, such a tunnel endpoint will not be negatively impacted by omission of the transport-layer checksum. However, other applications at the intended destination node or another IPv6 node can be impacted if they are allowed to receive datagrams without a transport-layer checksum.

In particular, it is important that already deployed applications are not impacted by any change at the transport layer. If these applications execute on nodes that implement RFC 2460, they will reject all datagrams without a UDP checksum.

The implications on firewalls, NATs and other middleboxes need to be considered. It should not be expected that NATs handle IPv6 UDP datagrams in the same way as they handle IPv4 UDP datagrams. Firewalls are intended to be configured, and therefore may need to be explicitly updated to allow new services or protocols.

In general, UDP-based applications need to employ a mechanism that allows a large percentage of the corrupted packets to be removed before they reach an application, both to protect the applications data stream and the control plane of higher layer protocols. These checks are currently performed by the UDP checksum for IPv6, or the reduced checksum for UDP-Lite when used with IPv6.

Although the use of UDP over IPv6 with no checksum may have merits as a tunnel encapsulation and is widely used in IPv4, there are dangers for IPv6 nodes (hosts and routers). If the use of UDP transport without a checksum were to become prevalent for IPv6 (e.g. tunnel and host applications using this are widely deployed), there would also be a significant danger of the Internet carrying an increased volume of packets without a transport checksum for other applications, potentially including applications that have traditionally used IPv4 UDP transport without a checksum. This result is highly undesirable. Other solutions need to be found, such as the use of IPV6 with the minimal checksum coverage for UDP-Lite. This requires that the IPv4 and IPv6 solutions to differ, since there are different deployed infrastructures.

Guidance has also been provided to help evaluate the case for disabling the checksum for specific applications

6.  Acknowledgements

Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert, Magnus Westerlund, others in the TSV directorate.

Thanks also to: Rémi Denis-Courmont, Pekka Savola and many others who contributed comments and ideas via the 6man, behave, lisp and mboned lists.

7.  IANA Considerations

This document does not require IANA considerations.

8.  Security Considerations

Transport checksums provide the first stage of protection for the stack, although they can not be considered authentication mechanisms. These checks are also desirable to ensure packet counters correctly log actual activity, and can be used to detect unusual behaviours.

9.  References

9.1. Normative References

9.2. Informative References

Appendix A.  Document Change History

{RFC EDITOR NOTE: This section must be deleted prior to publication}

Individual Draft 00

This is the first DRAFT of this document - It contains a compilation of various discussions and contributions from a variety of IETF WGs, including: mboned, tsv, 6man, lisp, and behave. This includes contributions from Magnus with text on RTP, and various updates.

Individual Draft 01

• This version corrects some typos and editorial NiTs and adds discussion of the need to negotiate and verify operation of a new mechanism (3.3.4).

Individual Draft 02

• Version -02 corrects some typos and editorial NiTs.
• Added reference to ECMP for tunnels.
• Clarifies the recommendations at the end of the document.

Working Group Draft 00

• Working Group Version -00 corrects some typos and removes much of rationale for UDPTT. It also adds some discussion of IPv6 extension header

Authors' Addresses