Nur um sicher zu gehen:
Hat sich an der site.conf seit dem 2. Dezember 2014 nichts mehr getan?
https://github.com/ffrl/sites-ffrl/commit/545cefb46060346aef440d3d310e70654d1bbb0a
https://github.com/ffrl/sites-ffrl/commits/master/site-rheinufer/site.conf
Ich dätte schwören können, dass da jetzt mehr als 4 Supernodes aktiv sind.
Den richtigen Branch wählen, z.B.:
https://github.com/ffrl/sites-ffrl/blob/v2014.4/site-rheinufer/site.conf
Daraus ergibt sich eine Frage von mir, müsste nicht durch das umstellen der IPv6 Adressen auf das ffrl Netz nicht auch der prefix in der site.conf geändert werden?
Hi MrMM,
Nee das ist nur für ULA IPs, sprich die privaten IP-Adressen die wir für NTP sowie interne Update Server nutzen. Diese ist natürlich gleich geblieben 
Gruß
Cyrus
Wir haben angedacht in Aachen komplett mit den öffentlichen v6 Adressen zu arbeiten und diese auch entsprechend als prefix in die site.conf zu schreiben.
Hast du Bedenken?
Die ULA-Adressen sollten im bundesweiten Freifunk-Netz geroutet werden. Bisher läuft das bei uns noch nicht, ist aber in Planung. Bis dahin könnt ihr diese als verlässliche IP für Dienste verwenden, die auch bei geändertem oder defekten Routing der public IPs erreichbar bleiben.
Nach dem Wechsel werden wir für Rheinufer auf lange Sicht das Prefix nicht mehr wechseln. 2a03:2260:40::/48 bleibt also stabil. Die Frage ist nur, wie wir die große Domäne in kleinere aufteilen. Ich hoffe, dass das dynamisch hinbekommen, also die 65000 Subnetze irgendwie verteilen. Dann bekommen die Clients neue Präfixe oberhalb von 2a03:2260:40::/64.
Also ULA ist ein muss, schon alleine weil wir nicht möchten das die Public IPs von anderen Maschinen als den Gateways verteilt wird. Außerdem kann es dabei zu Problemen kommen (Auf jeder Node läuft per Default ein Radvd für die Clients, dieser könnte Probleme verursachen wenn er das selbe Prefix wie die Gateways announcen möchte).
Aber auch die Punkte von @nomaster sind wichtig, denn wenn keine Supernode Verbindung besteht wird jeder Client die Public IP als „Funktionierende Internetverbindung“ deuten.
Daher wird auf Nodes ausschließlich das ULA Netz Announced und von den Gateways der Public IP Prefix.
Das liegt aber nicht daran, dass es aus dem ULA-Space stammende Adressen sind, sondern dass der RADVD auf den Nodes nicht diese als Default Router announced. Korrekt?
Das stimmt :).
ULA Adressen sollten aber auch bei vorhandener Default-Route ins Public Internet, diese niemals als Source-Adresse verwenden. Daher ist es quasi ein „doppelter Schutz“ 
Mittlerweile sind jedoch einige Communities dazu übergegangen nur noch die Public Prefixe zu nutzen.
Im Ruhrgebiet haben wir diesen Change auch bereits gemacht.
Würde ich aber an dieser Stelle nicht empfehlen, jeder Änderung am Prefix muss dann mit einer Firmware Update ausgerollt werden für etwas was sowieso von den Supernodes abhängig ist 
Public IPs sollten nur von Gateways verteilt werden und wenn diese auch einen Uplink bieten 
Das erklär mal den Teams OpenWRT, Linux oder irgendwem der verantwortlich ist…das ist ja lediglich eine Gegenmaßnahme gegen das kaputte v6 Handling, weil die Menge der IP Adressen durch Memory Leaks über die Neighbor Table die Gluon Router zum Absturz bringt…
Also wir haben 2 Prefixes, Public sowie ULA.
Public wird von den Supernodes announced (bzw nur zwei von den Supernodes damit kein RA Sturm losbricht). Und ULA halt nur von den Nodes 