Projekte/v642/IPv4 Support - Versionsgeschichte

Runout: benötigte OpenWRT Pakete

2019-09-14T20:45:56Z

benötigte OpenWRT Pakete

← Nächstältere Version		Version vom 14. September 2019, 20:45 Uhr
Zeile 65:		Zeile 65:
	Notiz am Rande. In den meisten Betriebssystemen, die IPv6 unterstützen, können IPv4-mapped-Adressen einfach eingegeben werden, indem diese als letzte 32 Bit der Adresse in Dotted-Decimal-Notation eingegeben werden. Zum Beispiel <code>::ffff:123.123.123.123</code>. Um RFC-konform zu sein müssen die vorherigen 16 Bit mit ffff belegt werden.		Notiz am Rande. In den meisten Betriebssystemen, die IPv6 unterstützen, können IPv4-mapped-Adressen einfach eingegeben werden, indem diese als letzte 32 Bit der Adresse in Dotted-Decimal-Notation eingegeben werden. Zum Beispiel <code>::ffff:123.123.123.123</code>. Um RFC-konform zu sein müssen die vorherigen 16 Bit mit ffff belegt werden.

			==== OpenWRT ====
			OpenWRT benötigt folgende Pakete um die Befehle in den nächsten Abschnitten ausführen zu können.

			* ip-full
			* kmod-ip6-tunnel

	==== Home-Router ====		==== Home-Router ====

Wnagele: Add TCP MSS Clamping info

2017-04-07T13:59:01Z

Add TCP MSS Clamping info

← Nächstältere Version		Version vom 7. April 2017, 13:59 Uhr
Zeile 126:		Zeile 126:
	</blockquote>		</blockquote>

	~~=== Offene Punkte ===~~		Da es leider Systeme gibt die ICMP Nachrichten filtern und daher keine PMTU (Path MTU) Discovery durchführen können, verwenden wir TCP MSS Clamping auf dem Wrap Server. Dadurch werden die initialen TCP SYN Messages angepasst damit sie die korrekte MTU verwenden.
	* '''MTUs''' -- ~~Auswirkung von geringeren IPv6~~-~~MTUs auf große IPv4~~-~~Pakete und~~ -~~Fragmente muss noch ausführlicher getestet werden.~~		<blockquote>
			<code>
			iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
			</code>
			</blockquote>

Wnagele am 20. März 2017 um 15:37 Uhr

2017-03-20T15:37:34Z

← Nächstältere Version		Version vom 20. März 2017, 15:37 Uhr
Zeile 115:		Zeile 115:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -6 tunnel add ~~wrap078041114123~~ mode ipip6 remote 2a02:61:0:ee:1:ffff:185.194.20.123 local 2a02:61:0:ee::ffff:185.194.20.123 dev lo		ip -6 tunnel add wrap185194020123 mode ipip6 remote 2a02:61:0:ee:1:ffff:185.194.20.123 local 2a02:61:0:ee::ffff:185.194.20.123 dev lo
	</code>		</code>
	</blockquote>		</blockquote>
Zeile 121:		Zeile 121:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -6 link set dev ~~wrap078041114123~~ up<br/>		ip -6 link set dev wrap185194020123 up<br/>
	ip -4 route add 185.194.20.123/32 dev ~~wrap078041114123~~		ip -4 route add 185.194.20.123/32 dev wrap185194020123
	</code>		</code>
	</blockquote>		</blockquote>

Wnagele: Change to new 185.194.20.0/23 block

2017-03-19T12:28:31Z

Change to new 185.194.20.0/23 block

← Nächstältere Version		Version vom 19. März 2017, 12:28 Uhr
Zeile 61:		Zeile 61:

	=== Beispielkonfiguration ===		=== Beispielkonfiguration ===
	Im folgenden eine Beispielkonfiguration, mit welcher die IPv4-Adresse <code>78.41.~~114~~.123</code> konfiguriert wird. Der Home-Router ist dabei ein Router im Mesh-Netz, welcher dazu gewählt wurde, diese IPv4-Adresse zu terminieren. (Welcher Router das in der Praxis macht, bleibt aber dem Halter der IPv4-Adresse überlassen: Es kann ein Mesh-Router oder ein nachgestellter Router in seinem Netz-Perimeter sein.)		Im folgenden eine Beispielkonfiguration, mit welcher die IPv4-Adresse <code>185.194.20.123</code> konfiguriert wird. Der Home-Router ist dabei ein Router im Mesh-Netz, welcher dazu gewählt wurde, diese IPv4-Adresse zu terminieren. (Welcher Router das in der Praxis macht, bleibt aber dem Halter der IPv4-Adresse überlassen: Es kann ein Mesh-Router oder ein nachgestellter Router in seinem Netz-Perimeter sein.)

	Notiz am Rande. In den meisten Betriebssystemen, die IPv6 unterstützen, können IPv4-mapped-Adressen einfach eingegeben werden, indem diese als letzte 32 Bit der Adresse in Dotted-Decimal-Notation eingegeben werden. Zum Beispiel <code>::ffff:123.123.123.123</code>. Um RFC-konform zu sein müssen die vorherigen 16 Bit mit ffff belegt werden.		Notiz am Rande. In den meisten Betriebssystemen, die IPv6 unterstützen, können IPv4-mapped-Adressen einfach eingegeben werden, indem diese als letzte 32 Bit der Adresse in Dotted-Decimal-Notation eingegeben werden. Zum Beispiel <code>::ffff:123.123.123.123</code>. Um RFC-konform zu sein müssen die vorherigen 16 Bit mit ffff belegt werden.
Zeile 70:		Zeile 70:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -6 addr add 2a02:61:0:ee:1:ffff:78.41.~~114~~.123/128 dev lo preferred_lft 0		ip -6 addr add 2a02:61:0:ee:1:ffff:185.194.20.123/128 dev lo preferred_lft 0
	</code>		</code>
	</blockquote>		</blockquote>
Zeile 78:		Zeile 78:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -6 tunnel add wrap1 mode ipip6 remote 2a02:61:0:ee::ffff:78.41.~~114~~.123 local 2a02:61:0:ee:1:ffff:78.41.~~114~~.123 dev lo<br/>		ip -6 tunnel add wrap1 mode ipip6 remote 2a02:61:0:ee::ffff:185.194.20.123 local 2a02:61:0:ee:1:ffff:185.194.20.123 dev lo<br/>
	ip -6 link set dev wrap1 up		ip -6 link set dev wrap1 up
	</code>		</code>
Zeile 86:		Zeile 86:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -4 addr add 78.41.~~114~~.123/32 dev wrap1		ip -4 addr add 185.194.20.123/32 dev wrap1
	</code>		</code>
	</blockquote>		</blockquote>
Zeile 95:		Zeile 95:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -4 route add 0.0.0.0/0 via 78.41.~~114~~.123 dev wrap1<br/>		ip -4 route add 0.0.0.0/0 via 185.194.20.123 dev wrap1<br/>
	iptables -t nat -A POSTROUTING -o wrap1 -j MASQUERADE		iptables -t nat -A POSTROUTING -o wrap1 -j MASQUERADE
	</code>		</code>
Zeile 109:		Zeile 109:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -6 addr add 2a02:61:0:ee::ffff:78.41.~~114~~.123/128 dev lo preferred_lft 0		ip -6 addr add 2a02:61:0:ee::ffff:185.194.20.123/128 dev lo preferred_lft 0
	</code>		</code>
	</blockquote>		</blockquote>
Zeile 115:		Zeile 115:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -6 tunnel add wrap078041114123 mode ipip6 remote 2a02:61:0:ee:1:ffff:78.41.~~114~~.123 local 2a02:61:0:ee::ffff:78.41.~~114~~.123 dev lo		ip -6 tunnel add wrap078041114123 mode ipip6 remote 2a02:61:0:ee:1:ffff:185.194.20.123 local 2a02:61:0:ee::ffff:185.194.20.123 dev lo
	</code>		</code>
	</blockquote>		</blockquote>
Zeile 122:		Zeile 122:
	<code>		<code>
	ip -6 link set dev wrap078041114123 up<br/>		ip -6 link set dev wrap078041114123 up<br/>
	ip -4 route add 78.41.~~114~~.123/32 dev wrap078041114123		ip -4 route add 185.194.20.123/32 dev wrap078041114123
	</code>		</code>
	</blockquote>		</blockquote>

Dhopfm: Update auf neuen IPv6-Block

2017-03-19T11:42:58Z

Update auf neuen IPv6-Block

← Nächstältere Version		Version vom 19. März 2017, 11:42 Uhr
Zeile 19:		Zeile 19:

	== Implementierung ==		== Implementierung ==
	Im Netz werden vom Verein an den Border-Punkten (im Moment bei Nessus und in der Krypta) sogennannte Wrapping-Server zur Verfügung gestellt. Diese Server werden im IPv6-Mesh die Route <code>2a02:60:~~100~~:ee::/80</code> announcieren. Da diese Route von mehreren Punkten ins Netz announciert wird, wird diese als Anycast verstanden. Anycast heißt, dass Traffic von Euch immer zum topologisch nächsten Server geroutet wird. Auch ermöglicht uns diese Art des Routings sofort Redundanzen zu haben. Wenn ein Server kaputt ist, wird die Route im Netz nicht mehr announciert, und ein andere Server übernimmt die Arbeit. Da (anders als bei Tunnellösungen) kein State besteht, ist das Wechseln auf einen anderen Wrapping-Server völlig transparent.		Im Netz werden vom Verein an den Border-Punkten (im Moment bei Nessus und in der Krypta) sogennannte Wrapping-Server zur Verfügung gestellt. Diese Server werden im IPv6-Mesh die Route <code>2a02:61:0:ee::/80</code> announcieren. Da diese Route von mehreren Punkten ins Netz announciert wird, wird diese als Anycast verstanden. Anycast heißt, dass Traffic von Euch immer zum topologisch nächsten Server geroutet wird. Auch ermöglicht uns diese Art des Routings sofort Redundanzen zu haben. Wenn ein Server kaputt ist, wird die Route im Netz nicht mehr announciert, und ein andere Server übernimmt die Arbeit. Da (anders als bei Tunnellösungen) kein State besteht, ist das Wechseln auf einen anderen Wrapping-Server völlig transparent.

	Weiters haben diese Server native IPv4-Anbindung am Backbone-Netz. Über diese Anbindung werden zu ihnen noch zu fixierende IPv4-Prefixes geroutet. Dort wiederum besteht der Fall, dass mehrere Routen zur selben IPv4-Adresse führen, und diese werden demnach im Backbone-Netz zum nächstgelegenen Server gesandt. Selbes Spiel wie oben im Mesh.		Weiters haben diese Server native IPv4-Anbindung am Backbone-Netz. Über diese Anbindung werden zu ihnen noch zu fixierende IPv4-Prefixes geroutet. Dort wiederum besteht der Fall, dass mehrere Routen zur selben IPv4-Adresse führen, und diese werden demnach im Backbone-Netz zum nächstgelegenen Server gesandt. Selbes Spiel wie oben im Mesh.
Zeile 31:		Zeile 31:
	Um die Konfiguration dieses Systems einfach zu halten, haben wir uns entschlossen, eine IPv4-in-IPv6-mapped-Struktur zu verwenden. Diese sind im [https://www.ietf.org/rfc/rfc4291.txt RFC4291] näher beschrieben.		Um die Konfiguration dieses Systems einfach zu halten, haben wir uns entschlossen, eine IPv4-in-IPv6-mapped-Struktur zu verwenden. Diese sind im [https://www.ietf.org/rfc/rfc4291.txt RFC4291] näher beschrieben.

	Für die Wrapper-Infrastruktur wurde der folgende Prefix zugewiesen: <code>2a02:60:~~100~~:ee::/64</code>		Für die Wrapper-Infrastruktur wurde der folgende Prefix zugewiesen: <code>2a02:61:0:ee::/64</code>

	Daraus ergeben sich folgende verwendbare Adressen:		Daraus ergeben sich folgende verwendbare Adressen:
	<blockquote>		<blockquote>
	<code>		<code>
	2a02:~~0060~~:~~0100~~:00ee:0000:0000:0000:0000 -		2a02:0061:0000:00ee:0000:0000:0000:0000 -
	2a02:~~0060~~:~~0100~~:00ee:ffff:ffff:ffff:ffff		2a02:0061:0000:00ee:ffff:ffff:ffff:ffff
	</code>		</code>
	</blockquote>		</blockquote>
Zeile 44:		Zeile 44:
	Innerhalb dieses Prefixes haben wir zwei /80 zugewiesen, welche einmal in die Richtung nach Außen (also ins Internet aus Sicht vom Mesh-Endknoten bei Dir) und einmal nach Innen routen.		Innerhalb dieses Prefixes haben wir zwei /80 zugewiesen, welche einmal in die Richtung nach Außen (also ins Internet aus Sicht vom Mesh-Endknoten bei Dir) und einmal nach Innen routen.

	Egress/nach Außen: <code>2a02:60:~~100~~:ee::/80</code>		Egress/nach Außen: <code>2a02:61:0:ee::/80</code>
	<blockquote>		<blockquote>
	<code>		<code>
	2a02:~~0060~~:~~0100~~:00ee:0000:0000:0000:0000 -		2a02:0061:0000:00ee:0000:0000:0000:0000 -
	2a02:~~0060~~:~~0100~~:00ee:0000:ffff:ffff:ffff		2a02:0061:0000:00ee:0000:ffff:ffff:ffff
	</code>		</code>
	</blockquote>		</blockquote>

	Ingress/nach Innen: <code>2a02:60:~~100~~:ee:1::/80</code>		Ingress/nach Innen: <code>2a02:61:0:ee:1::/80</code>
	<blockquote>		<blockquote>
	<code>		<code>
	2a02:~~0060~~:~~0100~~:00ee:0001:0000:0000:0000 -		2a02:0061:0000:00ee:0001:0000:0000:0000 -
	2a02:0060:~~0100~~:00ee:0001:ffff:ffff:ffff		2a02:0060:0000:00ee:0001:ffff:ffff:ffff
	</code>		</code>
	</blockquote>		</blockquote>
Zeile 70:		Zeile 70:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -6 addr add 2a02:60:~~100~~:ee:1:ffff:78.41.114.123/128 dev lo preferred_lft 0		ip -6 addr add 2a02:61:0:ee:1:ffff:78.41.114.123/128 dev lo preferred_lft 0
	</code>		</code>
	</blockquote>		</blockquote>
Zeile 78:		Zeile 78:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -6 tunnel add wrap1 mode ipip6 remote 2a02:60:~~100~~:ee::ffff:78.41.114.123 local 2a02:60:~~100~~:ee:1:ffff:78.41.114.123 dev lo<br/>		ip -6 tunnel add wrap1 mode ipip6 remote 2a02:61:0:ee::ffff:78.41.114.123 local 2a02:61:0:ee:1:ffff:78.41.114.123 dev lo<br/>
	ip -6 link set dev wrap1 up		ip -6 link set dev wrap1 up
	</code>		</code>
Zeile 109:		Zeile 109:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -6 addr add 2a02:60:~~100~~:ee::ffff:78.41.114.123/128 dev lo preferred_lft 0		ip -6 addr add 2a02:61:0:ee::ffff:78.41.114.123/128 dev lo preferred_lft 0
	</code>		</code>
	</blockquote>		</blockquote>
Zeile 115:		Zeile 115:
	<blockquote>		<blockquote>
	<code>		<code>
	ip -6 tunnel add wrap078041114123 mode ipip6 remote 2a02:60:~~100~~:ee:1:ffff:78.41.114.123 local 2a02:60:~~100~~:ee::ffff:78.41.114.123 dev lo		ip -6 tunnel add wrap078041114123 mode ipip6 remote 2a02:61:0:ee:1:ffff:78.41.114.123 local 2a02:61:0:ee::ffff:78.41.114.123 dev lo
	</code>		</code>
	</blockquote>		</blockquote>

Albert: Rechtschreibfehler; minimale Ergänzung

2016-05-12T16:28:04Z

Rechtschreibfehler; minimale Ergänzung

← Nächstältere Version		Version vom 12. Mai 2016, 16:28 Uhr
Zeile 23:		Zeile 23:
	Weiters haben diese Server native IPv4-Anbindung am Backbone-Netz. Über diese Anbindung werden zu ihnen noch zu fixierende IPv4-Prefixes geroutet. Dort wiederum besteht der Fall, dass mehrere Routen zur selben IPv4-Adresse führen, und diese werden demnach im Backbone-Netz zum nächstgelegenen Server gesandt. Selbes Spiel wie oben im Mesh.		Weiters haben diese Server native IPv4-Anbindung am Backbone-Netz. Über diese Anbindung werden zu ihnen noch zu fixierende IPv4-Prefixes geroutet. Dort wiederum besteht der Fall, dass mehrere Routen zur selben IPv4-Adresse führen, und diese werden demnach im Backbone-Netz zum nächstgelegenen Server gesandt. Selbes Spiel wie oben im Mesh.

	Auf jedem Server werden alle IPv4-Adressen aus den Netzen, die wir dorthin routen, vorkonfiguriert. Dies ist möglich, da wir ein statisches Mapping der IPv4-Adresse in die IPv6-Endpunkt-Adresse machen. Dadurch benötigt es keinerlei neue Konfiguration, um eine IPv4-Adresse in Betrieb zu nehmen, wenn sie Dir zugewiesen wurde. Der Wrap-Server ~~weiss~~ einfach ~~das~~ diese IPv4-Adresse an diesen IPv6-Endpunkt geschickt wird.		Auf jedem Server werden alle IPv4-Adressen aus den Netzen, die wir dorthin routen, vorkonfiguriert. Dies ist möglich, da wir ein statisches Mapping der IPv4-Adresse in die IPv6-Endpunkt-Adresse machen. Dadurch benötigt es keinerlei neue Konfiguration, um eine IPv4-Adresse in Betrieb zu nehmen, wenn sie Dir zugewiesen wurde. Der Wrap-Server weiß einfach, dass diese IPv4-Adresse an diesen IPv6-Endpunkt geschickt wird.

	Auf der anderen Seite bei Dir wiederum konfigurierst Du nur ein solches Interface für die IPv4-Adresse die Dir zugewiesen wurde. Die IPv6-Adressen, die Du für diese Konfiguration benötigst, ergeben sich wiederum aus der Dir zugewiesenen IPv4-Adresse. Mehr dazu im Beispiel unten.		Auf der anderen Seite bei Dir wiederum konfigurierst Du nur ein solches Interface für die IPv4-Adresse die Dir zugewiesen wurde. Die IPv6-Adressen, die Du für diese Konfiguration benötigst, ergeben sich wiederum aus der Dir zugewiesenen IPv4-Adresse. Mehr dazu im Beispiel unten.
Zeile 42:		Zeile 42:


	Innerhalb dieses Prefixes haben wir zwei /80 zugewiesen, welche einmal in die Richtung nach Außen (~~Ansicht~~ vom Mesh-Endknoten bei Dir) und einmal nach Innen routen.		Innerhalb dieses Prefixes haben wir zwei /80 zugewiesen, welche einmal in die Richtung nach Außen (also ins Internet aus Sicht vom Mesh-Endknoten bei Dir) und einmal nach Innen routen.

	Egress/nach ~~Aussen~~: <code>2a02:60:100:ee::/80</code>		Egress/nach Außen: <code>2a02:60:100:ee::/80</code>
	<blockquote>		<blockquote>
	<code>		<code>

Albert: Ui, noch Bindestriche ergänzt

2016-05-12T16:25:21Z

Ui, noch Bindestriche ergänzt

← Nächstältere Version		Version vom 12. Mai 2016, 16:25 Uhr
Zeile 75:		Zeile 75:
	Die Option <code>preferred_lft</code> setzen wir, damit diese Adresse nicht anstatt der Loopback-Adresse für Verbindungen, die von diesem Router ausgehen (und keine spezifische Source-IP haben), verwendet wird. Mehr Details hierzu gibt es [http://www.davidc.net/networking/ipv6-source-address-selection-linux hier] -- leider kann man in Linux keine Primary-IPv6-Adresse für ausgehende Verbindungen setzen.		Die Option <code>preferred_lft</code> setzen wir, damit diese Adresse nicht anstatt der Loopback-Adresse für Verbindungen, die von diesem Router ausgehen (und keine spezifische Source-IP haben), verwendet wird. Mehr Details hierzu gibt es [http://www.davidc.net/networking/ipv6-source-address-selection-linux hier] -- leider kann man in Linux keine Primary-IPv6-Adresse für ausgehende Verbindungen setzen.

	Als nächstes legen wir ein virtuelles Interface mit ''4in6'' Konfiguration an und aktivieren dieses. Die IPv6-Adressen geben die Source und Destinations wie oben beschrieben an.		Als nächstes legen wir ein virtuelles Interface mit ''4in6''-Konfiguration an und aktivieren dieses. Die IPv6-Adressen geben die Source und Destinations wie oben beschrieben an.
	<blockquote>		<blockquote>
	<code>		<code>
Zeile 127:		Zeile 127:

	=== Offene Punkte ===		=== Offene Punkte ===
	* '''MTUs''' - Auswirkung von geringeren IPv6-MTUs auf große IPv4-Pakete und -Fragmente muss noch ausführlicher getestet werden.		* '''MTUs''' -- Auswirkung von geringeren IPv6-MTUs auf große IPv4-Pakete und -Fragmente muss noch ausführlicher getestet werden.

Albert: Noch mehr Bindestriche!!1!

2016-05-12T16:22:58Z

Noch mehr Bindestriche!!1!

← Nächstältere Version		Version vom 12. Mai 2016, 16:22 Uhr
Zeile 31:		Zeile 31:
	Um die Konfiguration dieses Systems einfach zu halten, haben wir uns entschlossen, eine IPv4-in-IPv6-mapped-Struktur zu verwenden. Diese sind im [https://www.ietf.org/rfc/rfc4291.txt RFC4291] näher beschrieben.		Um die Konfiguration dieses Systems einfach zu halten, haben wir uns entschlossen, eine IPv4-in-IPv6-mapped-Struktur zu verwenden. Diese sind im [https://www.ietf.org/rfc/rfc4291.txt RFC4291] näher beschrieben.

	Für die Wrapper Infrastruktur wurde der folgende Prefix zugewiesen: <code>2a02:60:100:ee::/64</code>		Für die Wrapper-Infrastruktur wurde der folgende Prefix zugewiesen: <code>2a02:60:100:ee::/64</code>

	Daraus ergeben sich folgende verwendbare Adressen:		Daraus ergeben sich folgende verwendbare Adressen:

Albert: Fehlende Bindestriche ergänzt

2016-05-12T16:22:02Z

Fehlende Bindestriche ergänzt

← Nächstältere Version		Version vom 12. Mai 2016, 16:22 Uhr
Zeile 1:		Zeile 1:
	Ziel des [[Projekte/v642\|v642-Projektes]] ist es, das gesamte FunkFeuer-Netz auf ein natives IPv6-Netz umzustellen. Genauere Details zu den Beweggründen finden sich auf der Projektseite selbst. Es ist allerdings klar, dass auf absehbare Zeit Endnutzer weiterhin Inhalte über IPv4 abrufen werden ~~müssen~~ und diese eventuell auch bereitstellen wollen. Um dies zu ermöglichen, gibt es eine Vielzahl an sogenannten Transition-Mechanismen. Im Folgenden sollen die Gründe, warum wir uns für ''4in6'' als den Mechanismus für das FunkFeuer-Netz entschieden haben, und auch die technische Implementierung erläutert werden.		Ziel des [[Projekte/v642\|v642-Projektes]] ist es, das gesamte FunkFeuer-Netz auf ein natives IPv6-Netz umzustellen. Genauere Details zu den Beweggründen finden sich auf der Projektseite selbst. Es ist allerdings klar, dass auf absehbare Zeit Endnutzer weiterhin Inhalte über IPv4 abrufen werden und diese eventuell auch bereitstellen wollen. Um dies zu ermöglichen, gibt es eine Vielzahl an sogenannten Transition-Mechanismen. Im Folgenden sollen die Gründe, warum wir uns für ''4in6'' als den Mechanismus für das FunkFeuer-Netz entschieden haben, und auch die technische Implementierung erläutert werden.


Zeile 5:		Zeile 5:
	In der Wikipedia gibt es eine ganze Liste von [https://en.wikipedia.org/wiki/Category:IPv6_transition_technologies IPv6-Transition-Mechanismen]. Warum also für uns ''4in6''?		In der Wikipedia gibt es eine ganze Liste von [https://en.wikipedia.org/wiki/Category:IPv6_transition_technologies IPv6-Transition-Mechanismen]. Warum also für uns ''4in6''?

	Als ersten Schritt nahmen wir alle Mechanismen aus dem Rennen, welche dem Endnutzer keine IPv4 Adresse in seinem Netzwerk-Perimeter zur Verfügung stellen. Wir hielten es für wichtig, dass in einem freien Netz die Nutzer weiterhin auf beiden Netzwerk-Protokollen Inhalte nach ihren eigenen Wünschen verbreiten können. Dies wäre mit NAT-basierten Lösungen, wo Protokollübersetzungen mit State zentral durchgeführt werden, nur schwer möglich.		Als ersten Schritt nahmen wir alle Mechanismen aus dem Rennen, welche dem Endnutzer keine IPv4-Adresse in seinem Netzwerk-Perimeter zur Verfügung stellen. Wir hielten es für wichtig, dass in einem freien Netz die Nutzer weiterhin auf beiden Netzwerk-Protokollen Inhalte nach ihren eigenen Wünschen verbreiten können. Dies wäre mit NAT-basierten Lösungen, wo Protokollübersetzungen mit State zentral durchgeführt werden, nur schwer möglich.

	Am Ende bleiben uns damit noch einige Tunnel- und Wrapping-Mechanismen zur Verfügung. Verwaltung ist für uns hier wichtig, da eine große Anzahl von Tunnels schwer zu handhaben sind und wir uns das generell ersparen wollen. Daher wollen wir einen Mechanismus, der pflegeleicht ist. Auch soll State in den Tunnels vermieden werden. Der Unterschied ist hierbei, dass ein Tunnel großteils als konstant gesehen wird -- das heißt er hat eine Verbindung, welche aufrecht erhalten wird (engl. Stateful). Stateful ist generell schwieriger zu skalieren und für unsere Zwecke irrelevant da wir nur zwischen zwei Protokollen übersetzen wollen. Damit begeben wir uns auf das Feld, das besser als Wrapper oder Übersetzer zu bezeichnen ist. Hier kommt dann auch ''4in6'' ins Spiel, welches aufgrund der gut "abgehangenen" Spezifizierung ([https://www.ietf.org/rfc/rfc2473.txt RFC2473] aus dem Jahre 1998!) und dem entsprechend guten Support in Linux gewählt wurde.		Am Ende bleiben uns damit noch einige Tunnel- und Wrapping-Mechanismen zur Verfügung. Verwaltung ist für uns hier wichtig, da eine große Anzahl von Tunnels schwer zu handhaben sind und wir uns das generell ersparen wollen. Daher wollen wir einen Mechanismus, der pflegeleicht ist. Auch soll State in den Tunnels vermieden werden. Der Unterschied ist hierbei, dass ein Tunnel großteils als konstant gesehen wird -- das heißt er hat eine Verbindung, welche aufrecht erhalten wird (engl. Stateful). Stateful ist generell schwieriger zu skalieren und für unsere Zwecke irrelevant da wir nur zwischen zwei Protokollen übersetzen wollen. Damit begeben wir uns auf das Feld, das besser als Wrapper oder Übersetzer zu bezeichnen ist. Hier kommt dann auch ''4in6'' ins Spiel, welches aufgrund der gut "abgehangenen" Spezifizierung ([https://www.ietf.org/rfc/rfc2473.txt RFC2473] aus dem Jahre 1998!) und dem entsprechend guten Support in Linux gewählt wurde.
Zeile 23:		Zeile 23:
	Weiters haben diese Server native IPv4-Anbindung am Backbone-Netz. Über diese Anbindung werden zu ihnen noch zu fixierende IPv4-Prefixes geroutet. Dort wiederum besteht der Fall, dass mehrere Routen zur selben IPv4-Adresse führen, und diese werden demnach im Backbone-Netz zum nächstgelegenen Server gesandt. Selbes Spiel wie oben im Mesh.		Weiters haben diese Server native IPv4-Anbindung am Backbone-Netz. Über diese Anbindung werden zu ihnen noch zu fixierende IPv4-Prefixes geroutet. Dort wiederum besteht der Fall, dass mehrere Routen zur selben IPv4-Adresse führen, und diese werden demnach im Backbone-Netz zum nächstgelegenen Server gesandt. Selbes Spiel wie oben im Mesh.

	Auf jedem Server werden alle IPv4-Adressen aus den Netzen, die wir dorthin routen, vorkonfiguriert. Dies ist möglich, da wir ein statisches Mapping der IPv4-Adresse in die IPv6-Endpunkt-Adresse machen. Dadurch benötigt es keinerlei neue Konfiguration, um eine IPv4 Adresse in Betrieb zu nehmen, wenn sie Dir zugewiesen wurde. Der Wrap-Server weiss einfach das diese IPv4 Adresse an diesen IPv6 Endpunkt geschickt wird.		Auf jedem Server werden alle IPv4-Adressen aus den Netzen, die wir dorthin routen, vorkonfiguriert. Dies ist möglich, da wir ein statisches Mapping der IPv4-Adresse in die IPv6-Endpunkt-Adresse machen. Dadurch benötigt es keinerlei neue Konfiguration, um eine IPv4-Adresse in Betrieb zu nehmen, wenn sie Dir zugewiesen wurde. Der Wrap-Server weiss einfach das diese IPv4-Adresse an diesen IPv6-Endpunkt geschickt wird.

	Auf der anderen Seite bei Dir wiederum konfigurierst Du nur ein solches Interface für die IPv4-Adresse die Dir zugewiesen wurde. Die IPv6-Adressen, die Du für diese Konfiguration benötigst, ergeben sich wiederum aus der Dir zugewiesenen IPv4 Adresse. Mehr dazu im Beispiel unten.		Auf der anderen Seite bei Dir wiederum konfigurierst Du nur ein solches Interface für die IPv4-Adresse die Dir zugewiesen wurde. Die IPv6-Adressen, die Du für diese Konfiguration benötigst, ergeben sich wiederum aus der Dir zugewiesenen IPv4-Adresse. Mehr dazu im Beispiel unten.


Zeile 73:		Zeile 73:
	</code>		</code>
	</blockquote>		</blockquote>
	Die Option <code>preferred_lft</code> setzen wir, damit diese Adresse nicht anstatt der Loopback-Adresse für Verbindungen, die von diesem Router ausgehen (und keine spezifische Source-IP haben), verwendet wird. Mehr Details hierzu gibt es [http://www.davidc.net/networking/ipv6-source-address-selection-linux hier] -- leider kann man in Linux keine Primary IPv6 Adresse für ausgehende Verbindungen setzen.		Die Option <code>preferred_lft</code> setzen wir, damit diese Adresse nicht anstatt der Loopback-Adresse für Verbindungen, die von diesem Router ausgehen (und keine spezifische Source-IP haben), verwendet wird. Mehr Details hierzu gibt es [http://www.davidc.net/networking/ipv6-source-address-selection-linux hier] -- leider kann man in Linux keine Primary-IPv6-Adresse für ausgehende Verbindungen setzen.

	Als nächstes legen wir ein virtuelles Interface mit ''4in6'' Konfiguration an und aktivieren dieses. Die IPv6-Adressen geben die Source und Destinations wie oben beschrieben an.		Als nächstes legen wir ein virtuelles Interface mit ''4in6'' Konfiguration an und aktivieren dieses. Die IPv6-Adressen geben die Source und Destinations wie oben beschrieben an.

Albert: Diverse Typos und Spellos ausgebessert

2016-05-12T16:18:21Z

Diverse Typos und Spellos ausgebessert

Änderungen zeigen