One document matched: draft-fairhurst-6man-tsvwg-udptt-01.txt
Differences from draft-fairhurst-6man-tsvwg-udptt-00.txt
Internet Engineering Task Force G. Fairhurst
Internet-Draft University of Aberdeen
Intended status: Informational June 21, 2009
Expires: December 23, 2009
The UDP Tunnel Transport mode
draft-fairhurst-6man-tsvwg-udptt-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document proposes a standards track protocol called the UDP
Tunnel Transport. This protocol updates the UDP processing of RFC
2460 for hosts and routers. The update enables a sender to generate
Fairhurst Expires December 23, 2009 [Page 1]
Internet-Draft UDPTT June 2009
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 4
2. Update to RFC 2460 to support UDTT . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. UDPTT Next Header Value . . . . . . . . . . . . . . . . . 5
2.3. UDPTT Header Format . . . . . . . . . . . . . . . . . . . 5
2.4. UDP and UDPTT Datagrams with no payload . . . . . . . . . 6
2.5. Calculation of Header Check . . . . . . . . . . . . . . . 6
2.6. Multicast support for UDPTT . . . . . . . . . . . . . . . 7
3. Using UDPTT . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. UDPTT Usage Guidelines . . . . . . . . . . . . . . . . . . 8
3.2. Requirements for Tunnelled Protocols . . . . . . . . . . . 8
3.3. Backwards compatibility with RFC 2460 . . . . . . . . . . 9
3.4. Middlebox Traversal and Incremental Checksum Update . . . 10
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Why do we need a checksum? . . . . . . . . . . . . . 13
A.1. IPv4 Compatibility . . . . . . . . . . . . . . . . . . . . 14
A.2. Why not set the IPv6 UDP checksum to zero? . . . . . . . . 15
Appendix B. Applicability for AMT . . . . . . . . . . . . . . . . 15
Appendix C. Document Change History . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Fairhurst Expires December 23, 2009 [Page 2]
Internet-Draft UDPTT June 2009
1. Introduction
The UDP Tunnel Transport (UDPTT) is a protocol that updates the User
Datagram Protocol (UDP) processing of RFC2460 [RFC2460] for 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.
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.
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.
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.
1.1. Background
UDP is defined in [RFC0768]. 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.
The UDP header includes a 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 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.
Fairhurst Expires December 23, 2009 [Page 3]
Internet-Draft UDPTT June 2009
Applications are recommended to enable UDP checksums [RFC5405],
although UDP [RFC0768] permits the option to be disabled when used
with IPv4.
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 [RFC2460], 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).
UDP-Lite [RFC3828] 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.
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.
1.2. Use of UDP Tunnels
One increasingly popular use of UDP is as a tunneling protocol, where
a tunnel endpoint encapsulates the packets of another protocol inside
UDP datagrams and transmits them to another tunnel endpoint. Using
UDP as a tunneling protocol is attractive when the payload protocol
is not supported by middleboxes that may exist along the path,
because many middleboxes support transmission using UDP. In this
use, the receiving endpoint decapsulates the UDP datagrams and
forwards the original packets contained in the payload [RFC5405].
Tunnels establish virtual links that appear to directly connect
locations that are distant in the physical Internet topology and can
be used to create virtual (private) networks.
This is expected to be the normal use of UDPTT, where UDPTT may
Fairhurst Expires December 23, 2009 [Page 4]
Internet-Draft UDPTT June 2009
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.
{Note: The current specification targets use with IPv6, however the
method may also be applicable to IPv4}
2. Update to RFC 2460 to support UDTT
This section defines the update to IPv6 [RFC2460], if this document
is approved for publication by the IETF.
2.1. Terminology
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 [RFC2119].
2.2. UDPTT Next Header Value
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.
2.3. UDPTT Header Format
The UDPTT header is shown in figure udptt_format (Figure 1) . The
use of this format resembles that of UDP.
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | Header |
| 0x0008 | Check |
+--------+--------+--------+--------+
| |
: UDPTT Payload :
| (no additional integrity check) |
+-----------------------------------+
Figure 1: UDPTT Header Format
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 Checksum Coverage Field in
UDP-Lite. The value of 0x0008 is legal for both UDP and UDP-Lite.
Fairhurst Expires December 23, 2009 [Page 5]
Internet-Draft UDPTT June 2009
The length of the payload part is determined from the size
information provided by the IP module in the same manner as for TCP
[RFC0793].
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.
2.4. UDP and UDPTT Datagrams with no payload
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.
2.5. Calculation of Header Check
The Header Check is computed as the 16-bit one's complement of the
one's complement sum [RFC1071] of a pseudo-header of information
collected from the IPv6 and UDPTT header fields.
The following illustration shows the UDPTT pseudo-header for IPv6:
0 7 8 15 16 23 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000000008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Next H value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fairhurst Expires December 23, 2009 [Page 6]
Internet-Draft UDPTT June 2009
UDPTT Pseudo header fields
o As in UDP, if the IPv6 packet carrying the UDPTT datagrams any
additional ext 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 [RFC2460].
o 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
[RFC2460]. (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.
o 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.
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) [RFC2460] specifies that
IPv6 receivers must discard UDP datagrams containing a zero checksum,
and should log the error. This processing is preserved in this
update.
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
eliminate expensive computation in routers that need to handle many
UDPTT flows operating at high rate.
2.6. Multicast support for UDPTT
Like UDP and UDP-Lite, UDPTT MAY be used as a transport for multicast
datagrams.
Fairhurst Expires December 23, 2009 [Page 7]
Internet-Draft UDPTT June 2009
3. Using UDPTT
This section provides information for implementors and users of
UDPTT.
3.1. UDPTT Usage Guidelines
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.
IPv6 Jumbograms are not supported in the UDPTT protocol. If
required, such packets may be sent using UDP.
The UDP Usage Guidelines [RFC5405] provides guidance for application
designers the use of UDP to support tunneling. These guidelines also
apply to this protocol.
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 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. Therefore:
A tunnel receiver MUST discard UDPTT packets where the UDPTT payload
size is less than the minimum required by the tunnelled protocol
being transported.
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.
3.2. Requirements for Tunnelled Protocols
This section identifies the requirements for protocols transported
within the payload of a UDPTT datagram.
Specifically, these requirements dictate that:
Fairhurst Expires December 23, 2009 [Page 8]
Internet-Draft UDPTT June 2009
o An inner IPv4 (or IPv6) packet with a UDP checksum equal to 0 MUST
NOT be tunneled.
o The tunneling protocol and implementation MUST NOT be used to
transport IPv4 or IPv6 packets that use network-layer
fragmentation.
o 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).
o A packet encapsulated over UDPTT MUST provide an integrity check
of the transported information (e.g. an IPv6 packet that does not
itself carry UDPTT).
o 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).
o Non-IP inner packets MUST use a CRC or other mechanism for
checking packet length and integrity.
o Tunneling protocols that send IPv4 packets with the UDP checksum
equal to 0 MUST NOT be tunneled themselves over UDPTT (even if
more deeply encapsulated packets have checksums or other integrity
checking mechanisms).
3.3. Backwards compatibility with RFC 2460
There are three possible behaviours when a UDPTT datagram is received
by an IPv6 host that only supports UDP as defined in [RFC2460].
1. A receiver that uses a checksum algorithm uses the transport
header Length field to calculate the UDP checksum (as defined for
UDP in [RFC2460]) 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 -
corresponding to only the ports fields), 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 [RFC5405]. Since no data is passed
Fairhurst Expires December 23, 2009 [Page 9]
Internet-Draft UDPTT June 2009
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.
2. 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.
3. A receiver with a checksum that uses the IP Length field is not
compliant with UDP defined in [RFC2460]) . 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.
3.4. Middlebox Traversal and Incremental Checksum Update
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:
o Middleboxes SHOULD NOT truncate IPv6 datagrams where the IP length
exceeds the Length specified in the UDP Header.
o If required to update the transport checksum (UDPTT Header Check),
a middlebox MAY use the incremental checksum update procedure
[RFC1141].
o If required to validate the transport checksum (UDPTT Header
Check), a middlebox MUST use the method defined in this document.
This document does not modify the requirement that IPv6 receivers
must discard UDP datagrams containing a zero checksum zero checksum
[RFC2460].
Fairhurst Expires December 23, 2009 [Page 10]
Internet-Draft UDPTT June 2009
4. Acknowledgements
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.
5. IANA Considerations
The IANA IPv6 Next Header registry entry for the decimal value 17
needs to reference this document in addition to the RFC 2460.
6. Security Considerations
{This section to be expanded in future revisions}
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.
Section 3.3 describes middlebox traversal. Firewalls and other
security devices may need to be updated to correctly process UDPTT
datagrams.
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.
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 a packet 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).
UDPTT is compatible with the IPsec Encapsulation Security Protocol,
Fairhurst Expires December 23, 2009 [Page 11]
Internet-Draft UDPTT June 2009
ESP [RFC4303], and the Authentication Header, AH [RFC4302]. 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.
A section describes issues relating to backwards compatibility in
hosts. This section may also be applicable to middleboxes that
manipulate the transport-layer information.
7. References
7.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071,
September 1988.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
7.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the
Internet checksum", RFC 1141, January 1990.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
Fairhurst Expires December 23, 2009 [Page 12]
Internet-Draft UDPTT June 2009
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
Appendix A. Why do we need a checksum?
{This section to be expanded in future revisions}
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.
Corruption in the network may result in:
o 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.
o 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.
o a datagram payload being truncated by corruption of the length
field. Such a datagram needs to be discarded.
The decision to omit an integrity check at the IPv6 level means that
the transport check is overloaded with many functions including
validating:
o the endpoint address was not corrupted within a router - this
packet was meant for this destination and a wrong header has not
been spliced to a different payload.
o the extension header processing is correctly delimited - the start
of data has not been corrupted. The protocol types does this also
to some extent.
o reassembly processing, when used.
o the length of the payload.
Fairhurst Expires December 23, 2009 [Page 13]
Internet-Draft UDPTT June 2009
o the port values - i.e. the correct application gets the payload
(applications should also check source ports/address).
o the payload integrity.
In IPv4, the first 4 checks are made by the IPv4 header checksum.
In IPv6, this checking occurs within the stack using the UDP checksum
information. UDPTT also performs these checks.
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).
There are implications on the detectability of mis-delivery of a
packet to an incorrect endpoint/socket, and the robustness of the
Internet infrastructure.
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.
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.
Some IPv6 aware middleware and firewalls may drop or truncate UDPTT
datagrams.
{Note: The author would be glad to know of specific cases of
truncation and other behaviours.}
A.1. IPv4 Compatibility
The current version of this document does not specify encapsulation
using IPv4 [RFC0791]. For this network protocol. UDP is permitted
to disable the UDP checksum and rely on the IPv4 header checksum.
{Note: Future versions of this document could also consider support
for IPv4 if the WG considers this useful|}
Fairhurst Expires December 23, 2009 [Page 14]
Internet-Draft UDPTT June 2009
A.2. Why not set the IPv6 UDP checksum to zero?
{This section to be expanded in future revisions}
Topics to be discussed:
o RFC2460
o Behaviour of NAT/Middleboxes
o Implications on host acting as routers and transport end points.
Appendix B. Applicability for AMT
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.
The intention is that UDPTT offers a safe alternate approach to the
IPv6 method currently defined in AMT.
Appendix C. Document Change History
{RFC EDITOR NOTE: This section must be deleted prior to publication}
Individual Draft 00 This is the first presentation of this
document.
Draft -01 Phil Chimento helped define changes to improve the
protocol.
* Added text on excluding the header length value in the pseudo
header for the UDPTT Header Check.
Fairhurst Expires December 23, 2009 [Page 15]
Internet-Draft UDPTT June 2009
* Rewrote security considerations
* Added caveats for protocols using UDPTT
* MUST DO - how do receivers differentiate UDPTT from other UDP
packets? - Could be via API call-down to enter UDPTT mode
(setsockopt) or by something in the UDPTT header, or attempting
both UDP and UDPTT checksums and seeing which worked. The
simplest case would be to set UDPTT inner length to 1 (which is
not valid for UDP/IPv6 or UDP/IPv4).
*
Issues left
*
Author's Address
Godred Fairhurst
University of Aberdeen
School of Engineering
Aberdeen, AB24 3UE,
Scotland, UK
Phone:
Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry
Fairhurst Expires December 23, 2009 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 17:34:04 |