NAT Traversal - Revision history

Stefan at 10:15, 16 March 2006

2006-03-16T10:15:24Z

← Older revision		Revision as of 10:15, 16 March 2006
Line 1:		Line 1:
	Note: work in progress

	== Overview ==		== Overview ==

Stefan: /* TURN */

2006-03-16T10:13:05Z

TURN

← Older revision		Revision as of 10:13, 16 March 2006
Line 190:		Line 190:
	'''Idee und Technik:'''		'''Idee und Technik:'''

	Eine typische TURN-Konfiguration ähnelt stark der STUN-Konfiguration. Ein TURN-Client, der sich hinter einem NAT in einem privaten Netzwerk befindet, kommuniziert mit einem externen sich im öffentlichen Netzwerk befindlichen TURN-Server. Dieser TURN-Server dient als Datenrelay, er leitet also Daten zwischen dem Client und externen Peers weiter. Die Kommunikation zwischen Client und Server besteht anfänglich aus einfachen Request- und Response-Nachrichten. Der Syntax (Paketaufbau) dieser Nachrichten entspricht im Wesentlichen dem von STUN. Ebenfalls werden auf allg. Funktionen (z.B. Discovery und Authentifizierung) des STUN-Protokolls zurückgegriffen. Lediglich einige Attribute und Nachrichtentypen wurden ergänzt. Da bspw. die Kommunikation nicht nur aus einfachen Requests und Responses besteht, sondern auch datenintensivere Datenströme wie RTP über den TURN-Server weitergeleitet werden müssen, gibt es zusätzliche Attribute (z.B. BANDWITH) die von dem TURN-Server für die Bereitstellung und Verteilung von Ressourcen (z.B. Puffer, Bandbreite) verarbeitet werden.		Eine typische ''TURN-Konfiguration'' ähnelt stark der STUN-Konfiguration. Ein TURN-Client, der sich hinter einem NAT in einem privaten Netzwerk befindet, kommuniziert mit einem externen sich im öffentlichen Netzwerk befindlichen TURN-Server. Dieser TURN-Server dient als Datenrelay, er leitet also Daten zwischen dem Client und externen Peers weiter. Die Kommunikation zwischen Client und Server besteht anfänglich aus einfachen Request- und Response-Nachrichten. Der ''Syntax (Paketaufbau)'' dieser Nachrichten entspricht im Wesentlichen dem von STUN. Ebenfalls werden auf allg. Funktionen (z.B. Discovery und Authentifizierung) des STUN-Protokolls zurückgegriffen. Lediglich einige Attribute und Nachrichtentypen wurden ergänzt. Da bspw. die Kommunikation nicht nur aus einfachen Requests und Responses besteht, sondern auch datenintensivere Datenströme wie RTP über den TURN-Server weitergeleitet werden müssen, gibt es zusätzliche Attribute (z.B. BANDWITH) die von dem TURN-Server für die Bereitstellung und Verteilung von Ressourcen (z.B. Puffer, Bandbreite) verarbeitet werden.

	Die ersten Schritte einer erfolgreichen Kommunikation mit einem TURN-Server sind Discovery und Mechanismen zur Authentifizierung. Nach erfolgreichem Discovery, erlangt der Client Kenntnis darüber, wo sich ein potentieller TURN-Server befindet und kann diesen kontaktieren, um sich im zweiten Vorbereitungsschritt authentifizieren zu lassen.		Die ersten Schritte einer erfolgreichen Kommunikation mit einem TURN-Server sind Discovery und Mechanismen zur Authentifizierung. Nach erfolgreichem Discovery, erlangt der Client Kenntnis darüber, wo sich ein potentieller TURN-Server befindet und kann diesen kontaktieren, um sich im zweiten Vorbereitungsschritt authentifizieren zu lassen.

	Der Client ist nun befähigt dem TURN-Server ein TURN-Request zu senden. Der TURN-Server teil dem Client in seiner Antwort eine durch den Server vergebene "allocated transport adress" mit. Diese IP/PORT-Adresse ist öffentlich und dient dem Client als emulierte zukünftige Absenderkennung bei der Kommunikation mit externen Peers.		Der Client ist nun befähigt dem TURN-Server ein TURN-Request zu senden. Der TURN-Server teil dem Client in seiner Antwort eine durch den Server vergebene ''"allocated transport adress"'' mit. Diese IP/PORT-Adresse ist öffentlich und dient dem Client als emulierte zukünftige Absenderkennung bei der Kommunikation mit externen Peers.

	<table style="width:100%;">		<table style="width:100%;">
	<tr>		<tr>
	<td>		<td>
	Das rechtsstehende Schaubild verdeutlicht die Umgebung und Funktionsweise des TURN-Servers.		Das rechtsstehende Schaubild verdeutlicht die ''Umgebung und Funktionsweise des TURN-Servers''.
	Wie schon erwähnt befindet sich dieser im öffentlichen Netzwerk und hat somit auch Kontakt		Wie schon erwähnt befindet sich dieser im öffentlichen Netzwerk und hat somit auch Kontakt
	mit externen Peers. Der interne TURN-Client befindet sich in einem privaten Netzwerk, welches		mit externen Peers. Der interne TURN-Client befindet sich in einem privaten Netzwerk, welches
	über einen NAT mit dem öffentlichen Netzwerk verbunden ist. Das besondere am TURN-Server ist, dass dieser mit einem eingehenden TURN-Request ein sog. 5er Tupel generiert und speichert, das Verbindungsinformationen eines TURN-Clients oder dessen gewünschten Kommunikationspartnern enthält. So unterscheidet man internal 5-Tupel (TURN-clientseitig) und external 5-Tupel (Verbindungsdaten zu Peers im öffentlichen Netzwerk). Mit Hilfe dieser Tupel ist es dem TURN-Server möglich einen adress-restricted NAT zu emulieren. Der TURN-Server leitet demnach Pakete von einem externen Host B nur dann an einen bekannten internen TURN-Client A weiter, wenn zuvor ein Paket über den TURN-Server von A nach B geschickt worden ist. Im Detail läuft dies folgendermaßen ab:		über einen NAT mit dem öffentlichen Netzwerk verbunden ist. Das besondere am TURN-Server ist, dass dieser mit einem eingehenden TURN-Request ein sog. ''5er Tupel'' generiert und speichert, das Verbindungsinformationen eines TURN-Clients oder dessen gewünschten Kommunikationspartnern enthält. So unterscheidet man internal 5-Tupel (TURN-clientseitig) und external 5-Tupel (Verbindungsdaten zu Peers im öffentlichen Netzwerk). Mit Hilfe dieser Tupel ist es dem TURN-Server möglich einen adress-restricted NAT zu emulieren. Der TURN-Server leitet demnach Pakete von einem externen Host B nur dann an einen bekannten internen TURN-Client A weiter, wenn zuvor ein Paket über den TURN-Server von A nach B geschickt worden ist. Im Detail läuft dies folgendermaßen ab:
	</td>		</td>
	<td valign="top">		<td valign="top">
Line 219:		Line 219:
	Jedes durch X instanziierte external-5-Tupel stellt einen externen Kommunikationspartner (Peer) dar, der berechtigt ist in dieser Form mit X über die "allocated transport adress" zu kommunizieren. Beim symmetrischen NAT sind nur Verbindungen mit einer IP und Port-Kombination zwischen X und Y möglich. In diesem Fall, kann nur ein einziger externer Host Y mit X über dieselbe IP/PORT-Kombination in Kontakt treten, die X beim erstmaligen Kontaktieren des Y verwendet hat.		Jedes durch X instanziierte external-5-Tupel stellt einen externen Kommunikationspartner (Peer) dar, der berechtigt ist in dieser Form mit X über die "allocated transport adress" zu kommunizieren. Beim symmetrischen NAT sind nur Verbindungen mit einer IP und Port-Kombination zwischen X und Y möglich. In diesem Fall, kann nur ein einziger externer Host Y mit X über dieselbe IP/PORT-Kombination in Kontakt treten, die X beim erstmaligen Kontaktieren des Y verwendet hat.

	Da diese Form der Kommunikation aufgrund der Kapselung der Datenpakete durch den TURN-Server in TURN-Messages nicht sehr effizient ist, bietet TURN die Möglichkeit mit Hilfe des Aufrufs "Set Active Destination" ein Ziel Y als aktiv zu setzen. Alle Pakete von Y werden fortan als ungekapselte reine Datenpakete an X weitergeleitet, was einen Performancevorteil mit sich bringt. Diese Option sollte dann eingesetzt werden, wenn davon auszugehen ist, dass eine länger andauernde Verbindung mit hohem Datenaufkommen (z.B. eine VoIP-Session) aufgebaut werden soll.		Da diese Form der Kommunikation aufgrund der Kapselung der Datenpakete durch den TURN-Server in TURN-Messages nicht sehr effizient ist, bietet TURN die Möglichkeit mit Hilfe des Aufrufs "''Set Active Destination"'' ein Ziel Y als aktiv zu setzen. Alle Pakete von Y werden fortan als ungekapselte reine Datenpakete an X weitergeleitet, was einen Performancevorteil mit sich bringt. Diese Option sollte dann eingesetzt werden, wenn davon auszugehen ist, dass eine länger andauernde Verbindung mit hohem Datenaufkommen (z.B. eine VoIP-Session) aufgebaut werden soll.

	== Hole punching ==		== Hole punching ==

Stefan: /* TURN */

2006-03-16T10:09:51Z

TURN

← Older revision		Revision as of 10:09, 16 March 2006
Line 215:		Line 215:
	'''2.''' TURN-Server sendet Datenpaket (Inhalt: Z) an Y		'''2.''' TURN-Server sendet Datenpaket (Inhalt: Z) an Y

	'''3.''' X erhält Bestätigung (Send Response) vom TURN-Server, Y ist nun befähigt über die "allocated transport adress" mit X zu kommunizieren		'''3.''' X erhält Bestätigung (Send Response) vom TURN-Server. Y ist nun befähigt über die "allocated transport adress" mit X zu kommunizieren.

	Jedes durch X instanziierte external-5-Tupel stellt einen externen Kommunikationspartner (Peer) dar, der berechtigt ist in dieser Form mit X über die "allocated transport adress" zu kommunizieren. Beim symmetrischen NAT sind nur Verbindungen mit einer IP und Port-Kombination zwischen X und Y möglich. In diesem Fall, kann nur ein einziger externer Host Y mit X über dieselbe IP/PORT-Kombination in Kontakt treten, die X beim erstmaligen Kontaktieren des Y verwendet hat.		Jedes durch X instanziierte external-5-Tupel stellt einen externen Kommunikationspartner (Peer) dar, der berechtigt ist in dieser Form mit X über die "allocated transport adress" zu kommunizieren. Beim symmetrischen NAT sind nur Verbindungen mit einer IP und Port-Kombination zwischen X und Y möglich. In diesem Fall, kann nur ein einziger externer Host Y mit X über dieselbe IP/PORT-Kombination in Kontakt treten, die X beim erstmaligen Kontaktieren des Y verwendet hat.

Stefan: /* TURN */

2006-03-16T10:08:39Z

TURN

← Older revision		Revision as of 10:08, 16 March 2006
Line 209:		Line 209:
	</tr>		</tr>
	</table>		</table>
	1. interner Client X sendet Send Request (enthält Zieladresse des gewünschten Kommunikationspartners Y und Daten Z) an TURN-Server		'''1.''' interner Client X sendet Send Request (enthält Zieladresse des gewünschten Kommunikationspartners Y und Daten Z) an TURN-Server

	1.2 falls dieser Kontakt erstmalig ist, wird ein entsprechendes external-5-Tupel instanziiert		'''1.2''' falls dieser Kontakt erstmalig ist, wird ein entsprechendes external-5-Tupel instanziiert

	2. TURN-Server sendet Datenpaket (Inhalt: Z) an Y		'''2.''' TURN-Server sendet Datenpaket (Inhalt: Z) an Y

	3. X erhält Bestätigung (Send Response) vom TURN-Server, Y ist nun befähigt über die "allocated transport adress" mit X zu kommunizieren		'''3.''' X erhält Bestätigung (Send Response) vom TURN-Server, Y ist nun befähigt über die "allocated transport adress" mit X zu kommunizieren
	Jedes durch X instanziierte external-5-Tupel stellt einen externen Kommunikationspartner (Peer) dar, der berechtigt ist in dieser Form mit X über die "allocated transport adress" zu kommunizieren. Beim symmetrischen NAT sind nur Verbindungen mit einer IP und Port-Kombination zwischen X und Y möglich. In diesem Fall, kann nur ein einziger externer Host Y mit X über dieselbe IP/PORT-Kombination in Kontakt treten, die X beim erstmaligen Kontaktieren des Y verwendet hat.		Jedes durch X instanziierte external-5-Tupel stellt einen externen Kommunikationspartner (Peer) dar, der berechtigt ist in dieser Form mit X über die "allocated transport adress" zu kommunizieren. Beim symmetrischen NAT sind nur Verbindungen mit einer IP und Port-Kombination zwischen X und Y möglich. In diesem Fall, kann nur ein einziger externer Host Y mit X über dieselbe IP/PORT-Kombination in Kontakt treten, die X beim erstmaligen Kontaktieren des Y verwendet hat.

Stefan: /* TURN */

2006-03-16T10:07:38Z

TURN

← Older revision		Revision as of 10:07, 16 March 2006
Line 203:		Line 203:
	mit externen Peers. Der interne TURN-Client befindet sich in einem privaten Netzwerk, welches		mit externen Peers. Der interne TURN-Client befindet sich in einem privaten Netzwerk, welches
	über einen NAT mit dem öffentlichen Netzwerk verbunden ist. Das besondere am TURN-Server ist, dass dieser mit einem eingehenden TURN-Request ein sog. 5er Tupel generiert und speichert, das Verbindungsinformationen eines TURN-Clients oder dessen gewünschten Kommunikationspartnern enthält. So unterscheidet man internal 5-Tupel (TURN-clientseitig) und external 5-Tupel (Verbindungsdaten zu Peers im öffentlichen Netzwerk). Mit Hilfe dieser Tupel ist es dem TURN-Server möglich einen adress-restricted NAT zu emulieren. Der TURN-Server leitet demnach Pakete von einem externen Host B nur dann an einen bekannten internen TURN-Client A weiter, wenn zuvor ein Paket über den TURN-Server von A nach B geschickt worden ist. Im Detail läuft dies folgendermaßen ab:		über einen NAT mit dem öffentlichen Netzwerk verbunden ist. Das besondere am TURN-Server ist, dass dieser mit einem eingehenden TURN-Request ein sog. 5er Tupel generiert und speichert, das Verbindungsinformationen eines TURN-Clients oder dessen gewünschten Kommunikationspartnern enthält. So unterscheidet man internal 5-Tupel (TURN-clientseitig) und external 5-Tupel (Verbindungsdaten zu Peers im öffentlichen Netzwerk). Mit Hilfe dieser Tupel ist es dem TURN-Server möglich einen adress-restricted NAT zu emulieren. Der TURN-Server leitet demnach Pakete von einem externen Host B nur dann an einen bekannten internen TURN-Client A weiter, wenn zuvor ein Paket über den TURN-Server von A nach B geschickt worden ist. Im Detail läuft dies folgendermaßen ab:
		⚫	</td>

		⚫	<td valign="top">
		⚫	[[Image:TURN-Server-kl.jpg\|thumb\|Figure 12: TURN-Server]]
		⚫	</td>
		⚫	</tr>
		⚫	</table>
	1. interner Client X sendet Send Request (enthält Zieladresse des gewünschten Kommunikationspartners Y und Daten Z) an TURN-Server		1. interner Client X sendet Send Request (enthält Zieladresse des gewünschten Kommunikationspartners Y und Daten Z) an TURN-Server

Line 211:		Line 216:

	3. X erhält Bestätigung (Send Response) vom TURN-Server, Y ist nun befähigt über die "allocated transport adress" mit X zu kommunizieren		3. X erhält Bestätigung (Send Response) vom TURN-Server, Y ist nun befähigt über die "allocated transport adress" mit X zu kommunizieren
⚫	</td>
⚫	<td valign="top">
⚫	[[Image:TURN-Server-kl.jpg\|thumb\|Figure 12: TURN-Server]]
⚫	</td>
⚫	</tr>
⚫	</table>
	Jedes durch X instanziierte external-5-Tupel stellt einen externen Kommunikationspartner (Peer) dar, der berechtigt ist in dieser Form mit X über die "allocated transport adress" zu kommunizieren. Beim symmetrischen NAT sind nur Verbindungen mit einer IP und Port-Kombination zwischen X und Y möglich. In diesem Fall, kann nur ein einziger externer Host Y mit X über dieselbe IP/PORT-Kombination in Kontakt treten, die X beim erstmaligen Kontaktieren des Y verwendet hat.		Jedes durch X instanziierte external-5-Tupel stellt einen externen Kommunikationspartner (Peer) dar, der berechtigt ist in dieser Form mit X über die "allocated transport adress" zu kommunizieren. Beim symmetrischen NAT sind nur Verbindungen mit einer IP und Port-Kombination zwischen X und Y möglich. In diesem Fall, kann nur ein einziger externer Host Y mit X über dieselbe IP/PORT-Kombination in Kontakt treten, die X beim erstmaligen Kontaktieren des Y verwendet hat.

Stefan: /* TURN */

2006-03-16T10:07:05Z

TURN

← Older revision		Revision as of 10:07, 16 March 2006
Line 202:		Line 202:
	Wie schon erwähnt befindet sich dieser im öffentlichen Netzwerk und hat somit auch Kontakt		Wie schon erwähnt befindet sich dieser im öffentlichen Netzwerk und hat somit auch Kontakt
	mit externen Peers. Der interne TURN-Client befindet sich in einem privaten Netzwerk, welches		mit externen Peers. Der interne TURN-Client befindet sich in einem privaten Netzwerk, welches
	über einen NAT mit dem öffentlichen Netzwerk verbunden ist. Das besondere am TURN-Server ist, dass dieser mit einem eingehenden TURN-Request ein sog. 5er Tupel generiert und speichert, das Verbindungsinformationen zu TURN-Clients ~~und~~ dessen gewünschten Kommunikationspartnern enthält. So unterscheidet man internal 5-Tupel (TURN-clientseitig) und external 5-Tupel (Verbindungsdaten zu Peers im öffentlichen Netzwerk). Mit Hilfe dieser Tupel ist es dem TURN-Server möglich einen adress-restricted NAT zu emulieren. Der TURN-Server leitet demnach Pakete von einem externen Host B nur dann an einen bekannten internen TURN-Client A weiter, wenn zuvor ein Paket über den TURN-Server von A nach B geschickt worden ist. Im Detail läuft dies folgendermaßen ab:		über einen NAT mit dem öffentlichen Netzwerk verbunden ist. Das besondere am TURN-Server ist, dass dieser mit einem eingehenden TURN-Request ein sog. 5er Tupel generiert und speichert, das Verbindungsinformationen eines TURN-Clients oder dessen gewünschten Kommunikationspartnern enthält. So unterscheidet man internal 5-Tupel (TURN-clientseitig) und external 5-Tupel (Verbindungsdaten zu Peers im öffentlichen Netzwerk). Mit Hilfe dieser Tupel ist es dem TURN-Server möglich einen adress-restricted NAT zu emulieren. Der TURN-Server leitet demnach Pakete von einem externen Host B nur dann an einen bekannten internen TURN-Client A weiter, wenn zuvor ein Paket über den TURN-Server von A nach B geschickt worden ist. Im Detail läuft dies folgendermaßen ab:

	1. interner Client X sendet Send Request (enthält Zieladresse des gewünschten Kommunikationspartners Y und Daten Z) an TURN-Server		1. interner Client X sendet Send Request (enthält Zieladresse des gewünschten Kommunikationspartners Y und Daten Z) an TURN-Server

Stefan at 10:04, 16 March 2006

2006-03-16T10:04:01Z

← Older revision		Revision as of 10:04, 16 March 2006
Line 196:		Line 196:
	Der Client ist nun befähigt dem TURN-Server ein TURN-Request zu senden. Der TURN-Server teil dem Client in seiner Antwort eine durch den Server vergebene "allocated transport adress" mit. Diese IP/PORT-Adresse ist öffentlich und dient dem Client als emulierte zukünftige Absenderkennung bei der Kommunikation mit externen Peers.		Der Client ist nun befähigt dem TURN-Server ein TURN-Request zu senden. Der TURN-Server teil dem Client in seiner Antwort eine durch den Server vergebene "allocated transport adress" mit. Diese IP/PORT-Adresse ist öffentlich und dient dem Client als emulierte zukünftige Absenderkennung bei der Kommunikation mit externen Peers.

			<table style="width:100%;">
			<tr>
			<td>
	Das rechtsstehende Schaubild verdeutlicht die Umgebung und Funktionsweise des TURN-Servers.		Das rechtsstehende Schaubild verdeutlicht die Umgebung und Funktionsweise des TURN-Servers.
	Wie schon erwähnt befindet sich dieser im öffentlichen Netzwerk und hat somit auch Kontakt		Wie schon erwähnt befindet sich dieser im öffentlichen Netzwerk und hat somit auch Kontakt
Line 208:		Line 211:

	3. X erhält Bestätigung (Send Response) vom TURN-Server, Y ist nun befähigt über die "allocated transport adress" mit X zu kommunizieren		3. X erhält Bestätigung (Send Response) vom TURN-Server, Y ist nun befähigt über die "allocated transport adress" mit X zu kommunizieren
			</td>

			<td valign="top">
			[[Image:TURN-Server-kl.jpg\|thumb\|Figure 12: TURN-Server]]
			</td>
			</tr>
			</table>
	Jedes durch X instanziierte external-5-Tupel stellt einen externen Kommunikationspartner (Peer) dar, der berechtigt ist in dieser Form mit X über die "allocated transport adress" zu kommunizieren. Beim symmetrischen NAT sind nur Verbindungen mit einer IP und Port-Kombination zwischen X und Y möglich. In diesem Fall, kann nur ein einziger externer Host Y mit X über dieselbe IP/PORT-Kombination in Kontakt treten, die X beim erstmaligen Kontaktieren des Y verwendet hat.		Jedes durch X instanziierte external-5-Tupel stellt einen externen Kommunikationspartner (Peer) dar, der berechtigt ist in dieser Form mit X über die "allocated transport adress" zu kommunizieren. Beim symmetrischen NAT sind nur Verbindungen mit einer IP und Port-Kombination zwischen X und Y möglich. In diesem Fall, kann nur ein einziger externer Host Y mit X über dieselbe IP/PORT-Kombination in Kontakt treten, die X beim erstmaligen Kontaktieren des Y verwendet hat.

Stefan: /* TURN */

2006-03-16T10:01:13Z

TURN

← Older revision		Revision as of 10:01, 16 March 2006
Line 190:		Line 190:
	'''Idee und Technik:'''		'''Idee und Technik:'''

	Eine typische TURN-Konfiguration ähnelt stark der STUN-Konfiguration ~~(Schaubild)~~. Ein TURN-Client, der sich hinter einem NAT in einem privaten Netzwerk befindet, kommuniziert mit einem externen sich im öffentlichen Netzwerk befindlichen TURN-Server. Dieser TURN-Server dient als Datenrelay, er leitet also Daten zwischen dem Client und externen Peers weiter. Die Kommunikation zwischen Client und Server besteht anfänglich aus einfachen Request- und Response-Nachrichten. Der Syntax (Paketaufbau) dieser Nachrichten entspricht im Wesentlichen dem von STUN. Ebenfalls werden auf allg. Funktionen (z.B. Discovery und Authentifizierung) des STUN-Protokolls zurückgegriffen. Lediglich einige Attribute und Nachrichtentypen wurden ergänzt. Da bspw. die Kommunikation nicht nur aus einfachen Requests und Responses besteht, sondern auch datenintensivere Datenströme wie RTP über den TURN-Server weitergeleitet werden müssen, gibt es zusätzliche Attribute (z.B. BANDWITH) die von dem TURN-Server für die Bereitstellung und Verteilung von Ressourcen (z.B. Puffer, Bandbreite) verarbeitet werden.		Eine typische TURN-Konfiguration ähnelt stark der STUN-Konfiguration. Ein TURN-Client, der sich hinter einem NAT in einem privaten Netzwerk befindet, kommuniziert mit einem externen sich im öffentlichen Netzwerk befindlichen TURN-Server. Dieser TURN-Server dient als Datenrelay, er leitet also Daten zwischen dem Client und externen Peers weiter. Die Kommunikation zwischen Client und Server besteht anfänglich aus einfachen Request- und Response-Nachrichten. Der Syntax (Paketaufbau) dieser Nachrichten entspricht im Wesentlichen dem von STUN. Ebenfalls werden auf allg. Funktionen (z.B. Discovery und Authentifizierung) des STUN-Protokolls zurückgegriffen. Lediglich einige Attribute und Nachrichtentypen wurden ergänzt. Da bspw. die Kommunikation nicht nur aus einfachen Requests und Responses besteht, sondern auch datenintensivere Datenströme wie RTP über den TURN-Server weitergeleitet werden müssen, gibt es zusätzliche Attribute (z.B. BANDWITH) die von dem TURN-Server für die Bereitstellung und Verteilung von Ressourcen (z.B. Puffer, Bandbreite) verarbeitet werden.

	Die ersten Schritte einer erfolgreichen Kommunikation mit einem TURN-Server sind Discovery und Mechanismen zur Authentifizierung. Nach erfolgreichem Discovery, erlangt der Client Kenntnis darüber, wo sich ein potentieller TURN-Server befindet und kann diesen kontaktieren, um sich im zweiten Vorbereitungsschritt authentifizieren zu lassen.		Die ersten Schritte einer erfolgreichen Kommunikation mit einem TURN-Server sind Discovery und Mechanismen zur Authentifizierung. Nach erfolgreichem Discovery, erlangt der Client Kenntnis darüber, wo sich ein potentieller TURN-Server befindet und kann diesen kontaktieren, um sich im zweiten Vorbereitungsschritt authentifizieren zu lassen.

Stefan: /* TURN */

2006-03-16T10:00:20Z

TURN

← Older revision		Revision as of 10:00, 16 March 2006
Line 190:		Line 190:
	'''Idee und Technik:'''		'''Idee und Technik:'''

	Eine typische TURN-Konfiguration ähnelt stark der STUN-Konfiguration (Schaubild). Ein TURN-Client, der sich hinter einem NAT in einem privaten Netzwerk befindet, kommuniziert mit einem externen sich im öffentlichen Netzwerk befindlichen TURN-Server. Dieser TURN-Server dient als Datenrelay, er leitet also Daten zwischen dem Client und externen Peers weiter. Die Kommunikation zwischen Client und Server besteht anfänglich aus einfachen Request- und Response-Nachrichten. Der Syntax (Paketaufbau) dieser Nachrichten entspricht im Wesentlichen dem von STUN. Ebenfalls werden auf allg. Funktionen (z.B. Discovery und Authentifizierung) des STUN-Protokolls zurückgegriffen. Da die Kommunikation nicht nur aus einfachen Requests und Responses besteht, sondern auch datenintensivere Datenströme wie RTP über den TURN-Server weitergeleitet werden müssen, gibt es zusätzliche Attribute (z.B. ~~BANWITH~~) die von dem TURN-Server für die Bereitstellung und Verteilung von Ressourcen (z.B. Puffer, Bandbreite) verarbeitet werden.		Eine typische TURN-Konfiguration ähnelt stark der STUN-Konfiguration (Schaubild). Ein TURN-Client, der sich hinter einem NAT in einem privaten Netzwerk befindet, kommuniziert mit einem externen sich im öffentlichen Netzwerk befindlichen TURN-Server. Dieser TURN-Server dient als Datenrelay, er leitet also Daten zwischen dem Client und externen Peers weiter. Die Kommunikation zwischen Client und Server besteht anfänglich aus einfachen Request- und Response-Nachrichten. Der Syntax (Paketaufbau) dieser Nachrichten entspricht im Wesentlichen dem von STUN. Ebenfalls werden auf allg. Funktionen (z.B. Discovery und Authentifizierung) des STUN-Protokolls zurückgegriffen. Lediglich einige Attribute und Nachrichtentypen wurden ergänzt. Da bspw. die Kommunikation nicht nur aus einfachen Requests und Responses besteht, sondern auch datenintensivere Datenströme wie RTP über den TURN-Server weitergeleitet werden müssen, gibt es zusätzliche Attribute (z.B. BANDWITH) die von dem TURN-Server für die Bereitstellung und Verteilung von Ressourcen (z.B. Puffer, Bandbreite) verarbeitet werden.

	~~Der~~ ersten Schritte einer erfolgreichen Kommunikation mit einem TURN-Server sind Discovery und Mechanismen zur Authentifizierung. Nach erfolgreichem Discovery, erlangt der Client Kenntnis darüber, wo sich ein potentieller TURN-Server befindet und kann diesen kontaktieren, um sich im zweiten Vorbereitungsschritt authentifizieren zu lassen.		Die ersten Schritte einer erfolgreichen Kommunikation mit einem TURN-Server sind Discovery und Mechanismen zur Authentifizierung. Nach erfolgreichem Discovery, erlangt der Client Kenntnis darüber, wo sich ein potentieller TURN-Server befindet und kann diesen kontaktieren, um sich im zweiten Vorbereitungsschritt authentifizieren zu lassen.

	Der Client ist nun befähigt dem TURN-Server ein TURN-Request zu senden. Der TURN-Server teil dem Client in seiner Antwort eine durch den Server vergebene "allocated transport adress" mit. Diese IP/PORT-Adresse ist öffentlich und dient dem Client als zukünftige Absenderkennung bei der Kommunikation mit externen Peers.		Der Client ist nun befähigt dem TURN-Server ein TURN-Request zu senden. Der TURN-Server teil dem Client in seiner Antwort eine durch den Server vergebene "allocated transport adress" mit. Diese IP/PORT-Adresse ist öffentlich und dient dem Client als emulierte zukünftige Absenderkennung bei der Kommunikation mit externen Peers.

	Das rechtsstehende Schaubild verdeutlicht die Umgebung und Funktionsweise des TURN-Servers.		Das rechtsstehende Schaubild verdeutlicht die Umgebung und Funktionsweise des TURN-Servers.

Stefan: /* TURN */

2006-03-16T09:53:26Z

TURN

← Older revision		Revision as of 09:53, 16 March 2006
Line 182:		Line 182:
	'''Einführung:'''		'''Einführung:'''

	TURN (Traversal Using Relay NAT), als ein noch sehr junger Ansatz zur Lösung des NAT-Problems, versucht die Grenzen des STUN-Protokolls aufzuweichen. Wie im vorherigen Kapitel angesprochen, macht der Einsatz von STUN hinter symmetrischen NATs wenig Sinn. Diesem und anderen typischen NAT-Problemen, versucht sich der ~~Internet-Draft (2005)~~[http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-08.txt Internet ~~Draft~~] über TURN anzunehmen. Dabei liegt ein besonderes Augenmerk darauf, das schwierige Problem symmetrischer NATs in der Form zu vereinfachen, dass wir es im Endeffekt nur noch mit restriktiven NAT-Typen zu tun haben.		TURN (Traversal Using Relay NAT), als ein noch sehr junger Ansatz zur Lösung des NAT-Problems, versucht die Grenzen des STUN-Protokolls aufzuweichen. Wie im vorherigen Kapitel angesprochen, macht der Einsatz von STUN hinter symmetrischen NATs wenig Sinn. Diesem und anderen typischen NAT-Problemen, versucht sich der [http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-08.txt Internet-Draft (2005)] über TURN anzunehmen. Dabei liegt ein besonderes Augenmerk darauf, das schwierige Problem symmetrischer NATs in der Form zu vereinfachen, dass wir es im Endeffekt nur noch mit restriktiven NAT-Typen zu tun haben.

	'''Ziel:'''		'''Ziel:'''