IP-Vergabe für Stadtgebiete

[tuxmos]

Ich hatte es beim treffen inm August schon mal angesprochen:

Der Übersicht halber währe ich für eine Aufteilung der Stadtgebiete (PLZ) in die einzelnen Projekte (Subnetze).
Bei aktuellem Projektstand z.B. die Projekte Postleitzahlen zugeordnet. Also z.B. .250 für 06108, .251 für 06114, .252 für 06112 und 06116, .253 für 06120 - 06126 und .246 erst mal für Umgebung (Zscherben, Angersdorf usw.) und Tests/Mobil etc.
Die Zusammenfassungen der PLZ-Gebiete ergeben sich aus der derzeitigen Nodedichte vor Ort und der begrenzten Projektzahl.
siehe Karte:


Ich denke, noch währe der Aufwand für eine Umstellung zu bewältigen. Müsste halt nur gut organisiert werden um zeitweilige doppler zu vermeiden.
Bei der Gelegenheit kann dann ja mal die Nodeliste entschlackt werden und wieder IP's frei gemacht werden.

rené

[culo]

kann ich nur zustimmen, da die einige von uns sowieso mehrere Router zu laufen haben.
Gruß, culo

[tox]

ich habs jetz nich nachgeprüft, ob die anzahl der adressen auf die plz-bereiche etwa gleichverteilt sind, aber grundsätzlich halte ich das für eine sehr gute idee.

@tux das mit dem raussuchen nicht mehr erwendeter adressen hab ich doch schon mal gehört? mindestens auf dem vorletzten treffen und mindestens in einem post davor

[tuxmos]

ich habs jetz nich nachgeprüft, ob die anzahl der adressen auf die plz-bereiche etwa gleichverteilt sind, aber grundsätzlich halte ich das für eine sehr gute idee.

@tux das mit dem raussuchen nicht mehr erwendeter adressen hab ich doch schon mal gehört? mindestens auf dem vorletzten treffen und mindestens in einem post davor

Das beweist, das man in diese Richtung endlich mal aktiv werden muß. Ne Gleichverteilung wirds wohl nicht geben, da die Nodedichte grad im Paulusviertel recht hoch ist und da auch noch mehr zu erwarten ist. Warscheinlich sollte man da auch gleich noch Reserven mit einbauen. Andere PLZ-Bereiche haben da noch etwas mehr Luft.
Müsste man mal alles genauer betrachten und beraten. Ist wohl ne Aufgabe fürs nächste Treffen, denk ich.

René

[tox]

wenns nich wieder um schatten eines anderen themas untergeht, wie so viele male...

sprich mich bitte unbedingt darauf an, denn ich vergess es diesmal nicht und würd es schon gern ausarbeiten.

[se]

also ich würde sagen, dass wir viel zu wenig adressen haben um sowas sinnvoll umsetzen zu können.

der aufwand der adress-umverteilung ist sehr groß. schon bei der umverteilung der lan-kopplungen hat man gesehen, dass das relativ mühselig ist, dabei musste man da noch nicht mal mit kurzzeitigen dopplern rechnen. gleichzeitig sehe ich den nutzen, der daraus resultieren würde, wenn überhaupt, als ziemlich kurzfristig, da wir so oder so bald neue adressen brauchen werden, außer wir kommen irgendwie von der 47-grenze weg.

sinnvoller halte ich es da, wenn wir uns gleich einen größeren adressbereich (z.b. aus 10.0.0.0/8 - was für ein bereich da in frage kommt, sollte man separat diskutieren) nehmen und dort bei der verteilung von anfang an den bezug von adress-bereichen zu stadtteilen machen.

man sollte auch das wachstum nicht vergessen, mit dem zu rechnen ist. in einem jahr dürften wir zwischen 200 und 300 nodes haben, in 2 jahren dann zwischen 400 und 600. zumindest wenn wir so wachsen wie leipzig.


raussuchen nicht verwendeter adressen finde ich gut. das ist auch nicht so schwierig. einfach ne liste aus der node-verwaltung generieren und die knoten aus der olsr-topologie abziehen. die verbleibenden knoten manuell überprüfen.

[Cyrus]

raussuchen nicht verwendeter adressen finde ich gut. das ist auch nicht so schwierig. einfach ne liste aus der node-verwaltung generieren und die knoten aus der olsr-topologie abziehen. die verbleibenden knoten manuell überprüfen.

Falls jemand 'nen kleines Script schreiben will:
http://www2.freifunk-halle.de/meshtrack ... taTopology
gibts die Daten aus der Topographiedatenbank im JSON-Format, mtime ist hier der interessante Wert, nämlich der Zeitpunkt wann der Knoten zuletzt erfasst wurde, so hat man dann auch die Knoten drin, die aktuell grad nicht am Netz hängen.

[stromer]

Also ich finde die Idee der Stadtgebiets verteilung gut.

Im kleinen habe ich ja schon versucht mein "IP-Königreich Kanena" nicht in allen Adressbereichen zu verteilen. Noch nicht ganz gelungen, aber ich arbeite dran .
Wenn in kleinen Schritten dass erstmal passiert, beim Tausch von Adressen eben in gegenseitiger Absprache, ist der Aufwand sicher erträglich.
tmk und ich haben das schon mal praktiziert, die Erschöpfung hielt sich in Grenzen.

Ich bin gerade relativ gut erholt und entspannt wieder im Lande mit festem Boden unter den Füßen und möchte daher schon mal Interesse an 252.33 (culo) und 252.29 (mono) anmelden . Würde gut in meine Raupensammlung passen. Biete dafür 246.28 oder 246.35 oder 246.39

Für die Zukunft ist sicherlich se's Gedanke zu verfolgen.

[tuxmos]

sinnvoller halte ich es da, wenn wir uns gleich einen größeren adressbereich (z.b. aus 10.0.0.0/8 - was für ein bereich da in frage kommt, sollte man separat diskutieren) nehmen und dort bei der verteilung von anfang an den bezug von adress-bereichen zu stadtteilen machen.

War mein erster Favorit, hab den Vorschlag aber garnicht erst gemacht, da ich mir das noch aufwendiger vorgestellt habe, einen eigenen IP Bereich zu erhalten. Würde aber alles, in Bezug auf die Verteilung, einfacher machen. Man könnte direkt die PLZen umsetzen oder noch ne feinere aufteilung nach Stadtgebieten. siehe:

[tuxmos]

Aber warscheinlich ist das schon wieder zu kompliziert, wer wohnt in welchem Stadtgebiet und wie genau sind die Grenzen zu ziehen.
Einfacher ist da die Zuordnung zu PLZen. Hat ja jeder sw auf ws in seiner Adresse zu stehen. Irrtümer weitestgehend ausgeschlossen.
Da es nur 13 PLZ-Gebiete in Halle sind, kann man ja zB dann dem Gebiet 06108 erst mal die Subnetze 008, 108 und 208 geben. Das sind dann pro PLZen-Gebiet 3x47=141 Nodes.
Da die PLZen als gerade Zahlen vegeben sind, kann man die nächste Ungerade dann noch als Reserve dazu behalten, also zB die 009, 109 und 209. Sind dann pro Gebiet 282 Nodes.

Die 001 - 007 und 034 - 099 usw. kann man dann für Testprojekte, Sonderprojekte, Umgebung/Saalekreis usw. nehmen.

So mal meine ersten konkretisierten Gedanken dazu.

René

[tuxmos]

Hm. Bedeutet das nicht auch, das wir uns ne eigene Firmwarevariante basteln müssen oder zumindest das IP-Vergabescript anpassen müssen?

Sagt/Schreibt mal einer was. Selbstgespräche sind zwar zum Nachdenken ganz nützlich, aber mehr Gehirne denken besser.

Außerdem ist es interressanter mal ins Forum zu schauen und es gibt was neues zu lesen.

René

[stromer]

Außerdem ist es interressanter mal ins Forum zu schauen und es gibt was neues zu lesen.

Ja, richtig sehe ich auch so.

Aber zurück zum Thema. Anpassung der IP-Vergabe in der Firmware ist sicherlich notwendig, aber dafür gibt es doch bestimmt Spezialisten.

Beim Lesen der Beiträge komme ich eigentlich auch zu dem Schluß: Wenn schon Umstellung, dann richtig mit eigenem IP-Bereich nach dem Vorschlag von se. Noch ist der Aufwand bei etwas über 100 aktiven Nodes beherrschbar, zumal viele AP's von relativ wenigen Admins verwaltet werden, die "Einzelgänger" müssen da eben mit durch. Außerdem ist die Variante zukunftssicherer.

Wer entscheidet eigentlich über die IP-Nutzung ? Beim Nachlesen bin ich da nicht so richtig schlau geworden. Kann jeder in dem privaten Adressbereich sich was heraussuchen und dann nur irgendwo "einen Zettel an die Laterne packen - ist meins"
Nach http://wiki.freifunk.net/IP-Netze ist 10.6.0.0/16 noch nicht belegt.

[se]

10.6.0.0/16 würde ich nicht nehmen, da es mit 10.4.0.0/14 kollidiert.
was ist mit 10.80.0.0/16?
dann können wir da ein paar projekte anlegen.
wir müssten nur noch einen weg finden, wie wir intelligent den laptops ip-adressen zuweisen.

stromer: es gibt keine zentrale instanz, die über die nutzung des ip-bereichs entscheidet. das entscheidet jeder für sich.

wenn wir eine adäquate vergabe-logik entwickelt haben, spricht nichts dagegen, sofort anzufangen diese adressen zu vergeben. es müsste nur überall der OLSR-broadcast auf 255.255.255.255 gesetzt werden, statt 104.255.255.255 wie es derzeit ist.

[tuxmos]

stromer: es gibt keine zentrale instanz, die über die nutzung des ip-bereichs entscheidet. das entscheidet jeder für sich.

Komisch. Ich hätte angenommen, das es Eine geben muss und das die Berliner als Initiatoren das machen. Wenn jede Stadt nach Willkür einen IP-Adressbereich nimmt, ohne auf die Anderen zu achten, kommts doch sicher zu Bereichsdopplern und damit Routingproblemen im Intercityrouting, oder nicht?

René

[se]

dazu hat mal jemand die liste gemacht
http://wiki.freifunk.net/IP-Netze
damit man gucken kann, welchen bereich man am besten nimmt. wenn man mal nachguckt gibt es in der liste auch überschneidungen, welche man natürlich vermeiden sollte.

[tuxmos]

dazu hat mal jemand die liste gemacht
http://wiki.freifunk.net/IP-Netze
damit man gucken kann, welchen bereich man am besten nimmt. wenn man mal nachguckt gibt es in der liste auch überschneidungen, welche man natürlich vermeiden sollte.

Was spricht also dagegen uns zwischen Leipzig und Weimar einzureihen? Also 10.62.0.0/16 bzw. 104.62.0.0/16

[se]

spricht nichts dagegen. gegen 104.62.0.0/16 spricht einerseits, dass das den berlinern "gehört", ggf. zugeteilt ist, zudem ist damit zu rechnen, dass im richtigen internet innerhalb der nächsten jahre die 104er adressen vergeben werden, d.h. wenn wir die 104er adressen benutzen, können wir aus dem freifunk-netz heraus diese adressen im internet nicht erreichen.

ich tendiere immer mehr für ein netz im 10er bereich. von mir aus 10.62.0.0/16, hauptsache es ist irgendwie geklärt, wie wir das mit den laptops machen.

[se]

hab das laptop-thema mal der übersicht halber abgespalten.

zudem habe ich 10.62.0.0/16 für halle akquieriert.
wenn wir das mit den laptops so machen wie tox und ich in dem "IP-Vergabe für Laptops" thread vorgeschlagen haben, spricht nichts dagegen, die projekte vollständig auszunutzen, d.h. keine begrenzung auf 47 knoten pro projektnummer.

von dem 10.62.0.0/16er bereich (adressen 10.62.0.1 bis 10.62.255.254) gilt es jetzt bereiche festzulegen, die geografischen bereichen zugewiesen werden. die idee mit den X projekten pro plz finde ich schonmal gut. außerdem muss aus dem 10.62.0.0/16er bereich ein adresspool für laptops bestimmt werden. da diese laptop-adressen zentral per dhcp verteilt werden sollen, kann man diesen bereich später noch beliebig ändern.

tuxmos:

welcher logik folgt diese aufteilung? wenn wir jedem dieser bereiche eine projekt-nummer zuteilen, haben wir doch schon ne gute vergabelogik. vernachlässigen dürfen wir aber nicht gebiete weiter außerhalb von halle. die brauchen auch ausreichend adressen! (bestes beispiel kanena)

[tuxmos]

Diese Karte ist von der Stadt und zeigt die Stadtgebiete, also zB. Paulusviertel, Mühlwegviertel, usw.
Die Andere Karte weiter oben mit den Blauen Linien ist die Aufteilung in PLZ-Gebiete. Das Sind dann 13 und darauf basiert mein letzter Vorschlag. Da ja dann ne Menge 10.62.x.x Projekte ungenutzt sind

Die 001 - 007 und 034 - 099 usw. kann man dann für Testprojekte, Sonderprojekte, Umgebung/Saalekreis usw. nehmen.

Ich kenne die PLZen von der nächsten Umgebung von Halle nicht, denke aber das die sich auf ähnliche weise anbinden lassen. OK, hab grad gesehn, Kanena ist 06116, gehört also noch zu Halle.
- Kabelsketal hat zB. die 06184 und fällt auch noch ins Schema. Ich denke also, solange es passt, kann man das bei der Vergabe der Projekte berücksichtigen.

[sneumann]

Moin!

Verzeiht meine Ignoranz, aber *warum* will man die 246/250/252 Projekte
geographisch geordnet verteilen. Hilft es dem Netz beim Routing ?
Oder hilft es uns Menschen beim schnellen Erkennen der Nachbarn/Topographie ?

Ich habe nichts gegen eine Adressumstellung wegen IP Knappheit,
aber IPs im restlichen Internet werden von ICANN/Ripe auch nicht
nach Längen/Breitengraden vergeben.

Habe ich etwas übersehen ?

Gruss,
Steffen

[tuxmos]

Moin!

Verzeiht meine Ignoranz, aber *warum* will man die 246/250/252 Projekte
geographisch geordnet verteilen. Hilft es dem Netz beim Routing ?
Oder hilft es uns Menschen beim schnellen Erkennen der Nachbarn/Topographie ?

zweiteres und IPkappheit
Auf lange Sicht reichen die Projekte im Leipziger Netz nicht mehr aus und das sind dann zwei Fliegen die unter eine Klappe geraten.
Ich finde die IP-Vergabe im Moment Caotisch, ist aber auf jeden fall nur ne Empfindungsache, zugegeben. Aber noch ist das Ganze überschaubar und zu händeln.

[tox]

http://www.freifunk-halle.de/phpBB3/vie ... =658#p5514

[Cyrus]

Ich halte es auch für sinnvoll den 10.0.0.0/8 Bereich zu verwenden, nur wir sollten vorher überprüfen, da es ja anscheinend in Halle noch ISPs gibt die keine öffentlichen IPs vergeben, aus welchem Pool die ihre Adressen beziehen und ggf. noch die IP-Pools größerer LANs (Uninetz o.ä. falls die den private IPs benutzen) einbeziehen.

[tuxmos]

Uni-Wlan benutzt 10.0.0.0/8

[stromer]

Kanena ist 06116, gehört also noch zu Halle.

Wollt ich doch meinen

Die Stadtgebietsaufteilung anhand der PLZ ist doch eine gute Variante der Orientierung. Das dann in einigen Gegenden noch Reserven sind, sehe ich eher positiv.
Für die jeweiligen Bereich sollten sich dann "Freiwillige" finden, die darin die erstmalige IP-Vergabe vornehmen oder mindestens koordinieren.
Ich würde das schon mal für 06116 und auch östlichen Saalekreis (06184 = z.B. Kabelsketal) machen.

[tox]

mh, ihr müsste mit der 10.0.0.0/8 aufpassen. dieser bereich wird von vpns genutzt, wie zum beispiel dem von der uni. das hieße, jeder der im freifunk is, bekommt probleme, wenn er sich per vpn mit der uni verbindet...

[se]

naja, nicht wirklich. dann setzt man sich eine route 10.61.0.0/16 explizit über den freifunk-router. 10.0.0.0/8 geht dann sicherlich über das uni-tunnel-interface. freifunk-internet und uni-vpn müssten trotzdem ohne probleme parallel funktionieren. man würde nur die einzelnen freifunk-router nicht mehr erreichen, wenn ne 10.0.0.0/8er route in den uni-tunnel geht. aber wie man das umgeht steht ja in meinem 2. satz.

[tox]

wir wollen die sache vereinfachen und manuelle routeneintragungen verstehe ich eher nicht darunter...

mal ne frage, für die rechner im lan an einem ff-router erscheinen doch die anderen ff-nodes quasi als internet, oder? das problem beim cisco-clienten, den man für den tunnel verwendet, ist, dass er sämtliche routen außer die des lans in die uni tunnelt...

ich würde einfach bitten, einen adressbereich zu wählen, der sich überhaupt nicht mit üblichen vpn-netzen überschneidet und mache mal unverbindlich den vorschlag nach RFC 3330 für klasse-b-netz mit 172.16.0.0/12 und somit einer million möglichen adressen.

[se]

wenn der vpn-client alle adressen außer vom lan in die uni tunnelt, dann ist da auch 104.0.0.0/8 und 172.16.0.0/12 dabei... d.h. es ist egal, was man beim transportnetz für einen adressbereich wählt. der vpn-client kriegt garnichts vom transportnetz mit.
zudem würde ich soeine entscheidung überhaupt garnicht davon abhängig machen, was irgendein vpn-client der uni für routing-gewohnheiten hat.

wie gesagt, wenn ich mir das richtig vorstelle besteht grundsätzlich kein problem aus dem freifunk-netz raus übers internet ins uninetz per tunnel zu kommen. wenn der vpn-client ne default route über den tunnel jagt, muss man so oder so auf der eigenen seite was anpassen um ins freifunk-transportnetz zu kommen. anm: mit transportnetz meine ich alle knoten, die derzeit 104.61.... als adresse haben. deine aussage "jeder der im freifunk is, bekommt probleme, wenn er sich per vpn mit der uni verbindet" möchte ich damit zurückweisen.

wenn in fast allen freifunk-communities 10.0.0.0/8er adressen verwendet werden, sollten wir da keine ausnahme machen. das erschwert die zusammenarbeit unnötig, wenn man mal in richtung zwischenstädtische vernetzung denkt.

[tox]

mh, das mag stimmen, dass auch der andere bereich sowieso getunnelt würde. und dass man clientseitig was am routing ändern muss, liegt immanent an diesem speziellen vpn-client.

aber hallo, bin ich denn der einzige, der der meinung ist, dass man nicht blind anderen freifunkern alles nachmachen muss? ich kann immer noch argumentieren, dass andere vpns (und die gibt es garantiert) potenziell im angedachten adressbereich arbeiten, die die standardroute nich ändern, und ich hätte keinen bock jedes mal die routen manuell zu bearbeiten und mich zwischen dem vpn und den ff-knoten zu entscheiden. ich finde ein b-klasse-netz ist absolut ausreichend. erst recht im hinblick, den teilnehmern arbeit und graue haare zu ersparn. du musst bedenken, dass nich alle ffler solche freaks sind, die mit iptables jonglieren wie du möglicherweise, und erst recht haben sie keine lust auf potenziell hausgemachte probleme, die im vorfeld hätten einfach vermieden werden können durch die wahl eines anderen adressbereichs.