IPv6 Redesign - Versionsgeschichte

Yanosz am 28. August 2019 um 10:25 Uhr

2019-08-28T10:25:50Z

← Nächstältere Version		Version vom 28. August 2019, 12:25 Uhr
Zeile 1:		Zeile 1:
			[[Kategorie:Archiv]]
			{{:Archiv-Hinweis}}

	[[Kategorie:Netz-und-Technik]]		[[Kategorie:Netz-und-Technik]]
	== Einleitung ==		== Einleitung ==

Kerel am 19. März 2015 um 21:28 Uhr

2015-03-19T21:28:14Z

← Nächstältere Version		Version vom 19. März 2015, 23:28 Uhr
Zeile 1:		Zeile 1:
			[[Kategorie:Netz-und-Technik]]
	== Einleitung ==		== Einleitung ==
	Neue Vorhaben:		Neue Vorhaben:

Yanosz am 22. Dezember 2014 um 00:25 Uhr

2014-12-22T00:25:05Z

@@ Zeile 7: / Zeile 7: @@
 === Auswahl der Default-Route ===
 * Jan ist nicht klar, ob es möglich ist, radv / DHCPv6 aus dem Uplink-Netz und der Mesh-Wolke naiv in der Routing-Tabelle des Nodes abzulegen.
-** Der Node routed nicht. Alle Pakete haben eine IPv6-Adresse des Nodes mit zugh. Interface als absender. radv / DHCPv6 werden mit ihrem Interface in der in der Tabelle gespeichert. => Linux kann muss (?) eine zum Interface / IPv6 passende route nehmen
+** Der Node routed nicht. Alle Pakete haben eine IPv6-Adresse des Nodes mit zugh. Interface als absender. radv / DHCPv6 werden mit ihrem Interface in der in der Tabelle gespeichert.
 ** Routing-Paradigma ist, dass sich eine route idR nicht nach der Quelladress richtet. Eine Auswahl nach IF ist afair im IPv6 GW-selection-Algorithmus nicht vorgesehen. Daher wäre es nicht zwingend falsch, eine Default-Routes eines anderen Interfaces zu nehmen.
@@ Zeile 13: / Zeile 13: @@
 === Netz der Adressen ===
-Aus welchem Netz sollen Nodes und Supernodes Adressen für NTP nutzen?
+Super-Nodes verwenden Link-Local Adressen für NTP und Routing. Supernode vpn1..9 hat die Link Local Adresse fe80::10(1..9)
-* Option 1: ULA
+Diese Adressen werden statisch auf den Nodes in einer eigenen Routing-Tablle hinterlegt.

Yanosz am 21. November 2014 um 11:27 Uhr

2014-11-21T11:27:31Z

← Nächstältere Version		Version vom 21. November 2014, 13:27 Uhr
Zeile 25:		Zeile 25:

	Eine denkbare Option ist, global Adressen statisch, lokal zu konfigurieren und eine eigene Routing-Tabelle für zu erstellen (ip rule add from $range table mesh-traffic). Welche Default-Route soll in diesem Fall in der Table mesh-traffic stehen		Eine denkbare Option ist, global Adressen statisch, lokal zu konfigurieren und eine eigene Routing-Tabelle für zu erstellen (ip rule add from $range table mesh-traffic). Welche Default-Route soll in diesem Fall in der Table mesh-traffic stehen
	# Vers. Adressen für alle Supernodes		# Vers. Adressen für alle Supernodes
	# Die gleiche Adresse für alle Supernodes		# Die gleiche Adresse für alle Supernodes
	# Global oder Link Lokal?		# Global oder Link Lokal?

	Bei vers. Adressen wäre zu klären, wie sich ein Node verhält, wenn ein Default-Router nicht mehr erreichbar ist. (Wird erfolglos versucht sie zu verwenden, auch wenn kein ICMPv6 Lookup möglich ist?)		Bei vers. Adressen wäre zu klären, wie sich ein Node verhält, wenn ein Default-Router nicht mehr erreichbar ist. (Wird erfolglos versucht sie zu verwenden, auch wenn kein ICMPv6 Lookup möglich ist?)
Zeile 45:		Zeile 45:
	* Situation: Client hat alte IPv6-Adresse (z.B. clubnetz des C4) per radvd empfangen und versucht sie als Absenderadresse im FF-Netz zu verwenden. Wie verhindern wir das?		* Situation: Client hat alte IPv6-Adresse (z.B. clubnetz des C4) per radvd empfangen und versucht sie als Absenderadresse im FF-Netz zu verwenden. Wie verhindern wir das?

	* Global-IPv6-Adresse der Supernodes als Route announcen - Passende IPv6-Adresse sollte gewählt werden. -> Passiert das? Kann radvd das? Brauchen wir da stateful DHCPv6?		* Global-IPv6-Adresse der Supernodes als Route announcen - Passende IPv6-Adresse sollte gewählt werden. -> Passiert das? Kann radvd das? Brauchen wir da stateful DHCPv6?

	* Fremdes radvd killen: Wenn ein Client ein /64 mit einer Fremden IPv6-Adresse verwerwendet, sendet der entspr. Supernode ein radvd-Annoucement, dass die max. Gültigkeit des Ranges auf < 10s setzt.		* Fremdes radvd killen: Wenn ein Client ein /64 mit einer Fremden IPv6-Adresse verwerwendet, sendet der entspr. Supernode ein radvd-Annoucement, dass die max. Gültigkeit des Ranges auf < 10s setzt.
	** -> Die IP wird Clientseitig gelöscht		** -> Die IP wird Clientseitig gelöscht
	** -> Ruft Störungen hervor, wenn der Client nach wie vor dem anderen Netz verbunden ist.		** -> Ruft Störungen hervor, wenn der Client nach wie vor dem anderen Netz verbunden ist.

	Jan ist nicht bekannt, welche Best-Practices für Clients gelten, die gleichzeitig mit zwei völlig vers. IPv6 Netzen verbunden sind. Eigentlich sollte es dazu aber Ideen geben.		Jan ist nicht bekannt, welche Best-Practices für Clients gelten, die gleichzeitig mit zwei völlig vers. IPv6 Netzen verbunden sind. Eigentlich sollte es dazu aber Ideen geben.

Yanosz: Die Seite wurde neu angelegt: „== Einleitung == Neue Vorhaben: # Fastd-Verbindungen zwischen Nodes und Supernodes sollen über IPv6 abgewickelt werden können. # Wir möchten NTP auf den Sup…“

2014-11-21T11:26:56Z

Die Seite wurde neu angelegt: „== Einleitung == Neue Vorhaben: # Fastd-Verbindungen zwischen Nodes und Supernodes sollen über IPv6 abgewickelt werden können. # Wir möchten NTP auf den Sup…“

Neue Seite

== Einleitung ==
Neue Vorhaben:
# Fastd-Verbindungen zwischen Nodes und Supernodes sollen über IPv6 abgewickelt werden können.
# Wir möchten NTP auf den Supernodes betreiben

== Ideen / Probleme / Diskussionspunkte ==
=== Auswahl der Default-Route ===
* Jan ist nicht klar, ob es möglich ist, radv / DHCPv6 aus dem Uplink-Netz und der Mesh-Wolke naiv in der Routing-Tabelle des Nodes abzulegen.
** Der Node routed nicht. Alle Pakete haben eine IPv6-Adresse des Nodes mit zugh. Interface als absender. radv / DHCPv6 werden mit ihrem Interface in der in der Tabelle gespeichert. => Linux kann muss (?) eine zum Interface / IPv6 passende route nehmen
** Routing-Paradigma ist, dass sich eine route idR nicht nach der Quelladress richtet. Eine Auswahl nach IF ist afair im IPv6 GW-selection-Algorithmus nicht vorgesehen. Daher wäre es nicht zwingend falsch, eine Default-Routes eines anderen Interfaces zu nehmen.

Es scheint sauberer, eine eigene Routing-Tabelle für Mesh-Traffic zu verwenden - insb. falls der Router irgendwann routed um ULA / "next node" IP-Adressen zu verteilen.

=== Netz der Adressen ===
Aus welchem Netz sollen Nodes und Supernodes Adressen für NTP nutzen?
* Option 1: ULA
* Option 2: Public

Für global spricht, dass Router nach wie vor extern erreichbar sein können (wollen wir das? -> Wahrscheinlich ja, Monitoring).

Für ULA spricht, dass die Probleme bei der Routing-Tabelle (s.o.) nicht auftreten. Es wird nie eine ULA-Adresse über einen WAN-Uplink verwendet -- gleichzeitig wird intern eine ULA-Adresse verwendet, wenn es möglich ist (DNS, NTP).

Wenn wir global Adressen verwenden, können wir sie vorauss. nicht via radv ankündigen, da sie mit ihrem Scope in der Default-Routing-Tabelle des Nodes landen sollten (s.o. - muss das zwingend sein?).
Landen Router mit ULA oder Global radv's eigentlich automatisch als default-router in der Routing-Tabelle es nodes? --> Jan muss mal eine E-Mail an die Debian IPv6-Liste schreiben.

Eine denkbare Option ist, global Adressen statisch, lokal zu konfigurieren und eine eigene Routing-Tabelle für zu erstellen (ip rule add from $range table mesh-traffic). Welche Default-Route soll in diesem Fall in der Table mesh-traffic stehen
# Vers. Adressen für alle Supernodes
# Die gleiche Adresse für alle Supernodes
# Global oder Link Lokal?

Bei vers. Adressen wäre zu klären, wie sich ein Node verhält, wenn ein Default-Router nicht mehr erreichbar ist. (Wird erfolglos versucht sie zu verwenden, auch wenn kein ICMPv6 Lookup möglich ist?)
Bei der gl. Adresse wäre zu klären, wie sich Anycast hier verhält. Linux kann keine globalen Anycast-Adressen setzen (nicht implementiert - ip addr add .. anycast bricht ohne Fehler ab - macht aber nix. Erkennt Linux, dass eine Globale Adresse bereits verwenden wird, ist keine Kommunikation möglich.
* Passiert das bei Link-Local genau so?
* Gibt es Ideen, ein Anycast-Setup für's routing zu bauen? - Kann man eine Multi-Cast Adresse (z.B. all-routers, link local) als default-Route verwenden?

=== Puppet + Supernodes ===
Unabh. vom gewählten Prefix und Scope muss ein Supernode eine feste Adresse daraus haben (z.B.) NetzID::F<NodeId_fuehrenden_Nullen>. An dieser Adresse sollte ein NTP-Server laufen, der da erreichbar ist.
Um zukünftige Optionen (insb. nur ein global Netz für clients in der mesh-cloud) nicht zu verbauen, sollten wir ein Netz nehmen, das aktuell nicht verwendet wird.

Vorschlag: Einfach ein ungenutztes, Public-IPv6-Netz (/64) zu Tests auf bat0 legen und entspr. Konvention verwenden. Wir können uns dann immer noch entscheiden, wie weiter verfahren. Vor dem nächsten FW-Release sollten wir wissen, welches Netz wird nehmen und zukünftige Dinge kaputt zu machen.

=== Ganz andere Frage: Fremde IPv6-Adressen ===
* Situation: Client hat alte IPv6-Adresse (z.B. clubnetz des C4) per radvd empfangen und versucht sie als Absenderadresse im FF-Netz zu verwenden. Wie verhindern wir das?

* Global-IPv6-Adresse der Supernodes als Route announcen - Passende IPv6-Adresse sollte gewählt werden. -> Passiert das? Kann radvd das? Brauchen wir da stateful DHCPv6?

* Fremdes radvd killen: Wenn ein Client ein /64 mit einer Fremden IPv6-Adresse verwerwendet, sendet der entspr. Supernode ein radvd-Annoucement, dass die max. Gültigkeit des Ranges auf < 10s setzt.
** -> Die IP wird Clientseitig gelöscht
** -> Ruft Störungen hervor, wenn der Client nach wie vor dem anderen Netz verbunden ist.

Jan ist nicht bekannt, welche Best-Practices für Clients gelten, die gleichzeitig mit zwei völlig vers. IPv6 Netzen verbunden sind. Eigentlich sollte es dazu aber Ideen geben.