draft-ietf-mmusic-rtsp-nat-evaluation-00.txt		draft-ietf-mmusic-rtsp-nat-evaluation-01.txt
	Network Working Group M. Westerlund		Network Working Group M. Westerlund
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational T. Zeng		Intended status: Informational T. Zeng
	Expires: December 31, 2007 June 29, 2007		Expires: January 12, 2009 July 11, 2008
	The evaluation of different NAT traversal Techniques for media		The evaluation of different NAT traversal Techniques for media
	controlled by Real-time Streaming Protocol (RTSP)		controlled by Real-time Streaming Protocol (RTSP)
	draft-ietf-mmusic-rtsp-nat-evaluation-00		draft-ietf-mmusic-rtsp-nat-evaluation-01
	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 34		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 December 31, 2007.		This Internet-Draft will expire on January 12, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes several NAT traversal techniques that could		This document describes several NAT traversal techniques that could
	be used by RTSP. Each technique includes a description on how it		be used by RTSP. Each technique includes a description on how it
	would be used, the security implications of using it and any other		would be used, the security implications of using it and any other
	deployment considerations it has. There are also disussions on how		deployment considerations it has. There are also disussions on how
	NAT traversal techniques relates to firewalls and how each technique		NAT traversal techniques relates to firewalls and how each technique
	can be applied in different use cases. These findings where used		can be applied in different use cases. These findings where used
	when selecting the NAT traversal for RTSP solution to standardize in		when selecting the NAT traversal for RTSP solution to standardize in
	skipping to change at page 2, line 27		skipping to change at page 2, line 26
	1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Detecting the loss of NAT mappings . . . . . . . . . . . . . . 7		2. Detecting the loss of NAT mappings . . . . . . . . . . . . . . 7
	3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 8		3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 8
	4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . . 9		4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . . 9
	4.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 10		4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 10
	4.1.2. Using STUN to traverse NAT without server		4.1.2. Using STUN to traverse NAT without server
	modifications . . . . . . . . . . . . . . . . . . . . 10		modifications . . . . . . . . . . . . . . . . . . . . 10
	4.1.3. Embedding STUN in RTSP . . . . . . . . . . . . . . . . 12		4.1.3. Embedding STUN in RTSP . . . . . . . . . . . . . . . . 12
	4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 13		4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 13
	4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 13		4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 14
	4.1.6. Deployment Considerations . . . . . . . . . . . . . . 14		4.1.6. Deployment Considerations . . . . . . . . . . . . . . 14
	4.1.7. Security Considerations . . . . . . . . . . . . . . . 16		4.1.7. Security Considerations . . . . . . . . . . . . . . . 16
	4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 16		4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 17
	4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 17		4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 17
	4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 19		4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 19
	4.2.4. Deployment Considerations . . . . . . . . . . . . . . 19		4.2.4. Deployment Considerations . . . . . . . . . . . . . . 20
	4.2.5. Security Consideration . . . . . . . . . . . . . . . . 20		4.2.5. Security Consideration . . . . . . . . . . . . . . . . 20
	4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 20		4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 20
	4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 20		4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 20
	4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 21		4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 21
	4.3.3. Deployment Considerations . . . . . . . . . . . . . . 21		4.3.3. Deployment Considerations . . . . . . . . . . . . . . 21
	4.3.4. Security Consideration . . . . . . . . . . . . . . . . 21		4.3.4. Security Consideration . . . . . . . . . . . . . . . . 22
	4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 23		4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 23
	4.4. Application Level Gateways . . . . . . . . . . . . . . . . 24		4.4. Application Level Gateways . . . . . . . . . . . . . . . . 25
	4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 24		4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 25
	4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 25		4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 25
	4.4.3. Deployment Considerations . . . . . . . . . . . . . . 26		4.4.3. Deployment Considerations . . . . . . . . . . . . . . 26
	4.4.4. Security Considerations . . . . . . . . . . . . . . . 26		4.4.4. Security Considerations . . . . . . . . . . . . . . . 27
	4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 26		4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 27
	4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 26		4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 27
	4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 27		4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 27
	4.5.3. Deployment Considerations . . . . . . . . . . . . . . 27		4.5.3. Deployment Considerations . . . . . . . . . . . . . . 28
	4.5.4. Security Considerations . . . . . . . . . . . . . . . 27		4.5.4. Security Considerations . . . . . . . . . . . . . . . 28
	4.6. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . . 28		4.6. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . . 28
	4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28		4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28
	4.6.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 28		4.6.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 29
	4.6.3. Deployment Considerations . . . . . . . . . . . . . . 29		4.6.3. Deployment Considerations . . . . . . . . . . . . . . 30
	4.6.4. Security Considerations . . . . . . . . . . . . . . . 30		4.6.4. Security Considerations . . . . . . . . . . . . . . . 30
	5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 31		5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	6. Comparision of NAT traversal techniques . . . . . . . . . . . 31		6. Comparision of NAT traversal techniques . . . . . . . . . . . 32
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 32		8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
	10. Informative References . . . . . . . . . . . . . . . . . . . . 33		10. Informative References . . . . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
	Intellectual Property and Copyright Statements . . . . . . . . . . 36		Intellectual Property and Copyright Statements . . . . . . . . . . 37
	1. Introduction		1. Introduction
	Today there is a proliferate deployment of different flavors of		Today there is a proliferate deployment of different flavors of
	Network Address Translator (NAT) boxes that in many cases only		Network Address Translator (NAT) boxes that in many cases only
	loosely follows standards[RFC3022][RFC2663][RFC3424]]. NATs cause		loosely follows standards[RFC3022][RFC2663][RFC3424]]. NATs cause
	discontinuity in address realms [RFC3424], therefore an application		discontinuity in address realms [RFC3424], therefore an application
	protocol, such as RTSP, needs to deal with such discontinuities		protocol, such as RTSP, needs to deal with such discontinuities
	caused by NATs. The problem is that, being a media control protocol		caused by NATs. The problem is that, being a media control protocol
	managing one or more media streams, RTSP carries network address and		managing one or more media streams, RTSP carries network address and
	port information within its protocol messages. Because of this, even		port information within its protocol messages. Because of this, even
	if RTSP itself, when carried over TCP for example, may not be blocked		if RTSP itself, when carried over TCP for example, may not be blocked
	by NATs, its media streams may be blocked by NATs. This will occur		by NATs, its media streams may be blocked by NATs. This will occur
	unless special protocol provisions are added to support NAT-		unless special protocol provisions are added to support NAT-
	traversal.		traversal.
	Like NATs, firewalls (FWs) are also middle boxes that need to be		Like NATs, firewalls (FWs) are also middle boxes that need to be
	considered. to prevent unwanted traffic from getting in or out of the		considered. Firewalls helps prevent unwanted traffic from getting in
	protected network. RTSP is designed such that a firewall can be		or out of the protected network. RTSP is designed such that a
	configured to let RTSP controlled media streams to go through with		firewall can be configured to let RTSP controlled media streams to go
	minimal implementation effort. The minimal effort is to implement an		through with minimal implementation effort. The minimal effort is to
	ALG (Application Level Gateway) to interpret RTSP parameters. There		implement an ALG (Application Level Gateway) to interpret RTSP
	is also a large class of firewalls, commonly home FWs, that uses a		parameters. There is also a large class of firewalls, commonly home
	similar filtering behavior to what NAT has. This type of firewalls		FWs, that uses a similar filtering behavior to what NAT has. This
	can be handled using the same solution as employed for NAT traversal		type of firewalls can be handled using the same solution as employed
	instead of relying on ALGs.		for NAT traversal instead of relying on ALGs.
	This document describes several NAT-traversal mechanisms for RTSP		This document describes several NAT-traversal mechanisms for RTSP
	controlled media streaming. These NAT solutions fall into the		controlled media streaming. These NAT solutions fall into the
	category of ""UNilateral Self-Address Fixing (UNSAF)" as defined in		category of ""UNilateral Self-Address Fixing (UNSAF)" as defined in
	[RFC3424] and quoted below:		[RFC3424] and quoted below:
	"UNSAF is a process whereby some originating process attempts to		"UNSAF is a process whereby some originating process attempts to
	determine or fix the address (and port) by which it is known - e.g.		determine or fix the address (and port) by which it is known - e.g.
	to be able to use address data in the protocol exchange, or to		to be able to use address data in the protocol exchange, or to
	advertise a public address from which it will receive connections."		advertise a public address from which it will receive connections."
	Following the guidelines spelled out in RFC 3424, we describe the		Following the guidelines spelled out in RFC 3424, we describe the
	required RTSP protocol extensions for each method, transition		required RTSP protocol extensions for each method, transition
	strategies, and security concerns.		strategies, and security concerns.
	This document is capturing the evaluation done in the process to		This document is capturing the evaluation done in the process to
	recommend FW/NAT traversal methods for RTSP streaming servers based		recommend FW/NAT traversal methods for RTSP streaming servers based
	on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec		on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec
	[I-D.ietf-mmusic-rfc2326bis].		[I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT
			traversal for the media streams carried over UDP [RFC0768]. Where
			RTP [RFC3550] over UDP being the main case for such usage. The
			findings should be applicable to other protocols as long as they have
			similar properties.
	1.1. Network Address Translators		1.1. Network Address Translators
	Readers are urged to refer to [RFC2663] for information on NAT		Readers are urged to refer to [RFC2663] for information on NAT
	taxonomy and terminology. Traditional NAT is the most common type of		taxonomy and terminology. Traditional NAT is the most common type of
	NAT device deployed. Readers may refer to [RFC3022] for detailed		NAT device deployed. Readers may refer to [RFC3022] for detailed
	information on traditional NAT. Traditional NAT has two main		information on traditional NAT. Traditional NAT has two main
	varieties -- Basic NAT and Network Address/Port Translator (NAPT).		varieties -- Basic NAT and Network Address/Port Translator (NAPT).
	NAPT is by far the most commonly deployed NAT device. NAPT allows		NAPT is by far the most commonly deployed NAT device. NAPT allows
	skipping to change at page 13, line 15		skipping to change at page 13, line 15
	If STUN server is co-located with RTSP server's media output port, an		If STUN server is co-located with RTSP server's media output port, an
	RTSP client using RTP transport over UDP can use STUN to traverse ALL		RTSP client using RTP transport over UDP can use STUN to traverse ALL
	types of NATs. In the case of port and address dependent mapping		types of NATs. In the case of port and address dependent mapping
	NATs, the party inside the NAT must initiate UDP traffic. The STUN		NATs, the party inside the NAT must initiate UDP traffic. The STUN
	Bind Request, being a UDP packet itself, can serve as the traffic		Bind Request, being a UDP packet itself, can serve as the traffic
	initiating packet. Subsequently, both the STUN Binding Response		initiating packet. Subsequently, both the STUN Binding Response
	packets and the RTP/RTCP packets can traverse the NAT, regardless of		packets and the RTP/RTCP packets can traverse the NAT, regardless of
	whether the RTSP server or the RTSP client is behind NAT.		whether the RTSP server or the RTSP client is behind NAT.
	Likewise, if an RTSP server is behind a NAT, then an embedded STUN		Likewise, if an RTSP server is behind a NAT, then an embedded STUN
	server must co-locate on the RTSP client's RTCP port. In this case,		server must co-locate on the RTSP client's RTCP port. Also it will
	we assume that the client has some means of establishing TCP		become the client that needs to disclose his destination address
	connection to the RTSP server behind NAT so as to exchange RTSP		rather than the server so that the server correctly can determine its
	messages with the RTSP server.		NAT external source address for the media streams. In this case, we
			assume that the client has some means of establishing TCP connection
			to the RTSP server behind NAT so as to exchange RTSP messages with
			the RTSP server.
	To minimize delay, we require that the RTSP server supporting this		To minimize delay, we require that the RTSP server supporting this
	option must inform its client the RTP and RTCP ports from where the		option must inform its client the RTP and RTCP ports from where the
	server intend to send out RTP and RTCP packets, respectively. This		server intend to send out RTP and RTCP packets, respectively. This
	can be done by using the "server_port" parameter in RFC2326, and the		can be done by using the "server_port" parameter in RFC2326, and the
	"src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in		"src_addr" parameter in [I-D.ietf-mmusic-rfc2326bis]. Both are in
	the RTSP Transport header. But in general this strategy will require		the RTSP Transport header. But in general this strategy will require
	that one first do one SETUP request per media to learn the server		that one first do one SETUP request per media to learn the server
	ports, then perform the STUN checks, followed by a subsequent SETUP		ports, then perform the STUN checks, followed by a subsequent SETUP
	to change the client port and destination address to what was learned		to change the client port and destination address to what was learned
	skipping to change at page 14, line 5		skipping to change at page 14, line 12
	different, but may not work as well with other media transport		different, but may not work as well with other media transport
	protocols.		protocols.
	4.1.5. ALG considerations		4.1.5. ALG considerations
	If a NAT supports RTSP ALG (Application Level Gateway) and is not		If a NAT supports RTSP ALG (Application Level Gateway) and is not
	aware of the STUN traversal option, service failure may happen,		aware of the STUN traversal option, service failure may happen,
	because a client discovers its public IP address and port numbers,		because a client discovers its public IP address and port numbers,
	and inserts them in its SETUP requests, when the RTSP ALG processes		and inserts them in its SETUP requests, when the RTSP ALG processes
	the SETUP request it may change the destination and port number,		the SETUP request it may change the destination and port number,
	resulting in unpredictable behavior. In such cases a convenient way		resulting in unpredictable behavior. In such cases two alternatives
	should be provided to turn off STUN-based NAT traversal.		exist:
			1. The usage of TLS to encrypt the RTSP TCP connection to prevent
			the ALG from reading and modifying the RTSP messages.
			2. To turn of the STUN based NAT traversal mechanism
			As it may be difficult to determine why the failure occurs, the usage
			of TLS protected RTSP message exchange at all times would avoid this
			issue.
	4.1.6. Deployment Considerations		4.1.6. Deployment Considerations
	For the non-embedded usage of STUN the following applies:		For the non-embedded usage of STUN the following applies:
	Advantages:		Advantages:
	o Using STUN does not require RTSP server modifications; it only		o Using STUN does not require RTSP server modifications; it only
	affects the client implementation.		affects the client implementation.
	Disadvantages:		Disadvantages:
	o Requires a STUN server deployed in the public address space.		o Requires a STUN server deployed in the public address space.
	o Only works with endpoint independent and address dependent		o Only works with NATs that perform endpoint independent and address
	mapping. Port and address dependent filtering NATs create some		dependent mappings. Port and address dependent filtering NATs
	issues.		create some issues.
	o Does not work with port and address dependent mapping NATs without		o Does not work with port and address dependent mapping NATs without
	server modifications.		server modifications.
	o Will mostly not work if a NAT uses multiple IP addresses, since		o Will mostly not work if a NAT uses multiple IP addresses, since
	RTSP server generally requires all media streams to use the same		RTSP server generally requires all media streams to use the same
	IP as used in the RTSP connection.		IP as used in the RTSP connection to prevent becoming a DDOS tool.
	o Interaction problems exist when a RTSP-aware ALG interferes with		o Interaction problems exist when a RTSP-aware ALG interferes with
	the use of STUN for NAT traversal.		the use of STUN for NAT traversal unless TLS secured RTSP message
			exchange is used.
	o Using STUN requires that RTSP servers and clients support the		o Using STUN requires that RTSP servers and clients support the
	updated RTSP specification, because it is no longer possible to		updated RTSP specification, because it is no longer possible to
	guarantee that RTP and RTCP ports are adjacent to each other, as		guarantee that RTP and RTCP ports are adjacent to each other, as
	required by the "client_port" and "server_port" parameters in		required by the "client_port" and "server_port" parameters in
	RFC2326.		RFC2326.
	Transition:		Transition:
	The usage of STUN can be phased out gradually as the first step of a		The usage of STUN can be phased out gradually as the first step of a
	skipping to change at page 15, line 44		skipping to change at page 16, line 12
	means more processing is required to de-multiplex STUN packets		means more processing is required to de-multiplex STUN packets
	from media packets. For example, the de-multiplexer must be able		from media packets. For example, the de-multiplexer must be able
	to differentiate a RTCP RR packet from a STUN packet, and forward		to differentiate a RTCP RR packet from a STUN packet, and forward
	the former to the streaming server, the later to STUN server.		the former to the streaming server, the later to STUN server.
	o Even if the RTSP server is in the open, and the client is behind a		o Even if the RTSP server is in the open, and the client is behind a
	multi-addressed NAT, it may still break if the RTSP server does		multi-addressed NAT, it may still break if the RTSP server does
	not allow RTP packets to be sent to an IP differs from the IP of		not allow RTP packets to be sent to an IP differs from the IP of
	the client's RTSP request.		the client's RTSP request.
	o Interaction problems exist when a RTSP ALG is not aware of STUN.		o Interaction problems exist when a RTSP ALG is not aware of STUN
			unless TLS is used to protect the RTSP messages.
	o Using STUN requires that RTSP servers and clients support the		o Using STUN requires that RTSP servers and clients support the
	updated RTSP specification, and they both agree to support the		updated RTSP specification, and they both agree to support the NAT
	proper feature tag.		traversal feature.
	o Increases the setup delay with at least the amount of time it		o Increases the setup delay with at least the amount of time it
	takes to perform STUN message exchanges. Most likely an extra		takes to perform STUN message exchanges. Most likely an extra
	SETUP sequence will be required.		SETUP sequence will be required.
	Transition:		Transition:
	The usage of STUN can be phased out gradually as the first step of a		The usage of STUN can be phased out gradually as the first step of a
	STUN capable machine can be to check the presence of NATs for the		STUN capable machine can be to check the presence of NATs for the
	presently used network connection. The removal of STUN capability in		presently used network connection. The removal of STUN capability in
	skipping to change at page 16, line 46		skipping to change at page 17, line 17
	messages to change media destination. This protects against		messages to change media destination. This protects against
	hijacking, however as a client can be the initiator of an attack,		hijacking, however as a client can be the initiator of an attack,
	these mechanisms cannot securely prevent RTSP servers being used as		these mechanisms cannot securely prevent RTSP servers being used as
	DoS attack tools.		DoS attack tools.
	4.2. ICE		4.2. ICE
	4.2.1. Introduction		4.2.1. Introduction
	ICE (Interactive Connectivity Establishment) [I-D.ietf-mmusic-ice] is		ICE (Interactive Connectivity Establishment) [I-D.ietf-mmusic-ice] is
	a methodology for NAT traversal that is under development for SIP		a methodology for NAT traversal that has been developed for SIP using
	using SDP offer/answer. The basic idea is to try, in a parallel		SDP offer/answer. The basic idea is to try, in a parallel fashion,
	fashion, all possible connection addresses that an end point may		all possible connection addresses that an end point may have. This
	have. This allows the end-point to use the best available UDP		allows the end-point to use the best available UDP "connection"
	"connection" (meaning two UDP end-points capable of reaching each		(meaning two UDP end-points capable of reaching each other). The
	other). The methodology has very nice properties in that basically		methodology has very nice properties in that basically all NAT
	all NAT topologies are possible to traverse.		topologies are possible to traverse.
	Here is how ICE works on a high level. End point A collects all		Here is how ICE works on a high level. End point A collects all
	possible address that can be used, including local IP addresses, STUN		possible address that can be used, including local IP addresses, STUN
	derived addresses, TURN addresses, etc. On each local port that any		derived addresses, TURN addresses, etc. On each local port that any
	of these address and port pairs leads to, a STUN server is installed.		of these address and port pairs leads to, a STUN server is installed.
	This STUN server only accepts STUN requests using the correct		This STUN server only accepts STUN requests using the correct
	authentication through the use of username and password.		authentication through the use of username and password.
	End-point A then sends a request to establish connectivity with end-		End-point A then sends a request to establish connectivity with end-
	point B, which includes all possible destinations to get the media		point B, which includes all possible destinations to get the media
	skipping to change at page 18, line 35		skipping to change at page 19, line 4
	server primary address.		server primary address.
	5. The connectivity checks are performed. For the server the		5. The connectivity checks are performed. For the server the
	connectivity checks from the server to the clients have an		connectivity checks from the server to the clients have an
	additional usage. They verify that there is someone willingly to		additional usage. They verify that there is someone willingly to
	receive the media, thus protecting itself from performing		receive the media, thus protecting itself from performing
	unknowingly an DoS attack.		unknowingly an DoS attack.
	6. Connectivity checks from the client's primary to the server's		6. Connectivity checks from the client's primary to the server's
	primary was successful. Thus no further SETUP requests are		primary was successful. Thus no further SETUP requests are
	necessary and processing can proceed with step 7. If the checks		necessary and processing can proceed with step 7. If another
	for the primary failed and If further candidates have been		address than the primary has been verified by the client to work,
	derived during the connectivity checks, then those can be		that address may then be promoted for usage in a SETUP request
	promoted in new candidate lines in SETUP request updating the		(Goto 7). If the checks for the availble candidates failed and
	list (Goto 5). If another address than the primary has been		If further candidates have been derived during the connectivity
	verified by the client to work, that address may then be promoted		checks, then those can be promoted in new candidate lines in
	for usage in a SETUP request (Goto 7).		SETUP request updating the list (Goto 5).
	7. Client issues PLAY request. If the server also has completed its		7. Client issues PLAY request. If the server also has completed its
	connectivity checks for this primary addresses (based on username		connectivity checks for this primary addresses (based on username
	as it may be derived addresses if the client was behind NAT) then		as it may be derived addresses if the client was behind NAT) then
	it can directly answer 200 OK (Goto 8). If the connectivity		it can directly answer 200 OK (Goto 8). If the connectivity
	check has not yet completed it responds with a 1xx code to		check has not yet completed it responds with a 1xx code to
	indicate that it is verifying the connectivity. If that fails		indicate that it is verifying the connectivity. If that fails
	within the set timeout an error is reported back. Client needs		within the set timeout an error is reported back. Client needs
	to go back to 6.		to go back to 6.
	skipping to change at page 20, line 5		skipping to change at page 20, line 20
	o Solves NAT connectivity discovery for basically all cases as long		o Solves NAT connectivity discovery for basically all cases as long
	as a TCP connection between them can be established. This		as a TCP connection between them can be established. This
	includes servers behind NATs. (Note that a proxy between address		includes servers behind NATs. (Note that a proxy between address
	domains may be required to get TCP through).		domains may be required to get TCP through).
	o Improves defenses against DDOS attacks, as media receiving client		o Improves defenses against DDOS attacks, as media receiving client
	requires authentications, via STUN on its media reception ports.		requires authentications, via STUN on its media reception ports.
	Disadvantages:		Disadvantages:
	Increases the setup delay with at least the amount of time it		o Increases the setup delay with at least the amount of time it
	takes for the server to perform its STUN requests.		takes for the server to perform its STUN requests.
	Assumes that it is possible to de-multiplex between media packets		o Assumes that it is possible to de-multiplex between media packets
	and STUN packets.		and STUN packets.
	Has fairly high implementation burden put on both RTSP server and		o Has fairly high implementation burden put on both RTSP server and
	client. The precise implantation complexity needs to be assessed		client.
	once ICE is fully defined as a standard. Currently ICE is still a
	protocol under development.
	4.2.5. Security Consideration		4.2.5. Security Consideration
	One should review the security consideration section of ICE and STUN		One should review the security consideration section of ICE and STUN
	to understand that ICE is contains some potential issues. However		to understand that ICE is contains some potential issues. However
	these can be avoided by a correctly utilizing ICE in RTSP. In fact		these can be avoided by a correctly utilizing ICE in RTSP. In fact
	ICE do help avoid the DDoS issue with RTSP substantially as it		ICE do help avoid the DDoS issue with RTSP substantially as it
	reduces the possibility for a DDoS using RTSP servers to attackers		reduces the possibility for a DDoS using RTSP servers to attackers
	that are on-path between the RTSP server and the target and capable		that are on-path between the RTSP server and the target and capable
	of intercepting the STUN connectivity check packets and correctly		of intercepting the STUN connectivity check packets and correctly
	skipping to change at page 23, line 16		skipping to change at page 23, line 28
	could be increased. To achieve a longer random tag while still using		could be increased. To achieve a longer random tag while still using
	RTP and RTCP, it will be necessary to develop RTP and RTCP payload		RTP and RTCP, it will be necessary to develop RTP and RTCP payload
	formats for carrying the random tag.		formats for carrying the random tag.
	4.3.5. A Variation to Symmetric RTP		4.3.5. A Variation to Symmetric RTP
	Symmetric RTP requires a valid RTP format in the FW packet, which is		Symmetric RTP requires a valid RTP format in the FW packet, which is
	the first packet that the client sends to the server to set up		the first packet that the client sends to the server to set up
	virtual RTP connection. There is currently no appropriate RTP packet		virtual RTP connection. There is currently no appropriate RTP packet
	format for this purpose, although the No-Op format is a proposal to		format for this purpose, although the No-Op format is a proposal to
	fix the problem [I-D.ietf-avt-rtp-no-op].		fix the problem [I-D.ietf-avt-rtp-no-op]. There exist a document
			that discusses the implication of different type of packets as keep-
			alives for RTP [I-D.ietf-avt-app-rtp-keepalive] and its findings are
			very relevant to the FW packet.
	Meanwhile, there has been FW traversal techniques deployed in the		Meanwhile, there has been FW traversal techniques deployed in the
	wireless streaming market place that use non-RTP messages as FW		wireless streaming market place that use non-RTP messages as FW
	packets. This section attempts to summarize a subset of those		packets. This section attempts to summarize a subset of those
	solutions that happens to use a variation to the standard symmetric		solutions that happens to use a variation to the standard symmetric
	RTP solution.		RTP solution.
	In this variation of symmetric RTP, the FW packet is a small UDP		In this variation of symmetric RTP, the FW packet is a small UDP
	packet that does not contain RTP header. Hence the solution can no		packet that does not contain RTP header. Hence the solution can no
	longer be called symmetric RTP, yet it employs the same technique for		longer be called symmetric RTP, yet it employs the same technique for
	skipping to change at page 23, line 47		skipping to change at page 24, line 14
	client's SSRC, and record the NAT bindings accordingly. The server		client's SSRC, and record the NAT bindings accordingly. The server
	then sends a FW packet as the response to the client.		then sends a FW packet as the response to the client.
	The FW packet can contain the SSRC to identify the RTP stream, and		The FW packet can contain the SSRC to identify the RTP stream, and
	can be made no bigger than 12 bytes, making it distinctively		can be made no bigger than 12 bytes, making it distinctively
	different from RTP packets, whose header size is 12 bytes.		different from RTP packets, whose header size is 12 bytes.
	RTSP signaling can be added to do the following:		RTSP signaling can be added to do the following:
	1. Enables or disables such FW message exchanges. When the FW/NAT		1. Enables or disables such FW message exchanges. When the FW/NAT
	has an RTSP-aware ALG, it is better to disable FW message		has an RTSP-aware ALG, it is possible to disable FW message
	exchange and let ALG works out the address and port mappings.		exchange and let ALG works out the address and port mappings.
	2. Configures the number of re-tries and the re-try interval of the		2. Configures the number of re-tries and the re-try interval of the
	FW message exchanges.		FW message exchanges.
	Such FW packets may also contain digital signatures to support three-		Such FW packets may also contain digital signatures to support three-
	way handshake based receiver authentications, so as to prevent DDoS		way handshake based receiver authentications, so as to prevent DDoS
	attacks described before.		attacks described before.
	This approach has the following advantages when compared with the		This approach has the following advantages when compared with the
	skipping to change at page 24, line 36		skipping to change at page 24, line 51
	1. RTP traffic is normally accompanied by RTCP traffic. This		1. RTP traffic is normally accompanied by RTCP traffic. This
	approach needs to rely on RTCP RRs and SRs to enable NAT		approach needs to rely on RTCP RRs and SRs to enable NAT
	traversal for RTCP endpoints, or use the same type of FW messages		traversal for RTCP endpoints, or use the same type of FW messages
	also for RTCP endpoints.		also for RTCP endpoints.
	2. The server's sender SSRC for the RTP stream must be signaled in		2. The server's sender SSRC for the RTP stream must be signaled in
	RTSP's SETUP response, in the Transport header of the RTSP SETUP		RTSP's SETUP response, in the Transport header of the RTSP SETUP
	response.		response.
			A solution with a 3-way handshaking and its own FW packets can be
			compared with ICE and have the following differencies:
			o Only works for servers with public IP addresses compared to any
			type of server
			o Is somewhat simpler to implement due to the avoidance of the ICE
			prioritization and checkboard mechanisms.
			However, a 3-way binding protocol is very similar to using STUN in
			both directions as binding protocol. Using STUN would remove the
			need for implementing a new protocol.
	4.4. Application Level Gateways		4.4. Application Level Gateways
	4.4.1. Introduction		4.4.1. Introduction
	An Application Level Gateway (ALG) reads the application level		An Application Level Gateway (ALG) reads the application level
	messages and performs necessary changes to allow the protocol to work		messages and performs necessary changes to allow the protocol to work
	through the middle box. However this behavior has some problems in		through the middle box. However this behavior has some problems in
	regards to RTSP:		regards to RTSP:
	1. It does not work when the RTSP protocol is used with end-to-end		1. It does not work when the RTSP protocol is used with end-to-end
	skipping to change at page 27, line 6		skipping to change at page 27, line 36
	4.5. TCP Tunneling		4.5. TCP Tunneling
	4.5.1. Introduction		4.5.1. Introduction
	Using a TCP connection that is established from the client to the		Using a TCP connection that is established from the client to the
	server ensures that the server can send data to the client. The		server ensures that the server can send data to the client. The
	connection opened from the private domain ensures that the server can		connection opened from the private domain ensures that the server can
	send data back to the client. To send data originally intended to be		send data back to the client. To send data originally intended to be
	transported over UDP requires the TCP connection to support some type		transported over UDP requires the TCP connection to support some type
	of framing of the RTP packets. Using TCP also results in that the		of framing of the media data packets. Using TCP also results in that
	client has to accept that real-time performance may no longer be		the client has to accept that real-time performance may no longer be
	possible. TCP's problem of ensuring timely deliver was the reasons		possible. TCP's problem of ensuring timely deliver was the reasons
	why RTP was developed. Problems that arise with TCP are: head-of-		why RTP was developed. Problems that arise with TCP are: head-of-
	line blocking, delay introduced by retransmissions, highly varying		line blocking, delay introduced by retransmissions, highly varying
	congestion control.		rate due to the congestion control algorithm.
	4.5.2. Usage of TCP tunneling in RTSP		4.5.2. Usage of TCP tunneling in RTSP
	The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports		The RTSP core specification [I-D.ietf-mmusic-rfc2326bis] supports
	interleaving of media data on the TCP connection that carries RTSP		interleaving of media data on the TCP connection that carries RTSP
	signaling. See section 10.13 in [I-D.ietf-mmusic-rfc2326bis] for how		signaling. See section 14 in [I-D.ietf-mmusic-rfc2326bis] for how to
	to perform this type of TCP tunneling. There is currently new		perform this type of TCP tunneling. There also exist another way of
	finished work on one more way of transporting RTP over TCP in AVT and		transporting RTP over TCP defined in Appendix . For signaling and
	MMUSIC. For signaling and rules on how to establish the TCP		rules on how to establish the TCP connection in lieu of UDP, see
	connection in lieu of UDP, see [RFC4091]. Another draft describes		appendix C.2 in [I-D.ietf-mmusic-rfc2326bis]. This is based on the
	how to frame RTP over the TCP connection is described in RFC 4571		framing of RTP over the TCP connection as described in RFC 4571
	[RFC4571].		[RFC4571].
	4.5.3. Deployment Considerations		4.5.3. Deployment Considerations
	Advantage:		Advantage:
	o Works through all types of NATs where server is in the open.		o Works through all types of NATs where server is in the open.
	Disadvantage:		Disadvantage:
	skipping to change at page 32, line 26		skipping to change at page 33, line 15
	| R1 | R2 | R3 | R4 | R5 |		| R1 | R2 | R3 | R4 | R5 |
	------------+------+------+------+------+------+		------------+------+------+------+------+------+
	STU | Yes | Yes | No | Maybe| No |		STU | Yes | Yes | No | Maybe| No |
	------------+------+------+------+------+------+		------------+------+------+------+------+------+
	ICE | Yes | Yes | No | No | Yes |		ICE | Yes | Yes | No | No | Yes |
	------------+------+------+------+------+------+		------------+------+------+------+------+------+
	SymRTP | Yes | Yes | Yes |Maybe | No |		SymRTP | Yes | Yes | Yes |Maybe | No |
	------------+------+------+------+------+------+		------------+------+------+------+------+------+
	V. SymRTP | Yes | Yes | Yes | Yes |future|		V. SymRTP | Yes | Yes | Yes | Yes |future|
	------------+------+------+------+------+------+		------------+------+------+------+------+------+
			3-W SymRTP | Yes | Yes | Yes | Maybe| Yes |
			------------+------+------+------+------+------+
	TURN | Yes | Yes | No | No | Yes |		TURN | Yes | Yes | No | No | Yes |
	------------------------------------------------		------------------------------------------------
			The different techniques was discussed in the MMUSIC WG. It was
			established that the WG would pursue an ICE based solution due to its
			generality and capability of handle also servers delivering media
			from behind NATs. There has been some discussion if the increased
			implementation burden of ICE is motivated compared to a 3-W SymRTP
			solution for this generality.
	7. IANA Considerations		7. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	8. Security Considerations		8. Security Considerations
	In preceding sessions we have discussed security merits of each and		In preceding sessions we have discussed security merits of each and
	every NAT/FW traversal methods for RTSP. In summary, the presence of		every NAT/FW traversal methods for RTSP discussed here. In summary,
	NAT(s) is a security risk, as a client cannot perform source		the presence of NAT(s) is a security risk, as a client cannot perform
	authentication of its IP address. This prevents the deployment of		source authentication of its IP address. This prevents the
	any future RTSP extensions providing security against hijacking of		deployment of any future RTSP extensions providing security against
	sessions by a man-in-the-middle.		hijacking of sessions by a man-in-the-middle.
	Each of the proposed solutions has security implications. Using STUN		Each of the proposed solutions has security implications. Using STUN
	will provide the same level of security as RTSP with out transport		will provide the same level of security as RTSP with out transport
	level security and source authentications; as long as the server does		level security and source authentications; as long as the server does
	not grant a client request to send media to different IP addresses.		not grant a client request to send media to different IP addresses.
	Using symmetric RTP will have a higher risk of session hijacking or		Using symmetric RTP will have a higher risk of session hijacking or
	denial of service than normal RTSP. The reason is that there exists		denial of service than normal RTSP. The reason is that there exists
	a probability that an attacker is able to guess the random tag that		a probability that an attacker is able to guess the random tag that
	the client uses to prove its identity when creating the address		the client uses to prove its identity when creating the address
	bindings. This can be solved in the variation of symmetric RTP		bindings. This can be solved in the variation of symmetric RTP
	skipping to change at page 33, line 34		skipping to change at page 34, line 32
	are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon,		are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon,
	Amir Wolf, Anders Klemets, and Colin Perkins. Thomas Zeng would also		Amir Wolf, Anders Klemets, and Colin Perkins. Thomas Zeng would also
	like to give special thanks to Greg Sherwood of PacketVideo for his		like to give special thanks to Greg Sherwood of PacketVideo for his
	input into this memo.		input into this memo.
	Section Section 1.1 contains text originally written for RFC 4787 by		Section Section 1.1 contains text originally written for RFC 4787 by
	Francois Audet and Cullen Jennings.		Francois Audet and Cullen Jennings.
	10. Informative References		10. Informative References
			[I-D.ietf-avt-app-rtp-keepalive]
			Marjou, X. and A. Sollaud, "Application Mechanism for
			maintaining alive the Network Address Translator (NAT)
			mappings associated to RTP flows.",
			draft-ietf-avt-app-rtp-keepalive-03 (work in progress),
			April 2008.
	[I-D.ietf-avt-rtp-no-op]		[I-D.ietf-avt-rtp-no-op]
	Andreasen, F., "A No-Op Payload Format for RTP",		Andreasen, F., "A No-Op Payload Format for RTP",
	draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.		draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
	[I-D.ietf-behave-rfc3489bis]		[I-D.ietf-behave-rfc3489bis]
	Rosenberg, J., "Session Traversal Utilities for (NAT)		Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
	(STUN)", draft-ietf-behave-rfc3489bis-06 (work in		"Session Traversal Utilities for (NAT) (STUN)",
	progress), March 2007.		draft-ietf-behave-rfc3489bis-16 (work in progress),
			July 2008.
	[I-D.ietf-behave-turn]		[I-D.ietf-behave-turn]
	Rosenberg, J., "Obtaining Relay Addresses from Simple		Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
	Traversal Underneath NAT (STUN)",		Relays around NAT (TURN): Relay Extensions to Session
	draft-ietf-behave-turn-03 (work in progress), March 2007.		Traversal Utilities for NAT (STUN)",
			draft-ietf-behave-turn-08 (work in progress), June 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-16 (work in progress), June 2007.		draft-ietf-mmusic-ice-19 (work in progress), October 2007.
	[I-D.ietf-mmusic-rfc2326bis]		[I-D.ietf-mmusic-rfc2326bis]
	Schulzrinne, H., "Real Time Streaming Protocol 2.0		Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
	(RTSP)", draft-ietf-mmusic-rfc2326bis-15 (work in		and M. Stiemerling, "Real Time Streaming Protocol 2.0
	progress), June 2007.		(RTSP)", draft-ietf-mmusic-rfc2326bis-18 (work in
			progress), May 2008.
			[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
			August 1980.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time		[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
	Streaming Protocol (RTSP)", RFC 2326, April 1998.		Streaming Protocol (RTSP)", RFC 2326, April 1998.
	[RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588,		[RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588,
	May 1999.		May 1999.
	skipping to change at page 34, line 51		skipping to change at page 36, line 14
	[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,		[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
	"STUN - Simple Traversal of User Datagram Protocol (UDP)		"STUN - Simple Traversal of User Datagram Protocol (UDP)
	Through Network Address Translators (NATs)", RFC 3489,		Through Network Address Translators (NATs)", RFC 3489,
	March 2003.		March 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.
	[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network
	Address Types (ANAT) Semantics for the Session Description
	Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, July 2006.		Description Protocol", RFC 4566, July 2006.
	[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)		[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
	and RTP Control Protocol (RTCP) Packets over Connection-		and RTP Control Protocol (RTCP) Packets over Connection-
	Oriented Transport", RFC 4571, July 2006.		Oriented Transport", RFC 4571, July 2006.
	[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.
	skipping to change at page 36, line 7		skipping to change at page 37, line 7
	Thomas Zeng		Thomas Zeng
	Phone:		Phone:
	Fax:		Fax:
	Email: thomas.zeng@gmail.com		Email: thomas.zeng@gmail.com
	URI:		URI:
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	skipping to change at page 36, line 44		skipping to change at line 1700
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 44 change blocks.
	103 lines changed or deleted		149 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/