Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
RFC 6936
Document | Type | RFC - Proposed Standard (April 2013) Errata | |
---|---|---|---|
Authors | Gorry Fairhurst , Magnus Westerlund | ||
Last updated | 2015-10-14 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
IESG | Responsible AD | Brian Haberman | |
Send notices to | (None) |
RFC 6936
Fairhurst & Westerlund Standards Track [Page 35] RFC 6936 Applicability of Zero UDP Checksum with IPv6 April 2013 A.2.3. Ingress and Egress Performance Implications IP-in-IP tunnels are often considered efficient, because they introduce very little processing and have low data overhead. The other proposals introduce a UDP-like header, which incurs an associated data overhead. Processing is minimized for the method that uses a zero UDP checksum and for the method that ignores the UDP checksum on reception, and processing is 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 datagram. Regular UDP is clearly the most costly to process, always requiring checksum calculation over the entire datagram. It is important to note that the zero UDP 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. A.2.4. Deployability The major factors influencing deployability of these solutions are a need to update both endpoints, a need for negotiation, and the need to update middleboxes. These are summarized 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 needs changes only in the tunnel ingress. o IP-in-IP tunnels should not require changes to the endpoints, but they raise issues regarding the traversal of firewalls and other security devices, which are expected to require updates. o Ignoring the checksum on reception will require changes at both endpoints. The never-ceasing risk of path failure requires additional checks to ensure that this solution is robust, and it will require changes or additions to the tunnel control protocol to negotiate support and validate the path. o The remaining solutions (including the zero UDP checksum method) offer similar deployability. UDP-Lite requires support at both endpoints and in middleboxes. UDPTT and the zero UDP checksum method, with or without an extension header, require support at Fairhurst & Westerlund Standards Track [Page 36] RFC 6936 Applicability of Zero UDP Checksum with IPv6 April 2013 both endpoints and in middleboxes. UDP-Lite, UDPTT, and the zero UDP checksum method and the use of extension headers may also require changes or additions to the tunnel control protocol to negotiate support and path validation. A.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 they do not verify the inner packet. They provide only a strong indication that the delivered packet was intended for the tunnel egress and was correctly delimited. The methods using a zero UDP checksum, ignoring the UDP checksum on reception, and IP-and-IP encapsulation all provide no verification that a received datagram was intended to be processed by a specific tunnel egress or that the inner encapsulated packet was correct. Section 3.1 discusses experience using specific protocols in well- managed networks. A.2.6. Comparison Summary The comparisons above may be summarized as, "there is no silver bullet that will slay all the issues". One has to select which downsides can best be lived with. Focusing on the existing solutions, they can be summarized as: Regular UDP: The method defined in RFC 2460 has good middlebox traversal and load balancing and multiplexing, and requires a checksum in the outer headers to cover the whole packet. IP-in-IP: A low-complexity encapsulation that has limited middlebox traversal, no multiplexing support, and poor load-balancing support that could improve over time. UDP-Lite: A medium-complexity encapsulation that has good multiplexing support, limited middlebox traversal that may possibly improve over time, and poor load-balancing support that could improve over time, and that, in most cases, requires application-level negotiation to select the protocol and validation to confirm that the path forwards UDP-Lite. Delta computation of a tunnel checksum: The delta checksum is an optimization in the processing of UDP, and, as such, it exhibits some of the drawbacks of using regular UDP. Fairhurst & Westerlund Standards Track [Page 37] RFC 6936 Applicability of Zero UDP Checksum with IPv6 April 2013 The remaining proposals may be described in similar terms: Zero Checksum: A low-complexity encapsulation that has good multiplexing support, limited middlebox traversal that could improve over time, and good load-balancing support, and that, in most cases, requires application-level negotiation and validation to confirm that the path forwards a zero UDP checksum. UDPTT: A medium-complexity encapsulation that has good multiplexing support, limited middlebox traversal that may possibly improve over time, and good load-balancing support, and that, in most cases, requires application-level negotiation to select the transport and validation to confirm the path forwards UDPTT datagrams. IPv6 Destination Option IP-in-IP Tunneling: A medium-complexity encapsulation that has no multiplexing support, limited middlebox traversal, and poor load-balancing support that could improve over time, and that, in most cases, requires negotiation to confirm that the option is supported and validation to confirm the path forwards the option. IPv6 Destination Option Combined with Zero UDP Checksum: A medium- complexity encapsulation that has good multiplexing support, limited load-balancing support that could improve over time, and that, in most cases, requires negotiation to confirm the option is supported and validation to confirm the path forwards the option. Ignore the Checksum on Reception: A low-complexity encapsulation that has good multiplexing support, medium middlebox traversal that can never improve, and good load-balancing support, and that, in most cases, requires negotiation to confirm that the option is supported by the remote endpoint and validation to confirm the path forwards a zero UDP checksum. There is no clear single optimum solution. If the most important need is to traverse middleboxes, 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, if low complexity is necessary, and one does not require load balancing, IP-in-IP tunneling is the simplest. If one wants strengthened error detection, but with the currently limited middlebox traversal and load balancing, UDP-Lite is appropriate. Zero UDP checksum addresses another set of constraints: low complexity and a need for load balancing from the current Internet, provided that the usage can accept the currently limited support for middlebox traversal. Fairhurst & Westerlund Standards Track [Page 38] RFC 6936 Applicability of Zero UDP Checksum with IPv6 April 2013 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, because it requires both load balancer and endpoint 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 a long time to evolve. However, we note that the deployment of IPv6-capable middleboxes is still in its initial phase, and if a new method becomes standardized quickly, fewer boxes will be non-compliant. Thus, the question of whether to permit use of datagrams with a zero UDP checksum for IPv6 under reasonable constraints is best viewed as a trade-off among a number of more subjective questions: o Is there sufficient interest in using a zero UDP checksum with the given constraints (summarized 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 analysis concludes that the IETF should carefully consider constraints on sanctioning the use of any new transport mode. The 6man working group of the IETF has determined that the answers to the above questions are sufficient to update IPv6 to standardize use of a zero UDP checksum for use by tunnel encapsulations for specific applications. Each application should consider the implications of choosing an IPv6 transport that uses a zero UDP checksum. In many cases, standard methods may be more appropriate and may simplify application design. The use of checksum off-loading may help alleviate the checksum processing cost and permit use of a checksum using the method defined in RFC 2460. Fairhurst & Westerlund Standards Track [Page 39] RFC 6936 Applicability of Zero UDP Checksum with IPv6 April 2013 Authors' Addresses Godred Fairhurst University of Aberdeen School of Engineering Aberdeen, AB24 3UE Scotland, UK 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 EMail: magnus.westerlund@ericsson.com Fairhurst & Westerlund Standards Track [Page 40]