Portal:Netz/IPv6: Unterschied zwischen den Versionen

Version vom 12. September 2017, 16:29 Uhr

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.

Jede Hood bekommt aus dem fd43:5602:29bd::/48 Netz ein eigenes /64 herausgeschnitten welches korrekt durch alle Hoods routet (genauso wie wir es aktuell mit den ipv4 10er Adressen tun)
Die Routerfirmware wird so angepasst, das aus der Hoodfile das /64 Netz gezogen und eine IP auf br-mesh gelegt wird. --> https://pw.freifunk-franken.de/patch/462/
Das fd43:5602:29bd::/48 Netz hat keinen Zugang zum Internet (deshalb AdvDefaultLifetime 0;). Wir machen kein v6 NAT oder so einen Kram!
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.
Ob Router später eine öffentliche v6 bekommen sollen, muss noch diskutiert werden. Ist aktuell nicht Gegenstand des Aufbaus und wird auch hiermit nicht verbaut falls man das später mal möchte.

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)

@@ Zeile 22: / Zeile 22: @@
 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)
+* Jede Hood bekommt aus dem fd43:5602:29bd::/48 Netz ein eigenes /64 herausgeschnitten welches 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? [[Benutzer:RedDog|RedDog]] ([[Benutzer Diskussion:RedDog|Diskussion]]) 13:21, 1. Sep. 2017 (CEST)
+* Die Routerfirmware wird so angepasst, das aus der Hoodfile das /64 Netz gezogen und eine IP auf br-mesh gelegt wird. --> https://pw.freifunk-franken.de/patch/462/
-*** Genau so ist die Idee ja, war bisschen undeutlich ausgedrückt sry. [[Benutzer:ChristianD|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? [[Benutzer:RedDog|RedDog]] ([[Benutzer Diskussion: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...). [[Benutzer:ChristianD|ChristianD]]
-**** Ob man nun das hood System oder den radvd anpasst ist fast egal. Wobei das hood System ja kryptografisch gesichert ist und daher zu bevorzugen ist. [[Benutzer:RedDog|RedDog]] ([[Benutzer Diskussion:RedDog|Diskussion]]) 10:42, 2. Sep. 2017 (CEST)
-***** Das Problem ist eher bei einer Änderung, man muss dann nur den radvd anpassen und nicht auch die Hoodfile. Aber ich lass mich hier mal von dir überzeugen und die Knoten sollen sich anhand der Hoodfile selbst konfigurieren, ich kann damit leben. [[Benutzer:ChristianD|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? [[Benutzer:RedDog|RedDog]] ([[Benutzer Diskussion: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:
-**** Achja stimmt, das umfast das ja. ;) Wir müssen nur aufpassen, dass VPN Dienste etc dabei nicht kaputt gehen. Die ULA sind ja genau so gedacht, dass es (durch random) keine Kollision geben soll. Aber da die Route weitestgehend unspezifisch ist, sollte es gehen, sondern der anderen VPN Dienst das nicht ähnlich macht. [[Benutzer:RedDog|RedDog]] ([[Benutzer Diskussion:RedDog|Diskussion]]) 10:42, 2. Sep. 2017 (CEST)
-***** genau die selbe Überlegung hatte ich auch, solang niemand anderes das gleiche macht dürfte nix passieren ;) Es ist irgendwie keine wunderbare GANZ schöne Lösung aber in meinen Augen eine mit der ich leben kann [[Benutzer:ChristianD|ChristianD]]
-<pre>
-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#
-</pre>
-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/ [[Benutzer:ChristianD|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. [[Benutzer:RedDog|RedDog]] ([[Benutzer Diskussion:RedDog|Diskussion]]) 13:21, 1. Sep. 2017 (CEST)
+* Ob Router später eine öffentliche v6 bekommen sollen, muss noch diskutiert werden. Ist aktuell nicht Gegenstand des Aufbaus und wird auch hiermit nicht verbaut falls man das später mal möchte.
-*** 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 [[Benutzer:ChristianD|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. [[Benutzer:RedDog|RedDog]] ([[Benutzer Diskussion: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 [[Benutzer:ChristianD|ChristianD]]
-**** Nein, das ist keine Security! Habe extra erwähnt, dass es eigentlich keinen Unterschied macht. Jedoch ist die Hürde die Knoten in einem Massenangriff mit zu erwischen etwas höher, weil die meisten Massenangreifer vermutlich nicht erst ins Freifunk Netz einloggen. Zum Beispiel, wenn unser dropbear nen Loch hat und das Bier wirklich mal drop't, dann wäre es besser die ganzen verwundbaren Knoten in einem öffentlich zugänglichen Privaten als im Internet zu haben. Gezielte Angriffe wird man sicher nicht los, aber man gewinnt ggf ein paar Minuten zum Updaten. [[Benutzer:RedDog|RedDog]] ([[Benutzer Diskussion:RedDog|Diskussion]]) 10:42, 2. Sep. 2017 (CEST)
-***** ok ist auf jeden Fall ein Argument. Ich bin jetzt zwigespalten. Eigentlich will ich es schon aber... vielleicht sollten wir uns in der breiten Masse mit beiden Argumenten ("Zeitgewinn bei Bug" gegen "noch leichteres erreichen der Knoten") wenden? Ich für meinen Teil werde meinen Knoten dennoch eine PublicV6 geben wenn wir eine haben, wie wir es in der breiten Masse machen keine Ahnung [[Benutzer:ChristianD|ChristianD]]
-****** Ist eh erstmal nicht relevant, weil kein public v6 da ist bzw wir noch nicht wissen, wie wir das mit dem Routing wirklich hinkriegen. Ich sehe die Diskussion daher erstmal noch nicht, und wenn es soweit ist, wird die dann schon kommen. [[Benutzer:RedDog|RedDog]] ([[Benutzer Diskussion:RedDog|Diskussion]]) 11:52, 2. 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.
-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 [[Benutzer:ChristianD|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 [[Benutzer:ChristianD|ChristianD]])
 == Subnetze der Hoods: ==