Portal:Netz/IPv6

Vorschlag für ein IPv6 Setup im KeyXchangeV2:

• Die Router vergeben weiterhin fdff:: Adressen, damit sie in ihrer Hood erreichbar bleiben und auch erreichbar sind, wenn sie gar keiner Hood angehören. fdff::1 wird auch weiterhin so wie früher funktionieren

• Die Gateways in der Hood lassen einen radvd laufen mit folgender config:

interface bat0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 60;
        MaxRtrAdvInterval 300;
        AdvDefaultLifetime 0;
        prefix fd43:5602:29bd:X::/64 {
                AdvOnLink on;
                AdvAutonomous on;
        };
        route fc00::/7 {
        };
};

beim prefix wird die X bei jeder Hood hochgezählt und wie bei den 10er v4 Adressen hier notiert. Die route fc00::/7 wird gesetzt, damit das ICVPN auch v6 fähig ist.

• Auf den Gateways wird Babel so konfiguriert, das es das fd43:5602:29bd::/48 korrekt durch alle Hoods routet (genauso wie wir es aktuell mit den ipv4 10er Adressen tun)
  • Also jeder Gateway announced im Babel dann sein fd43:5602:29bd:X::/64 Prefix? RedDog (Diskussion) 13:21, 1. Sep. 2017 (CEST)
• Die Router werden so konfiguriert, das sie auf br-mesh sich per Routeradvertisment zu den fdff:: Adressen ebenfalls eine fd43:5602:29bd:X::/64 Adresse holen. Danach sind alle Router, egal in welcher Hood über diese Adresse erreichbar. Ebenso sind sie über das ICVPN erreichbar.
  • Wieso hier das Prefix nicht aus dem Hood-File nehmen und dann lokal auf dem Knoten konfigurieren? RedDog (Diskussion) 13:21, 1. Sep. 2017 (CEST)
• Das fd43:5602:29bd::/48 Netz hat keinen Zugang zum Internet (deshalb AdvDefaultLifetime 0;). Wir machen kein v6 NAT oder so einen Kram!
  • Das würde aber das Routing im fd43:5602:29bd::/48 kaputt machen, da die Nutzer ja nur ihr /64 sehen. Vielleicht kann man das mit einem "route fd43:5602:29bd::/48" Eintrag fixen? RedDog (Diskussion) 13:21, 1. Sep. 2017 (CEST)
• Das ganze kann auch dezentral weiter geführt werden. Wenn jemand sich sein eigenes Prefix nach RFC4193 generieren will, kann er dies tun. Da wir die komplette ULA Range routen dürfte dies funktionieren.
  • Dann haben wir aber das Routing Problem, wo der Nutzer nur sein /64 sieht und die anderen Netze nicht erreicht, weil er kein Gateway hat. RedDog (Diskussion) 13:21, 1. Sep. 2017 (CEST)
• Sollten später mal öffentliche v6 Adressen per RA in eine Hood vergeben werden, sind Router sogar aus dem Internet per v6 erreichbar. Wir verbauen uns hier nichts!
  • Theoretisch macht es keinen Unterschied, ob die Knoten im Freifunk-Netz oder nur über das Internet angreifbar sind. Dennoch, wenn mal ne kritische Sicherheitslücke da ist wäre das unschön. Ich plädiere dafür den Knoten keine public v6 zu geben. RedDog (Diskussion) 13:21, 1. Sep. 2017 (CEST)

Das hier genannte Subnetz wurde nach RFC4193 auf https://cd34.com/rfc4193/ mit der MAC meiner Netzwerkkarte am 01.09.2017 gegen 10Uhr generiert.

Subnetze der Hoods:

• trainstationv2: fd43:5602:29bd:1::/64
• trainstationv2 feste Adressen:
• fd43:5602:29bd:1::1/64 Gateway vm3fffgwcd1

(muss mal irgendwann in eine Tabellenform wie bei den ipv4 Netzen gepackt werden)