[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-fairhurst-tsvwg-6man-udpzero) 00 01 02 03 04 05 06 07 08 09 10 12 RFC 6936

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


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

Abstract

   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.  The document describes issues
   and design principles that need to be considered when UDP is used
   with IPv6 to support tunnel encapsulations and provides
   recommendations.

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, 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



Fairhurst & Westerlund  Expires February 9, 2011                [Page 1]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   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
     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . .  5
       1.2.1.  Motivation for new approaches  . . . . . . . . . . . .  5
       1.2.2.  Reducing forwarding cost . . . . . . . . . . . . . . .  6
       1.2.3.  Need to inspect the entire packet  . . . . . . . . . .  7
       1.2.4.  Interactions with middleboxes  . . . . . . . . . . . .  7
       1.2.5.  Support for load balancing . . . . . . . . . . . . . .  7
   2.  Standards-Track Transports . . . . . . . . . . . . . . . . . .  8
     2.1.  UDP with Standard Checksum . . . . . . . . . . . . . . . .  8
     2.2.  UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . .  8
       2.2.1.  Using UDP-Lite as a Tunnel Encapsulation . . . . . . .  8
     2.3.  IP in IPv6 Tunnel Encapsulations . . . . . . . . . . . . .  9
   3.  Evaluation of proposal to update RFC 2460 to support zero
       checksum . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Alternatives to the Standard Checksum  . . . . . . . . . . 10
     3.2.  Applicability of method  . . . . . . . . . . . . . . . . . 11
     3.3.  Effect of packet modification in the network . . . . . . . 12
       3.3.1.  Corruption of the destination IP address . . . . . . . 12
       3.3.2.  Corruption of the source IP address  . . . . . . . . . 13
       3.3.3.  Delivery to an unexpected port . . . . . . . . . . . . 14
       3.3.4.  Validating the network path  . . . . . . . . . . . . . 15
       3.3.5.  Requirements on the specification of transported
               protocols  . . . . . . . . . . . . . . . . . . . . . . 16
     3.4.  Comparision  . . . . . . . . . . . . . . . . . . . . . . . 18
   4.  Requirements on the specification of transported protocols . . 18
     4.1.  Constraints required oin usage of a zero checksum  . . . . 20
   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Appendix A.  Document Change History . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25







Fairhurst & Westerlund  Expires February 9, 2011                [Page 2]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


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 UDP transport endpoint may
   be either a host or a router.  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 key issues, and introduces the
   use of UDP as a tunnel transport protocol.

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

   Section 3 evaluates proposals to update the UDP transport behaviour
   to allow for better support of tunnel protocols.  It focuses on a
   proposal to eliminate the checksum for this use-case with 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 the
   following issues:

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

   o  Protection of the endpoint transport state from 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-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.  The normal behaviour is for the sender to calculate
   a checksum over a block of data that includes a pseudo header and the
   UDP datagram payload.  The UDP header includes a 16-bit one's
   complement checksum that provides a statistical guarantee that the
   payload was not corrupted in transit.  This also allows a receiver to
   verify that the endpoint was the intended destination of the



Fairhurst & Westerlund  Expires February 9, 2011                [Page 3]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   datagram, because the transport pseudo header covers the IP
   addresses, port numbers, transport payload length, and 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
   data that was sent.  Although the IPv4 UDP [RFC0768] checksum may be
   disabled, applications are recommended to enable UDP checksums
   [RFC5405].

   IPv4 UDP checksum control is often a kernel-wide configuration
   control (e.g.  In Linux and BSD), rather than a per socket call.
   There are also Networking Interface Cards (NICs) that automatically
   calculate TCP [RFC0793] and UDP checksums on transmission when a
   checksum of zero is sent to the NIC, using a method known as checksum
   offloading.

   The network-layer fields that are validated by a 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 of payload (always included in the pseudo header of the
      checksum)

   o  Length of the network layer extension headers (i.e. by correct
      position of the checksum 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 reassembly
   of any fragmented datagram (unless the application using the payload
   is corruption tolerant, as indicated by UDP-Lite's checksum coverage
   field).  For UDP, this is normally provided as a part of the
   integrity check.  Disabling the IPv4 checksum prevents this check.  A



Fairhurst & Westerlund  Expires February 9, 2011                [Page 4]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   lack of checksum can lead to issues in a translator or middlebox
   (e.g.  Many IPv4 Network Address Translators, NATs, rely on port
   numbers to find the mappings, packet fragments do not carry port
   numbers, so fragments get dropped).  RFC2765 [RFC2765] provides some
   guidance on the processing of fragmented IPv4 UDP datagrams that do
   not carry a UDP checksum.

   IPv6 does not provide a network-layer integrity check.  The removal
   of the header checksum from the IPv6 specification released routers
   from a need to update a network-layer checksum for each router hop as
   the IPv6 Hop Count is changed (in contrast to the checksum update
   needed when an IPv4 router modifies the Time-To-Live (TTL)).

   The IP header checksum calculation was seen as redundant for most
   traffic (with UDP or TCP checksums enabled), and people wanted to
   avoid this extra processing.  However, there was concern that the
   removal of the IP header checksum in IPv6 would lessen the protection
   of the source/destination IP addresses and result in a significant (a
   multiplier of ~32,000) increase in the number of times that a UDP
   packet was accidentally delivered to the wrong destination address
   and/or apparently sourced from the wrong source address when the UDP
   checksum was set to zero.  This would have had implications on the
   detectability of mis-delivery of a packet to an incorrect endpoint/
   socket, and the robustness of the Internet infrastructure.  The use
   of the UDP checksum is therefore required [RFC2460] when endpoint
   application s transmit UDP datagrams over IPv6.

1.2.  Use of UDP Tunnels

   One increasingly popular use of UDP is as a tunneling protocol, where
   a tunnel endpoint encapsulates the packets of another protocol inside
   UDP datagrams and transmits them to another tunnel endpoint.  Using
   UDP as a tunneling protocol is attractive when the payload protocol
   is not supported by the middleboxes that may exist along the path,
   because many middleboxes support transmission using UDP.  In this
   use, the receiving endpoint decapsulates the UDP datagrams and
   forwards the original packets contained in the payload [RFC5405].
   Tunnels establish virtual links that appear to directly connect
   locations that are distant in the physical Internet topology and can
   be used to create virtual (private) networks.

1.2.1.  Motivation for new approaches

   A number of tunnel encapsulations deployed over IPv4 have used the
   UDP transport with a zero checksum.  Users of these protocols expect
   a similar solution for IPv6.

   A number of tunnel protocols are currently being defined (e.g.



Fairhurst & Westerlund  Expires February 9, 2011                [Page 5]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   Automated Multicast Tunnels, AMT [AMT], and the Locator/Identifier
   Separation Protocol, LISP [LISP]).  These protocols have proposed an
   update to IPv6 UDP checksum processing.  These tunnel protocols could
   benefit from simpler checksum processing for various reasons:

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

   o  Eliminating a need to access the entire packet when forwarding the
      packet by a tunnel endpoint.

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

   o  A desire to use the port number space to enable load-sharing.

1.2.2.  Reducing forwarding cost

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

   The argument concerning redundant processing costs is valid regarding
   the integrity of a tunneled packet.  In some architectures (e.g.  PC-
   based routers), other mechanisms may also significantly reduce
   checksum processing costs: There are implementations that have
   optimised checksum processing algorithms, including the use of
   checksum-offloading.  This processing is readily available for IPv4
   packets at high line rates.  Such processing may be anticipated for
   IPv6 endpoints, allowing receivers to reject corrupted packets
   without further processing.  Relaxing RFC 2460 to minimise the
   processing impact for existing hardware is a transition policy
   decision, which seems undesirable if at the same time it yields a



Fairhurst & Westerlund  Expires February 9, 2011                [Page 6]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   solution that may reduce stability and functionality in future
   network scenarios.

1.2.3.  Need to inspect the entire packet

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

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 the same protocol
   issues as for IPv4.  It is not clear that NATs will work the same way
   for IPv6.  Any change to RFC 2460 would also require rewriting (or
   defining) IPv6 NAT behaviour to achieve consistent widescale
   deployment.

   The requirements for IPv6 firewall traversal are likely be to be
   similar to those for IPv4.  In addition, it can be reasonably
   expected that a firewall conforming to RFC 2460 will not regard UDP
   datagrams with a zero checksum as valid packets.  If an updated IPv6
   mode were to be defined for IPv6, this may also need firewalla to be
   updated.

   Key questions in this space include:

   o  What do IPv6 routers do today with zero-checksum UDP packets?

   o  What types of middleboxes does the tunnel protocol need to cross
      (routers, NAT boxes, firewalls, etc.), and how will those
      middleboxes deal with these packets?

   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 a basis to design load-
   balancing solutions for IPv4.  This approach could also be leveraged
   for IPv6.  However, support for extension headers would increase the
   complexity of providing standards-compliant solutions for IPv6.




Fairhurst & Westerlund  Expires February 9, 2011                [Page 7]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   An alternate method could utilise the IPv6 Flow Label to perform load
   balancing.  This would release IPv6 load-balancing devices from the
   need 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 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 to start
   using the IPv6 Flow Label as a part of the flow hash, providing
   support for ECMP without requiring use of UDP.


2.  Standards-Track Transports

   The IETF has defined a set of IPv6 transports that at be used with
   IPv6.  These are described in the following sections, followed by a
   description of standards tunnel encapsulations.

2.1.  UDP with Standard Checksum

   UDP with standard checksum behaviour is defined in RFC 2460, and
   should be the default choice.  Guidelines are provided in [RFC5405].

2.2.  UDP-Lite

   UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as
   a proposed standard, RFC 3828.  A MIB is defined in RFC 5097 and
   unicast usage guidelines in [RFC5405].

   UDP-Lite provides a checksum with an optional partial coverage.  When
   using this option, a datagram is divided into a sensitive part
   (covered by the checksum) and an insensitive part (not covered by the
   checksum).  Errors/corruption in the insensitive part will not cause
   the datagram to be discarded by the transport layer at the receiving
   endpoint.  A minor side-effect of using UDP-Lite is that this was
   specified for damage-tolerant payloads, and some link-layers may
   employ different link encapsulations when forwarding UDP-Lite
   segments (e.g.  Over radio access bearers).  When the checksum covers
   the entire packet, which should be 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, without the need for a router/middelbox to
   traverse the entire packet payload.

   In the LISP case, the bytes that would need to be "checksummed" for



Fairhurst & Westerlund  Expires February 9, 2011                [Page 8]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   UDP-Lite would be the set of bytes that are added to the packet by
   the LISP encapsulating router.  When an IPv4/UDP header is per-pended
   by a LISP router, the LISP ETR needs to calculate the IP header
   checksum over 20 bytes (the IP header).  If an IPv6/UDP-Lite header
   were per-pended by a LISP router, the ETR would need to calculate an
   IP header checksum over 48 bytes (the IP pseudo header and the UDP
   header).  This results in an increase in the number of bytes to be
   the checksummed for IPv6 (48 bytes rather than 20), but this is not
   thought to be a major additional processing overhead for a well-
   optimized implementation where 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 not
   include a checksum, since tunnel encapsulations are typically layered
   directly over the Internet layer (identified by the upper layer type
   field) and are also not used as endpoint transport protocols.  That
   is, there is little chance of confusing a tunnel-encapsulated packet
   with other application data that could result in corruption of
   application state or data.

   From the end-to-end perspective, the principal difference is that the
   network-layer Next Header field identifies a separate transport,
   which reduces the probability that corruption could result in the
   packet being delivered to the wrong endpoint or application.
   Specifically, packets are only delivered to protocol modules that
   process a specific next header value.  The next header field
   therefore provides a first-level check of correct demultiplexing.  In
   contrast, the UDP port space is shared by many diverse applications
   and therefore UDP demultiplexing relies solely on the port numbers.


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

   This section evaluates a proposal to update IPv6 [RFC2460], to
   provide the option that some nodes may suppress generation and
   checking of the UDP transport checksum.  The decision to omit an
   integrity check at the IPv6 level means that the transport check is
   overloaded with many functions including validating:

   o  the endpoint address was not corrupted within a router - i.e.
      This packet was intended to be received by this destination and a
      wrong header has not been spliced to a different payload;

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



Fairhurst & Westerlund  Expires February 9, 2011                [Page 9]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   o  reassembly processing, when used;

   o  the length of the payload;

   o  the port values - i.e.  The correct application receives the
      payload (applications should also check the expected use of source
      ports/addresses);

   o  the payload integrity.

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

   In IPv6, these checks occur within the endpoint stack using the UDP
   checksum information.  An IPv6 node also relies on the header
   information to determine whether to send an ICMPv6 error message
   [RFC2463] 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.  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 (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 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).  The process may be easier for IPv4 over IPv6
      encapsulation, where the encapsulated IPv4 header checksum could
      be used as 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 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



Fairhurst & Westerlund  Expires February 9, 2011               [Page 10]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


      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 flow.  The value may be cached per
      flow/destination to minimise per-packet processing.  This proposal
      is not discussed further in this document, since function is
      nearly the same as for UDP-Lite.

   o  Use of a new IPv6 Extension Header that provides 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.

   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 in the following sections.

3.2.  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 which 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.
   There are additional requirements, e.g. fragmentation must not be
   performed, since correct reassembly can not be verified at the
   receiver when there is no checksum.  Allowing fragmentation would
   also open the receiver to a wide range of mis-behaviours.  Host-based
   fragmentation must therefore be disabled.  Policing this, and
   ensuring correct interactions with the stack, implies much more than
   simply disabling the checksum algorithm for specific packets at the
   transport interface.

   There are also proposals to simply ignore a specific received UDP
   checksum value, however this also can result in problems (e.g. when
   used with a NAT that always adjusts the checksum value).

   The IETF should carefully consider constraints on sanctioning the use



Fairhurst & Westerlund  Expires February 9, 2011               [Page 11]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   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, also 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.

3.3.  Effect of packet modification in the network

   IP packets may be corrupted as they traverse an Internet path.
   Evidence has been presented [Sigcomm2000] to show that this was once
   an issue with IPv4 routers, and occasional corruption could result
   from bad internal router processing in routers or hosts.  These
   errors are not detected by the strong frame checksums employed at the
   link-layer (RFC 3819).  There is no current evidence that such cases
   are rare in the modern Internet, nor that they may not be applicable
   to IPv6.  It therefore seems prudent not to relax this constraint.
   The emergence of low-end IPv6 routers and the proposed use of NAT
   with IPv6 further motivate the need to protect from this type of
   error.

   Corruption in the network may result in:

   o  A datagram being mis-delivered to the wrong host/router or the
      wrong transport entity within an endpoint.  Such a datagram needs
      to be discarded.

   o  A datagram payload being corrupted, but still delivered to the
      intended host/router transport entity.  Such a datagram needs to
      be either discarded or correctly processed by an application that
      provides its own integrity checks.

   o  A datagram payload being truncated by corruption of the length
      field.  Such a datagram needs to be discarded.

   When a checksum is used with UDP over IPv6, this significantly
   reduces the impact of errors, reducing the probability of undetected
   corruption of state (and data) on both the host stack and the
   applications using the transport service.

   The following sections examine the impact of modifying each of these
   header fields.

3.3.1.  Corruption of the destination IP address

   An IP endpoint destination address could be modified in the network
   (e.g. corrupted by an error).  This is not a concern for IPv4,



Fairhurst & Westerlund  Expires February 9, 2011               [Page 12]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   because the IP header checksum will result in this packet being
   discarded by the receiving IP stack.  Such modification in the
   network can not be detected when using IPv6.

   There are two possible outcomes:

   o  Delivery to a destination address that is not in use (the packet
      will not be delivered, but could result in an error report).

   o  Delivery to a different destination address.  This modification
      will normally be detected by the transport checksum, resulting in
      silent discard.  Without this checksum, the packet would be passed
      to the endpoint port demultiplexing function.  If an application
      is bound to the associated ports, the packet payload will be
      passed to the application (see the subsequent section on port
      processing).

3.3.2.  Corruption of the source IP address

   This section examines what happens when the source address is
   corrupted in transit.  (This is not a concern in IPv4, because the IP
   header checksum will normally result in this packet being discarded
   by the receiving IP stack).

   Corruption of an IPv6 source address does not result in the IP packet
   being delivered to a different endpoint protocol or destination
   address.  If only the source address is corrupted, the datagram will
   likely be processed in the intended context, although with erroneous
   origin information.  The result will depend on the 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).

   o  A stateless application will process the datagram outside of any
      context, a simple example is the ECHO server, which will respond
      with a datagram directed to the modified source address.  This
      would create unwanted additional processing load, and generate
      traffic to the modified endpoint address.

   o  Some datagram applications build state using the information from
      packet headers.  A previously unused source address would result
      in receiver processing and the creation of unnecessary transport-
      layer state at the receiver.  For example, Real Time Prottocol
      (RTP) flows commonly employ a source independent receiver port.
      State is created for each received flow.  Reception of a datagram



Fairhurst & Westerlund  Expires February 9, 2011               [Page 13]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


      with a corrupted source address will therefore result in
      accumulation of unnecessary state in the RTP state machine,
      including collision detection and response (since the same
      synchronization source, SSRC, value will appear to arrive from
      multiple source IP addresses).

   In general, the effect of corrupting the source address will depend
   upon the protocol that processes the packet and its robustness to
   this error.  For the case where the packet is received by a tunnel
   endpoint, the tunnel application is expected to correctly handle a
   corrupted source address.

   The impact of source address modification is more difficult to
   quantify when the receiving application is not that originally
   intended and several fields have been modified in transit.

3.3.3.  Delivery to an unexpected port

   This section considers 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 case, but 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 the
   intended machine).

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

   o  Delivery to a port that is not in use.  The packet is discarded,
      but could generate an ICMPv6 message (e.g. port unreachable).

   o  It could be delivered to a different node that implements the same
      application, where the packet may be accepted, generating side-
      effects or accumulated state.

   o  It could be delivered to an application that does not implement
      the tunnel protocol, where the packet may be incorrectly parsed,
      and may be misinterpreted, generating side-effects or accumulated
      state.

   The probability of each outcome depends on the statistical
   probability that the source address and the destination port of the
   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 than for connection-oriented transports, because





Fairhurst & Westerlund  Expires February 9, 2011               [Page 14]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   1.  There is no handshake prior to communication and no sequence
       numbers (as in TCP, DCCP, or SCTP).  Together, this makes it hard
       to verify that an application is given only 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 of datagrams
       they receive (guidance on this topic is provided in [RFC5405]).

   While these rules could in principle be revised to declare naive
   applications as "Historic".  This remedy is not realistic: the
   transport owes it to the stack to do its best to reject bogus
   datagrams.

   If checksum coverage is suppressed, the application therefore needs
   to provide a method to detect and discard the unwanted data.  The
   encapsulated tunnel protocol would need to perform its own integrity
   checks on any control information and ensure an integrity check is
   applied to the tunneled packet.  It is not reasonable to assume that
   it is safe for one application to use a zero checksum value and that
   other applications will not.  It is therefore important to consider
   the possibility that a packet will be received by a different node to
   that for which it was intended, or that it will arrive at the correct
   tunnel destination with the wrong source address in the external
   header.

3.3.4.  Validating the network path

   IP transports designed for use in the general Internet should not
   assume specific characteristics.  Network protocols may reroute
   packets and change the set of routers and middleboxes along a path.
   Therefore transports such as TCP, SCTP and DCCP are designed to
   negotiate protocol parameters, adapt to different network path
   characteristics, and receive feedback 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.

   Any application/tunnel that seeks to make use of zero checksum must
   include functionality to both negotiate and verify that the zero
   checksum support is provided by the path and validate that this
   continues to work (e.g., in the case of re-routing events) between
   the intended parties.  This increases the complexity of using such a
   solution.







Fairhurst & Westerlund  Expires February 9, 2011               [Page 15]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


3.3.5.  Requirements on the specification of transported protocols

   If the IETF were to revise the standard for UDP using IPv6 for
   specific use-cases there are a set of questions that would need to be
   answered.  These include:

   Is there a reason why IP in IP 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 is a need 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 the IPv6
      flow label.

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

   o  One argument against using UDP-Lite is that this transport is not
      implemented on all endpoints.  However, there is at least one open
      source implementation as a part of 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.

   o  It has also been argued that UDP-Lite requires a checksum
      computation.  The UDP-Lite checksum, for instance includes the
      length field, but need not include the UDP-Lite payload, and
      therefore would not require access to the full datagram payload by
      the tunnel endpoints.

   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
   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 of a router and host are
      therefore not fixed, and a consistent method must be specified
      that can be used on all nodes.  It can not be assumed that a



Fairhurst & Westerlund  Expires February 9, 2011               [Page 16]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


      particular protocol (or transport mode) will only be used on a
      specific type of network node (e.g. permitting the UDP checksum to
      be disabled only on a router).  It is important to note 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 is the
      case for a zero UDP checksum and also for use of an IPv6 Extension
      Header carrying a transport checksum.

   o  The method needs to consider the impact of load balancing, and
      whether this may be enabled for the chosen transport protocol.

   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 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 be specified to verify the integrity of the inner
       (tunneled) packet for each tunnel application that uses a zero-
       checksum.  This method must be robust to the use of other
       applications that also use a zero-checksum.

   3.  Non-IP inner (tunneled) packets must have a CRC or other
       mechanism for checking packet integrity.

   4.  If a method proposes selective ignoring of the checksum on
       reception, it needs to provide guidance that is appropriate for
       all use-cases, including defining how currently standardised
       nodes handle any new use.

   5.  The tunneling protocol must not allow fragmentation of the inner
       packets being carried.  We suggest the following elaborations of
       the above restrictions, if a change in the IPv6 specification
       moves forward, 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.

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



Fairhurst & Westerlund  Expires February 9, 2011               [Page 17]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


       verified).

   7.

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

3.4.  Comparision

   This section compares different methods to support datagram
   tunneling.  This includes a proposal for updating the behaviour of
   UDP.  This 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 the expected functions if an
   additional end-to-end IPv6 extension header were to be required in
   combination with use of the zero checksum option.

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

   Incremental cksum update?    X    -     X  N/A   N/A  X     -    ?
   Verification 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 of functions (i.e. not all combinations)
   Table 1


4.  Requirements on the specification of transported protocols

   If the IETF were to revise the standard for UDP using IPv6 for
   specific use-cases there are a set of questions that would need to be
   answered.  These include:



Fairhurst & Westerlund  Expires February 9, 2011               [Page 18]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   Is there a reason why IP in IP 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 is a need 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 the IPv6
      flow label.

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

   o  One argument against using UDP-Lite is that this transport is not
      implemented on all endpoints.  However, there is at least one open
      source implementation as a part of 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.

   o  It has also been argued that UDP-Lite requires a checksum
      computation.  The UDP-Lite checksum, for instance includes the
      length field, but need not include the UDP-Lite payload, and
      therefore would not require access to the full datagram payload by
      the tunnel endpoints.

   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
   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 of a router and host are
      therefore not fixed, 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 the UDP checksum to
      be disabled only on a router).  It is important to note that
      protocol changes intended for one specific use are often re-used
      for different applications.




Fairhurst & Westerlund  Expires February 9, 2011               [Page 19]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


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

   o  The method needs to consider the impact of load balancing, and
      whether this may be enabled for the chosen transport protocol.

   o  If a method proposes selective ignoring of the checksum on
      reception, it needs to provide guidance that is appropriate for
      all use-cases, including defining how currently standardised nodes
      handle any new use.

4.1.  Constraints required oin 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 checksum.

   2.   Implementations must provide a way to signal which ports will be
        enabled to receive UDP datagrams with a zero checksum.  An IPv6
        node that enables reception of 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.  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 the integrity of the inner
        (tunneled) packet for each tunnel application that uses a zero-
        checksum.  This method must be robust to the use of other
        applications that also use a zero-checksum.

   6.   Non-IP inner (tunneled) packets must have a CRC or other
        mechanism for checking packet integrity.





Fairhurst & Westerlund  Expires February 9, 2011               [Page 20]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   7.   UDP applications that support use of a zero-checksum, should not
        rely upon correct reception of the IP and UDP protocol
        information 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.  IPv6 nodes that receive ICMPv6 messages that relate to packets
        with a zero UDP checksum must provide appropriate checks
        concerning the consistency of the reported packet was actually
        originated by 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 remain restricted to endpoints
   that explicitly enable this mode and adopt the above procedures


5.  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.  When correctly implemented, such a tunnel endpoint
   will not be negatively impacted by omission of the transport-layer



Fairhurst & Westerlund  Expires February 9, 2011               [Page 21]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   checksum.  However, 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 is 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 a UDP checksum.

   The implications on firewalls, NATs and other middleboxes need to be
   considered.  It should not be expected that NATs handle IPv6 UDP
   datagrams in the same way as they handle IPv4 UDP datagrams.
   Firewalls are intended to be configured, and therefore may need to be
   explicitly updated to allow new services or protocols.

   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 use of UDP over IPv6 with no checksum may have merits as
   a tunnel encapsulation and is widely used in IPv4, there are dangers
   for IPv6 nodes (hosts and routers).  If the use of UDP transport
   without a checksum were to become prevalent for IPv6 (e.g. tunnel and
   host applications using this are widely deployed), there would also
   be a significant danger of the Internet carrying an increased volume
   of packets without a transport checksum for other applications,
   potentially including applications that have traditionally used IPv4
   UDP transport without a checksum.  This result is highly undesirable.
   Other solutions need to be found, such as the use of IPV6 with the
   minimal checksum coverage for UDP-Lite.  This requires that the IPv4
   and IPv6 solutions to differ, since there are different deployed
   infrastructures.

   Guidance has also been provided to help evaluate the case for
   disabling the checksum for specific applications


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



Fairhurst & Westerlund  Expires February 9, 2011               [Page 22]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


7.  IANA Considerations

   This document does not require IANA considerations.


8.  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.  References

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

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




Fairhurst & Westerlund  Expires February 9, 2011               [Page 23]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   [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 the Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998.

   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
              (SIIT)", RFC 2765, February 2000.

   [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, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
              for Application Designers", BCP 145, RFC 5405,
              November 2008.

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



Fairhurst & Westerlund  Expires February 9, 2011               [Page 24]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


   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.

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













Fairhurst & Westerlund  Expires February 9, 2011               [Page 25]


Internet-Draft      IPv6 UDP Checksum Considerations         August 2010


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
   Stockholm,   SE-164 80
   Sweden

   Phone:
   Fax:
   Email: magnus.westerlund@ericsson.com
   URI:




























Fairhurst & Westerlund  Expires February 9, 2011               [Page 26]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/