INTERNET-DRAFT                                           Lars-Ake
Network Working Group                                        L-A. Larzon
INTERNET-DRAFT                            Lulea University of Technology, Sweden
January 24, 2002                                        Mikael Degermark Technology
Expires: July 24, 2002                                     Stephen June 2003                                          M. Degermark
                                                                 S. Pink
                                               The University of Arizona, USA Arizona
                                                   L-E. Jonsson (editor)
                                                   G. Fairhurst (editor)
                                                  University of Aberdeen
                                                        December 5, 2002

                          The UDP Lite UDP-Lite Protocol

Status of this Memo memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC-2026].

   This document is an Internet-Draft. RFC2026.

   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 "work in progress.'' progress".

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   Please direct comments to the TSV WG mailing list:


   This document describes the UDP Lite UDP-Lite protocol, which is similar to
   UDP [RFC-768], but can also serve applications which that in lossy error-prone
   network environments prefer to have partially damaged payloads
   delivered rather than discarded. If this feature is not used, UDP UDP-
   Lite is semantically identical to classic UDP.


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC-2119].

Table of Contents

   1.  Introduction...................................................2
   2.  Terminology....................................................3
   3.  Protocol Description...........................................3
      3.1.  Fields....................................................3
      3.2.  Pseudo Header.............................................4
      3.3.  Application Interface.....................................4
      3.4.  IP Interface..............................................5
      3.5.  Jumbograms................................................5
   4.  Lower Layer Considerations.....................................5
   5.  Compatibility with UDP.........................................6
   6.  Security Considerations........................................7
   7.  IANA Considerations............................................7
   8.  References.....................................................8
      8.1.  Normative References......................................8
      8.2.  Informative References....................................8
   9.  Acknowledgements...............................................8
   10.  Authors' Addresses............................................9

1.  Introduction

   Why another transport protocol?

   First, there is a class of applications which that prefer to have damaged
   data delivered rather than discarded by the network. A number of
   codecs for voice and video fall into this class. These codecs are
   designed to cope better with errors in the payload than with loss of
   entire packets.

   Second, there are a number of link technologies where data can be
   partially damaged. Several radio technologies exhibit this behavior
   when operating at a point where cost and delay is are sufficiently low.

   Third, intermediate layers should not prevent such error-tolerant
   applications to run well over in the presence of such links. The
   intermediate layers are IP and the transport layer. IP is not a
   problem in this regard since the IP header has no checksum which that
   covers the IP payload. The generally available transport protocol
   best suited for these applications is UDP, since it has no overhead
   for retransmission of erroneous packets, in-order delivery delivery, or error
   correction.  However, In IPv4 [RFC-791], the UDP checksum either covers either the
   entire datagram packet or nothing at all.
   Moreover, in the next version of IP, In IPv6 [RFC-2460], the UDP checksum
   is mandatory and must not be disabled. The IPv6 header does not have
   a header checksum and it was deemed necessary to always protect the
   IP addressing information by making the UDP checksum mandatory.

   A transport protocol is needed that conforms with to the properties of
   link layers and applications described above. above [UDP-LITE]. The error-detection error-
   detection mechanism of the transport layer must be able to protect
   vital information such as headers, but also to optionally ignore
   errors best dealt with by the application. What should be verified by
   the checksum is best specified by the sending application.

   UDP Lite

   UDP-Lite provides a checksum with optionally an optional partial coverage. When
   using this option, a datagram packet 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
   datagram packet
   to be discarded. discarded by the transport layer at the receiving end host.
   When the checksum covers the entire
   datagram, packet, which SHOULD should be the
   default, UDP Lite UDP-Lite is semantically identical to UDP.

   Compared to UDP (hereafter referred to as "classic UDP"), UDP, the UDP-Lite partial checksum provides extra
   flexibility for applications with that want to define the payload as
   partially insensitive data. to bit errors.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC-2119].

3.  Protocol description Description

   The UDP Lite UDP-Lite header is shown in figure 1. Its format differs from
   UDP in that the Length field has been replaced with a Checksum
   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 [rfc-793].

                    0              15 16             31
                   |     Source      |   Destination   |
                   |      Port       |      Port       |
                   |    Checksum     |                 |
                   |    Coverage     |    Checksum     |
                   |                                   |
                   :              Payload              :
                   |           data bytes ...                                   |
                   +---------------- ...---------------+

                      Figure 1: New UDP UDP-Lite Header Format

3.1.  Fields

   The fields ``Source Port'' Source Port and ``Destination port'' Destination Port are defined as in the UDP
   specification [RFC-768]. UDP-Lite uses the same set of port number
   values as those assigned by the IANA for use by UDP.

   Checksum Coverage is the number of bytes, octets, counting from the first
   octet of the new UDP UDP-Lite header, that are covered by the checksum. The UDP
   UDP-Lite header MUST always be included in covered by the checksum. Despite this
   requirement, the Checksum Coverage is expressed in bytes octets from the
   beginning of the UDP Lite header UDP-Lite header, in order to preserve compatibility
   with classic the same way as for UDP. A
   Checksum Coverage of zero indicates that the entire new UDP UDP-Lite packet
   is included in covered by the checksum. This means that the value of the Checksum
   Coverage field MUST be either zero 0 or at least eight. 8. A UDP-Lite packet with
   a Checksum Coverage value of 1 to 7 MUST be discarded by the
   receiver. UDP-Lite packets with a Checksum Coverage greater than the
   IP length MUST also be discarded.

   Checksum is the 16-bit one's complement of the one's complement sum
   of a pseudo-header of information from the IP header, the number of
   octets specified by the Checksum Coverage (starting at the first byte
   octet in the new UDP UDP-Lite header), virtually padded with a zero bytes octet at
   the end (if necessary) to make a multiple of two bytes. octets [RFC-1071].
   If the computed checksum is zero, 0, it is transmitted as all ones (the
   equivalent in one's complement arithmetic).

   The transmitted checksum MUST NOT be all zeroes.

Pseudo header

   Similar If an application
   using UDP-Lite wishes to classic UDP, UDP Lite uses a conceptually prefixed pseudo have no protection of the packet payload, it
   should use a Checksum Coverage value of 8. This differs from the use
   of UDP over IPv4, in that the minimal UDP-Lite checksum always covers
   the UDP-Lite protocol header, which includes the Checksum Coverage

3.2.  Pseudo Header

   UDP and UDP-Lite use the same conceptually prefixed pseudo header
   from the IP layer for checksumming purposes.  The format of the checksum. This pseudo header is the same as different
   for classic UDP, IPv4 and differs for
   different versions of IP. IPv6. The pseudo header of UDP Lite UDP-Lite is different from
   the pseudo header of classic UDP in one way: The value of the
   length Length field of
   the pseudo header is not taken from the UDP Lite UDP-Lite header, but rather
   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 Length
   field of the pseudo header includes the UDP
   Lite UDP-Lite header and all
   subsequent bytes octets in the IP payload.


3.3.  Application Interface

   A user

   An application interface should allow the same operations as for classic
   UDP. In addition to this, it SHOULD should provide a way for the sending
   application to pass the checksum coverage value to the UDP Lite UDP-Lite
   module. There SHOULD should also be a way to pass the checksum coverage
   value to the receiving application, or at least let the receiving
   application block delivery of packets with coverage values less than
   a value provided by the application.


   It is RECOMMENDED that the default behaviour behavior of UDP Lite is UDP-Lite be to mimic
   UDP by having the coverage Checksum Coverage field match the length of the UDP
   Lite datagram
   UDP-Lite packet, and verifying verify the entire packet. Applications that want
   to define the payload as partially insensitive to bit errors SHOULD (e.g.
   error tolerant codecs using RTP [RFC-1889]) should do that by a separate an
   explicit system call on the sender side. Applications that wish to
   receive payloads which that were only partially covered by a checksum SHOULD
   should inform the receiving system by a separate an explicit system call.

   The characteristics of the links forming an Internet path may vary
   greatly. It is therefore difficult to make assumptions about the
   level or patterns of errors that may occur in the insensitive part of
   the UDP-Lite payload. Applications that use UDP-Lite should not make
   any assumptions regarding the correctness of the received data beyond
   the indicated checksum coverage, and should if necessary introduce
   their own appropriate validity checks.

3.4.  IP Interface

   As for classic UDP, the UDP Lite IP module must pass provide the pseudo header to the UDP UDP-
   Lite module. The UDP Lite UDP-Lite pseudo header contains the IP addresses and
   protocol fields of the IP header, and also the length of the IP payload
   payload, which is derived from the length Length field of the IP header.

   The sender IP module MUST NOT pad the IP payload with extra bytes octets
   since the length of the UDP Lite UDP-Lite payload delivered to the receiver
   depends on the length of the IP payload.

3.5.  Jumbograms

   The Checksum Coverage field is 16 bits and can represent a checksum
   coverage of up to 65535 octets. This allows arbitrary checksum
   coverage for IP packets, unless they are Jumbograms. For Jumbograms,
   the checksum can cover either the entire payload (when the Checksum
   Coverage field has the value zero), or else at most the initial 65535
   octets of the UDP-Lite packet.

4.  Lower layer considerations Layer Considerations

   Since UDP Lite UDP-Lite can deliver packets with damaged payloads to an
   application that wants them, frames carrying UDP Lite UDP-Lite packets need
   not be discarded by lower layers when there are errors only in the
   insensitive part. For a link layer that supports partial error detection,
   the Checksum Coverage field in the UDP Lite UDP-Lite header MAY be used as a
   hint of where errors should do not need to be detected.  Link Lower layers that do not
   support partial checksums SHOULD MUST
   use a strong error detection mechanism to detect errors in the entire frame.
   In general, lower layers SHOULD detect errors at least errors that
   occur in the sensitive part of the frame using strong error detection mechanisms,
   but need not do so for packet, and discard damaged
   packets. The sensitive part consists of the insensitive part.

   Note that it is usually only over links where errors are frequent
   that octets between the partial checksum feature first
   octet of UDP Lite can make a difference
   to the application. On links where errors are infrequent it is
   RECOMMENDED IP header and the last octet identified by the Checksum
   Coverage field. At least the sensitive part would thus be treated in
   exactly the same way as UDP packets.

   Link layers that lower layeers do not support partial error detection suitable for
   UDP-Lite, as described above, MUST detect errors in the entire packet.

Jumbograms UDP-
   Lite packet, and discard damaged packets. The Checksum Coverage field whole UDP-Lite packet
   is 16 bits and can represent checksum
   coverage up to 65535 octets. This allows arbitrary checksum coverage
   for IP datagrams, unless they are Jumbograms. For Jumbograms, the
   Checksum can cover either the entire payload (when thus treated in exactly the Checksum
   Coverage field has same way as a UDP packet.

   It should be noted that UDP-Lite would only make a difference to the value zero), or else at most
   application if partial error detection, based on the initial 65535
   octets partial checksum
   feature of UDP-Lite, is implemented also by link layers, as discussed
   above. Obviously, partial error detection at the link layer would
   only make a difference when implemented over error-prone links.

5.  Compatibility with UDP Lite datagram.

Backwards compatibility

   The syntactic and semantic similarity between

   UDP Lite and classic UDP-Lite have similar syntax and semantics. Applications
   designed for UDP suggests that they might share may therefore use UDP-Lite instead, and will by
   default receive the same full packet coverage. The similarities also
   ease implementation of UDP-Lite, since only minor modifications are
   needed to an existing UDP implementation.

   UDP-Lite has been allocated a separate IP protocol identifier. identifier, XXXX
   [INSERT IANA NUMBER BEFORE PUBLICATION], that allows a receiver to
   identify whether UDP or UDP-Lite is used. A system unaware of UDP-
   Lite will in general return an ICMP Protocol Unreachable error
   message to the sender. This section explores some consequences simple method of doing so. detecting UDP-Lite
   unaware systems is the primary benefit of having separate protocol

   The remainder of this section provides the rationale for allocating a
   separate IP protocol identifier for UDP-Lite, rather than sharing the
   IP protocol identifier with UDP.

   There are no known interoperability problems between classic UDP and
   UDP Lite UDP-Lite
   if they were to share the protocol identifier of classic with UDP. To be more precise: Specifically,
   there is no case where a potentially problematic packet is delivered
   to an unsuspecting application; a UDP
   Lite UDP-Lite payload with partial
   checksum coverage cannot be delivered to UDP applications, and UDP datagrams which
   packets that only partially fills fill the IP payload cannot be delivered
   to UDP Lite applications.

   If applications using UDP-Lite.

   However, if the protocol identifier was were to be shared between UDP and UDP Lite
   UDP-Lite, and a
   UDP Lite UDP-Lite implementation sends UDP Lite packets with was to send a UDP-Lite packet
   using a partial checksums checksum to a classic UDP implementation, the classic UDP
   implementation would silently discard them the packet, because a
   mismatching pseudo header would cause the UDP checksum to mismatch. fail.
   Neither the sending nor the receiving application would be notified.  The obvious
   Potential solutions to this include could have been:

     1) explicit application in-band signaling (not (while not using the
        partial checksum coverage option) to enable the sender to learn
        whether the receiver is UDP Lite UDP-Lite enabled or not, or
     2) use of out-of-band signaling such as H.323, SIP, or RTCP to convey
   whether the receiver is UDP Lite enabled.

   If UDP Lite has its own separate protocol identifier, on the other
   hand, a system unaware of UDP Lite would return ICMP Protocol
   Unreachable error messages to the sender. This simple method of
   detecting UDP Lite unaware systems is the primary benefit of having
   separate protocol identifiers.

   Therefore, this draft proposes to allocate a new protocol identifier
   for UDP Lite.

Security considerations

   The security impact of UDP Lite is twofold. First, applications who
   do not expect damaged payloads are bound to malfunction if damaged
   payloads are delivered to them. To avoid this, we RECOMMEND that the
   sending and the receiving side application both explicitly enable the
   partial checksum option.  Packets with partial checksums SHOULD NOT
   be delivered of out-of-band signaling such as H.323, SIP, or RTCP to applications that have not enabled
        convey whether the partial
   checksum option.

   Second, receiver is UDP-Lite enabled.

   Anyway, since UDP-Lite has now been assigned its own protocol
   identifier, there is no need to consider the question possibility of how delivery
   of a UDP-Lite packet to an unsuspecting UDP Lite interacts port.

6.  Security Considerations

   The security impact of UDP-Lite is related to its interaction with
   authentication and encryption mechanisms. When the partial checksum
   option of UDP Lite UDP-Lite is enabled, it is fine with the application if the insensitive part portion of a packet changes
   may change in transit. This is contrary to the idea behind most
   authentication mechanisms; mechanisms: authentication succeeds when if the packet has
   not changed in transit. Unless authentication mechanisms that operate
   only on the sensitive part of packets are developed, developed and used,
   authentication will always fail on UDP Lite UDP-Lite packets where the
   insensitive part has been damaged.

   The IPSec integrity check (Encapsulation Security Protocol, ESP, or
   Authentication Header, AH) is applied (at least) to the entire IP
   packet payload. Corruption of any bit within the protected area will
   then result in the discarding of the UDP-Lite packet by the IP

   Encryption is also an issue when using UDP Lite. UDP-Lite. If a few bits of an
   encrypted packet are damaged, the decryption transform will typically
   spread this error errors so that the packet becomes too damaged to be of use. Most
   Many strong encryption transforms today exhibit this behaviour, behavior, for good reason.  It might be possible to develop
   reasons obvious from a security point of view. There exist encryption
   transforms, stream ciphers, which would do not spread damage errors in this way
   when the damage occurs in the insensitive part of the packet.  A class of such
   transforms would be transforms where the sensitive part is encrypted
   using a strong transform as usual, and the insensitive part is
   encrypted by XORing it with a cryptographic hash computed over the
   cleartext of the sensitive part.  However, it is clear that with most
   transforms in use today, encryption eliminates the benefits that the
   partial checksum coverage option of the UDP Lite might bring.

7.  IANA considerations

   We request that a Considerations

   A new ip IP protocol identifier is allocated number, XXXX [INSERT NUMBER BEFORE PUBLICATION],
   has been assigned for UDP


   We have presented the UDP Lite protocol. UDP-Lite.


       IANA assignment instruction:
       - The main motivation IANA must reserve an IP protocol number for this
   new variant of UDP-Lite.


8.  References

8.1.  Normative References

   [RFC-768]   Postel, J., "User Datagram Protocol", RFC 768 (STD6),
               August 1980.

   [RFC-791]   Postel, J., "Internet Protocol", RFC 791 (STD5),
               September 1981.

   [RFC-793]   Postel, J., "Transmission Control Protocol", RFC 793
               (STD7), September 1981.

   [RFC-1071]  Braden, R., Borman, D., and C. Partridge, "Computing the classic UDP transport protocol is decreased packet
   error rates
               Internet Checksum", RFC 1071, September 1988.

   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119 (BCP15), March 1997.

   [RFC-2460]  Deering, S., and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.

8.2.  Informative References

   [RFC-1889]  Schulzrinne, H., Casner, S., Frederick, R., and
               V. Jacobson, "RTP: A Transport Protocol for damage-tolerant applications today using classic UDP
   in harsh network environments.  UDP Lite provides optionally partial
   checksum coverage which increases the flexibility of classic UDP by
   making it possible Real-Time
               Applications", RFC 1889, January 1996.

   [RFC-2026]  Bradner, S., "The Internet Standards Process", RFC 2026,
               October 1996.

   [RFC-2402]  Kent, S., and R. Atkinson, "IP Authentication Header",
               RFC 2402, November 1998.

   [RFC-2406]  Kent, S., and R. Atkinson, "IP Encapsulating Security
               Payload (ESP)", RFC 206, November 1998.

   [UDP-LITE]  Larzon, L-A., Degermark, M., and S. Pink, "UDP Lite for
               Real-Time Multimedia Applications", Proceedings of the
               IEEE International Conference of Communications (ICC),

9.  Acknowledgements

   Thanks to Ghyslain Pelletier for significant technical and editorial
   comments. Thanks also to define a packet as partially insensitive Elisabetta Carrara and Mats Naslund for
   reviewing the security considerations chapter, and to bit
   errors on Peter Eriksson
   for doing a per-packet basis. If no part language review and thereby improving the clarity of a packet is defined as
   insensitive, UDP Lite is semantically identical to classic UDP.

Contact info this

10.  Authors' Addresses

   Lars-Ake Larzon
   Department of CS & EE
   Lulea University of Technology
   S-971 87 Lulea, Sweden

   Mikael Degermark
   Department of Computer Science
   The University of Arizona
   P.O. Box 210077
   Tucson, AZ 85721-0077 85721-0077, USA

   Stephen Pink
   The University of Arizona
   P.O. Box 210077
   Tucson, AZ 85721-0077 85721-0077, USA

Normative References

   [RFC-768]   Postel, J., "User Datagram Protocol," RFC 768,
               Information Sciences Institute, August 1980.

   [RFC-793]   Postel, J., "Transmission Control Protocol," RFC 793,
               Information Sciences Institute, September 1981.

   [RFC-2460]  Deering, S., Hinden, R., "Internet Protocol, Version 6
               (IPv6) Specification," RFC 2460, IETF, December 1998.

Informative References

   [RFC-2026]  Bradner, S., "The

   Lars-Erik Jonsson
   Ericsson AB
   Box 920
   S-971 28 Lulea, Sweden

   Godred Fairhurst
   Department of Engineering
   University of Aberdeen
   Aberdeen, AB24 3UE, UK

Full Copyright Statement

   Copyright (C) The Internet Standards Process," RFC 2026,
               Harvard University, October 1996.

   [RFC-2119]  Bradner, S., "Key words 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 use the purpose of
   developing Internet standards in RFCs which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to Indicate
               Requirement Levels," Harvard University, March 1997. translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This draft document and the information contained herein is provided on an

This Internet-Draft expires July 24, 2002 June 5, 2003.