draft-ietf-tsvwg-udp-guidelines-10.txt		draft-ietf-tsvwg-udp-guidelines-11.txt
	Transport Area Working Group L. Eggert		Transport Area Working Group L. Eggert
	Internet-Draft Nokia		Internet-Draft Nokia
	Intended status: BCP G. Fairhurst		Intended status: BCP G. Fairhurst
	Expires: February 23, 2009 University of Aberdeen		Expires: April 13, 2009 University of Aberdeen
	August 22, 2008		October 10, 2008
	Unicast UDP Usage Guidelines for Application Designers		Unicast UDP Usage Guidelines for Application Designers
	draft-ietf-tsvwg-udp-guidelines-10		draft-ietf-tsvwg-udp-guidelines-11
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 to 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/1id-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.
	This Internet-Draft will expire on February 23, 2009.		This Internet-Draft will expire on April 13, 2009.
	Abstract		Abstract
	The User Datagram Protocol (UDP) provides a minimal, message-passing		The User Datagram Protocol (UDP) provides a minimal, message-passing
	transport that has no inherent congestion control mechanisms.		transport that has no inherent congestion control mechanisms.
	Because congestion control is critical to the stable operation of the		Because congestion control is critical to the stable operation of the
	Internet, applications and upper-layer protocols that choose to use		Internet, applications and upper-layer protocols that choose to use
	UDP as an Internet transport must employ mechanisms to prevent		UDP as an Internet transport must employ mechanisms to prevent
	congestion collapse and establish some degree of fairness with		congestion collapse and establish some degree of fairness with
	concurrent traffic. This document provides guidelines on the use of		concurrent traffic. This document provides guidelines on the use of
	skipping to change at page 2, line 14		skipping to change at page 2, line 14
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 5		3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 6		3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 6
	3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 11		3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 11
	3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 12		3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 12
	3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 13		3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 13
	3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 15		3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 14
	3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 17		3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 16
	3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 18		3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 18
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 18		4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 21		8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
	8.2. Informative References . . . . . . . . . . . . . . . . . . 22		8.2. Informative References . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
	Intellectual Property and Copyright Statements . . . . . . . . . . 27		Intellectual Property and Copyright Statements . . . . . . . . . . 28
	1. Introduction		1. Introduction
	The User Datagram Protocol (UDP) [RFC0768] provides a minimal,		The User Datagram Protocol (UDP) [RFC0768] provides a minimal,
	unreliable, best-effort, message-passing transport to applications		unreliable, best-effort, message-passing transport to applications
	and upper-layer protocols (both simply called "applications" in the		and upper-layer protocols (both simply called "applications" in the
	remainder of this document). Compared to other transport protocols,		remainder of this document). Compared to other transport protocols,
	UDP and its UDP-Lite variant [RFC3828] are unique in that they do not		UDP and its UDP-Lite variant [RFC3828] are unique in that they do not
	establish end-to-end connections between communicating end systems.		establish end-to-end connections between communicating end systems.
	UDP communication consequently does not incur connection		UDP communication consequently does not incur connection
	skipping to change at page 7, line 12		skipping to change at page 7, line 12
	way that is independent of the transport protocol. Such mechanisms		way that is independent of the transport protocol. Such mechanisms
	have failed to see deployment, but would otherwise simplify the		have failed to see deployment, but would otherwise simplify the
	design of congestion control mechanisms for UDP sessions, so that		design of congestion control mechanisms for UDP sessions, so that
	they fulfill the requirements in [RFC2914].		they fulfill the requirements in [RFC2914].
	3.1.1. Bulk Transfer Applications		3.1.1. Bulk Transfer Applications
	Applications that perform bulk transmission of data to a peer over		Applications that perform bulk transmission of data to a peer over
	UDP, i.e., applications that exchange more than a small number of UDP		UDP, i.e., applications that exchange more than a small number of UDP
	datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC)		datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC)
	[RFC3448], window-based, TCP-like congestion control, or otherwise		[RFC5348], window-based, TCP-like congestion control, or otherwise
	ensure that the application complies with the congestion control		ensure that the application complies with the congestion control
	principles.		principles.
	TFRC has been designed to provide both congestion control and		TFRC has been designed to provide both congestion control and
	fairness in a way that is compatible with the IETF's other transport		fairness in a way that is compatible with the IETF's other transport
	protocols. TFRC is currently being updated		protocols. If an application implements TFRC, it need not follow the
	[I-D.ietf-dccp-rfc3448bis], and application designers SHOULD always		remaining guidelines in Section 3.1.1, because TFRC already addresses
	evaluate whether the latest published specification fits their needs.		them, but SHOULD still follow the remaining guidelines in the
	If an application implements TFRC, it need not follow the remaining		subsequent subsections of Section 3.
	guidelines in Section 3.1.1, because TFRC already addresses them, but
	SHOULD still follow the remaining guidelines in the subsequent
	subsections of Section 3.
	Bulk transfer applications that choose not to implement TFRC or TCP-		Bulk transfer applications that choose not to implement TFRC or TCP-
	like windowing SHOULD implement a congestion control scheme that		like windowing SHOULD implement a congestion control scheme that
	results in bandwidth use that competes fairly with TCP within an		results in bandwidth use that competes fairly with TCP within an
	order of magnitude. Section 2 of [RFC3551] suggests that		order of magnitude. Section 2 of [RFC3551] suggests that
	applications SHOULD monitor the packet loss rate to ensure that it is		applications SHOULD monitor the packet loss rate to ensure that it is
	within acceptable parameters. Packet loss is considered acceptable		within acceptable parameters. Packet loss is considered acceptable
	if a TCP flow across the same network path under the same network		if a TCP flow across the same network path under the same network
	conditions would achieve an average throughput, measured on a		conditions would achieve an average throughput, measured on a
	reasonable timescale, that is not less than that of the UDP flow.		reasonable timescale, that is not less than that of the UDP flow.
	skipping to change at page 13, line 20		skipping to change at page 13, line 15
	An application that requires reliable and ordered message delivery		An application that requires reliable and ordered message delivery
	SHOULD choose an IETF standard transport protocol that provides these		SHOULD choose an IETF standard transport protocol that provides these
	features. If this is not possible, it will need to implement a set		features. If this is not possible, it will need to implement a set
	of appropriate mechanisms itself.		of appropriate mechanisms itself.
	3.4. Checksum Guidelines		3.4. Checksum Guidelines
	The UDP header includes an optional, 16-bit ones-complement checksum		The UDP header includes an optional, 16-bit ones-complement checksum
	that provides an integrity check. This results in a relatively weak		that provides an integrity check. This results in a relatively weak
	protection from in terms of coding theory [RFC3819] and application		protection in terms of coding theory [RFC3819] and application
	developers SHOULD implement additional checks where data integrity is		developers SHOULD implement additional checks where data integrity is
	important, e.g., through a Cyclic Redundancy Check (CRC) included		important, e.g., through a Cyclic Redundancy Check (CRC) included
	with the data to verify the integrity of an entire object/file sent		with the data to verify the integrity of an entire object/file sent
	over UDP service.		over UDP service.
	The UDP checksum provides a statistical guarantee that the payload		The UDP checksum provides a statistical guarantee that the payload
	was not corrupted in transit. It also allows the receiver to verify		was not corrupted in transit. It also allows the receiver to verify
	that it was the intended destination of the packet, because it covers		that it was the intended destination of the packet, because it covers
	the IP addresses, port numbers and protocol number, and it verifies		the IP addresses, port numbers and protocol number, and it verifies
	that the packet is not truncated or padded, because it covers the		that the packet is not truncated or padded, because it covers the
	skipping to change at page 17, line 8		skipping to change at page 16, line 47
	UDP for these deployments. On the other hand, there is anecdotal		UDP for these deployments. On the other hand, there is anecdotal
	evidence that suggests that direct communication through middleboxes,		evidence that suggests that direct communication through middleboxes,
	e.g., by using ICE [I-D.ietf-mmusic-ice], does succeed less often		e.g., by using ICE [I-D.ietf-mmusic-ice], does succeed less often
	with TCP than with UDP. The tradeoffs between different transport		with TCP than with UDP. The tradeoffs between different transport
	protocols - especially when it comes to middlebox traversal - deserve		protocols - especially when it comes to middlebox traversal - deserve
	careful analysis.		careful analysis.
	3.6. Programming Guidelines		3.6. Programming Guidelines
	The de facto standard application programming interface (API) for		The de facto standard application programming interface (API) for
	TCP/IP applications is the "sockets" interface [POSIX]. Although		TCP/IP applications is the "sockets" interface [POSIX]. Some
	this API was developed for UNIX in the early 1980s, a wide variety of		platforms also offer applications the ability to directly assemble
	non-UNIX operating systems also implements it. The sockets API		and transmit IP packets through "raw sockets" or similar facilities.
	supports both IPv4 and IPv6 [RFC3493]. The UDP sockets API differs		This is a second, more cumbersome method of using UDP. The
	from that for TCP in several key ways. Because application		guidelines in this document cover all such methods through which an
	programmers are typically more familiar with the TCP sockets API, the		application may use UDP. Because the sockets API is by far the most
	remainder of this section discusses these differences. [STEVENS]		common method, the remainder of this section discusses it in more
	provides usage examples of the UDP sockets API.		detail.
			Although the sockets API was developed for UNIX in the early 1980s, a
			wide variety of non-UNIX operating systems also implements it. The
			sockets API supports both IPv4 and IPv6 [RFC3493]. The UDP sockets
			API differs from that for TCP in several key ways. Because
			application programmers are typically more familiar with the TCP
			sockets API, the remainder of this section discusses these
			differences. [STEVENS] provides usage examples of the UDP sockets
			API.
	UDP datagrams may be directly sent and received, without any		UDP datagrams may be directly sent and received, without any
	connection setup. Using the sockets API, applications can receive		connection setup. Using the sockets API, applications can receive
	packets from more than one IP source address on a single UDP socket.		packets from more than one IP source address on a single UDP socket.
	Some servers use this to exchange data with more than one remote host		Some servers use this to exchange data with more than one remote host
	through a single UDP socket at the same time. When applications need		through a single UDP socket at the same time. When applications need
	to ensure that they receive packets from a particular source address,		to ensure that they receive packets from a particular source address,
	they MUST implement corresponding checks at the application layer or		they MUST implement corresponding checks at the application layer or
	explicitly request that the operating system filter the received		explicitly request that the operating system filter the received
	packets.		packets.
	skipping to change at page 18, line 28		skipping to change at page 18, line 28
	state. This prevents delayed packets from the closed connection		state. This prevents delayed packets from the closed connection
	instance from being mistakenly associated with a later connection		instance from being mistakenly associated with a later connection
	instance that happens to reuse the same IP address and port pairs.		instance that happens to reuse the same IP address and port pairs.
	The UDP protocol does not implement such a mechanism. Therefore,		The UDP protocol does not implement such a mechanism. Therefore,
	UDP-based applications need to be robust in this case. One		UDP-based applications need to be robust in this case. One
	application may close a socket or terminate, followed in time by		application may close a socket or terminate, followed in time by
	another application receiving on the same port. This later		another application receiving on the same port. This later
	application may then receive packets intended for the first		application may then receive packets intended for the first
	application that were delayed in the network.		application that were delayed in the network.
			The Internet can provide service differentiation to applications
			based on IP-layer packet markings [RFC2475]. This facility can be
			used for UDP traffic. Different operating systems provide different
			interfaces for marking packets to applications. Differentiated
			services require support from the network, and application deployers
			need to discuss the provisioning of this functionality with their
			network operator.
	3.7. ICMP Guidelines		3.7. ICMP Guidelines
	Applications can utilize information about ICMP error messages that		Applications can utilize information about ICMP error messages that
	the UDP layer passes up for a variety of purposes [RFC1122].		the UDP layer passes up for a variety of purposes [RFC1122].
	Applications SHOULD validate that the information in the ICMP message		Applications SHOULD validate that the information in the ICMP message
	payload, e.g., a reported error condition, corresponds to a UDP		payload, e.g., a reported error condition, corresponds to a UDP
	datagram that the application actually sent. Note that not all APIs		datagram that the application actually sent. Note that not all APIs
	have the necessary functions to support this validation, and some		have the necessary functions to support this validation, and some
	APIs already perform this validation internally before passing ICMP		APIs already perform this validation internally before passing ICMP
	information to the application.		information to the application.
	skipping to change at page 19, line 50		skipping to change at page 20, line 10
	objects, such as files or messages, instead of individual UDP		objects, such as files or messages, instead of individual UDP
	payloads. In these situations, CMS [RFC3852], S/MIME [RFC3851] or		payloads. In these situations, CMS [RFC3852], S/MIME [RFC3851] or
	OpenPGP [RFC4880] could be used. In addition, there are many non-		OpenPGP [RFC4880] could be used. In addition, there are many non-
	IETF protocols in this area.		IETF protocols in this area.
	Like congestion control mechanisms, security mechanisms are difficult		Like congestion control mechanisms, security mechanisms are difficult
	to design and implement correctly. It is hence RECOMMENDED that		to design and implement correctly. It is hence RECOMMENDED that
	applications employ well-known standard security mechanisms such as		applications employ well-known standard security mechanisms such as
	DTLS or IPsec, rather than inventing their own.		DTLS or IPsec, rather than inventing their own.
			The Generalized TTL Security Mechanism (GTSM) [RFC3682] may be used
			with UDP applications (especially when the intended endpoint is on
			the same link as the sender). This is a lightweight mechanism that
			allows a receiver to filter unwanted packets.
	In terms of congestion control, [RFC2309] and [RFC2914] discuss the		In terms of congestion control, [RFC2309] and [RFC2914] discuss the
	dangers of congestion-unresponsive flows to the Internet. This		dangers of congestion-unresponsive flows to the Internet. This
	document provides guidelines to designers of UDP-based applications		document provides guidelines to designers of UDP-based applications
	to congestion-control their transmissions, and does not raise any		to congestion-control their transmissions, and does not raise any
	additional security concerns.		additional security concerns.
	5. Summary		5. Summary
	This section summarizes the guidelines made in Section 3 and		This section summarizes the guidelines made in Section 3 and
	Section 4 in a tabular format in Table 1 for easy referencing.		Section 4 in a tabular format in Table 1 for easy referencing.
	skipping to change at page 21, line 15		skipping to change at page 22, line 8
	6. IANA Considerations		6. IANA Considerations
	This document raises no IANA considerations.		This document raises no IANA considerations.
	(Note to the RFC Editor: Please remove this section upon		(Note to the RFC Editor: Please remove this section upon
	publication.)		publication.)
	7. Acknowledgments		7. Acknowledgments
	Thanks to Paul Aitken, Mark Allman, Francois Audet, Iljitsch van		Thanks to Paul Aitken, Mark Allman, Francois Audet, Iljitsch van
	Beijnum, Stewart Bryant, Remi Denis-Courmont, Wesley Eddy, Pasi		Beijnum, Stewart Bryant, Remi Denis-Courmont, Lisa Dusseault, Wesley
	Eronen, Sally Floyd, Robert Hancock, Jeffrey Hutzelman, Cullen		Eddy, Pasi Eronen, Sally Floyd, Robert Hancock, Jeffrey Hutzelman,
	Jennings, Tero Kivinen, Peter Koch, Jukka Manner, Philip Matthews,		Cullen Jennings, Tero Kivinen, Peter Koch, Jukka Manner, Philip
	Joerg Ott, Colin Perkins, Tom Petch, Carlos Pignataro, Pasi		Matthews, Joerg Ott, Colin Perkins, Tom Petch, Carlos Pignataro, Pasi
	Sarolahti, Pascal Thubert, Joe Touch and Magnus Westerlund for their		Sarolahti, Pascal Thubert, Joe Touch, Dave Ward and Magnus Westerlund
	comments on this document.		for their comments on this document.
	The middlebox traversal guidelines in Section 3.5 incorporate ideas		The middlebox traversal guidelines in Section 3.5 incorporate ideas
	from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh		from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh
	and Dan Kegel.		and Dan Kegel.
	Lars Eggert is partly funded by [TRILOGY], a research project		Lars Eggert is partly funded by [TRILOGY], a research project
	supported by the European Commission under its Seventh Framework		supported by the European Commission under its Seventh Framework
	Program.		Program.
	8. References		8. References
	skipping to change at page 22, line 14		skipping to change at page 23, line 6
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,		[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
	RFC 2914, September 2000.		RFC 2914, September 2000.
	[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission		[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
	Timer", RFC 2988, November 2000.		Timer", RFC 2988, November 2000.
	[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
	Friendly Rate Control (TFRC): Protocol Specification",
	RFC 3448, January 2003.
	[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and		[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
	G. Fairhurst, "The Lightweight User Datagram Protocol		G. Fairhurst, "The Lightweight User Datagram Protocol
	(UDP-Lite)", RFC 3828, July 2004.		(UDP-Lite)", RFC 3828, July 2004.
	[RFC4787] Audet, F. and C. Jennings, "Network Address Translation		[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
	(NAT) Behavioral Requirements for Unicast UDP", BCP 127,		(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
	RFC 4787, January 2007.		RFC 4787, January 2007.
	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, March 2007.		Discovery", RFC 4821, March 2007.
			[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
			Friendly Rate Control (TFRC): Protocol Specification",
			RFC 5348, September 2008.
	8.2. Informative References		8.2. Informative References
	[FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in		[FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in
	TCP and Its Effect on Busy Servers", Proc. IEEE Infocom,		TCP and Its Effect on Busy Servers", Proc. IEEE Infocom,
	March 1999.		March 1999.
	[I-D.ford-behave-app]		[I-D.ford-behave-app]
	Ford, B., "Application Design Guidelines for Traversal		Ford, B., "Application Design Guidelines for Traversal
	through Network Address Translators",		through Network Address Translators",
	draft-ford-behave-app-05 (work in progress), March 2007.		draft-ford-behave-app-05 (work in progress), March 2007.
	[I-D.ietf-dccp-ccid4]		[I-D.ietf-dccp-ccid4]
	Floyd, S. and E. Kohler, "Profile for Datagram Congestion		Floyd, S. and E. Kohler, "Profile for Datagram Congestion
	Control Protocol (DCCP) Congestion ID 4: TCP-Friendly		Control Protocol (DCCP) Congestion ID 4: TCP-Friendly
	Rate Control for Small Packets (TFRC-SP)",		Rate Control for Small Packets (TFRC-SP)",
	draft-ietf-dccp-ccid4-02 (work in progress),		draft-ietf-dccp-ccid4-02 (work in progress),
	February 2008.		February 2008.
	[I-D.ietf-dccp-rfc3448bis]
	Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
	Friendly Rate Control (TFRC): Protocol Specification",
	draft-ietf-dccp-rfc3448bis-06 (work in progress),
	April 2008.
	[I-D.ietf-mmusic-ice]		[I-D.ietf-mmusic-ice]
	Rosenberg, J., "Interactive Connectivity Establishment		Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols",		Traversal for Offer/Answer Protocols",
	draft-ietf-mmusic-ice-19 (work in progress), October 2007.		draft-ietf-mmusic-ice-19 (work in progress), October 2007.
	[I-D.ietf-nsis-nslp-natfw]		[I-D.ietf-nsis-nslp-natfw]
	Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,		Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
	"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",		"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
	draft-ietf-nsis-nslp-natfw-18 (work in progress),		draft-ietf-nsis-nslp-natfw-19 (work in progress),
	February 2008.		September 2008.
	[I-D.ietf-nsis-ntlp]		[I-D.ietf-nsis-ntlp]
	Schulzrinne, H. and R. Hancock, "GIST: General Internet		Schulzrinne, H. and R. Hancock, "GIST: General Internet
	Signalling Transport", draft-ietf-nsis-ntlp-16 (work in		Signalling Transport", draft-ietf-nsis-ntlp-16 (work in
	progress), July 2008.		progress), July 2008.
	[POSIX] IEEE Std. 1003.1-2001, "Standard for Information		[POSIX] IEEE Std. 1003.1-2001, "Standard for Information
	Technology - Portable Operating System Interface (POSIX)",		Technology - Portable Operating System Interface (POSIX)",
	Open Group Technical Standard: Base Specifications Issue		Open Group Technical Standard: Base Specifications Issue
	6, ISO/IEC 9945:2002, December 2001.		6, ISO/IEC 9945:2002, December 2001.
	skipping to change at page 23, line 50		skipping to change at page 24, line 36
	[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host		[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
	Anycasting Service", RFC 1546, November 1993.		Anycasting Service", RFC 1546, November 1993.
	[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,		[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
	S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,		S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
	Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,		Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
	S., Wroclawski, J., and L. Zhang, "Recommendations on		S., Wroclawski, J., and L. Zhang, "Recommendations on
	Queue Management and Congestion Avoidance in the		Queue Management and Congestion Avoidance in the
	Internet", RFC 2309, April 1998.		Internet", RFC 2309, April 1998.
			[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
			and W. Weiss, "An Architecture for Differentiated
			Services", RFC 2475, December 1998.
	[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",		[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
	RFC 2675, August 1999.		RFC 2675, August 1999.
	[RFC2743] Linn, J., "Generic Security Service Application Program		[RFC2743] Linn, J., "Generic Security Service Application Program
	Interface Version 2, Update 1", RFC 2743, January 2000.		Interface Version 2, Update 1", RFC 2743, January 2000.
	[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,		[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
	Floyd, S., and M. Luby, "Reliable Multicast Transport		Floyd, S., and M. Luby, "Reliable Multicast Transport
	Building Blocks for One-to-Many Bulk-Data Transfer",		Building Blocks for One-to-Many Bulk-Data Transfer",
	RFC 3048, January 2001.		RFC 3048, January 2001.
	skipping to change at page 24, line 37		skipping to change at page 25, line 27
	RFC 3493, February 2003.		RFC 3493, February 2003.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, July 2003.		Applications", STD 64, RFC 3550, July 2003.
	[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and		[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
	Video Conferences with Minimal Control", STD 65, RFC 3551,		Video Conferences with Minimal Control", STD 65, RFC 3551,
	July 2003.		July 2003.
			[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
			Security Mechanism (GTSM)", RFC 3682, February 2004.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, March 2004.		RFC 3711, March 2004.
	[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate		[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
	Control (WEBRC) Building Block", RFC 3738, April 2004.		Control (WEBRC) Building Block", RFC 3738, April 2004.
	[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.		[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
	Conrad, "Stream Control Transmission Protocol (SCTP)		Conrad, "Stream Control Transmission Protocol (SCTP)
	Partial Reliability Extension", RFC 3758, May 2004.		Partial Reliability Extension", RFC 3758, May 2004.
End of changes. 19 change blocks.
	48 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/