Auf ICVPN-V4 verzichten und IP-Bereiche größer machen


#1

Moin,

nur 2000 IPs pro Domäne kann schnell mal dünn werden bei größeren Veranstaltungen. Das ist eigentlich schade und unnötig. ICVPN-V4 machen wir ohnehin nicht.

Daher schlage ich vor, dass wir darauf auch langfristig verzichten und einfach jeder Domäne ein /16 geben. Dann hätte jedes Gateway genug IPs im Vorrat und der Spuk ist vorbei.

Konkret braucht Paulo hier z. B. eine größere Menge IPs: 100x WLAN Landesgestüt

@Adminteam

Grüße
Matthias


#3

Die Option sich doch ins ICVPN anzubinden sollte wenn möglich offen bleiben, man kann ja eine Anfrage für weitere IPs nach noch einem 16er Bereich rausschicken.
Ansonsten bin ich der meinung das es doch zu viele Domänen gibt, vor allem viele in denen nichtmal 10 Knoten stehen :wink:
Bei Gronau bin ich mir nicht sicher ob es dort nicht sogar ein eigenes /16 Netz gibt.


#4

Größere IP-Bereiche zu bekommen, halte ich für unrealistisch. Die sind jetzt schon - zu recht - etwas knauserig.

Es macht doch eh niemand ICVPN von uns, also warum hier nicht einen klaren Schnitt setzen.

Es bringt uns auch nichts, zwei Minnidomänen zusammen zu legen und dort doppelt so viele IPs zu haben. Das Problem tritt eher in den großen Domänen auf. Wir haben das jetzt einmal klar aufgeteilt und können so auch wieder wachsen, ohne dass es Chaos gibt.


#5

Ich hatte schon mal wo geäußert, dass IPv4 für mich tot ist und nur noch lokal sinnvoll ist.


#6

ICVPN (derzeit auch noch v4) halte ich genauso erstrebenswert, wie ein Routing unserer Domänen untereinander (über die privaten IPs).
Alles andere ist, in meinen Augen, nicht mehr wirklich der Freifunkgedanke. (Jaja, ich weiß; der alte Fundi …)


#7

Ich denke, dass selbst Twitter eher IPv6 macht, als das wir den ICVPN wieder aufbauen. Außerdem ist IPv4 für mich eine tote Technologie, in die ich möglichst keine Zeit mehr investieren möchte. Von daher bin ich dafür einfach die IP Bereiche zu vergrößern und damit auf die Möglichkeit zu verzichten sich an den ICVPNv4 anzuschließen, anstatt viel Energie und Zeit darin zu investieren es doch noch irgendwie mit einem beschränkten IPv4 Bereich hinzubekommen.


#8

ICVPN ja aber warum das dann v4 sein muss verstehe ich nicht und halte es daher für überflüssig. Also +1 für @mpw s Vorschlag


#9

Dass wir kein ICVPN machen liegt lediglich daran dass wir es bei früheren Anläufen nicht hinbekommen haben und es in letzter Zeit nicht angegangen wurde.

Ich bin klar dafür die Möglichkeit für das ICVPN auch für IPv4 zu erhalten da das immer noch ein integraler Bestandteil der Freifunk Gemeinschaft ist.
Überflüssig ist IPv4 dort nur wenn auch die anderen Teilnehmer des ICVPN kein IPv4 mehr verwenden.


#10

Stimmt das wirklich?
Ich habe ICVPN nie erlebt und es auch nie vermisst.
Ich weiss auch nicht wofür man es bei v6 braucht.


#11

Kann sich ja ändern, wenn es mal funktioniert.

Meinst Du die globalen v6-Adressen? Die haben mit Freifunk recht wenig zu tun; die sind nur Teil eines unserer Services.


#12

Ich sehe nicht warum ich noch ein Tunnel durch das öffentliche Internet bauen soll wenn ich die Dinge auch direkt im öffentlichen Internet erreichen kann. Du sagst das wäre nur ein Dienst. Genau, ist ICVPN auch. Und Internet ist weiterhin die Killer App :slight_smile:

Vielleicht habe ich den Sinn von ICVPN nicht verstanden.
Ich dachte immer das dient dazu das man Dinge in einem FF Netz aus einem anderen FF Netz erreichen kann. Mit v6 braucht man dazu kein VPN/Router/BGP Sessions.
Kann man machen, ist aber nicht besser.

Irgendwas an Resourcen - die wir gerade gut gebrauchen können - daher zurückzuhalten da vielleicht irgendwann jemand was damit machen will finde ich nicht gut.
Wenn jemand v4 ICVPN machen will kann man die Adressen ja zurückholen, wir strukturieren das Zeug ja eh laufend um.

Ach so, Freifunk ist nur kaputtes v4 auf nicht routbaren Adressen? Hmm.


#13

Genau Das; zuzüglich kaputtem v6 …
Aber wir können den Schrunz ja auch abschalten und einfach Internetprovider werden.


#14

Ich glaube diese Diskussion hat für uns beide das Ende des Machbaren erreicht :wink:


#15

:wink:


#16

Wir können es uns ja jetzt auch leisten ständig mal was umzubauen, um Vor- und Nachteile zu testen (dank Automatisierungen). Ein weiteres Argument gegen das ICVPNv4 Veto. :blush:


#17

Das ICVPN ist ein direkter Interconnect zwischne den Freifunk Cummunities.
Hierzu gehört unter anderem auch die aüflösuung der internen TopLevel domains wie .ffms, .ffpb, …

Selbst bei verwendung von öffentlichen IPv6-Adressen auf beiden Seiten ist immernoch konsens dass dieser Interconnect direkt erfolgen soll.
Und längst nicht alle FF Communities haben öffentliche IPv6 Adressen aus den verschiedensten Gründen.


#18

Der Punkt, den ich halt nicht verstehe: Wenn das so toll ist oder euch beiden so wichtig ist, warum ist das nicht längst konfiguriert?

Ich habe von Anfang an ganz offen gesagt, dass ich nichts davon halte und da keine Zeit investieren werde. Ihr beide habt genauso Zugriff auf die Server, macht es, wenn ihr Bock habt. Testen, dann ins Ansible und dann ist es ein für alle mal einsatzbereit.

Derzeit sind mir keine internen Dienste in anderen Communities bekannt, auf die man dadurch Zugriff bekäme. Ich stelle einfach mal eine These auf:

Wenn es mal einen tollen, internen Dienst geben wird, wird dieser auch per IPV6 erreichbar sein.

Und, wenn wir die drei Pakete, die da im Monat von unserer Community zu einer anderen gehen, nicht durch das FFRL-Backbone, sondern direkt verschicken möchten, dann können wir das immer noch rein für V6 machen.

Zu bedenken wäre noch ICVPN als Exitbackup, wenn der FFRL mal komplett ausfallen sollte. Ich bezweifle einfach, dass es eine Community gibt, die die 4 Gbit/s, die da derzeit so anfallen, ansatzweise übernehmen könnte. Daher halte ich das nicht für eine praktikable Lösung. Ich glaube eher, dass die Communities dann anfangen sich schnell VPN-Tunnel zu kaufen.


#19

Wir haben derzeit den Zustand, dass wenn eines von zwei Gateways einer Domäne wegbricht nicht mehr ausreichend viele IPv4 Adressen für die Clients (eine Stunde Lease Dauer) zur Verfügung stehen.
Das heißt Freifunk ist für viele Nutzer nicht mehr nutzbar.

Ärgerlich: Bei einem Ausfall eines Gateways sind gleich mehrere Domänen betroffen. Besonders ärgerlich: Das andere Gateway könnte den Ausfall problemlos kompensieren, wenn es denn genügend IPv4 Adressen verteilen dürfte.

Da wir derzeit kein ICVPN machen und man die Address-Konfiguration sehr schnell wieder ändern kann, wenn wir irgendwann dann doch vielleicht gegebenenfalls eventuell womöglich ICVPN machen, sehe ich kein Problem darin den gesamten 10.0.0.0/8 Space für Freifunk Münsterland zu verwenden.

Ich gehe sogar so weit: Ich denke es wäre noch nicht mal eine Abstimmung darüber nötig, da Niemandem zu keiner Zeit auch nur der geringste Nachteil dadurch entsteht. Gegenreden? (Falls ja werde ich es doch noch am kommenden Mittwoch zur Abstimmung einreichen, falls nein wird es einfach umgesetzt).


#20

Moin,

ich bin dafür, aber bedenke zwei Dinge:

  • Es wäre noch eleganter, wenn sich die beiden Gateways einen DHCP-Bereich teilen würden. Kea sollte das können, soweit ich mal gehört hatte.

  • Wir brauchen dafür eine neue Firmware, die auch nicht ohne weiteres mit der alten kompatibel ist. Das sollten wir mit einer Umstellung auf 11s kombinieren. Derzeit werden alle domänen-fremden IPs weggefiltert:

    Bridge chain: FFPB_NET_ONLY, entries: 7, policy: DROP
    -p IPv4 --ip-proto udp --ip-dport 67 -j RETURN
    -p IPv4 --ip-src 10.43.128.0/21 -j RETURN
    -p ARP --arp-ip-src 10.43.128.0/21 --arp-ip-dst 10.43.128.0/21 -j RETURN
    -p ARP --arp-ip-src 0.0.0.0 --arp-ip-dst 10.43.128.0/21 -j RETURN
    -p IPv6 --ip6-src fe80::/ffc0:: -j RETURN
    -p IPv6 --ip6-dst ff00::/ff00:: -j RETURN
    -p IPv6 --ip6-src 2a03:2260:115:1600::/ffff:ffff:ffff:ffff:: -j RETURN
    (Domäne 16)

Man könnte auch dieses FFPB-Filterpaket rausnehmen. Dann wäre ein fließender Übergang möglich. Das soll aber angeblich das Grundrauschen erhöhen.

Grüße
Matthias


#21

Jo, KEA kann das. Musste aber halt ne echte Datenbank dran hängen. Das wollen wir ja auch machen, aber habe ich jetzt im ersten Schritt aufgrund der höheren Komplexität nicht gemacht. Außerdem muss man sich überlegen, wo man die DB-Server hinstellen möchte. Außerdem muss sichergestellt werden, dass ein Client ein anderes Default-Gateway bekommt, wenn sein Knoten an einem anderen Gateway als zuvor hängt. Das geschieht ja derzeit einfach indem wir das Lease als ungültig erklären.

Für mich schließen sich die beiden Dinge aber auch nicht aus.

Klar, man kann jetzt nicht einfach ein Knöpfchen drücken. Wir sollten uns am Mittwoch mal überlegen, wie wir die Adressen aufteilen wollen.