Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums
draft-ietf-6man-udpzero-10

      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.

A.2.  Comparison

   This section compares the above listed methods to support datagram
   tunneling.  It includes proposals for updating the behaviour of UDP.

   While this comparison focuses on applications that are expected to
   execute on routers, 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 no way to identify the role of the receiving node from a
   received packet.

A.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 would also have been
   able to 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 UDP datagrams 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

Fairhurst & Westerlund    Expires July 25, 2013                [Page 30]
Internet-Draft   Applicability of IPv6 UDP Zero Checksum    January 2013

   with middleboxes, especially Firewalls and NATs, and will likely
   require them to be updated before the extension header is passed.

   Datagrams with a zero UDP 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 a datagram with a zero UDP checksum.

   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.

A.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
   unlikely to be supported by deployed hashing mechanisms, which could
   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.

A.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 method that uses a zero
   UDP checksum, ignoring the UDP 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 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.

Fairhurst & Westerlund    Expires July 25, 2013                [Page 31]
Internet-Draft   Applicability of IPv6 UDP Zero Checksum    January 2013

A.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 tunnel 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
      the zero UDP checksum method with or without an extension header
      require support at both end-points and in middleboxes.  UDP-Lite,
      UDPTT, and the zero UDP checksum method and use of extension
      headers may additionally 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 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
   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.

Fairhurst & Westerlund    Expires July 25, 2013                [Page 32]
Internet-Draft   Applicability of IPv6 UDP Zero Checksum    January 2013

A.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:  The method defined in RFC 2460 has 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
      to select the protocol and validation to confirm the path forwards
      UDP-Lite.

   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 to confirm
      the path forwards a zero UDP checksum.

   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 to select the transport and
      validation to confirm the path forwards UDPTT datagrams.

   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 negotiation to confirm the option is
      supported and validation to confirm the path forwards the option.

Fairhurst & Westerlund    Expires July 25, 2013                [Page 33]
Internet-Draft   Applicability of IPv6 UDP Zero Checksum    January 2013

   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 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,
      with good multiplexing support, medium middlebox traversal that
      never can improve, good load balancing support, in most cases
      requiring negotiation to confirm 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, 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.  Zero UDP
   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 a new
   method becomes standardized, the 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 therefore best
   viewed as a trade-off between a number of more subjective questions:

   o  Is there sufficient interest in using a zero UDP 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 ?

Fairhurst & Westerlund    Expires July 25, 2013                [Page 34]
Internet-Draft   Applicability of IPv6 UDP Zero Checksum    January 2013

   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 answer to the
   above questions are sufficient to update IPv6 to standardise 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 method defined in
   RFC 2460.

Appendix B.  Document Change History

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

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

   Individual Draft 01

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

   Individual Draft 02

      *  Version -02 corrects some typos and editorial NiTs.

      *  Added reference to ECMP for tunnels.

      *  Clarifies the recommendations at the end of the document.

   Working Group Draft 00

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

Fairhurst & Westerlund    Expires July 25, 2013                [Page 35]
Internet-Draft   Applicability of IPv6 UDP Zero Checksum    January 2013

   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).

   Working Group Draft 07

      *  Interim Version

      *  Submission after IESG Feedback

      *  Updates to enable the document to become a PS Applicability
         Statement

Fairhurst & Westerlund    Expires July 25, 2013                [Page 36]
Internet-Draft   Applicability of IPv6 UDP Zero Checksum    January 2013

   Working Group Draft 08

      *  First Version written as a PS Applicability Statement

      *  Changes to reflect decision to update RFC 2460, rather than
         recommend decision

      *  Updates to requirements for middleboxes

      *  Inclusion of requirements for security, API, and tunnel

      *  Move of the rationale for the update to an Annex (former
         section 4)

   Working Group Draft 09

      *  Submission after second WGLC (note mistake corrected in -09).

      *  Clarified role of API for supporting full checksum.

      *  Clarified that full checksum is required in security
         considerations, and therefore noting that full checksum should
         not be treated as an attack - consistent with remainder of
         document.

      *  Added mention that API can set a mode in transport stack - to
         link to similar statement in RFC 2460 update.

      *  Fixed typos.

   Working Group Draft 08

      *  Submission to correct unwanted removal of text from section 5
         bullets 5-7 by GF.

      *  Replaced section 5 text with the text from 08, and reapplied
         the editorial correction.

      *  Note to reviewers: Please compare this revision with -08 used
         in the IETF LC).

Fairhurst & Westerlund    Expires July 25, 2013                [Page 37]
Internet-Draft   Applicability of IPv6 UDP Zero Checksum    January 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    Expires July 25, 2013                [Page 38]