One document matched: draft-ietf-6man-udpzero-12.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-6man-udpzero-12" ipr="trust200902">
<!--1 category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Applicability of IPv6 UDP Zero Checksum">Applicability
Statement for the use of IPv6 UDP Datagrams with Zero Checksums</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Godred Fairhurst" initials="G." surname="Fairhurst">
<organization>University of Aberdeen</organization>
<address>
<postal>
<street>School of Engineering</street>
<!-- Reorder these if your country does things differently -->
<city>Aberdeen, AB24 3UE</city>
<country>Scotland, UK</country>
</postal>
<email>gorry@erg.abdn.ac.uk</email>
<uri>http://www.erg.abdn.ac.uk/users/gorry</uri>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>Stockholm,</city>
<code>SE-164 80</code>
<country>Sweden</country>
</postal>
<phone>+46 8 719 0000</phone>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<date day="25" month="February" year="2013"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document provides an applicability statement for the use of UDP
transport checksums with IPv6. It defines recommendations and
requirements for the use of IPv6 UDP datagrams with a zero UDP checksum.
It describes the issues and design principles that need to be considered
when UDP is used with IPv6 to support tunnel encapsulations and examines
the role of the IPv6 UDP transport checksum. The document also
identifies issues and constraints for deployment on network paths that
include middleboxes. An appendix presents a summary of the trade-offs
that were considered in evaluating the safety of the update to RFC 2460
that updates use of the UDP checksum with IPv6.</t>
<!-- -->
</abstract>
</front>
<middle>
<section anchor="sec-intro" title="Introduction">
<t>The <xref target="RFC0768">User Datagram Protocol (UDP)</xref>
transport is defined for <xref target="RFC0791">the Internet Protocol
(IPv4)</xref> and is defined in "<xref target="RFC2460">Internet
Protocol, Version 6 (IPv6)</xref> for IPv6 hosts and routers. The UDP
transport protocol has a minimal set of features. This limited set has
enabled a wide range of applications to use UDP, but these application
do need to provide many important transport functions on top of UDP. The
<xref target="RFC5405">UDP Usage Guidelines</xref> provides overall
guidance for application designers, including the use of UDP to support
tunneling. The key difference between UDP usage with IPv4 and IPv6 is
that RFC 2460 mandates use of a calculated UDP checksum, i.e. a non-zero
value, due to the lack of an IPv6 header checksum. The inclusion of the
pseudo header in the checksum computation provides a statistical check
that datagrams have been delivered to the intended IPv6 destination
node. Algorithms for checksum computation are described in <xref
target="RFC1071"/>.</t>
<t>The lack of a possibility to use an IPv6 datagram with a zero UDP
checksum has been observed as a real problem for certain classes of
application, primarily tunnel applications. This class of application
has been deployed with a zero UDP checksum using IPv4. The design of
IPv6 raises different issues when considering the safety of using a UDP
checksum with IPv6. These issues can significantly affect applications,
both when an endpoint is the intended user and when an innocent
bystander (when a packet is received by a different endpoint to that
intended).</t>
<t>This document examines the issues and an appendix compares the
strengths and weaknesses of a number of proposed solutions. This
identifies a set of issues that must be considered and mitigated to be
able to safely deploy IPv6 applications that use a zero UDP checksum.
The provided comparison of methods is expected to also be useful when
considering applications that have different goals from the ones that
initiated the writing of this document, especially the use of already
standardized methods. The analysis concludes that using a zero UDP
checksum is the best method of the proposed alternatives to meet the
goals for certain tunnel applications.</t>
<t>This document defines recommendations and requirements for use of
IPv6 datagrams with a zero UDP checksum. This usage is expected to have
initial deployment issues related to middleboxes, limiting the usability
more than desired in the currently deployed Internet. However, this
limitation will be largest initially and will reduce as updates are
provided in middleboxes that support the zero UDP checksum for IPv6. The
document therefore derives a set of constraints required to ensure safe
deployment of a zero UDP checksum.</t>
<t>Finally, the document also identifies some issues that require future
consideration and possibly additional research.</t>
<section title="Document Structure">
<t><xref target="sec-intro"/> provides a background to key issues, and
introduces the use of UDP as a tunnel transport protocol.</t>
<t><xref target="sec-standards"/> describes a set of standards-track
datagram transport protocols that may be used to support tunnels.</t>
<t><xref target="Issues"/> discusses issues with a zero UDP checksum
for IPv6. It considers the impact of corruption, the need for
validation of the path and when it is suitable to use a zero UDP
checksum.</t>
<t><xref target="sec-constraints"/> is an applicability statement that
defines requirements and recommendations on the implementation of IPv6
nodes that support the use of a zero UDP checksum.</t>
<t>Section 5 provides an applicability statement that defines
requirements and recommendations for protocols and tunnel
encapsulations that are transported over an IPv6 transport that does
not perform a UDP checksum calculation to verify the integrity at the
transport endpoints.</t>
<t><xref target="sec-summary"/> provides the recommendations for
standardization of zero UDP checksum with a summary of the findings
and notes remaining issues needing future work.</t>
<t><xref target="Proposal"/> evaluates the set of proposals to update
the UDP transport behaviour and other alternatives intended to improve
support for tunnel protocols. It concludes by assessing the trade-offs
of the various methods, identifying advantages and disadvantages for
each method.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
</section>
<section title="Use of UDP Tunnels ">
<t>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 <xref
target="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.</t>
<section title="Motivation for new approaches">
<t>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.</t>
<t>A number of tunnel protocols are also currently being defined
(e.g. Automated Multicast Tunnels, <xref
target="I-D.ietf-mboned-auto-multicast">AMT</xref>, and the
Locator/Identifier Separation Protocol, <xref
target="LISP">LISP</xref>). These protocols motivated an update to
IPv6 UDP checksum processing to benefit from simpler checksum
processing for various reasons:<list style="symbols">
<t>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).</t>
<t>Eliminating a need to access the entire packet when
forwarding the packet by a tunnel endpoint.</t>
<t>Enhancing ability to traverse and function with
middleboxes.</t>
<t>A desire to use the port number space to enable
load-sharing.</t>
</list></t>
</section>
<section title="Reducing forwarding cost">
<t>It is a common requirement to terminate a large number of tunnels
on a single router/host. The processing cost per tunnel includes
both state (memory requirements) and per-packet processing at the
tunnel ingress and egress.</t>
<t>Automatic IP Multicast Tunneling, known as <xref
target="I-D.ietf-mboned-auto-multicast">AMT</xref> currently
specifies UDP as the transport protocol for packets carrying
tunneled IP multicast packets. The current specification for AMT
states that the UDP checksum in the outer packet header should be
zero (see <xref target="I-D.ietf-mboned-auto-multicast">Section 6.6
of</xref>). This argues that the computation of an additional
checksum is an unwarranted burden on nodes implementing lightweight
tunneling protocols when an inner packet is already adequately
protected, . The AMT protocol needs to replicate a multicast packet
to each gateway tunnel. In this case, the outer IP addresses are
different for each tunnel and therefore require a different pseudo
header to be built for each UDP replicated encapsulation.</t>
<t>The argument concerning redundant processing costs is valid
regarding the integrity of a tunneled packet. In some architectures
(e.g. PC-based routers), other mechanisms may also significantly
reduce checksum processing costs: There are implementations that
have optimised checksum processing algorithms, including the use of
checksum-offloading. This processing is readily available for IPv4
packets at high line rates. Such processing may be anticipated for
IPv6 endpoints, allowing receivers to reject corrupted packets
without further processing. However, there are certain classes of
tunnel end-points where this off-loading is not available and
unlikely to become available in the near future.</t>
</section>
<section title="Need to inspect the entire packet">
<t>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.</t>
<t>When this design is used to support a tunnel ingress and egress,
it prevents fast processing of a transport checksum over an entire
(large) packet. Hence the currently defined IPv6 UDP checksum is
poorly suited to use within a router that is unable to access the
entire packet and does not provide checksum-offloading. Thus
enabling checksum calculation over the complete packet can impact
router design, performance improvement, energy consumption and/or
cost.</t>
</section>
<section title="Interactions with middleboxes">
<t>Many paths in the Internet include one or more middleboxes of
various types. There exist large classes of middleboxes that will
handle zero UDP checksum packets, which would not support UDP-Lite
or the other investigated proposals. These middleboxes includes load
balancers (see <xref target="sec-loadbalancers"/>) including Equal
Cost Multipath Routing, traffic classifiers and other functions that
reads some fields in the UDP headers but does not validate the UDP
checksum.</t>
<t>There are also middleboxes that either validates or modify the
UDP checksum. The two most common classes are Firewalls and NATs. In
IPv4, UDP-encapsulation may be desirable for NAT traversal, since
UDP support is commonly provided. It is also necessary due to the
almost ubiquitous deployment of IPv4 NATs. There has also been
discussion of NAT for IPv6, although not for the same reason as in
IPv4. If IPv6 NAT becomes a reality they hopefully do not present
the same protocol issues as for IPv4. If NAT is defined for IPv6, it
should take into consideration the use of a zero UDP checksum.</t>
<t>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
datagrams with a zero UDP checksum as valid. Use of a zero UDP
checksum with IPv6 requires firewalls to be updated before the full
utility of the change is available.</t>
<t>It can be expected that datagrams with zero UDP checksum will
initially not have the same middlebox traversal characteristics as
regular UDP (RFC 2460). However when implementations follow the
requirements specified in this document, we expect the traversal
capabilities to improve over time. We also note that deployment of
IPv6-capable middleboxes is still in its initial phases. Thus, it
might be that the number of non-updated boxes quickly become a very
small percentage of the deployed middleboxes.</t>
</section>
<section anchor="sec-loadbalancers" title="Support for load balancing">
<t>The UDP port number fields have been used as a basis to design
load-balancing solutions for IPv4. This approach has also been
leveraged for IPv6. An alternate method would be to utilise the
<xref target="RFC6437">IPv6 Flow Label</xref> as a basis for entropy
for load balancing. This would have the desirable effect of
releasing IPv6 load-balancing devices from the need to assume
semantics for the use of the transport port field and also works for
all type of transport protocols.</t>
<t>This use of the flow-label for load balancing is consistent with
the intended use, although further clarity was needed to ensure the
field can be consistently used for this purpose, therefore an
updated IPv6 Flow Label <xref target="RFC6437"/> and Equal-Cost
Multi-Path routing usage, <xref target="RFC6438">(ECMP)</xref> was
produced. 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.</t>
<t>However, the method for populating the outer IPv6 header with a
value for the flow label is not trivial: If the inner packet uses
IPv6, then the flow label value could be copied to the outer packet
header. However, many current end-points set the flow label to a
zero value (thus no entropy). The ingress of a tunnel seeking to
provide good entropy in the flow label field would therefore need to
create a random flow label value and keep corresponding state, so
that all packets that were associated with a flow would be
consistently given the same flow label. Although possible, this
complexity may not be desirable in a tunnel ingress.</t>
<t>The end-to-end use of flow labels for load balancing is a
long-term solution. Even if the usage of the flow label is
clarified, there would be a transition time before a significant
proportion of end-points start to assign a good quality flow label
to the flows that they originate, with continued use of load
balancing using the transport header fields until any widespread
deployment is finally achieved.</t>
</section>
</section>
</section>
<section anchor="sec-standards" title="Standards-Track Transports">
<t>The IETF has defined a set of transport protocols that may be
applicable for tunnels with IPv6. There are also a set of network layer
encapsulation tunnels such as IP-in-IP and GRE. These already
standardized solutions are discussed here prior to the issues, as
background for the issue description and some comparison of where the
issue may already occur.</t>
<section title="UDP with Standard Checksum">
<t><xref target="RFC0768">UDP</xref> with standard checksum behaviour,
as defined in RFC 2460, has already been discussed. UDP usage
guidelines are provided in <xref target="RFC5405"/>.</t>
</section>
<section title="UDP-Lite">
<t>UDP-Lite <xref target="RFC3828"/> offers an alternate transport to
UDP, specified as a proposed standard, RFC 3828. A MIB is defined in
<xref target="RFC5097"/> and unicast usage guidelines in <xref
target="RFC5405"/>. There is at least one open source implementation
as a part of the Linux kernel since version 2.6.20.</t>
<t>UDP-Lite provides a checksum with optional partial coverage. When
using this option, a datagram is divided into a sensitive part
(covered by the checksum) and an insensitive part (not covered by the
checksum). When the checksum covers the entire packet, UDP-Lite is
fully equivalent with UDP, with the exception that it uses a different
value in the Next Header field in the IPv6 header. Errors/corruption
in the insensitive part will not cause the datagram to be discarded by
the transport layer at the receiving endpoint. A minor side-effect of
using UDP-Lite is that this was specified for damage-tolerant payloads
and some link-layers may employ different link encapsulations when
forwarding UDP-Lite segments (e.g. radio access bearers). Most
link-layers will cover the insensitive part with the same strong layer
2 frame CRC that covers the sensitive part.</t>
<section title="Using UDP-Lite as a Tunnel Encapsulation">
<t>Tunnel encapsulations can use UDP-Lite (e.g. Control And
Provisioning of Wireless Access Points, CAPWAP <xref
target="RFC5415"/>), since UDP-Lite provides a transport-layer
checksum, including an IP pseudo header checksum, in IPv6, without
the need for a router/middlebox to traverse the entire packet
payload. This provides most of the verification required for
delivery and still keeps a low complexity for the checksumming
operation. UDP-Lite may set the length of checksum coverage on a per
packet basis. This feature could be used if a tunnel protocol is
designed to only verify delivery of the tunneled payload and uses a
calculated checksum for control information.</t>
<t>There is currently poor support for middlebox traversal using
UDP-Lite, because UDP-Lite uses a different IPv6 network-layer Next
Header value to that of UDP, and few middleboxes are able to
interpret UDP-Lite and take appropriate actions when forwarding the
packet. This makes UDP-Lite less suited to protocols needing general
Internet support, until such time that UDP-Lite has achieved better
support in middleboxes and end-points.</t>
</section>
</section>
<section title="General Tunnel Encapsulations">
<t>The IETF has defined a set of tunneling protocols or network layer
encapsulations, e.g., IP-in-IP and GRE. These either do not include a
checksum or use a checksum that is optional, since tunnel
encapsulations are typically layered directly over the Internet layer
(identified by the upper layer type in the IPv6 Next Header field) and
are also not used as endpoint transport protocols. There is little
chance of confusing a tunnel-encapsulated packet with other
application data that could result in corruption of application state
or data.</t>
<t>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.</t>
</section>
<section title="Relation to UDP-Lite and UDP with checksum">
<t>The operation of IPv6 with UDP with a zero-checksum is not the same
as IPv4 with UDP with a zero-checksum. Protocol designers should not
be fooled into thinking the two are the same. The requirements below
list a set of additional considerations.</t>
<t>Where possible, existing general tunnel encapsulations, such as
GRE, IP-in-IP, should be used. This section assumes that such existing
tunnel encapsulations do not offer the functionally required to
satisfy the protocol designer's goals. The section considers the
standardized alternative solutions, rather than the full set of ideas
evaluated in <xref target="Proposal"/>. The alternatives to UDP with a
zero checksum are UDP with a (calculated) checksum, and UDP-Lite.</t>
<t>UDP with a checksum has the advantage of close to universal support
in both endpoints and middleboxes. It also provides statistical
verification of delivery to the intended destination (address and
port). However, some classes of device have limited support for
calculation of a checksum that covers a full datagram. For these
devices, this can incur significant processing cost (e.g. requiring
processing in the router slow-path) and can hence reduce capacity or
fail to function.</t>
<t>UDP-Lite has the advantage of using a checksum that is calculated
only over the pseudo header and the UDP header. This provides a
statistical verification of delivery to the intended destination
(address and port). The checksum can be calculated without access to
the datagram payload, only requiring access to the part to be
protected. A drawback is that UDP-Lite has currently limited support
in both end-points (i.e. is not supported on all operating system
platforms) and middleboxes (that require support for the UDP-Lite
header type). A path verification method is therefore recommended.</t>
<t>IPv6 and UDP with a zero-checksum can also be used by nodes that do
not permit calculation of a payload checksum. Many existing classes of
middleboxes do not verify or change the transport checksum. For these
middleboxes, IPv6 with a zero UDP checksum is expected to function
where UDP-Lite would not. However, support for the zero UDP checksum
in middleboxes that do change or verify the checksum is currently
limited, and this may result in datagrams with a zero UDP checksum
being discarded, therefore a path verification method is
recommended.</t>
<t>There are sets of constrains for which no solution exist: A
protocol designer that needs to originate or receive datagrams on a
device that can not efficiently calculate a checksum over a full
datagram and also needs these packets to pass through a middlebox that
verifies or changes a UDP checksum, but does not support a zero UDP
checksum, can not use the zero UDP checksum method. Similarly, one
that originates datagrams on a device with UDP-Lite support, but needs
the packets to pass through a middlebox that does not support
UDP-Lite, can not use UDP-Lite. For such cases, there is no optimal
solution and the current recommendation is to use or fall-back to
using UDP with full checksum coverage.</t>
</section>
</section>
<section anchor="Issues" title="Issues Requiring Consideration">
<t>This informative section evaluates issues around the proposal to
update IPv6 [RFC2460], to enable the UDP transport checksum to be set to
zero. Some of the identified issues are shared with other protocols
already in use. The section also provides background to the requirements
and recommendations that follow.</t>
<t>The decision in RFC 2460 to omit an integrity check at the network
level meant that the IPv6 transport checksum was overloaded with many
functions, including validating: <list style="symbols">
<t>the endpoint address was not corrupted within a router, i.e., a
packet was intended to be received by this destination and validate
that the packet does not consist of a wrong header spliced to a
different payload;</t>
<t>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;</t>
<t>reassembly processing, when used;</t>
<t>the length of the payload;</t>
<t>the port values - i.e., the correct application receives the
payload (applications should also check the expected use of source
ports/addresses);</t>
<t>the payload integrity.</t>
</list></t>
<t>In IPv4, the first four checks are performed using the IPv4 header
checksum.</t>
<t>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 <xref
target="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.</t>
<section title="Effect of packet modification in the network">
<t>IP packets may be corrupted as they traverse an Internet path.
Older evidence in <xref target="Sigcomm2000">"When the CRC and TCP
Checksum Disagree"</xref> show that this was once an issue in year
2000 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
<xref target="RFC3819"/>. During the development of this document in
2009, individuals provided reports of observed rates for received UDP
datagrams using IPv4 where the UDP checksum had been detected as
corrupt. These rates where as high as 1.39E-4 for some paths, but also
close to zero for some other paths.</t>
<t>There is extensive experience of deployment using tunnel protocols
in well-managed networks (e.g. corporate networks or service provider
core networks). This has shown the robustness of methods such as PWE
and MPLS that do not employ a transport protocol checksum and have not
specified mechanisms to protect from corruption of the unprotected
headers (such as the VPN Identifier in MPLS). Reasons for the
robustness may include:</t>
<t><list style="symbols">
<t>A reduced probability of corruption on paths through
well-managed networks.</t>
<t>IP form the majority of the inner traffic carried by these
tunnel. Hence from a transport perspective, endpoint verification
is already being performed when processing a received IPv4 packet
or by the transport pseudo-header for an IPv6 packet. This update
to UDP does not change this behaviour.</t>
<t>In certain cases, a combination of additional filtering (e.g.
filter of a MAC destination address in a L2 tunnel) significantly
reduces the probability of final mis-delivery to the IP stack.</t>
<t>The tunnel protocols did not use a UDP transport header, any
corruption is therefore unlikely to result in misdelivery to
another UDP-based application. This concern is specific to the use
of UDP with IPv6.</t>
</list></t>
<t>While this experience can guide the present recommendations, any
update to UDP must preserve operation in the general Internet. This is
heterogeneous and can include links and systems of very varying
characteristics. Transport protocols used by hosts need to be designed
with this in mind, especially when there is need to traverse edge
networks, where middlebox deployments are common.</t>
<t>For the general Internet, there is no current evidence that
corruption is rare, nor that this may not be applicable to IPv6. It
therefore seems prudent not to relax checks on misdelivery . The
emergence of low-end IPv6 routers and the proposed use of NAT with
IPv6 further motivate the need to protect from misdelivery.</t>
<t>Corruption in the network may result in: <list style="symbols">
<t>A datagram being misdelivered to the wrong host/router or the
wrong transport entity within an endpoint. Such a datagram needs
to be discarded;</t>
<t>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;</t>
<t>A datagram payload being truncated by corruption of the length
field. Such a datagram needs to be discarded.</t>
</list></t>
<t>When a checksum is used, this significantly reduces the impact of
errors, reducing the probability of undetected corruption of state
(and data) on both the host stack and the applications using the
transport service.</t>
<t>The following sections examine the impact of modifying each of
these header fields.</t>
<section title="Corruption of the destination IP address">
<t>An IPv6 endpoint destination address could be modified in the
network (e.g. corrupted by an error). This is not a concern for
IPv4, because the IP header checksum will result in this packet
being discarded by the receiving IP stack. Such modification in the
network can not be detected at the network layer when using IPv6.
Detection of this corruption by a UDP receiver relies on the IPv6
pseudo header incorporated in the transport checksum.</t>
<t>There are two possible outcomes:</t>
<t><list style="symbols">
<t>Delivery to a destination address that is not in use (the
packet will not be delivered, but could result in an error
report);</t>
<t>Delivery to a different destination address. This
modification will normally be detected by the transport
checksum, resulting in silent discard. Without a computed
checksum, the packet would be passed to the endpoint port
demultiplexing function. If an application is bound to the
associated ports, the packet payload will be passed to the
application (see the subsequent section on port processing).</t>
</list></t>
</section>
<section title="Corruption of the source IP address">
<t>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. Detection of this corruption by a UDP
receiver relies on the IPv6 pseudo header incorporated in the
transport checksum.</t>
<t>Corruption of an IPv6 source address does not result in the IP
packet being delivered to a different endpoint protocol or
destination address. If only the source address is corrupted, the
datagram will likely be processed in the intended context, although
with erroneous origin information. When using Unicast Reverse Path
Forwarding <xref target="RFC2827"/>, a change in address may result
in the router discarding the packet when the route to the modified
source address is different to that of the source address of the
original packet.</t>
<t>The result will depend on the application or protocol that
processes the packet. Some examples are:</t>
<t><list style="symbols">
<t>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).</t>
<t>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.</t>
<t>Some datagram applications build state using the information
from packet headers. A previously unused source address would
result in receiver processing and the creation of unnecessary
transport-layer state at the receiver. For example, Real Time
Protocol (RTP) <xref target="RFC3550"/> sessions commonly employ
a source independent receiver port. State is created for each
received flow. Reception of a datagram with a corrupted source
address will therefore result in accumulation of unnecessary
state in the RTP state machine, including collision detection
and response (since the same synchronization source, SSRC, value
will appear to arrive from multiple source IP addresses).</t>
<t>ICMP messages relating to a corrupted packet can be
misdirected to the wrong source node.</t>
</list></t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Corruption of Port Information">
<t>This section describes what happens if one or both of the UDP
port values are corrupted in transit. This can also happen with IPv4
is used with a zero UDP checksum, but not when UDP checksums are
calculated or when UDP-Lite is used. If the ports carried in the
transport header of an IPv6 packet were corrupted in transit,
packets may be delivered to the wrong application process (on the
intended machine) and/or responses or errors sent to the wrong
application process (on the intended machine).</t>
</section>
<section title="Delivery to an unexpected port">
<t>If one combines the corruption effects, such as destination
address and ports, there is a number of potential outcomes when
traffic arrives at an unexpected port. This section discusses these
possibilities and their outcomes for a packet that does not use the
UDP checksum validation:</t>
<t><list style="symbols">
<t>Delivery to a port that is not in use. The packet is
discarded, but could generate an ICMPv6 message (e.g. port
unreachable).</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>The probability of each outcome depends on the statistical
probability that the address or the port information for the source
or destination becomes corrupt in the datagram such that they match
those of an existing flow or server port. Unfortunately, such a
match may be more likely for UDP than for connection-oriented
transports, because:<list style="numbers">
<t>There is no handshake prior to communication and no sequence
numbers (as in TCP, DCCP, or SCTP). Together, this makes it hard
to verify that an application process is given only the
application data associated with a specific transport
session.</t>
<t>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
<xref target="RFC5405"/>).</t>
</list>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.</t>
<t>If checksum coverage is suppressed, the application therefore
needs to provide a method to detect and discard the unwanted data. A
tunnel protocol would need to perform its own integrity checks on
any control information if transported in datagrams with a zero UDP
checksum. If the tunnel payload is another IP packet, the packets
requiring checksums can be assumed to have their own checksums
provided that the rate of corrupted packets is not significantly
larger due to the tunnel encapsulation. If a tunnel transports other
inner payloads that do not use IP, the assumptions of corruption
detection for that particular protocol must be fulfilled, this may
require an additional checksum/CRC and/or integrity protection of
the payload and tunnel headers.</t>
<t>A protocol that uses a zero UDP checksum can not assume that it
is the only protocol using a zero UDP checksum. Therefore, it needs
to gracefully handle misdelivery. It must be robust to reception of
malformed packets received on a listening port and expect that these
packets may contain corrupted data or data associated with a
completely different protocol.</t>
</section>
<section title="Corruption of Fragmentation Information">
<t>The fragmentation information in IPv6 employs a 32-bit identity
field, compared to only a 16-bit field in IPv4, a 13-bit fragment
offset and a 1-bit flag, indicating if there are more fragments.
Corruption of any of these field may result in one of two
outcomes:</t>
<t><list style="hanging">
<t hangText="Reassembly failure: ">An error in the "More
Fragments" field for the last fragment will for example result
in the packet never being considered complete and will
eventually be timed out and discarded. A corruption in the ID
field will result in the fragment not being delivered to the
intended context thus leaving the rest incomplete, unless that
packet has been duplicated prior to corruption. The incomplete
packet will eventually be timed out and discarded.</t>
<t hangText="Erroneous reassembly:">The re-assembled packet did
not match the original packet. This can occur when the ID field
of a fragment is corrupted, resulting in a fragment becoming
associated with another packet and taking the place of another
fragment. Corruption in the offset information can cause the
fragment to be misaligned in the reassembly buffer, resulting in
incorrect reassembly. Corruption can cause the packet to become
shorter or longer, however completion of reassembly is much less
probable, since this would require consistent corruption of the
IPv6 headers payload length field and the offset field. The
possibility of mis-assembly requires the reassembling stack to
provide strong checks that detect overlap or missing data, note
however that this is not guaranteed and has been clarified in
<xref target="RFC5722">"Handling of Overlapping IPv6
Fragments"</xref>.</t>
</list>The erroneous reassembly of packets is a general concern
and such packets should be discarded instead of being passed to
higher layer processes. The primary detector of packet length
changes is the IP payload length field, with a secondary check by
the transport checksum. The Upper-Layer Packet length field included
in the pseudo header assists in verifying correct reassembly, since
the Internet checksum has a low probability of detecting insertion
of data or overlap errors (due to misplacement of data). The
checksum is also incapable of detecting insertion or removal of all
zero-data that occurs in a multiple of a 16-bit chunk.</t>
<t>The most significant risk of corruption results following
mis-association of a fragment with a different packet. This risk can
be significant, since the size of fragments is often the same (e.g.
fragments resulting when the path MTU results in fragmentation of a
larger packet, common when addition of a tunnel encapsulation header
expands the size of a packet). Detection of this type of error
requires a checksum or other integrity check of the headers and the
payload. Such protection is anyway desirable for tunnel
encapsulations using IPv4, since the small fragmentation ID can
easily result in wrap-around <xref target="RFC4963"/>, this is
especially the case for tunnels that perform flow aggregation <xref
target="I-D.ietf-intarea-tunnels"/>.</t>
<t>Tunnel fragmentation behavior matters. There can be outer or
inner fragmentation <xref target="I-D.ietf-intarea-tunnels">"Tunnels
in the Internet Architecture"</xref>. If there is inner
fragmentation by the tunnel, the outer headers will never be
fragmented and thus a zero UDP checksum in the outer header will not
affect the reassembly process. When a tunnel performs outer header
fragmentation, the tunnel egress needs to perform reassembly of the
outer fragments into an inner packet. The inner packet is either a
complete packet or a fragment. If it is a fragment, the destination
endpoint of the fragment will perform reassembly of the received
fragments. The complete packet or the reassembled fragments will
then be processed according to the packet Next Header field. The
receiver may only detect reassembly anomalies when it uses a
protocol with a checksum. The larger the number of reassembly
processes to which a packet has been subjected, the greater the
probability of an error.</t>
<t><list style="symbols">
<t>An IP-in-IP tunnel that performs inner fragmentation has
similar properties to a UDP tunnel with a zero UDP checksum that
also performs inner fragmentation.</t>
<t>An IP-in-IP tunnel that performs outer fragmentation has
similar properties to a UDP tunnel with a zero UDP checksum that
performs outer fragmentation.</t>
<t>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.</t>
<t>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.</t>
<t>Unless there is verification at each reassembly, the
probability for undetected error will increase with the number
of times fragmentation is recursively applied, making IP-in-IP
and UDP with zero UDP checksum both vulnerable to undetected
errors.</t>
</list></t>
<t>In conclusion, fragmentation of datagrams with a zero UDP
checksum does not worsen the performance compared to some other
commonly used tunnel encapsulations. However, caution is needed for
recursive tunneling without any additional verification at the
different tunnel layers.</t>
</section>
</section>
<section title="Where Packet Corruption Occurs">
<t>Corruption of IP packets can occur at any point along a network
path, during packet generation, during transmission over the link, in
the process of routing and switching, etc. Some transmission steps
include a checksum or Cyclic Redundancy Check (CRC) that reduces the
probability for corrupted packets being forwarded, but there still
exists a probability that errors may propagate undetected.</t>
<t>Unfortunately the community lacks reliable information to identify
the most common functions or equipment that result in packet
corruption. However, there are indications that the place where
corruption occurs can vary significantly from one path to another.
There is therefore a risk in applying evidence from one domain of
usage to infer characteristics for another. Methods intended for
general Internet usage must therefore assume that corruption can occur
and deploy mechanisms to mitigate the effect of corruption and/or
resulting misdelivery.</t>
</section>
<section title="Validating the network path">
<t>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.</t>
<t>A zero value in the UDP checksum field is explicitly disallowed in
RFC2460. Thus it may be expected that any device on the path that has
a reason to look beyond the IP header, for example to validate the UDP
checksum, will consider such a packet as erroneous or illegal and may
discard it, unless the device is updated to support the new behavior.
Any middlebox that modifies the UDP checksum, for example a NAT that
changes the values of the IP and UDP header in such a way that the
checksum over the pseudo header changes value, will need to be updated
to support this behavior. Until then, a zero UDP checksum packet is
likely to be discarded either directly in the middlebox or at the
destination, when a zero UDP checksum has been modified to a non-zero
by an incremental update.</t>
<t>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 using negotiation or an explicit mandate to use the new
behavior by all nodes that support the new protocol.</t>
<t>Enabling the use of a zero checksum places new requirements on
equipment deployed within the network, such as middleboxes. A
middlebox (e.g. Firewalls, Network Address Translators) may enable
zero checksum usage for a particular range of ports. Note that
checksum off-loading and operating system design may result in all
IPv6 UDP traffic being sent with a calculated checksum. This requires
middleboxes that are configured to enable a zero UDP checksum to
continue to work with bidirectional UDP flows that use a zero UDP
checksum in only one direction, and therefore they must not maintain
separate state for a UDP flow based on its checksum usage.</t>
<t>Support along the path between end points can be guaranteed in
limited deployments by appropriate configuration. In general, it can
be expected to take time for deployment of any updated behaviour to
become ubiquitous.</t>
<t>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. Note that a bidirectional path does not necessarily
support the same checksum usage in both the forward and return
directions: Receipt of a datagram with a zero UDP checksum, does not
imply that the remote endpoint can also receive a datagram with a zero
UDP checksum. This will require periodic validation of the path,
adding complexity to any solution using the new behavior.</t>
</section>
<section title="Applicability of method">
<t>The update to the IPv6 specification defined in <xref
target="I-D.ietf-6man-udpchecksums"/> only modifies IPv6 nodes that
implement specific protocols designed to permit omission of a UDP
checksum. This document therefore provides an applicability statement
for the updated method indicating when the mechanism can (and can not)
be used. Enabling this, and ensuring correct interactions with the
stack, implies much more than simply disabling the checksum algorithm
for specific packets at the transport interface.</t>
<t>When the method is 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 application
processes could confuse a corrupted or wrongly delivered UDP datagram
with that of data addressed to the application running on their
endpoint.</t>
<t>The protocol or application that uses the zero checksum method must
ensure that the lack of checksum does not affect the protocol
operation. This includes being robust to receiving a unintended packet
from another protocol or context following corruption of a destination
or source address and/or port value. It also includes considering the
need for additional implicit protection mechanisms required when using
the payload of a UDP packet received with a zero checksum.</t>
</section>
<section title="Impact on non-supporting devices or applications">
<t>It is important to consider the potential impact of using a zero
UDP checksum on end-point devices or applications that are not
modified to support the new behavior or by default or preference, use
the regular behavior. These applications must not be significantly
impacted by the update.</t>
<t>To illustrate why this necessary, consider the implications of a
node that enables use of a zero UDP checksum at the interface level:
This would result in all applications that listen to a UDP socket
receiving datagrams where the checksum was not verified. This could
have a significant impact on an application that was not designed with
the additional robustness needed to handle received packets with
corruption, creating state or destroying existing state in the
application.</t>
<t>A zero UDP checksum therefore needs to 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 datagrams with a zero UDP checksum.
These other applications would not be affected by this changed
behavior. An application that allows the changed behavior should be
aware of the risk of corruption and the increased level of misdirected
traffic, and can be designed robustly to handle this risk.</t>
</section>
</section>
<section anchor="sec-constraints"
title="Constraints on implementation of IPv6 nodes supporting zero checksum">
<t>This section is an applicability statement that defines requirements
and recommendations on the implementation of IPv6 nodes that support use
of a zero value in the checksum field of a UDP datagram.</t>
<t>All implementations that support this zero UDP checksum method MUST
conform to the requirements defined below.</t>
<t><list style="numbers">
<t>An IPv6 sending node MAY use a calculated RFC 2460 checksum for
all datagrams that it sends. This explicitly permits an interface
that supports checksum offloading to insert an updated UDP checksum
value in all UDP datagrams that it forwards, however note that
sending a calculated checksum requires the receiver to also perform
the checksum calculation. Checksum offloading can normally be
switched off for a particular interface to ensure that datagrams are
sent with a zero UDP checksum.</t>
<t>IPv6 nodes SHOULD by default NOT allow the zero UDP checksum
method for transmission.</t>
<t>IPv6 nodes MUST provide a way for the application/protocol to
indicate the set of ports that will be enabled to send datagrams
with a zero UDP checksum. This may be implemented by enabling a
transport mode using a socket API call when the socket is
established, or a similar mechanism. It may also be implemented by
enabling the method for a pre-assigned static port used by a
specific tunnel protocol.</t>
<t>IPv6 nodes MUST provide a method to allow an application/protocol
to indicate that a particular UDP datagram is required to be sent
with a UDP checksum. This needs to be allowed by the operating
system at any time (e.g. to send keep-alive datagrams), not just
when a socket is established in the zero checksum mode.</t>
<t>The default IPv6 node receiver behaviour MUST discard all IPv6
packets carrying datagrams with a zero UDP checksum.</t>
<t>IPv6 nodes MUST provide a way for the application/protocol to
indicate the set of ports that will be enabled to receive datagrams
with a zero UDP checksum. This may be implemented via a socket API
call, or similar mechanism. It may also be implemented by enabling
the method for a pre-assigned static port used by a specific tunnel
protocol.</t>
<t>IPv6 nodes supporting usage of zero UDP checksums MUST also allow
reception using a calculated UDP checksum on all ports configured to
allow zero UDP checksum usage. (The sending endpoint, e.g.
encapsulating ingress, may choose to compute the UDP checksum, or
may calculate this by default.) The receiving endpoint MUST use the
reception method specified in RFC2460 when the checksum field is not
zero.</t>
<t>RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams
with a zero UDP checksum. This remains the case for any datagram
received on a port that does not explicitly enable processing of a
zero UDP checksum. A port for which the zero UDP checksum has been
enabled MUST NOT log the datagram solely because the checksum value
is zero.</t>
<t>IPv6 nodes MAY separately identify received UDP datagrams that
are discarded with a zero UDP checksum. It SHOULD NOT add these to
the standard log, since the endpoint has not been verified. This may
be used to support other functions (such as a security policy).</t>
<t>IPv6 nodes that receive ICMPv6 messages that refer to packets
with a zero UDP checksum MUST provide appropriate checks concerning
the consistency of the reported packet to verify that the reported
packet actually originated from the node, before acting upon the
information (e.g. validating the address and port numbers in the
ICMPv6 message body).</t>
</list></t>
</section>
<section title="Requirements on usage of the zero UDP checksum">
<t>This section is an applicability statement that identifies
requirements and recommendations for protocols and tunnel encapsulations
that are transported over an IPv6 transport flow (e.g. tunnel) that does
not perform a UDP checksum calculation to verify the integrity at the
transport endpoints. Before deciding to use the zero UDP checksum and
loose the integrity verification provided, a protocol developer should
seriously consider if they can use checksummed UDP packets or <xref
target="RFC3828">UDP-Lite</xref>, because IPv6 with a zero UDP checksum
is not equivalent in behavior to IPv4 with zero UDP checksum.</t>
<t>The requirements and recommendations for protocols and tunnel
encapsulations using an IPv6 transport flow that does not perform a UDP
checksum calculation to verify the integrity at the transport endpoints
are:<list style="numbers">
<t>Transported protocols that enable the use of zero UDP checksum
MUST only enable this for a specific port or port-range. This needs
to be enabled at the sending and receiving endpoints for a UDP
flow.</t>
<t>An integrity mechanism is always RECOMMENDED at the transported
protocol layer to ensure that corruption rates of the delivered
payload is not increased (e.g. the inner-most packet of a UDP
tunnel). A mechanism that isolates the causes of corruption (e.g.
identifying misdelivery, IPv6 header corruption, tunnel header
corruption) is expected to also provide additional information about
the status of the tunnel (e.g. to suggest a security attack).</t>
<t>A transported protocol that encapsulates Internet Protocol (IPv4
or IPv6) packets MAY rely on the inner packet integrity checks,
provided that the tunnel protocol will not significantly increase
the rate of corruption of the inner IP packet. If a significantly
increased corruption rate can occur, then the tunnel protocol MUST
provide an additional integrity verification mechanism. Early
detection is desirable to avoid wasting unnecessary computation,
transmission capacity or storage for packets that will subsequently
be discarded.</t>
<t>A transported protocol that supports use of a zero UDP checksum,
MUST be designed so that corruption of this information does not
result in accumulated state for the protocol.</t>
<t>A transported protocol with a non-tunnel payload or one that
encapsulates non-IP packets MUST have a CRC or other mechanism for
checking packet integrity, unless the non-IP packet is specifically
designed for transmission over a lower layer that does not provide a
packet integrity guarantee.</t>
<t>A transported protocol with control feedback SHOULD be robust to
changes in the network path, since the set of middleboxes on a path
may vary during the life of an association. The UDP endpoints need
to discover paths with middleboxes that drop packets with a zero UDP
checksum. Therefore, transported protocols SHOULD send keep-alive
messages with a zero UDP checksum. An endpoint that discovers an
appreciable loss rate for keep-alive packets MAY terminate the UDP
flow (e.g. tunnel). Section 3.1.3 of RFC 5405 describes requirements
for congestion control when using a UDP-based transport.</t>
<t>A protocol with control feedback that can fall-back to using UDP
with a calculated RFC 2460 checksum is expected to be more robust to
changes in the network path. Therefore, keep-alive messages SHOULD
include both UDP datagrams with a checksum and datagrams with a zero
UDP checksum. This will enable the remote endpoint to distinguish
between a path failure and dropping of datagrams with a zero UDP
checksum.</t>
<t>A middlebox implementation MUST allow forwarding of an IPv6 UDP
datagram with both a zero and standard UDP checksum using the same
UDP port.</t>
<t>A middlebox MAY configure a restricted set of specific port
ranges that forward UDP datagrams with a zero UDP checksum. The
middlebox MAY drop IPv6 datagrams with a zero UDP checksum that are
outside a configured range.</t>
<t>When a middlebox forwards an IPv6 UDP flow containing datagrams
with both a zero and standard UDP checksum, the middlebox MUST NOT
maintain separate state for flows depending on the value of their
UDP checksum field. (This requirement is necessary to enable a
sender that always calculates a checksum to communicate via a
middlebox with a remote endpoint that uses a zero UDP checksum.)</t>
</list></t>
<t>Special considerations are required when designing a UDP tunnel
protocol, where the tunnel ingress or egress may be a router that may
not have access to the packet payload. When the node is acting as a host
(i.e., sending or receiving a packet addressed to itself), the checksum
processing is similar to other hosts. However, when the node (e.g. a
router) is acting as a tunnel ingress or egress that forwards a packet
to or from a UDP tunnel, there may be restricted access to the packet
payload. This prevents calculating (or verifying) a UDP checksum. In
this case, the tunnel protocol may use a zero UDP checksum and must:</t>
<t><list style="symbols">
<t>Ensure that tunnel ingress and tunnel egress router are both
configured to use a zero UDP checksum. For example, this may include
ensuring that hardware checksum offloading is disabled.</t>
<t>The tunnel operator must ensure that middleboxes on the network
path are updated to support use of a zero UDP checksum.</t>
<t>A tunnel egress should implement appropriate security techniques
to protect from overload, including source address filtering to
prevent traffic injection by an attacker, and rate-limiting of any
packets that incur additional processing, such as UDP datagrams used
for control functions that require verification of a calculated
checksum to verify the network path. Usage of common control traffic
for multiple tunnels between a pair of nodes can assist in reducing
the number of packets to be processed.</t>
</list></t>
</section>
<section anchor="sec-summary" title="Summary">
<t>This document provides an applicability statement for the use of UDP
transport checksums with IPv6.</t>
<t>It examines the role of the UDP transport checksum when used with
IPv6 and presents a summary of the trade-offs in evaluating the safety
of updating RFC 2460 to permit an IPv6 endpoint to use a zero UDP
checksum field to indicate that no checksum is present.</t>
<t>Application designers should first examine whether their transport
goals may be met using standard UDP (with a calculated checksum) or by
using UDP-Lite. The use of UDP with a zero UDP checksum has merits for
some applications, such as tunnel encapsulation, and is widely used in
IPv4. However, there are different dangers for IPv6: There is an
increased risk of corruption and misdelivery when using zero UDP
checksum in IPv6 compared to using IPv4 due to the lack of an IPv6
header checksum. Thus, applications need to evaluate the risks of
enabling use of a zero UDP checksum and 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. The use of checksum
off-loading may help alleviate the cost of checksum processing and
permit use of a checksum using method defined in RFC 2460.</t>
<t>Tunnel applications using UDP for encapsulation can in many cases use
a zero UDP checksum without significant impact on the corruption rate. A
well-designed tunnel application should include consistency checks to
validate the header information encapsulated with a received packet. In
most cases, tunnels encapsulating IP packets can rely on the integrity
protection provided by the transported protocol (or tunneled inner
packet). When correctly implemented, such an endpoint will not be
negatively impacted by omission of the transport-layer checksum.
Recursive tunneling and fragmentation is a potential issue that can
raise corruption rates significantly, and requires careful
consideration.</t>
<t>Other UDP applications at the intended destination node or another
node can be impacted if they are allowed to receive datagrams that have
a zero UDP checksum. It is important that already deployed applications
are not impacted by a change at the transport layer. If these
applications execute on nodes that implement RFC 2460, they will discard
(and log) all datagrams with a zero UDP checksum. This is not an
issue.</t>
<t>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 data stream of the
application 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.</t>
<t>The transport of recursive tunneling and the use of fragmentation
pose difficult issues that need to be considered in the design of tunnel
protocols. 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 verification of
correctness. This requires extra thought and careful consideration in
the design of transported tunnels.</t>
<t>Any use of the updated method must consider the implications on
firewalls, NATs and other middleboxes. It is not expected that IPv6 NATs
handle IPv6 UDP datagrams in the same way that they handle IPv4 UDP
datagrams. In many deployed cases this will require an update to support
an IPv6 zero UDP 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, and therefore new devices are expected to follow the methods
specified in this document.</t>
<t>Each application should consider the implications of choosing an IPv6
transport that uses a zero UDP checksum, and consider whether other
standard methods may be more appropriate, and may simplify application
design.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Brian Haberman, Brian Carpenter, Margaret Wasserman, Lars Eggert,
others in the TSV directorate. Barry Leiba, Ronald Bonica, Pete Resnick,
and Stewart Bryant are thanked for resulting in a document with much
greater applicability. Thanks to P.F. Chimento for careful review and
editorial corrections.</t>
<t>Thanks also to: Rémi Denis-Courmont, Pekka Savola, Glen
Turner, and many others who contributed comments and ideas via the 6man,
behave, lisp and mboned lists.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This document does not require any actions by IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>Depending on the hardware design, the processing requirements may
differ for tunnels that have a zero UDP checksum and those that
calculate a checksum. This processing overhead may need to be considered
when deciding whether to enable a tunnel and to determine an acceptable
rate for transmission. This can become a security risk for designs that
can handle a significantly larger number of packets with zero UDP
checksums compared to datagrams with a non-zero checksum, such as tunnel
egress. An attacker could attempt to inject non-zero checksummed UDP
packets into a tunnel forwarding zero checksum UDP packets and cause
overload in the processing of the non-zero checksums, e.g. if this
happens in a routers slow path. Protection mechanisms should therefore
be employed when this threat exists. Protection may include source
address filtering to prevent an attacker injecting traffic, as well as
throttling the amount of non-zero checksum traffic. The latter may
impact the function of the tunnel protocol.</t>
<t>Transmission of IPv6 packets with a zero UDP checksum could reveal
additional information to an on-path attacker to identify the operating
system or configuration of a sending node. There is a need to probe the
network path to determine whether the current path supports using IPv6
packets with a zero UDP checksum. The details of the probing mechanism
may differ for different tunnel encapsulations and if visible in the
network (e.g. if not using IPsec in encryption mode) could reveal
additional information to an on-path attacker to identify the type of
tunnel being used.</t>
<t>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. This applicability statement therefore permits
this method to be enabled only for specific ranges of ports.</t>
<t>When the zero UDP checksum mode is enabled for a range of ports,
nodes and middleboxes must forward received UDP datagrams that have
either a calculated checksum or a zero checksum.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- -->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<?rfc include='reference.RFC.0791'
?>
<?rfc include='reference.RFC.0768'?>
<?rfc include='reference.RFC.2460'?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.I-D.ietf-6man-udpchecksums'?>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include='reference.I-D.ietf-mboned-auto-multicast'?>
<?rfc include='reference.RFC.2827'?>
<?rfc include='reference.RFC.1071'?>
<reference anchor="UDPTT">
<front>
<title>The UDP Tunnel Transport mode</title>
<author fullname="" surname="G Fairhurst">
<organization/>
</author>
<date day="20" month="Feb" year="2010"/>
</front>
</reference>
<reference anchor="LISP">
<front>
<title>Locator/ID Separation Protocol (LISP)</title>
<author fullname="" surname="D. Farinacci et al">
<organization>Internet draft,
draft-farinacci-lisp-24.txt</organization>
</author>
<date day="02" month="November" year="2012"/>
</front>
</reference>
<reference anchor="Sigcomm2000">
<front>
<title>When the CRC and TCP Checksum Disagree</title>
<author fullname="" surname="Jonathan Stone and Craig Partridge ">
<organization>http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/9-1.htm</organization>
</author>
<date year="2000"/>
</front>
</reference>
<?rfc ?>
<?rfc include='reference.RFC.1141'?>
<?rfc include='reference.RFC.1624'?>
<?rfc include='reference.RFC.4443'?>
<?rfc include='reference.I-D.ietf-intarea-tunnels'?>
<?rfc include='reference.RFC.3550'?>
<?rfc include='reference.RFC.3819'?>
<?rfc include='reference.RFC.3828'?>
<?rfc include='reference.RFC.4963'
?>
<?rfc include='reference.RFC.5097'
?>
<?rfc include='reference.RFC.5405'?>
<?rfc include='reference.RFC.5415'?>
<?rfc include='reference.RFC.5722'?>
<?rfc include='reference.RFC.6437'
?>
<?rfc include='reference.RFC.6438'?>
<!-- A reference written by by an organization not a person.
Discusses IPv4 cksum=0, and alludes to IPv6 case:
UDP Encapsulation of IPsec ESP Packets (draft-ietf-ipsec-udp-encaps-09)
-->
</references>
<section anchor="Proposal"
title="Evaluation of proposal to update RFC 2460 to support zero checksum">
<t>This informative appendix documents the evaluation of the proposal to
update IPv6 [RFC2460], to provide the option that some nodes may
suppress generation and checking of the UDP transport checksum. It also
compares the proposal with other alternatives, and notes that for a
particular application some standard methods may be more appropriate
than using IPv6 with a zero UDP checksum.</t>
<section title="Alternatives to the Standard Checksum">
<t>There are several alternatives to the normal method for calculating
the UDP Checksum <xref target="RFC1071"/> that do not require a tunnel
endpoint to inspect the entire packet when computing a checksum. These
include (in decreasing order of complexity):<list style="symbols">
<t>Delta computation of the checksum from an encapsulated checksum
field. Since the checksum is a cumulative sum <xref
target="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 <xref target="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).</t>
<t>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.</t>
<t>The proposed UDP Tunnel Transport <xref target="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.</t>
<t>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 datagram (in the network or an
endpoint) that is treated in this way compared to a packet that
has actually been corrupted.</t>
<t>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).</t>
<t><xref target="I-D.ietf-6man-udpchecksums">UDP modified to
disable checksum processing</xref>. This eliminates the need for a
checksum calculation, but would require constraints on appropriate
usage and updates to end-points and middleboxes.</t>
<t>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.</t>
</list>These options are compared and discussed further in the
following sections.</t>
</section>
<section title="Comparison">
<t>This section compares the above listed methods to support datagram
tunneling. It includes proposals for updating the behaviour of
UDP.</t>
<t>While this comparison focuses on applications that are expected to
execute on routers, the distinction between a router and a host is not
always clear, especially at the transport level. Systems (such as
unix-based operating systems) routinely provide both functions. There
is no way to identify the role of the receiving node from a received
packet.</t>
<section title="Middlebox Traversal">
<t>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.</t>
<t>A method that ignores the UDP checksum on reception is expected
to have a good probability of traversal, because most middleboxes
perform an incremental checksum update. UDPTT would also have been
able to traverse a middlebox with this behaviour. However, a
middlebox on the path that attempts to verify a standard checksum
will not forward packets using either of these methods, preventing
traversal. A method that ignores the checksum has an additional
downside in that it prevents improvement of middlebox traversal,
because there is no way to identify UDP datagrams that use the
modified checksum behaviour.</t>
<t>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.</t>
<t>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.</t>
<t>Datagrams with a zero UDP checksum will not be passed by any
middlebox that validates the checksum using RFC 2460 or updates the
checksum field, such as NAT or firewalls. This would require an
update to correctly handle a datagram with a zero UDP checksum.</t>
<t>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.</t>
</section>
<section title="Load Balancing">
<t>The usefulness of solutions for load balancers depends on the
difference in entropy in the headers for different flows that can be
included in a hash function. All the proposals that use the UDP
protocol number have equal behavior. UDP-Lite has the potential for
equally good behavior as for UDP. However, UDP-Lite is currently
unlikely to be supported by deployed hashing mechanisms, which could
cause a load balancer to not use the transport header in the
computed hash. A load balancer that only uses the IP header will
have low entropy, but could be improved by including the IPv6 the
flow label, providing that the tunnel ingress ensures that different
flow labels are assigned to different flows. However, a transition
to the common use of good quality flow labels is likely to take time
to deploy.</t>
</section>
<section title="Ingress and Egress Performance Implications">
<t>IP-in-IP tunnels are often considered efficient, because they
introduce very little processing and low data overhead. The other
proposals introduce a UDP-like header incurring associated data
overhead. Processing is minimised for the method that uses a zero
UDP checksum, ignoring the UDP checksum on reception, and only
slightly higher for UDPTT, the extension header and UDP-Lite. The
delta-calculation scheme operates on a few more fields, but also
introduces serious failure modes that can result in a need to
calculate a checksum over the complete datagram. Regular UDP is
clearly the most costly to process, always requiring checksum
calculation over the entire datagram.</t>
<t>It is important to note that the zero UDP checksum method,
ignoring checksum on reception, the Option Header, UDPTT and
UDP-Lite will likely incur additional complexities in the
application to incorporate a negotiation and validation
mechanism.</t>
</section>
<section title="Deployability">
<t>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:<list
style="symbols">
<t>The solution with the best deployability is regular UDP. This
requires no changes and has good middlebox traversal
characteristics.</t>
<t>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.</t>
<t>IP-in-IP tunnels should not require changes to the
end-points, but raise issues when traversing firewalls and other
security devices, which are expected to require updates.</t>
<t>Ignoring the checksum on reception will require changes at
both end-points. The never ceasing risk of path failure requires
additional checks to ensure this solution is robust and will
require changes or additions to the tunnel control protocol to
negotiate support and validate the path.</t>
<t>The remaining solutions (including the zero checksum method)
offer similar deployability. UDP-Lite requires support at both
end-points and in middleboxes. UDPTT and the zero UDP checksum
method with or without an extension header require support at
both end-points and in middleboxes. UDP-Lite, UDPTT, and the
zero UDP checksum method and use of extension headers may
additionally require changes or additions to the tunnel control
protocol to negotiate support and path validation.</t>
</list></t>
</section>
<section title="Corruption Detection Strength">
<t>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.</t>
<t>The methods using a zero UDP checksum, ignoring the UDP checksum
on reception and IP-and-IP encapsulation all provide no verification
that a received datagram was intended to be processed by a specific
tunnel egress or that the inner encapsulated packet was correct.
Section 3.1 discusses experience using specific protocols in
well-managed networks.</t>
</section>
<section title="Comparison Summary">
<t>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:</t>
<t><list style="hanging">
<t hangText="Regular UDP:">The method defined in RFC 2460 has
good middlebox traversal and load balancing and multiplexing,
requiring a checksum in the outer headers covering the whole
packet.</t>
<t hangText="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.</t>
<t hangText="UDP-Lite:">A medium complexity encapsulation, with
good multiplexing support, limited middlebox traversal, but
possible to improve over time, currently poor load balancing
support that could improve over time, in most cases requiring
application level negotiation to select the protocol and
validation to confirm the path forwards UDP-Lite.</t>
</list>The delta-checksum is an optimization in the processing of
UDP, as such it exhibits some of the drawbacks of using regular
UDP.</t>
<t>The remaining proposals may be described in similar terms:</t>
<t><list style="hanging">
<t hangText="Zero-Checksum:">A low complexity encapsulation,
with good multiplexing support, limited middlebox traversal that
could improve over time, good load balancing support, in most
cases requiring application level negotiation and validation to
confirm the path forwards a zero UDP checksum.</t>
<t hangText="UDPTT:">A medium complexity encapsulation, with
good multiplexing support, limited middlebox traversal, but
possible to improve over time, good load balancing support, in
most cases requiring application level negotiation to select the
transport and validation to confirm the path forwards UDPTT
datagrams.</t>
<t hangText="IPv6 Destination Option IP in IP tunneling:">A
medium complexity, with no multiplexing support, limited
middlebox traversal, currently poor load balancing support that
could improve over time, in most cases requiring negotiation to
confirm the option is supported and validation to confirm the
path forwards the option.</t>
<t
hangText="IPv6 Destination Option combined with UDP Zero-checksuming:">A
medium complexity encapsulation, with good multiplexing support,
limited load balancing support that could improve over time, in
most cases requiring negotiation to confirm the option is
supported and validation to confirm the path forwards the
option.</t>
<t hangText="Ignore the checksum on reception:">A low complexity
encapsulation, with good multiplexing support, medium middlebox
traversal that never can improve, good load balancing support,
in most cases requiring negotiation to confirm the option is
supported by the remote endpoint and validation to confirm the
path forwards a zero UDP checksum.</t>
</list></t>
<t>There is no clear single optimum solution. If the most important
need is to traverse middleboxes, then the best choice is to stay
with regular UDP and consider the optimizations that may be required
to perform the checksumming. If one can live with limited middlebox
traversal, low complexity is necessary and one does not require load
balancing, then IP-in-IP tunneling is the simplest. If one wants
strengthened error detection, but with currently limited middlebox
traversal and load-balancing. UDP-Lite is appropriate. Zero UDP
checksum addresses another set of constraints, low complexity and a
need for load balancing from the current Internet, providing it can
live with currently limited middlebox traversal.</t>
<t>Techniques for load balancing and middlebox traversal do continue
to evolve. Over a long time, developments in load balancing have
good potential to improve. This time horizon is long since it
requires both load balancer and end-point updates to get full
benefit. The challenges of middlebox traversal are also expected to
change with time, as device capabilities evolve. Middleboxes are
very prolific with a larger proportion of end-user ownership, and
therefore may be expected to take long time cycles to evolve.</t>
<t>One potential advantage is that the deployment of IPv6-capable
middleboxes are still in its initial phase and the quicker a new
method becomes standardized, the fewer boxes will be
non-compliant.</t>
<t>Thus, the question of whether to permit use of datagrams with a
zero UDP checksum for IPv6 under reasonable constraints, is
therefore best viewed as a trade-off between a number of more
subjective questions:</t>
<t><list style="symbols">
<t>Is there sufficient interest in using a zero UDP checksum
with the given constraints (summarised below)?</t>
<t>Are there other avenues of change that will resolve the issue
in a better way and sufficiently quickly ?</t>
<t>Do we accept the complexity cost of having one more solution
in the future?</t>
</list>The analysis concludes that the IETF should carefully
consider constraints on sanctioning the use of any new transport
mode. The 6man working group of the IETF has determined that the
answer to the above questions are sufficient to update IPv6 to
standardise use of a zero UDP checksum for use by tunnel
encapsulations for specific applications.</t>
<t>Each application should consider the implications of choosing an
IPv6 transport that uses a zero UDP checksum. In many cases,
standard methods may be more appropriate, and may simplify
application design. The use of checksum off-loading may help
alleviate the checksum processing cost and permit use of a checksum
using method defined in RFC 2460.</t>
</section>
</section>
</section>
<section title="Document Change History">
<t>{RFC EDITOR NOTE: This section must be deleted prior to
publication}</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="Individual Draft 01"><list style="symbols">
<t>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).</t>
</list></t>
<t hangText="Individual Draft 02"><list style="symbols">
<t>Version -02 corrects some typos and editorial NiTs.</t>
<t>Added reference to ECMP for tunnels.</t>
<t>Clarifies the recommendations at the end of the document.</t>
</list></t>
<t hangText="Working Group Draft 00"><list style="symbols">
<t>Working Group Version -00 corrects some typos and removes
much of rationale for UDPTT. It also adds some discussion of
IPv6 extension header.</t>
</list></t>
<t hangText="Working Group Draft 01"><list style="symbols">
<t>Working Group Version -01 updates the rules and incorporates
off-list feedback. This version is intended for wider review
within the 6man working group.</t>
</list></t>
<t hangText="Working Group Draft 02"><list style="symbols">
<t>This version is the result of a major rewrite and re-ordering
of the document.</t>
<t>A new section comparing the results have been added.</t>
<t>The constraints list has been significantly altered by
removing some and rewording other constraints.</t>
<t>This contains other significant language updates to clarify
the intent of this draft.</t>
</list></t>
<t hangText="Working Group Draft 03"><list style="symbols">
<t>Editorial updates</t>
</list></t>
<t hangText="Working Group Draft 04"><list style="symbols">
<t>Resubmission only updating the AMT and RFC2765
references.</t>
</list></t>
<t hangText="Working Group Draft 05"><list style="symbols">
<t>Resubmission to correct editorial NiTs - thanks to Bill
Atwood for noting these.Group Draft 05.</t>
</list></t>
<t hangText="Working Group Draft 06"><list style="symbols">
<t>Resubmission to keep draft alive (spelling updated from
05).</t>
</list></t>
<t hangText="Working Group Draft 07"><list style="symbols">
<t>Interim Version</t>
<t>Submission after IESG Feedback Added</t>
<t>Updates to enable the document to become a PS Applicability
Statement</t>
</list></t>
<t hangText="Working Group Draft 08"><list style="symbols">
<t>First Version written as a PS Applicability Statement</t>
<t>Changes to reflect decision to update RFC 2460, rather than
recommend decision</t>
<t>Updates to requirements for middleboxes</t>
<t>Inclusion of requirements for security, API, and tunnel</t>
<t>Move of the rationale for the update to an Annex (former
section 4)</t>
</list></t>
<t hangText="Working Group Draft 09"><list style="symbols">
<t>Submission after second WGLC (note mistake corrected in
-09).</t>
<t>Clarified role of API for supporting full checksum.</t>
<t>Clarified that full checksum is required in security
considerations, and therefore noting that full checksum should
not be treated as an attack - consistent with remainder of
document.</t>
<t>Added mention that API can set a mode in transport stack - to
link to similar statement in RFC 2460 update.</t>
<t>Fixed typos.</t>
</list></t>
<t hangText="Working Group Draft 10"><list style="symbols">
<t>Submission to correct unwanted removal of text from section 5
bullets 5-7 by GF.</t>
<t>Replaced section 5 text with the text from 08, and reapplied
the editorial correction.</t>
<t>Note to reviewers: Please compare this revision with -08 used
in the IETF LC).</t>
</list></t>
<t hangText="Working Group Draft 11"><list style="symbols">
<t>Added REF for 5097 (Noted by S.Turner)</t>
<t>Added text in response to P. Resnick on place where checksum
is calculated.</t>
<t>Added text to note experience with MPLS/PWE; Appendix updated
to refer to this (S. Bryant)</t>
<t>Added text in response to P.Resnick's 2nd comments.</t>
<t>Request to make UDP-Lite more clearly recommended (J Touch,
P.Resnick)</t>
<t>Added considerations around usage of zero checksum in
routers.</t>
<t>Added text in response to Stewart Bryant's comments on router
requirements.</t>
</list></t>
</list></t>
</section>
<!-- Change Log
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:41:19 |