Internet Engineering Task Force                             G. Fairhurst
Internet-Draft                                    University of Aberdeen
Intended status: Standards Track                           M. Westerlund
Expires: April 25, June 14, 2013                                          Ericsson
                                                        October 22,
                                                       December 11, 2012

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

Abstract

   This document provides an applicability statement for the use of UDP
   transport checksums when used with IPv6.  This  It defines recommendations and
   requirements for the use of IPv6 UDP datagrams with a zero UDP
   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
   -
   encapsulations and updates anticipated to examines the related PS role of the IPv6 UDP transport
   checksum.  An appendix presents a summary of the trade-offs that were
   considered in evaluating the safety of the update to RFC 2460 that
   updates use of the UDP checksum with 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, June 14, 2013.

Copyright Notice

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
     1.1.  Document Structure . . . . . . . . . . . . . . . . . . . .  4  6
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5  6
     1.3.  Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . .  5  6
       1.3.1.  Motivation for new approaches  . . . . . . . . . . . .  6  7
       1.3.2.  Reducing forwarding cost . . . . . . . . . . . . . . .  6  7
       1.3.3.  Need to inspect the entire packet  . . . . . . . . . .  7  8
       1.3.4.  Interactions with middleboxes  . . . . . . . . . . . .  7  8
       1.3.5.  Support for load balancing . . . . . . . . . . . . . .  8  9
   2.  Standards-Track Transports . . . . . . . . . . . . . . . . . .  8  9
     2.1.  UDP with Standard Checksum . . . . . . . . . . . . . . . .  8 10
     2.2.  UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . .  9 10
       2.2.1.  Using UDP-Lite as a Tunnel Encapsulation . . . . . . .  9 10
     2.3.  General Tunnel Encapsulations  . . . . . . . . . . . . . .  9 11
   3.  Issues Requiring Consideration . . . . . . . . . . . . . . . . 10 11
     3.1.  Effect of packet modification in the network . . . . . . . 11 12
       3.1.1.  Corruption of the destination IP address . . . . . . . 12 13
       3.1.2.  Corruption of the source IP address  . . . . . . . . . 12 13
       3.1.3.  Corruption of Port Information . . . . . . . . . . . . 13 14
       3.1.4.  Delivery to an unexpected port . . . . . . . . . . . . 13 15
       3.1.5.  Corruption of Fragmentation Information  . . . . . . . 15 16
     3.2.  Where Packet Corruption Occurs . . . . . . . . . . . . . . 18
     3.3.  Validating the network path  . . . . . . . . . . . . . . . 17
     3.3. 18
     3.4.  Applicability of method  . . . . . . . . . . . . . . . . . 17
     3.4. 19
     3.5.  Impact on non-supporting devices or applications . . . . . 18 20
   4.  Evaluation  Constraints on implementation of proposal to update RFC 2460 to support IPv6 nodes supporting
       zero checksum  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     4.1.  Alternatives to 20
   5.  Requirements on the Standard Checksum  . . usage of zero UDP checksum . . . . . . . . 19
     4.2.  Comparison 22
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . 20
       4.2.1.  Middlebox Traversal . . . 24
   7.  Acknowledgements . . . . . . . . . . . . . . 20
       4.2.2.  Load Balancing . . . . . . . . . 25
   8.  IANA Considerations  . . . . . . . . . . . 21
       4.2.3.  Ingress and Egress Performance Implications . . . . . 21
       4.2.4.  Deployability . . . . . 25
   9.  Security Considerations  . . . . . . . . . . . . . . . 22
       4.2.5.  Corruption Detection Strength . . . . 25
   10. References . . . . . . . . 22
       4.2.6.  Comparison Summary . . . . . . . . . . . . . . . . . . 23
   5.  Constraints on implementation of IPv6 nodes supporting
       zero checksum 26
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     10.2. Informative References . . . . . 25
   6.  Requirements on the specification of transported protocols . . 25
   7.  Summary . . . . . . . . . . . 27
   Appendix A.  Evaluation of proposal to update RFC 2460 to
                support zero checksum . . . . . . . . . . . . . . . . 27
   8.  Acknowledgements 28
     A.1.  Alternatives to the Standard Checksum  . . . . . . . . . . 28
     A.2.  Comparison . . . . . . . . . . . . . 28
   9.  IANA Considerations . . . . . . . . . . . 30
       A.2.1.  Middlebox Traversal  . . . . . . . . . . 29
   10. Security Considerations . . . . . . . 30
       A.2.2.  Load Balancing . . . . . . . . . . . . 29
   11. References . . . . . . . . 31
       A.2.3.  Ingress and Egress Performance Implications  . . . . . 31
       A.2.4.  Deployability  . . . . . . . . . . . . . 29
     11.1. Normative References . . . . . . . 32
       A.2.5.  Corruption Detection Strength  . . . . . . . . . . . . 29
     11.2. Informative References 32
       A.2.6.  Comparison Summary . . . . . . . . . . . . . . . . . . 29 33
   Appendix A. B.  Document Change History . . . . . . . . . . . . . . . 31 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 37

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 RFC 2460 mandates use of the a calculated UDP checksum,
   i.e. a non-
   zero non-zero value, due to the lack of an IPv6 header checksum.

   The lack of a possibility to use UDP an IPv6 datagram with a zero-checksum in IPv6 zero UDP
   checksum 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 UDP checksum using IPv4.
   The design of IPv6 raises different issues when considering the
   safety of using a zero checksum
   for UDP checksum with IPv6.  These issues can
   significantly affect applications, both when an endpoint is the
   intended user and when an innocent bystander (received (i.e. a packet received
   by a different endpoint to that intended).  The

   This document examines these the issues and an appendix compares the
   strengths and weaknesses of a number of proposed solutions.  This
   analysis presents
   identifies a set of issues that must be considered and mitigated to
   be able to safely deploy UDP with IPv6 applications that use a zero checksum over
   IPv6. UDP
   checksum.  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 UDP checksum is the best method of the several proposed
   alternatives to meet the goals for certain tunnel applications.  Unfortunately, this

   This document defines recommendations and requirements for use of
   IPv6 datagrams with a zero UDP checksum.  This usage is expected to
   have some initial 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 are provided in middleboxes that support of UDP the zero UDP
   checksum for IPv6 are provided to
   middleboxes. IPv6.  The document therefore derives a set of
   constraints required to ensure safe deployment of a zero checksum in UDP.  It UDP
   checksum.

   Finally, the document 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.

   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 checksum for IPv6.  It
   considers the impact of corruption, the need for validation of the
   path and when it is suitable to use a zero UDP 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. checksum.

   Section 6 5 provides an applicability statement that identifies defines
   requirements and recommendations for protocols and tunnel
   encapsulations that are transported over an IPv6 transport connection flow that
   does not perform a UDP checksum calculation to verify the integrity
   at the transport endpoints.

   Section 7 6 provides the recommendations for standardization of zero-
   checksum zero
   UDP checksum with a summary of the findings and notes remaining
   issues needing future work.

   Appendix A evaluates the set of proposals to update the UDP transport
   behaviour and other alternatives intended to improve support for
   tunnel protocols.  It concludes by assessing the trade-offs of the
   various methods identifying advantages and disadvantages for each
   method.

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.

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]).
   [I-D.ietf-lisp]).  These protocols have proposed motivated an update to IPv6 UDP
   checksum processing.
   These tunnel protocols could processing to 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  The processing cost per tunnel concerns includes both
   state (memory requirements) and per-packet processing costs. processing.

   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  This argues that the computation
   of an additional checksum, when an inner packet is already adequately
   protected, checksum is an unwarranted burden on nodes
   implementing lightweight tunneling protocols. protocols when an inner packet is
   already adequately protected, .  The AMT protocol needs to replicate
   a multicast packet to each gateway tunnel.  In this case, the outer
   IP addresses are different for each tunnel and therefore require a
   different pseudo header to be built for each UDP replicated
   encapsulation.

   The argument concerning redundant processing costs is valid regarding
   the integrity of a tunneled packet.  In some architectures (e.g.  PC-
   based routers), other mechanisms may also significantly reduce
   checksum processing costs: There are implementations that have
   optimised checksum processing algorithms, including the use of
   checksum-offloading.  This processing is readily available for IPv4
   packets at high line rates.  Such processing may be anticipated for
   IPv6 endpoints, allowing 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. consideration the use of a zero UDP checksum.

   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 UDP checksum as valid packets.  If valid.  Use of a zero-checksum
   for zero UDP were to be allowed for IPv6, this would need
   checksum with IPv6 requires firewalls to be updated before the full
   utility of the change is available.

   It can be expected that UDP datagrams with zero-checksum zero UDP checksum will
   initially not have the same middlebox traversal characteristics as
   regular UDP.
   However, if standardized UDP (RFC 2460).  However when implementations follow the
   requirements specified in this document, we can expect an improvement over time of the traversal capabilities.
   capabilities to improve over time.  We also note that deployment of IPv6-
   capable
   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.

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 a 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. the updated IPv6 Flow Label
   Specification [RFC6437] and Equal-Cost Multi-Path routing, ECMP [ECMP]).
   [RFC6438]).  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
   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 UDP, with the exception that it uses a
   different value in the Next Header field in the IPv6 header.  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, damage-
   tolerant payloads and some link-
   layers link-layers may employ different link
   encapsulations when forwarding UDP-
   Lite 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 router/middlebox 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
   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 Next Header value.  The next header 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 enable the option of using a UDP transport checksum to be set
   to zero.  Some of the identified issues are shared with other
   protocols already in use.  The section also provides background to
   the requirements and recommendations that follow.

   The decision by IPv6 RFC 2460 to omit an integrity check at the network
   level
   has meant that the IPv6 transport check checksum 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 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);

   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 mis-delivery 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.

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 pre-established context may
      disregard the datagram as invalid, or could map this to another
      context (if a context for the modified source address was already
      activated).

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

   o  Also, as noted above, ICMP messages relating to the corrupted
      packet will be misdirected to the wrong source.

   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 when
   used with a zero checksum case, UDP checksum, but not when UDP checksums are enabled
   calculated 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 application 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).

   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 process is given only the
       application data associated with a specific 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 datagrams with zero-checksum. a zero UDP
   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 uses a zero UDP checksum can not assume that it is
   the only protocol using a zero UDP checksum.  Therefore, it needs to
   gracefully handle misdelivery. mis-delivery.  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
   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 require 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
   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- zero
   UDP 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 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 zero UDP 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 UDP 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
      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 UDP checksum both vulnerable to undetected errors.

   In conclusion conclusion, fragmentation of packets datagrams with a zero-checksum zero UDP checksum
   does not worsen the situation performance compared to some other commonly used
   tunnel encapsulations.  However, caution is needed for recursive
   tunneling without any additional verification at the different tunnel
   layers.

3.2.  Where Packet Corruption Occurs

   Corruption of IP packets can occur at any point in the transmission
   chain, during packet generation, in the transmission link, in the
   process of routing and switching, etc.  Some steps have checksum or
   Cyclic Redundancy Check (CRC), which reduces the probability for
   erroneous packets being used, but there still exists some probability
   for errors to propagate undetected.  Unfortunately we lack solid
   information about what the most common functions or equipment that
   generate packet corruption are.  However we have indications that
   there are significant variations in where corruption may occur.  Thus
   there is a risk in applying evidence from one domain of usage onto
   another.  Anyone intending general Internet usage must unfortunately
   assume that corruption will occur and cope with it.

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

   A zero value in the UDP checksum field 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 the 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, 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 needed to
   support the use of a new protocol.

   Enabling the use of a zero checksum places new requirements on
   equipment deployed within the network, such as middleboxes.  A
   middlebox (e.g.  Firewalls, Network Address and Port Translation
   (NAPT)) may enable zero checksum usage for a particular range of
   ports.  Note that checksum off-loading and operating system design
   may result in all IPv6 UDP traffic being sent with a calculated
   checksum.  This requires middleboxes that are configured to enable a
   zero UDP checksum to continue to work with bidirectional UDP flows
   that use a zero UDP checksum in only one direction, and therefore
   they must not maintain separate state for a UDP flow based on its
   checksum usage.

   Support along the path between end points may can 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 re-
   negotiate.  Note that a bidirectional path does not necessarily
   support the path, same checksum usage in both the forward and return
   directions: Receipt of a datagram with a zero UDP checksum, does not
   imply that the remote endpoint can also receive a datagram with a
   zero UDP checksum.  This will require periodic validation of the
   path, adding complexity to any solution using the new behavior.

3.3.

3.4.  Applicability of method

   The expectation of the present proposal IPv6 specification update defined in [I-D.ietf-6man-udpchecksums] is that this change would
   only apply to modifies IPv6 router nodes that implement specific protocols that designed
   to 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 UDP checksum.  This document therefore need a specific
   provides an applicability statement for the updated method indicating
   when the mechanism can (and can not) be used.  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

   When the use
   of any new transport mode.  If this method 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 application
   processes could confuse a corrupted or wrongly delivered packet UDP datagram
   with that of data addressed to an the application running on their endpoint unless they accept
   endpoint.

   First of all the using protocol or application must ensure that
   behavior.

3.4. this
   doesn't significantly affect themselves.  That includes receiving
   packets from other protocols or contexts as an effect of the
   corruption of destination or source address and port values.  That
   also includes considering what additional implicit protection
   mechanisms that exist due to the usage the payload of the UDP packet
   with a zero checksum have.

3.5.  Impact on non-supporting devices or applications

   It is important to consider what the potential impact the zero-checksum
   behavior may have of using a zero UDP
   checksum on end-points, end-point 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. update.

   To illustrate a potential issue, why this necessary, consider the implications of a node
   that were to enable
   enabling the use of a zero-checksum zero UDP checksum at the interface level: This
   would result in all applications that listen to a UDP socket
   receiving datagram datagrams 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

   The use of a zero-checksum could zero UDP checksum therefore needs to be enabled only for
   individual ports using by 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- zero UDP checksum.
   These other applications would not be effected affected by this changed
   behavior.  An application that allows the changed behavior should be
   aware of the risk for of corruption and the increased level of
   misdirected traffic, and can be designed robustly to handle this
   risk.

4.  Evaluation  Constraints on implementation of proposal to update RFC 2460 to support IPv6 nodes supporting zero checksum

   This informative section evaluates is an applicability statement that defines requirements
   and recommendations on the proposal to update implementation of IPv6
   [RFC2460], to provide the option that some nodes may suppress
   generation and checking that support
   use of a zero value in the checksum field of a UDP transport checksum.  It also
   compares the proposal with other alternatives.

4.1.  Alternatives to the Standard Checksum

   There are several alternatives to the normal method for calculating
   the datagram.

   All implementations that support this zero UDP Checksum [RFC1071]that do not require a tunnel endpoint checksum method MUST
   conform to
   inspect the entire packet when computing requirements defined below.

   1.   An IPv6 sending node MAY use a checksum.  These include
   (in decreasing order of complexity):

   o  Delta computation of the calculated RFC 2460 checksum from for
        all datagrams that it sends.  This explicitly permits an encapsulated
        interface that supports checksum
      field.  Since the offloading to insert an updated
        UDP checksum is value in all UDP datagrams that it forwards,
        however note that sending a cumulative sum [RFC1624], an
      encapsulating header calculated checksum requires the
        receiver to also perform the checksum calculation.  Checksum
        offloading can normally be derived from switched off for a particular
        interface to ensure that the new pseudo
      header, datagrams are sent with a zero UDP
        checksum.

   2.   IPv6 nodes SHOULD by default NOT allow the inner zero UDP checksum and the sum of
        method for transmission.

   3.   IPv6 nodes MUST provide a way for the other network-layer
      fields not included in application/protocol to
        indicate the pseudo header set of the encapsulated
      packet, in ports that will be enabled to send datagrams
        with a manner resembling incremental checksum update
      [RFC1141]. zero UDP checksum.  This would not require access to the whole packet, but
      does require fields to may be collected across implemented via a socket
        API call, or similar mechanism.  It may also be implemented by
        enabling the header, and
      arithmetic operations on each packet.  The method would only work for packets a pre-assigned static port used by a
        specific tunnel protocol.

   4.   IPv6 nodes MUST provide a method to allow an application/
        protocol to indicate that contain a 2's complement transport checksum (i.e.
      it would not particular UDP datagram requires a
        UDP checksum.  This needs to be appropriate for SCTP or allowed by the operating system
        at any time (e.g. to send keep-alive datagrams), not just when IP fragmentation a
        socket is
      used).

   o  UDP-Lite established.

   5.   The default IPv6 node receiver behaviour MUST discard all IPv6
        packets carrying datagrams with a zero UDP checksum.

   6.   IPv6 nodes MUST provide a way for the checksum coverage set application/protocol to only
        indicate the header portion set of ports that will be enabled to receive
        datagrams with a packet. zero UDP checksum.  This requires may be implemented via
        a pseudo header checksum calculation
      only on the encapsulating packet header.  The computed checksum
      value socket API call, or similar mechanism.  It may also be cached (before adding
        implemented by enabling the Length field) method for each
      flow/destination and subsequently combined with the Length a pre-assigned static
        port used by a specific tunnel protocol.

   7.   IPv6 nodes supporting usage of each
      packet zero UDP checksums MUST allow
        reception using a calculated UDP checksum, also on ports
        configured to minimise per-packet processing.  This value is combined
      with the allow zero UDP payload length for checksum usage.  The sending
        endpoint, e.g. encapsulating ingress, may choose to compute 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 checksum, or may calculate this by default.  In either case,
        the endpoint MUST use the reception method where UDP would be modified to derive specified in RFC2460
        when the checksum only
      from the encapsulating packet protocol header. field is not zero.

   8.   RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams
        with a zero UDP checksum.  This value remains the case for any
        datagram received on a port that does not change between packets in explicitly enable
        processing of a single flow.  The value may be
      cached per flow/destination to minimise per-packet processing.

   o  There zero UDP checksum.  A port for which the zero
        UDP checksum has been a proposal to simply ignore enabled MUST NOT log the datagram solely
        because the UDP checksum value
      on reception at the tunnel egress, allowing is zero.

   9.   IPv6 nodes MAY separately identify received UDP datagrams that
        are discarded with a tunnel ingress zero UDP checksum.  It SHOULD NOT add these
        to
      insert any value correct or false.  For tunnel usage, a non the standard checksum value log, since the endpoint has not been verified.
        This may be used, forcing an RFC 2460 receiver used to drop the packet.  The main downside is support other functions (such as a security
        policy).

   10.  IPv6 nodes that it would be
      impossible receive ICMPv6 messages that refer to identify packets
        with a zero UDP datagram (in checksum MUST provide appropriate checks
        concerning the network or an
      endpoint) that is treated in this way compared to a consistency of the reported packet to verify that
      has
        the reported packet 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 originated from the network layer.  This would allow an endpoint to
      verify delivery to an appropriate end point, but would also
      require IPv6 nodes to correctly handle node, before
        acting upon the additional header, and
      would require changes to middlebox behavior information (e.g. when used with a
      NAT that always adjusts validating the checksum value).

   o address and
        port numbers in the ICMPv6 message body).

5.  Requirements on the usage of zero 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 section is an applicability statement that identifies
   requirements and middleboxes.

   o  IP-in-IP tunneling.  As this method completely dispenses with a
      transport protocol in the outer-layer it has reduced overhead recommendations for protocols and
      complexity, but also reduced functionality.  There is no outer
      checksum tunnel
   encapsulations that are transported over the packet and also no ports to an IPv6 transport flow that
   does not 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 UDP checksum calculation to verify the following
   sections.

4.2.  Comparison

   This section compares integrity
   at the above listed methods to support datagram
   tunneling.  It includes proposals for updating transport endpoints.

   1.   Protocols that enable the behaviour use of UDP.

4.2.1.  Middlebox Traversal

   Regular zero UDP with a standard checksum MUST only
        enable this for a specific port or port-range.  This needs to be
        enabled at the delta encoded
   optimization for creating correct checksums have the best
   possibilities sending and receiving endpoints for successful traversal of a middlebox.  No new
   support UDP flow.

   2.   An integrity mechanism is required. always RECOMMENDED at the protocol
        layer to ensure that corruption rates of delivered payloads or
        encapsulated packets are not increased.  A method mechanism that ignores
        isolates the UDP checksum on reception causes of corruption (e.g. identifying mis-
        delivery, IPv6 header corruption, tunnel header corruption) 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, provide additional information about the status
        of the tunnel (e.g. to suggest a middlebox security attack).

   3.   A protocol that encapsulates Internet Protocol (IPv4 or IPv6)
        packets MAY rely on the path inner packet integrity checks, provided
        that
   attempts to verify a standard checksum the tunnel protocol will not forward packets using
   either significantly increase the
        rate of corruption of these methods, preventing traversal.  A method that ignores the checksum has inner IP packet.  If a significantly
        increased corruption rate can occur, then the protocol MUST
        provide an additional downside in that it prevents
   improvement of middlebox traversal, because there integrity verification mechanism.  Early
        detection is no way desirable to
   identify avoid wasting unnecessary computation/
        transmission capacity/storage for packets that will subsequently
        be discarded.

   4.   A protocol that supports use the modified of a zero UDP checksum behaviour.

   IP-in-IP or GRE tunnels offer good traversal MUST be
        designed so that corruption of middleboxes the protocol header information
        does not result in accumulated state for the protocol.

   5.   A UDP based protocol with an non-tunnel payload or that
        encapsulate non-IP packets MUST have
   not been designed a CRC or other mechanism
        for security, e.g. firewalls.  However, firewalls
   may be expected to be configured to block general tunnels as they
   present checking packet integrity, unless the non-IP packet is
        specifically designed for transmission over lower layers that do
        not provide a large attack surface. packet integrity guarantee.

   6.   A new IPv6 Destination Options header will suffer traversal issues protocol with middleboxes, especially Firewalls and NATs, and will likely
   require them to control feedback SHOULD be updated before robust to changes in
        the extension header is passed.

   Packets using network path.  The set of middleboxes on a path may vary
        during the life of an association.  Endpoints need to discover
        paths with middleboxes that drop packets with a zero UDP
        checksum.  Therefore protocols SHOULD send keep-alive messages
        with a zero checksum will not be passed by any
   middlebox UDP checksum.  An endpoint that validates the checksum using RFC 2460 or updates the
   checksum field, such as NAT or firewalls.  This would require discovers an
   update to correctly handle
        appreciable loss rate for keep-alive packets MAY terminate the zero checksum packets.

   UDP-Lite will require an update of almost all type
        tunnel.  Section 3.1.3 of middleboxes,
   because it requires support RFC 5405 describes requirements for a separate network-layer
        congestion control when using UDP-based transport.

   7.   A protocol
   number.  Once enabled, the method with control feedback that can fall-back to support incremental using UDP
        with a calculated RFC 2460 checksum
   update would are expected to be identical more
        robust 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 changes in the headers for different flows that can be
   included in network path.  Therefore keep-alive
        messages SHOULD include both UDP datagrams with a hash function.  All checksum and
        datagrams with a zero UDP checksum.  This will enable the proposals remote
        endpoint to distinguish between a path failure and dropping of
        datagrams with a zero UDP checksum.

   8.   Middlebox implementations MUST allow forwarding of IPv6 UDP
        datagram with both a zero and standard UDP checksum.

   9.   A middlebox MAY configure a restricted set of specific port
        ranges that use the forward UDP
   protocol number have equal behavior.  UDP-Lite has datagrams with a zero UDP checksum.  The
        middlebox MAY drop IPv6 datagrams with a zero UDP checksum that
        are outside a configured range.

   10.  When a middlebox forwards IPv6 UDP datagram flows containing
        datagrams with both zero and standard UDP checksum, the potential for
   equally good behavior as
        middlebox MUST NOT maintain separate state for UDP.  However, UDP-Lite the flow
        depending on the value of the UDP checksum field.  This
        requirement is currently
   likely necessary to not be supported by deployed hashing mechanisms, which may
   cause enable a load balancer sender that always
        calculates a checksum to not use the transport header in the computed
   hash.  A load balancer communicate via a middlebox with a
        remote endpoint that only uses a zero UDP checksum.

6.  Summary

   This document examines the IP header will have low
   entropy, but could be improved by including the IPv6 the flow label,
   providing that role of the tunnel ingress ensures that different flow labels
   are assigned to different flows.  However, UDP transport checksum when
   used with IPv6.  It presents a transition to summary of the common
   use trade-offs in
   evaluating the safety of good quality flow labels is likely updating RFC 2460 to take time permit an IPv6 endpoint
   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. use a zero UDP checksum field to indicate that no checksum is
   present.

   The other
   proposals introduce use of UDP with a UDP-like header incurring associated data
   overhead.  Processing zero UDP checksum has merits for some
   applications, such as tunnel encapsulation, and is minimised widely used in
   IPv4.  However, there are different dangers for IPv6: There is an
   increased risk of corruption and mis-delivery when using zero UDP
   checksum in IPv6 compared to IPv4, due to the zero-checksum method,
   ignoring lack of an IPv6 header
   checksum.  Thus, applications need to re-evaluate the risks of
   enabling use of a zero UDP checksum on reception, and only slightly higher consider a solution that at
   least provides the same delivery protection as for
   UDPTT, IPv4, for example
   by utilizing UDP-Lite, or by enabling the extension header and UDP-Lite. UDP checksum.  The delta-calculation
   scheme operates on use of
   checksum off-loading may help alleviate the checksum processing cost
   and permit use of a few more fields, but also introduces serious
   failure modes that checksum using method defined in RFC 2460.

   Tunnel applications using UDP for encapsulation can result in many cases use
   a need to calculate a checksum over
   the complete packet.  Regular zero UDP is clearly the most costly to
   process, always requiring checksum calculation over without significant impact on the entire
   packet.

   It is important corruption
   rate.  A well-designed tunnel application should include consistency
   checks to note that validate the zero-checksum method, ignoring
   checksum header information encapsulated with a
   received packet.  In most cases, tunnels encapsulating IP packets can
   rely on reception, the Option Header, UDPTT and UDP-Lite inner packets' own integrity protection.  When correctly
   implemented, such a tunnel endpoint will
   likely incur additional complexities in not be negatively impacted
   by omission of the application to
   incorporate a negotiation transport-layer checksum.  Recursive tunneling and validation mechanism.

4.2.4.  Deployability

   The major factors influencing deployability of these solutions are a
   need to update both end-points,
   fragmentation is a need for negotiation potential issue that can raise corruption rates
   significantly, and requires careful consideration.

   Other UDP applications at the need
   to update middleboxes.  These intended destination node or another
   node can be impacted if they 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 allowed to deploy receive datagrams that
   have a zero UDP checksum.  It is the delta checksum solution.  This
      does important that already deployed
   applications are not modify impacted by a change at the protocol transport layer.  If
   these applications execute on the wire and only needs changes in
      tunnel ingress.

   o  IP-in-IP tunnels should nodes that implement RFC 2460, they
   will discard (and log) all datagrams with a zero UDP checksum.  This
   is not require changes an issue.

   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 end-points, but
      raise issues when traversing firewalls data stream of
   the application and other security-type
      devices, which the control plane of higher layer protocols.
   These checks are expected to require updates.

   o  Ignoring currently performed by the UDP 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 for IPv6, or additions to the tunneling control protocol to
      negotiate support and validate
   the path.

   o  The remaining solutions offer similar deployability. reduced checksum for UDP-Lite
      requires support at both end-points when used with IPv6.

   Recursive tunneling and fragmentation is a difficult issue relating
   to tunnels in middleboxes.  UDPTT and
      Zero-checksum with or without general.  There is an Extension header require support
      at both end-points and increased risk of an error in middleboxes.  UDP-Lite, UDPTT, and Zero-
      checksum and Extension header may additionally require changes or
      additions to the
   inner-most packet when fragmentation results from several layers of
   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 several different reassembly processes are run without
   verification at the tunnel egress. of correctness.  This can significantly
   reduce the probability that a corrupted inner packet is forwarded.
   UDP-Lite, UDPTT issue requires extra thought and
   careful consideration.

   The use of the extension header all provide some
   verification against corruption, but do not verify updated method must consider the inner packet.
   They only provide a strong indication implications on
   firewalls, NATs and other middleboxes.  It is not expected that IPv6
   NATs handle IPv6 UDP datagrams in the delivered packet was
   intended for same way that they handle IPv4
   UDP datagrams.  This possibly reduces the tunnel egress and was correctly delimited.  The
   Zero-checksum, ignoring need to update the checksum on reception and IP-and-IP
   encapsulation provide no verification that a received packet was
   checksum.  Firewalls are intended to be processed by a specific tunnel egress or that the
   inner packet was correct.

4.2.6.  Comparison Summary

   The comparisons above configured, and therefore may
   need to be summarised explicitly updated to allow new services or protocols.
   IPv6 middlebox deployment is not yet as "there prolific as it is no silver bullet
   that will slay all the issues".  One has in IPv4,
   and therefore new devices are expected to select which down side(s)
   can best be lived with.  Focusing on follow the existing solutions, methods
   specified in this can
   be summarized as:

   Regular UDP:  Good middlebox traversal document.

   Each application should consider the implications of choosing an IPv6
   transport that uses a zero UDP checksum, and load balancing consider whether other
   standard methods may be more appropriate, and
      multiplexing, requiring a checksum may simplify
   application design.

7.  Acknowledgements

   Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert,
   others in the outer headers covering TSV directorate.

   Thanks also to: Remi Denis-Courmont, Pekka Savola, Glen Turner, and
   many others who contributed comments and ideas via the whole packet.

   IP 6man, behave,
   lisp and mboned lists.

   Barry Leiba, Ronald Bonica and Stewart Bryant are thanked for
   resulting in IP:  A low complexity encapsulation, a document with limited middlebox
      traversal, no multiplexing support, and currently poor load
      balancing support that could improve over time.

   UDP-Lite: much greater applicability.

   A medium complexity encapsulation, with good multiplexing
      support, limited middlebox traversal, but possible Special thanks to improve over
      time, currently poor load balancing support that could improve
      over time, in most cases requiring application level negotiation P.F. Chimento for review and validation.

   The delta-checksum is an optimization in editorial
   corrections.

8.  IANA Considerations

   This document does not require any actions by IANA.

9.  Security Considerations

   Transport checksums provide the processing of UDP, as
   such it exhibits some first stage of the drawbacks of using regular UDP.

   The remaining proposals may protection for the
   stack, although they can not 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 considered authentication mechanisms.
   These checks are also desirable to ensure packet counters correctly
   log actual activity, and validation.

   UDPTT:  A medium complexity encapsulation, with good multiplexing
      support, limited middlebox traversal, but possible can be used to improve over
      time, good load balancing support, in most cases requiring
      application level negotiation detect unusual behaviours.

   Depending on the hardware design, the processing requirements may
   differ for tunnels that have a zero UDP checksum and validation.

   IPv6 Destination Option IP in IP tunneling:  A medium complexity,
      with no multiplexing support, limited middlebox traversal,
      currently poor load balancing support those that could improve over
      time, in most cases requiring application level negotiation
   calculate a checksum.  This processing overhead may need to be
   considered when deciding whether to enable a tunnel and
      validation. to determine
   an acceptable rate for transmission.

   Transmission of IPv6 Destination Option combined packets with a zero UDP Zero-checksuming:  A medium
      complexity encapsulation, with good multiplexing support, limited
      load balancing support that checksum could improve over time, in most cases
      requiring application level negotiation and validation.

   Ignore reveal
   additional information to an on-path attacker to identify 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.
   operating system or configuration of a sending node.  There is no clear single optimum solution.  If the most important a need is to traverse middleboxes, then the best choice is
   to stay with
   regular UDP and consider probe the optimizations that may be required network path 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 determine whether the simplest.  If one wants
   strengthened error detection, but path supports
   using IPv6 packets with currently limited middlebox
   traversal and load-balancing.  UDP-Lite is appropriate. a zero UDP Zero-
   checksum addresses another set checksum.  The details of constraints, low complexity and a
   need for load balancing from the current Internet, providing it can
   live with currently limited middlebox traversal.

   Techniques
   probing mechanism may differ for load balancing different tunnel encapsulations and middlebox traversal do continue to
   evolve.  Over a long time, developments
   if visible in load balancing have good
   potential the network (e.g. if not using IPsec in encryption
   mode) could reveal additional information to improve.  This time horizon is long since it requires
   both load balancer and end-point updates an on-path attacker to get full benefit.  The
   challenges
   identify the type of middlebox tunnel being used.

   IP-in-IP or GRE tunnels offer good 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 middleboxes that have
   not been designed for security, e.g. firewalls.  However, firewalls
   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 configured to allow UDP with a zero-checksum for
   IPv6 under reasonable constraints, is therefore best viewed block general tunnels as they
   present 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.

5.  Constraints on implementation of IPv6 nodes supporting zero checksum large attack surface.  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
   therefore permits this 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 only 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 ranges
   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 ports.

10.  References

10.1.  Normative References

   [I-D.ietf-6man-udpchecksums]
              Eubanks, M., Chimento, P., and M. Westerlund, "UDP
              Checksums for Tunneled Packets",
              draft-ietf-6man-udpchecksums-05 (work in progress),
              October 2012.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              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.

10.2.  Informative References

   [I-D.ietf-intarea-tunnels]
              Touch, J. and M. Townsley, "Tunnels in the Internet
              Architecture", draft-ietf-intarea-tunnels-00 (work in
              progress), March 2010.

   [I-D.ietf-lisp]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-24 (work in progress), November 2012.

   [I-D.ietf-mboned-auto-multicast]
              Bumgardner, G., "Automatic Multicast Tunneling",
              draft-ietf-mboned-auto-multicast-14 (work in progress),
              June 2012.

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

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

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437, November 2011.

   [RFC6438]  Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
              for Equal Cost Multipath Routing and Link Aggregation in
              Tunnels", RFC 6438, November 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.  Evaluation of proposal to update RFC 2460 to support zero
             checksum

   This informative appendix documents the evaluation of 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, and notes that
   for a particular application some standard methods may be more
   appropriate than using IPv6 with a zero-checksum. zero UDP checksum.

A.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 should remain would not require access to the case whole packet, but
      does require fields to be collected across the header, and
      arithmetic operations on each packet.  The method would only work
      for
       any datagram received 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 port that
      method where UDP would be modified to derive the checksum only
      from the encapsulating packet protocol header.  This value does
      not explicitly enable
       zero-checksum change between packets in a single flow.  The value may be
      cached per flow/destination to minimise per-packet processing.  A port for which zero-checksum

   o  There has been enabled MUST NOT log 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 solely because (in the
       checksum network or an
      endpoint) that is zero, but MAY log treated in this way compared to support other functions
       (such as a security policy).

   5.  IPv6 nodes MAY separately identify received UDP datagrams packet that
       are discarded with
      has actually been corrupted.

   o  A method has been proposed that uses a zero checksum.  It SHOULD NOT add these new (to be defined) IPv6
      Destination Options Header to provide an end-to-end validation
      check at the standard log, since the network layer.  This would allow an endpoint has not been verified.

   6. to
      verify delivery to an appropriate end point, but would also
      require IPv6 nodes that receive ICMPv6 messages that refer to packets correctly handle the additional header, and
      would require changes to middlebox behavior (e.g. when used with a zero
      NAT that always adjusts the checksum value).

   o  UDP modified to disable checksum MUST provide processing
      [I-D.ietf-6man-udpchecksums].  This eliminates the need for a
      checksum calculation, but would require constraints on appropriate checks
       concerning
      usage and updates to end-points and middleboxes.

   o  IP-in-IP tunneling.  As this method completely dispenses with a
      transport protocol in the consistency of outer-layer it has reduced overhead and
      complexity, but also reduced functionality.  There is no outer
      checksum over the reported packet and also no ports to verify that
       the reported packet actually originated from the node, before
       acting upon perform
      demultiplexing between different tunnel types.  This reduces the
      information (e.g. validating the address available upon which a load balancer may act.

   These options are compared and port
       numbers discussed further in the ICMPv6 message body).

6.  Requirements on the specification of transported protocols following
   sections.

A.2.  Comparison

   This section is an applicability statement that identifies
   requirements and recommendations compares the above listed methods to support datagram
   tunneling.  It includes proposals for protocols and tunnel
   encapsulations updating the behaviour of UDP.

   While this comparison focuses on applications that are transported over an IPv6 transport connection
   that does not perform a UDP checksum calculation expected to verify
   execute on routers, the
   integrity distinction between a router and a host is
   not always clear, especially at the transport endpoints.

   1. 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 Tunnels 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 enable ignores the use UDP checksum on reception is expected to
   have a good probability of zero traversal, because most middleboxes
   perform an incremental checksum MUST only enable update.  UDPTT may also traverse a
   middlebox with this only for behaviour.  However, a specific port or port-range.

   2.  UDP Tunnels that encapsulate IP MAY rely middlebox on the inner packet
       integrity checks provided path that the tunnel
   attempts to verify a standard checksum 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 forward packets using
   either of these methods, preventing traversal.  A method that will
       subsequently be discarded.

   3.  An integrity mechanisms is always RECOMMENDED at ignores
   the tunnel layer
       to ensure checksum has an additional downside in that corruption rates it prevents
   improvement of the inner-most packet are not
       increased.  A mechanism middlebox traversal, because there is no way to
   identify UDP datagrams that isolates use the causes modified checksum behaviour.

   IP-in-IP or GRE tunnels offer good traversal of corruption
       (e.g. identifying mis-delivery, 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 corruption, tunnel will suffer traversal issues
   with middleboxes, especially Firewalls and NATs, and will likely
   require them to be updated before the extension header corruption) is expected to also provide additional
       information about passed.

   Datagrams with a zero UDP checksum will not be passed by any
   middlebox that validates the status of checksum using RFC 2460 or updates the tunnel (e.g.
   checksum field, such as NAT or firewalls.  This would require an
   update to suggest correctly handle a
       security attack).

   4.  UDP Tunnels that encapsulate non-IP packets MUST have datagram with a CRC or
       other mechanism zero UDP checksum.

   UDP-Lite will require an update of almost all type of middleboxes,
   because it requires support for checking packet integrity, unless a separate network-layer protocol
   number.  Once enabled, the non-IP
       packet specifically is designed for transmission over lower
       layers method to support incremental checksum
   update would be identical to that do not provide any packet integrity guarantee.  In
       particular, for UDP, but different for checksum
   validation.

A.2.2.  Load Balancing

   The usefulness of solutions for load balancers depends on the tunnel endpoint MUST be designed so
   difference in entropy in the headers for different flows that
       corruption of this information does not result can be
   included in accumulated
       state or incorrect processing of a tunneled payload.

   5.  UDP Tunnels hash function.  All the proposals that support use of a zero-checksum, SHOULD NOT rely
       upon correct reception of the IP and UDP
   protocol information
       (including number have equal behavior.  UDP-Lite has the length of potential for
   equally good behavior as for UDP.  However, UDP-Lite is currently
   unlikely to be supported by deployed hashing mechanisms, which may
   cause a load balancer to not use the packet) when decoding and processing transport header in the packet payload.  In particular, computed
   hash.  A load balancer that only uses the application MUST IP header will have low
   entropy, but could be
       designed so improved by including the IPv6 the flow label,
   providing that corruption the tunnel ingress ensures that different flow labels
   are assigned to different flows.  However, a transition to the common
   use of this information does not result
       in accumulated state or incorrect 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 of and low data overhead.  The other
   proposals introduce a tunneled
       payload.

   6.  A UDP Tunnel egress UDP-like header incurring associated data
   overhead.  Processing is minimised for the method that supports uses a zero
   UDP checksum, ignoring the UDP checksum MUST 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
       allow reception using
   introduces serious failure modes that can result in a standard UDP checksum.  The encapsulating
       endpoint may choose need to compute
   calculate a checksum over the complete datagram.  Regular UDP checksum, or the sending
       endpoint IPv6 stack may enable this by default.  In either case,
       the remote endpoint uses is
   clearly the reception method specified in
       RFC2460.

   7.  UDP Tunnels with control feedback need to be robust most costly to changes in
       network path.  The set of middleboxes on a path may vary during process, always requiring checksum
   calculation over the life of an association.  Endpoints need entire datagram.

   It is important to discover paths
       with middleboxes note that drop packets with a the zero UDP checksum.
       Therefore keep-alive messages SHOULD include both UDP datagrams
       with a checksum method, ignoring
   checksum on reception, the Option Header, UDPTT and UDP datagrams with a zero checksum.  This UDP-Lite will enable
   likely incur additional complexities in the remote endpoint application to distinguish between
   incorporate a path
       failure negotiation and dropping validation mechanism.

A.2.4.  Deployability

   The major factors influencing deployability of UDP datagrams with these solutions are 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 to update both end-points, 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 need for negotiation and zero
       checksum UDP datagrams within the configured range, but may drop
       IPv6 UDP datagrams with a zero checksum that need
   to update middleboxes.  These are outside 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
       configured ranges.

7.  Summary delta checksum solution.  This document examines
      does not modify the role of protocol on the transport checksum when used
   with IPv6, as defined wire and only needs changes in RFC2460.

   It presents a summary of the trade-offs for evaluating the safety of
   updating RFC 2460
      tunnel ingress.

   o  IP-in-IP tunnels should not require changes to permit an IPv6 UDP endpoint the end-points, but
      raise issues when traversing firewalls and other security-type
      devices, which are expected to use a zero value
   in require updates.

   o  Ignoring the checksum field on reception will require changes at both
      end-points.  The never ceasing risk of path failure requires
      additional checks to indicate that no checksum ensure this solution is present.  A
   decision not robust and will
      require changes or additions 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 the tunneling control protocol to
      negotiate support and validate any header information encapsulated 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 a packet.  In most cases tunnels encapsulating IP packets can
   rely on or without an extension header
      require support at both end-points and in middleboxes.  UDP-Lite,
      UDPTT, and the inner packets own integrity protection.  When correctly
   implemented, such a tunnel endpoint will not be negatively impacted
   by omission zero UDP checksum method and use of extension
      headers may additionally require changes or additions to the transport-layer checksum.  Recursive
      tunneling control protocol to negotiate support and path
      validation.

A.2.5.  Corruption Detection Strength

   The standard UDP checksum and
   fragmentation is a potential issue that the delta checksum can raise corruption rates
   significantly, and requires careful consideration.

   Other applications both provide
   some verification at the intended destination node or another IPv6
   node tunnel egress.  This can be impacted if they are allowed to receive datagrams significantly
   reduce the probability that do
   not have a transport-layer checksum.  It corrupted inner packet is particularly important
   that already deployed applications are forwarded.
   UDP-Lite, UDPTT and the extension header all provide some
   verification against corruption, but do not impacted by any change at verify the transport layer.  If these applications execute on nodes inner packet.
   They only provide a strong indication that
   implement RFC 2460, they will reject all datagrams with the delivered packet was
   intended for the tunnel egress and was correctly delimited.  The
   methods using a zero UDP checksum, thus this is not an issue.  For nodes ignoring the UDP checksum on
   reception and IP-and-IP encapsulation all provide no verification
   that implement
   support for zero-checksum it is important a received datagram was intended to ensure be processed by a specific
   tunnel egress or that only UDP
   applications the inner encapsulated packet was correct.

A.2.6.  Comparison Summary

   The comparisons above may be summarised as "there is no silver bullet
   that desire zero-checksum can receive and originate
   zero-checksum packets.  Thus, will slay all the enabling of zero-checksum needs issues".  One has to select which down side(s)
   can best be at 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 port level, not for
      checksum in the outer headers covering the entire host or for all use of an
   interface.

   The implications on firewalls, NATs whole packet.

   IP in IP:  A low complexity encapsulation, with limited middlebox
      traversal, no multiplexing support, and other middleboxes need 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 be
   considered.  It is not expected improve over
      time, currently poor load balancing support that IPv6 NATs handle IPv6 UDP
   datagrams could improve
      over time, in the same way that they handle IPv4 UDP datagrams.  This
   possibly reduces the need most cases requiring application level negotiation
      to update select the checksum.  Firewalls are
   intended to be configured, protocol and therefore may need to be explicitly
   updated validation to allow new services or protocols.  IPv6 middlebox
   deployment confirm the path forwards
      UDP-Lite.

   The delta-checksum is not yet as prolific an optimization in the processing of UDP, as
   such it is in IPv4.  Thus, relatively
   few current middleboxes exhibits some of the drawbacks of using regular UDP.

   The remaining proposals may actually block IPv6 UDP 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.

   In general, UDP-based applications need to employ a mechanism that
   allows a large percentage of the corrupted packets

   UDPTT:  A medium complexity encapsulation, with good multiplexing
      support, limited middlebox traversal, but possible to be removed
   before they reach an application, both improve over
      time, good load balancing support, in most cases requiring
      application level negotiation to protect the data stream of select the application transport and
      validation to confirm the control plane of higher layer protocols.
   These checks are path forwards UDPTT datagrams.

   IPv6 Destination Option IP in IP tunneling:  A medium complexity,
      with no multiplexing support, limited middlebox traversal,
      currently performed by poor load balancing support that could improve over
      time, in most cases requiring negotiation to confirm the UDP checksum for IPv6, or option is
      supported and validation to confirm the reduced checksum for UDP-Lite when used path forwards the option.

   IPv6 Destination Option combined with IPv6.

   The use of UDP with no checksum has merits for some applications,
   such as tunnel Zero-checksuming:  A medium
      complexity 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 with good multiplexing support, limited
      load balancing support that could improve over time, in IPv6 compared to IPv4 due most cases
      requiring negotiation to confirm the removed IP header checksum.  Thus, applications need option is supported and
      validation to make a
   new evaluation of confirm 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 path forwards the same
   delivery protection as for IPv4, for example by utilizing UDP-Lite,
   or by enabling option.

   Ignore the UDP checksum.  Tunnel applications using UDP for
   encapsulation checksum on reception:  A low complexity encapsulation,
      with good multiplexing support, medium middlebox traversal that
      never can improve, good load balancing support, in many case use zero-checksum without significant
   impact on the corruption rate.  In some cases, most cases
      requiring negotiation to confirm the use of checksum
   off-loading may help alleviate option is supported by the checksum processing cost.

   Recursive tunneling
      remote endpoint and fragmentation is a difficult issue relating validation to tunnels in general. confirm the path forwards a zero
      UDP checksum.

   There is an increased risk of an error in no clear single optimum solution.  If the
   inner-most packet when fragmentation when several layers of tunneling most important
   need is to traverse middleboxes, then the best choice is to stay with
   regular UDP and several different reassembly processes are run without
   verification of correctness.  This issue requires future thought consider the optimizations that may be required to
   perform the checksumming.  If one can live with limited middlebox
   traversal, low complexity is necessary and
   consideration.

   The conclusion one does not require load
   balancing, then IP-in-IP tunneling is that the simplest.  If one wants
   strengthened error detection, but with currently limited middlebox
   traversal and load-balancing.  UDP-Lite is appropriate.  Zero UDP zero
   checksum in IPv6 should be
   standardized, as addresses another set of constraints, low complexity and a
   need for load balancing from the current Internet, providing it satisfies usage requirements that are can
   live with currently
   difficult to address.  We limited middlebox traversal.

   Techniques for load balancing and middlebox traversal do note that a safe deployment of zero-
   checksum will need continue to follow
   evolve.  Over a set of constraints listed in
   Section 5.

8.  Acknowledgements

   Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert,
   others long time, developments 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 load balancing have good
   potential to improve.  This document does not require any actions by IANA.

10.  Security Considerations

   Transport checksums provide the first stage time horizon is long since it requires
   both load balancer and end-point updates to get full benefit.  The
   challenges of protection for the
   stack, although they can not be considered authentication mechanisms.
   These checks middlebox traversal are also desirable expected to ensure packet counters correctly
   log actual activity, change with
   time, as device capabilities evolve.  Middleboxes are very prolific
   with a larger proportion of end-user ownership, and can therefore may be used
   expected 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 take long time cycles to evolve.

   One potential advantage is that the deployment of IPv6-capable
   middleboxes are still 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 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 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 using a zero UDP checksum with the
      given constraints (summarised below)?

   o  Are there other avenues of change that will resolve the IPv6 flow label for equal cost multipath
              routing issue in tunnels (draft-carpenter-flow-ecmp)".

   [I-D.ietf-intarea-tunnels]
              Touch, J. a
      better way and M. Townsley, "Tunnels in sufficiently quickly ?

   o  Do we accept 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 complexity cost of having one more solution 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 future?

   The analysis concludes that the
              Internet checksum", RFC 1141, January 1990.

   [RFC1624]  Rijsinghani, A., "Computation of IETF should carefully consider
   constraints on sanctioning the Internet Checksum via
              Incremental Update", RFC 1624, May 1994.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial use of any new transport mode.  The
   6man working group 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.

   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast IETF has determined that the answer to the
   above questions are sufficient to update IPv6 to standardise use of a
   zero UDP Usage Guidelines checksum 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 use by tunnel encapsulations for specific
   applications.

   Each application should consider the implications of Overlapping choosing an 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
   transport that uses a zero UDP checksum.  In many cases, standard
   methods may be more appropriate, and Craig Partridge , "When may simplify application design.
   The use of checksum off-loading may help alleviate the CRC checksum
   processing cost and TCP
              Checksum Disagree", 2000.

   [UDPTT]    G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010. permit use of a checksum using method defined in
   RFC 2460.

Appendix A. 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.

   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

   Working Group Draft 07

      *  Interim Version

      *  Resubmission after IESG Feedback

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

   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)

Authors' Addresses

   Godred Fairhurst
   University of Aberdeen
   School of Engineering
   Aberdeen, AB24 3UE, 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,
   Stockholm  SE-164 80
   Sweden

   Phone: +46 8 719 0000
   Fax:
   Email: magnus.westerlund@ericsson.com
   URI: