IPv6 Redesign

Aus Freifunk Köln, Bonn und Umgebung
Version vom 28. August 2019, 12:25 Uhr von Yanosz (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

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.