draft-ietf-mmusic-latching-01.txt		draft-ietf-mmusic-latching-02.txt
	Network Working Group E. Ivov		Network Working Group E. Ivov
	Internet-Draft Jitsi		Internet-Draft Jitsi
	Intended status: Informational H. Kaplan		Intended status: Informational H. Kaplan
	Expires: November 08, 2013 Acme Packet		Expires: December 12, 2013 Acme Packet
	D. Wing		D. Wing
	Cisco		Cisco
	May 07, 2013		June 10, 2013
	Latching: Hosted NAT Traversal (HNT) for Media in Real-Time		Latching: Hosted NAT Traversal (HNT) for Media in Real-Time
	Communication		Communication
	draft-ietf-mmusic-latching-01		draft-ietf-mmusic-latching-02
	Abstract		Abstract
	This document describes behavior of signalling intermediaries in		This document describes behavior of signalling intermediaries in
	Real-Time Communication (RTC) deployments, sometimes referred to as		Real-Time Communication (RTC) deployments, sometimes referred to as
	Session Border Controllers (SBCs), when performing Hosted NAT		Session Border Controllers (SBCs), when performing Hosted NAT
	Traversal (HNT). HNT is a set of mechanisms, such as media relaying		Traversal (HNT). HNT is a set of mechanisms, such as media relaying
	and latching, that such intermediaries use to enable other RTC		and latching, that such intermediaries use to enable other RTC
	devices behind NATs to communicate with each other. This document is		devices behind NATs to communicate with each other. This document is
	non-normative, and is only written to explain HNT in order to provide		non-normative, and is only written to explain HNT in order to provide
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 08, 2013.		This Internet-Draft will expire on December 12, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 4		3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5
	4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 5		4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. Informative References . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Network Address Translators (NATs) are widely used in the Internet by		Network Address Translators (NATs) are widely used in the Internet by
	consumers and organizations. Although specific NAT behaviors vary,		consumers and organizations. Although specific NAT behaviors vary,
	this document uses the term "NAT" for devices that map any IPv4 or		this document uses the term "NAT" for devices that map any IPv4 or
	IPv6 address and transport port number to another IPv4 or IPv6		IPv6 address and transport port number to another IPv4 or IPv6
	address and transport port number. This includes consumer NATs,		address and transport port number. This includes consumer NATs,
	Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs, etc.		Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs, etc.
	skipping to change at page 2, line 48		skipping to change at page 3, line 8
	Protocols like SIP [RFC3261], and others that try to use a more		Protocols like SIP [RFC3261], and others that try to use a more
	direct path for media than with signalling, are difficult to use		direct path for media than with signalling, are difficult to use
	across NATs. They use IP addresses and transport port numbers		across NATs. They use IP addresses and transport port numbers
	encoded in bodies such as SDP [RFC4566] as well as, in the case of		encoded in bodies such as SDP [RFC4566] as well as, in the case of
	SIP, various header fields. Such addresses and ports are unusable		SIP, various header fields. Such addresses and ports are unusable
	unless all peers in a session are located behind the same NAT.		unless all peers in a session are located behind the same NAT.
	Mechanisms such as Session Traversal Utilities for NAT (STUN)		Mechanisms such as Session Traversal Utilities for NAT (STUN)
	[RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and		[RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and
	Interactive Connectivity Establishment (ICE) [RFC5245] did not exist		Interactive Connectivity Establishment (ICE) [RFC5245] did not exist
	when protocols like SIP began being deployed. Session Border		when protocols like SIP began being deployed. Some mechanisms, such
	Controllers (SBCs) that were already being used by SIP domains for		as the early versions of STUN [RFC3489], had started appearing but
	other SIP and media-related purposes began to use proprietary		they were unreliable and suffered a number of issues typical for
	mechanisms to enable SIP devices behind NATs to communicate across		UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424].
	the NATs.		For these and other reasons, Session Border Controllers (SBCs) that
			were already being used by SIP domains for other SIP and media-
			related purposes began to use proprietary mechanisms to enable SIP
			devices behind NATs to communicate across the NATs.
	The term often used for this behavior is Hosted NAT Traversal (HNT),		The term often used for this behavior is Hosted NAT Traversal (HNT),
	although some manufacturers sometimes use other names such as "Far-		although some manufacturers sometimes use other names such as "Far-
	end NAT Traversal" or "NAT assist" instead. The systems which		end NAT Traversal" or "NAT assist" instead. The systems which
	perform HNT are frequently SBCs as described in [RFC5853], although		perform HNT are frequently SBCs as described in [RFC5853], although
	other systems such as media gateways and "media proxies" sometimes		other systems such as media gateways and "media proxies" sometimes
	perform the same role. For the purposes of this document, all such		perform the same role. For the purposes of this document, all such
	systems are referred to as SBCs, and the NAT traversal behavior is		systems are referred to as SBCs, and the NAT traversal behavior is
	called HNT.		called HNT.
	skipping to change at page 3, line 47		skipping to change at page 4, line 18
	The SIP signaling-layer component of HNT is typically more		The SIP signaling-layer component of HNT is typically more
	implementation-specific and deployment-specific than the SDP and		implementation-specific and deployment-specific than the SDP and
	media components. For the purposes of this document it is hence		media components. For the purposes of this document it is hence
	assumed that signaling intermediaries handle traffic in way that		assumed that signaling intermediaries handle traffic in way that
	allows protocols such as SIP to function correctly across the NATs.		allows protocols such as SIP to function correctly across the NATs.
	The rest of this document is going to focus primarily on use of HNT		The rest of this document is going to focus primarily on use of HNT
	for SIP. However, the mechanisms described here are relatively		for SIP. However, the mechanisms described here are relatively
	generic and are often used with other protocols, such as XMPP		generic and are often used with other protocols, such as XMPP
	[RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/		[RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/
	MEGACO [RFC3015], and H.323 [H.323].		MEGACO [RFC5125], and H.323 [H.323].
	2. Background		2. Background
	The general problems with NAT traversal for protocols such as SIP		The general problems with NAT traversal for protocols such as SIP
	are:		are:
	1. The addresses and port numbers encoded in SDP bodies (or their		1. The addresses and port numbers encoded in SDP bodies (or their
	equivalents) by NATed User Agents (UAs) are not usable across the		equivalents) by NATed User Agents (UAs) are not usable across the
	Internet, because they represent the private network addressing		Internet, because they represent the private network addressing
	information of the UA rather than the addresses/ports that will		information of the UA rather than the addresses/ports that will
	skipping to change at page 5, line 6		skipping to change at page 5, line 25
	3. Impact on Signaling		3. Impact on Signaling
	Along with codec and other media-layer information, session		Along with codec and other media-layer information, session
	establishment signaling also conveys, potentially private and non-		establishment signaling also conveys, potentially private and non-
	globally routable addressing information. Signaling intermediaries		globally routable addressing information. Signaling intermediaries
	would hence modify such information so that peer UAs are given the		would hence modify such information so that peer UAs are given the
	(public) addressing information of a media relay controlled by the		(public) addressing information of a media relay controlled by the
	intermediary.		intermediary.
	Quite often, the IP address of the newly introduced media relay may		Quite often, the IP address of the newly introduced media relay may
	be the same as that of the signaling intermediary (e.g. the SIP SBC)		be the same as that of the signaling intermediary (e.g. the SIP SBC)
	or it may be a completely different one. In almost all cases		or it may be a completely different one. In almost all cases
	however, the new address would belong to the same IP address family		however, the new address would belong to the same IP address family
	as the one used for signaling, since it is known to work for that UA.		as the one used for signaling, since it is known to work for that UA.
	The port numbers introduced in the signaling by the intermediary are		The port numbers introduced in the signaling by the intermediary are
	typically allocated dynamically. Allocation strategies are entirely		typically allocated dynamically. Allocation strategies are entirely
	implementation dependent and they often vary from one product to the		implementation dependent and they often vary from one product to the
	next.		next.
	The offer/answer media negotiation model [RFC3264] is such that once		The offer/answer media negotiation model [RFC3264] is such that once
	skipping to change at page 6, line 34		skipping to change at page 6, line 50
	traffic would belong to the public interface of the NAT in front		traffic would belong to the public interface of the NAT in front
	of the UA and anything that the relay sends there would find its		of the UA and anything that the relay sends there would find its
	way to it.		way to it.
	5. Similarly the source of the stream originating at the remote		5. Similarly the source of the stream originating at the remote
	party would be latched upon and used for media going in that		party would be latched upon and used for media going in that
	direction.		direction.
	6. Latching is usually done only once per peer and not allowed to		6. Latching is usually done only once per peer and not allowed to
	change or cause a re-latching until a new offer and answer get		change or cause a re-latching until a new offer and answer get
	exchanged (e.g. in a subsequent call or after a SIP peer has		exchanged (e.g. in a subsequent call or after a SIP peer has gone
	gone on and off hold). The reasons for such restrictions are		on and off hold). The reasons for such restrictions are mostly
	mostly related to security: once a session has started a user		related to security: once a session has started a user agent is
	agent is not expected to suddenly start streaming from a		not expected to suddenly start streaming from a different port
	different port without sending a new offer first. A change may		without sending a new offer first. A change may indicate an
	indicate an attempt to hijack the session. In some cases		attempt to hijack the session. In some cases however, a port
	however, a port change may be caused by a re-mapping in a NAT		change may be caused by a re-mapping in a NAT device standing
	device standing between the SBC and the UA. More advanced SBCs		between the SBC and the UA. More advanced SBCs may therefore
	may therefore allow some level of flexibility on the re-latching		allow some level of flexibility on the re-latching restrictions
	restrictions while carefully considering the potential security		while carefully considering the potential security implications
	implications of doing so.		of doing so.
	Figure 2 describes how latching occurs for SIP where HNT is provided		Figure 2 describes how latching occurs for SIP where HNT is provided
	by an SBC connected to two networks: 203.0.113/24 facing towards the		by an SBC connected to two networks: 203.0.113/24 facing towards the
	User Agent Client (UAC) network and 198.51.100/24 facing towards the		User Agent Client (UAC) network and 198.51.100/24 facing towards the
	User Agent Server (UAS) network.		User Agent Server (UAS) network.
	192.0.2.1 198.51.100.33		192.0.2.1 198.51.100.33
	Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 Bob		Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 Bob
	------- --- --- -------		------- --- --- -------
	| | | |		| | | |
	1. |--SIP INVITE+offer c=192.0.2.1--->| |		1. |--SIP INVITE+offer c=192.0.2.1--->| |
	| | | |		| | | |
	2. | | (SBC allocates 198.51.100.2:22007 |		2. | | (SBC allocates 198.51.100.2:22007 |
	| | for inbound RTP from UAS) |		| | for inbound RTP from UAS) |
	| | | |		| | | |
	3. | | |---INVITE+offer---->|		3. | | |---INVITE+offer---->|
	| | |c=198.51.100.2:22007|		| | |c=198.51.100.2:22007|
	| | | |		| | | |
	4. | | |<---180 Ringing-----|		4. | | |<---180 Ringing-----|
	| | | |		| | | |
	| | | |		| | | |
	5. |<------180 Ringing----------------| |		5. |<------180 Ringing----------------| |
	| | | |		| | | |
	6. | | |<---200+answer------|		6. | | |<---200+answer------|
	| | | |		| | | |
	7. | | (SBC allocates 203.0.113.4:36010 |		7. | | (SBC allocates 203.0.113.4:36010 |
	| | for inbound RTP from UAC) |		| | for inbound RTP from UAC) |
	| | | |		| | | |
	8. |<-200+answer,c=203.0.113.4:36010--| c=198.51.100.33 |		8. |<-200+answer,c=203.0.113.4:36010--| c=198.51.100.33 |
	| | | |		| | | |
	9. |------------ACK------------------>| |		9. |------------ACK------------------>| |
	10. | | |-------ACK--------->|		10. | | |-------ACK--------->|
	| | | |		| | | |
	11. |=====RTP,dest=203.0.113.4:36010==>| |		11. |=====RTP,dest=203.0.113.4:36010==>| |
	| | | |		| | | |
	12. | | (SBC latches to |		12. | | (SBC latches to |
	| | source IP address and |		| | source IP address and |
	| | port seen at (10)) |		| | port seen at (10)) |
	| | | |		| | | |
	13. | | |<====== RTP ========|		13. | | |<====== RTP ========|
	| | | |		| | | |
	14. |<=====RTP, to latched address=====| |		14. |<=====RTP, to latched address=====| |
	| | | |		| | | |
	Figure 2: Latching by a SIP SBC across two interfaces		Figure 2: Latching by a SIP SBC across two interfaces
	While XMPP implementations often rely on ICE to handle NAT traversal,		While XMPP implementations often rely on ICE to handle NAT traversal,
	there are some that also support a non-ICE transport called XMPP		there are some that also support a non-ICE transport called XMPP
	Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how		Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how
	latching occurs for one such XMPP implementation where HNT is		latching occurs for one such XMPP implementation where HNT is
	provided by an XMPP server on the public internet.		provided by an XMPP server on the public internet.
	192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8		192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8
	XMPP Client1 NAT XMPP Server XMPP Client2		XMPP Client1 NAT XMPP Server XMPP Client2
	------- --- --- -------		----- --- --- -----
	| | | |		| | | |
	1. |----session-initiate cand=192.0.2.1--->| |		1. |----session-initiate cand=192.0.2.1--->| |
	| | | |		| | | |
	2. |<------------ack-----------------------| |		2. |<------------ack-----------------------| |
	| | | |		| | | |
	3. | | (Server allocates 203.0.113.9:2200 |		3. | | (Server allocates 203.0.113.9:2200 |
	| | for inbound RTP from Client2) |		| | for inbound RTP from Client2) |
	| | | |		| | | |
	4. | | |--session-initiate->|		4. | | |--session-initiate->|
	| | cand=203.0.113.9:2200|		| | cand=203.0.113.9:2200|
	| | | |		| | | |
	5. | | |<-------ack---------|		5. | | |<-------ack---------|
	| | | |		| | | |
	| | | |		| | | |
	6. | | |<--session-accept---|		6. | | |<--session-accept---|
	| | | cand=198.51.100.8 |		| | | cand=198.51.100.8 |
	| | | |		| | | |
	7. | | |--------ack-------> |		7. | | |--------ack-------> |
	| | | |		| | | |
	8. | | (Server allocates 203.0.113.9:3300 |		8. | | (Server allocates 203.0.113.9:3300 |
	| | for inbound RTP from Client1) |		| | for inbound RTP from Client1) |
	| | | |		| | | |
	9. |<-session-accept cand=203.0.113.9:3300-| |		9. |<-session-accept cand=203.0.113.9:3300-| |
	| | | |		| | | |
	10. |-----------------ack------------------>| |		10. |-----------------ack------------------>| |
	| | | |		| | | |
	| | | |		| | | |
	11. |======RTP, dest=203.0.113.9:3300======>| |		11. |======RTP, dest=203.0.113.9:3300======>| |
	| | | |		| | | |
	12. | | (XMPP server latches to |
	| | src IP 203.0.113.4 and |		12. | | (XMPP server latches to |
	| | src port seen at (10)) |		| | src IP 203.0.113.4 and |
	| | | |		| | src port seen at (10)) |
	13. | | |<====== RTP ========|		| | | |
	| | | |		13. | | |<====== RTP ========|
	14. |<======RTP, to latched address=========| |		| | | |
	| | | |		14. |<======RTP, to latched address=========| |
			| | | |
	Figure 3: Latching by a SIP SBC across two interfaces		Figure 3: Latching by a SIP SBC across two interfaces
	The above is a general description, and some details vary between		The above is a general description, and some details vary between
	implementations or configuration settings. For example, some		implementations or configuration settings. For example, some
	intermediaries perform additional logic before latching on received		intermediaries perform additional logic before latching on received
	packet source information to prevent malicious attacks or latching		packet source information to prevent malicious attacks or latching
	erroneously to previous media senders - often called "rogue-rtp" in		erroneously to previous media senders - often called "rogue-rtp" in
	the industry.		the industry.
	skipping to change at page 12, line 36		skipping to change at page 12, line 50
	Note to the RFC-Editor: please remove this section prior to		Note to the RFC-Editor: please remove this section prior to
	publication as an RFC.		publication as an RFC.
	7. Acknowledgements		7. Acknowledgements
	The authors would like to thank Flemming Andreasen, Miguel A.		The authors would like to thank Flemming Andreasen, Miguel A.
	Garcia, Ari Keraenen and Paul Kyzivat for their reviews and		Garcia, Ari Keraenen and Paul Kyzivat for their reviews and
	suggestions on improving this document.		suggestions on improving this document.
	8. References		8. Informative References
	8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	8.2. Informative References
	[H.323] International Telecommunication Union , "Packet Based		[H.323] International Telecommunication Union , "Packet Based
	Multimedia Communication Systems", Recommendation H.323,		Multimedia Communication Systems", Recommendation H.323,
	July 2003.		July 2003.
	[RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen,
	B., and J. Segers, "Megaco Protocol Version 1.0", RFC
	3015, November 2000.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	with Session Description Protocol (SDP)", RFC 3264, June		with Session Description Protocol (SDP)", RFC 3264, June
	2002.		2002.
			[RFC3424] Daigle, L. IAB, "IAB Considerations for UNilateral Self-
			Address Fixing (UNSAF) Across Network Address
			Translation", RFC 3424, November 2002.
	[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control		[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control
	Protocol (MGCP) Version 1.0", RFC 3435, January 2003.		Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
			[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
			"STUN - Simple Traversal of User Datagram Protocol (UDP)
			Through Network Address Translators (NATs)", RFC 3489,
			March 2003.
	[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.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474, August 2006.		Initiation Protocol (SIP)", RFC 4474, August 2006.
	[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.
	[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.
			[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic",
			RFC 5125, February 2008.
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment		[RFC5245] 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", RFC 5245, April		Traversal for Offer/Answer Protocols", RFC 5245, April
	2010.		2010.
	[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,		[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
	"Session Traversal Utilities for NAT (STUN)", RFC 5389,		"Session Traversal Utilities for NAT (STUN)", RFC 5389,
	October 2008.		October 2008.
	[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
End of changes. 17 change blocks.
	116 lines changed or deleted		119 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/