[WLANware] IP's für freie Netze

[Florian E. Teply]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Paufler wrote:
> Hallo Florian
> 
>> Da hast Du ebenfalls recht, die genannten /16-Netze sind eher spärlich
>> bestückt, da kann man auch mal eben alle IP-"Besitzer" per EMail
>> anschreiben und um ihre Mitwirkung bitten. Besonders beim .23.er Netz
>> geht das fix, gut 80% der 7 vergebenen IPs entfallen auf mich ;-)
> Supi. Dann fangen wir hier mal an ;)
> 
Gut, wo soll ich hin?? ;-)

>>>>> Eine andere Möglichkeit wäre die Nutzung eines anderen, noch nicht vergebenen, 
>>>>> IP-Blocks - es muss ja nicht 104.0.0.0/8 sein. Soweit ich weiß, ist die 
>>>>> 103.0.0.0/8 auch noch reserved und bisher ungenutzt.
>>>> Würden wir eine zweite IP Vergabe anzetteln, welche dann
>>>> Deutschland-weit eindeutig ist und zaghaft auf die neuen IPs migrieren?
>>>> Stellen 3 Städte um statt nur Berlin? Haben wir mit 103|105 die chance
>>>> auf eine gute Lösung für alle?
>>>>
>> Mal eben überschlagen, ein /8-Netz wären etwa 16 Millionen Adressen.
>> Angenommen, Freifunk breitet sich wirklich flächendeckend aus, dann
>> könnte das schon recht knapp werden, da 16 Mio Adressen nicht
>> gleichbedeutend ist mit 16 Mio Nodes. Okay, offiziell werden im Internet
>> ja auch die IPv4-Adressen schon seit Jahren knapp, aber das ist ein ganz
>> anderer Schuh.
> Nunja - wir sollten loslegen. /8 passt denke ich wieder eine Weile auch
> für andere Städte. Und wenn das nicht reicht, dann das nächste /8 ;)
> 
Das ist wohl wahr. Ich glaube kaum, daß Berlin in kürzerer Zeit mehr als
32k Adressen benötigen wird... Wieviele sind aktuell vergeben??

>> Da müsste man sich schon ganz ordentlich Gedanken darüber
>> machen, wie man die Adressen anordnen will, also nach logischem
>> (netztopologisch gesehen) oder physikalischem Standort (geographisch).
>> Den Adressbereich dabei allzusehr zu zerstückeln bringt Kopfschmerzen
>> beim Routing, egal nach welcher Logik die Ranges aufgeteilt werden.
>> Wenn man sie rasterförmig geografisch anlegt (beispielsweise nach
>> Maidenhead-(QTH)-Locatoren), dann kann jeder Node bereits anhand der
>> IP-Adresse grob ermitteln, ob das Ziel etwas weiter weg ist (und dann
>> auch, in welcher Richtung) oder ob das Ding irgendwie lokal verteilt
>> werden kann. Da hat man aber auch wieder die Situation, daß bei einer
>> solchen gleichförmigen geografischen Verteilung einerseits in eher
>> ländlichen Gebieten (mal von den Ozeanen ganz abgesehen) der Adressraum
>> schlecht ausgenutzt wird, während in Ballungsgebieten die IP-Adressen
>> mitunter knapp werden könnten. 
> Hier denke ich, sollten wir keep-it-simple machen. Wir verteilen /16
> einfach der Reihe nach. Warum komplizieren?

Das war eigentlich mehr ein globaler Ansatz für die IPv6-Geschichte.
Quasi ein ideenhaltiges Vorgeplänkel.
> 
>> Ich persönlich favorisiere den Ansatz,
>> sich für eine übergreifende Lösung mit IPv6 anzufreunden, nen
>> /64-Bereich zu bekommen, ist selbst für nen Privatmenschen kein Problem,
>> mit ein wenig Überzeugungsgeschick ist auch ein /48 oder gar ein /32
>> denkbar. Das ließe dann 64, 80 oder sogar 96 Bit für die interne Vergabe
>> übrig. Das sollte dennoch nicht unbedingt dazu verleiten, einfach mal
>> mit der Salzstreuermethode die Adressen zu vergeben ;-)
> IPv6 macht erst mit /64 auf dem AP spass. Erst dann geht autoconfig und
> die Benutzer im Umkreis brauchen keine Config zu machen. OLSR
> Funktioniert imo allerdings weiterhin hostrouten-basiert. D.H. jeder AP
> ist in der Tabelle incl. seines /64. Das müsste gehen.
> 
Zugegebenermaßen hab ich mich mit autoconfig noch überhaupt nicht
beschäftigt. Aber mal für etwas Klarheit: meinst du hier /64 für jeden
Node, /64 für jedes HNA oder /64 für ganz Berlin/Deutschland/Welt??

>> In Anbetracht dieser Ausführung denke ich, daß wir uns mal gemeinsam
>> Gedanken machen sollten, wie man IPv6-Adressen sinnvoll vergeben könnte
>> und quasi nebenbei dem OLSR IPv6 beibringen. 
> Ein Test können wir mal für die c-base timen. 5-6 APs zeigt imo schon
> recht gut was geht und was nicht. In der Vergangenheit gabt auch dazu
> schon tests und die eine oder andere eMail.
> 
Das sollten wir hinbekommen denke ich. Allerdings weiß ich über bereits
erfolgte Tests nix, wäre vielleicht gut, wenn da jemand mal sowas wie ne
kurze Zusammenfassung schreiben könnte. Man muß ja nicht x-mal das rad
neu erfinden...

>> Dann kann man
>> übergangsweise auch nicht weltweit eindeutige IPv4-Adressen entsprechend
>> auf eindeutige IPv6-Adressen mappen, also beispielsweise ein Leipziger
>> 10.0.0.0/8 auf 3ffe:abcd:1:: und ein Münchner 10.0.0.0/8 auf
>> 3ffe:abcd:2:: Und um nicht jedesmal nen ganzen 24Bit-Bereich dafür
>> freihalten zu müssen, könnte man das auch noch mit ein wenig NAT anreichern.
> Hierzu kennt IPv6 2 Konzepte. imo rechnet mensch die IP in hex um und
> packt sie ans Ende. 3ffe:abcd:1::affe:babe, wobei affe:babe die
> umgerechnete ipv4 addy ist. Einfacher für den Menschen finde ich
> allerdings die ip einfach in die ipv6 zu übernehmen.
> 3ffe:abcd:1::0104:0132:0023:007. Anyway - whatever we do, we just have
> to do it. IPv6 gibts bei sixxs oder freenet6. google mit ipv6 tunnel
> broker bringt viele Lösungen zum Vorschein. Einfach anmelden und
> loslegen. Wenn wir genug darüber wissen, können wir das auch besser planen.
> 
> Also los - ipv4 reform und ipv6 testbed.
> 
Haben wir uns bzgl. IPv4 Reform schon geeinigt?? Also wir alle, nicht
nur Du und ich ;-)

Gruß
Florian
- --
Langeweile? Lust auf ein fesselndes Spiel?
- -> Das MorgenGrauen erwartet Dich!!
http://mg.mud.de/newweb oder
http://telnet.morgengrauen.info
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFLr14gyo72NEMX5sRAtHhAJ0VaKL+cep3otoJcyfXY3B652AlgwCdG0Li
3GUBTlVprFtkV86OH1hdHic=
=ilRT
-----END PGP SIGNATURE-----