Skip to main content

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]