< draft-pashalidis-nsis-gist-legacynats-00.txt		draft-pashalidis-nsis-gist-legacynats-01.txt >
	NSIS A. Pashalidis		NSIS A. Pashalidis
	Internet-Draft H. Tschofenig		Internet-Draft NEC
	Expires: January 18, 2007 Siemens		Intended status: Informational H. Tschofenig
	July 17, 2006		Expires: September 6, 2007 Siemens
			March 5, 2007
	GIST Legacy NAT Traversal		GIST Legacy NAT Traversal
	draft-pashalidis-nsis-gist-legacynats-00.txt		draft-pashalidis-nsis-gist-legacynats-01.txt
	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 January 18, 2007.		This Internet-Draft will expire on September 6, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes an extension to the General Internet		This document describes an extension to the General Internet
	Signalling Transport (GIST) protocol that enables the protocol to		Signalling Transport (GIST) protocol that enables the protocol to
	traverse different types of Network Address Translator (NAT). These		traverse different types of Network Address Translator (NAT). These
	NATs are assumed to not support GIST, i.e. to be "legacy" NATs. The		NATs are assumed to not support GIST, i.e. to be "legacy" NATs. The
	purpose of this extension is to enable GIST hosts to correctly		purpose of this extension is to enable GIST hosts to correctly
	interpret signalling messages with respect to the data traffic they		interpret signalling messages with respect to the data traffic they
	refer to, in the presence of such NATs. Note that this extension		refer to, in the presence of such NATs. Note that this extension
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 23 ¶
	5. Legacy NAT Traversal Mechanism . . . . . . . . . . . . . . . . 7		5. Legacy NAT Traversal Mechanism . . . . . . . . . . . . . . . . 7
	5.1. Traversal of NI-side legacy NATs . . . . . . . . . . . . . 7		5.1. Traversal of NI-side legacy NATs . . . . . . . . . . . . . 7
	5.1.1. Treatment of Data Traffic . . . . . . . . . . . . . . 10		5.1.1. Treatment of Data Traffic . . . . . . . . . . . . . . 10
	5.1.2. Treatment of Signalling Traffic . . . . . . . . . . . 12		5.1.2. Treatment of Signalling Traffic . . . . . . . . . . . 12
	5.1.3. Refreshing NSIS State . . . . . . . . . . . . . . . . 12		5.1.3. Refreshing NSIS State . . . . . . . . . . . . . . . . 12
	5.2. Traversal of NR-side legacy NATs . . . . . . . . . . . . . 12		5.2. Traversal of NR-side legacy NATs . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . . . 16		Intellectual Property and Copyright Statements . . . . . . . . . . 15
	1. Introduction		1. Introduction
	Network Address Translators (NATs) modify certain fields in the IP		Network Address Translators (NATs) modify certain fields in the IP
	and transport layer header of the packets that traverse them. In the		and transport layer header of the packets that traverse them. In the
	context of signalling as specified by the General Internet Signalling		context of signalling as specified by the General Internet Signalling
	Transport (GIST) protocol [1], this behaviour may lead to the		Transport (GIST) protocol [1], this behaviour may lead to the
	installation of state at network nodes that may be inconsistent and		installation of state at network nodes that may be inconsistent and
	meaningless with respect to the data traffic that traverses these		meaningless with respect to the data traffic that traverses these
	nodes.		nodes.
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 28 ¶
	| +-----+ |		| +-----+ |
	+------+ +------+ +--+---+ +------+		+------+ +------+ +--+---+ +------+
	+--+ | GIST | | IP | | IP | | GIST | +--+		+--+ | GIST | | IP | | IP | | GIST | +--+
	|DS+-+peer 1+--+router| |router+--+peer 2+-+DR|		|DS+-+peer 1+--+router| |router+--+peer 2+-+DR|
	+--+ +------+ +---+--+ +--+---+ +------+ +--+		+--+ +------+ +---+--+ +--+---+ +------+ +--+
	| +-----+ |		| +-----+ |
	| | NAT | |		| | NAT | |
	+----+ B +-----+		+----+ B +-----+
	+-----+		+-----+
	Figure 1: Network with more than one NAT at an addressing boundary		Figure 1: Network with more than one NAT at an addressing boundary
	Figure 1 illustrates the importance of assumptions (3) and (4). With		Figure 1 illustrates the importance of assumptions (3) and (4). With
	regard to that figure, suppose that a (D-mode) signalling session has		regard to that figure, suppose that a (D-mode) signalling session has
	been setup between the two adjacent GIST peers 1 and 2 and that both		been setup between the two adjacent GIST peers 1 and 2 and that both
	signalling and data traffic follows the path GIST peer 1 -> IP router		signalling and data traffic follows the path GIST peer 1 -> IP router
	-> NAT A -> IP router -> GIST peer 2. Suppose now that, after some		-> NAT A -> IP router -> GIST peer 2. Suppose now that, after some
	time, GIST peer 1 decides to set up a C-mode connection with peer 2.		time, GIST peer 1 decides to set up a C-mode connection with peer 2.
	Suppose moreover that the left IP router decides to forward the		Suppose moreover that the left IP router decides to forward the
	C-mode signalling traffic on the link towards NAT B. Thus, signalling		C-mode signalling traffic on the link towards NAT B. Thus, signalling
	traffic now follows the alternative path GIST peer 1 -> IP router ->		traffic now follows the alternative path GIST peer 1 -> IP router ->
	skipping to change at page 8, line 18 ¶		skipping to change at page 8, line 18 ¶
	data |GIST| | | |GIST| data		data |GIST| | | |GIST| data
	-----+ |NODE| | | |NODE| +----		-----+ |NODE| | | |NODE| +----
	| | 1 | +----------------------+ | 2 | |		| | 1 | +----------------------+ | 2 | |
	+--+----+-+ UDP TUNNEL +----------+		+--+----+-+ UDP TUNNEL +----------+
	signl.| | | +----------------------+ | | |signl.		signl.| | | +----------------------+ | | |signl.
	-----+ +----+ +----------+ +----+ +----		-----+ +----+ +----------+ +----+ +----
	internal external		internal external
	side side		side side
	Figure 2: High level overview of NI-side legacy NAT traversal		Figure 2: High level overview of NI-side legacy NAT traversal
	mechanism		mechanism
	The following may serve as indications for the existence of one or		The following may serve as indications for the existence of one or
	more GIST-unaware NAT(s) between two GIST peers. For the purposes of		more GIST-unaware NAT(s) between two GIST peers. For the purposes of
	the discussion in this section, these peers are called the "upstream"		the discussion in this section, these peers are called the "upstream"
	GIST peer (which also happens to be the querying peer) and the		GIST peer (which also happens to be the querying peer) and the
	"downstream" GIST peer (which also happens to be the responding		"downstream" GIST peer (which also happens to be the responding
	peer). These indications can only be detected by the receiver of a		peer). These indications can only be detected by the receiver of a
	GIST message, i.e. by the downstream peer. The first occasion these		GIST message, i.e. by the downstream peer. The first occasion these
	indications may be detected is with the reception of a GIST QUERY		indications may be detected is with the reception of a GIST QUERY
	where the downstream peer assumes the role of the responder. Note		where the downstream peer assumes the role of the responder. Note
	skipping to change at page 13, line 7 ¶		skipping to change at page 13, line 7 ¶
	5.2. Traversal of NR-side legacy NATs		5.2. Traversal of NR-side legacy NATs
	The traversal of NR-side legacy NATs is not as straight-forward as		The traversal of NR-side legacy NATs is not as straight-forward as
	the case of NI-side legacy NAT traversal. This is because an NR-side		the case of NI-side legacy NAT traversal. This is because an NR-side
	legacy NAT is likely to block all "unsolicited" incoming traffic.		legacy NAT is likely to block all "unsolicited" incoming traffic.
	That is, such a NAT is unlikely to install a NAT binding on the basis		That is, such a NAT is unlikely to install a NAT binding on the basis
	of a packet that arrives on its public side. Instead, such packets		of a packet that arrives on its public side. Instead, such packets
	are typically only forwarded towards the private side, if they match		are typically only forwarded towards the private side, if they match
	an already installed NAT binding.		an already installed NAT binding.
	The NR-side legacy NAT traversal mechanism will be specified in a		The NR-side legacy NAT traversal mechanism descibed in this document
	future version of this document.		only works with a certain subset of legacy NATs, namely those that
			are configured with static NAT bindings. In particular, it is
			assumed that the NR-side legacy NATs are configured to forward all
			incoming UDP packets that are destined to one of the NAT's public
			addresses, and which carry destination port number XXX (Editor's
			note: replace XXX with the well-known port number of GIST), to an
			internal IP address, denoted IPINT. It is further assumed that IPINT
			is assigned to a GIST node, denoted INTGIST. It is assumed that
			INTGIST knows the IP addresses assigned to the legacy NAT, and it is
			aware of fact that a static binding points to it.
			A GIST QUERY that arrives at the legacy NAT is now forwarded to
			INTGIST due to the static binding. INTGIST
	6. Security Considerations		6. Security Considerations
	Editor's note: this section will be completed after normative		Editor's note: this section will be completed after normative
	behaviour has been fully specified.		behaviour has been fully specified.
	7. Acknowledgements		7. Acknowledgements
	The authors would like to thank Robert Hancock and Martin Stiemerling		The authors would like to thank Robert Hancock and Martin Stiemerling
	for his insightful comments.		for his insightful comments.
	skipping to change at page 15, line 8 ¶		skipping to change at page 14, line 24 ¶
	[6] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network		[6] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network
	Address Translations (NATs)", RFC 4380, February 2006.		Address Translations (NATs)", RFC 4380, February 2006.
	[7] Rosenberg, J., Mahy, R., and C. Huitema, "Obtaining Relay		[7] Rosenberg, J., Mahy, R., and C. Huitema, "Obtaining Relay
	Addresses from Simple Traversal of UDP Through NAT",		Addresses from Simple Traversal of UDP Through NAT",
	draft-ietf-behave-turn-01.txt (work in progress), February 2006.		draft-ietf-behave-turn-01.txt (work in progress), February 2006.
	Authors' Addresses		Authors' Addresses
	Andreas Pashalidis		Andreas Pashalidis
	Siemens		NEC
	Otto-Hahn-Ring 6		Kurfuersten-Anlage 36
	Munich, Bavaria 81739		Heidelberg 69115
	Germany		Germany
	Email: Andreas.Pashalidis@siemens.com		Email: Andreas.Pashalidis@netlab.nec.de
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The IETF Trust (2007).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
			THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
			OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
			THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 16, line 29 ¶		skipping to change at page 15, line 45 ¶
	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.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 13 change blocks.
	35 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/