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)
    • Genau so ist die Idee ja, war bisschen undeutlich ausgedrückt sry. ChristianD
• 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)
    • Kann man diskutieren, denke aber es ist einfach einfacher wenn man es per RA auf den Knoten automatisch konfiguriert, ist auch deutlich flexibler da man nicht mehrere Systeme hat die man anpassen muss wenn sich das prefix mal ändern sollte (warum auch immer...). ChristianD
• 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)
    • dafür setzen wir im radvd route fc00::/7 demnach sollte das schon gehen, sieht am Client dann so aus:

root@christiandux:/home/christiand# ifconfig wlan0
wlan0     Link encap:Ethernet  Hardware Adresse 08:11:96:4d:de:c0  
          inet Adresse:10.83.2.3  Bcast:10.83.3.255  Maske:255.255.252.0
          inet6-Adresse: fdff::a11:96ff:fe4d:dec0/64
Gültigkeitsbereich:Global
          inet6-Adresse: fe80::a11:96ff:fe4d:dec0/64
Gültigkeitsbereich:Verbindung
          inet6-Adresse: fd43:5602:29bd:1:a11:96ff:fe4d:dec0/64
Gültigkeitsbereich:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:133 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:1464 (1.4 KiB)  TX bytes:24235 (23.6 KiB)

root@christiandux:/home/christiand# ip -6 r s
fd43:5602:29bd:1::/64 dev wlan0  proto ra  metric 10
fdff::/64 dev wlan0  proto ra  metric 10
fc00::/7 via fe80::dceb:ddff:fea1:4a13 dev wlan0  proto ra  metric 10
fe80::/64 dev wlan0  proto kernel  metric 256
root@christiandux:/home/christiand#

wer es selbst testen will, baut meinen keyxchangev2 Patch durch, setzt im Router keine Koordinaten und landet dann in einer TrainstationV2 in welcher dieses Setup so umgesetzt wurde babel vom Gateway hier: http://144.76.70.186:8080/ ChristianD

• 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)
    • siehe Punkt zuvor, das sollte schon so gehen glaub ich es muss halt dafür gesorgt werden das route fc00::/7 den Clients mitgegeben wird ChristianD
• 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)
    • security through obscurity? Nein ich würde meinen Routern sofort eine public v6 geben, wenn ich welche hätte. Ich bin dafür das so zu tun ChristianD

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

Allgemeines noch zu Kommentaren:

• Ich finde die Nodes sollten bei reine L2 Router ("Switche") bleiben und jetzt nicht anfangen L3 Sachen auf einmal zu routen deshalb radvd auf dem Gateway , die IPv6 die sich beziehen ist dann wie eine managed IP auf einen managbaren Switch anzusehen, fdff:: ist halt eine notwendige Sache um sie auch ohne Hood erreichbar zu halten (meine Meinung ChristianD)
• Sollte man das geroutete ULA Netz dennoch an jeden Node vergeben wollen müsste man vermutlich auf radvd setzen, da uradvd die routen so wohl nicht setzen kann. Weiterhin müsste der Node dann das ULA Netz weiterrouten zu einen Gateway da nur dies Babel spricht. Finde das zu komplex und die Lösung das "einfach" die Gateways radvd machen viel einfacher und unkomplizierter (meine Meinung ChristianD)

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)