draft-ietf-tsvwg-udp-lite-00.txt		draft-ietf-tsvwg-udp-lite-01.txt
	INTERNET-DRAFT Lars-Ake Larzon		Network Working Group L-A. Larzon
	TSV WG Lulea University of Technology, Sweden		INTERNET-DRAFT Lulea University of Technology
	January 24, 2002 Mikael Degermark		Expires: June 2003 M. Degermark
	Expires: July 24, 2002 Stephen Pink		S. Pink
	The University of Arizona, USA		The University of Arizona
			L-E. Jonsson (editor)
			Ericsson
			G. Fairhurst (editor)
			University of Aberdeen
			December 5, 2002
	The UDP Lite Protocol		The UDP-Lite Protocol
	<draft-ietf-tsvwg-udp-lite-00.txt>		<draft-ietf-tsvwg-udp-lite-01.txt>
	Status of this Memo		Status of this memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of [RFC-2026].		all provisions of Section 10 of RFC2026.
	This document is an Internet-Draft. Internet-Drafts are working		Internet-Drafts are working documents of the Internet Engineering
	documents of the Internet Engineering Task Force (IETF), its areas,		Task Force (IETF), its areas, and its working groups. Note that other
	and its working groups. Note that other groups may also distribute		groups may also distribute working documents as Internet-Drafts.
	working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as ``work in progress.''		material or cite them other than as "work in progress".
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/lid-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html
	Please direct comments to the TSV WG mailing list: tsvwg@ietf.org		Please direct comments to the TSV WG mailing list: tsvwg@ietf.org
	Abstract		Abstract
	This document describes the UDP Lite protocol, which is similar to		This document describes the UDP-Lite protocol, which is similar to
	classic UDP [RFC-768], but can also serve applications which in lossy		UDP [RFC-768], but can also serve applications that in error-prone
	network environments prefer to have partially damaged payloads		network environments prefer to have partially damaged payloads
	delivered rather than discarded. If this feature is not used, UDP		delivered rather than discarded. If this feature is not used, UDP-
	Lite is semantically identical to classic UDP.		Lite is semantically identical to UDP.
	Conventions		Table of Contents
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		1. Introduction...................................................2
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		2. Terminology....................................................3
	document are to be interpreted as described in [RFC-2119].		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
	Introduction		1. Introduction
	Why another transport protocol?		Why another transport protocol?
	First, there is a class of applications which prefer to have damaged		First, there is a class of applications that prefer to have damaged
	data delivered rather than discarded by the network. A number of		data delivered rather than discarded by the network. A number of
	codecs for voice and video fall into this class. These codecs are		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		designed to cope better with errors in the payload than with loss of
	entire packets.		entire packets.
	Second, there are a number of link technologies where data can be		Second, there are a number of link technologies where data can be
	partially damaged. Several radio technologies exhibit this behavior		partially damaged. Several radio technologies exhibit this behavior
	when operating at a point where cost and delay is sufficiently low.		when operating at a point where cost and delay are sufficiently low.
	Third, intermediate layers should not prevent such applications to		Third, intermediate layers should not prevent error-tolerant
	run well over such links. The intermediate layers are IP and the		applications to run well in the presence of such links. The
	transport layer. IP is not a problem in this regard since the IP		intermediate layers are IP and the transport layer. IP is not a
	header has no checksum which covers the IP payload. The generally		problem in this regard since the IP header has no checksum that
	available transport protocol best suited for these applications is		covers the IP payload. The generally available transport protocol
	UDP, since it has no overhead for retransmission of erroneous		best suited for these applications is UDP, since it has no overhead
	packets, in-order delivery or error correction. However, the UDP		for retransmission of erroneous packets, in-order delivery, or error
	checksum either covers the entire datagram or nothing at all.		correction. In IPv4 [RFC-791], the UDP checksum covers either the
	Moreover, in the next version of IP, IPv6 [RFC-2460], the UDP		entire packet or nothing at all. In IPv6 [RFC-2460], the UDP checksum
	checksum is mandatory and must not be disabled. The IPv6 header does		is mandatory and must not be disabled. The IPv6 header does not have
	not have a header checksum and it was deemed necessary to always		a header checksum and it was deemed necessary to always protect the
	protect the IP addressing information by making the UDP checksum		IP addressing information by making the UDP checksum mandatory.
	mandatory.
	A transport protocol is needed that conforms with the properties of		A transport protocol is needed that conforms to the properties of
	link layers and applications described above. The error-detection		link layers and applications described above [UDP-LITE]. The error-
	mechanism of the transport layer must be able to protect vital		detection mechanism of the transport layer must be able to protect
	information such as headers, but also to optionally ignore errors		vital information such as headers, but also to optionally ignore
	best dealt with by the application. What should be verified by the		errors best dealt with by the application. What should be verified by
	checksum is best specified by the sending application.		the checksum is best specified by the sending application.
	UDP Lite provides a checksum with optionally partial coverage. When		UDP-Lite provides a checksum with an optional partial coverage. When
	using this option, a datagram is divided into a sensitive part		using this option, a packet is divided into a sensitive part (covered
	(covered by checksum) and an insensitive part (not covered by		by the checksum) and an insensitive part (not covered by the
	checksum). Errors in the insensitive part will not cause the		checksum). Errors in the insensitive part will not cause the packet
	datagram to be discarded. When the checksum covers the entire		to be discarded by the transport layer at the receiving end host.
	datagram, which SHOULD be the default, UDP Lite is semantically		When the checksum covers the entire packet, which should be the
	identical to UDP.		default, UDP-Lite is semantically identical to UDP.
	Compared to UDP (hereafter referred to as "classic UDP"), the partial		Compared to UDP, the UDP-Lite partial checksum provides extra
	checksum provides extra flexibility for applications with partially		flexibility for applications that want to define the payload as
	insensitive data.		partially insensitive to bit errors.
	Protocol description		2. Terminology
	The UDP Lite header is shown in figure 1. Its format differs from		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	classic UDP in that the Length field has been replaced with a		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	Checksum Coverage field. This can be done since information about UDP		document are to be interpreted as described in [RFC-2119].
	packet length can be provided by the IP module in the same manner as
	for TCP [rfc-793].		3. Protocol Description
			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
			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		0 15 16 31
	+--------+--------+--------+--------+		+--------+--------+--------+--------+
	| Source | Destination |		| Source | Destination |
	| Port | Port |		| Port | Port |
	+--------+--------+--------+--------+		+--------+--------+--------+--------+
	| Checksum | |		| Checksum | |
	| Coverage | Checksum |		| Coverage | Checksum |
	+--------+--------+--------+--------+		+--------+--------+--------+--------+
	| |		| |
	| data bytes ... |		: Payload :
	+---------------- ...---------------+		| |
			+-----------------------------------+
	Figure 1: New UDP Header Format		Figure 1: UDP-Lite Header Format
	Fields		3.1. Fields
	The fields ``Source Port'' and ``Destination port'' are defined as in		The fields Source Port and Destination Port are defined as in the UDP
	the UDP specification [RFC-768].		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, counting from the first		Checksum Coverage is the number of octets, counting from the first
	byte of the new UDP header, that are covered by the checksum. The UDP		octet of the UDP-Lite header, that are covered by the checksum. The
	Lite header MUST always be included in the checksum. Despite this		UDP-Lite header MUST always be covered by the checksum. Despite this
	requirement, the Checksum Coverage is expressed in bytes from the		requirement, the Checksum Coverage is expressed in octets from the
	beginning of the UDP Lite header in order to preserve compatibility		beginning of the UDP-Lite header, in the same way as for UDP. A
	with classic UDP. A Checksum Coverage of zero indicates that the		Checksum Coverage of zero indicates that the entire UDP-Lite packet
	entire new UDP packet is included in the checksum. This means that		is covered by the checksum. This means that the value of the Checksum
	the value of the Checksum Coverage field MUST be either zero or at		Coverage field MUST be either 0 or at least 8. A UDP-Lite packet with
	least eight.		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		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		of a pseudo-header of information from the IP header, the number of
	bytes specified by the Checksum Coverage (starting at the first byte		octets specified by the Checksum Coverage (starting at the first
	in the new UDP header), virtually padded with zero bytes at the end		octet in the UDP-Lite header), virtually padded with a zero octet at
	(if necessary) to make a multiple of two bytes. If the computed		the end (if necessary) to make a multiple of two octets [RFC-1071].
	checksum is zero, it is transmitted as all ones (the equivalent in		If the computed checksum is 0, it is transmitted as all ones (the
	one's complement arithmetic). The transmitted checksum MUST NOT be		equivalent in one's complement arithmetic).
	all zeroes.
	Pseudo header		The transmitted checksum MUST NOT be all zeroes. If an application
			using UDP-Lite wishes to 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
			field.
	Similar to classic UDP, UDP Lite uses a conceptually prefixed pseudo		3.2. Pseudo Header
	header from the IP layer for checksumming purposes. The format of
	the pseudo header is the same as for classic UDP, and differs for
	different versions of IP. The pseudo header of UDP Lite is different
	from the pseudo header of classic UDP in one way: The value of the
	length field of the pseudo header is not taken from the 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 field of the pseudo header includes the UDP
	Lite header and all subsequent bytes in the IP payload.
	User Interface		UDP and UDP-Lite use the same conceptually prefixed pseudo header
			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
			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
			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
			field of the pseudo header includes the UDP-Lite header and all
			subsequent octets in the IP payload.
	A user interface should allow the same operations as for classic UDP.		3.3. Application Interface
	In addition to this, it SHOULD provide a way for the sending
	application to pass the checksum coverage value to the UDP Lite		An application interface should allow the same operations as for
	module. There SHOULD also be a way to pass the checksum coverage		UDP. In addition to this, it should provide a way for the sending
			application to pass the checksum coverage value to the UDP-Lite
			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.
	We RECOMMEND that the default behaviour of UDP Lite is to mimic		It is RECOMMENDED that the default behavior of UDP-Lite be to mimic
	classic UDP by having the coverage field match the length of the UDP		UDP by having the Checksum Coverage field match the length of the
	Lite datagram and verifying the entire packet. Applications that want		UDP-Lite packet, and verify the entire packet. Applications that want
	to define the payload as partially insensitive to bit errors SHOULD		to define the payload as partially insensitive to bit errors (e.g.
	do that by a separate system call on the sender side. Applications		error tolerant codecs using RTP [RFC-1889]) should do that by an
	that wish to receive payloads which were only partially covered by a		explicit system call on the sender side. Applications that wish to
	checksum SHOULD inform the system by a separate system call.		receive payloads that were only partially covered by a checksum
			should inform the receiving system by an explicit system call.
	IP Interface		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.
	As for classic UDP, the UDP Lite module must pass the pseudo header		3.4. IP Interface
	to the UDP Lite module. The UDP Lite 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 the length field of the IP
	header.
	The IP module MUST NOT pad the IP payload with extra bytes since the		As for UDP, the IP module must provide the pseudo header to the UDP-
	length of the UDP Lite payload delivered to the receiver depends on		Lite module. The UDP-Lite pseudo header contains the IP addresses and
	the length of the IP payload.		protocol fields of the IP header, and also the length of the IP
			payload, which is derived from the Length field of the IP header.
	Lower layer considerations		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
			depends on the length of the IP payload.
	Since UDP Lite can deliver packets with damaged payloads to an		3.5. Jumbograms
	application that wants them, frames carrying 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 Coverage field in the UDP Lite header MAY be used as a
	hint of where errors should be detected. Link layers that do not
	support partial checksums SHOULD detect errors in the entire frame.
	In general, lower layers SHOULD detect errors at least in the
	sensitive part of the frame using strong error detection mechanisms,
	but need not do so for the insensitive part.
	Note that it is usually only over links where errors are frequent		The Checksum Coverage field is 16 bits and can represent a checksum
	that the partial checksum feature of UDP Lite can make a difference		coverage of up to 65535 octets. This allows arbitrary checksum
	to the application. On links where errors are infrequent it is		coverage for IP packets, unless they are Jumbograms. For Jumbograms,
	RECOMMENDED that lower layeers detect errors in the entire packet.		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.
	Jumbograms		4. Lower Layer Considerations
	The Checksum Coverage field is 16 bits and can represent checksum		Since UDP-Lite can deliver packets with damaged payloads to an
	coverage up to 65535 octets. This allows arbitrary checksum coverage		application that wants them, frames carrying UDP-Lite packets need
	for IP datagrams, unless they are Jumbograms. For Jumbograms, the		not be discarded by lower layers when there are errors only in the
	Checksum can cover either the entire payload (when the Checksum		insensitive part. For a link that supports partial error detection,
	Coverage field has the value zero), or else at most the initial 65535		the Checksum Coverage field in the UDP-Lite header MAY be used as a
	octets of the UDP Lite datagram.		hint of where errors do not need to be detected. Lower layers MUST
			use a strong error detection mechanism to detect at least errors that
			occur in the sensitive part of the packet, and discard damaged
			packets. The sensitive part consists of the octets between the first
			octet of the 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.
	Backwards compatibility		Link layers that do not support partial error detection suitable for
			UDP-Lite, as described above, MUST detect errors in the entire UDP-
			Lite packet, and discard damaged packets. The whole UDP-Lite packet
			is thus treated in exactly the same way as a UDP packet.
	The syntactic and semantic similarity between UDP Lite and classic		It should be noted that UDP-Lite would only make a difference to the
	UDP suggests that they might share the same protocol identifier.		application if partial error detection, based on the partial checksum
	This section explores some consequences of doing so.		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.
	There are no known interoperability problems between classic UDP and		5. Compatibility with UDP
	UDP Lite if they were to share the protocol identifier of classic
	UDP. To be more precise: there is no case where a potentially
	problematic packet is delivered to an unsuspecting application; a UDP
	Lite payload with partial checksum coverage cannot be delivered to
	UDP applications, and UDP datagrams which only partially fills the IP
	payload cannot be delivered to UDP Lite applications.
	If the protocol identifier was shared between UDP and UDP Lite and a		UDP and UDP-Lite have similar syntax and semantics. Applications
	UDP Lite implementation sends UDP Lite packets with partial checksums		designed for UDP may therefore use UDP-Lite instead, and will by
	to a classic UDP implementation, the classic UDP implementation would		default receive the same full packet coverage. The similarities also
	silently discard them because a mismatching pseudo header would cause		ease implementation of UDP-Lite, since only minor modifications are
	the UDP checksum to mismatch. Neither the sending nor the receiving		needed to an existing UDP implementation.
	application would be notified. The obvious solutions to this include
	1) explicit application in-band signaling (not using the partial		UDP-Lite has been allocated a separate IP protocol identifier, XXXX
	checksum coverage option) to enable the sender to learn whether the		[INSERT IANA NUMBER BEFORE PUBLICATION], that allows a receiver to
	receiver is UDP Lite enabled or not, or		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 simple method of detecting UDP-Lite
			unaware systems is the primary benefit of having separate protocol
			identifiers.
	2) use of out-of-band signaling such as H.323, SIP, or RTCP to convey		The remainder of this section provides the rationale for allocating a
	whether the receiver is UDP Lite enabled.		separate IP protocol identifier for UDP-Lite, rather than sharing the
			IP protocol identifier with UDP.
	If UDP Lite has its own separate protocol identifier, on the other		There are no known interoperability problems between UDP and UDP-Lite
	hand, a system unaware of UDP Lite would return ICMP Protocol		if they were to share the protocol identifier with UDP. Specifically,
	Unreachable error messages to the sender. This simple method of		there is no case where a potentially problematic packet is delivered
	detecting UDP Lite unaware systems is the primary benefit of having		to an unsuspecting application; a UDP-Lite payload with partial
	separate protocol identifiers.		checksum coverage cannot be delivered to UDP applications, and UDP
			packets that only partially fill the IP payload cannot be delivered
			to applications using UDP-Lite.
	Therefore, this draft proposes to allocate a new protocol identifier		However, if the protocol identifier were to be shared between UDP and
	for UDP Lite.		UDP-Lite, and a UDP-Lite implementation was to send a UDP-Lite packet
			using a partial checksum to a UDP implementation, the UDP
			implementation would silently discard the packet, because a
			mismatching pseudo header would cause the UDP checksum to fail.
			Neither the sending nor the receiving application would be notified.
			Potential solutions to this could have been:
	Security considerations		1) explicit application in-band signaling (while not using the
			partial checksum coverage option) to enable the sender to learn
			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
			convey whether the receiver is UDP-Lite enabled.
	The security impact of UDP Lite is twofold. First, applications who		Anyway, since UDP-Lite has now been assigned its own protocol
	do not expect damaged payloads are bound to malfunction if damaged		identifier, there is no need to consider the possibility of delivery
	payloads are delivered to them. To avoid this, we RECOMMEND that the		of a UDP-Lite packet to an unsuspecting UDP port.
	sending and the receiving side application both explicitly enable the
	partial checksum option. Packets with partial checksums SHOULD NOT
	be delivered to applications that have not enabled the partial
	checksum option.
	Second, there is the question of how UDP Lite interacts with		6. Security Considerations
			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, it is fine with the application if the		option of UDP-Lite is enabled, the insensitive portion of a packet
	insensitive part of a packet changes in transit. This is contrary to		may change in transit. This is contrary to the idea behind most
	the idea behind most authentication mechanisms; authentication		authentication mechanisms: authentication succeeds if the packet has
	succeeds when the packet has not changed in transit. Unless		not changed in transit. Unless authentication mechanisms that operate
	authentication mechanisms that operate only on the sensitive part of		only on the sensitive part of packets are developed and used,
	packets are developed, authentication will always fail on UDP Lite		authentication will always fail on UDP-Lite packets where the
	packets where the insensitive part has been damaged.		insensitive part has been damaged.
	Encryption is also an issue when using UDP Lite. If a few bits of an		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
			receiver.
			Encryption is also an issue when using UDP-Lite. If a few bits of an
	encrypted packet are damaged, the decryption transform will typically		encrypted packet are damaged, the decryption transform will typically
	spread this error so that the packet becomes too damaged to be of		spread errors so that the packet becomes too damaged to be of use.
	use. Most strong encryption transforms today exhibit this behaviour,		Many strong encryption transforms today exhibit this behavior, for
	for good reason. It might be possible to develop encryption		reasons obvious from a security point of view. There exist encryption
	transforms which would not spread damage in this way when the damage		transforms, stream ciphers, which do not spread errors in this way
	occurs in the insensitive part of the packet. A class of such		when the damage occurs in the insensitive part of the packet.
	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.
	IANA considerations		7. IANA Considerations
	We request that a new ip protocol identifier is allocated for UDP		A new IP protocol number, XXXX [INSERT NUMBER BEFORE PUBLICATION],
	Lite.		has been assigned for UDP-Lite.
	Conclusions		[NOTE, REMOVE BEFORE PUBLICATION]
	We have presented the UDP Lite protocol. The main motivation for this		IANA assignment instruction:
	new variant of the classic UDP transport protocol is decreased packet		- The IANA must reserve an IP protocol number for UDP-Lite.
	error rates 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 to define a packet as partially insensitive to bit
	errors on a per-packet basis. If no part of a packet is defined as
	insensitive, UDP Lite is semantically identical to classic UDP.
	Contact info		[END OF NOTE]
			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
			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 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),
			1999.
			9. Acknowledgements
			Thanks to Ghyslain Pelletier for significant technical and editorial
			comments. Thanks also to Elisabetta Carrara and Mats Naslund for
			reviewing the security considerations chapter, and to Peter Eriksson
			for doing a language review and thereby improving the clarity of this
			document.
			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@cdt.luth.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		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		Tucson, AZ 85721-0077, USA
	Email: steve@cs.arizona.edu		Email: steve@cs.arizona.edu
	Normative References		Lars-Erik Jonsson
			Ericsson AB
			Box 920
			S-971 28 Lulea, Sweden
			Email: lars-erik.jonsson@ericsson.com
	[RFC-768] Postel, J., "User Datagram Protocol," RFC 768,		Godred Fairhurst
	Information Sciences Institute, August 1980.		Department of Engineering
			University of Aberdeen
			Aberdeen, AB24 3UE, UK
			Email: gorry@erg.abdn.ac.uk
	[RFC-793] Postel, J., "Transmission Control Protocol," RFC 793,		Full Copyright Statement
	Information Sciences Institute, September 1981.
	[RFC-2460] Deering, S., Hinden, R., "Internet Protocol, Version 6		Copyright (C) The Internet Society (2002). All Rights Reserved.
	(IPv6) Specification," RFC 2460, IETF, December 1998.
	Informative References		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.
	[RFC-2026] Bradner, S., "The Internet Standards Process," RFC 2026,		The limited permissions granted above are perpetual and will not be
	Harvard University, October 1996.		revoked by the Internet Society or its successors or assigns.
	[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate		This document and the information contained herein is provided on an
	Requirement Levels," Harvard University, March 1997.		"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 draft expires July 24, 2002		This Internet-Draft expires June 5, 2003.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/