layer3: fdff::/64 adressen machen freifunk internes routing bei minimal configurationen schwieriger #76

New Issue

jkimmel · 2021-01-11T13:39:43+01:00

jkimmel commented

2021-01-11 13:39:43 +01:00

Wenn man einen Knoten nur mit einem IPv6 Netz ausstattet, also beispielsweise einem aus https://sub.f3netze.de, dann ist es wegen dem fdff::/64, welches automatisch vergeben wird, unmöglich das interne Netz zu erreichen.

Konkretes Beispiel an der DNS64 Anycast Adresse fd43:5602:29bd:ffff:1:1:1:64:

Client versucht fd43:5602:29bd:ffff:1:1:1:64 zu erreich und hat
1. Link-Local Adressen
2. fdff::/64 Adressen
3. Adressen aus dem global gerouteten Netz (z.b. 2a0b:f4c0:stuv:wxyz::/64)
Waehlt wegen RFC 3484 als eine Adresse aus dem fdff::/64 Netz als Source Adresse.
Das fdff::/64 ist nicht geroutet, Pakete finden also aus dem Internen Netz nicht wieder zurück zum Absenser.

Es gibt 2 offensichtliche Lösungen zu dem Problem:

Das fdff::/64 Netz nicht mehr konfigurieren und verteilen
Man ist gezwungen ein passendes ULA Prefix zu konfigurieren (Stichwort fd43-Adressen)

Option 2 stoert mich gerade gewaltig, weil es eigentlich unnoetiger Mehraufwand ist einen Router richtig aufzusetzen ist.

Option 1 waere prinzipiell die schoenere Loesung. Aber ohne anderen bequemen Ersatz (z.b. DNS) vermutlich keine gute Alternative.

Ich wuerde deshalb hier nach echten Loesungsansatzen fischen, ob es eine gute Alternative zum fdff::/64 Netz gibt. Ich werde auch ein paar Sachen probieren und hier sammeln, vorallem auch die Fehlschlaege, damit es nicht noch jemand probiert und fuer die Zukunft dokumentiert ist.

Wer schon eine gute Idee hat, gerne her damit.

Wenn man einen Knoten nur mit *einem* IPv6 Netz ausstattet, also beispielsweise einem aus [https://sub.f3netze.de](https://sub.f3netze.de), dann ist es wegen dem `fdff::/64`, welches automatisch vergeben wird, unmöglich das interne Netz zu erreichen. Konkretes Beispiel an der DNS64 Anycast Adresse `fd43:5602:29bd:ffff:1:1:1:64`: 1. Client versucht `fd43:5602:29bd:ffff:1:1:1:64` zu erreich und hat 1. Link-Local Adressen 2. `fdff::/64` Adressen 3. Adressen aus dem global gerouteten Netz (z.b. `2a0b:f4c0:stuv:wxyz::/64`) 2. Waehlt wegen [RFC 3484](https://www.ietf.org/rfc/rfc3484.txt) als eine Adresse aus dem `fdff::/64` Netz als Source Adresse. 3. Das `fdff::/64` ist nicht geroutet, Pakete finden also aus dem Internen Netz nicht wieder zurück zum Absenser. Es gibt 2 offensichtliche Lösungen zu dem Problem: 1. Das `fdff::/64` Netz nicht mehr konfigurieren und verteilen 2. Man ist gezwungen ein passendes ULA Prefix zu konfigurieren (Stichwort `fd43`-Adressen) Option 2 stoert mich gerade gewaltig, weil es eigentlich unnoetiger Mehraufwand ist einen Router richtig aufzusetzen ist. Option 1 waere prinzipiell die schoenere Loesung. Aber ohne anderen bequemen Ersatz (z.b. DNS) vermutlich keine gute Alternative. Ich wuerde deshalb hier nach echten Loesungsansatzen fischen, ob es eine gute Alternative zum `fdff::/64` Netz gibt. Ich werde auch ein paar Sachen probieren und hier sammeln, vorallem auch die Fehlschlaege, damit es nicht noch jemand probiert und fuer die Zukunft dokumentiert ist. Wer schon eine gute Idee hat, gerne her damit.

jkimmel added the

layer3

RFC

labels 2021-01-11 13:39:43 +01:00

fbl commented

2021-01-11 13:45:47 +01:00

Vielleicht kann man an der preferred lifetime schrauben?

fbl commented

2021-01-11 14:14:52 +01:00

Man ist gezwungen ein passendes ULA Prefix zu konfigurieren (Stichwort fd43-Adressen)

Ein geroutetes ULA Prefix zu konfigurieren ist keine Lösung, sondern wenn überhaupt nur ein kaputter Workaround. Beispiele:

Jemand hat fdb0::/48 im icvpn. Dann wird ein Client fdff verwenden um sich zu verbinden, auch wenn eine Adresse aus fd43:5602:29bd::/48 konfiguriert ist.
Man verwendet auf einem layer3 Router fc42::/48 statt fd43:5602:29bd::/48. dann sind sogar Ziele in unserem fd43 nicht erreichbar, weil das Prefix von Adressen aus fdff::/64 mehr gleiche Bits hat.

> 2. Man ist gezwungen ein passendes ULA Prefix zu konfigurieren (Stichwort `fd43`-Adressen) Ein geroutetes ULA Prefix zu konfigurieren ist keine Lösung, sondern wenn überhaupt nur ein kaputter Workaround. Beispiele: * Jemand hat `fdb0::/48` im icvpn. Dann wird ein Client fdff verwenden um sich zu verbinden, auch wenn eine Adresse aus `fd43:5602:29bd::/48` konfiguriert ist. * Man verwendet auf einem layer3 Router `fc42::/48` statt `fd43:5602:29bd::/48`. dann sind sogar Ziele in unserem fd43 nicht erreichbar, weil das Prefix von Adressen aus `fdff::/64` mehr gleiche Bits hat.

Blackyfff commented

2021-01-16 00:37:23 +01:00

Um den aktuellen Stand nochmal zusammenzufassen:

Das fdff::/64 Netz nicht mehr konfigurieren und verteilen

muss so oder so sein, da es auch andere Probleme verursacht

dann bleibt aber das Problem der Erreichbarkeit des Routers vor dem Einrichten.

Dafür stand im Raum

DNS Eintrag sinnvoll setzen

das löst nicht das Problem auf welche Adresse der Eintrag zeigen soll, bei fdff wäre das kein Problem, da das statisch ist (war).
Außerdem hat das Gerät mit welchem man Zugriff erlangen will, erstmal den Router nicht als DNS, außer dieser verteilt schon DHCPv4 oder RAs, da beißt sich die Katze in den Schwanz.

~~Ich persönlich finde diesen Weg zu umständlich.~~

Scheint die einzige nutzerfreundliche Lösung zu sein.

Temporäres ULA generieren und per RA announcen

Hat den Vorteil, dass es gerouted werden kann und wäre laut ChristianD auch gut fürs MQTT.
Nachteil ist man kann nicht mehr auf eine feste Adresse zugreifen und ist von den RAs abhängig.

feste v6 LL Adresse bis zur Ersteinrichtung vergeben

Hier wurde im Chat angebracht, das würde nicht funktionieren. Das kann ich nicht nachstellen, bei mir im OpenWRT hänge ich via ip addr add fe80::fff:1/64 dev XXX die Adresse ans Interface und Firefox, Chrome und sogar Edge und IE können via http://[fe80::fff:1] aufs Web-Interface (luci unter uhttpd).

~~Vielleicht könnte man ja 2+3 kombinieren.~~

Da die Browser (Firefox/Chrome) die zoneid nicht mögen und es ohne zoneid auf den meisten Betriebssystemen nicht funktioniert wird 3. auch nichts.

Um den aktuellen Stand nochmal zusammenzufassen: > 1. Das `fdff::/64` Netz nicht mehr konfigurieren und verteilen muss so oder so sein, da es auch andere Probleme verursacht dann bleibt aber das Problem der Erreichbarkeit des Routers vor dem Einrichten. Dafür stand im Raum 1. DNS Eintrag sinnvoll setzen das löst nicht das Problem auf welche Adresse der Eintrag zeigen soll, bei `fdff` wäre das kein Problem, da das statisch ist (war). Außerdem hat das Gerät mit welchem man Zugriff erlangen will, erstmal den Router nicht als DNS, außer dieser verteilt schon DHCPv4 oder RAs, da beißt sich die Katze in den Schwanz. ~~Ich persönlich finde diesen Weg zu umständlich.~~ Scheint die einzige nutzerfreundliche Lösung zu sein. 2. Temporäres ULA generieren und per RA announcen Hat den Vorteil, dass es gerouted werden kann und wäre laut ChristianD auch gut fürs MQTT. Nachteil ist man kann nicht mehr auf eine feste Adresse zugreifen und ist von den RAs abhängig. 3. feste v6 LL Adresse bis zur Ersteinrichtung vergeben ~~Hier wurde im Chat angebracht, das würde nicht funktionieren. Das kann ich nicht nachstellen, bei mir im OpenWRT hänge ich via `ip addr add fe80::fff:1/64 dev XXX` die Adresse ans Interface und Firefox, Chrome und sogar Edge und IE können via http://[fe80::fff:1] aufs Web-Interface (luci unter uhttpd).~~ ~~Vielleicht könnte man ja 2+3 kombinieren.~~ Da die Browser (Firefox/Chrome) die zoneid nicht mögen und es ohne zoneid auf den meisten Betriebssystemen nicht funktioniert wird 3. auch nichts.

ChristianD commented

2021-01-16 09:19:28 +01:00

Ich hab das Problem mittlerweile begriffen.

ich finde 2. am besten wobei man überlegen kann ob man das temporäre generieren will oder einfach behalten will so das jeder Router sein eigenes ULA Netz hat.

Die Amateurfunker haben vorgerechnet (kömnnt ihr gerne nachrechnen ich bin zu Faul, Geburtstagsparadoxon und so ;)) das bei 10.000 generierten ULA Netzen die Chance einer Kollision irgendwo unter 1% liegt (ich meine es waren 5 Promille oder sogar 0,5 Promille). Wenn man noch hergeht und default nicht immer das ::/48 nimmt sondern da nochmal 16bit zufällig generiert und dann sowas hat wie ULA:3fda::/64 ist die Chance nochmal geringer einer automatischen Kollision (wobei natürlich jeder selbst das ganze /48 nutzen kann wenn jemand irgendwie will was aber wohl die Minderheit ist).

Ja wir geben damit das ICVPN auf. Anderseits, wer es nutzen will konfiguriert sich unser fd43 ULA drauf (dann müsste man das temporäre wieder verwerfen) und kommt ins ICVPN. Das ist so bisschen eine Designentscheidung jetzt.

Ich persönlich bin dafür das generierte erstmal immer zu behalten, mit der Option (vom User wählbar) es verwerfen zu können wenn man will und sich dann auch manuell z.b. ein fd43 für ICVPN konfigurieren zu können wenn man will. Also den User jede Möglichkeit offen lassen wenn er aber nichts spezielles macht bleibt das generierte ULA dauerhaft drauf.

Ich hab das Problem mittlerweile begriffen. ich finde 2. am besten wobei man überlegen kann ob man das temporäre generieren will oder einfach behalten will so das jeder Router sein eigenes ULA Netz hat. Die Amateurfunker haben vorgerechnet (kömnnt ihr gerne nachrechnen ich bin zu Faul, Geburtstagsparadoxon und so ;)) das bei 10.000 generierten ULA Netzen die Chance einer Kollision irgendwo unter 1% liegt (ich meine es waren 5 Promille oder sogar 0,5 Promille). Wenn man noch hergeht und default nicht immer das ::/48 nimmt sondern da nochmal 16bit zufällig generiert und dann sowas hat wie ULA:3fda::/64 ist die Chance nochmal geringer einer automatischen Kollision (wobei natürlich jeder selbst das ganze /48 nutzen kann wenn jemand irgendwie will was aber wohl die Minderheit ist). Ja wir geben damit das ICVPN auf. Anderseits, wer es nutzen will konfiguriert sich unser fd43 ULA drauf (dann müsste man das temporäre wieder verwerfen) und kommt ins ICVPN. Das ist so bisschen eine Designentscheidung jetzt. Ich persönlich bin dafür das generierte erstmal immer zu behalten, mit der Option (vom User wählbar) es verwerfen zu können wenn man will und sich dann auch manuell z.b. ein fd43 für ICVPN konfigurieren zu können wenn man will. Also den User jede Möglichkeit offen lassen wenn er aber nichts spezielles macht bleibt das generierte ULA dauerhaft drauf.

rohammer commented

2021-01-16 15:52:06 +01:00

ist keine Loesung.
fdff in der l3-firmware ist der Fehler. Das stammt aus der node-firmware. Ich kann mich noch gut erinnern, dass alle happy waren, keine mac-Adressen mehr umrechnen zu muessen.
Zur Erreichbarkeit nach dem ersten Flashen koennte man doch die OpenWrt default IP lassen. (ok, wieder ein Grund das configurenetwork umzubauen - und keiner hat Bock darauf)

2. ist keine Loesung. fdff in der l3-firmware ist der Fehler. Das stammt aus der node-firmware. Ich kann mich noch gut erinnern, dass alle happy waren, keine mac-Adressen mehr umrechnen zu muessen. Zur Erreichbarkeit nach dem ersten Flashen koennte man doch die OpenWrt default IP lassen. (ok, wieder ein Grund das configurenetwork umzubauen - und keiner hat Bock darauf)

jkimmel commented

2021-01-17 01:46:36 +01:00

`fdff::/64` ist ein Bug und muss weg

Da sind wir uns einig.

Also was koennen wir machen?

1. Langfristig alles per DNS erreichbar machen

Ich glaube da kommen wir nicht dran vorbei.

Unabhaengig davon, fuer was wir uns bei 2. entscheiden, ist mein Vorschlag mit router.local, oder freifunk.local immer auf den lokalen Router zu zeigen. Ob das nach dem Flashen dann erst einmal noch fdff::1, ein gewuerfeltes ULA Prefix, oder die vom Benutzer definierte Adresse ist, spielt keine Rolle, solange die TTL klein ist. Eventuell braucht es so garkeine manuelle Adresseingabe mehr.

configuregateway koennte auch noch deutlich die moeglichen URLs fuer das webinterface erzeugen. Einmal mit

http://[2001:db8::]/
die vom Benutzer definitert IP
http://router.local/ oder http://freifunk.local/
... koennen wir bei Gelegenheit mal drueber streiten, was uns da gefaellt
http://$hostname.local
macht Sinn bei aufbauten mit mehreren Routern im Netz, Stichwort VXLAN
http://$hostname.fff.community
... Wenn ich @Blackyfff richtig verstanden habe, soll das denke ich irgendwann mal moeglich sein.

Das waere denke ich ziemlich bequem und wenig Fehleranfaellig in der Benutzung.

2. Wie mit `fdff::/64` umgehen

a) `fdff::/64` vorerst behalten und entfernen sobald irgend ein anderes v6 Netz konfiguriert ist

Theoretisch muss das fdff::/64 erst weg, sobald man mit dem Freifunknetz reden will.
So koennte man fuer die Inbetriebnahme in der Doku (hab noch nicht nachgesehen, wo das alles verwendet wird, aber hier mal ein Vorgeschmack) alles so beibehalten, aber man muss sich damit abfinden, dass dann einmal die Verbindung abreist und man man ab dann die konfigurierte Adresse nehmen muss.
Vielleicht waere diese Aenderung auch die einfachste zu implementieren, eventuell sogar klein genug fuer das naechste Bugfix-release?
Das wird allerdings noch nicht das Optimum sein, aber ich wuerde gerade lieber mit etwas weniger Bequemlichkeit statt mit einem "kaputten" Netz leben.
Das kann auch unabhaengig von 1. passieren.

b) Immer ULA wuerfeln und `fdff::/64` komplett verwerfen

Ein gewuerfeltes ULA Prefix koennen wir freifunkintern "immer" routen. Aber wie das ULA Prefix erzeugen?

Da sehe ich 3 Varianten (im wesentlichen das, was Christian schon schrieb, aber nochmal mit meinen Worten):

Richtiges ULA Prefix wuerfeln
Das heist: Nach dem flashen wird versucht die Zeit zu synchronisieren. Wenn das klappt, oder ein timeout passiert wird ein richtiges ULA Prefix (/48) nach RFC 4193 gefwuerfelt.
Freifunk internes /48 vorgeben und die letzten 16 bits wuerfeln
Wir definieren ein ULA Prefix und erzeugen mit einem aehnlichen verfahren wie in RFC 4193 die restlichen bits fuer ein (temporaeres?) /64.
Ein /16 vorgeben und die Mac Adresse (oder Hash) vom Router anhaengen
Eine art Mischform. Vermutlich Pfusch, aber man laeuft relativ wenig Gefahr Ueberschneidungen zu haben. Ausserdem wuerde damit nur ein /64 erzeugt, also nicht ganz so verschwenderisch wie 1..

Fuer mich klingt 1. ziemlich verschwenderisch. Man koennte aber riskieren dieses Prefix tatsaechlich einfach dann konfiguriert zu lassen und fertig.

Bei 2. ist die Kollisionsgefahr schon etwas groesser. Hier muesste man es vielleicht so handhaben, dass hier das nicht mehr verwendet wird, sobald eine ordentliches Netz manuell konfiguriert wurde. Ob man dann aber viel gegenueber a) gewonnen hat...? Spielt halt gut mit ICVPN zusammen und es ist ausgeschlossen irgendwelche andere, reservierte Netze kaputt zu machen.

Tjo und 3. war halt so eine Schnapsidee. Aber ich wollte sie mal formulieren, falls es jemand auf andere Gedanken bringt.

c) ?

Viel andere Wege sehe ich gerade leider nicht. Ich waere allerdings damit einverstanden zunaechst a) umzusetzen, langfristig aber eine Variante aus b) anzustreben - ausser uns faellt etwas besseres ein.

Was klappt nicht

(feste) Link Local Adresse

Browser werdens nicht richtig implementieren, siehe

Ausserdem waere es auch wegen den Zond-IDs ein komplettes Durcheinander fuer die Dokumentation.

Link Local Adresse in DNS

Ich habe probiert eine LL per DNS auszuliefern, in der Hoffnung, dass automatisch das richtige Interface benutzt wird - funktioniert nur halb. Dinge wie ping schaffen es, im Browser gehts nicht. Geht moeglicherweise besser mit mDNS, aber das laeuft nicht ueberall.

Ungeklaert: Preferred Lifetime von `fdff::/64` auf 0 setzen

Kann man das im OpenWRT ueberhaupt pro Prefix definieren?
- https://openwrt.org/docs/techref/odhcpd sieht nicht so vielversprechend aus
Wie handhaben das die verschiedenen Betriebssysteme?

Was wollen wir nicht

NAT6 fuer `fdff::/64`

Aufgefallen ist das ganze ja, weil trotz konfigurierter globalen Adresse die fdff Adresse als Sourceadresse fuer unser internes Freifunknetz fd43... benutzt wurde. Man koennte das natuerlich natten... aber 🤮

Alles per IPv4 managen

Weil da klappt das ja!
Ja ne.. klappt halt auch nur wegen NAT, oder weil man extra Adressen reservieren muss. Dann haben wir ja nichts gewonnen, weil man koennte dann ja auch einfach ein fd43 Prefix reservieren. Sportliches Ziel sollten einfache IPv6-only Knoten sein bzw. bleiben.

[2]: https://wiki.freifunk-franken.de/mediawiki/index.php?title=+Spezial%3ASuche&search=fdff&go=Seite "Suchergebnis zu fdff im Freifunkwiki`
[3]: https://tools.ietf.org/html/rfc4193#section-3.2.2 "RFC 4193"
[4]: ca97ec836d
[5]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2
[6]: https://openwrt.org/docs/techref/odhcpd

### `fdff::/64` ist ein Bug und muss weg Da sind wir uns einig. Also was koennen wir machen? #### 1. Langfristig alles per DNS erreichbar machen Ich glaube da kommen wir nicht dran vorbei. Unabhaengig davon, fuer was wir uns bei **2.** entscheiden, ist mein Vorschlag mit [`router.local`](1), oder [`freifunk.local`](1) immer auf den lokalen Router zu zeigen. Ob das nach dem Flashen dann erst einmal noch `fdff::1`, ein gewuerfeltes ULA Prefix, oder die vom Benutzer definierte Adresse ist, spielt keine Rolle, solange die TTL klein ist. Eventuell braucht es so garkeine manuelle Adresseingabe mehr. `configuregateway` koennte auch noch deutlich die moeglichen URLs fuer das webinterface erzeugen. Einmal mit * `http://[2001:db8::]/` die vom Benutzer definitert IP * `http://router.local/` oder `http://freifunk.local/` ... koennen wir bei Gelegenheit mal drueber streiten, was uns da gefaellt * `http://$hostname.local` macht Sinn bei aufbauten mit mehreren Routern im Netz, Stichwort VXLAN * `http://$hostname.fff.community` ... Wenn ich @Blackyfff richtig verstanden habe, soll das denke ich irgendwann mal moeglich sein. Das waere denke ich ziemlich bequem und wenig Fehleranfaellig in der Benutzung. #### 2. Wie mit `fdff::/64` umgehen ##### a) `fdff::/64` vorerst behalten und entfernen sobald irgend ein anderes v6 Netz konfiguriert ist *Theoretisch* muss das `fdff::/64` erst weg, sobald man mit dem Freifunknetz reden will. So koennte man fuer die Inbetriebnahme in der Doku (hab noch nicht nachgesehen, wo das alles verwendet wird, aber [hier mal ein Vorgeschmack](2)) alles so beibehalten, aber man muss sich damit abfinden, dass dann einmal die Verbindung abreist und man man ab dann die konfigurierte Adresse nehmen muss. Vielleicht waere diese Aenderung auch die einfachste zu implementieren, eventuell sogar klein genug fuer das naechste Bugfix-release? Das wird allerdings noch nicht das Optimum sein, aber ich wuerde gerade lieber mit etwas weniger Bequemlichkeit statt mit einem "kaputten" Netz leben. Das kann auch unabhaengig von **1.** passieren. ##### b) Immer ULA wuerfeln und `fdff::/64` komplett verwerfen Ein gewuerfeltes ULA Prefix koennen wir freifunkintern "immer" routen. Aber wie das ULA Prefix erzeugen? Da sehe ich 3 Varianten (im wesentlichen das, was Christian schon schrieb, aber nochmal mit meinen Worten): 1. ***Richtiges* ULA Prefix wuerfeln** Das heist: Nach dem flashen wird versucht die Zeit zu synchronisieren. Wenn das klappt, oder ein timeout passiert wird ein richtiges ULA Prefix (`/48`) nach [RFC 4193](3) gefwuerfelt. 2. **Freifunk internes `/48` vorgeben und die letzten 16 bits wuerfeln** Wir definieren ein ULA Prefix und erzeugen mit einem aehnlichen verfahren wie in [RFC 4193](3) die restlichen bits fuer ein (temporaeres?) `/64`. 3. **Ein `/16` vorgeben und die Mac Adresse (oder Hash) vom Router anhaengen** Eine art Mischform. Vermutlich Pfusch, aber man laeuft relativ wenig Gefahr Ueberschneidungen zu haben. Ausserdem wuerde damit nur ein `/64` erzeugt, also nicht ganz so verschwenderisch wie `1.`. Fuer mich klingt `1.` ziemlich verschwenderisch. Man koennte aber riskieren dieses Prefix tatsaechlich einfach dann konfiguriert zu lassen und fertig. Bei `2.` ist die Kollisionsgefahr schon etwas groesser. Hier muesste man es vielleicht so handhaben, dass hier das nicht mehr verwendet wird, sobald eine ordentliches Netz manuell konfiguriert wurde. Ob man dann aber viel gegenueber **a)** gewonnen hat...? Spielt halt gut mit ICVPN zusammen und es ist ausgeschlossen irgendwelche andere, reservierte Netze kaputt zu machen. Tjo und `3.` war halt so eine Schnapsidee. Aber ich wollte sie mal formulieren, falls es jemand auf andere Gedanken bringt. ##### c) ? Viel andere Wege sehe ich gerade leider nicht. Ich waere allerdings damit einverstanden zunaechst **a)** umzusetzen, langfristig aber eine Variante aus **b)** anzustreben - ausser uns faellt etwas besseres ein. ----- ### Was klappt nicht #### (feste) Link Local Adresse Browser werdens nicht richtig implementieren, siehe * [https://github.com/whatwg/url/commit/ca97ec836d3ff246d5c53f420b0eb2798f2a982c](4) * [https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2](5) Ausserdem waere es auch wegen den Zond-IDs ein komplettes Durcheinander fuer die Dokumentation. #### Link Local Adresse in DNS Ich habe probiert eine LL per DNS auszuliefern, in der Hoffnung, dass automatisch das richtige Interface benutzt wird - funktioniert nur halb. Dinge wie `ping` schaffen es, im Browser gehts nicht. Geht moeglicherweise besser mit `mDNS`, aber das laeuft nicht ueberall. #### Ungeklaert: Preferred Lifetime von `fdff::/64` auf 0 setzen * Kann man das im OpenWRT ueberhaupt pro Prefix definieren? * [https://openwrt.org/docs/techref/odhcpd](6) sieht nicht so vielversprechend aus * Wie handhaben das die verschiedenen Betriebssysteme? ### Was wollen wir nicht #### NAT6 fuer `fdff::/64` Aufgefallen ist das ganze ja, weil trotz konfigurierter globalen Adresse die `fdff` Adresse als Sourceadresse fuer unser internes Freifunknetz `fd43...` benutzt wurde. Man koennte das natuerlich natten... aber 🤮 #### Alles per IPv4 managen Weil da klappt das ja! Ja ne.. klappt halt auch nur wegen NAT, oder weil man extra Adressen reservieren muss. Dann haben wir ja nichts gewonnen, weil man koennte dann ja auch einfach ein `fd43` Prefix reservieren. Sportliches Ziel sollten einfache IPv6-only Knoten sein bzw. bleiben. ----- [1]: https://en.wikipedia.org/wiki/.local "Wikipedia zu .local" [2]: https://wiki.freifunk-franken.de/mediawiki/index.php?title=+Spezial%3ASuche&search=fdff&go=Seite "Suchergebnis zu `fdff` im Freifunkwiki` [3]: https://tools.ietf.org/html/rfc4193#section-3.2.2 "RFC 4193" [4]: https://github.com/whatwg/url/commit/ca97ec836d3ff246d5c53f420b0eb2798f2a982c [5]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2 [6]: https://openwrt.org/docs/techref/odhcpd

ChristianD commented

2021-01-17 08:11:26 +01:00

Das heist: Nach dem flashen wird versucht die Zeit zu synchronisieren. Wenn das klappt, oder ein timeout passiert wird ein richtiges ULA Prefix (/48) nach RFC 4193 gefwuerfelt.

OpenWRT hat natürlich das gleiche Problem mit der Zeit und ich hab mal geguckt wie die das lösen:
https://github.com/openwrt-mirror/openwrt/blob/master/package/base-files/files/etc/uci-defaults/12_network-generate-ula

Fuer mich klingt 1. ziemlich verschwenderisch.

IPv6 ist dafür da, verschwendet zu werden. Rechne mal nach wieviel /48 in den fd00::/8 drinnen stecken ;)

Bei 2. ist die Kollisionsgefahr schon etwas groesser.

Man könnte natürlich vor dem announcen prüfen ob das Netz schon announced wird.

> Das heist: Nach dem flashen wird versucht die Zeit zu synchronisieren. Wenn das klappt, oder ein timeout passiert wird ein richtiges ULA Prefix (/48) nach RFC 4193 gefwuerfelt. OpenWRT hat natürlich das gleiche Problem mit der Zeit und ich hab mal geguckt wie die das lösen: https://github.com/openwrt-mirror/openwrt/blob/master/package/base-files/files/etc/uci-defaults/12_network-generate-ula > Fuer mich klingt 1. ziemlich verschwenderisch. IPv6 ist dafür da, verschwendet zu werden. Rechne mal nach wieviel /48 in den fd00::/8 drinnen stecken ;) > Bei 2. ist die Kollisionsgefahr schon etwas groesser. Man könnte natürlich vor dem announcen prüfen ob das Netz schon announced wird.

Blackyfff commented

2021-01-17 23:12:48 +01:00

Für 2. a) wäre es auch möglich die fdff::1 Adresse zumindest auf dem Router zu behalten.
Also man wirft das Netz weg legt aber die fdff::1/128 auf das loopback des Routers. Ich konnte allerdings noch nicht testen ob der Router diese /128 dann als Source Adresse nehmen würde wenn er mit fd43 sprechen möchte, ansonsten müsste man es vieleicht an ein dummy interface mit hoher metric hängen und eine extra Route dafür einrichten. Aber so müsste man nicht auf auf ein dynamisches DNS setzen, sondern könnte z.B. router.fff.community statisch auf fdff::1 setzen.

Für 2. a) wäre es auch möglich die fdff::1 Adresse zumindest auf dem Router zu behalten. Also man wirft das Netz weg legt aber die fdff::1/128 auf das loopback des Routers. Ich konnte allerdings noch nicht testen ob der Router diese /128 dann als Source Adresse nehmen würde wenn er mit fd43 sprechen möchte, ansonsten müsste man es vieleicht an ein dummy interface mit hoher metric hängen und eine extra Route dafür einrichten. Aber so müsste man nicht auf auf ein dynamisches DNS setzen, sondern könnte z.B. router.fff.community statisch auf fdff::1 setzen.

jkimmel commented

2021-01-17 23:57:24 +01:00

Fuer fdff auf lo besteht ueberhaupt keine Notwendigkeit, wenn DNS funktioniert. Viel zu einfach einen passenden Eintrag dem dnsmasq beizubringen.

Blackyfff commented

2021-01-18 00:14:31 +01:00

Absolut notwendig nicht.
Aber das würde ein paar Probleme umgehen:

die Dokumentationen bleiben weiterhin gültig (bezüglich fdff::1, natürlich nicht die zum Netz)
der DNS Eintrag wäre statisch und könnte somit auch von allen anderen DNS-Servern verteilt werden (für den Fall man betreibt keinen eigenen DNS)
weniger Code, weil es nur ein statischer Eintrag ist, der mit der Firmware ausgeliefert wird und nicht zur Laufzeit ermittelt werden muss. (auf der anderen Seite hat man dann natürlich den Code für das anhängen ans lo)

Absolut notwendig nicht. Aber das würde ein paar Probleme umgehen: 1. die Dokumentationen bleiben weiterhin gültig (bezüglich fdff::1, natürlich nicht die zum Netz) 2. der DNS Eintrag wäre statisch und könnte somit auch von allen anderen DNS-Servern verteilt werden (für den Fall man betreibt keinen eigenen DNS) 3. weniger Code, weil es nur ein statischer Eintrag ist, der mit der Firmware ausgeliefert wird und nicht zur Laufzeit ermittelt werden muss. (auf der anderen Seite hat man dann natürlich den Code für das anhängen ans lo)

jkimmel commented

2021-01-18 00:21:15 +01:00

Aber wenn DNS geht, dann brauchts auch kein fdff mehr :) Ich will am Ende ja weg von irgendwelchen IP Adressen. Fuer Bequemlichkeit hat man Hostnames erfunden. Wir sollten Sie nutzen.

jkimmel referenced a pull request that will close this issue

2021-01-19 09:17:42 +01:00

layer3: move from fixed address to fixed hostname #80

SebaBe commented

2023-01-05 11:54:48 +01:00

Mein erster Gedanke beim durchlesen, ICVPN sollte einfach kein Blocker sein.
Wie schon öfters gesagt bin ich fürs abschalten.

Das Ding bringt für >99% der User keine Vorteile und der Rest findet auch eine individuelle Lösung, falls er denn eine braucht.

Würde viele andere Vorteile mit sich bringen und quasi keine Nachteile...

Mein erster Gedanke beim durchlesen, ICVPN sollte einfach kein Blocker sein. Wie schon öfters gesagt bin ich fürs abschalten. Das Ding bringt für >99% der User keine Vorteile und der Rest findet auch eine individuelle Lösung, falls er denn eine braucht. Würde viele andere Vorteile mit sich bringen und quasi keine Nachteile...

fbl commented

2023-01-30 15:11:15 +01:00

Die fdff Adressen nicht zu konfigurieren löst dieses Problem leider nicht, denn wenn beispielsweise auf dem WAN-Interface eine fc00::/7 Adresse konfiguriert ist, dann brichts trotzdem. Damit das später ordentlich funktioniert brauchen wir entweder eine saubere Isolation zwischen Freifunk und WAN (#270) oder eine andere Lösung.

Theoretisch könnte das Entfernen der fdff Adressen simpel umgangen werden, indem die Source Address Selection angepasst wird. Mit der glibc ginge das über /etc/gai.conf. Die musl bietet leider keine ähnliche Möglichkeit: "So far the label/precedence table cannot be customized" (musl source, src/network/lookup_name.c)

So oder so sollten wir dieses Problem möglichst bald angehen.

Die fdff Adressen nicht zu konfigurieren löst dieses Problem leider nicht, denn wenn beispielsweise auf dem WAN-Interface eine fc00::/7 Adresse konfiguriert ist, dann brichts trotzdem. Damit das später ordentlich funktioniert brauchen wir entweder eine saubere Isolation zwischen Freifunk und WAN (#270) oder eine andere Lösung. Theoretisch könnte das Entfernen der fdff Adressen simpel umgangen werden, indem die Source Address Selection angepasst wird. Mit der glibc ginge das über `/etc/gai.conf`. Die musl bietet leider keine ähnliche Möglichkeit: `"So far the label/precedence table cannot be customized"` (musl source, `src/network/lookup_name.c`) So oder so sollten wir dieses Problem möglichst bald angehen.

fbl added this to the next-bugfix milestone 2023-01-30 15:11:19 +01:00

fbl removed this from the next-bugfix milestone 2023-02-21 23:55:36 +01:00

jkimmel commented

2023-03-10 17:37:32 +01:00

So Workaround für /etc/rc.local.fff_userconfig, weil es mich jetzt wirklich einmal zu viel angekotzt hat:

#!/bin/sh

for ip in $(uci get network.client.ip6addr); do
        case $ip in
                fdff*) uci del_list network.client.ip6addr=$ip ;;
        esac
done

uci commit
reload_config

So Workaround für `/etc/rc.local.fff_userconfig`, weil es mich jetzt wirklich einmal zu viel angekotzt hat: ```sh #!/bin/sh for ip in $(uci get network.client.ip6addr); do case $ip in fdff*) uci del_list network.client.ip6addr=$ip ;; esac done uci commit reload_config ```

jkimmel commented

2024-03-07 12:29:03 +01:00

Noch ein Punkt, wo die fdff::/64 Adressen Probleme machen: syncthing geht kaputt.
Syncthing lernt die Adressen der anderen Peers über mehrere discovery Mechanismen. So weit ich weiß, werden dabei Adressen aus dem lokalem Netz vor ULA Adressen vor GUA, vor IPv4 priorisiert.
Damit werden fast immer die fdff Adressen probiert, da es für syncthing so aussieht, als wäre das Peer direkt im selben Netz erreichbar. Einen Fallback wie bei IPv4 gibt es scheinbar bei IPv6 (IMHO zu Recht) nicht.

Noch ein Punkt, wo die `fdff::/64` Adressen Probleme machen: [syncthing](https://syncthing.net/) geht kaputt. Syncthing lernt die Adressen der anderen Peers über mehrere discovery Mechanismen. So weit ich weiß, werden dabei Adressen aus dem lokalem Netz vor ULA Adressen vor GUA, vor IPv4 priorisiert. Damit werden fast immer die `fdff` Adressen probiert, da es für syncthing so aussieht, als wäre das Peer direkt im selben Netz erreichbar. Einen Fallback wie bei IPv4 gibt es scheinbar bei IPv6 (IMHO zu Recht) nicht.

fbl commented

2024-03-07 12:31:28 +01:00

ULA über GUA zu bevorzugen ist aber auch so n bisschen kaputt.

jkimmel commented

2024-03-07 12:36:21 +01:00

Spielt aber in dem Fall keine Rolle und ich kann mich auch täuschen.

fbl commented

2024-03-07 12:38:14 +01:00

Ich vermute ja eher, dass die ULA deshalb gewinnt (falls sie denn überhaupt zuverlässig gewinnt und das nicht random ist, wovon ich bisher immer ausging), weil most-specific gewinnt. Und da wir fdff::/64 ja quasi in jedem Netz verwenden ist die Wahrscheinlichkeit extrem hoch dass die fdff:: am nähesten dran liegt.

Tut für die fdff:: baustelle aber eh nichts zur Sache.

Ich vermute ja eher, dass die ULA deshalb gewinnt (falls sie denn überhaupt zuverlässig gewinnt und das nicht random ist, wovon ich bisher immer ausging), weil most-specific gewinnt. Und da wir fdff::/64 ja quasi in jedem Netz verwenden ist die Wahrscheinlichkeit extrem hoch dass die fdff:: am nähesten dran liegt. Tut für die fdff:: baustelle aber eh nichts zur Sache.

jkimmel commented

2024-03-07 12:41:12 +01:00

Syncthing teilt Adressen in WAN und LAN Adressen. fdff schaut nach LAN aus (weil gleiches /64, auch wenn anderes Netz) und gewinnt.

Syncthing teilt Adressen in WAN und LAN Adressen. `fdff` schaut nach LAN aus (weil gleiches /64, auch wenn anderes Netz) und gewinnt.

fbl commented

2024-03-18 23:21:48 +01:00

Ich möchte die Diskussion hierzu gerne noch einmal frisch aufnehmen.

Folgende Ideen:

mDNS benutzen
- Würde im Prinzip auch mit Link Local Adresse funktionieren 👍
- Android kann seit Ende 2021 ebenfalls endlich mDNS auflösen 👍
  - allerdings scheinbar nur wenn die Antwort ein Unicast ist 👎
  - das ist beim OpenWrt umdns leider nicht der Fall
dnsmasq kann verschiedene hilfreiche Dinge, z.B. interface-name
- Das würde dann analog zu #80 funktionieren, nur mit weniger manuell.
- Dafür würde ich auf keinen Fall eine echte TLD verwenden, denn das bricht mit dnssec
  - Stattdessen sollte dafür .lan verwendet werden

Eine Kombination der oben genannten Ideen könnte es sehr einfach erlauben fdff auf layer3 sehr einfach nach Erstkonfiguration zu entfernen. Vielleicht sogar (mDNS) vollständig.

Ich möchte die Diskussion hierzu gerne noch einmal frisch aufnehmen. Folgende Ideen: - mDNS benutzen - Würde im Prinzip auch mit Link Local Adresse funktionieren 👍 - Android kann seit Ende 2021 ebenfalls endlich mDNS auflösen 👍 - allerdings scheinbar nur wenn die Antwort ein Unicast ist 👎 - das ist beim OpenWrt `umdns` leider nicht der Fall - dnsmasq kann verschiedene hilfreiche Dinge, z.B. `interface-name` - Das würde dann analog zu #80 funktionieren, nur mit weniger manuell. - Dafür würde ich auf keinen Fall eine echte TLD verwenden, denn das bricht mit dnssec - Stattdessen sollte dafür `.lan` verwendet werden Eine Kombination der oben genannten Ideen könnte es sehr einfach erlauben fdff auf layer3 sehr einfach nach Erstkonfiguration zu entfernen. Vielleicht sogar (mDNS) vollständig.

fbl commented

2024-03-18 23:42:14 +01:00

RFC sagt, dass umdns das falsch macht. Mein Android sendet einen mDNS query, dessen source Port != 5353 ist. Dann gilt: https://datatracker.ietf.org/doc/html/rfc6762#section-6.7

avahi-nodbus-daemon machts richtig, damit klappts auch unter Android. Kostet uns aber 128 KiB auf einem WDR4900.

RFC sagt, dass `umdns` das falsch macht. Mein Android sendet einen mDNS query, dessen source Port != 5353 ist. Dann gilt: https://datatracker.ietf.org/doc/html/rfc6762#section-6.7 `avahi-nodbus-daemon` machts richtig, damit klappts auch unter Android. Kostet uns aber 128 KiB auf einem WDR4900.

fbl commented

2024-03-18 23:44:30 +01:00

Hilft aber leider alles nicht so recht, denn wenn am Router nur die Link-Local Adresse konfiguriert ist, dann glauben Geräte dass keine Adressen vergeben werden und trennen sich wieder vom Netzwerk.

jkimmel commented

2024-03-19 01:20:38 +01:00

Also ich bin ja eher für .internal, weil dazu gerade ein RFC in Arbeit ist.

Und ja. mDNS und link-local Adressen sind irgendwie nicht die Lösung. Echt Schade, dass man das auf drölf Spezialszenarien optimiert hat, aber simples, lokales, infrastrukturfreies DNS ist damit echt nicht so simpel.

Ansonsten hatte ich noch folgende Ideen:

Der Router kann ruhig die fdff::/128 Adresse haben und immer behalten, z.b. mit auf lo legen.
Solange der Router kein IPv6 Netz konfiguriert hat, kann man prinzipiell ein fdff::/64 Prefix verteilen, oder man würfelt eine anderes Prefix aus einem Bereich, den wir in Zukunft auf den Routen im Babel filtern.

Das hätte den riesigen Vorteil, dass wir unsere Dokumentation nicht anpassen müssen und man weiterhin den Router mit einer einfach IPv6 Adresse erreicht.
Aber ein Client bekommt niemals eine fdff::/64, wenn der Router ordentlich im Netz mitspielt und es kann da keine Verwirrungen mehr geben.

Also ich bin ja eher für `.internal`, weil dazu gerade ein [RFC](https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-internal-00#ref-IANA.SUN) in Arbeit ist. Und ja. mDNS und link-local Adressen sind irgendwie nicht die Lösung. Echt Schade, dass man das auf drölf Spezialszenarien optimiert hat, aber simples, lokales, infrastrukturfreies DNS ist damit echt nicht so simpel. Ansonsten hatte ich noch folgende Ideen: - Der Router kann ruhig die `fdff::/128` Adresse haben und immer behalten, z.b. mit auf `lo` legen. - Solange der Router kein IPv6 Netz konfiguriert hat, kann man prinzipiell ein `fdff::/64` Prefix verteilen, oder man würfelt eine anderes Prefix aus einem Bereich, den wir in Zukunft auf den Routen im Babel filtern. Das hätte den riesigen Vorteil, dass wir unsere Dokumentation nicht anpassen müssen und man weiterhin den Router mit einer einfach IPv6 Adresse erreicht. Aber ein Client bekommt niemals eine `fdff::/64`, wenn der Router ordentlich im Netz mitspielt und es kann da keine Verwirrungen mehr geben.

Sign in to join this conversation.