Internet Engineering Task Force G. Fairhurst Internet-Draft University of Aberdeen Intended status: Standards Track M. Westerlund Expires: April 25, 2013 Ericsson October 22, 2012 Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums draft-ietf-6man-udpzero-07 Abstract This document provides an applicability statement for the use of UDP transport checksums when used with IPv6. This defines recommendations and requirements for use of IPv6 UDP datagrams with a zero checksum. It examines the role of the IPv6 UDP transport checksum, as defined in RFC2460 and 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 as an indication that no checksum is present. This method is compared with some other possibilities. The document also describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations. XXX NOTE - This revision is a partial response to comments received during IESG review. There are additional comments to be incorporated - and updates anticipated to the related PS that updates IPv6. This is therefore an interim version. XXX 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 April 25, 2013. Copyright Notice Fairhurst & Westerlund Expires April 25, 2013 [Page 1] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 Copyright (c) 2012 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. Fairhurst & Westerlund Expires April 25, 2013 [Page 2] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 5 1.3.1. Motivation for new approaches . . . . . . . . . . . . 6 1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 6 1.3.3. Need to inspect the entire packet . . . . . . . . . . 7 1.3.4. Interactions with middleboxes . . . . . . . . . . . . 7 1.3.5. Support for load balancing . . . . . . . . . . . . . . 8 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 8 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 8 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 9 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 9 3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 10 3.1. Effect of packet modification in the network . . . . . . . 11 3.1.1. Corruption of the destination IP address . . . . . . . 12 3.1.2. Corruption of the source IP address . . . . . . . . . 12 3.1.3. Corruption of Port Information . . . . . . . . . . . . 13 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 13 3.1.5. Corruption of Fragmentation Information . . . . . . . 15 3.2. Validating the network path . . . . . . . . . . . . . . . 17 3.3. Applicability of method . . . . . . . . . . . . . . . . . 17 3.4. Impact on non-supporting devices or applications . . . . . 18 4. Evaluation of proposal to update RFC 2460 to support zero checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Alternatives to the Standard Checksum . . . . . . . . . . 19 4.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 20 4.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 21 4.2.3. Ingress and Egress Performance Implications . . . . . 21 4.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 22 4.2.5. Corruption Detection Strength . . . . . . . . . . . . 22 4.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 23 5. Constraints on implementation of IPv6 nodes supporting zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Requirements on the specification of transported protocols . . 25 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix A. Document Change History . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Fairhurst & Westerlund Expires April 25, 2013 [Page 3] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 1. Introduction The User Datagram Protocol (UDP) [RFC0768] transport is defined for the Internet Protocol (IPv4) [RFC0791] and is defined in Internet Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The UDP transport protocol has a minimal set of features. This limited set has enabled a wide range of applications to use UDP, but these application do need to provide many important transport functions on top of UDP. The UDP Usage Guidelines [RFC5405] provides overall guidance for application designers, including the use of UDP to support tunneling. The key difference between UDP usage with IPv4 and IPv6 is that IPv6 mandates use of the UDP checksum, i.e. a non- zero value, due to the lack of an IPv6 header checksum. The lack of a possibility to use UDP with a zero-checksum in IPv6 has been observed as a real problem for certain classes of application, primarily tunnel applications. This class of application has been deployed with a zero checksum using IPv4. The design of IPv6 raises different issues when considering the safety of using a zero checksum for UDP with IPv6. These issues can significantly affect applications, both when an endpoint is the intended user and when an innocent bystander (received by a different endpoint to that intended). The document examines these issues and compares the strengths and weaknesses of a number of proposed solutions. This analysis presents a set of issues that must be considered and mitigated to be able to safely deploy UDP with a zero checksum over IPv6. The provided comparison of methods is expected to also be useful when considering applications that have different goals from the ones that initiated the writing of this document, especially the use of already standardized methods. The analysis concludes that using UDP with a zero checksum is the best method of the proposed alternatives to meet the goals for certain tunnel applications. Unfortunately, this usage is expected to have some deployment issues related to middleboxes, limiting the usability more than desired in the currently deployed internet. However, this limitation will be largest initially and will reduce as updates for support of UDP zero checksum for IPv6 are provided to middleboxes. The document therefore derives a set of constraints required to ensure safe deployment of zero checksum in UDP. It also identifies some issues that require future consideration and possibly additional research. 1.1. Document Structure Section 1 provides a background to key issues, and introduces the use of UDP as a tunnel transport protocol. Fairhurst & Westerlund Expires April 25, 2013 [Page 4] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 Section 2 describes a set of standards-track datagram transport protocols that may be used to support tunnels. Section 3 discusses issues with a zero checksum in UDP for IPv6. It considers the impact of corruption, the need for validation of the path and when it is suitable to use a zero checksum. Section 4 evaluates a set of proposals to update the UDP transport behaviour and other alternatives intended to improve support for tunnel protocols. It focuses on a proposal to allow a zero checksum for this use-case with IPv6 and assesses the trade-offs that would arise. Section 5 is an applicability statement that defines requirements and recommendations on the implementation of IPv6 nodes that support the use of a UDP zero value in the checksum of a UDP datagram. Section 6 provides an applicability statement that identifies requirements and recommendations for protocols and tunnel encapsulations that are transported over an IPv6 transport connection that does not perform a UDP checksum calculation to verify the integrity at the transport endpoints. Section 7 provides the recommendations for standardization of zero- checksum with a summary of the findings and notes remaining issues needing future work. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. 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]. 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. Fairhurst & Westerlund Expires April 25, 2013 [Page 5] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 1.3.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 also currently being defined (e.g. Automated Multicast Tunnels, AMT [I-D.ietf-mboned-auto-multicast], and the Locator/Identifier Separation Protocol, LISP [LISP]). These protocols have proposed an update to IPv6 UDP checksum processing. These tunnel protocols could benefit from simpler checksum processing for various reasons: o 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). o Eliminating a need to access the entire packet when forwarding the packet by a tunnel endpoint. o Enhancing ability to traverse middleboxes, especially Network Address Translators, NATs. o A desire to use the port number space to enable load-sharing. 1.3.2. Reducing forwarding cost It is a common requirement to terminate a large number of tunnels on a single router/host. Processing per tunnel concerns both state (memory requirements) and per-packet processing costs. Automatic IP Multicast Tunneling, known as AMT [I-D.ietf-mboned-auto-multicast] currently specifies UDP as the transport protocol for 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 of [I-D.ietf-mboned-auto-multicast]). 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- Fairhurst & Westerlund Expires April 25, 2013 [Page 6] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 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 receivers to reject corrupted packets without further processing. However, there are certain classes of tunnel end-points where this off-loading is not available and unlikely to become available in the near future. 1.3.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. Thus enabling checksum calculation over the complete packet can impact router design, performance improvement, energy consumption and/or cost. 1.3.4. Interactions with middleboxes In IPv4, UDP-encapsulation may be desirable for NAT traversal, since UDP support is commonly provided. It is also necessary due to the almost ubiquitous deployment of IPv4 NATs. There has also been discussion of NAT for IPv6, although not for the same reason as in IPv4. If IPv6 NAT becomes a reality they hopefully do not present the same protocol issues as for IPv4. If NAT is defined for IPv6, it should take UDP zero checksum into consideration. 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. If a zero-checksum for UDP were to be allowed for IPv6, this would need firewalls to be updated before full utility of the change is available. It can be expected that UDP with zero-checksum will initially not have the same middlebox traversal characteristics as regular UDP. However, if standardized we can expect an improvement over time of the traversal capabilities. We also note that deployment of IPv6- capable middleboxes is still in its initial phases. Thus, it might be that the number of non-updated boxes quickly become a very small percentage of the deployed middleboxes. Fairhurst & Westerlund Expires April 25, 2013 [Page 7] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 1.3.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 has also been leveraged for IPv6. An alternate method would be to utilise the IPv6 Flow Label as basis for entropy for the load balancing. This would have the desirable effect of releasing IPv6 load-balancing devices from the need to assume semantics for the use of the transport port field and also works for all type of transport protocols. 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. Equal-Cost Multi-Path routing, ECMP [ECMP]). Router vendors could be encouraged to start using the IPv6 Flow Label as a part of the flow hash, providing support for ECMP without requiring use of UDP. However, the method for populating the outer IPv6 header with a value for the flow label is not trivial: If the inner packet uses IPv6, then the flow label value could be copied to the outer packet header. However, many current end-points set the flow label to a zero value (thus no entropy). The ingress of a tunnel seeking to provide good entropy in the flow label field would therefore need to create a random flow label value and keep corresponding state, so that all packets that were associated with a flow would be consistently given the same flow label. Although possible, this complexity may not be desirable in a tunnel ingress. The end-to-end use of flow labels for load balancing is a long-term solution. Even if the usage of the flow label is clarified, there would be a transition time before a significant proportion of end- points start to assign a good quality flow label to the flows that they originate, with continued use of load balancing using the transport header fields until any widespread deployment is finally achieved. 2. Standards-Track Transports The IETF has defined a set of transport protocols that may be applicable for tunnels with IPv6. There are also a set of network layer encapsulation tunnels such as IP-in-IP and GRE. These already standardized solutions are discussed here prior to the issues, as background for the issue description and some comparison of where the issue may already occur. 2.1. UDP with Standard Checksum UDP [RFC0768] with standard checksum behaviour, as defined in RFC 2460, has already been discussed. UDP usage guidelines are provided Fairhurst & Westerlund Expires April 25, 2013 [Page 8] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 in [RFC5405]. 2.2. UDP-Lite UDP-Lite [RFC3828] 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]. There is at least one open source implementation as a part of the Linux kernel since version 2.6.20. UDP-Lite provides a checksum with 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). When the checksum covers the entire packet, UDP-Lite is fully equivalent with UDP. Errors/corruption in the insensitive part will not cause the datagram to be discarded by the transport layer at the receiving endpoint. A minor side-effect of using UDP-Lite is that this was specified for damage-tolerant payloads, and some link- layers may employ different link encapsulations when forwarding UDP- Lite segments (e.g. radio access bearers). Most link-layers will cover the insensitive part with the same strong layer 2 frame CRC that covers the sensitive part. 2.2.1. Using UDP-Lite as a Tunnel Encapsulation Tunnel encapsulations can use UDP-Lite (e.g. Control And Provisioning of Wireless Access Points, CAPWAP [RFC5415]), 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. This provides most of the verification required for delivery and still keeps the complexity of the checksumming operation low. UDP-Lite may set the length of checksum coverage on a per packet basis. This feature could be used if a tunnel protocol is designed to only verify delivery of the tunneled payload and uses full checksumming for control information. There is currently poor support for middlebox traversal using UDP- Lite, because UDP-Lite uses a different IPv6 network-layer Next Header value to that of UDP, and few middleboxes are able to interpret UDP-Lite and take appropriate actions when forwarding the packet. This makes UDP-Lite less suited to protocols needing general Internet support, until such time that UDP-Lite has achieved better support in middleboxes and end-points. 2.3. General Tunnel Encapsulations The IETF has defined a set of tunneling protocols or network layer encapsulations, e.g., IP-in-IP and GRE. These either do not include Fairhurst & Westerlund Expires April 25, 2013 [Page 9] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 a checksum or use a checksum that is optional, since tunnel encapsulations are typically layered directly over the Internet layer (identified by the upper layer type in the IPv6 Next Header field) and are also not used as endpoint transport protocols. 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 applications and therefore UDP demultiplexing relies solely on the port numbers. 3. Issues Requiring Consideration This informative section evaluates issues around the proposal to update IPv6 [RFC2460], to provide the option of using a UDP transport checksum set to zero. Some of the identified issues are shared with other protocols already in use. The decision by IPv6 to omit an integrity check at the network level has meant that the transport check was overloaded with many functions, including validating: o the endpoint address was not corrupted within a router, i.e., a packet was intended to be received by this destination and validate that the packet does not consist of a wrong header spliced to a different payload; o that extension header processing is correctly delimited - i.e., the start of data has not been corrupted. In this case, reception of a valid next header value provides some protection; o reassembly processing, when used; o the length of the payload; o the port values - i.e., the correct application receives the payload (applications should also check the expected use of source ports/addresses); Fairhurst & Westerlund Expires April 25, 2013 [Page 10] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 o the payload integrity. In IPv4, the first four 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 [RFC4443] 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. Effect of packet modification in the network IP packets may be corrupted as they traverse an Internet path. Evidence has been presented [Sigcomm2000] 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 [RFC3819]. 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: o 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; o 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; o A datagram payload being truncated by corruption of the length field. Such a datagram needs to be discarded. When a checksum is used, 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. The following sections examine the impact of modifying each of these header fields. Fairhurst & Westerlund Expires April 25, 2013 [Page 11] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 3.1.1. Corruption of the destination IP address An IPv6 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 at the network layer when using IPv6. There are two possible outcomes: o Delivery to a destination address that is not in use (the packet will not be delivered, but could result in an error report); o Delivery to a different destination address. This modification will normally be detected by the transport checksum, resulting in silent discard. Without a computed 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.1.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 normally 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. When using Unicast Reverse Path Forwarding [RFC2827], a change in address may result in the router discarding the packet when the route to the modified source address is different to that of the source address of the original packet. The result will depend on the application or protocol that processes the packet. Some examples are: o An application that requires a per-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). o 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 Fairhurst & Westerlund Expires April 25, 2013 [Page 12] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 would create unwanted additional processing load, and generate traffic to the modified endpoint address. o Some datagram 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, Real Time Protocol (RTP) [RFC3550] sessions 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.1.3. Corruption of Port Information This section describes 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 carried in the transport header of an IPv6 packet 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). 3.1.4. Delivery to an unexpected port If one combines the corruption effects, such as destination address and ports, there is a number of potential outcomes when traffic arrives at an unexpected port. This section discusses these possibilities and their outcomes for a packet that does not use the UDP checksum validation: o Delivery to a port that is not in use. The packet is discarded, but could generate an ICMPv6 message (e.g. port unreachable). Fairhurst & Westerlund Expires April 25, 2013 [Page 13] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 o 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. o 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 address or the port information for the source or destination becomes corrupt in the datagram such that they match those of an existing flow or server port. 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 transport session. 2. Applications writers often bind to wild-card values in endpoint identifiers and do not always validate correctness of datagrams they receive (guidance on this topic is provided in [RFC5405]). While these rules could, in principle, 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 therefore needs to provide a method to detect and discard the unwanted data. A tunnel protocol would need to perform its own integrity checks on any control information if transported in UDP with zero-checksum. If the tunnel payload is another IP packet, the packets requiring checksums can be assumed to have their own checksums provided that the rate of corrupted packets is not significantly larger due to the tunnel encapsulation. If a tunnel transports other inner payloads that do not use IP, the assumptions of corruption detection for that particular protocol must be fulfilled, this may require an additional checksum/CRC and/or integrity protection of the payload and tunnel headers. A protocol using UDP zero-checksum can never assume that it is the only protocol using a zero checksum. Therefore, it needs to gracefully handle misdelivery. It must be robust to reception of malformed packets received on a listening port and expect that these packets may contain corrupted data or data associated with a Fairhurst & Westerlund Expires April 25, 2013 [Page 14] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 completely different protocol. 3.1.5. Corruption of Fragmentation Information The fragmentation information in IPv6 employs a 32-bit identity field, compared to only a 16-bit field in IPv4, a 13-bit fragment offset and a 1-bit flag, indicating if there are more fragments. Corruption of any of these field may result in one of two outcomes: Reassembly failure: An error in the "More Fragments" field for the last fragment will for example result in the packet never being considered complete and will eventually be timed out and discarded. A corruption in the ID field will result in the fragment not being delivered to the intended context thus leaving the rest incomplete, unless that packet has been duplicated prior to corruption. The incomplete packet will eventually be timed out and discarded. Erroneous reassembly: The re-assemblied packet did not match the original packet. This can occur when the ID field of a fragment is corrupted, resulting in a fragment becoming associated with another packet and taking the place of another fragment. Corruption in the offset information can cause the fragment to be misaligned in the reassembly buffer, resulting in incorrect reassembly. Corruption can cause the packet to become shorter or longer, however completion of reassembly is much less probable, since this would requires consistent corruption of the IPv6 headers payload length field and the offset field. The possibility of mis-assembly requires the reassembling stack to provide strong checks that detect overlap or missing data, note however that this is not guaranteed and has recently been clarified in "Handling of Overlapping IPv6 Fragments" [RFC5722]. The erroneous reassembly of packets is a general concern and such packets should be discarded instead of being passed to higher layer processes. The primary detector of packet length changes is the IP payload length field, with a secondary check by the transport checksum. The Upper-Layer Packet length field included in the pseudo header assists in verifying correct reassembly, since the Internet checksum has a low probability of detecting insertion of data or overlap errors (due to misplacement of data). The checksum is also incapable of detecting insertion or removal of all zero-data that occurs in a multiple of a 16-bit chunk. The most significant risk of corruption results following mis- association of a fragment with a different packet. This risk can be significant, since the size of fragments is often the same (e.g. fragments resulting when the path MTU results in fragmentation of a Fairhurst & Westerlund Expires April 25, 2013 [Page 15] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 larger packet, common when addition of a tunnel encapsulation header expands the size of a packet). Detection of this type of error requires a checksum or other integrity check of the headers and the payload. Such protection is anyway desirable for tunnel encapsulations using IPv4, since the small fragmentation ID can easily result in wrap-around [RFC4963], this is especially the case for tunnels that perform flow aggregation [I-D.ietf-intarea-tunnels]. Tunnel fragmentation behavior matters. There can be outer or inner fragmentation "Tunnels in the Internet Architecture" [I-D.ietf-intarea-tunnels]. If there is inner fragmentation by the tunnel, the outer headers will never be fragmented and thus a zero- checksum in the outer header will not affect the reassembly process. When a tunnel performs outer header fragmentation, the tunnel egress needs to perform reassembly of the outer fragments into an inner packet. The inner packet is either a complete packet or a fragment. If it is a fragment, the destination endpoint of the fragment will perform reassembly of the received fragments. The complete packet or the reassembled fragments will then be processed according to the packet next header field. The receiver may only detect reassembly anomalies when it uses a protocol with a checksum. The larger the number of reassembly processes to which a packet has been subjected, the greater the probability of an error. o An IP-in-IP tunnel that performs inner fragmentation has similar properties to a UDP tunnel with a zero-checksum that also performs inner fragmentation. o An IP-in-IP tunnel that performs outer fragmentation has similar properties to a UDP tunnel with a zero checksum that performs outer fragmentation. o A tunnel that performs outer fragmentation can result in a higher level of corruption due to both inner and outer fragmentation, enabling more chances for reassembly errors to occur. o Recursive tunneling can result in fragmentation at more than one header level, even for inner fragmentation unless it goes to the inner most IP header. o Unless there is verification at each reassembly, the probability for undetected error will increase with the number of times fragmentation is recursively applied, making IP-in-IP and UDP with zero checksum both vulnerable to undetected errors. In conclusion fragmentation of packets with a zero-checksum does not worsen the situation compared to some other commonly used tunnel encapsulations. However, caution is needed for recursive tunneling Fairhurst & Westerlund Expires April 25, 2013 [Page 16] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 without any additional verification at the different tunnel layers. 3.2. Validating the network path IP transports designed for use in the general Internet should not assume specific path characteristics. Network protocols may reroute packets that change the set of routers and middleboxes along a path. Therefore transports such as TCP, SCTP and DCCP have been designed to negotiate protocol parameters, adapt to different network path characteristics, and receive feedback to verify 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. The zero-checksum in UDP is explicitly disallowed in RFC2460. Thus it may be expected that any device on the path that has a reason to look beyond the IP header will consider such a packet as erroneous or illegal and may likely discard it, unless the device is updated to support a new behavior. A pair of end-points intending to use a new behavior will therefore not only need to ensure support at each end- point, but also that the path between them will deliver packets with the new behavior. This may require negotiation or an explicit mandate to use the new behavior by all nodes intended to use a new protocol. Support along the path between end points may be guaranteed in limited deployments by appropriate configuration. In general, it can be expected to take time for deployment of any updated behaviour to become ubiquitous. A sender will need to probe the path to verify the expected behavior. Path characteristics may change, and usage therefore should be robust and able to detect a failure of the path under normal usage and re-negotiate. This will require periodic validation of the path, adding complexity to any solution using the new behavior. 3.3. Applicability of method The expectation of the present proposal defined in [I-D.ietf-6man-udpchecksums] is that this change would only apply to IPv6 router nodes that implement specific protocols that permit omission of UDP checksums. 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. Fairhurst & Westerlund Expires April 25, 2013 [Page 17] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 Enabling this, and ensuring correct interactions with the stack, implies much more than simply disabling the checksum algorithm for specific packets at the transport interface. The IETF should carefully consider constraints on sanctioning the use of any new transport 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, 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 unless they accept that behavior. 3.4. Impact on non-supporting devices or applications It is important to consider what potential impact the zero-checksum behavior may have on end-points, devices or applications that are not modified to support the new behavior or by default or preference, use the regular behavior. These applications must not be significantly impacted by the changes. To illustrate a potential issue, consider the implications of a node that were to enable use of a zero-checksum at the interface level: This would result in all applications that listen to a UDP socket receiving datagram where the checksum was not verified. This could have a significant impact on an application that was not designed with the additional robustness needed to handle received packets with corruption, creating state or destroying existing state in the application. In contrast, the use of a zero-checksum could be enabled only for individual ports using an explicit request by the application. In this case, applications using other ports would maintain the current IPv6 behavior, discarding incoming UDP datagrams with a zero- checksum. These other applications would not be effected by this changed behavior. An application that allows the changed behavior should be aware of the risk for corruption and the increased level of misdirected traffic, and can be designed robustly to handle this risk. 4. Evaluation of proposal to update RFC 2460 to support zero checksum This informative section evaluates the proposal to update IPv6 [RFC2460], to provide the option that some nodes may suppress generation and checking of the UDP transport checksum. It also compares the proposal with other alternatives. Fairhurst & Westerlund Expires April 25, 2013 [Page 18] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 4.1. Alternatives to the Standard Checksum There are several alternatives to the normal method for calculating the UDP Checksum [RFC1071]that do not require a tunnel endpoint to inspect the entire packet when computing a checksum. These include (in decreasing order of complexity): o Delta computation of the checksum from an encapsulated checksum field. Since the checksum is a cumulative sum [RFC1624], 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 a manner resembling incremental checksum update [RFC1141]. 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). o UDP-Lite with the checksum coverage set to only the header portion of a packet. This requires a pseudo header checksum calculation only on the encapsulating packet header. The computed checksum value may be cached (before adding the Length field) for each flow/destination and subsequently combined with the Length of each packet to minimise per-packet processing. This value is combined with the UDP payload length for the pseudo header, however this length is expected to be known when performing packet forwarding. o The proposed UDP Tunnel Transport, UDPTT [UDPTT] suggested a method where UDP would be modified to derive the checksum only from the encapsulating packet protocol header. This value does not change between packets in a single flow. The value may be cached per flow/destination to minimise per-packet processing. o There has been a proposal to simply ignore the UDP checksum value on reception at the tunnel egress, allowing a tunnel ingress to insert any value correct or false. For tunnel usage, a non standard checksum value may be used, forcing an RFC 2460 receiver to drop the packet. The main downside is that it would be impossible to identify a UDP datagram (in the network or an endpoint) that is treated in this way compared to a packet that has actually been corrupted. o A method has been proposed that uses a new (to be defined) IPv6 Destination Options Header to provide an end-to-end validation check at the network layer. This would allow an endpoint to verify delivery to an appropriate end point, but would also Fairhurst & Westerlund Expires April 25, 2013 [Page 19] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 require IPv6 nodes to correctly handle the additional header, and would require changes to middlebox behavior (e.g. when used with a NAT that always adjusts the checksum value). o UDP modified to disable checksum processing [I-D.ietf-6man-udpchecksums]. This requires no checksum calculation, but would require constraints on appropriate usage and updates to end-points and middleboxes. o IP-in-IP tunneling. As this method completely dispenses with a transport protocol in the outer-layer it has reduced overhead and complexity, but also reduced functionality. There is no outer checksum over the packet and also no ports to perform demultiplexing between different tunnel types. This reduces the information available upon which a load balancer may act. These options are compared and discussed further in the following sections. 4.2. Comparison This section compares the above listed methods to support datagram tunneling. It includes proposals for updating the behaviour of UDP. 4.2.1. Middlebox Traversal Regular UDP with a standard checksum or the delta encoded optimization for creating correct checksums have the best possibilities for successful traversal of a middlebox. No new support is required. A method that ignores the UDP checksum on reception is expected to have a good probability of traversal, because most middleboxes perform an incremental checksum update. UDPTT may also traverse a middlebox with this behaviour. However, a middlebox on the path that attempts to verify a standard checksum will not forward packets using either of these methods, preventing traversal. A method that ignores the checksum has an additional downside in that it prevents improvement of middlebox traversal, because there is no way to identify packets that use the modified checksum behaviour. IP-in-IP or GRE tunnels offer good traversal of middleboxes that have not been designed for security, e.g. firewalls. However, firewalls may be expected to be configured to block general tunnels as they present a large attack surface. A new IPv6 Destination Options header will suffer traversal issues with middleboxes, especially Firewalls and NATs, and will likely Fairhurst & Westerlund Expires April 25, 2013 [Page 20] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 require them to be updated before the extension header is passed. Packets using UDP with a zero checksum will not be passed by any middlebox that validates the checksum using RFC 2460 or updates the checksum field, such as NAT or firewalls. This would require an update to correctly handle the zero checksum packets. UDP-Lite will require an update of almost all type of middleboxes, because it requires support for a separate network-layer protocol number. Once enabled, the method to support incremental checksum update would be identical to that for UDP, but different for checksum validation. 4.2.2. Load Balancing The usefulness of solutions for load balancers depends on the difference in entropy in the headers for different flows that can be included in a hash function. All the proposals that use the UDP protocol number have equal behavior. UDP-Lite has the potential for equally good behavior as for UDP. However, UDP-Lite is currently likely to not be supported by deployed hashing mechanisms, which may cause a load balancer to not use the transport header in the computed hash. A load balancer that only uses the IP header will have low entropy, but could be improved by including the IPv6 the flow label, providing that the tunnel ingress ensures that different flow labels are assigned to different flows. However, a transition to the common use of good quality flow labels is likely to take time to deploy. 4.2.3. Ingress and Egress Performance Implications IP-in-IP tunnels are often considered efficient, because they introduce very little processing and low data overhead. The other proposals introduce a UDP-like header incurring associated data overhead. Processing is minimised for the zero-checksum method, ignoring the checksum on reception, and only slightly higher for UDPTT, the extension header and UDP-Lite. The delta-calculation scheme operates on a few more fields, but also introduces serious failure modes that can result in a need to calculate a checksum over the complete packet. Regular UDP is clearly the most costly to process, always requiring checksum calculation over the entire packet. It is important to note that the zero-checksum method, ignoring checksum on reception, the Option Header, UDPTT and UDP-Lite will likely incur additional complexities in the application to incorporate a negotiation and validation mechanism. Fairhurst & Westerlund Expires April 25, 2013 [Page 21] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 4.2.4. Deployability The major factors influencing deployability of these solutions are a need to update both end-points, a need for negotiation and the need to update middleboxes. These are summarised below: o The solution with the best deployability is regular UDP. This requires no changes and has good middlebox traversal characteristics. o The next easiest to deploy is the delta checksum solution. This does not modify the protocol on the wire and only needs changes in tunnel ingress. o IP-in-IP tunnels should not require changes to the end-points, but raise issues when traversing firewalls and other security-type devices, which are expected to require updates. o Ignoring the checksum on reception will require changes at both end-points. The never ceasing risk of path failure requires additional checks to ensure this solution is robust and will require changes or additions to the tunneling control protocol to negotiate support and validate the path. o The remaining solutions offer similar deployability. UDP-Lite requires support at both end-points and in middleboxes. UDPTT and Zero-checksum with or without an Extension header require support at both end-points and in middleboxes. UDP-Lite, UDPTT, and Zero- checksum and Extension header may additionally require changes or additions to the tunneling control protocol to negotiate support and path validation. 4.2.5. Corruption Detection Strength The standard UDP checksum and the delta checksum can both provide some verification at the tunnel egress. This can significantly reduce the probability that a corrupted inner packet is forwarded. UDP-Lite, UDPTT and the extension header all provide some verification against corruption, but do not verify the inner packet. They only provide a strong indication that the delivered packet was intended for the tunnel egress and was correctly delimited. The Zero-checksum, ignoring the checksum on reception and IP-and-IP encapsulation provide no verification that a received packet was intended to be processed by a specific tunnel egress or that the inner packet was correct. Fairhurst & Westerlund Expires April 25, 2013 [Page 22] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 4.2.6. Comparison Summary The comparisons above may be summarised as "there is no silver bullet that will slay all the issues". One has to select which down side(s) can best be lived with. Focusing on the existing solutions, this can be summarized as: Regular UDP: Good middlebox traversal and load balancing and multiplexing, requiring a checksum in the outer headers covering the whole packet. IP in IP: A low complexity encapsulation, with limited middlebox traversal, no multiplexing support, and currently poor load balancing support that could improve over time. UDP-Lite: A medium complexity encapsulation, with good multiplexing support, limited middlebox traversal, but possible to improve over time, currently poor load balancing support that could improve over time, in most cases requiring application level negotiation and validation. The delta-checksum is an optimization in the processing of UDP, as such it exhibits some of the drawbacks of using regular UDP. The remaining proposals may be described in similar terms: Zero-Checksum: A low complexity encapsulation, with good multiplexing support, limited middlebox traversal that could improve over time, good load balancing support, in most cases requiring application level negotiation and validation. UDPTT: A medium complexity encapsulation, with good multiplexing support, limited middlebox traversal, but possible to improve over time, good load balancing support, in most cases requiring application level negotiation and validation. IPv6 Destination Option IP in IP tunneling: A medium complexity, with no multiplexing support, limited middlebox traversal, currently poor load balancing support that could improve over time, in most cases requiring application level negotiation and validation. IPv6 Destination Option combined with UDP Zero-checksuming: A medium complexity encapsulation, with good multiplexing support, limited load balancing support that could improve over time, in most cases requiring application level negotiation and validation. Fairhurst & Westerlund Expires April 25, 2013 [Page 23] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 Ignore the checksum on reception: A low complexity encapsulation, with good multiplexing support, medium middlebox traversal that never can improve, good load balancing support, in most cases requiring application level negotiation and validation. There is no clear single optimum solution. If the most important need is to traverse middleboxes, then the best choice is to stay with regular UDP and consider the optimizations that may be required to perform the checksumming. If one can live with limited middlebox traversal, low complexity is necessary and one does not require load balancing, then IP-in-IP tunneling is the simplest. If one wants strengthened error detection, but with currently limited middlebox traversal and load-balancing. UDP-Lite is appropriate. UDP Zero- checksum addresses another set of constraints, low complexity and a need for load balancing from the current Internet, providing it can live with currently limited middlebox traversal. Techniques for load balancing and middlebox traversal do continue to evolve. Over a long time, developments in load balancing have good potential to improve. This time horizon is long since it requires both load balancer and end-point updates to get full benefit. The challenges of middlebox traversal are also expected to change with time, as device capabilities evolve. Middleboxes are very prolific with a larger proportion of end-user ownership, and therefore may be expected to take long time cycles to evolve. One potential advantage is that the deployment of IPv6 capable middleboxes are still in its initial phase and the quicker zero-checksum becomes standardized the fewer boxes will be non-compliant. Thus, the question of whether to allow UDP with a zero-checksum for IPv6 under reasonable constraints, is therefore best viewed as a trade-off between a number of more subjective questions: o Is there sufficient interest in zero-checksum with the given constraints (summarised below)? o Are there other avenues of change that will resolve the issue in a better way and sufficiently quickly ? o Do we accept the complexity cost of having one more solution in the future? The authors do think the answer to the above questions are such that zero-checksum should be standardized for use by tunnel encapsulations. Fairhurst & Westerlund Expires April 25, 2013 [Page 24] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 5. Constraints on implementation of IPv6 nodes supporting zero checksum This section is an applicability statement that defines requirements and recommendations on the implementation of IPv6 nodes that support the use of a UDP zero value in the checksum of a UDP datagram. 1. IPv6 nodes SHOULD by default NOT allow the zero checksum method for transmission or reception. 2. The default node receiver behaviour MUST discard all IPv6 packets carrying UDP datagrams with a zero checksum. IPv6 nodes MUST provide a way for the application/protocol to indicate the set of ports that will be enabled to send UDP datagrams with a zero checksum. This may be implemented via a socket API call, or similar mechanism. It may also be implemented by enabling the method for a pre-assigned static port used by a specific tunnel protocol. 3. IPv6 nodes MUST provide a way for the application/protocol to indicate the set of ports that will be enabled to receive UDP datagrams with a zero checksum. 4. RFC 2460 specifies that IPv6 nodes SHOULD log received UDP datagrams with a zero-checksum. This should remain the case for any datagram received on a port that does not explicitly enable zero-checksum processing. A port for which zero-checksum has been enabled MUST NOT log the datagram solely because the checksum is zero, but MAY log this to support other functions (such as a security policy). 5. IPv6 nodes MAY separately identify received UDP datagrams that are discarded with a zero checksum. It SHOULD NOT add these to the standard log, since the endpoint has not been verified. 6. IPv6 nodes that receive ICMPv6 messages that refer to packets with a zero UDP checksum MUST provide appropriate checks concerning the consistency of the reported packet to verify that the reported packet actually originated from the node, before acting upon the information (e.g. validating the address and port numbers in the ICMPv6 message body). 6. Requirements on the specification of transported protocols This section is an applicability statement that identifies requirements and recommendations for protocols and tunnel encapsulations that are transported over an IPv6 transport connection that does not perform a UDP checksum calculation to verify the Fairhurst & Westerlund Expires April 25, 2013 [Page 25] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 integrity at the transport endpoints. 1. UDP Tunnels that enable the use of zero checksum MUST only enable this only for a specific port or port-range. 2. UDP Tunnels that encapsulate IP MAY rely on the inner packet integrity checks provided that the tunnel will not significantly increase the rate of corruption of the inner IP packet. If a significantly increased corruption rate can occur, then the tunnel MUST provide an additional integrity verification mechanism. Early detection is desirable to avoid wasting unneccessary computation/storage for packets that will subsequently be discarded. 3. An integrity mechanisms is always RECOMMENDED at the tunnel layer to ensure that corruption rates of the inner-most packet are not increased. A mechanism that isolates the causes of corruption (e.g. identifying mis-delivery, IPv6 header corruption, tunnel header corruption) is expected to also provide additional information about the status of the tunnel (e.g. to suggest a security attack). 4. UDP Tunnels that encapsulate non-IP packets MUST have a CRC or other mechanism for checking packet integrity, unless the non-IP packet specifically is designed for transmission over lower layers that do not provide any packet integrity guarantee. In particular, the tunnel endpoint MUST be designed so that corruption of this information does not result in accumulated state or incorrect processing of a tunneled payload. 5. UDP Tunnels that support use of a zero-checksum, SHOULD NOT rely upon correct reception of the IP and UDP protocol information (including the length of the packet) 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. 6. A UDP Tunnel egress that supports a zero UDP checksum MUST also allow reception using a standard UDP checksum. The encapsulating endpoint may choose to compute the UDP checksum, or the sending endpoint IPv6 stack may enable this by default. In either case, the remote endpoint uses the reception method specified in RFC2460. 7. UDP Tunnels with control feedback need to be robust to changes in network path. The set of middleboxes on a path may vary during the life of an association. Endpoints need to discover paths Fairhurst & Westerlund Expires April 25, 2013 [Page 26] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 with middleboxes that drop packets with a zero UDP checksum. Therefore keep-alive messages SHOULD include both UDP datagrams with a checksum and UDP datagrams with a zero checksum. This will enable the remote endpoint to distinguish between a path failure and dropping of UDP datagrams with a zero checksum. Note that path validation need only be performed for each pair of tunnel endpoints, not for each tunnel context. 8. Middleboxes implementations MUST allow IPv6 packets forward both a zero and standard UDP checksum. A middlebox MAY configure specific port ranges that forward UDP datagrams with a zero UDP checksum. These middleboxes MUST forward both standard and zero checksum UDP datagrams within the configured range, but may drop IPv6 UDP datagrams with a zero checksum that are outside the configured ranges. 7. 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. In most cases tunnels encapsulating IP packets can rely on the inner packets own integrity protection. When correctly implemented, such a tunnel endpoint will not be negatively impacted by omission of the transport-layer checksum. Recursive tunneling and fragmentation is a potential issue that can raise corruption rates significantly, and requires careful consideration. Other applications at the intended destination node or another IPv6 node can be impacted if they are allowed to receive datagrams that do not have a transport-layer checksum. It is particularly 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 with a zero UDP checksum, thus this is not an issue. For nodes that implement support for zero-checksum it is important to ensure that only UDP applications that desire zero-checksum can receive and originate zero-checksum packets. Thus, the enabling of zero-checksum needs to be at a port level, not for the entire host or for all use of an interface. Fairhurst & Westerlund Expires April 25, 2013 [Page 27] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 The implications on firewalls, NATs and other middleboxes need to be considered. It is not expected that IPv6 NATs handle IPv6 UDP datagrams in the same way that they handle IPv4 UDP datagrams. This possibly reduces the need to update the checksum. Firewalls are intended to be configured, and therefore may need to be explicitly updated to allow new services or protocols. IPv6 middlebox deployment is not yet as prolific as it is in IPv4. Thus, relatively few current middleboxes may actually block IPv6 UDP with a zero checksum. 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 data stream of the application 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. The use of UDP with no checksum has merits for some applications, such as tunnel encapsulation, and is widely used in IPv4. However, there are dangers for IPv6: There is a bigger risk of corruption and miss-delivery when using zero-checksum in IPv6 compared to IPv4 due to the removed IP header checksum. Thus, applications need to make a new evaluation of the risks of enabling a zero-checksum. Some applications will need to re-consider their usage of zero-checksum, and possibly consider a solution that at least provides the same delivery protection as for IPv4, for example by utilizing UDP-Lite, or by enabling the UDP checksum. Tunnel applications using UDP for encapsulation can in many case use zero-checksum without significant impact on the corruption rate. In some cases, the use of checksum off-loading may help alleviate the checksum processing cost. Recursive tunneling and fragmentation is a difficult issue relating to tunnels in general. There is an increased risk of an error in the inner-most packet when fragmentation when several layers of tunneling and several different reassembly processes are run without verification of correctness. This issue requires future thought and consideration. The conclusion is that UDP zero checksum in IPv6 should be standardized, as it satisfies usage requirements that are currently difficult to address. We do note that a safe deployment of zero- checksum will need to follow a set of constraints listed in Section 5. 8. Acknowledgements Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert, Fairhurst & Westerlund Expires April 25, 2013 [Page 28] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 others in the TSV directorate. Thanks also to: Remi Denis-Courmont, Pekka Savola and many others who contributed comments and ideas via the 6man, behave, lisp and mboned lists. 9. IANA Considerations This document does not require any actions by IANA. 10. 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. 11. References 11.1. Normative References [I-D.ietf-6man-udpchecksums] Eubanks, M., Chimento, P., and M. Westerlund, "UDP Checksums for Tunneled Packets", draft-ietf-6man-udpchecksums-04 (work in progress), September 2012. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 11.2. Informative References [ECMP] "Using the IPv6 flow label for equal cost multipath routing in tunnels (draft-carpenter-flow-ecmp)". [I-D.ietf-intarea-tunnels] Fairhurst & Westerlund Expires April 25, 2013 [Page 29] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 Touch, J. and M. Townsley, "Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-00 (work in progress), March 2010. [I-D.ietf-mboned-auto-multicast] Bumgardner, G., "Automatic Multicast Tunneling", draft-ietf-mboned-auto-multicast-14 (work in progress), June 2012. [LISP] D. Farinacci et al, "Locator/ID Separation Protocol (LISP)", March 2009. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988. [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the Internet checksum", RFC 1141, January 1990. [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007. Fairhurst & Westerlund Expires April 25, 2013 [Page 30] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [Sigcomm2000] Jonathan Stone and Craig Partridge , "When the CRC and TCP Checksum Disagree", 2000. [UDPTT] G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010. 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. Fairhurst & Westerlund Expires April 25, 2013 [Page 31] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 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. 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. Working Group Draft 02 * This version is the result of a major rewrite and re-ordering of the document. * A new section comparing the results have been added. * The constraints list has been significantly altered by removing some and rewording other constraints. * This contains other significant language updates to clarify the intent of this draft. Working Group Draft 03 * Editorial updates Working Group Draft 04 * Resubmission only updating the AMT and RFC2765 references. Working Group Draft 05 * Resubmission to correct editorial NiTs - thanks to Bill Atwood for noting these.Group Draft 05. Working Group Draft 06 * Resubmission to keep draft alive (spelling updated from 05). WoIt that UDP with a zero checksum in IPv6 can safely be used for this purpose, provided that this usage is governed by a set of constraints.rking Group Draft 07 * Resubmission after IESG Feedback Fairhurst & Westerlund Expires April 25, 2013 [Page 32] Internet-Draft Applicability of IPv6 UDP Zero Checksum October 2012 * This document becomes a PS Applicability Statement Authors' Addresses Godred Fairhurst University of Aberdeen School of Engineering Aberdeen, AB24 3UE, Scotland, UK Phone: Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/users/gorry Magnus Westerlund Ericsson Farogatan 6 Stockholm, SE-164 80 Sweden Phone: +46 8 719 0000 Fax: Email: magnus.westerlund@ericsson.com URI: Fairhurst & Westerlund Expires April 25, 2013 [Page 33]