draft-ietf-tsvwg-udp-lite-02.txt   rfc3828.txt 
Network Working Group L-A. Larzon Network Working Group L-A. Larzon
INTERNET-DRAFT Lulea University of Technology Request for Comments: 3828 Lulea University of Technology
Expires: January 2003 M. Degermark Category: Standards Track M. Degermark
S. Pink S. Pink
The University of Arizona The University of Arizona
L-E. Jonsson (Editor) L-E. Jonsson, Ed.
Ericsson Ericsson
G. Fairhurst (Editor) G. Fairhurst, Ed.
University of Aberdeen University of Aberdeen
August, 2003 July 2004
The UDP-Lite Protocol
<draft-ietf-tsvwg-udp-lite-02.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering The Lightweight User Datagram Protocol (UDP-Lite)
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 Status of this Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/lid-abstracts.txt Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
Please direct comments to the TSV WG mailing list: tsvwg@ietf.org Copyright (C) The Internet Society (2004).
Abstract Abstract
This document describes the UDP-Lite protocol, which is similar to This document describes the Lightweight User Datagram Protocol (UDP-
UDP [RFC-768], but can also serve applications that in error-prone Lite), which is similar to the User Datagram Protocol (UDP) (RFC
network environments prefer to have partially damaged payloads 768), but can also serve applications in error-prone network
delivered rather than discarded. If this feature is not used, UDP- environments that prefer to have partially damaged payloads delivered
Lite is semantically identical to UDP. rather than discarded. If this feature is not used, UDP-Lite is
semantically identical to UDP.
Table of Contents Table of Contents
Larzon, et al. [Page 1] 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Introduction...................................................2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology....................................................3 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Description...........................................3 3.1. Fields . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Fields....................................................3 3.2. Pseudo Header. . . . . . . . . . . . . . . . . . . . . . 5
3.2. Pseudo Header.............................................4 3.3. Application Interface. . . . . . . . . . . . . . . . . . 5
3.3. Application Interface.....................................4 3.4. IP Interface . . . . . . . . . . . . . . . . . . . . . . 6
3.4. IP Interface..............................................5 3.5. Jumbograms . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Jumbograms................................................5 4. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 6
4. Lower Layer Considerations.....................................6 5. Compatibility with UDP . . . . . . . . . . . . . . . . . . . . 7
5. Compatibility with UDP.........................................6 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations........................................7 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations............................................8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. References.....................................................8 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.1. Normative References......................................8 8.2. Informative References . . . . . . . . . . . . . . . . . 9
8.2. Informative References....................................9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements...............................................10 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
10. Authors' Addresses............................................11 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document describes a new transport protocol, UDP-Lite, (also This document describes a new transport protocol, UDP-Lite, (also
known as UDPLite). This new protocol is based on three observations: known as UDPLite). This new protocol is based on three observations:
First, there is a class of applications that benefit from having First, there is a class of applications that benefit from having
damaged data delivered rather than discarded by the network. A number damaged data delivered rather than discarded by the network. A
of codecs for voice and video fall into this class (e.g. the AMR number of codecs for voice and video fall into this class (e.g., the
speech codec [RFC-3267], the Internet Low Bit Rate Codec [ILBRC], and AMR speech codec [RFC-3267], the Internet Low Bit Rate Codec [ILBRC],
error resilient H.263+ [ITU-H.263], H.264 [ITU-H.264; H.264] and and error resilient H.263+ [ITU-H.263], H.264 [ITU-H.264; H.264], and
MPEG-4 [ISO-14496] video codecs). These codecs may be designed to MPEG-4 [ISO-14496] video codecs). These codecs may be designed to
cope better with errors in the payload than with loss of entire cope better with errors in the payload than with loss of entire
packets. packets.
Second, all links that support IP transmission should use a strong Second, all links that support IP transmission should use a strong
link layer integrity check (e.g. CRC-32 [LINK]), and this MUST be link layer integrity check (e.g., CRC-32 [RFC-3819]), and this MUST
used by default for IP traffic. When the under-lying link supports be used by default for IP traffic. When the under-lying link
it, certain types of traffic (e.g. UDP-Lite) may benefit from a supports it, certain types of traffic (e.g., UDP-Lite) may benefit
different link behavior that permits partially damaged IP packets to from a different link behavior that permits partially damaged IP
be forwaded when requested [LINK]. Several radio technologies (e.g. packets to be forwarded when requested [RFC-3819]. Several radio
[3GPP-QoS]) support this link behavior when operating at a point technologies (e.g., [3GPP]) support this link behavior when operating
where cost and delay are sufficiently low. If error-prone links are at a point where cost and delay are sufficiently low. If error-prone
aware of the error sensitive portion of a packet, it is also possible links are aware of the error sensitive portion of a packet, it is
for the physical link to provide greater protection to reduce the also possible for the physical link to provide greater protection to
probability of corruption of these error sensitive bytes (e.g., the reduce the probability of corruption of these error sensitive bytes
use of unequal Forward Error Correction). (e.g., the use of unequal Forward Error Correction).
Third, intermediate layers (i.e., IP and the transport layer Third, intermediate layers (i.e., IP and the transport layer
protocols) should not prevent error-tolerant applications from protocols) should not prevent error-tolerant applications from
running well in the presence of such links. IP is not a problem in running well in the presence of such links. IP is not a problem in
this regard, since the IP header has no checksum that covers the IP this regard, since the IP header has no checksum that covers the IP
payload. The generally available transport protocol best suited for payload. The generally available transport protocol best suited for
Larzon, et al. [Page 2]
these applications is UDP, since it has no overhead for these applications is UDP, since it has no overhead for
retransmission of erroneous packets, in-order delivery, or error retransmission of erroneous packets, in-order delivery, or error
correction. In IPv4 [RFC-791], the UDP checksum covers either the correction. In IPv4 [RFC-791], the UDP checksum covers either the
entire packet or nothing at all. In IPv6 [RFC-2460], the UDP checksum entire packet or nothing at all. In IPv6 [RFC-2460], the UDP
is mandatory and must not be disabled. The IPv6 header does not have checksum is mandatory and must not be disabled. The IPv6 header does
a header checksum and it was deemed necessary to always protect the not have a header checksum and it was deemed necessary to always
IP addressing information by making the UDP checksum mandatory. protect the IP addressing information by making the UDP checksum
mandatory.
A transport protocol is needed that conforms to the properties of A transport protocol is needed that conforms to the properties of
link layers and applications described above [LDP99]. The error- link layers and applications described above [LDP99]. The error-
detection mechanism of the transport layer must be able to protect detection mechanism of the transport layer must be able to protect
vital information such as headers, but also to optionally ignore vital information such as headers, but also to optionally ignore
errors best dealt with by the application. The set of octets to be errors best dealt with by the application. The set of octets to be
verified by the checksum is best specified by the sending verified by the checksum is best specified by the sending
application. application.
UDP-Lite provides a checksum with an optional partial coverage. When UDP-Lite provides a checksum with an optional partial coverage. When
skipping to change at page 13, line ? skipping to change at page 4, line 5
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
3. Protocol Description 3. Protocol Description
The UDP-Lite header is shown in figure 1. Its format differs from The UDP-Lite header is shown in figure 1. Its format differs from
UDP in that the Length field has been replaced with a Checksum UDP in that the Length field has been replaced with a Checksum
Coverage field. This can be done since information about UDP packet Coverage field. This can be done since information about UDP packet
length can be provided by the IP module in the same manner as for TCP length can be provided by the IP module in the same manner as for TCP
[RFC-793]. [RFC-793].
Larzon, et al. [Page 3]
0 15 16 31 0 15 16 31
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source | Destination | | Source | Destination |
| Port | Port | | Port | Port |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Checksum | | | Checksum | |
| Coverage | Checksum | | Coverage | Checksum |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| | | |
: Payload : : Payload :
| | | |
+-----------------------------------+ +-----------------------------------+
Figure 1: UDP-Lite Header Format Figure 1: UDP-Lite Header Format
3.1. Fields 3.1. Fields
The fields Source Port and Destination Port are defined as in the UDP The fields Source Port and Destination Port are defined as in the UDP
specification [RFC-768]. UDP-Lite uses the same set of port number specification [RFC-768]. UDP-Lite uses the same set of port number
values as those assigned by the IANA for use by UDP. values assigned by the IANA for use by UDP.
Checksum Coverage is the number of octets, counting from the first Checksum Coverage is the number of octets, counting from the first
octet of the UDP-Lite header, that are covered by the checksum. The octet of the UDP-Lite header, that are covered by the checksum. The
UDP-Lite header MUST always be covered by the checksum. Despite this UDP-Lite header MUST always be covered by the checksum. Despite this
requirement, the Checksum Coverage is expressed in octets from the requirement, the Checksum Coverage is expressed in octets from the
beginning of the UDP-Lite header, in the same way as for UDP. A beginning of the UDP-Lite header in the same way as for UDP. A
Checksum Coverage of zero indicates that the entire UDP-Lite packet Checksum Coverage of zero indicates that the entire UDP-Lite packet
is covered by the checksum. This means that the value of the Checksum is covered by the checksum. This means that the value of the
Coverage field MUST be either 0 or at least 8. A UDP-Lite packet with Checksum Coverage field MUST be either 0 or at least 8. A UDP-Lite
a Checksum Coverage value of 1 to 7 MUST be discarded by the packet with a Checksum Coverage value of 1 to 7 MUST be discarded by
receiver. Irrespective of the Checksum Coverage, the computed the receiver. Irrespective of the Checksum Coverage, the computed
Checksum field MUST include a pseudo-header, based on the IP header Checksum field MUST include a pseudo-header, based on the IP header
(see below). UDP-Lite packets with a Checksum Coverage greater than (see below). UDP-Lite packets with a Checksum Coverage greater than
the IP length MUST also be discarded. the IP length MUST also be discarded.
The Checksum field is the 16-bit one's complement of the one's The Checksum field is the 16-bit one's complement of the one's
complement sum of a pseudo-header of information collected from the complement sum of a pseudo-header of information collected from the
IP header, the number of octets specified by the Checksum Coverage IP header, the number of octets specified by the Checksum Coverage
(starting at the first octet in the UDP-Lite header), virtually (starting at the first octet in the UDP-Lite header), virtually
padded with a zero octet at the end (if necessary) to make a multiple padded with a zero octet at the end (if necessary) to make a multiple
of two octets [RFC-1071]. Prior to computation, the checksum field of two octets [RFC-1071]. Prior to computation, the checksum field
MUST be set to zero. If the computed checksum is 0, it is transmitted MUST be set to zero. If the computed checksum is 0, it is
as all ones (the equivalent in one's complement arithmetic). transmitted as all ones (the equivalent in one's complement
arithmetic).
Since the transmitted checksum MUST NOT be all zeroes, an application Since the transmitted checksum MUST NOT be all zeroes, an application
using UDP-Lite that wishes to have no protection of the packet using UDP-Lite that wishes to have no protection of the packet
payload, should use a Checksum Coverage value of 8. This differs from payload should use a Checksum Coverage value of 8. This differs
the use of UDP over IPv4, in that the minimal UDP-Lite checksum from the use of UDP over IPv4 in that the minimal UDP-Lite checksum
always covers the UDP-Lite protocol header, which includes the always covers the UDP-Lite protocol header, which includes the
Checksum Coverage field. Checksum Coverage field.
Larzon, et al. [Page 4]
3.2. Pseudo Header 3.2. Pseudo Header
UDP and UDP-Lite use the same conceptually prefixed pseudo header UDP and UDP-Lite use the same conceptually prefixed pseudo header
from the IP layer for the checksum. This pseudo header is different from the IP layer for the checksum. This pseudo header is different
for IPv4 and IPv6. The pseudo header of UDP-Lite is different from for IPv4 and IPv6. The pseudo header of UDP-Lite is different from
the pseudo header of UDP in one way: The value of the Length field of the pseudo header of UDP in one way: The value of the Length field of
the pseudo header is not taken from the UDP-Lite header, but rather the pseudo header is not taken from the UDP-Lite header, but rather
from information provided by the IP module. This computation is done from information provided by the IP module. This computation is done
in the same manner as for TCP [RFC-793], and implies that the Length in the same manner as for TCP [RFC-793], and implies that the Length
field of the pseudo header includes the UDP-Lite header and all field of the pseudo header includes the UDP-Lite header and all
subsequent octets in the IP payload. subsequent octets in the IP payload.
3.3. Application Interface 3.3. Application Interface
An application interface should allow the same operations as for An application interface should allow the same operations as for UDP.
UDP. In addition to this, it should provide a way for the sending In addition to this, it should provide a way for the sending
application to pass the Checksum Coverage value to the UDP-Lite application to pass the Checksum Coverage value to the UDP-Lite
module. There should also be a way to pass the Checksum Coverage module. There should also be a way to pass the Checksum Coverage
value to the receiving application, or at least let the receiving value to the receiving application, or at least let the receiving
application block delivery of packets with coverage values less than application block delivery of packets with coverage values less than
a value provided by the application. a value provided by the application.
It is RECOMMENDED that the default behavior of UDP-Lite be to mimic It is RECOMMENDED that the default behavior of UDP-Lite be set to
UDP by having the Checksum Coverage field match the length of the mimic UDP by having the Checksum Coverage field match the length of
UDP-Lite packet, and verify the entire packet. Applications that wish the UDP-Lite packet and verify the entire packet. Applications that
to define the payload as partially insensitive to bit errors (e.g. wish to define the payload as partially insensitive to bit errors
error tolerant codecs using RTP [RFC-1889]) should do this by an (e.g., error tolerant codecs using RTP [RFC-3550]) should do this by
explicit system call on the sender side. Applications that wish to an explicit system call on the sender side. Applications that wish
receive payloads that were only partially covered by a checksum to receive payloads that were only partially covered by a checksum
should inform the receiving system by an explicit system call. should inform the receiving system by an explicit system call.
The characteristics of the links forming an Internet path may vary The characteristics of the links forming an Internet path may vary
greatly. It is therefore difficult to make assumptions about the greatly. It is therefore difficult to make assumptions about the
level or patterns of errors that may occur in the corruption level or patterns of errors that may occur in the corruption
insensitive part of the UDP-Lite payload. Applications that use UDP- insensitive part of the UDP-Lite payload. Applications that use
Lite should not make any assumptions regarding the correctness of the UDP-Lite should not make any assumptions regarding the correctness of
received data beyond the position indicated by the Checksum Coverage the received data beyond the position indicated by the Checksum
field, and should if necessary introduce their own appropriate Coverage field, and should, if necessary, introduce their own
validity checks. appropriate validity checks.
3.4. IP Interface 3.4. IP Interface
As for UDP, the IP module must provide the pseudo header to the UDP- As for UDP, the IP module must provide the pseudo header to the UDP-
Lite protocol module (known as the UDPLite module). The UDP-Lite Lite protocol module (known as the UDPLite module). The UDP-Lite
pseudo header contains the IP addresses and protocol fields of the IP pseudo header contains the IP addresses and protocol fields of the IP
header, and also the length of the IP payload, which is derived from header, and also the length of the IP payload, which is derived from
the Length field in the IP header. the Length field in the IP header.
The sender IP module MUST NOT pad the IP payload with extra octets, The sender IP module MUST NOT pad the IP payload with extra octets,
since the length of the UDP-Lite payload delivered to the receiver since the length of the UDP-Lite payload delivered to the receiver
depends on the length of the IP payload. depends on the length of the IP payload.
Larzon, et al. [Page 5]
3.5. Jumbograms 3.5. Jumbograms
The Checksum Coverage field is 16 bits and can represent a Checksum The Checksum Coverage field is 16 bits and can represent a Checksum
Coverage value of up to 65535 octets. This allows arbitrary checksum Coverage value of up to 65535 octets. This allows arbitrary checksum
coverage for IP packets, unless they are Jumbograms. For Jumbograms, coverage for IP packets, unless they are Jumbograms. For Jumbograms,
the checksum can cover either the entire payload (when the Checksum the checksum can cover either the entire payload (when the Checksum
Coverage field has the value zero), or else at most the initial 65535 Coverage field has the value zero), or else at most the initial 65535
octets of the UDP-Lite packet. octets of the UDP-Lite packet.
4. Lower Layer Considerations 4. Lower Layer Considerations
Since UDP-Lite can deliver packets with damaged payloads to an Since UDP-Lite can deliver packets with damaged payloads to an
application that wishes to receive them, frames carrying UDP-Lite application that wishes to receive them, frames carrying UDP-Lite
packets need not be discarded by lower layer protocols when there are packets need not be discarded by lower layer protocols when there are
errors only in the insensitive part. For a link that supports partial errors only in the insensitive part. For a link that supports
error detection, the Checksum Coverage field in the UDP-Lite header partial error detection, the Checksum Coverage field in the UDP-Lite
MAY be used as a hint of where errors do not need to be detected. header MAY be used as a hint of where errors do not need to be
Lower layers MUST use a strong error detection mechanism [LINK] to detected. Lower layers MUST use a strong error detection mechanism
detect at least errors that occur in the sensitive part of the [RFC-3819] to detect at least errors that occur in the sensitive part
packet, and discard damaged packets. The sensitive part consists of of the packet, and discard damaged packets. The sensitive part
the octets between the first octet of the IP header and the last consists of the octets between the first octet of the IP header and
octet identified by the Checksum Coverage field. The sensitive part the last octet identified by the Checksum Coverage field. The
would thus be treated in exactly the same way as for a UDP packet. sensitive part would thus be treated in exactly the same way as for a
UDP packet.
Link layers that do not support partial error detection suitable for Link layers that do not support partial error detection suitable for
UDP-Lite, as described above, MUST detect errors in the entire UDP- UDP-Lite, as described above, MUST detect errors in the entire UDP-
Lite packet, and MUST discard damaged packets [LINK]. The whole UDP- Lite packet, and MUST discard damaged packets [RFC-3819]. The whole
Lite packet is thus treated in exactly the same way as a UDP packet. UDP-Lite packet is thus treated in exactly the same way as a UDP
packet.
It should be noted that UDP-Lite would only make a difference to an It should be noted that UDP-Lite would only make a difference to an
application if partial error detection, based on the partial checksum application if partial error detection, based on the partial checksum
feature of UDP-Lite, is implemented also by link layers, as discussed feature of UDP-Lite, is implemented also by link layers, as discussed
above. Partial error detection at the link layer would only make a above. Partial error detection at the link layer would only make a
difference when implemented over error-prone links. difference when implemented over error-prone links.
5. Compatibility with UDP 5. Compatibility with UDP
UDP and UDP-Lite have similar syntax and semantics. Applications UDP and UDP-Lite have similar syntax and semantics. Applications
designed for UDP may therefore use UDP-Lite instead, and will by designed for UDP may therefore use UDP-Lite instead, and will by
default receive the same full packet coverage. The similarities also default receive the same full packet coverage. The similarities also
ease implementation of UDP-Lite, since only minor modifications are ease implementation of UDP-Lite, since only minor modifications are
needed to an existing UDP implementation. needed to an existing UDP implementation.
UDP-Lite has been allocated a separate IP protocol identifier, XXXX UDP-Lite has been allocated a separate IP protocol identifier, 136
(UDPLite) [INSERT IANA NUMBER BEFORE PUBLICATION], that allows a (UDPLite), that allows a receiver to identify whether UDP or UDP-Lite
receiver to identify whether UDP or UDP-Lite is used. A destination is used. A destination end host that is unaware of UDP-Lite will, in
end host that is unaware of UDP-Lite will, in general, return an ICMP general, return an ICMP "Protocol Unreachable" or an ICMPv6 "Payload
Type Unknown" error message (depending on the IP protocol type).
Larzon, et al. [Page 6] This simple method of detecting UDP-Lite unaware systems is the
"Protocol Unreachable" or an ICMPv6 "Payload Type Unknown" error primary benefit of having separate protocol identifiers.
message (depending on the IP protocol type). This simple method of
detecting UDP-Lite unaware systems is the primary benefit of having
separate protocol identifiers.
The remainder of this section provides the rationale for allocating a The remainder of this section provides the rationale for allocating a
separate IP protocol identifier for UDP-Lite, rather than sharing the separate IP protocol identifier for UDP-Lite, rather than sharing the
IP protocol identifier with UDP. IP protocol identifier with UDP.
There are no known interoperability problems between UDP and UDP-Lite There are no known interoperability problems between UDP and UDP-Lite
if they were to share the protocol identifier with UDP. Specifically, if they were to share the protocol identifier with UDP.
there is no case where a potentially problematic packet is delivered Specifically, there is no case where a potentially problematic packet
to an unsuspecting application; a UDP-Lite payload with partial is delivered to an unsuspecting application; a UDP-Lite payload with
checksum coverage cannot be delivered to UDP applications, and UDP partial checksum coverage cannot be delivered to UDP applications,
packets that only partially fill the IP payload cannot be delivered and UDP packets that only partially fill the IP payload cannot be
to applications using UDP-Lite. delivered to applications using UDP-Lite.
However, if the protocol identifier were to have been shared between However, if the protocol identifier were to have been shared between
UDP and UDP-Lite, and a UDP-Lite implementation was to send a UDP- UDP and UDP-Lite, and a UDP-Lite implementation was to send a UDP-
Lite packet using a partial checksum to a UDP implementation, the UDP Lite packet using a partial checksum to a UDP implementation, the UDP
implementation would silently discard the packet, because a implementation would silently discard the packet, because a
mismatching pseudo header would cause the UDP checksum to fail. mismatching pseudo header would cause the UDP checksum to fail.
Neither the sending nor the receiving application would be notified. Neither the sending nor the receiving application would be notified.
Potential solutions to this could have been: Potential solutions to this could have been:
1) explicit application in-band signaling (while not using the 1) explicit application in-band signaling (while not using the
partial checksum coverage option) to enable the sender to learn partial checksum coverage option) to enable the sender to learn
whether the receiver is UDP-Lite enabled or not, or whether the receiver is UDP-Lite enabled or not, or
2) use of out-of-band signaling such as H.323, SIP, or RTCP to 2) use of out-of-band signaling such as H.323, SIP, or RTCP to convey
convey whether the receiver is UDP-Lite enabled. whether the receiver is UDP-Lite enabled.
Since UDP-Lite has been assigned its own IP protocol identifier, Since UDP-Lite has been assigned its own IP protocol identifier,
there is no need to consider this possibility of delivery of a UDP- there is no need to consider this possibility of delivery of a UDP-
Lite packet to an unsuspecting UDP port. Lite packet to an unsuspecting UDP port.
6. Security Considerations 6. Security Considerations
The security impact of UDP-Lite is related to its interaction with The security impact of UDP-Lite is related to its interaction with
authentication and encryption mechanisms. When the partial checksum authentication and encryption mechanisms. When the partial checksum
option of UDP-Lite is enabled, the insensitive portion of a packet option of UDP-Lite is enabled, the insensitive portion of a packet
may change in transit. This is contrary to the idea behind most may change in transit. This is contrary to the idea behind most
authentication mechanisms: authentication succeeds if the packet has authentication mechanisms: authentication succeeds if the packet has
not changed in transit. Unless authentication mechanisms that operate not changed in transit. Unless authentication mechanisms that
only on the sensitive part of packets are developed and used, operate only on the sensitive part of packets are developed and used,
authentication will always fail for UDP-Lite packets where the authentication will always fail for UDP-Lite packets where the
insensitive part has been damaged. insensitive part has been damaged.
The IPSec integrity check (Encapsulation Security Protocol, ESP, or The IPsec integrity check (Encapsulation Security Protocol, ESP
[RFC-2406], or Authentication Header, AH [RFC-2402]) is applied (at
Larzon, et al. [Page 7] least) to the entire IP packet payload. Corruption of any bit within
Authentication Header, AH) is applied (at least) to the entire IP the protected area will then result in the IP receiver discarding the
packet payload. Corruption of any bit within the protected area will UDP-Lite packet.
then result in the IP receiver discarding the UDP-Lite packet.
When IPSEC is used with ESP payload encryption, a link can not When IPsec is used with ESP payload encryption, a link can not
determine the specific transport protocol of a packet being forwarded determine the specific transport protocol of a packet being forwarded
by inspecting the IP packet payload. In this case, the link MUST by inspecting the IP packet payload. In this case, the link MUST
provide a standard integrity check covering the entire IP packet and provide a standard integrity check covering the entire IP packet and
payload. UDP-Lite provides no benefit in this case. payload. UDP-Lite provides no benefit in this case.
Encryption (e.g., at the transport or application levels) Encryption (e.g., at the transport or application levels) may be
may be used. Note that omitting an integrity check can, under used. If a few bits of an encrypted packet are damaged, the
certain circumstances, compromise confidentiality [Bell98]. decryption transform will typically spread errors so that the packet
becomes too damaged to be of use. Many encryption transforms today
If a few bits of an encrypted packet are damaged, the decryption exhibit this behavior. There exist encryption transforms, and stream
transform will typically spread errors so that the packet becomes ciphers, which do not cause error propagation. Note that omitting an
too damaged to be of use. Many encryption transforms today exhibit integrity check can, under certain circumstances, compromise
this behavior. There exist encryption transforms, stream ciphers, confidentiality [Bellovin98]. Proper use of stream ciphers poses its
which do not cause error propagation. Proper use of stream ciphers own challenges [BB01]. In particular, an attacker can cause
can be quite difficult, especially when authentication-checking is predictable changes to the ultimate plaintext, even without being
omitted [BB01]. In particular, an attacker can cause predictable able to decrypt the ciphertext.
changes to the ultimate plaintext, even without being able to
decrypt the ciphertext.
7. IANA Considerations 7. IANA Considerations
A new IP protocol number, XXXX [INSERT NUMBER BEFORE PUBLICATION], A new IP protocol number, 136 has been assigned for UDP-Lite. The
has been assigned for UDP-Lite. The name associated with this name associated with this protocol number is "UDPLite". This ensures
protocol number is "UDPLite". This ensures compatibility across a compatibility across a wide range of platforms, since on some
wide range of platforms, since on some platforms the "-" character platforms the "-" character may not form part of a protocol entity
may not form part of a protocol entity name. name.
[NOTE, REMOVE BEFORE PUBLICATION]
IANA assignment instruction:
The IANA must reserve an IP protocol number for UDP-Lite.
IANA - Please NOTE the name of the registry entry MUST be
"UDPLite", as detailed above.
[END OF NOTE]
Larzon, et al. [Page 8]
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC-768] Postel, J., "User Datagram Protocol", RFC 768 (STD6), [RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC-791] Postel, J., "Internet Protocol", RFC 791 (STD5), [RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC-793] Postel, J., "Transmission Control Protocol", RFC 793 [RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC
(STD7), September 1981. 793, September 1981.
[RFC-1071] Braden, R., Borman, D., and C. Partridge, "Computing the [RFC-1071] Braden, R., Borman, D. and C. Partridge, "Computing the
Internet Checksum", RFC 1071, September 1988. Internet Checksum", RFC 1071, September 1988.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119 (BCP15), March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
8.2. Informative References 8.2. Informative References
[Bell98] Bellovin, S.M., "Cryptography and the Internet", [Bellovin98] Bellovin, S.M., "Cryptography and the Internet", in
Proceedings of CRYPTO 98, August, 1988. Proceedings of CRYPTO '98, August 1988.
[BB01] Bellovin, S.M., and M. Blaze, "Cryptographic Modes of [BB01] Bellovin, S. and M. Blaze, "Cryptographic Modes of
Operation for the Internet", 2nd NIST Workshop on Modes Operation for the Internet", Second NIST Workshop on
of Operation, August 2001. Modes of Operation, August 2001.
[3GPP] "Technical Specification Group Services and System [3GPP] "Technical Specification Group Services and System
Aspects; Quality of Service (QoS) concept and Aspects; Quality of Service (QoS) concept and
architecture", TS 23.107 V5.9.0, Technical Specification architecture", TS 23.107 V5.9.0, Technical Specification
3rd Generation Partnership Project, June 2003. 3rd Generation Partnership Project, June 2003.
[H.264] Hannuksela, M.M., T. Stockhammer, M. Westerlund. And [H.264] Hannuksela, M.M., Stockhammer, T., Westerlund, M. and D.
D. Singer, "RTP payload Format for H.264 Video", Internet Singer, "RTP payload Format for H.264 Video", Internet
Draft, Work in Progress, March 2003. Draft, Work in Progress, March 2003.
[ILBRC] S.V. Andersen, et. al., "Internet Low Bit Rate Codec", [ILBRC] S.V. Andersen, et. al., "Internet Low Bit Rate Codec",
draft-ietf-avt-ilbc-codec-01.txt, Internet Draft, Work in Work in Progress, March 2003.
Progress, March 2003.
[ISO-14496] ISO/IEC International Standard 1446 (MPEG-4), [ISO-14496] ISO/IEC International Standard 1446 (MPEG-4),
"Information Technology Coding of Audio-Visual "Information Technology Coding of Audio-Visual Objects",
Objects", January 2000. January 2000.
[ITU-H.263] "Video Coding for Low Bit Rate Communication," ITU-T [ITU-H.263] "Video Coding for Low Bit Rate Communication," ITU-T
Recommendation H.263, January 1998. Recommendation H.263, January 1998.
Larzon, et al. [Page 9] [ITU-H.264] "Draft ITU-T Recommendation and Final Draft
[ITU-H.264] "Draft ITU-T Recommendation and Final Draft International International Standard of Joint Video Specification",
Standard of Joint Video Specification",
ITU-T Recommendation H.264, May 2003. ITU-T Recommendation H.264, May 2003.
[LINK] Phil Karn, Editor, "Advice for Internet Subnetwork [RFC-3819] Karn, Ed., P., Bormann, C., Fairhurst, G., Grossman, D.,
Designers", Work in Progress, IETF. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and
L. Wood, "Advice for Internet Subnetwork Designers", BCP
[RFC-1889] Schulzrinne, H., Casner, S., Frederick, R., and 89, RFC 3819, July 2004.
V. Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[RFC-2026] Bradner, S., "The Internet Standards Process", RFC 2026, [RFC-3550] Schulzrinne, H., Casner, S., Frederick, R. and V.
October 1996. Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, July 2003.
[RFC-2402] Kent, S., and R. Atkinson, "IP Authentication Header", [RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998. RFC 2402, November 1998.
[RFC-2406] Kent, S., and R. Atkinson, "IP Encapsulating Security [RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 206, November 1998. Payload (ESP)", RFC 2406, November 1998.
[RFC-3267] Sjoberg, J., M. Westerlund, A. Lakeaniemi, and Q. Xie, [RFC-3267] Sjoberg, J., Westerlund, M., Lakeaniemi, A. and Q. Xie,
"Real-Time Transport Protocol (RTP) Payload Format and "Real-Time Transport Protocol (RTP) Payload Format and
File Storage Format for the Adaptiove Multi-Rate (AMR) File Storage Format for the Adaptive Multi-Rate (AMR)
and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs",
RFC 3267, June 2002. RFC 3267, June 2002.
[LDP99] Larzon, L-A., Degermark, M., and S. Pink, "UDP Lite for [LDP99] Larzon, L-A., Degermark, M. and S. Pink, "UDP Lite for
Real-Time Multimedia Applications", Proceedings of the Real-Time Multimedia Applications", Proceedings of the
IEEE International Conference of Communications (ICC), IEEE International Conference of Communications (ICC),
1999. 1999.
9. Acknowledgements 9. Acknowledgements
Thanks to Ghyslain Pelletier for significant technical and editorial Thanks to Ghyslain Pelletier for significant technical and editorial
comments. Thanks also to Steven Bellovin, Elisabetta Carrara, and comments. Thanks also to Steven Bellovin, Elisabetta Carrara, and
Mats Naslund for reviewing the security considerations chapter, and Mats Naslund for reviewing the security considerations chapter, and
to Peter Eriksson for a language review and thereby improving the to Peter Eriksson for a language review, thereby improving the
clarity of this document. clarity of this document.
Larzon, et al. [Page 10]
10. Authors' Addresses 10. Authors' Addresses
Lars-Ake Larzon Lars-Ake Larzon
Department of CS & EE Department of CS & EE
Lulea University of Technology Lulea University of Technology
S-971 87 Lulea, Sweden S-971 87 Lulea, Sweden
Email: lln@cdt.luth.se
EMail: lln@csee.ltu.se
Mikael Degermark Mikael Degermark
Department of Computer Science Department of Computer Science
The University of Arizona The University of Arizona
P.O. Box 210077 P.O. Box 210077
Tucson, AZ 85721-0077, USA Tucson, AZ 85721-0077, USA
Email: micke@cs.arizona.edu
EMail: micke@cs.arizona.edu
Stephen Pink Stephen Pink
The University of Arizona The University of Arizona
P.O. Box 210077 P.O. Box 210077
Tucson, AZ 85721-0077, USA Tucson, AZ 85721-0077, USA
Email: steve@cs.arizona.edu
EMail: steve@cs.arizona.edu
Lars-Erik Jonsson Lars-Erik Jonsson
Ericsson AB Ericsson AB
Box 920 Box 920
S-971 28 Lulea, Sweden S-971 28 Lulea, Sweden
Email: lars-erik.jonsson@ericsson.com
EMail: lars-erik.jonsson@ericsson.com
Godred Fairhurst Godred Fairhurst
Department of Engineering Department of Engineering
University of Aberdeen University of Aberdeen
Aberdeen, AB24 3UE, UK Aberdeen, AB24 3UE, UK
Email: gorry@erg.abdn.ac.uk
Larzon, et al. [Page 11]
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires December, 2003.
Larzon, et al. [Page 12]
[NOTE, REMOVE BEFORE PUBLICATION]
Document History 02j - This section is intended to assist the AD in
review of the document. It must be deleted by the RFC Editor.
(1) IANA Assignemnet Name chnage UDP-Lite renamed UDPLite to
increase the portability of the code to operating systems that
use the "-" character as a part of the mapping function (i.e.
not allowed in the protocol ID).
Having done this, I now worry a little that this may now divorce
the RFC from the previous published work --- should we also
refer people to UDP-Lite?
(2) Text added to 2nd para, section 3.1 to say pseudo header always
present.
(3) Text added to 2nd para, section 3.1 to say initial checksum value
is zero.
(4) Section 5, added IPv6 text: A destination end host that is
unaware of UDP-Lite will, in general, return an ICMP "Protocol
Unreachable" or an ICMPv6 "Payload Type Unknown" error message
(depending on the IP protocol type).
(5) BSD Code behaviour? This is a protocol problem with a BSD EMail: gorry@erg.abdn.ac.uk
implementation, not a spec fault.
(6) Examples added of applications 11. Full Copyright Statement
(7) Examples of systems that would use it Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
(8) Security issues (text requested by IESG). This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
(9) Minor NiTs with written English corrected. Intellectual Property
(10) Introduction starts rather strangely - can we fix this? The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
(11) Security AD Text Revised, and now OK. Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
(12) Revised security note: The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
When IPSEC is used with ESP payload encryption, there is no Acknowledgement
visibility of the transport header, and therefore a link can not
determine which transport layer protocol is used, and would not be
able to determine the value of the Checksum Coverage field. UDP-Lite
provides no benefit in this case, and the link MUST provide a
standard integrity check.
[END OF NOTE] Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/