One document matched: draft-fairhurst-6man-tsvwg-udptt-00.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-00"
ipr="trust200902">
<!-- 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="13" month="April" 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 the UDP
Tunnel Transport. This protocol updates the UDP processing of RFC 2460
for 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. The document also updates the
way the IPv6 UDP length field is interpreted. The use of 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 UDP
processing of <xref target="RFC2460">RFC2460</xref> for hosts and
routers. UDPTT is intended to transport datagrams that carry
tunnel-encapsulated packets,</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 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 UDP flow. This value may be cached
as part of the tunnel endpoint flow state. Once the tunnel has been
created, this requires 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 and UDP for tunneling. Section 2 defines the UDPTT
protocol and section 3 provides information about the use of UDPTT.</t>
<section title="Background">
<t>The User Datagram Protocol (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.</t>
<t>The UDP header includes an optional, 16-bit one's complement
checksum that provides an a statistical guarantee that the payload was
not corrupted in transit. It also allows the receiver to verify that
it was the intended destination of the datagram, because it includes a
pseudo header that covers the IP addresses, port numbers, and Next
Header value corresponding to the UDP transport protocol. This
verifies that the datagram is not truncated or padded, because it
covers the size field. It 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). The offered protection
is identical to that provided by UDP-Lite using minimal checksum
coverage.</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 end 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 will normally be protected by other integrity
checks, and generally all parts of the packet will seek equal
protection, as for UDP and TCP.</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">udptt_format</xref> . The use of this format
resembles that of UDP, and is a subset of the format specified for
UDP-Lite <xref target="RFC3828"></xref>.</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 does not provide any additional information to
identify the type of tunnel being supported or the format of the
tunnel encapsulation.</t>
<t>In UDPTT, the Length field has been replaced by a constant value of
8 (corresponding to the size of the UDP pseudo-header). The length of
the payload part is determined by 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 normally 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 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 UDP header fields <xref
target="RFC2460"></xref>.</t>
<t>Prior to computation, the checksum 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 pseudo header is different from the pseudo header of UDP in one
way: The value of the Upper-Layer Packet Length field of the pseudo
header<xref target="RFC2460"></xref> is not taken from the UDPTT
header, but rather from information provided by the IP module. This
computation is perfomed in the same manner as for <xref
target="RFC0793">TCP</xref>, where the Length field in the pseudo
header includes the UDPTT header and all subsequent bytes in the IPv6
payload.</t>
<t>IPv6 Jumbograms are NOT supported in the UDPTT protocol. If
required, such packets may be sent using UDP.</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 teh
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 eliminate 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="Guidelines for Application Designers">
<t>Implementors may use UDPTT in the same way as UDP providing that
the application does not need to validate the UDP datagram payload.
The protocol is not constrained to the semantics of one particular
tunnel usage, and is belived compatible with a range of tunnel
mechanisms. Like UDP-Lite, this protocol does not provide an integrity
check of the payload data, in this case assumed to be a tunneled
packet. This is consistent with other IETF-defined tunnel
encapsulations. If the tunnel requires greater assurance that data is
correct or has been delivered to the correct end point (e.g. where
control data is carried over UDPTT), then the tunnel encapsulation
SHOULD introduce its own integrity checks.</t>
<t>Implementors may use cache the Header Check value (as described in
section 2.5) to reduce per-packet processing cost for established
tunnels.</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>
</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>. <list style="numbers">
<t>A receiver with a checksum that uses the Upper-Layer Packet
Length from the IP Length field. A receiver that uses the
UDP-Length field 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>
<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 UDP Length field. A receiver that uses the
UDP-Length field will calculate a correct checksum. The transport
layer will forward a truncated UDP packet (with the payload part
removed), since the UDP Length will be interpreted as indicating
there is no payload part. This behaviour may result in an
application receiving null UDP packets. Application designers are
encouraged to design their applications to be robust to such
packets <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. A receiver that uses the
UDP-Length field will calculate a correct checksum. The transport
layer will forward the UDP packet towards the application with the
payload part. This is also the expected behaviour for 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 SHOULD NOT truncate IPv6 datagrams where the IP
length exceeds the Length specified in the UDP Header.</t>
<t>If required to update the transport checksum (UDPTT Header
Check), a middlebox MAY use the <xref
target="RFC1141">increemental 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.</t>
</list>This document does not modify the requirement that IPv6
receivers must discard UDP datagrams containing a zero checksum <xref
target="RFC2460">zero checksum</xref>.</t>
<t></t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements"></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>{This section to be expanded in future revisions}</t>
<t>Checks provide the first stage of protection for the stack, although
they can not be considered authentication mechanisms.</t>
<t>Checks are 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>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>
<t>UDPTT is compatible with the IPsec Encapsulation Security Protocol,
<xref target="RFC2406">ESP</xref>, and the Authentication Header, <xref
target="RFC2402">AH</xref>.</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 Refe.xmlrences">
<!-- 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.2402'?>
<?rfc include='reference.RFC.2406'?>
<?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? Stuff">
<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.</t>
<t>In tunnel encapsulations, payload integrity 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 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>{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>RFC2460</t>
<t>Behaviour of NAT/Middleboxes</t>
<t>Implications on host acting as routers and transport end
points.</t>
</list></t>
<t></t>
</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 presentation of
this document.</t>
</list></t>
</section>
<!-- Change Log
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 17:00:51 |