draft-aoun-nsis-nslp-natfw-migration-00.txt		draft-aoun-nsis-nslp-natfw-migration-01.txt
	NSIS Working Group C. Aoun		NSIS Working Group C. Aoun
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: April 20, 2004 M. Brunner		Expires: August 16, 2004 M. Brunner
	M. Stiemerling		M. Stiemerling
	M. Martin		M. Martin
	NEC		NEC
	H. Tschofenig		H. Tschofenig
	Siemens		Siemens
	October 21, 2003		February 16, 2004
	NATFirewall NSLP migration and intra-realm communication		NAT/Firewall NSLP Migration Considerations
	considerations		draft-aoun-nsis-nslp-natfw-migration-01
	draft-aoun-nsis-nslp-natfw-migration-00
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 36		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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 April 20, 2004.		This Internet-Draft will expire on August 16, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document discusses NAT/FW migration to support the NSIS NAT/FW		This document discusses migration issues towards NSIS NAT/FW NSLP
	NSLP as well as intra-realm communications considerations. The		enabled NATs and Firewalls. The document will serve as input to the
	document will serve as input to the NSIS NATFW NSLP document.		NSIS NATFW NSLP document.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. NSIS Responder address selection for intra realm
	communications optimization . . . . . . . . . . . . . . . 4
	2.1 Potential solutions to the problem . . . . . . . . . . . . 5
	2.1.1 Intra realm solution protocol operation impacts . . . . . 7
	2.1.2 Intra realm solution application protocols impacts . . . . 7
	3. NATFW NSLP migration analysis . . . . . . . . . . . . . . 8
	3.1 Global scoped address determination with NSIS unaware
	NATs . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2 Analysis of unilateral NSIS signaling . . . . . . . . . . 13
	3.3 Co-existence with existing NAT traversal mechanisms . . . 19
	3.4 NSIS protocol traversal of NSIS Unaware Firewalls and
	NATs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	3.4.1 NSIS protocol traversal of NSIS Unaware Firewalls . . . . 20
	3.4.1.1 NSIS protocol traversal of a mix of NSIS Unaware
	Firewalls and NSIS aware NATs . . . . . . . . . . . . . . 21
	3.4.1.2 NSIS protocol traversal of NSIS Unaware NATs . . . . . . . 22
	4. NATFW NSLP NTLP requirements . . . . . . . . . . . . . . . 23
	5. Security Considerations . . . . . . . . . . . . . . . . . 24
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . 25
	7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 26
	Normative References . . . . . . . . . . . . . . . . . . . 27
	Informative References . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . 29
	Intellectual Property and Copyright Statements . . . . . . 31
	1. Introduction
	Whether interim NAT and Firewall traversal mechanisms will already be
	deployed in networks or not, it is important to understand NSIS NATFW
	NSLP co-existence with non-NSIS aware NATs and Firewalls until their
	migration to NSIS would have been accomplished. The NSIS NATFW NSLP
	responder provides the NSIS NATFW NSLP Initiator with its address, in
	some cases the NSIS responder may have several addresses: a (or
	several) global scoped address and its locally scoped address(es).
	Which address does it provide to the NSIS initiator? This document
	will cover both the above issues and serve as input to the NSIS NATFW
	NSLP main document.
	2. NSIS Responder address selection for intra realm communications
	optimization
	An NSIS Element hosting an NSIS NATFW NSLP may have more than one
	address, its local scoped address(es) and global scoped address(es).
	A default address selection that priorities arbitrarily a global
	scoped address over a local scoped address may imply none optimal
	routing for communications between NSIS elements hosted within the
	same addressing realm.
	In Figure 1 the arbitrary selection of the global scoped address,
	works properly to receive NSIS signaling from Host B. However in
	deployment scenario shown in Figure 2, host A and host C end-up
	communicating through their local MB1 middlebox resulting in a non
	optimal data path with all its implications (additional delay,
	additional bandwidth in certain parts of the network infrastructure,
	etc ...).
	+---------------------+ +--------------------+
	| | | |
	| Host A | ,-----------. | Host B |
	| +-----+| ,-'The NET `-. | |
	| | MB1 |+-- --+ |
	| +-----+| `-. ,-' | |
	| | `-----------' | |
	| | | |
	+---------------------+ +--------------------+
	MB: Middle box (NAT or Firewall or a combination)
	Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Figure 1
	+---------------------+ +--------------------+
	| | | |
	| Host A`-. | ,-----------. | Host B |
	| `. +-----+| ,-'The NET `-. | |
	| i.. MB1 |+-- --+ |
	| Host C_.-'' +-----+| `-. ,-' | |
	| | `-----------' | |
	| | | |
	+---------------------+ +--------------------+
	MB: Middle box (NAT or Firewall or a combination)
	Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Host C: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Figure 2
	2.1 Potential solutions to the problem
	There are two ways to deal with this non-optimal routing of packets
	for intra-realm communications between NSIS entities. The NSIS
	Responder should either:
	1. Decide based on local decision, which address to provide to the
	NI to signal it or,
	2. Let the far end NSIS Initiator decide which address to select
	based on the NSIS Responder's provided addresses
	(1) lets the NSIS Responder decide on its own, which address to
	provide based on certain hints, which may not be the most optimal
	decision since the NSIS Responder may not have sufficient knowledge
	about the NSIS Initiator at the time of delivering its address to the
	responder. In most cases none arbitrary local decision for address
	selection requires to know about the far end host, which is not
	always practical.
	An example of such local based address selection is the IPv6 default		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	address selection mechanism ([2]) where an IPv6 (or IPv6/v4) node has
	to select which source and destination address to pick in order to
	communicate with a far end node. The mechanism relies on receiving
	input from the local resolver (DNS client or local hosts file) about
	the far end node . In the context of multimedia applications (and
	probably others as well), the NSIS Initiator is provided the NSIS
	Responder contact information (includes IP address and transport port
	[1] via the user application protocols (example: SIP, H.323 etc ...).
	Within that specific context, the NSIS Responder does not have
	sufficient information about the NSIS Initiator to provide it a valid
	address.
	Hence it can not decide successfully in all cases which address to		3. NSIS unaware NAT Traversal . . . . . . . . . . . . . . . . . . 5
	provide to the NSIS Initiator. Hence (2) is more efficient as it
	requires the NSIS Responder to provide all its addresses (local
	scoped and global scoped ones) to the NSIS Initiator. As a result,
	the NSIS Initiator will need to decide on which address to signal the
	NSIS Responder among all the provided ones. One possible way for the
	NSIS Initiator to decide from which address it will send NSIS
	signaling to the NSIS Responder and which NSIS Responder address to
	use is to check on which address the NSIS responder will reply back.
	An existing proposal [3] discusses the usage of (2) for SIP User
	Agents (SIP UA), the SIP UA will probe the far end SIP UA to see from
	which address it will response back. In [3], the STUN protocol [7] is
	used to check the responsiveness of the far end host. In [6], the
	reverse routability used to check which address to respond to
	counters RTP DOS attacks. The same required reverse routability could
	be achieved by the NSIS NATFW NSLP.
	****Include message sequences in the next iteration of the		4. Unilateral NSIS signaling . . . . . . . . . . . . . . . . . . 8
	discussion*******
	In the context of NSIS, the NSIS protocol itself should be used as		5. NSIS unaware Firewall Traversal . . . . . . . . . . . . . . . 13
	the probing mechanism.
	Consequently the NSIS Initiator will send simultaneously several NSIS
	messages towards the NSIS Responder, one message per provided
	address.
	The following occur during the process:
	o In case the NSIS Responder and Initiator are located within the		6. NATFW NSLP NTLP requirements . . . . . . . . . . . . . . . . . 14
	same addressing realm, the NSIS Responder should receive a
	response from all the addresses to which it has sent NSIS
	messages. The NSIS Initiator will then choose the local scoped
	address as the destination address for messages destined to the
	NSIS Responder.
	o In case the NSIS Responder and Initiator are not located within		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	the same addressing realm, the NSIS Initiator would only receive a
	response from the valid global scope address. In event that there
	is another NE within the network that has the same local scoped
	address as the originally targeted NSIS Responder, the wrongly
	targeted NSIS Responder should send back an error or discard the
	message (the later would be preferable).
	2.1.1 Intra realm solution protocol operation impacts		8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
	As opposed to the normal NSIS mode of operation, an NI that has		Normative References . . . . . . . . . . . . . . . . . . . . . 17
	already a security association with the neighboring NE on the path to
	a specific NR would need to verify that the target local scoped NR
	address is the same as one already cached in its NSIS neighbor table
	cache (association of Next hop NE with the target NR table).This
	would be required to avoid any confusion with an NSIS node that could
	be hosted within the same addressing realm and that would have the
	same local scoped address.
	There is a potential threat where an malicious NE with the same local
	scoped address as the target NR respond back positively to the NSIS
	message and consequently hijack the data flow. This threat could be
	counter-measured by proper cryptographic authentication of the NSIS
	Responder response by using keying material provided by the
	application signaling (assuming that it was secured).
	The procedure requiring an NSIS Initiator to send NSIS messages to		Informative References . . . . . . . . . . . . . . . . . . . . 18
	several NR addresses, requires that the NI sends his NSIS messages at
	the same time to avoid impacting real-time sensitive applications. In
	case the response to the message sent to the global scoped is
	received first, it could potentially be used as a hint that no
	response will be received from the NR's local scoped address. Hence
	there is no point to continue to delay the address selection process
	and proceed with the NSIS protocol operations. In case the first
	response is received from a local scoped address and has been
	authenticated with the keying material provided by the application
	signaling protocol then the address selection process ends, and the
	NSIS protocol operations continue.
	2.1.2 Intra realm solution application protocols impacts		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
	The proposed intra realm path optimization proposal requiring an NR		Intellectual Property and Copyright Statements . . . . . . . . 20
	to provide several data recipient addresses within the application
	protocol, has obviously a certain impact on the application protocol.
	[5] discusses the impact to SDP [8] and should be used by all the
	application protocols using SDP. A similar approach should be
	followed by other protocols, not using SDP, including H.323 [9] and
	others requiring usage of NSIS with multiple addresses for the NR.
	3. NATFW NSLP migration analysis		1. Introduction
	This section goes through a detailed analysis of the NATFW NSLP		The overall NSIS protocol suite (including the NATFW NSLP) is
	transition challenges and its possible solutions. The conception of		impacted by NSIS NATFW NSLP unaware NATs and Firewalls, this document
	the NSIS NATFW NSLP MUST ensure that upon its deployments in		covers impacts as well as some suggestions to ease the deployments of
	networks, it should not disrupt applications using interim NAT and		the NSIS protocol suite until the installed base on NATs and
	Firewall traversal mechanisms.		Firewalls migrates to NSIS.
	In addition:
	o The NATFW NSLP should ensure that an NR would not always be		The NATFW NSLP should allow an end host supporting NSIS to operate
	required to have minimal service, particularly when the NI has a		properly without the need of supporting true end-to-end NSIS
	simple network configuration without asymmetric route issues. In		signaling to its application correspondent. This is very practical
			during the initial phases of the NSIS migration and is applicable in
			simple network configurations not affected by asymmetric routing. In
	the early phases of the NSIS NATFW NSLP migration, this situation		the early phases of the NSIS NATFW NSLP migration, this situation
	will be quite frequent and hence this scenario must be supported.		will occur quite frequent and hence this scenario must be supported.
	o The NSIS protocol should be designed to traverse non-NSIS aware
	NATs and Firewalls, to allow usage of non NAT and Firewall related
	NSLP (Qos NSLP for example). As the reader will notice in the
	subsequent sections NRs behind
	o It is advised for an NSIS aware NAT and Firewall implementation to
	keep its existing currently used stateful behavior (depending on
	its applicability) until the transition to NSIS has ended (in
	order to have a smoother transition).
	Several deployment scenario will be considered within this analysis,
	for simplicity the discussed scenario cover at most two Middleboxes
	on the path between the NI and NR. In Figure 3, a total of 144
	deployment scenario could be possible only the ones having an NI or
	NR (only when there is a NAT) are considered. Implied but not shown
	scenario within Figure 5 are ones in the NI column or NR row.
	Obviously not all the scenario will be covered in this section, only
	the most interesting scenario are discussed in the next sections. A
	check list will be added later on in the annex of the next iteration
	of the analysis.
	`.-----+------+-------+-------+--------+------+-------+
	| `NR | NAT | FW |NATFW | NAT++ |FW++ |NATFW++|
	|NI `. |NE+NAT|NE+FW |NE+NATFW NE |NE | NE |
	|``````|``````|```````|```````|````````|``````|```````|
	| |Sc2 | |Sc10 |Sc14 | |Sc22 |
	|NAT |Sc3 |Sc7 |Sc11 |Sc15 |Sc19 |Sc23 |
	|NE+NAT|Sc4 |Sc8 |Sc12 |Sc16 |Sc20 |Sc24 |
	|`````````````````````````````````````````````````````
	| |Sc26 | |Sc34 |Sc38 | |Sc46 |
	| FW |Sc27 |Sc31 |Sc35 |Sc39 |Sc43 |Sc47 |
	| NE+FW|Sc28 |Sc32 |Sc36 |Sc40 |Sc44 |Sc48 |
	'''''''''''''''''''''''''''''''''''''''''''''''''''''''
	| |Sc50 | |Sc58 |Sc62 | |Sc70 |
	|NATFW |Sc51 |Sc55 |Sc59 |Sc63 |Sc67 |Sc71 |
	NE+NATFW Sc52 |Sc56 |Sc60 |Sc64 |Sc68 |Sc72 |
	'''''''''''''''''''''''''''''''''''''''''''''''''''''''
	| |Sc74 | |Sc82 |Sc86 | |Sc94 |
	| NAT++|Sc75 |Sc79 |Sc83 |Sc87 |Sc91 |Sc95 |
	| NE |Sc76 |Sc80 |Sc84 |Sc88 |Sc92 |Sc96 |
	+------+------+-------+-------+--------+------+-------+
	| |Sc98 | |Sc106 |Sc110 | | Sc118 |
	|FW++ |Sc99 | Sc103 |Sc107 |Sc111 |Sc115 | Sc119 |
	|NE |Sc100 | Sc104 |Sc108 |Sc112 |Sc116 | Sc120 |
	+------+------+-------+-------+--------+------+-------+
	| |Sc122 | |Sc130 | Sc134 | | Sc142 |
	|NATFW++ Sc123| Sc127 |Sc131 | Sc135 | Sc139| Sc143 |
	| NE | Sc124| Sc128 |Sc132 | Sc136 | Sc140| Sc144 |
	+------+------+-------+-------+--------+------+-------+
	Figure 3
	Scxyz: Scenario number xyz		The NSIS protocol should traverse NSIS unaware NATs (and possibly
	NAT : NSIS Unaware NAT		Firewalls) to allow a smoother deployment of, for example, Qos NSLP
	NE : NSIS Entity with NI and NR functions		in today's networks. To provide a smooth migration it is necessary to
	NE+NAT: NE hosted within a network connected to the NSIS unaware		understand the coexistence of NSIS aware and unware NATs and
	NAT FW : NSIS Unaware Firewall		Firewalls.
	NE+FW: NE hosted within a network protected by an NSIS Unaware FW
	NATFW: NSIS Unaware NAT and Firewall hosted within the same Middlebox
	NE+NATFW: NE hosted within a network protected by an NSIS Unaware
	NATFW
	NAT++: NSIS Aware NAT
	NAT++NE: NE hosted within a network connected to an NAT++
	FW++ : NSIS Aware FW
	FW++NE: NE hosted within a network connected to a FW++
	NATFW++: NSIS Aware NATFW
	NATFW++NE: NE hosted within a network connected to a NATFW++
	Every cell in Figure 3 is the combination of the NI's network and the
	NR's network. Deployments scenario, where there are no NI and NR, no
	NI (without an NR with a NAT), are not shown. For example:
	`.-----+------+		2. Terminology
	| `NR | NAT |
	|NI `. |NE+NAT|
	|````` :``````|
	| NAT |Sc2 |
	|NE+NAT|Sc3 |
	| |Sc4 |
	Figure 4		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [1].
	Scenario 1: NAT x NAT is not considered as there is no NI and no NR		The terminology used in this document is defined in [2].
	with a NAT
	Scenario 2: NAT x NE+NAT is considered as there is an NR with a NAT
	(even if it is not NSIS aware)
	Scenario 3: NE+NAT x NAT, is considered since there is an NI as part
	of the NE functions
	Scenario 4: NE+NAT x NE+NAT, is considered since there is an NI as
	part of the NE functions
	The same logic is applicable to all the cells in Figure 3
	For simplicity only network deployments are shown with a maximum of 2
	MBs on the path between the NI and the NR. Handled scenario within
	the NI column or NR raw are the ones having an NI or NR. In the next
	sections, we shall go through the various issues that are specific to
	the scenario mentioned in Figure 3.
	3.1 Global scoped address determination with NSIS unaware NATs		3. NSIS unaware NAT Traversal
	This section discusses the potentional role that an NE with a NATFW		This section discusses how an NE with any NSLP could still operate
	NSLP could still have to determine a global scoped address translated		when an NSIS unaware NAT is on the data path. The detection of an
	by a none NSIS aware NAT. Upon detection that the NE is attached to a		NSIS unaware NAT could be a feature of the NTLP [3], allowing its
	network hosting an NSIS unaware NAT, it could have the two		usage on any NE regardless of the supported NSLPs.
	alternatives, either:
	1. The NSIS API could invoke the services of a STUN client [7] as		Several NSIS independent approaches could be used by the NE to learn
	shown is Figure 7, this would allow applications using UDP		its global scoped address in order to use it for its hosted NSLPs. In
	transport to work (only applicable for cone NAT [7]).		this version of the document, only the STUN protocol [5] is
			considered as means to acquire the global scoped address; the next
			versions will consider other approaches.
	+---------------------------------------+		+---------------------------------------+
	| | +--------+		| | +--------+
	| +----------+ | | STUN |		| +----------+ | | STUN |
	| |Apps | | | Server |		| |Apps | | | Server |
	| +----------+ +---+| +--------+		| +----------+ +---+| +--------+
	| | STUN | |NAT||		| | STUN | |NAT||
	| | CLIENT | | ||		| | CLIENT | | ||
	| |__________| +---+|		| |__________| +---+|
	| |NATFW NSLP| |		| |ANY_NSLP | |
	| | NI/NR | |		| | NI/NR | |
	| +----------+ |		| +----------+ |
	| Host A |		| Host A |
	+---------------------------------------+		+---------------------------------------+
	Figure 5		Figure 1: STUN usage for NSIS unaware NATs
	2. The NE could send, through the NSIS unaware NAT, a bind request
	message towards a network entity hosting a simplified NR function
	responding to the message with the translated address. The
	translated address and port would correspond to the translated
	source address and port of the received NSIS message by the NE.
	This translated address and port information would only be useful
	for UDP transported data, and would imply that the NSIS protocol
	would be sent from the same address and port as the data flows.
	This behavior implies a change to the protocol operations, since
	the NTLP does not normally require transport protocol changes for
	a given NSLP (at least for now); the other implied modification
	is to support a minimum set of operations on the responding NE
	hosting the NATFW NSLP. The minimum set of operations would
	consist of the ability to authenticate the NE, providing the
	translated address and port, and support of UDP transport (as
	well as TCP if certificates need to be sent first). This
	mechanism would only be applicable to cone NATs [7].
	+---------------------------------------+		Within the initial stages of the NSIS migration, NE functions will be
	| | +--------+		co-hosting a STUN client that was already present on the application
	+ +----------+ | |NATFW |		end-host. Within Host A, shown in Figure 1, the NSIS API could invoke
	| |Apps | | | NSLP-NR|		the services of the STUN client (as shown in Figure 2) upon
	| +----------+ +---+| +--------+		determination that an NSIS unaware NAT was on the path.This would
	| |NATFW NSLP| |NAT||		allow applications using UDP transport to work (only applicable for
	| | NI/NR | | ||		cone NAT variants [5]).
	| +----------+ +---+|
	| Host A |
	| |
	+---------------------------------------+
	Figure 6
	+-----------------+		+-----------------+
	___________| NSIS aware NAT |_________		___________| NSIS aware NAT |_________
	| | Determination | |		| | Determination | |
	NSIS | +-----------------+ | NSIS		NSIS | +-----------------+ | NSIS
	Aware | | Unaware		Aware | | Unaware
	| |		| |
	| |		| |
	V V		V V
	+-------------------+ +------------+		+-------------------+ +------------+
	skipping to change at page 12, line 43		skipping to change at page 6, line 31
	| Send STUN |		| Send STUN |
	| binding |		| binding |
	| request |		| request |
	+-----+------+		+-----+------+
	|		|
	V		V
	+-------------------------+		+-------------------------+
	|Standard STUN operations |		|Standard STUN operations |
	+-------------------------+		+-------------------------+
	Figure 7		Figure 2: Interactions with a STUN client
	+-----------------+
	___________| NSIS aware NAT |_________		NSLPs would use the STUN returned global scoped address for the flow
	| | Determination | |		id [3].To allow NSIS signaling to be received by the NR on host A,
	NSIS | +-----------------+ | NSIS		without impacting existing applications (i.e. without explicitly
	Aware | | Unaware		providing the address and port of the NSIS recipient in the
			application signaling), the NSIS protocols would need to use NTLP
			datagram mode transport (as defined in [3]). This would imply that
			the NTLP will be using the same port as the data flows, this might
			complicate the proposed mode of operations (and might not meet the
			expected performance). The next version of the draft will discuss
			whether this approach would be practical based on received feedback
			from implementors.
			Subsequently we discuss how the NATFW NSLP could co-exist with
			interim NAT traversal mechanisms described in [8]. In Figure 3, a
			STUN client (Host A) [5], an NE (Host B), a host using a Media Proxy
			[8] and host using a TURN client [9] co-exist in the same network
			with a NATFW NSLP aware NAT. There are no reasons for the existing
			mechanisms to be mutually exclusive every host could continue using
			the existing interim solutions, meanwhile the unilateral NSIS
			signaling would be used until both ends support the NSIS NATFW NSLP.
			+---------------------------+
			| _|__1______.STUN Server
			|STUN Client ----'''''''''' |
			| Host A | App server
			| 2 _..NAT++ | .-'
			| NI/NR __.--'' | 3 .'+
			| Host B -'' | Media Proxy.-'
	| |		| |
	| |		| |
	V +------------+		| Host C |
	+-------------------+ If not UDP |Used data |		| 4 |