One document matched: draft-fairhurst-6man-tsvwg-udptt-02.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. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?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="info" docName="draft-fairhurst-6man-tsvwg-udptt-02"
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="UDPTT">The UDP Tunnel Transport mode</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>
<region></region>
<code></code>
<country>Scotland, UK</country>
</postal>
<phone></phone>
<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>
<date day="20" month="August" year="2009" />
<!-- 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 proposes a standards track protocol called the UDP
Tunnel Transport. This protocol updates the UDP processing of RFC 2460
for IPv6 hosts and routers. The update enables a sender to generate a
UDP datagram where the UDP checksum is replaced by a header check
determined only by the protocol header information. For this use, the
document also updates the way the IPv6 UDP length field is interpreted.
This mode is intended to minimise the processing cost for the transport
of tunnel packets using UDP.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The UDP Tunnel Transport (UDPTT) is a protocol that updates the User
Datagram Protocol (UDP) processing of <xref
target="RFC2460">RFC2460</xref> for IPv6 hosts and routers. UDPTT is
intended to transport datagrams that carry tunnel-encapsulated packets.
It is not intended as a general purpose transport, since it is
applicable only for cases where the tunnel application can provide a set
of checks on the correctness of the received payload.</t>
<t>A UDPTT end point may be either a host or a router. The tunneling
protocol introduces a header check that validates the delivery of the
packet to the correct transport endpoint. This check is not intended as
an authentication check (in the manner of a security protocol), but is
introduced to reduce the probability that the endpoint stacks receive
erroneous packets that may corrupt internal state, introduce unnecessary
packet processing, or lead to ambiguous packet counts.</t>
<t>The way in which the header check is computed in UDPTT will usually
result in a constant value for each UDPTT flow. This value may be cached
as part of the tunnel endpoint flow state. Once the tunnel has been
created, this requires a receiver to perform a 16-bit comparison
operation, rather than a 1's complement checksum. This approach was
driven by a desire to eliminate expensive computation in routers that
may need to handle many flows operating at high rate.</t>
<t>The next section provides background information on UDP variants and
the use of UDP for tunneling. Section 2 defines the UDPTT protocol and
section 3 provides information about the use of UDPTT.</t>
<section title="Background">
<t>UDP is defined in <xref target="RFC0768"></xref>. This 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 receiver validates
this checksum to verify delivery to the intended transport
endpoint.</t>
<t>The UDP header includes a 16-bit one's complement checksum that
provides a statistical guarantee that the payload was not corrupted in
transit. It also allows the receiver to verify that the endpoint was
the intended destination of the datagram, because it includes a pseudo
header that covers the IP addresses, port numbers, transport payload
length, and Next Header/Protocol value corresponding to the UDP
transport protocol. 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. Applications are recommended to enable UDP
checksums <xref target="RFC5405"></xref>, although <xref
target="RFC0768">UDP</xref> permits the option to be disabled when
used with IPv4.</t>
<t>Unlike IPv4, when UDP datagrams are originated by an IPv6 node, the
UDP checksum is not optional. The use of the UDP checksum is required
when applications transmit UDP over IPv6 <xref
target="RFC2460"></xref>, since there is no network-layer integrity
check. UDPTT provides an alternative intended to achieve at least
equivalent protection to using IPv4 (with the associated header
checksum) and UDP (with the checksum disabled).</t>
<t><xref target="RFC3828">UDP-Lite</xref> 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 in the
insensitive part will not cause the packet to be discarded by the
transport layer at the receiving host. When the checksum covers the
entire packet, which should be the default, UDP-Lite is semantically
identical to UDP. UDP-Lite is specified for use with IPv4 and IPv6,
and uses an IP protocol type (or IPv6 next header) with a value of 136
decimal.</t>
<t>While UDP-Lite benefits from differential link error treatment,
where the packet header is afforded higher protection on a radio link
compared to the payload, this is explicitly not the goal of UDPTT. For
UDPTT, the payload is expected to be protected by other integrity
checks, and generally all parts of the packet will seek equal
protection, as for UDP and TCP. Since UDP-Lite also includes the total
packet length (extracted from the IP module), the calculated checksum
depends on the size of the encapsulated packet, whereas in UDPTT, the
checksum protection does not validate the actual size of the transport
layer payload.</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 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"></xref>. 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>
<t>This is expected to be the normal use of UDPTT, where UDPTT may
replace UDP as the tunnel transport when there is a desire to reduce
processing costs at the tunnel endpoints. The end point for the UDPTT
may be either a host or a router.</t>
<t>{Note: The current specification targets use with IPv6, however the
method may also be applicable to IPv4}</t>
<!--Note: The current specification targets use with IPv6, however the method may also be applicable to IPv4-->
</section>
</section>
<section anchor="the_update" title="Update to RFC 2460 to support UDTT">
<t>This section defines the update to IPv6 [RFC2460], if this document
is approved for publication by the IETF.</t>
<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"></xref>.</t>
</section>
<section title="UDPTT Next Header Value">
<t>UDPTT datagrams are carried in the payload of IPv6 packets. UDP and
UDPTT share the next header protocol number (decimal 17) and are
differentiated only by the Length of the IP payload.</t>
</section>
<section title="UDPTT Header Format">
<t>The UDPTT header is shown in figure <xref
target="udptt_format"></xref>. The use of this format resembles that
of UDP.</t>
<figure align="center" anchor="udptt_format"
title="UDPTT Header Format">
<artwork align="center"><![CDATA[ 0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | Header |
| 0x0008 | Check |
+--------+--------+--------+--------+
| |
: UDPTT Payload :
| (no additional integrity check) |
+-----------------------------------+]]></artwork>
</figure>
<t></t>
<t>The source and destination ports are used in the same way as for
UDP and UDP-Lite. UDPTT places the constant value 0x0008 in the
position occupied by the Length field in UDP and the Checksum Coverage
Field in UDP-Lite. The value of 0x0008 is legal for both UDP and
UDP-Lite.</t>
<t>The length of the payload part is determined from the size
information provided by the IP module in the same manner as for <xref
target="RFC0793">TCP</xref>.</t>
<t>The Header Check field is a 16-bit value calculated as specified in
the next section. This value is set by the sender and validated by the
receiver.</t>
</section>
<section title="UDP and UDPTT Datagrams with no payload">
<t>It is expected that UDPTT datagrams will carry a
tunnel-encapsulated packet as payload. A UDPTT datagram with no
payload is indistinguishable from a UDP datagram with no payload. Both
have the same representation on the wire, and the same semantics at
the sender and receiver. There is no need for a receiver to
differentiate these packets.</t>
</section>
<section title="Calculation of IPv6 UDPTT Header Check">
<t>The Header Check is computed as the 16-bit one's complement of the
one's complement sum <xref target="RFC1071"></xref> of a pseudo-header
of information collected from the IPv6 and UDPTT header fields.</t>
<t>The following illustration shows the UDPTT pseudo-header for
IPv6:</t>
<figure align="center" title="UDPTT Pseudo header fields">
<artwork align="center"><![CDATA[ 0 7 8 15 16 23 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000000008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Next H value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="symbols">
<t>As in UDP, if the IPv6 packet carrying the UDPTT datagrams also
carries an additional extension header that contains a Routing
header, the Destination Address used in the pseudo-header is that
of the final destination. At the originating node, that address
will be in the last element of the Routing header; at the
recipient(s), that address will be in the Destination Address
field of the IPv6 header <xref target="RFC2460"></xref>.</t>
<t>The pseudo header is different from the pseudo header of UDP in
one way: This pseudo header replaces the Upper-Layer Packet Length
field, with a constant of 8. This value is identical to the
Upper-Layer Packet Length field that would be returned by a
compliant IPv6 UDP stack with no transport-layer payload <xref
target="RFC2460"></xref>. (It differs from the value that would
have been used by UDP-Lite, which utilises the length reported by
the IP Module in the pseudo header). Encapsulated packets need to
include their own methods to verify integrity and correct payload
length.</t>
<t>The Next H value in the pseudo-header is the value specified
for UDP (17 decimal). This value will differ from the Next Header
value in the IPv6 header if there are extension headers between
the IPv6 header and the upper-layer header.</t>
</list></t>
<t>Prior to computation, the Header Check field MUST be set to zero.
If the computed checksum is 0, it is transmitted as all ones (the
equivalent in one's complement arithmetic) <xref
target="RFC2460"></xref> specifies that IPv6 receivers must discard
UDP datagrams containing a zero checksum, and should log the error.
This processing is preserved in this update.</t>
<t>The way in which the Header check is computed in UDPTT will usually
result in a constant value for each UDP flow. This value may be cached
as part of the tunnel endpoint flow state. Once the tunnel has been
created, a sender MAY insert the cached value instead of computing the
checksum, and a receiver may then use a 16-bit comparison of the
received value against the cached value, rather than a 1's complement
checksum. This approach may be desirable to minimise expensive
computation in routers that need to handle many UDPTT flows operating
at high rate.</t>
</section>
<section title="Multicast support for UDPTT">
<t>Like UDP and UDP-Lite, UDPTT MAY be used as a transport for
multicast datagrams.</t>
</section>
</section>
<section title="Using UDPTT">
<t>This section provides information for implementors and users of
UDPTT.</t>
<section title="UDPTT Usage Guidelines">
<t>Implementors may use UDPTT in the same way as UDP providing that
the application does not need UDPTT to validate the
tunnel-encapsulated packet. The protocol is not constrained to the
semantics of one particular tunnel usage, and is believed compatible
with a range of tunnel mechanisms. If the tunnel requires greater
assurance that tunnel-encapsulated packet is correct or has been
delivered to the correct end point (e.g. where control data is carried
over UDPTT), then the tunnel encapsulation MUST introduce its own
integrity checks. This is consistent with the expected behaviour of
IETF-defined tunnel encapsulations.</t>
<t>IPv6 Jumbograms are not supported in the UDPTT protocol. If
required, such packets may be sent using UDP.</t>
<t>The <xref target="RFC5405">UDP Usage Guidelines</xref> provides
guidance for application designers the use of UDP to support
tunneling. These guidelines also apply to this protocol.</t>
<t>Unlike UDP, UDPTT does not validate the length field of the IP
header when calculating the transport checksum. This design decision
was driven by the goal that the checksum value should not normally
change from packet to packet within a single transport flow. The
omission of this value is a relaxation of the integrity check.
Therefore:</t>
<t><list style="symbols">
<t>A tunnel receiver MUST discard UDPTT packets where the UDPTT
payload size is less than the minimum required by the tunnelled
protocol being transported.</t>
<t>Application stacks SHOULD provide a way for a tunnel endpoint
to identify whether UDPTT is to be used. This could be identified
by a socket option, or similar operating system mechanism. A
sender uses the socket option to include data in a UDPTT datagram
(beyond the base UDP header), the receiver uses this to ensure the
protocol stack passes data based on the Upper Layer payload,
rather than the UDP header).</t>
</list></t>
</section>
<section title="Requirements for Tunnelled Protocols">
<t>This section identifies the requirements for protocols transported
within the payload of a UDPTT datagram.</t>
<t>Specifically, these requirements dictate that:</t>
<t><list style="symbols">
<t>An inner IPv4 (or IPv6) packet with a UDP checksum equal to 0
MUST NOT be tunneled.</t>
<t>The tunneling protocol and implementation MUST NOT be used to
transport IPv4 or IPv6 packets that use network-layer
fragmentation.</t>
<t>A receiver MUST check the size of the tunnel-encapsulated
packet based on information contained in the tunnel-encapsulated
packet. A tunnel receiver MUST discard any tunnel-encapsulated
packets where the reported length of the tunnelled packet is
different to that reported by the IP module (reduced by the size
of any header extensions present).</t>
<t>A packet encapsulated over UDPTT MAY also use the UDPTT tunnel
encapsulation mode, that is, tunnels may be recursively
encpauslated. However, the inner encapsulated packet MUST provide
an integrity check of the transported payload information (e.g.
the inner encapsulated IPv6 packet MUST NOT itself use UDPTT or be
an IPv4 UDP datagram with the checksum disabled).</t>
<t>A tunnel protocol that introduces control information MUST
provide its own integrity check methods (e.g. validating the
integrity of all control information and the length of the control
packet).</t>
<t>Non-IP inner packets MUST use a CRC or other mechanism for
checking packet length and integrity.</t>
</list></t>
</section>
<section title="Backwards compatibility with RFC 2460">
<t>There are three possible behaviours when a UDPTT datagram is
received by an IPv6 host that only supports UDP <xref
target="RFC2460">as defined in </xref>.</t>
<t><list style="numbers">
<t>A receiver checksum algorithm that uses the transport header
Length field to calculate the UDP checksum (<xref
target="RFC2460">as defined for UDP in</xref>) will result in a
valid checksum. However, the number of bytes forwarded to the
upper layer, is dependent on how the payload length is interpreted
when forwarding to the upper layer. An implementation could
forward a number of bytes corresponding to the UDP Length field
(i.e. 8 bytes), removing the payload part. Since the UDP Length
could be interpreted as indicating there is no payload part. This
behaviour would result in an application receiving null UDP
datagrams. Application designers are encouraged to design their
applications to be robust to reception of such datagrams <xref
target="RFC5405"></xref>. Since no data is passed to the
application, there is no danger of inserting unwanted bytes into
the data stream at the receiver. This behaviour is safe, but no
tunnel can be established until the stack is updated to support
UDPTT.</t>
<t>A receiver with a checksum that uses the Upper-Layer Packet
Length from the UDP Length field, and forwards a number of bytes
corresponding to the IP Length field (less any extension headers
present). This receiver will calculate a correct checksum. The
transport layer will forward the UDP datagram towards the
application with the payload part. This is also the expected
behaviour for UDPTT. The application using the transport service
will receive a set of bytes that are bit protected and therefore
may have been modified in transit. Since the UDP payload length is
not verified, the number of bytes could also be modified in
transit. This behaviour may not be what was intended by a UDP
application developer. A tunnel application designed for UDPTT can
use this behaviour.</t>
<t>A receiver with a checksum that uses the IP Length field is not
compliant with <xref target="RFC2460">UDP defined in </xref>).
This receiver will silently discard the packet, because a
mismatching pseudo header would cause the UDP checksum to fail.
This behaviour is safe, but no tunnel can be established until the
stack is updated to support UDPTT.</t>
</list></t>
</section>
<section title=" Middlebox Traversal and Incremental Checksum Update">
<t>Middlebox traversal needs to be considered when planning the
deployment of any new transport protocol. Middleboxes are known to
exist that verify the correctness of the UDP header. Following
publication of this specification it is expected that middleboxes will
support UDPTT:</t>
<t><list style="symbols">
<t>Middleboxes MUST NOT truncate IPv6 datagrams the UDP Header
Length is 8 and the IP length exceeds this length.</t>
<t>If required to update the transport checksum (UDPTT Header
Check), a middlebox MAY use the <xref target="RFC1141">incremental
checksum update procedure</xref>.</t>
<t>If required to validate the transport checksum (UDPTT Header
Check), a middlebox MUST use the method defined in this document
for IPv6 packets with a UDP length of 8.</t>
</list>This document does not modify the requirement that IPv6
receivers must discard UDP datagrams containing a zero checksum <xref
target="RFC2460"></xref>.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The author greatfuly acknowledges inputs provided by Magnus
Westerlund and Marshall Eubanks on the first version of the draft.
Discussion and inputs were provided by Philip Chimento to draft -01.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>The IANA IPv6 Next Header registry entry for the decimal value 17
needs to reference this document in addition to the RFC 2460.</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 spot unusual behaviours.</t>
<t>Section 3.3 describes middlebox traversal. Firewalls and other
security devices may need to be updated to correctly process UDPTT
datagrams.</t>
<t>UDPTT presents a possibility of an attack where an attacker sends a
flood of 'empty' UDPTT datagrams towards a tunnel endpoint. Datagram
applications should be designed to safely receive null datagrams, there
is therefore no danger that the tunnel receiver will insert unwanted
bytes in the application stream, such packets can contribute to the load
of a receiving tunnel server and any middleboxes that process the UDPTT
packet stream.</t>
<t>Unlike UDP, the UDPTT Header Check does not validate the length field
of the IP header when calculating the transport checksum. This design
decision was driven by the goal that the checksum value does not
normally change from packet to packet within a single transport flow.
The omission of this value is a relaxation of the integrity check.
However, a UDPTT application is required to provide its own integrity
check methods. If the IP length field of a UDPTT datagram was modified
in transit, a reduced value would result in "truncation" of the packet
payload, whereas an increase in value would result in additional data
after the intended payload. Endpoints are required to discard any
datagrams with an inconsistent length (after accounting for any
extension headers that may be present).</t>
<t>Endpoints that enable the use of UDPTT in the same port number range
as used for UDP SHOULD provide a method to allow a sending and receiving
application to indicate which port use a specific mode. This could be
performed using a socket option call to allow an application to request
use of the UDPTT semantics.</t>
<t>UDPTT is compatible with the IPsec Encapsulation Security Protocol,
<xref target="RFC4303">ESP</xref>, and the Authentication Header, <xref
target="RFC4302">AH</xref>. This may be used to encapsulated a UDPTT
packet, although this introduces processing that may not be desirable in
some deployment scenarios. IPsec may be used within a
tunnel-encapsulated packet.</t>
<t>A section describes issues relating to backwards compatibility in
hosts. This section may also be applicable to middleboxes that
manipulate the transport-layer information.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- -->
<!--Note: UFDP becomes normative if specified for IPv4. -->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
<?rfc include='reference.RFC.0791'?>
<?rfc include='reference.RFC.0793'?>
<?rfc include='reference.RFC.1071'?>
<?rfc include='reference.RFC.2460'?>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc ?>
<?rfc include='reference.RFC.0768'?>
<?rfc include='reference.RFC.1141'?>
<?rfc include='reference.RFC.4302'?>
<?rfc include='reference.RFC.4303'?>
<?rfc include='reference.RFC.3828'?>
<?rfc include='reference.RFC.5405'?>
<!-- A reference written by by an organization not a person. -->
</references>
<section anchor="app-additional" title="Why do we need a checksum? ">
<t>{This section to be expanded in future revisions}</t>
<t>Previous research showed malformed packets can be received across the
Internet, a side effect of broken internal processing (internal transfer
errors) in routers or hosts. When the checksum is used with UDP/IPv6, it
significantly reduces the impact of such 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>Corruption in the network may result in: <list style="symbols">
<t>a datagram being mis-delivered to the wrong host/router or the
wring transport entity within a host/router. Such a datagram should
be discarded.</t>
<t>a datagram payload being corrupted and delivered to the intended
host/router transport entity. Such a datagram needs to be either
discarded or correctly processed by an application that has 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>The decision to omit an integrity check at the IPv6 level means
that the transport check is overloaded with many functions including
validating: <list style="symbols">
<t>the endpoint address was not corrupted within a router - this
packet was meant for this destination and a wrong header has not
been spliced to a different payload.</t>
<t>the extension header processing is correctly delimited - the
start of data has not been corrupted. The protocol types does this
also to some extent.</t>
<t>reassembly processing, when used.</t>
<t>the length of the payload.</t>
<t>the port values - i.e. the correct application gets the payload
(applications should also check source ports/address).</t>
<t>the payload integrity.</t>
</list></t>
<t>In IPv4, the first 4 checks are made by the IPv4 header checksum.</t>
<t>In IPv6, this checking occurs within the stack using the UDP checksum
information. UDPTT also performs these checks (with the exception of the
length field, which UDPTT performs using the tunnel encapsulated
packet).</t>
<t>An IPv6 node also relies on the header information to determine
whether to send an ICMPv6 error message 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>
<t>In tunnel encapsulations, payload integrity and length verification
may be provided by higher layer tunnel encapsulations (often using the
IPv4, UDP, UDP-Lite, or TCP checksums).</t>
<t>There are implications on the detectability of mis-delivery of a
packet to an incorrect endpoint/socket, and the robustness of the
Internet infrastructure.</t>
<t>The IETF has defined other tunneling protocols that do not include a
check value. However, these are typically layered directly over the
Internet layer (identified by the upper layer type field) and are not
also used as endpoint transport protocols. 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. Since the UDP port space is shared many diverse
application, this check is not available when UDP is used as transport
and therefore the demultiplexing relies solely on the destination port
number.</t>
<t>Deterministic reporting of statistics is desirable: router/endpoint
MIBs and other statistics gathering methods have the ability to detect
this type of error, rather than recording this as valid traffic between
spurious endpoints.</t>
<t>Some IPv6 aware middleware and firewalls may drop or truncate UDPTT
datagrams.</t>
<t>{Note: The author would be glad to know of specific cases of
truncation and other behaviours.}</t>
<section title="IPv4 Compatibility">
<t>The current version of this document does not specify encapsulation
using IPv4 <xref target="RFC0791"></xref>. For this network protocol.
UDP is permitted to disable the UDP checksum and rely on the IPv4
header checksum.</t>
<t>{Note: Future versions of this document could also consider support
for IPv4 if the WG considers this useful|}</t>
</section>
<section title="Why not set the IPv6 UDP checksum to zero?">
<t>{This section to be expanded in future revisions}</t>
<t>Topics to be discussed:<list style="symbols">
<t>The role of a router and host are not fixed. 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. the UDP checksum
can be disabled only on a router). In IPv6, a node may select a
role of a router or host on a per interface basis. Protocol
changes intended for one specific use are often re-used for
different applications.</t>
<t>Why ignore checksum on reception is niave</t>
<t>Behaviour of NAT/Middleboxes needs to be updated for UDPTT and
for UDP cksum==0</t>
<t>Implications on host acting as routers and transport end
points.</t>
<t>Requires restrictions on recursive tunnels that are not
necessary with UDPTT</t>
</list></t>
<t></t>
</section>
</section>
<section title="Applicability for AMT">
<t>This specification is intended to be suited to use with "Automatic IP
Multicast Without Explicit Tunnels", also known as "AMT". AMT currently
specifies UDP as the transport protocol for tunneled packets; that is,
the outer packet carrying a tunneled (inner) packet. The specification
is for packets carrying tunneled multicast data only. In AMT, the UDP
checksum in the UDP header of the outer packet SHOULD be 0 (See
draft-ietf-mboned-auto-multicast-09, Section 6.6). However RFC 2460
(IPv6) explicitly states that IPv6 receivers MUST discard UDP packets
with a 0 checksum. So, while sending a UDP packet with a 0 checksum is
permitted in IPv4 packets, it is explicitly forbidden in IPv6 packets.
The computation of an additional checksum, when the inner packet(s) are
already adequately protected, is seen to be an unwarranted burden on
nodes implementing lightweight tunneling protocols.</t>
<t>The intention is that UDPTT offers a safe alternate approach to the
IPv6 method currently defined in AMT.</t>
</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 presentation of
this document.</t>
<t hangText="Draft -01">Phil Chimento helped define changes to
improve the protocol. <list style="symbols">
<t>Added text on excluding the header length value in the pseudo
header for the UDPTT Header Check.</t>
<t>Rewrote security considerations</t>
<t>Added caveats for protocols using UDPTT</t>
</list></t>
<t hangText="Draft -02"><list style="symbols">
<t>Fixed typos from XML formatting</t>
<t>Added some text on ICMP</t>
<t>Middleboxes MUST use UDPTT semantics for UDPTT</t>
<t>Added more text on why UDP cksum==0 may be bad</t>
<t>Added text on UDPTT API needs</t>
<t>Allowed recursion, of UDPTT, but not final inner protocol</t>
</list></t>
<t hangText="Issues "><list style="symbols">
<t>More detailed analysis of the UDP cksum==0 case could be
added</t>
</list></t>
</list></t>
</section>
<!-- Change Log
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:26:03 |