draft-ietf-tsvwg-udp-lite-01.txt		draft-ietf-tsvwg-udp-lite-02.txt
	Network Working Group L-A. Larzon		Network Working Group L-A. Larzon
	INTERNET-DRAFT Lulea University of Technology		INTERNET-DRAFT Lulea University of Technology
	Expires: June 2003 M. Degermark		Expires: January 2003 M. Degermark
	S. Pink		S. Pink
	The University of Arizona		The University of Arizona
	L-E. Jonsson (editor)		L-E. Jonsson (Editor)
	Ericsson		Ericsson
	G. Fairhurst (editor)		G. Fairhurst (Editor)
	University of Aberdeen		University of Aberdeen
	December 5, 2002		August, 2003
	The UDP-Lite Protocol		The UDP-Lite Protocol
	<draft-ietf-tsvwg-udp-lite-01.txt>		<draft-ietf-tsvwg-udp-lite-02.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 RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 2, line 7		skipping to change at page 13, line ?
	Abstract		Abstract
	This document describes the UDP-Lite protocol, which is similar to		This document describes the UDP-Lite protocol, which is similar to
	UDP [RFC-768], but can also serve applications that in error-prone		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 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....................................................3		3.1. Fields....................................................3
	3.2. Pseudo Header.............................................4		3.2. Pseudo Header.............................................4
	3.3. Application Interface.....................................4		3.3. Application Interface.....................................4
	3.4. IP Interface..............................................5		3.4. IP Interface..............................................5
	3.5. Jumbograms................................................5		3.5. Jumbograms................................................5
	4. Lower Layer Considerations.....................................5		4. Lower Layer Considerations.....................................6
	5. Compatibility with UDP.........................................6		5. Compatibility with UDP.........................................6
	6. Security Considerations........................................7		6. Security Considerations........................................7
	7. IANA Considerations............................................7		7. IANA Considerations............................................8
	8. References.....................................................8		8. References.....................................................8
	8.1. Normative References......................................8		8.1. Normative References......................................8
	8.2. Informative References....................................8		8.2. Informative References....................................9
	9. Acknowledgements...............................................8		9. Acknowledgements...............................................10
	10. Authors' Addresses............................................9		10. Authors' Addresses............................................11
	1. Introduction		1. Introduction
	Why another transport protocol?		This document describes a new transport protocol, UDP-Lite, (also
			known as UDPLite). This new protocol is based on three observations:
	First, there is a class of applications that prefer to have damaged		First, there is a class of applications that benefit from having
	data delivered rather than discarded by the network. A number of		damaged data delivered rather than discarded by the network. A number
	codecs for voice and video fall into this class. These codecs are		of codecs for voice and video fall into this class (e.g. the AMR
	designed to cope better with errors in the payload than with loss of		speech codec [RFC-3267], the Internet Low Bit Rate Codec [ILBRC], and
	entire packets.		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
			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		Second, all links that support IP transmission should use a strong
	partially damaged. Several radio technologies exhibit this behavior		link layer integrity check (e.g. CRC-32 [LINK]), and this MUST be
	when operating at a point where cost and delay are sufficiently low.		used by default for IP traffic. When the under-lying link supports
			it, certain types of traffic (e.g. UDP-Lite) may benefit from a
			different link behavior that permits partially damaged IP packets to
			be forwaded when requested [LINK]. Several radio technologies (e.g.
			[3GPP-QoS]) support this link behavior when operating at a point
			where cost and delay are sufficiently low. If error-prone links are
			aware of the error sensitive portion of a packet, it is also possible
			for the physical link to provide greater protection to reduce the
			probability of corruption of these error sensitive bytes (e.g., the
			use of unequal Forward Error Correction).
	Third, intermediate layers should not prevent error-tolerant		Third, intermediate layers (i.e., IP and the transport layer
	applications to run well in the presence of such links. The		protocols) should not prevent error-tolerant applications from
	intermediate layers are IP and the transport layer. IP is not a		running well in the presence of such links. IP is not a problem in
	problem in this regard since the IP header has no checksum that		this regard, since the IP header has no checksum that covers the IP
	covers the IP payload. The generally available transport protocol		payload. The generally available transport protocol best suited for
	best suited for these applications is UDP, since it has no overhead
	for retransmission of erroneous packets, in-order delivery, or error		Larzon, et al. [Page 2]
			these applications is UDP, since it has no overhead for
			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 checksum
	is mandatory and must not be disabled. The IPv6 header does not have		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		a header checksum and it was deemed necessary to always protect the
	IP addressing information by making the UDP checksum mandatory.		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 [UDP-LITE]. 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. What should be verified by		errors best dealt with by the application. The set of octets to be
	the checksum is best specified by the sending application.		verified by the checksum is best specified by the sending
			application.
	UDP-Lite provides a checksum with an optional partial coverage. When		UDP-Lite provides a checksum with an optional partial coverage. When
	using this option, a packet is divided into a sensitive part (covered		using this option, a packet is divided into a sensitive part (covered
	by the checksum) and an insensitive part (not covered by the		by the checksum) and an insensitive part (not covered by the
	checksum). Errors in the insensitive part will not cause the packet		checksum). Errors in the insensitive part will not cause the packet
	to be discarded by the transport layer at the receiving end host.		to be discarded by the transport layer at the receiving end host.
	When the checksum covers the entire packet, which should be the		When the checksum covers the entire packet, which should be the
	default, UDP-Lite is semantically identical to UDP.		default, UDP-Lite is semantically identical to UDP.
	Compared to UDP, the UDP-Lite partial checksum provides extra		Compared to UDP, the UDP-Lite partial checksum provides extra
	skipping to change at page 3, line 33		skipping to change at page 13, line ?
	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 :
	skipping to change at page 4, line 14		skipping to change at page 13, line ?
	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 Checksum
	Coverage field MUST be either 0 or at least 8. A UDP-Lite packet with		Coverage field MUST be either 0 or at least 8. A UDP-Lite packet with
	a Checksum Coverage value of 1 to 7 MUST be discarded by the		a Checksum Coverage value of 1 to 7 MUST be discarded by the
	receiver. UDP-Lite packets with a Checksum Coverage greater than the		receiver. Irrespective of the Checksum Coverage, the computed
	IP length MUST also be discarded.		Checksum field MUST include a pseudo-header, based on the IP header
			(see below). 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		The Checksum field is the 16-bit one's complement of the one's
	of a pseudo-header of information from the IP header, the number of		complement sum of a pseudo-header of information collected from the
	octets specified by the Checksum Coverage (starting at the first		IP header, the number of octets specified by the Checksum Coverage
	octet in the UDP-Lite header), virtually padded with a zero octet at		(starting at the first octet in the UDP-Lite header), virtually
	the end (if necessary) to make a multiple of two octets [RFC-1071].		padded with a zero octet at the end (if necessary) to make a multiple
	If the computed checksum is 0, it is transmitted as all ones (the		of two octets [RFC-1071]. Prior to computation, the checksum field
	equivalent in one's complement arithmetic).		MUST be set to zero. If the computed checksum is 0, it is transmitted
			as all ones (the equivalent in one's complement arithmetic).
	The transmitted checksum MUST NOT be all zeroes. If an application		Since the transmitted checksum MUST NOT be all zeroes, an application
	using UDP-Lite wishes to have no protection of the packet payload, it		using UDP-Lite that wishes to have no protection of the packet
	should use a Checksum Coverage value of 8. This differs from the use		payload, should use a Checksum Coverage value of 8. This differs from
	of UDP over IPv4, in that the minimal UDP-Lite checksum always covers		the use of UDP over IPv4, in that the minimal UDP-Lite checksum
	the UDP-Lite protocol header, which includes the Checksum Coverage		always covers the UDP-Lite protocol header, which includes the
	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. In addition to this, it should provide a way for the sending		UDP. 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 to mimic
	UDP by having the Checksum Coverage field match the length of the		UDP by having the Checksum Coverage field match the length of the
	UDP-Lite packet, and verify the entire packet. Applications that want		UDP-Lite packet, and verify the entire packet. Applications that wish
	to define the payload as partially insensitive to bit errors (e.g.		to define the payload as partially insensitive to bit errors (e.g.
	error tolerant codecs using RTP [RFC-1889]) should do that by an		error tolerant codecs using RTP [RFC-1889]) should do this by an
	explicit system call on the sender side. Applications that wish to		explicit system call on the sender side. Applications that wish to
	receive payloads that were only partially covered by a checksum		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 insensitive part of		level or patterns of errors that may occur in the corruption
	the UDP-Lite payload. Applications that use UDP-Lite should not make		insensitive part of the UDP-Lite payload. Applications that use UDP-
	any assumptions regarding the correctness of the received data beyond		Lite should not make any assumptions regarding the correctness of the
	the indicated checksum coverage, and should if necessary introduce		received data beyond the position indicated by the Checksum Coverage
	their own appropriate validity checks.		field, and should if necessary introduce their own 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 module. The UDP-Lite pseudo header contains the IP addresses and		Lite protocol module (known as the UDPLite module). The UDP-Lite
	protocol fields of the IP header, and also the length of the IP		pseudo header contains the IP addresses and protocol fields of the IP
	payload, which is derived from the Length field of the IP header.		header, and also the length of the IP payload, which is derived from
			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 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 wants them, frames carrying UDP-Lite packets need		application that wishes to receive them, frames carrying UDP-Lite
	not be discarded by lower layers when there are errors only in the		packets need not be discarded by lower layer protocols when there are
	insensitive part. For a link that supports partial error detection,		errors only in the insensitive part. For a link that supports partial
	the Checksum Coverage field in the UDP-Lite header MAY be used as a		error detection, the Checksum Coverage field in the UDP-Lite header
	hint of where errors do not need to be detected. Lower layers MUST		MAY be used as a hint of where errors do not need to be detected.
	use a strong error detection mechanism to detect at least errors that		Lower layers MUST use a strong error detection mechanism [LINK] to
	occur in the sensitive part of the packet, and discard damaged		detect at least errors that occur in the sensitive part of the
	packets. The sensitive part consists of the octets between the first		packet, and discard damaged packets. The sensitive part consists of
	octet of the IP header and the last octet identified by the Checksum		the octets between the first octet of the IP header and the last
	Coverage field. At least the sensitive part would thus be treated in		octet identified by the Checksum Coverage field. The sensitive part
	exactly the same way as UDP packets.		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 discard damaged packets. The whole UDP-Lite packet		Lite packet, and MUST discard damaged packets [LINK]. The whole UDP-
	is thus treated in exactly the same way as a UDP packet.		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 the		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. Obviously, partial error detection at the link layer would		above. Partial error detection at the link layer would only make a
	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, XXXX
	[INSERT IANA NUMBER BEFORE PUBLICATION], that allows a receiver to		(UDPLite) [INSERT IANA NUMBER BEFORE PUBLICATION], that allows a
	identify whether UDP or UDP-Lite is used. A system unaware of UDP-		receiver to identify whether UDP or UDP-Lite is used. A destination
	Lite will in general return an ICMP Protocol Unreachable error		end host that is unaware of UDP-Lite will, in general, return an ICMP
	message to the sender. This simple method of detecting UDP-Lite
	unaware systems is the primary benefit of having separate protocol		Larzon, et al. [Page 6]
	identifiers.		"Protocol Unreachable" or an ICMPv6 "Payload Type Unknown" error
			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. Specifically,
	there is no case where a potentially problematic packet is delivered		there is no case where a potentially problematic packet is delivered
	to an unsuspecting application; a UDP-Lite payload with partial		to an unsuspecting application; a UDP-Lite payload with partial
	checksum coverage cannot be delivered to UDP applications, and UDP		checksum coverage cannot be delivered to UDP applications, and UDP
	packets that only partially fill the IP payload cannot be delivered		packets that only partially fill the IP payload cannot be delivered
	to applications using UDP-Lite.		to applications using UDP-Lite.
	However, if the protocol identifier were to be shared between UDP and		However, if the protocol identifier were to have been shared between
	UDP-Lite, and a UDP-Lite implementation was to send a UDP-Lite packet		UDP and UDP-Lite, and a UDP-Lite implementation was to send a UDP-
	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 whether the receiver is UDP-Lite enabled.		convey whether the receiver is UDP-Lite enabled.
	Anyway, since UDP-Lite has now been assigned its own protocol		Since UDP-Lite has been assigned its own IP protocol identifier,
	identifier, there is no need to consider the possibility of delivery		there is no need to consider this possibility of delivery of a UDP-
	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 operate
	only on the sensitive part of packets are developed and used,		only on the sensitive part of packets are developed and used,
	authentication will always fail on 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, or
			Larzon, et al. [Page 7]
	Authentication Header, AH) is applied (at least) to the entire IP		Authentication Header, AH) is applied (at least) to the entire IP
	packet payload. Corruption of any bit within the protected area will		packet payload. Corruption of any bit within the protected area will
	then result in the discarding of the UDP-Lite packet by the IP		then result in the IP receiver discarding the UDP-Lite packet.
	receiver.
	Encryption is also an issue when using UDP-Lite. If a few bits of an		When IPSEC is used with ESP payload encryption, a link can not
	encrypted packet are damaged, the decryption transform will typically		determine the specific transport protocol of a packet being forwarded
	spread errors so that the packet becomes too damaged to be of use.		by inspecting the IP packet payload. In this case, the link MUST
	Many strong encryption transforms today exhibit this behavior, for		provide a standard integrity check covering the entire IP packet and
	reasons obvious from a security point of view. There exist encryption		payload. UDP-Lite provides no benefit in this case.
	transforms, stream ciphers, which do not spread errors in this way
	when the damage occurs in the insensitive part of the packet.		Encryption (e.g., at the transport or application levels)
			may be used. Note that omitting an integrity check can, under
			certain circumstances, compromise confidentiality [Bell98].
			If a few bits of an encrypted packet are damaged, the decryption
			transform will typically spread errors so that the packet becomes
			too damaged to be of use. Many encryption transforms today exhibit
			this behavior. There exist encryption transforms, stream ciphers,
			which do not cause error propagation. Proper use of stream ciphers
			can be quite difficult, especially when authentication-checking is
			omitted [BB01]. In particular, an attacker can cause predictable
			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, XXXX [INSERT NUMBER BEFORE PUBLICATION],
	has been assigned for UDP-Lite.		has been assigned for UDP-Lite. The name associated with this
			protocol number is "UDPLite". This ensures compatibility across a
			wide range of platforms, since on some platforms the "-" character
			may not form part of a protocol entity name.
	[NOTE, REMOVE BEFORE PUBLICATION]		[NOTE, REMOVE BEFORE PUBLICATION]
	IANA assignment instruction:		IANA assignment instruction:
	- The IANA must reserve an IP protocol number for UDP-Lite.		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]		[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", RFC 768 (STD6),
	August 1980.		August 1980.
	[RFC-791] Postel, J., "Internet Protocol", RFC 791 (STD5),		[RFC-791] Postel, J., "Internet Protocol", RFC 791 (STD5),
	September 1981.		September 1981.
	skipping to change at page 8, line 29		skipping to change at page 13, line ?
	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", RFC 2119 (BCP15), 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",
			Proceedings of CRYPTO Ì98, August, 1988.
			[BB01] Bellovin, S.M., and M. Blaze, "Cryptographic Modes of
			Operation for the Internet", 2nd NIST Workshop on Modes
			of Operation, August 2001.
			[3GPP] "Technical Specification Group Services and System
			Aspects; Quality of Service (QoS) concept and
			architecture", TS 23.107 V5.9.0, Technical Specification
			3rd Generation Partnership Project, June 2003.
			[H.264] Hannuksela, M.M., T. Stockhammer, M. Westerlund. And
			D. Singer, "RTP payload Format for H.264 Video", Internet
			Draft, Work in Progress, March 2003.
			[ILBRC] S.V. Andersen, et. al., "Internet Low Bit Rate Codec",
			draft-ietf-avt-ilbc-codec-01.txt, Internet Draft, Work in
			Progress, March 2003.
			[ISO-14496] ISO/IEC International Standard 1446 (MPEG-4),
			"Information Technology € Coding of Audio-Visual
			Objects", January 2000.
			[ITU-H.263] "Video Coding for Low Bit Rate Communication," ITU-T
			Recommendation H.263, January 1998.
			Larzon, et al. [Page 9]
			[ITU-H.264] "Draft ITU-T Recommendation and Final Draft International
			Standard of Joint Video Specification",
			ITU-T Recommendation H.264, May 2003.
			[LINK] Phil Karn, Editor, "Advice for Internet Subnetwork
			Designers", Work in Progress, IETF.
	[RFC-1889] Schulzrinne, H., Casner, S., Frederick, R., and		[RFC-1889] Schulzrinne, H., Casner, S., Frederick, R., and
	V. Jacobson, "RTP: A Transport Protocol for Real-Time		V. Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", RFC 1889, January 1996.		Applications", RFC 1889, January 1996.
	[RFC-2026] Bradner, S., "The Internet Standards Process", RFC 2026,		[RFC-2026] Bradner, S., "The Internet Standards Process", RFC 2026,
	October 1996.		October 1996.
	[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 206, November 1998.
	[UDP-LITE] Larzon, L-A., Degermark, M., and S. Pink, "UDP Lite for		[RFC-3267] Sjoberg, J., M. Westerlund, A. Lakeaniemi, and Q. Xie,
			"Real-Time Transport Protocol (RTP) Payload Format and
			File Storage Format for the Adaptiove Multi-Rate (AMR)
			and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs",
			RFC 3267, June 2002.
			[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 Elisabetta Carrara and Mats Naslund for		comments. Thanks also to Steven Bellovin, Elisabetta Carrara, and
	reviewing the security considerations chapter, and to Peter Eriksson		Mats Naslund for reviewing the security considerations chapter, and
	for doing a language review and thereby improving the clarity of this		to Peter Eriksson for a language review and thereby improving the
	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@cdt.luth.se
	Mikael Degermark		Mikael Degermark
	Department of Computer Science		Department of Computer Science
	skipping to change at page 10, line 5		skipping to change at page 13, line ?
	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		Email: gorry@erg.abdn.ac.uk
			Larzon, et al. [Page 11]
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	skipping to change at page 10, line 33		skipping to change at page 13, line ?
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	This Internet-Draft expires June 5, 2003.		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
			implementation, not a spec fault.
			(6) Examples added of applications
			(7) Examples of systems that would use it
			(8) Security issues (text requested by IESG).
			(9) Minor NiTs with written English corrected.
			(10) Introduction starts rather strangely - can we fix this?
			(11) Security AD Text Revised, and now OK.
			(12) Revised security note:
			When IPSEC is used with ESP payload encryption, there is no
			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]
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/