Diskussion:Portal:Netz/IPv6
Aus Freifunk Franken
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
- 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)
- 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
- 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. 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. 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. RedDog (Diskussion) 10:42, 2. 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
- 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)
- 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. 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 ChristianD
- 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. RedDog (Diskussion) 10:42, 2. Sep. 2017 (CEST)
- dafür setzen wir im radvd route fc00::/7 demnach sollte das schon gehen, sieht am Client dann so aus:
- 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)
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
- 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)
- 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
- 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. 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 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. RedDog (Diskussion) 11:52, 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 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. RedDog (Diskussion) 10:42, 2. 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
- 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.
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)
