Internet Engineering Task Force                             G. Fairhurst
Internet-Draft                                    University of Aberdeen
Intended status: Informational                             M. Westerlund
Expires: February 9, April 27, 2011                                         Ericsson Research
                                                         August 12,
                                                        October 24, 2010

                    IPv6 UDP Checksum Considerations
                       draft-ietf-6man-udpzero-01
                       draft-ietf-6man-udpzero-02

Abstract

   This document examines the role of the UDP transport checksum when
   used with IPv6, as defined in RFC2460.  It presents a summary of the
   trade-offs for evaluating the safety of updating RFC 2460 to permit
   an IPv6 UDP endpoint to use a zero value in the checksum field to
   indicate 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 and provides
   recommendations. encapsulations.  It concludes 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.

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 February 9, April 27, 2011.

Copyright Notice

   Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
     1.1.  Document Structure . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Background . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  5
       1.2.1.  The Role of a Transport Endpoint . . . . . . . . . . .  5
       1.2.2.  The UDP Checksum . . . . . . . . . . . . . . . . . . .  5
       1.2.3.  Differences between IPv6 and IPv4  . . . . . . . . . .  7
     1.3.  Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . .  5
       1.2.1.  7
       1.3.1.  Motivation for new approaches  . . . . . . . . . . . .  5
       1.2.2.  8
       1.3.2.  Reducing forwarding cost . . . . . . . . . . . . . . .  6
       1.2.3.  8
       1.3.3.  Need to inspect the entire packet  . . . . . . . . . .  7
       1.2.4.  9
       1.3.4.  Interactions with middleboxes  . . . . . . . . . . . .  7
       1.2.5.  9
       1.3.5.  Support for load balancing . . . . . . . . . . . . . .  7 10
   2.  Standards-Track Transports . . . . . . . . . . . . . . . . . .  8 10
     2.1.  UDP with Standard Checksum . . . . . . . . . . . . . . . .  8 10
     2.2.  UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . .  8 11
       2.2.1.  Using UDP-Lite as a Tunnel Encapsulation . . . . . . .  8 11
     2.3.  IP in IPv6  General Tunnel Encapsulations  . . . . . . . . . . . . .  9 . 11
   3.  Evaluation of proposal to update RFC 2460 to support zero
       checksum  Issues Requiring Consideration . . . . . . . . . . . . . . . . 12
     3.1.  Effect of packet modification in the network . . . . . . . 13
       3.1.1.  Corruption of the destination IP address . . . . .  9
     3.1.  Alternatives to the Standard Checksum . . 14
       3.1.2.  Corruption of the source IP address  . . . . . . . . . 10
     3.2.  Applicability 14
       3.1.3.  Corruption of method Port Information . . . . . . . . . . . . 15
       3.1.4.  Delivery to an unexpected port . . . . . 11
     3.3.  Effect of packet modification in the network . . . . . . . 12
       3.3.1. 15
       3.1.5.  Corruption of the destination IP address Fragmentation Information  . . . . . . . 12
       3.3.2.  Corruption of 16
     3.2.  Validating the source IP address network path  . . . . . . . . . 13
       3.3.3.  Delivery to an unexpected port . . . . . . 18
     3.3.  Applicability of method  . . . . . . 14
       3.3.4.  Validating the network path . . . . . . . . . . . 19
     3.4.  Impact on non-supporting devices or applications . . 15
       3.3.5.  Requirements on the specification . . . 20
   4.  Evaluation of transported
               protocols proposal to update RFC 2460 to support zero
       checksum . . . . . . . . . . . . . . . . . . . . . . . . . 16
     3.4.  Comparision . . 20
     4.1.  Alternatives to the Standard Checksum  . . . . . . . . . . 20
     4.2.  Comparison . . . . . . . . . . . . 18
   4. . . . . . . . . . . . . 22
       4.2.1.  Middlebox Traversal  . . . . . . . . . . . . . . . . . 22
       4.2.2.  Load Balancing . . . . . . . . . . . . . . . . . . . . 23
       4.2.3.  Ingress and Egress Performance Implications  . . . . . 23
       4.2.4.  Deployability  . . . . . . . . . . . . . . . . . . . . 23
       4.2.5.  Corruption Detection Strength  . . . . . . . . . . . . 24
       4.2.6.  Comparison Summary . . . . . . . . . . . . . . . . . . 24
   5.  Requirements on the specification of transported protocols . . 18
     4.1. 26
     5.1.  Constraints required oin on usage of a zero checksum . . . . 20
   5. . 26
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
   6. 28
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   7. 29
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   8. 30
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   9. 30
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     9.1. 30
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     9.2. 30
     10.2. Informative References . . . . . . . . . . . . . . . . . . 23 30
   Appendix A.  Document Change History . . . . . . . . . . . . . . . 24 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 33

1.  Introduction

   The User Datagram Protocol (UDP) transport was defined by RFC768
   [RFC0768] for IPv4 RFC791 [RFC0791] and is defined in RFC2460
   [RFC2460] for IPv6 hosts and routers.  A  The UDP transport endpoint may
   be either protocol has
   a host or minimal set of features.  This limited set has enabled a router. 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.  These guidelines are applicable to
   this discussion.

   This section provides a background to  The key issues,
   difference between UDP usage with IPv4 and introduces the IPv6 is that IPv6 mandates
   use of the UDP as checksum, i.e. a tunnel transport protocol.

   Section 2 describes a set of standards-track datagram transport
   protocols that may be used to support tunnels.

   Section 3 evaluates proposals non-zero value, due to update the UDP transport behaviour lack of an
   IPv6 header checksum.

   The lack of a possibility to allow use UDP with a zero-checksum in IPv6 has
   been observed as a real problem for better support certain classes of application,
   primarily tunnel protocols.  It focuses on applications.  This class of application has been
   deployed with a
   proposal to eliminate the zero checksum for this use-case with using IPv4.  The design of IPv6 and
   assess the trade-offs that would arise.

   Section 4 reviews the trade offs and provides recommendations.

1.1.  Background

   An Internet transport endpoint should concern itself with raises
   different issues when considering the
   following issues:

   o  Protection safety of the using a zero checksum
   for UDP with IPv6.  These issues can significantly affect
   applications, both when an endpoint transport state from unnecessary extra
      state (i.e.  Invalid state from rogue packets).

   o  Protection of is the endpoint transport state from corruption of
      internal state.

   o  Pre-filtering intended user and when an
   innocent bystander (received by the a different endpoint of erroneous data, to protect the
      transport from unnecessary processing and from corruption that it
      can not itself reject.

   o  Pre-filter of incorrectly addressed destination packets, before
      responding to a source address.

   UDP, as defined in [RFC0768], supports two checksum behaviours when
   used with IPv4.
   intended).  The normal behaviour is for document examines these issues and compares the sender to calculate
   strengths and weaknesses of a checksum over number of proposed solutions.  This
   analysis presents a block set of data issues that includes a pseudo header must be considered and the
   UDP datagram payload.  The
   mitigated to be able to safely deploy UDP header includes with a 16-bit one's
   complement zero checksum that provides a statistical guarantee that the
   payload was not corrupted in transit.  This also allows a receiver over
   IPv6.  The provided comparison of methods is expected to
   verify also be
   useful when considering applications that have different goals from
   the endpoint was ones that initiated the intended destination writing of this document, especially the
   datagram, because
   use of already standardized methods.

   The analysis concludes that using UDP with a zero checksum is the transport pseudo header covers
   best method of the IP
   addresses, port numbers, transport payload length, and Next Header/
   Protocol value corresponding proposed alternatives to meet the UDP transport protocol [RFC1071].
   The length field verifies that the datagram goals for
   certain tunnel applications.  Unfortunately, this usage is not truncated or
   padded.  The checksum therefore protects an application against
   receiving corrupted payload data in place of, or in addition to, expected
   to have some deployment issues related to middleboxes, limiting the
   data that was sent.  Although
   usability more than desired in the IPv4 currently deployed internet.
   However, this limitation will be largest initially and will reduce as
   updates for support of UDP [RFC0768] zero checksum may be
   disabled, applications for IPv6 are recommended provided to enable UDP checksums
   [RFC5405].

   IPv4 UDP checksum control is often a kernel-wide configuration
   control (e.g.  In Linux and BSD), rather than
   middleboxes.  The document therefore derives a per socket call.
   There are set of constraints
   required to ensure safe deployment of zero checksum in UDP.  It also Networking Interface Cards (NICs)
   identifies some issues that automatically
   calculate TCP [RFC0793] require future consideration and UDP checksums on transmission when possibly
   additional research.

1.1.  Document Structure

   Section 1 provides a
   checksum of zero is sent background to key issues, and introduces the NIC, using a method known use
   of UDP as checksum
   offloading.

   The network-layer fields that are validated by a tunnel transport checksum
   are:

   o  Endpoint IP source address (always included in the pseudo header
      of the checksum)

   o  Endpoint IP destination address (always included in the pseudo
      header of the checksum)

   o  Upper layer payload type (always included in the pseudo header of
      the checksum)

   o  IP length protocol.

   Section 2 describes a set of payload (always included standards-track datagram transport
   protocols that may be used to support tunnels.

   Section 3 discusses issues with a zero checksum in UDP for IPv6.  It
   considers the pseudo header impact of corruption, the
      checksum)

   o  Length need for validation of the network layer extension headers (i.e. by correct
      position
   path and when it is suitable to use a zero checksum.

   Section 4 evaluates a set of proposals to update the checksum bytes)

   The transport-layer fields that are validated by a UDP transport
   behaviour and other alternatives intended to improve support for
   tunnel protocols.  It focuses on a proposal to allow a zero checksum
   are:

   o  Transport demultiplexing, i.e. ports (always included in the
      checksum)

   o  Transport payload size (always included in
   for this use-case with IPv6 and assess the checksum)

   Transport endpoints also need to verify trade-offs that would
   arise.

   Section 5.1 lists the correctness of reassembly constraints perceived for safe deployment of any fragmented datagram (unless the application using
   zero-checksum.

   Section 6 provides the payload
   is corruption tolerant, as indicated by UDP-Lite's recommendations for standardization of zero-
   checksum coverage
   field).  For UDP, this is normally provided as with a part summary of the
   integrity check.  Disabling the IPv4 checksum prevents this check.  A
   lack of checksum can lead to findings and notes remaining issues in
   needing future work .

1.2.  Background

   This section provides a translator or middlebox
   (e.g.  Many IPv4 Network Address Translators, NATs, rely background on port
   numbers topics relevant to find the mappings, packet fragments do not carry port
   numbers, so fragments get dropped).  RFC2765 [RFC2765] provides some
   guidance on the processing
   following discussion.

1.2.1.  The Role of fragmented IPv4 UDP datagrams that do
   not carry a UDP checksum.

   IPv6 does not provide a network-layer integrity check.  The removal Transport Endpoint

   An Internet transport endpoint should concern itself with the
   following issues:

   o  Protection of the header checksum endpoint transport state from unnecessary extra
      state (e.g.  Invalid state from rogue packets).

   o  Protection of the IPv6 specification released routers endpoint transport state from a need corruption of
      internal state.

   o  Pre-filtering by the endpoint of erroneous data, to protect the
      transport from unnecessary processing and from corruption that it
      can not itself reject.

   o  Pre-filtering of incorrectly addressed destination packets, before
      responding to update a network-layer source address.

1.2.2.  The UDP Checksum

   UDP, as defined in [RFC0768], supports two checksum behaviours when
   used with IPv4.  The normal behaviour is for each router hop as the IPv6 Hop Count is changed (in contrast sender to the calculate
   a checksum update
   needed when an IPv4 router modifies over a block of data that includes a pseudo header and the Time-To-Live (TTL)).
   UDP datagram payload.  The IP UDP header includes a 16-bit one's
   complement checksum calculation that provides a statistical guarantee that the
   payload was seen as redundant for most
   traffic (with UDP or TCP checksums enabled), and people wanted not corrupted in transit.  This also allows a receiver to
   avoid this extra processing.  However, there was concern
   verify that the
   removal endpoint was the intended destination of the IP header checksum in IPv6 would lessen
   datagram, because the protection
   of transport pseudo header covers the source/destination IP addresses
   addresses, port numbers, transport payload length, and result in a significant (a
   multiplier of ~32,000) increase Next Header/
   Protocol value corresponding to the UDP transport protocol [RFC1071].
   The length field verifies that the datagram is not truncated or
   padded.  The checksum therefore protects an application against
   receiving corrupted payload data in place of, or in addition to, the number of times
   data that a UDP
   packet was accidentally delivered sent.  Although the IPv4 UDP [RFC0768] checksum may be
   disabled, applications are recommended to enable UDP checksums
   [RFC5405].

   The network-layer fields that are validated by a transport checksum
   are:

   o  Endpoint IP source address (always included in the wrong pseudo header
      of the checksum)

   o  Endpoint IP destination address
   and/or apparently sourced from (always included in the wrong source address when pseudo
      header of the UDP
   checksum was set to zero.  This would have had implications on checksum)

   o  Upper layer payload type (always included in the
   detectability pseudo header of mis-delivery
      the checksum)

   o  IP length of a packet to an incorrect endpoint/
   socket, and payload (always included in the robustness pseudo header of the Internet infrastructure.  The use
      checksum)

   o  Length of the network layer extension headers (i.e. by correct
      position of the UDP checksum is therefore required [RFC2460] when endpoint
   application s transmit UDP datagrams over IPv6.

1.2.  Use bytes)

   The transport-layer fields that are validated by a transport checksum
   are:

   o  Transport demultiplexing, i.e. ports (always included in the
      checksum)

   o  Transport payload size (always included in the checksum)

   Transport endpoints also need to verify the correctness of UDP Tunnels

   One increasingly popular use reassembly
   of UDP any fragmented datagram.  For UDP, this is normally provided as a tunneling protocol, where
   a tunnel endpoint encapsulates the packets
   part 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 integrity check.  Disabling the path,
   because many middleboxes support transmission using UDP.  In IPv4 checksum prevents
   this
   use, the receiving endpoint decapsulates check.  A lack of the UDP datagrams header and
   forwards the original packets contained checksum in the payload [RFC5405].
   Tunnels establish virtual links that appear fragments can
   lead to directly connect
   locations that are distant issues in the physical Internet topology and can
   be used a translator or middlebox.  For example, many IPv4
   Network Address Translators, NATs, rely on port numbers to create virtual (private) networks.

1.2.1.  Motivation for new approaches

   A number find the
   mappings, packet fragments do not carry port numbers, so fragments
   get dropped.  RFC2765 [RFC2765] provides some guidance on the
   processing of tunnel encapsulations deployed over fragmented IPv4 have used the UDP transport with datagrams that do not carry a zero UDP
   checksum.  Users of these protocols expect

   IPv4 UDP checksum control is often a similar solution for IPv6.

   A number of tunnel protocols are currently being defined kernel-wide configuration
   control (e.g.

   Automated Multicast Tunnels, AMT [AMT],  In Linux and BSD), rather than a per socket call.
   There are also Networking Interface Cards (NICs) that automatically
   calculate TCP [RFC0793] and the Locator/Identifier
   Separation Protocol, LISP [LISP]).  These protocols have proposed an
   update to IPv6 UDP checksums on transmission when a
   checksum processing.  These tunnel protocols could
   benefit from simpler checksum processing for various reasons:

   o  Reducing forwarding costs, motivated by redundancy present in of zero is sent to the
      encapsulated packet header, since in tunnel encapsulations,
      payload integrity and length verification may be provided by
      higher layer encapsulations (often NIC, using the IPv4, UDP, UDP-Lite,
      or TCP checksums).

   o  Eliminating a need to access method known as checksum
   offloading.

1.2.3.  Differences between IPv6 and IPv4

   IPv6 does not provide a network-layer integrity check.  The removal
   of the entire packet when forwarding header checksum from the
      packet by IPv6 specification released routers
   from a tunnel endpoint.

   o  Enhancing ability to traverse middleboxes, especially Network
      Address Translators, NATs.

   o  A desire need to use update a network-layer checksum for each router hop as
   the port number space to enable load-sharing.

1.2.2.  Reducing forwarding cost

   It IPv6 Hop Count is a common requirement changed (in contrast to terminate a large number of tunnels on
   a single router/host.  Processing per tunnel concerns both state
   (memory requirements) and per-packet processing costs.

   Automatic IP Multicast Without Explicit Tunnels, known as AMT [AMT]
   currently specifies UDP as the transport protocol for packets
   carrying tunneled IP multicast packets. checksum update
   needed when an IPv4 router modifies the Time-To-Live (TTL)).

   The current specification IP header checksum calculation was seen as redundant for AMT requires most
   traffic (with UDP or TCP checksums enabled), and people wanted to
   avoid this extra processing.  However, there was concern that the UDP
   removal of the IP header checksum in IPv6 combined with a UDP
   checksum set to zero would lessen the outer packet header
   should be 0 (see Section 6.6).  It argues that protection of the computation source/
   destination IP addresses and result in a significant (a multiplier of an
   additional checksum, when an inner
   ~32,000) increase in the number of times that a UDP packet is already adequately
   protected, is an unwarranted burden on nodes implementing lightweight
   tunneling protocols.  The AMT protocol needs was
   accidentally delivered to replicate the wrong destination address and/or
   apparently sourced from the wrong source address.  This would have
   had implications on the detectability of mis-delivery of a multicast packet to each gateway tunnel.  In this case, the outer IP addresses
   are different for each tunnel
   an incorrect endpoint/socket, 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 robustness 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 Internet
   infrastructure.  The use of
   checksum-offloading.  This processing the UDP checksum is readily available for IPv4
   packets at high line rates.  Such processing may be anticipated for
   IPv6 endpoints, allowing receivers to reject corrupted therefore required
   [RFC2460] when endpoint application s transmit UDP datagrams over
   IPv6.

1.3.  Use of UDP Tunnels

   One increasingly popular use of UDP is as a tunneling protocol, where
   a tunnel endpoint encapsulates the packets
   without further processing.  Relaxing RFC 2460 of another protocol inside
   UDP datagrams and transmits them to minimise another tunnel endpoint.  Using
   UDP as a tunneling protocol is attractive when the
   processing impact for existing hardware payload protocol
   is a transition policy
   decision, which seems undesirable if at not supported by the same time it yields a
   solution middleboxes that may reduce stability and functionality in future
   network scenarios.

1.2.3.  Need to inspect exist along the entire packet

   The currently-deployed hardware in path,
   because many routers uses a fast-path
   processing that only provides the first n bytes of a packet to middleboxes support transmission using UDP.  In this
   use, the
   forwarding engine, where typically n < 128.  This prevents fast
   processing of a transport checksum over an entire (large) packet.
   Hence receiving endpoint decapsulates the currently defined IPv6 UDP checksum is poorly suited to use
   within a router that is unable to access the entire packet datagrams and does
   not provide checksum-offloading.

1.2.4.  Interactions with middleboxes

   In IPv4, UDP-encapsulation may be desirable for NAT traversal, since
   UDP support is commonly provided.

   IPv6 NAT traversal does not necessarily present
   forwards the same protocol
   issues as for IPv4.  It is not clear that NATs will work original packets contained in the same way
   for IPv6.  Any change to RFC 2460 would also require rewriting (or
   defining) IPv6 NAT behaviour payload [RFC5405].
   Tunnels establish virtual links that appear to achieve consistent widescale
   deployment.

   The requirements for IPv6 firewall traversal directly connect
   locations that are likely be to be
   similar to those for IPv4.  In addition, it distant in the physical Internet topology and can
   be reasonably
   expected that a firewall conforming used to RFC 2460 will not regard create virtual (private) networks.

1.3.1.  Motivation for new approaches

   A number of tunnel encapsulations deployed over IPv4 have used the
   UDP
   datagrams transport with a zero checksum as valid packets.  If an updated IPv6
   mode were to be defined checksum.  Users of these protocols expect
   a similar solution for IPv6, this may IPv6.

   A number of tunnel protocols are also need firewalla currently being defined (e.g.
   Automated Multicast Tunnels, AMT [AMT], and the Locator/Identifier
   Separation Protocol, LISP [LISP]).  These protocols have proposed an
   update to be
   updated.

   Key questions in this space include:

   o  What do IPv6 routers do today with zero-checksum UDP packets? checksum processing.  These tunnel protocols could
   benefit from simpler checksum processing for various reasons:

   o  What types of middleboxes does  Reducing forwarding costs, motivated by redundancy present in the
      encapsulated packet header, since in tunnel protocol need to cross
      (routers, NAT boxes, firewalls, etc.), encapsulations,
      payload integrity and how will those
      middleboxes deal with these packets? length verification may be provided by
      higher layer encapsulations (often using the IPv4, UDP, UDP-Lite,
      or TCP checksums).

   o  What other IPv6 middleboxes exist today, and what would they do?

1.2.5.  Support for load balancing

   The UDP port number fields have been used as  Eliminating a basis need to design load-
   balancing solutions for IPv4.  This approach could also be leveraged
   for IPv6.  However, support for extension headers would increase access the
   complexity of providing standards-compliant solutions for IPv6.

   An alternate method could utilise entire packet when forwarding the IPv6 Flow Label
      packet by a tunnel endpoint.

   o  Enhancing ability to perform load
   balancing.  This would release IPv6 load-balancing devices from the
   need traverse middleboxes, especially Network
      Address Translators, NATs.

   o  A desire to assume semantics for the use of the transport port field.
   This use of the flow-label is consistent with the intended use,
   although further clarity may be needed number space to ensure the field can be
   consistently used for this purpose, (e.g.  Equal-Cost Multi-Path
   routing, ECMP [ECMP]).  Router vendors could be encouraged enable load-sharing.

1.3.2.  Reducing forwarding cost

   It is a common requirement to start
   using the IPv6 Flow Label as terminate a part of the flow hash, providing
   support for ECMP without requiring use large number of UDP.

2.  Standards-Track Transports

   The IETF has defined tunnels on
   a set of IPv6 transports that at be used with
   IPv6.  These are described in the following sections, followed by a
   description of standards single router/host.  Processing per tunnel encapsulations.

2.1. concerns both state
   (memory requirements) and per-packet processing costs.

   Automatic IP Multicast Without Explicit Tunnels, known as AMT [AMT]
   currently specifies UDP with Standard Checksum as the transport protocol for packets
   carrying tunneled IP multicast packets.  The current specification
   for AMT requires that the UDP with standard checksum behaviour is defined in RFC 2460, and the outer packet header
   should be 0 (see Section 6.6).  It argues that the default choice.  Guidelines are provided in [RFC5405].

2.2.  UDP-Lite

   UDP-Lite [RFC3828] offers computation of 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].

   UDP-Lite provides a checksum with
   additional checksum, when an optional partial coverage.  When
   using this option, a datagram inner packet is divided into already adequately
   protected, is an unwarranted burden on nodes implementing lightweight
   tunneling protocols.  The AMT protocol needs to replicate a sensitive part
   (covered by multicast
   packet to each gateway tunnel.  In this case, the checksum) outer IP addresses
   are different for each tunnel and an insensitive part (not covered by the
   checksum).  Errors/corruption in the insensitive part will not cause
   the datagram therefore require a different
   pseudo header to be discarded by the transport layer at built for each UDP replicated encapsulation.

   The argument concerning redundant processing costs is valid regarding
   the receiving
   endpoint.  A minor side-effect integrity of using UDP-Lite is that this was
   specified for damage-tolerant payloads, and a tunneled packet.  In some link-layers may
   employ different link encapsulations when forwarding UDP-Lite
   segments architectures (e.g.  Over radio access bearers).  When the  PC-
   based routers), other mechanisms may also significantly reduce
   checksum covers
   the entire packet, which should be processing costs: There are implementations that have
   optimised checksum processing algorithms, including the default.

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), since UDP-Lite
   provides a transport-layer checksum, including an IP pseudo header
   checksum, in IPv6,
   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 need for a router/middelbox near future.

1.3.3.  Need to
   traverse inspect the entire packet payload.

   In the LISP case, the bytes

   The currently-deployed hardware in many routers uses a fast-path
   processing that would need to be "checksummed" for
   UDP-Lite would be only provides the set of first n bytes that are added to the packet by
   the LISP encapsulating router.  When an IPv4/UDP header is per-pended
   by of a LISP router, the LISP ETR needs packet to calculate the IP header
   checksum over 20 bytes (the IP header).  If an IPv6/UDP-Lite header
   were per-pended by
   forwarding engine, where typically n <= 128.  This prevents fast
   processing of a LISP router, the ETR would need to calculate an
   IP header transport checksum over 48 bytes (the IP pseudo header and the UDP
   header).  This results in an increase in the number of bytes to be entire (large) packet.
   Hence the checksummed for currently defined IPv6 (48 bytes rather than 20), but this UDP checksum is not
   thought poorly suited to be a major additional processing overhead for use
   within a well-
   optimized implementation where router that is unable to access the pre-pended header bytes are
   already in memory.

2.3.  IP in IPv6 Tunnel Encapsulations

   The IETF has defined a set of tunneling protocols.  These do entire packet and does
   not
   include a checksum, since tunnel encapsulations are typically layered
   directly provide checksum-offloading.  Thus enabling checksum calculation
   over the Internet layer (identified by 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 upper layer type
   field) and are
   almost ubiquitous deployment of IPv4 NATs.  There has also been
   discussion of NAT for IPv6, although not used for the same reason as endpoint transport protocols.  That
   is, there in
   IPv4.  If IPv6 NAT becomes a reality they hopefully do not present
   the same protocol issues as for IPv4.  If NAT is little chance of confusing defined for IPv6, it
   should take UDP zero checksum into consideration.

   The requirements for IPv6 firewall traversal are likely be to be
   similar to those for IPv4.  In addition, it can be reasonably
   expected that a tunnel-encapsulated packet firewall conforming to RFC 2460 will not regard UDP
   datagrams with other application data that could result in corruption a zero checksum as valid packets.  If an zero-checksum
   for UDP were to be allowed for IPv6, this would need firewalls to be
   updated before full utility of
   application state or data.

   From the end-to-end perspective, the principal difference change is available.

   It can be expected that UDP with zero-checksum will initially not
   have the
   network-layer Next Header field identifies a separate transport,
   which reduces same middlebox traversal characteristics as regular UDP.
   However, if standardized we can expect an improvement over time of
   the probability traversal capabilities.  We also note that corruption could result deployment of IPv6-
   capable middleboxes is still in the
   packet being delivered to the wrong endpoint or application.
   Specifically, packets are only delivered to protocol modules its initial phases.  Thus, it might
   be that
   process a specific next header value.  The next header field
   therefore provides the number of non-updated boxes quickly become a first-level check very small
   percentage of correct demultiplexing.  In
   contrast, the deployed middleboxes.

1.3.5.  Support for load balancing

   The UDP port space is shared by many diverse applications
   and therefore UDP demultiplexing relies solely on the port numbers.

3.  Evaluation of proposal to update RFC 2460 number fields have been used as a basis to support zero checksum design load-
   balancing solutions for IPv4.  This section evaluates a proposal approach has also been leveraged
   for IPv6.  An alternate method would be to update utilise the IPv6 [RFC2460], to
   provide Flow
   Label as basis for entropy for the option that some nodes may suppress generation and
   checking load balancing.  This would have
   the desirable effect of releasing IPv6 load-balancing devices from
   the UDP transport checksum.  The decision need to omit an
   integrity check at assume semantics for the IPv6 level means that use of the transport check port field
   and also works for all type of transport protocols.  This use of the
   flow-label is
   overloaded consistent with many functions including validating:

   o the endpoint address was not corrupted within a router - i.e.
      This packet was intended use, although further
   clarity may be needed to ensure the field can be received by consistently used
   for this destination and a
      wrong header has not been spliced purpose, (e.g.  Equal-Cost Multi-Path routing, ECMP [ECMP]).

   Router vendors could be encouraged to a different payload;

   o  that extension header processing is correctly delimited - i.e.
      The start using the IPv6 Flow Label
   as a part of data has not been corrupted.  In this case, reception
      of a valid next header value provides some protection;

   o  reassembly processing, when used;

   o  the length of the payload;

   o  the port values - i.e.  The correct application receives the
      payload (applications should also check the expected flow hash, providing support for ECMP without
   requiring use of source
      ports/addresses);

   o  the payload integrity.

   In IPv4, UDP.  However, the first four checks are performed using method for populating the IPv4 outer
   IPv6 header
   checksum.

   In IPv6, these checks occur within with a value for the endpoint stack using flow label is not trivial: If the UDP
   checksum information.  An IPv6 node also relies on
   inner packet uses IPv6, then the header
   information to determine whether to send an ICMPv6 error message
   [RFC2463] and flow label value could be copied to determine
   the node to which this is sent.  Corrupted
   information may lead to misdelivery outer packet header.  However, many current end-points set the
   flow label to an unintended application
   socket on an unexpected host.

3.1.  Alternatives a zero value (thus no entropy).  The ingress of a
   tunnel seeking to provide good entropy in the Standard Checksum

   There are several alternatives flow label field would
   therefore need to the normal method for calculating
   the UDP Checksum create a random flow label value and keep
   corresponding state, so that do not require all packets that were associated with a tunnel endpoint to inspect
   flow would be consistently given the
   entire packet when computing same flow label.  Although
   possible, this complexity may not be desirable in a checksum.  These include (in
   decreasing order of complexity):

   o  Delta computation tunnel ingress.

   The end-to-end use of the checksum from an encapsulated checksum
      field.  Since the checksum flow labels for load balancing is a cumulative sum (RFC 1624), 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 long-term
   solution.  Even if the pseudo header usage of the encapsulated
      packet, in a manner resembling incremental checksum update
      [RFC1141].  This flow label is clarified, there
   would not require access be a transition time before a significant proportion of end-
   points start to the whole packet, but
      does require fields assign a good quality flow label to be collected across the header, and
      arithmetic operations on each packet.  The method would only work
      for packets flows that contain a 2's complement
   they originate, with continued use of load balancing using the
   transport checksum (i.e.
      it would not be appropriate for SCTP or when IP fragmentation header fields until any widespread deployment is
      used). finally
   achieved.

2.  Standards-Track Transports

   The process may be easier for IPv4 over IPv6
      encapsulation, where the encapsulated IPv4 header checksum could
      be used as IETF has defined a basis.

   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 transport protocols that may be cached (before adding the Length field)
   applicable for each
      flow/destination and subsequently combined tunnels with the Length IPv6.  There are also a set of each
      packet network
   layer encapsulation tunnels such as IP-in-IP and GRE.  These already
   standardized solutions are discussed here prior to minimise per-packet processing.  This value is combined
      with the UDP payload length issues, as
   background for the pseudo header, however this
      length is expected to be known when performing packet forwarding.

   o  The proposed UDP Tunnel Transport, UDPTT [UDPTT] suggested a
      method issue description and some comparison of where UDP would be modified to derive the
   issue may already occur.

2.1.  UDP with Standard Checksum

   UDP [RFC0768] with standard checksum only
      from the encapsulating packet protocol header.  This value does
      not change between packets behaviour is defined in a flow.  The value may be cached per
      flow/destination 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 minimise per-packet processing.  This proposal UDP, specified as
   a proposed standard, RFC 3828.  A MIB is not discussed further defined in this document, since function RFC 5097 and
   unicast usage guidelines in [RFC5405].  There is
      nearly the same at least one open
   source implementation as for UDP-Lite.

   o  Use of a new IPv6 Extension Header that part of the Linux kernel since version
   2.6.20.

   UDP-Lite provides an end-to-end
      validation check at a checksum with optional partial coverage.  When
   using this option, a datagram is divided into a sensitive part
   (covered by the network layer.  This would allow an
      endpoint to verify delivery to checksum) and an appropriate end point, but would
      also require IPv6 nodes to correctly handle insensitive part (not covered by the
   checksum).  When the additional header.

   o  UDP modified to disable checksum processing[UDPZ] (if progressed).
      This requires no checksum calculation, but would require
      constraints on appropriate usage.

   These options are discussed further covers the entire packet, UDP-Lite is
   fully equivalent with UDP.  Errors/corruption in the following sections.

3.2.  Applicability of method

   The expectation of insensitive part
   will not cause the present proposal defined in [UDPZ] datagram to be discarded by the transport layer at
   the receiving endpoint.  A minor side-effect of using UDP-Lite is
   that this change would only apply to IPv6 router nodes that implement
   specific protocols which permit omission of UDP checksums.  However,
   the distinction between a router was specified for damage-tolerant payloads, 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 some link-
   layers may employ different link encapsulations when forwarding UDP-
   Lite segments (e.g. radio access bearers).  Most link-layers will
   also
   no way to identify cover the role of a receiver from insensitive part by a received packet.

   Any new method would therefore need strong layer 2 frame CRC.

2.2.1.  Using UDP-Lite as a specific applicability
   statement indicating when the mechanism can (and Tunnel Encapsulation

   Tunnel encapsulations can not) be used.
   There are additional requirements, e.g. fragmentation must not be
   performed, use UDP-Lite (e.g.  Control And
   Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since correct reassembly can not be verified at the
   receiver when there is no checksum.  Allowing fragmentation would
   also open UDP-
   Lite provides a transport-layer checksum, including an IP pseudo
   header checksum, in IPv6, without the receiver to need for a wide range router/middelbox to
   traverse the entire packet payload.  This provides most of mis-behaviours.  Host-based
   fragmentation must therefore be disabled.  Policing this, the
   delivery verifications and
   ensuring correct interactions with still keep the stack, implies much more than
   simply disabling complexity of the checksum algorithm for specific packets at
   checksumming operation low.  UDP-Lite may set the
   transport interface.

   There are also proposals to simply ignore a specific received UDP length of checksum value, however this also can result in problems (e.g. when
   coverage on a per packet basis.  This feature could be used with if a NAT that always adjusts
   tunnel protocol is designed to only verify delivery of the checksum value).

   The IETF should carefully consider constraints on sanctioning the use
   of any new transport mode.  If this is specified tunneled
   payload and widely
   available, it may be expected 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 be used by applications that of UDP, and few middleboxes are
   perceived to gain benefit.  Any solution that uses an end-to-end
   transport protocol, rather than an IP in IP encapsulation, also needs able to minimise
   interpret UDP-Lite and take appropriate actions when forwarding the possibility
   packet.  This makes UDP-Lite less suited to protocols needing general
   Internet support, until such time that end-hosts could confuse UDP-Lite has achieved better
   support in middleboxes and end-points.

2.3.  General Tunnel Encapsulations

   The IETF has defined a corrupted set of tunneling protocols or wrongly delivered packet with network layer
   encapsulations, like IP-in-IP and GRE.  These either do not include a
   checksum or use a checksum that of data addressed to an
   application running on their endpoint.

3.3.  Effect of packet modification is optional, since tunnel
   encapsulations are typically layered directly over the Internet layer
   (identified by the upper layer type in the network

   IP packets may be corrupted IPv6 Next Header field)
   and are also not used as they traverse an Internet path.
   Evidence has been presented [Sigcomm2000] to show that this was once
   an issue endpoint transport protocols.  There is
   little chance of confusing a tunnel-encapsulated packet with IPv4 routers, and occasional corruption other
   application data that could result
   from bad internal router processing in routers corruption of application state
   or hosts.  These
   errors are not detected by data.

   From the strong frame checksums employed at end-to-end perspective, the
   link-layer (RFC 3819).  There principal difference is no current evidence that such cases
   are rare in the modern Internet, nor
   network-layer Next Header field identifies a separate transport,
   which reduces the probability that they may not be applicable corruption could result in the
   packet being delivered to IPv6.  It therefore seems prudent not the wrong endpoint or application.
   Specifically, packets are only delivered to relax this constraint. protocol modules that
   process a specific next header value.  The emergence next header field
   therefore provides a first-level check of low-end IPv6 routers correct demultiplexing.  In
   contrast, the UDP port space is shared by many diverse applications
   and therefore UDP demultiplexing relies solely on the proposed use of NAT
   with port numbers.

3.  Issues Requiring Consideration

   This section evaluates issues around the proposal to update IPv6 further motivate
   [RFC2460], to provide the need option of using a UDP transport checksum
   set to protect from this type zero.  Some of
   error.

   Corruption in the network may result in:

   o  A datagram being mis-delivered identified issues are shared with other
   protocols already in use.

   The decision by IPv6 to omit an integrity check at the wrong host/router or network level
   has meant that the
      wrong transport entity check was overloaded with many
   functions, including validating:

   o  the endpoint address was not corrupted within an endpoint.  Such a datagram needs
      to be discarded.

   o router - i.e.  A datagram payload being corrupted, but still delivered to the
      packet was 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 received by corruption of the length
      field.  Such this destination and a datagram needs wrong
      header has not been spliced to be discarded.

   When a checksum is used with UDP over IPv6, different payload;

   o  that extension header processing is correctly delimited - i.e.
      The start of data has not been corrupted.  In this significantly
   reduces the impact case, reception
      of errors, reducing a valid next header value provides some protection;

   o  reassembly processing, when used;

   o  the probability of undetected
   corruption length of state (and data) on both the host stack and the
   applications using payload;

   o  the transport service. port values - i.e.  The following sections examine correct application receives the impact of modifying each
      payload (applications should also check the expected use of these source
      ports/addresses);

   o  the payload integrity.

   In IPv4, the first four checks are performed using the IPv4 header fields.

3.3.1.  Corruption of
   checksum.

   In IPv6, these checks occur within the destination IP address

   An IP endpoint destination address could be modified in stack using the network
   (e.g. corrupted by an error).  This is not a concern for IPv4,
   because UDP
   checksum information.  An IPv6 node also relies on the IP header checksum will result in
   information to determine whether to send an ICMPv6 error message
   [RFC4443] and to determine the node to which this is sent.  Corrupted
   information may lead to misdelivery to an unintended application
   socket on an unexpected host.

3.1.  Effect of packet being
   discarded by the receiving IP stack.  Such modification in the network can not

   IP packets may be detected when using IPv6.

   There are two possible outcomes:

   o  Delivery corrupted as they traverse an Internet path.
   Evidence has been presented [Sigcomm2000] to a destination address show that is not in use (the packet
      will not be delivered, but this was once
   an issue with IPv4 routers, and occasional corruption could result in an error report).

   o  Delivery to a different destination address.  This modification
      will normally be
   from bad internal router processing in routers or hosts.  These
   errors are not detected by the transport checksum, resulting strong frame checksums employed at the
   link-layer [RFC3819].  There is no current evidence that such cases
   are rare in
      silent discard.  Without this checksum, the packet would modern Internet, nor that they may not be passed applicable
   to the endpoint port demultiplexing function.  If an application
      is bound IPv6.  It therefore seems prudent not to relax this constraint.
   The emergence of low-end IPv6 routers and the associated ports, proposed use of NAT
   with IPv6 further motivate the packet payload will be
      passed need to the application (see the subsequent section on port
      processing).

3.3.2.  Corruption protect from this type of the source IP address

   This section examines what happens when the source address is
   corrupted in transit.  (This is not a concern
   error.

   Corruption in IPv4, because the IP
   header checksum will normally network may result in this packet in:

   o  A datagram being discarded
   by mis-delivered to the receiving IP stack).

   Corruption of an IPv6 source address does not result in wrong host/router or the IP packet
      wrong transport entity within an endpoint.  Such a datagram needs
      to be discarded;

   o  A datagram payload being corrupted, but still delivered to a different endpoint protocol or destination
   address.  If only the source address is corrupted, the
      intended host/router transport entity.  Such a datagram will
   likely needs to
      be either discarded or correctly processed in the intended context, although with erroneous
   origin information.  The result will depend on the by an application or
   protocol that processes the packet.  Some examples are:

   o  An application that requires a per-established context may
      disregard the datagram as invalid, or could map this to another
      context (if a context for the modified source address was already
      activated).
      provides its own integrity checks;

   o  A stateless application will process the datagram outside payload being truncated by corruption of any
      context, a simple example is the ECHO server, which will respond
      with length
      field.  Such a datagram directed needs to be discarded.

   When a checksum is used, this significantly reduces the modified source address.  This
      would create unwanted additional processing load, impact of
   errors, reducing the probability of undetected corruption of state
   (and data) on both the host stack 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
   transport service.

   The following sections examine the creation impact of unnecessary transport-
      layer state at the receiver.  For example, Real Time Prottocol
      (RTP) flows commonly employ a source independent receiver port.
      State is created for modifying each received flow.  Reception of a datagram
      with a corrupted source address will therefore result in
      accumulation these
   header fields.

3.1.1.  Corruption 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 destination IP addresses).

   In general, the effect of corrupting the source address will depend
   upon the protocol that processes the packet and its robustness to
   this error.  For the case where

   An IP endpoint destination address could be modified in the packet is received network
   (e.g. corrupted by a tunnel
   endpoint, the tunnel application an error).  This is expected to correctly handle not a
   corrupted source address.

   The impact of source address modification is more difficult to
   quantify when concern for IPv4,
   because the receiving application is not that originally
   intended and several fields have been modified IP header checksum will result in transit.

3.3.3.  Delivery to an unexpected port

   This section considers what happens if one or both of this packet being
   discarded by the UDP port
   values are corrupted in transit.  (This can also happen with IPv4 receiving IP stack.  Such modification in the zero checksum case, but
   network can not when UDP checksums are enabled or
   with UDP-Lite).  If the ports were corrupted in transit, packets may be delivered to the wrong process (on the intended machine) and/or
   responses or errors sent to the wrong application process (on detected at the
   intended machine). network layer when using IPv6.

   There are several two possible outcomes for a packet that passes and does
   not use the UDP checksum validation: outcomes:

   o  Delivery to a port destination address that is not in use.  The use (the packet is discarded,
      will not be delivered, but could generate result in an ICMPv6 message (e.g. port unreachable). error report);

   o  It could be delivered  Delivery to a different node that implements destination address.  This modification
      will normally be detected by the same
      application, where transport checksum, resulting in
      silent discard.  Without this checksum, the packet may be accepted, generating side-
      effects or accumulated state.

   o  It could would be delivered passed
      to the endpoint port demultiplexing function.  If an application that does not implement
      is bound to the tunnel protocol, where associated ports, the packet may be incorrectly parsed,
      and may payload will be misinterpreted, generating side-effects or accumulated
      state.

   The probability of each outcome depends on
      passed to the statistical
   probability that application (see the source address and the destination subsequent section on port
      processing).

3.1.2.  Corruption of the
   datagram (the source port IP address

   This section examines what happens when the source address is not always used
   corrupted in UDP) match those of
   an existing connection.  Unfortunately, such transit.  This is not a match may be more
   likely for UDP than for connection-oriented transports, concern in IPv4, because
   1.  There is no handshake prior to communication and no sequence
       numbers (as the IP
   header checksum will normally result in TCP, DCCP, or SCTP).  Together, this makes it hard
       to verify that an application is given only packet being discarded
   by the data associated
       with a transport session.

   2.  Applications writers often bind to wild-card values in endpoint
       identifiers and do not always validate correctness receiving IP stack.

   Corruption 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 an IPv6 source address does not realistic: the
   transport owes it to result in the stack to do its best IP packet
   being delivered to reject bogus
   datagrams. a different endpoint protocol or destination
   address.  If checksum coverage only the source address is suppressed, corrupted, the application therefore needs
   to provide a method to detect and discard datagram will
   likely be processed in the unwanted data. intended context, although with erroneous
   origin information.  The
   encapsulated tunnel protocol would need to perform its own integrity
   checks result will depend on any control information and ensure an integrity check is
   applied to the tunneled application or
   protocol that processes the packet.  It is not reasonable to assume  Some examples are:

   o  An application that
   it is safe for one application requires a per-established context may
      disregard the datagram as invalid, or could map this to use another
      context (if a zero checksum value and that
   other applications context for the modified source address was already
      activated).

   o  A stateless application will not.  It is therefore important to consider process the possibility that datagram outside of any
      context, a packet simple example is the ECHO server, which will be received by respond
      with a different node datagram directed to
   that for which it was intended, or that it will arrive at the correct
   tunnel destination with modified source address.  This
      would create unwanted additional processing load, and generate
      traffic to the wrong 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 external
   header.

3.3.4.  Validating creation of unnecessary transport-
      layer state at the network path

   IP transports designed receiver.  For example, Real Time Protocol
      (RTP) [RFC3550] flows commonly employ a source independent
      receiver port.  State is created for use each received flow.
      Reception of a datagram with a corrupted source address will
      therefore result in accumulation of unnecessary state in the general Internet should not
   assume specific characteristics.  Network protocols may reroute
   packets RTP
      state machine, including collision detection and change response (since
      the set of routers and middleboxes along a path.
   Therefore transports such as TCP, SCTP and DCCP are designed to
   negotiate protocol parameters, adapt same synchronization source, SSRC, value will appear to different network path
   characteristics, and receive feedback that arrive
      from multiple source IP addresses).

   In general, the current path is suited
   to effect of corrupting the intended application.  Applications using UDP source address will depend
   upon the protocol that processes the packet and UDP-Lite
   need to provide their own mechanisms its robustness to confirm
   this error.  For the validity of case where the
   current network path.

   Any application/tunnel that seeks packet is received by a tunnel
   endpoint, the tunnel application is expected to make use correctly handle a
   corrupted source address.

   The impact of zero checksum must
   include functionality source address modification is more difficult to both negotiate and verify
   quantify when the receiving application is not that originally
   intended and several fields have been modified in transit.

3.1.3.  Corruption of Port Information

   This section describes what happens if one or both of the UDP port
   values are corrupted in transit.  This can also happen with IPv4 in
   the zero checksum support is provided by case, but not when UDP checksums are enabled or
   with UDP-Lite.  If the path and validate that this
   continues to work (e.g., ports carried in the case transport header of re-routing events) between an
   IPv6 packet were corrupted in transit, packets may be delivered to
   the intended parties.  This increases wrong process (on the complexity of using such a
   solution.

3.3.5.  Requirements on intended machine) and/or responses or
   errors sent to the specification of transported protocols

   If wrong application process (on the IETF were intended
   machine).

3.1.4.  Delivery to revise an unexpected port

   If one combines the standard for UDP using IPv6 for
   specific use-cases corruption effects there are is a set number of questions potential
   outcomes when traffic arrives at an unexpected port.  This section
   discusses these possibilities and their outcomes for a packet that would need
   does not use the UDP checksum validation:

   o  Delivery to be
   answered.  These include:

   Is there a reason why IP in IP port that is not a reasonable choice for
   encapsulation?

   o  Examples of arguments for requiring an encapsulation beyond
      IP-in-IP include the need for NAT traversal and/or firewall
      traversal.  However, the use of any new or non-standard transport
      protocol or variant would additionally require specific support in
      middleboxes.

   o  Another example use.  The packet is a need to perform port-demultiplexing discarded,
      but could generate an ICMPv6 message (e.g. for
      load balancing or ECMP).  This need port unreachable).

   o  It could also be met using UDP,
      UDP-Lite, or another supported transport, or by utilising the IPv6
      flow label.

   Is there a reason why UDP-Lite is not delivered to a reasonable choice for
   encapsulation?

   o  One argument against using UDP-Lite is different node that this transport is not
      implemented on all endpoints.  However, there is at least one open
      source implementation as a part of implements the Linux kernel since version
      2.6.20.

   o  Another argument against using UDP-Lite is that it uses a
      different IPv6 Next Header, which is currently not widely
      supported in middleboxes. same
      application, where the packet may be accepted, generating side-
      effects or accumulated state.

   o  It has also been argued could be delivered to an application that UDP-Lite requires a checksum
      computation.  The UDP-Lite checksum, for instance includes the
      length field, but need does not include implement
      the UDP-Lite payload, tunnel protocol, where the packet may be incorrectly parsed,
      and
      therefore would not require access to may be misinterpreted, generating side-effects or accumulated
      state.

   The probability of each outcome depends on the full datagram payload by statistical
   probability that the tunnel endpoints.

   If source address and the IETF needs to revise destination port of the rationale
   datagram (the source port is not always used in UDP) match those of
   an existing connection.  Unfortunately, such a match may be more
   likely for UDP checksums in RFC
   2460, should we remove the checksum than for connection-oriented transports, because:

   1.  There is no handshake prior to communication and no sequence
       numbers (as in TCP, DCCP, or replace SCTP).  Together, this makes it with one closer hard
       to
   UDP-Lite ?

   Additional topics verify that an application is given only the data associated
       with a transport session.

   2.  Applications writers often bind to be considered wild-card values in making endpoint
       identifiers and do not always validate correctness of datagrams
       they receive (guidance on this decision:

   o  In IPv6, a node selects 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 role of a router or host
   transport owes it to the stack to do its best to reject bogus
   datagrams.

   If checksum coverage is selected
      on a per interface basis.  The role of a router and host are suppressed, the application therefore not fixed, and needs
   to provide a consistent method must be specified
      that can be used to detect and discard the unwanted data.  A
   tunnel protocol would need to perform its own integrity checks on all nodes.  It any
   control information if transported in UDP with zero-checksum.  If the
   tunnel payload is another IP packet, the packets requiring checksums
   can not 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 (or transport mode) will only must be used on a
      specific type fulfilled, this may require an additional
   checksum/CRC and/or integrity protection > of network node (e.g. permitting the payload and tunnel
   headers.

   A protocol using UDP checksum to
      be disabled only on a router).  It is important to note zero-checksum can never assume that
      protocol changes intended for one specific use are often re-used
      for different applications.

   o  Behaviour of NAT/Middleboxes may need to be updated.  This it is the
      case for
   only protocol using a zero UDP checksum and also for use of an IPv6 Extension
      Header carrying a transport checksum.

   o  The method  Therefore, it needs to consider the impact
   gracefully handle misdelivery.  It must be robust to reception of load balancing,
   malformed packets received on a listening port and
      whether this expect that these
   packets may be enabled for the chosen transport contain corrupted data or data associated with a
   completely different protocol.

   If

3.1.5.  Corruption of Fragmentation Information

   The fragmentation information in IPv6 employs a zero checksum approach were 32-bit identity
   field, compared to be adopted by the IETF, only a 16-bit filed 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
   specification should consider adding "More Fragments" field for the following constraints on
   usage:

   1.  IPv6 protocol stack implementations should not by default allow
      last fragment will for example result in the new method.  The default node behaviour must discard all IPv6
       packets carrying UDP packets with no checksum.  RFC 2460
       specifies that IPv6 nodes should log discarded packets.

   2.  A method must packet never being
      considered complete and will eventually be specified timed out and
      discarded.  A corruption in the ID field will result in the
      fragment not being delivered to verify the integrity of intended context thus leaving
      the inner
       (tunneled) packet for each tunnel application rest incomplete, unless that uses a zero-
       checksum.  This method must be robust 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 use
      original packet.  This can occur when the ID field of other
       applications that also use a zero-checksum.

   3.  Non-IP inner (tunneled) packets must have fragment
      is corrupted, resulting in a CRC or other
       mechanism for checking fragment becoming associated with
      another packet integrity.

   4.  If a method proposes selective ignoring and taking the place of another fragment.
      Corruption in the checksum on
       reception, it needs offset information can cause the fragment to be
      misaligned in the reassembly buffer, resulting in incorrect
      reassembly.  Corruption can cause the packet to become shorter or
      longer, however completion of reassembly is much less probable,
      since this would requires consistent corruption of the IPv6
      headers payload length field and the offset field.  The
      possibility of mis-assembly requires the reassembling stack to
      provide guidance strong checks that detect overlap or missing data, note
      however that this is appropriate for
       all use-cases, including defining how currently standardised
       nodes handle any new use.

   5.  The tunneling protocol must not allow fragmentation guaranteed and has recently been
      clarified in "Handling of Overlapping IPv6 Fragments" [RFC5722].

   The erroneous reassembly of the inner packets is a general concern and such
   packets should be discarded instead of being carried.  We suggest the following elaborations passed to higher layer
   processes.  The primary detector of packet length changes is the above restrictions, if IP
   payload length field, with a change secondary check by the transport
   checksum.  The Upper-Layer Packet length field included in the IPv6 specification
       moves forward, pseudo
   header assists in verifying correct reassembly, since the tunnel must not forward an inner (tunneled)
       IPv4 packet that also has a UDP Internet
   checksum equal to 0.  This
       includes not tunneling other tunneling protocols that also use has a
       UDP checksum equal to 0, even if more deeply encapsulated packets
       have checksums low probability of detecting insertion of data or other integrity checking mechanisms.

   6.  If a method proposes recursive tunnels, it needs
   overlap errors (due to provide
       guidance that misplacement of data).The checksum is appropriate for also
   incapable of detecting insertion or removal of all use-cases.  Restrictions may
       be needed to the use zero-data that
   occurs in a multiple of a tunnel encapsulations and the use of
       recursive tunnels (e.g.  Necessary when the endpoint is not
       verified).

   7.

   8. 16-bit chunk.

   The new method should remain restricted to endpoints that
       explicitly enable this mode and adopt the above procedures.

3.4.  Comparision

   This section compares most significant risk of corruption results following mis-
   association of a fragment with a different methods to support datagram
   tunneling. packet.  This includes a proposal for updating risk can be
   significant, since the behaviour size of
   UDP.  This fragments is provided as an example, and does not seek to endorse
   any specific method or suggest that these proposals are ready to be
   standardised.  The final column often the expected functions if an
   additional end-to-end IPv6 extension header were to be required in
   combination with use of same (e.g.
   fragments resulting when the zero checksum option.

   Comparison of functions for selected methods
                               UDP UDPv4 UDPL IP   IP  UDPv6 UDPv6 UPv6
                                    zero      in path MTU results in         zero  EH
                                              IPv4 IPv6

   Incremental cksum update?    X    -     X  N/A   N/A  X     -    ?
   Verification fragmentation of IP length?   X    X     X  X     X    X     X    X
   Detect dest addr corruption? X    X     X  X     -    X     -    X
   Detect NH addr corruption?   -    -     -  X     -    -     -    X
   Flow demux fields present?   X    X     X  -     X    X     X    -
   Detect port corruption?      X    -     X  N/A   N/A  X     -    -
   Detect illegal pay length?   X    X     -  N/A   N/A  X     X    X
   Detect pay corruption?       X    -     ?  N/A   N/A  X     -    -
   Static cksum per flow?       -    X     -  N/A   N/A  -     X    X
   Partial/full midbox support? X    *     ?  ?     ?    X     ?    ?
   Restricted tunnel behaviour  X    *     X  X     ?    X     -    -

   X   = Provided/supported
   -   = Not provided/supported
   N/A = Not applicable
   ?   = Partial support
   *   = Supports a subset
   larger packet, common when addition of functions (i.e. not all combinations)
   Table 1

4.  Requirements on a tunnel encapsulation header
   expands the specification size of a packet).  Detection of this type of error
   requires a checksum or other integrity check of transported protocols

   If the IETF were to revise headers and the standard
   payload.  Such protection is anyway desirable for UDP tunnel
   encapsulations using IPv6 IPv4, since the small fragmentation ID can
   easily result in wrap-around [RFC4963], this is especially the case
   for
   specific use-cases there are a set of questions tunnels that would need to perform flow aggregation [I-D.ietf-intarea-tunnels].

   Tunnel fragmentation behavior matters.  There can be
   answered.  These include:

   Is 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 reason why IP zero-
   checksum in IP is the outer header will not affect the reassembly process.
   When a reasonable choice for
   encapsulation?

   o  Examples tunnel performs outer header fragmentation, the tunnel egress
   needs to perform reassembly of arguments for requiring the outer fragments into an encapsulation beyond
      IP-in-IP include inner
   packet.  The inner packet is either a complete packet or a fragment.
   If it is a fragment, the need for NAT traversal and/or firewall
      traversal.  However, destination endpoint of the use fragment will
   perform reassembly of any new the received fragments.  The complete packet or non-standard transport
   the reassembled fragments will then be processed according to the
   packet next header field.  The receiver may only detect reassembly
   anomalies when it uses a protocol or variant would additionally require specific support in
      middleboxes.

   o  Another example is with a need checksum.  The larger the
   number of reassembly processes to perform port-demultiplexing (e.g. for
      load balancing or ECMP).  This need could also be met using UDP,
      UDP-Lite, or another supported transport, or by utilising which a packet has been subjected,
   the IPv6
      flow label.

   Is there greater the probability of an error.

   o  An IP-in-IP tunnel that performs inner fragmentation has similar
      properties to a reason why UDP-Lite is not UDP tunnel with a reasonable choice for
   encapsulation? zero-checksum that also performs
      inner fragmentation.

   o  One argument against using UDP-Lite is  An IP-in-IP tunnel that this transport is not
      implemented on all endpoints.  However, there performs outer fragmentation has similar
      properties to a UDP tunnel with a zero checksum that performs
      outer fragmentation.

   o  A tunnel that performs outer fragmentation can result in a higher
      level of corruption due to both inner and outer fragmentation,
      enabling more chances for reassembly errors to occur.

   o  Recursive tunneling can result in fragmentation at more than one
      header level, even for inner fragmentation unless it goes to the
      inner most IP header.

   o  Unless there is verification at each reassembly the probability
      for undetected error will increase with the number of times
      fragmentation is recursively applied.  Making IP-in-IP and UDP
      with zero checksum equal subject to this effect.

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

3.2.  Validating the network path

   IP transports designed for use in the general Internet should not
   assume specific path characteristics.  Network protocols may reroute
   packets that change the set of routers and middleboxes along a path.
   Therefore transports such as TCP, SCTP and DCCP have been designed to
   negotiate protocol parameters, adapt to different network path
   characteristics, and receive feedback to verify that the current path
   is suited to the intended application.  Applications using UDP and
   UDP-Lite need to provide their own mechanisms to confirm the validity
   of the current network path.

   The zero-checksum in UDP is explicitly disallowed in RFC2460.  Thus
   it may be expected that any device on the path that has a reason to
   look beyond the IP header will consider such a packet as erroneous or
   illegal and may likely discard it, unless the device is updated to
   support a new behavior.  A pair of end-points intending to use a new
   behavior will therefore not only need to ensure support at each end-
   point, but also that the path between them will deliver packets with
   the new behavior.  This may require negotiation or an explicit
   mandate to use the new behavior by all nodes intended to use a new
   protocol.

   Support along the path between end points may be guaranteed in
   limited deployments by appropriate configuration.  In general, it can
   be expected to take time for deployment of any updated behaviour to
   become ubiquitous.  A sender will need to probe the path to verify
   the expected behavior.  Path characteristics may change, and usage
   therefore should be robust and able to detect a failure of the path
   under normal usage and re-negotiate.  This will require periodic
   validation of the path, adding complexity to any solution using the
   new behavior.

3.3.  Applicability of method

   The expectation of the present proposal defined in [UDPZ] is that
   this change would only apply to IPv6 router nodes that implement
   specific protocols that permit omission of UDP checksums.  However,
   the distinction between a router and a host is not always clear,
   especially at the transport level.  Systems (such as unix-based
   operating systems) routinely provide both functions.  There is also
   no way to identify the role of a receiver from a received packet.

   Any new method would therefore need a specific applicability
   statement indicating when the mechanism can (and can not) be used.
   Enabling this, and ensuring correct interactions with the stack,
   implies much more than simply disabling the checksum algorithm for
   specific packets at the transport interface.

   The IETF should carefully consider constraints on sanctioning the use
   of any new transport mode.  If this is specified and widely
   available, it may be expected to be used by applications that are
   perceived to gain benefit.  Any solution that uses an end-to-end
   transport protocol, rather than an IP-in-IP encapsulation, needs to
   minimise the possibility that end-hosts could confuse a corrupted or
   wrongly delivered packet with that of data addressed to an
   application running on their endpoint unless they accept that
   behavior.

3.4.  Impact on non-supporting devices or applications

   It is important to consider what potential impact the zero-checksum
   behavior may have on end-points, devices or applications that are not
   modified to support the new behavior or by default or preference, use
   the regular behavior.  These applications must not be significantly
   impacted by the changes.

   To illustrate a potential issue, consider the implications of a node
   that were to enable use of a zero-checksum at the interface level:
   This would result in all applications that listen to a UDP socket
   receiving datagram where the checksum was not verified.  This could
   have a significant impact on an application that was not designed
   with the additional robustness needed to handle received packets with
   corruption, creating state or destroying existing state in the
   application.

   In contrast, the use of a zero-checksum could be enabled only for
   individual ports using an explicit request by the application.  In
   this case, applications using other ports would maintain the current
   IPv6 behavior, discarding incoming UDP datagrams with a zero-
   checksum.  These other applications would not be effected by this
   changed behavior.  An application that allows the changed behavior
   should be aware of the risk for corruption and the increased level of
   misdirected traffic, and can be designed robustly to handle this
   risk.

4.  Evaluation of proposal to update RFC 2460 to support zero checksum

   This section evaluates the proposal to update IPv6 [RFC2460], to
   provide the option that some nodes may suppress generation and
   checking of the UDP transport checksum.  It also compares the
   proposal with other alternatives.

4.1.  Alternatives to the Standard Checksum

   There are several alternatives to the normal method for calculating
   the UDP Checksum that do not require a tunnel endpoint to inspect the
   entire packet when computing a checksum.  These include (in
   decreasing order of complexity):

   o  Delta computation of the checksum from an encapsulated checksum
      field.  Since the checksum is a cumulative sum [RFC1624], an
      encapsulating header checksum can be derived from the new pseudo
      header, the inner checksum and the sum of the other network-layer
      fields not included in the pseudo header of the encapsulated
      packet, in a manner resembling incremental checksum update
      [RFC1141].  This would not require access to the whole packet, but
      does require fields to be collected across the header, and
      arithmetic operations on each packet.  The method would only work
      for packets that contain a 2's complement transport checksum (i.e.
      it would not be appropriate for SCTP or when IP fragmentation is
      used).

   o  UDP-Lite with the checksum coverage set to only the header portion
      of a packet.  This requires a pseudo header checksum calculation
      only on the encapsulating packet header.  The computed checksum
      value may be cached (before adding the Length field) for each
      flow/destination and subsequently combined with the Length of each
      packet to minimise per-packet processing.  This value is combined
      with the UDP payload length for the pseudo header, however this
      length is expected to be known when performing packet forwarding.

   o  The proposed UDP Tunnel Transport, UDPTT [UDPTT] suggested a
      method where UDP would be modified to derive the checksum only
      from the encapsulating packet protocol header.  This value does
      not change between packets in a single flow.  The value may be
      cached per flow/destination to minimise per-packet processing.

   o  There has been a proposal to simply ignore the UDP checksum value
      on reception at the tunnel egress, allowing a tunnel ingress to
      insert any value correct or false.  For tunnel usage, a non
      standard checksum value may be used, forcing an RFC 2460 receiver
      to drop the packet.  The main downside is that it would be
      impossible to identify a UDP packet (in the network or an
      endpoint) that is treated in this way compared to a packet that
      has actually been corrupted.

   o  A method has been proposed that uses a new (to be defined) IPv6
      Destination Options Header to provide an end-to-end validation
      check at the network layer.  This would allow an endpoint to
      verify delivery to an appropriate end point, but would also
      require IPv6 nodes to correctly handle the additional header, and
      would require changes to middlebox behavior (e.g. when used with a
      NAT that always adjusts the checksum value).

   o  UDP modified to disable checksum processing[UDPZ].  This requires
      no checksum calculation, but would require constraints on
      appropriate usage and updates to end-points and middleboxes.

   o  IP-in-IP tunneling.  As this method completely dispenses with a
      transport protocol in the outer-layer it has reduced overhead and
      complexity, but also reduced functionality.  There is no outer
      checksum over the packet and also no ports to perform
      demultiplexing between different tunnel types.  This reduces the
      information available upon which a load balancer may act.

   These options are compared and discussed further in the following
   sections.

4.2.  Comparison

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

4.2.1.  Middlebox Traversal

   Regular UDP with a standard checksum or the delta encoded
   optimization for creating correct checksums have the best
   possibilities for successful traversal of a middlebox.  No new
   support is required.

   A method that ignores the UDP checksum on reception is expected to
   have a good probability of traversal, because most middleboxes
   perform an incremental checksum update.  UDPTT may also traverse a
   middlebox with this behaviour.  However, a middlebox on the path that
   attempts to verify a standard checksum will not forward packets using
   either of these methods, preventing traversal.  The methods that
   ignores the checksum has an additional downside in that middlebox
   traversal can not be improved, because there is no way to identify
   which packets use the modified checksum behaviour.

   IP-in-IP or GRE tunnels offer good traversal of middleboxes that have
   not been designed for security, e.g. firewalls.  However, firewalls
   may be expected to be configured to block general tunnels as they
   present a large attack surface.

   A new IPv6 Destination Options header will suffer traversal issues
   with middleboxes, especially Firewalls and NATs, and will likely
   require them to be updated before the extension header is passed.

   Packets using UDP with a zero checksum will not be passed by any
   middlebox that validates the checksum using RFC 2460 or updates the
   checksum field, such as NAT or firewalls.  This would require an
   update to correctly handle the zero checksum packets.

   UDP-Lite will require an update of almost all type of middleboxes,
   because it requires support for a separate network-layer protocol
   number.  Once enabled, the method to support incremental checksum
   update would be identical to that for UDP, but different for checksum
   validation.

4.2.2.  Load Balancing

   The usefulness of solutions for load balancers depends on the
   difference in entropy in the headers for different flows that can be
   included in a hash function.  All the proposals that use the UDP
   protocol number have equal behavior.  UDP-Lite has the potential for
   equally good behavior as for UDP.  However, UDP-Lite is currently
   likely to not be supported by deployed hashing mechanisms, which may
   cause a load balancer to not use the transport header in the computed
   hash.  A load balancer that only uses the IP header will have low
   entropy, but could be improved by including the IPv6 the flow label,
   providing that the tunnel ingress ensures that different flow labels
   are assigned to different flows.  However, a transition to the common
   use of good quality flow labels is likely to take time to deploy.

4.2.3.  Ingress and Egress Performance Implications

   IP-in-IP tunnels are often considered efficient, because they
   introduce very little processing and low data overhead.  The other
   proposals introduce a UDP-like header incurring associated data
   overhead.  Processing is minimised for the zero-checksum method,
   ignoring the checksum on reception, and only slightly higher for
   UDPTT, the extension header and UDP-Lite.  The delta-calculation
   scheme operates on a few more fields, but also introduces serious
   failure modes that can result in a need to calculate a checksum over
   the complete packet.  Regular UDP is clearly the most costly to
   process, always requiring checksum calculation over the entire
   packet.

   It is important to note that the zero-checksum method, ignoring
   checksum on reception, the Option Header, UDPTT and UDP-Lite will
   likely incur additional complexities in the application to
   incorporate a negotiation and validation mechanism.

4.2.4.  Deployability

   The major factors influencing deployability of these solutions are a
   need to update both end-points, a need for negotiation and the need
   to update middleboxes.  These are summarised below:

   o  The solution with the best deployability is regular UDP.  This
      requires no changes and has good middlebox traversal
      characteristics.

   o  The next easiest to deploy is the delta checksum solution.  This
      does not modify the protocol on the wire and only needs changes in
      tunnel ingress.

   o  IP-in-IP tunnels should not require changes to the end-points, but
      raise issues when traversing firewalls and other security-type
      devices, which are expected to require updates.

   o  Ignoring the checksum on reception will require changes at both
      end-points.  The never ceasing risk of path failure requires
      additional checks to ensure this solution is robust and will
      require changes or additions to the tunneling control protocol to
      negotiate support and validate the path.

   o  The remaining solutions offer similar deployability.  UDP-Lite
      requires support at both end-points and in middleboxes.  UDPTT and
      Zero-checksum with or without an Extension header require support
      at both end-points and in middleboxes.  UDP-Lite, UDPTT, and Zero-
      checksum and Extension header may additionally require changes or
      additions to the tunneling control protocol to negotiate support
      and path validation.

4.2.5.  Corruption Detection Strength

   The standard UDP checksum and the delta checksum can both provide
   some verification at the tunnel egress.  This can significantly
   reduce the probability that a corrupted inner packet is forwarded.
   UDP-Lite, UDPTT and the extension header all provide some
   verification against corruption, but do not verify the inner packet.
   They only provide a strong indication that the delivered packet was
   intended for the tunnel egress and was correctly delimited.  The
   Zero-checksum, ignoring the checksum on reception and IP-and-IP
   encapsulation provide no verification that a received packet was
   intended to be processed by a specific tunnel egress or that the
   inner packet was correct.

4.2.6.  Comparison Summary

   The comparisons above may be summarised as "there is no silver bullet
   that will slay all the issues".  One has to select which down side(s)
   can best be lived with.  Focusing on the existing solutions, this can
   be summarized as:

   Regular UDP:  Good middlebox traversal and load balancing and
      multiplexing, requiring a checksum in the outer headers covering
      the whole packet.

   IP in IP:  A low complexity encapsulation, with limited middlebox
      traversal, no multiplexing support, and currently poor load
      balancing support that could improve over time.

   UDP-Lite:  A medium complexity encapsulation, with good multiplexing
      support, limited middlebox traversal, but possible to improve over
      time, currently poor load balancing support that could improve
      over time, in most cases requiring application level negotiation
      and validation.

   The delta-checksum is an optimization in the processing of UDP, as
   such > it exhibits some of the drawbacks of using regular UDP.

   The remaining proposals may be described in similar terms:

   Zero-Checksum:  A low complexity encapsulation, with good
      multiplexing support, limited middlebox traversal that could
      improve over time, good load balancing support, in most cases
      requiring application level negotiation and validation.

   UDPTT:  A medium complexity encapsulation, with good multiplexing
      support, limited middlebox traversal, but possible to improve over
      time, good load balancing support, in most cases requiring
      application level negotiation and validation.

   IPv6 Destination Option IP in IP tunneling:  A medium complexity,
      with no multiplexing support, limited middlebox traversal,
      currently poor load balancing support that could improve over
      time, in most cases requiring application level negotiation and
      validation.

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

   Ignore the checksum on reception:  A low complexity encapsulation,
      with good multiplexing support, medium middlebox traversal that
      never can improve, good load balancing support, in most cases
      requiring application level negotiation and validation.

   There is at least one open
      source implementation as a part of no clear single optimum solution.  If the Linux kernel since version
      2.6.20.

   o  Another argument against using UDP-Lite most important
   need is that it uses a
      different IPv6 Next Header, which to traverse middleboxes, then the best choice is currently not widely
      supported in middleboxes.

   o  It has also been argued that UDP-Lite requires a checksum
      computation.  The UDP-Lite checksum, for instance includes to stay with
   regular UDP and consider the
      length field, but need not include optimizations that may be required to
   perform the UDP-Lite payload, checksumming.  If one can live with limited middlebox
   traversal, low complexity is necessary and
      therefore would one does not require access to the full datagram payload by load
   balancing, then IP-in-IP tunneling is the tunnel endpoints. simplest.  If the IETF needs to revise the rationale for UDP checksums in RFC
   2460, should we remove the checksum or replace it with one closer to wants
   strengthened error detection, but with currently limited middlebox
   traversal and load-balancing.  UDP-Lite ?

   Additional topics to be considered in making this decision:

   o  In IPv6, a node selects the role of a router or host is selected
      on a per interface basis.  The role appropriate.  UDP Zero-
   checksum addresses another set of a router and host are
      therefore not fixed, constraints, low complexity and a consistent method must be specified
      that can be used on all nodes.  It can not be assumed that a
      particular protocol (or transport mode) will only be used on a
      specific type of network node (e.g. permitting
   need for load balancing from the UDP checksum current Internet, providing it can
   live with currently limited middlebox traversal.

   Techniques for load balancing and middlebox traversal do continue to
      be disabled only on
   evolve.  Over a router).  It long time, developments in load balancing have good
   potential to improve.  This time horizon is important long since it requires
   end-point updates to get full benefit.  The challenges of middlebox
   traversal are also expected to note that
      protocol changes intended for one specific use change with time, as device
   capabilities evolve.  Middleboxes are often re-used
      for different applications.

   o  Behaviour very prolific with a larger
   proportion of NAT/Middleboxes end-user ownership, and therefore may need to be updated.  This expected to
   take long time cycles to evolve.  One potential advantage is that the
      case for a zero UDP checksum and also for use
   deployment of an IPv6 Extension
      Header carrying a transport checksum.

   o  The method needs to consider capable middleboxes are still in its initial phase
   and the impact quicker zero-checksum becomes standardized the fewer boxes
   will be non-compliant.

   Thus, the question of load balancing, and whether this may be enabled to allow UDP with a zero-checksum for
   IPv6 under reasonable constraints, is therefore best viewed as a
   trade-off between a number of more subjective questions:

   o  Is there sufficient interest in zero-checksum with the chosen transport protocol. given
      constraints (summarised below)?

   o  If  Are there other avenues of change that will resolve the issue in a method proposes selective ignoring
      better way and sufficiently quickly ?

   o  Do we accept the complexity cost of having one more solution in
      the checksum on
      reception, it needs future?

   The authors do think the answer to provide guidance the above questions are such that is appropriate
   zero-checksum should be standardized for
      all use-cases, including defining how currently standardised nodes
      handle any new use.

4.1. use by tunnel
   encapsulations.

5.  Requirements on the specification of transported protocols

5.1.  Constraints required oin on usage of a zero checksum

   If a zero checksum approach were to be adopted by the IETF, the
   specification should consider adding the following constraints on
   usage:

   1.  IPv6 protocol stack implementations should not by default allow
       the new method.  The default node receiver behaviour must discard
       all IPv6 packets carrying UDP packets with no a zero checksum.

   2.  Implementations must provide a way to signal which the set of ports
       that will be enabled to receive UDP datagrams with a zero
       checksum.  An IPv6 node that enables reception of UDP packets
       with a zero-checksum, must enable this only for a specific port
       or port-range.  This may be implemented via a socket API call, or
       similar mechanism.

   3.  RFC 2460 specifies that IPv6 nodes should log UDP datagrams with
       a zero checksum. zero-checksum.  This should remain the case for any datagram
       received on a port that does not explicitly enable zero-checksum
       processing.  A port for which zero-checksum has been enabled must
       not log the datagram.

   4.   (that pass the checksum).  A stack may separately identify UDP datagrams that are discarded
       with a zero checksum.  It should not add these to the standard
       log, since the endpoint has not been verified.

   5.   A method must be specified to verify  Tunnels that encapsulate IP may rely on the inner packet
       integrity checks provided that the tunnel will not significantly
       increase the rate of corruption of the inner
        (tunneled) packet for each tunnel application that uses IP packet.  If a zero-
        checksum.  This method
       significantly increased corruption rate can occur, then the
       tunnel must be robust provide an additional integrity verification
       mechanism.  An integrity mechanisms is always recommended at the
       tunnel layer to the use of other
        applications ensure that also use a zero-checksum. corruption rates of the inner most
       packet are not increased.

   6.  Tunnels that encapsulate Non-IP inner (tunneled) packets must have a CRC or other
       mechanism for checking packet integrity. integrity, unless the Non-IP packet
       specifically is designed for transmission over lower layers that
       do not provide any packet integrity guarantee.  In particular,
       the application must be designed so that corruption of this
       information does not result in accumulated state or incorrect
       processing of a tunneled payload.

   7.  UDP applications that support use of a zero-checksum, should not
       rely upon correct reception of the IP and UDP protocol
       information (including the length of the packet) when decoding
       and processing the packet payload.  In particular, the
       application must be designed so that corruption of this
       information does not result in accumulated state or incorrect
       processing of a tunneled payload.

   8.   The tunnel must not forward an inner (tunneled) IPv4 packet that
        also has a UDP checksum equal to 0.  This includes not tunneling
        other tunneling protocols that also use a UDP checksum equal to
        0, even if more deeply encapsulated packets have checksums or
        other integrity checking mechanisms.

   9.   The tunneling protocol must not allow fragmentation of the inner
        packets being carried.

   10.  If a method proposes recursive tunnels, it needs to provide
       guidance that is appropriate for all use-cases.  Restrictions may
       be needed to the use of a tunnel encapsulations and the use of
       recursive tunnels (e.g.  Necessary when the endpoint is not
       verified).

   11.

   9.  IPv6 nodes that receive ICMPv6 messages that relate refer to packets
       with a zero UDP checksum must provide appropriate checks
       concerning the consistency of the reported packet was to verify that
       the reported packet actually originated by from the node, before
       acting upon the information (e.g. validating the address and port
       numbers in the ICMPv6 message body).

   Deployment of the new method should needs to remain restricted to endpoints
   that explicitly enable this mode and adopt the above procedures

5. procedures.  Any
   middlebox that examines or interact with the UDP header over IPv6
   should support the new method.

6.  Summary

   This document examines the role of the transport checksum when used
   with IPv6, as defined in RFC2460.

   It presents a summary of the trade-offs for evaluating the safety of
   updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value
   in the checksum field to indicate that no checksum is present.  A
   decision not to include a UDP checksum in received IPv6 datagrams
   could impact a tunnel application that receives these packets.
   However, a well-designed tunnel application should include
   consistency checks to validate any header information encapsulated
   with a packet and ensure that an integrity check is included for each
   tunneled packet.  In most cases tunnels encapsulating IP packets can
   rely on the inner packets own integrity protection.  When correctly
   implemented, such a tunnel endpoint will not be negatively impacted
   by omission of the transport-layer checksum.  However, other  Recursive tunneling and
   fragmentation is a potential issues that can raise corruption rates
   significantly, and requires careful consideration.

   Other applications at the intended destination node or another IPv6
   node can be impacted if they are allowed to receive datagrams without
   a transport-layer checksum.

   In particular, it  It is particularly important that
   already deployed applications are not impacted by any change at the
   transport layer.  If these applications execute on nodes that
   implement RFC 2460, they will reject all datagrams without with a zero UDP checksum.
   checksum, thus this is not an issue.  For nodes that implement
   support for zero-checksum it is important to ensure that only UDP
   applications that desire zero-checksum can receive and originate
   zero-checksum packets.  Thus, the enabling of zero-checksum needs to
   be at a port level, not for the entire host or for all use of an
   interface.

   The implications on firewalls, NATs and other middleboxes need to be
   considered.  It should is not be expected that IPv6 NATs handle IPv6 UDP
   datagrams in the same way as that they handle IPv4 UDP datagrams.  This
   possibly reduces the need to update the checksum.  Firewalls are
   intended to be configured, and therefore may need to be explicitly
   updated to allow new services or protocols.  IPv6 middlebox
   deployment is not yet as prolific as it is in IPv4.  Thus, relatively
   few current middleboxes may actually block IPv6 UDP with a zero
   checksum.

   In general, UDP-based applications need to employ a mechanism that
   allows a large percentage of the corrupted packets to be removed
   before they reach an application, both to protect the applications
   data stream and the control plane of higher layer protocols.  These
   checks are currently performed by the UDP checksum for IPv6, or the
   reduced checksum for UDP-Lite when used with IPv6.

   Although the

   The use of UDP over IPv6 with no checksum may have has merits for some applications,
   such as
   a tunnel encapsulation encapsulation, and is widely used in IPv4, IPv4.  However,
   there are dangers for IPv6 nodes (hosts and routers).  If the use of UDP transport
   without IPv6: There is a checksum were to become prevalent for IPv6 (e.g. tunnel bigger risk of corruption and
   host applications
   miss-delivery when using this are widely deployed), there would also
   be zero-checksum in IPv6 compared to IPv4 due
   to the removed IP header checksum.  Thus, applications needs to make
   a significant danger new evaluation of the Internet carrying an increased volume risks of packets without enabling a transport checksum for other applications,
   potentially including zero-checksum.  Some
   applications that have traditionally used IPv4
   UDP transport without a checksum.  This result is highly undesirable.
   Other solutions will need to be found, such re-consider their usage of zero-checksum,
   and possibly consider a solution that at least provides the same
   delivery protection as for IPv4, for example by utilizing UDP-Lite,
   or by enabling the UDP checksum.  Tunnel applications using UDP for
   encapsulation can in many case use zero-checksum without significant
   impact on the corruption rate.  In some cases, the use of IPV6 with checksum
   off-loading may help alleviate the
   minimal checksum coverage for UDP-Lite. processing cost.

   Recursive tunneling and fragmentation is a difficult issue relating
   to tunnels in general.  There is an increased risk of an error in the
   inner-most packet when fragmentation when several layers of tunneling
   and several different reassembly processes are run without any
   verification of correctness.  This issue requires that the IPv4 future thought and
   consideration.

   The conclusion is that UDP zero checksum in IPv6 solutions to differ, since there should be
   standardized, as it satisfies usage requirements that are different deployed
   infrastructures.

   Guidance has also been provided currently
   difficult to help evaluate the case for
   disabling the address.  We do note that a safe deployment of zero-
   checksum for specific applications

6. will need to follow a set of constraints listed in
   Section 5.1.

7.  Acknowledgements

   Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert,
   Magnus Westerlund,
   others in the TSV directorate.

   Thanks also to: Remi Denis-Courmont, Pekka Savola and many others who
   contributed comments and ideas via the 6man, behave, lisp and mboned
   lists.

7.

8.  IANA Considerations

   This document does not require IANA considerations.

8.

9.  Security Considerations

   Transport checksums provide the first stage of protection for the
   stack, although they can not be considered authentication mechanisms.
   These checks are also desirable to ensure packet counters correctly
   log actual activity, and can be used to detect unusual behaviours.

9.

10.  References

9.1.

10.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC1071]  Braden, R., Borman, D., Partridge, C., and W. Plummer,
              "Computing the Internet checksum", RFC 1071,
              September 1988.

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

9.2.

10.2.  Informative References

   [AMT]      Internet draft, draft-ietf-mboned-auto-multicast-10,
              "Automatic IP Multicast Without Explicit Tunnels (AMT)",
              March 2010.

   [ECMP]     "Using the IPv6 flow label for equal cost multipath
              routing in tunnels (draft-carpenter-flow-ecmp)".

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

   [LISP]     Internet draft, draft-farinacci-lisp-12.txt, "Locator/ID
              Separation Protocol (LISP)", March 2009.

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

   [RFC1141]  Mallory, T. and A. Kullberg, "Incremental updating of the
              Internet checksum", RFC 1141, January 1990.

   [RFC2463]  Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for

   [RFC1624]  Rijsinghani, A., "Computation of the Internet Protocol Version 6
              (IPv6) Specification", Checksum via
              Incremental Update", RFC 2463, December 1998. 1624, May 1994.

   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
              (SIIT)", RFC 2765, February 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.

   [RFC4302]  Kent,

   [RFC4443]  Conta, A., Deering, S., "IP Authentication Header", and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", 4443, March 2006.

   [RFC4963]  Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
              Errors at High Data Rates", RFC 4303, December 2005. 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.

   [Sigcomm2000]
              http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/
              9-1.htm, "When the CRC and TCP Checksum Disagree", 2000.

   [UDPTT]    "The UDP Tunnel Transport mode", Feb 2010.

   [UDPZ]     "UDP Checksums for Tunneled Packets", (Oct 2009.

Appendix A.  Document Change History

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

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

   Individual Draft 01

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

   Individual Draft 02

      *  Version -02 corrects some typos and editorial NiTs.

      *  Added reference to ECMP for tunnels.

      *  Clarifies the recommendations at the end of the document.

   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.

   **TO BE DONE **

      *  This version requires review from proponents and opponents to
         the UDP zero checksum proposal.

      *  Work still to be done includes:

         1.  Text on issues with fragmentation needs to be updated to
             provide more clarity on issues.

         2.  Need a recommendation on whether to permit a multicast
             destination address with a zero UDP checksum.

         3.  Is it OK to send ICMPv6 messages in response to non-
             delivered UDP datagrams with a zero checksum?

         4.  The final section may need to be reworked if this document
             recommends a specific change to RFC 2460.

Authors' Addresses

   Godred Fairhurst
   University of Aberdeen
   School of Engineering
   Aberdeen, AB24 3UE,
   Scotland, UK

   Phone:
   Email: gorry@erg.abdn.ac.uk
   URI:   http://www.erg.abdn.ac.uk/users/gorry

   Magnus Westerlund
   Ericsson Research
   Torshamgatan 23
   Farogatan 6
   Stockholm,   SE-164 80
   Sweden

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