IPv6 Redesign: Unterschied zwischen den Versionen

Aus Freifunk Köln, Bonn und Umgebung
Zur Navigation springen Zur Suche springen
(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…“)
 
Keine Bearbeitungszusammenfassung
 
(3 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
[[Kategorie:Archiv]]
{{:Archiv-Hinweis}}
[[Kategorie:Netz-und-Technik]]
== Einleitung ==
== Einleitung ==
Neue Vorhaben:
Neue Vorhaben:
Zeile 7: Zeile 11:
=== Auswahl der Default-Route ===
=== 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.
* 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.
** 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 17:


=== Netz der Adressen ===
=== 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.
* 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.

Aktuelle Version vom 28. August 2019, 11:25 Uhr

Hinweis: Diese Seite wurde in das Archiv verschoben. Die Informationen sind größtenteils veraltet und nur für Spezialfälle relevant.

Einleitung

Neue Vorhaben:

  1. Fastd-Verbindungen zwischen Nodes und Supernodes sollen über IPv6 abgewickelt werden können.
  2. 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.
    • 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

Super-Nodes verwenden Link-Local Adressen für NTP und Routing. Supernode vpn1..9 hat die Link Local Adresse fe80::10(1..9) Diese Adressen werden statisch auf den Nodes in einer eigenen Routing-Tablle hinterlegt.

Abgerufen von „https://kbu.freifunk.net/wiki/index.php?title=IPv6_Redesign&oldid=5877“