[WLANware] IP's für freie Netze

Florian E. Teply usenet at teply.info
Mon Oct 16 21:28:31 CEST 2006


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

Benjamin Hagemann wrote:
> Moin!
> 
> Na, langsam werden die Mails echt lang :)

Äh, ja. ich werd' versuchen, mal sinnerhaltend zu kürzen. Hau mir aufn
Kopp, wenn ich was verdrehe ;-)
> 
[native IPv6-Connectivity]

>> Tja, hört sich verdächtig nach nem Henne-Ei-Problem an. Aber das muß ich
>> Dir ja nicht erklären.
> 
> mh, seh ich mittlerweile nicht mehr so. Die ISPs sind vorbereitet. Sie
> warten nur bis es lohnt ihre komplette Technik umzustellen, was doch
> sehr kostspielig ist. Klar, kleine/neue Provider starten gleich mit der
> neuen Technik, Große müssen dafür die teuren Ciscos umstellen - wenn der
> Kunde dafür bezahlt, wird das sicher auch schneller vorangehen als bis
> zum nächsten regulären Hardware+Sofware-Upgrade zu warten.
> 
Hmm, ich glaub kaum, daß wir es uns leisten können, für nen Satz neuer
Ciscos zu zahlen. Any Sponsors around?? ;-)

>>> Im Übrigen hat dann aber auch wieder jeder über seinen Provider seine v6
>>> Adressen und nicht ein /64 was man großartig aufteilen muß :)
>>>
>> Ja, WENN jeder mal eben ein /64 bekommt, dann braucht man nix aufteilen,
>> man muss nur noch routen ;-)
> 
> Im Moment dürfte SixxS für die Freifunker sicher noch genug haben ;)
> Ist nur schade, dass diese IPs PA space ist und wenn SixxS irgendwann
> kostenpflichtig würde, man mit seinen IPs nicht ohne weiteres umziehen
> kann - weiter läuft auch abuse bei SixxS auf, oder?
> 
Hmm, wegen abuse bin ich grad n bischen überfragt, in dem Zusammenhang
wäre es ja auch mal interessant zu wissen, was die unter abuse verstehen.

> 
> naja, IPv4 wird so schnell nicht aussterben und die FFF ist IPv6 ready.
> Dazu recht aktuell diese Heise Meldung:
> Registries überlegen Maßnahmen gegen IPv4-Adressmangel
> http://www.heise.de/newsticker/meldung/78095
> "Noch seien 25 Prozent oder 1,5 Milliarden IP-Adressen frei,..."
> 
> Aber wenn man IPv6 PI space bekäme und ein ISP der dies nativ routet -
> top!
> 
Das wäre in der Tat ziemlich cool. Da werden wir wohl noch ein paar
Provider nerven müssen ;-)

>> Insgesamt (also für den deutschsprachigen Raum) dürfte aktuell /20 so
>> ziemlich die Untergrenze sein, eher mehr.
> 
> und da jede Stadt/Gruppe ja nur nach jeweils einem /24 bis /20 fragt,
> ist das alles auch noch im Rahmen.
> 
Ah, so langsam fällt auch bei mir der Groschen ;-) Heute halt mal
pfennigweise...
Wenn ich jetzt mal genauer drüber nachdenke, müssen wir ja nicht
zwingend IPs aus dem selben Bereich haben. Stark fragmentierte Adressen
machen zwar wohl Kopfschmerzen beim Routing im WLAN, aber die Situation,
daß Berlin, Dortmund und Wien nativ per WLAN miteinander verbunden sind,
ist wohl noch in seeeeeehr weiter Zukunft anzusiedeln ;-) Innerhalb
einer Wolke wäre ein einheitlicher Bereich angebracht, aber zum
verbinden mehrerer Wolken per Langdraht ist das eher nicht besonders
aufwendig, beschränkt sich ja dann tendenziell auf wenige Verbindungspunkte.

>> Hmm, anscheinend hat sich bei mir da wieder Wunschdenken breitgemacht.
>> Ich hatte nämlich den Gedanken, ein und dasselbe /64 über mehrere Tunnel
>> verfügbar zu haben, nicht zwingend alle bei sixxs. Halt sowas in der Art
> 
> Naja, "ein und dasselbe" Netz nicht über den selben Anbieter/Tunnel wird
> schwierig ;) Du kannst es aber aufteilen und dann entsprechend in z.B.
> 2x /112  u.s.w. aufteilen.
> 
Das wäre natürlich auch ne Möglichkeit, quasi mehrere IPv6-Adressen pro
Gerät. Wenn die sich nur im Präfix unterscheiden, wär das eventuell
besonders einfach, nur ein paar Bits maskieren.

>> wie "UserA hat ein /80-Subnetz an seinem Uplink hängen, UserB ein
>> weiteres etc blablabla". Diese User haben zum einen einen Tunnel zu
>> IPv6-BROKER-A, zum anderen einen Tunnel zu IPv6-BROKER-B (also als mehr
>> oder weniger redundante Multipath-Anbindung), dazu vielleicht auch noch
>> den einen oder anderen Tunnel zu nem VPN-Server oder anderen Usern. Ich
>> mal es mal eben auf und stell ein Bildchen zur Verdeutlichung ins Netz...
>> So, zu finden unter http://www.teply.info/freifunk/Tunnelsetup.bmp .
>> Anhand dessen kann ich vielleicht deutlicher machen, wie das von mir
>> gedacht war. Wir haben da also die User A, B und C, die Tunnelbroker A
>> und B (oder halt nen VPN-Server oder wasauchimmer). Die drei User (als
>> Stellvertreter für ihre lokale Freifunk-Wolke) haben nen Uplink, darüber
>> laufen je ein Tunnel zu nem Tunnelbroker, zusätzlich hat User A auch
>> noch je einen direkten Tunnel mit User B und C, User B und C hören sich
>> über das Freifunknetz. Ich stelle mir das so vor, daß nun der Traffic
>> ins Internet Loadbalancing-mäßig über die Tunnelbroker geht,
>> Freifunktraffic geht je nach Link-Status übers WLAN, durch nen direkten
>> Tunnel oder auch über die Tunnel-Broker. Ist halt die Frage, ob und wie
>> es machbar ist, ein Netz dermaßen variabel geroutet zu bekommen.
>> Grundsätzlich sollte es kein Problem sein, in IPv4 geht das ja auch.
> 
> ;) naja...
> 
> Es klingt zwar ganz interessant ist aber sehr komplex und komplex heißt
> meist kostspielig und nicht jeder will es schwierig.
> Zum einen, warum willst du Tunnel, wenn du IPv6 (oder auch v4) nativ
> haben kannst?

Naja, üblicherweise kann man ja nicht beides gleichzeitig haben...
Ergo muß dann normalerweise eines getunnelt werden. Andererseits: sofern
grundsätzlich erstmal ne vernünftige Anbindung besteht, ist der Verlust
durch Nichtverfügbarkeit einer Variante eher gering. Nagut, momentan
wäre es eher ungünstig, IPv6-only angebunden zu sein, da anscheinend ein
größerer Teil des Netzes nicht per v6 erreichbar ist. Andersherum gibt
es auch ein paar (wenn auch wenige) Inseln, die nur v6-only erreichbar
sind. Die Idee hinter der Tunnelei war halt, in beiden Welten erreichbar
zu sein. So ne Art Kompatibilitätsmodus ;-)

> Die Redundanz zu zwei Tunnel (VPN ist es mit öffentlichen Adressen ja
> nicht) - Servern hilft dir bei einem Upstream Provider nicht viel. Da
> bräuchtest du schon 2 Telefonanschlüße von 2 auf komplett getrenten ISPs
> z.B. über den Kabelanschluß und über Telefonleitung. Die Tunnelserver im
> Internet sind eigentlich soweit recht stabil - zumindest stabiler als
> die Internetconnectivity.

Stimmt. Wobei man dann konsequenterweise die Anschlüsse auch noch auf
unterschiedliche Vermittlungsstellen (und unterscheidliche Gebäude)
aufteilen müsste. So gesehen haben wir das ja auch schon, die meisten
Wolken sind ja von mehreren Punkten aus ans Netz angebunden.

> Wenn du das über 2 Tunnelserver, sei es von einem Anbieter oder mehreren
> haben willst, mit öffentliche IPv6 Adressen dann fährst du für gewöhnlich
> BGP. BGP upstream kostet beim Provider, kostet bei dir Technik und
> knowhow. Ich weiß nicht in weit sowas auf einem Linksys mit quagga
> funktioniert oder wie groß eine passende Cisco dafür sein muß. FaUl,
> kannst du dazu was sagen? Aber gerade IPv6 und BGP wird auf einem
> Linksys bestimmt nicht lange gut gehen.

Jupp, das dürfte *ETWAS* eng werden. Wobei ja BGP nur auf den Gateways
nötig wäre.

> Weiter brauchst eine Stelle wo du totd und pTRTd für die alte IPv4
> Anwendungen laufen läßt oder möchtest du die alten Win98 User aussperren?
> Weiter brauchst du diese Technik an jedem Upstream.
> Die Entscheidung, ob das Paket über einen Tunnel raus oder in der eignen
> Wolke bleibt, wäre davon abhängig, ob das Gerät das Ziel via OLSR Routen
> direkt erreichen kann, ansonsten eben über eine default Route über einen
> der Tunnel.

Ja, so in etwa hab ich mir das gedacht.

> Ich hänge da in der großen BGP und AS Welt - du sprichst ja hier von
> quasi Autonomen Systemen - nicht praktisch drin, kann es aber
> halbwegs erahnen.
> 
Ich stecke da auch nicht drin, irgendwie bin ich wohl in diese Richtung
abgedriftet.

>> Eine mögliche Lösungsvariante wäre: wir finden den einen oder anderen
>> wohlgesinnten ISP, der sich in sein Tunnelnetz nen Router mit OLSR
>> hinstellt und uns IPv6 über nen OLSR durch verschiedenste (dynamische)
>> Tunnel routet.
> 
> Btw. wie groß werden dann eigentlich die Laufzeiten - über wLAN - Tunnel
> - Internet - dort ggf. IPv4 Umwandlung weil die meisten Server im
> Internet bisher nur über IPv4 angebunden sind und die Strecke wieder
> zurück - huihuihui
> 
Naja, das Laufzeitproblem besteht ja hauptsächlich im WLAN. Der Tunnel
und die Umwandlung waren bei meinem letzten Test (allerdings nur in
meinem internen Kabel-LAN) nicht großartig spürbar. Wenn ich nur wüsste,
wo ich mir die Daten aufgeschrieben habe, könnte ich mal eben
ausprobieren, wie das mit dem Mapping gehen könnte. Obwohl, das 6bone
ist ja eh inzwischen wieder weg...

> OLSR ist Routingtechnisch glaub ich nicht so ganz in der Lage das zu
> bieten, was du dir gerade erhoffst - dafür wurde es auch nicht
> entwickelt.
> 
Stümmt, OLSR ist wohl eher den internen Routingprotokollen zuzurechnen.

>> Davon gehe ich auch aus. Allerdings stellt sich da ein Problem: wenn wir
>> (mehrdeutige) private v4 nach dem Standardschema auf öffentliche v6
>> mappen, haben wir nix gewonnen, weil dann die verschiedenen
>> kollidierenden private-v4 netz die selbe public-v6-Adressen gemappt
>> bekämen, es wird also nicht eindeutig. Ich dachte eher an sowas wie
> 
> äh, ja sry - seh ich ein. Immer diese privaten IPs ;)
> 
>> "Leipzig bekommt $Präfix:abcd:IPv4, Dresden bekommt $Präfix:efab:IPv4
>> usw., so daß die v6-Adressen eindeutig einer der bisher verwendeten
>> Private-v4-Ranges zuordenbar sind.
> 
> Warum bei IPv6 noch die privaten IPv4 Adressen integrieren?
> Entweder erreicht man sie lokal über private IPv4(+link local IPv6) oder
> über die öffentliche IPv6. Außerdem gibt's ja noch DNS :)
> 
Das war meine Idee vom oben genannten Kompatibilitätsmodus. Also das
Szenario: Node A spricht nur noch v6, Node B noch nicht v6. Wenn die
dann miteinander kommunizieren wollen, muss irgendjemand zwischen den
beiden nen Übersetzer spielen. Da ist es dann halt besonders einfach, an
ne v4-Adresse nur nen v6-Präfix dranzukleben bzw. umgekehrt nen
v6-Präfix wegzuschnippeln um ne v4-Adresse zu erhalten. Natürlich unter
der Voraussetzung, daß sonst die zwei IP-Generationen kompatibel sind,
müsst ich nochmal nachlesen.

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

iD8DBQFFM91egyo72NEMX5sRApN5AJwOpUrFVkePafjmcfvAdWjUkppVuQCfbqjE
NqyVP7KIisGBjVmzmCPPalI=
=gPJW
-----END PGP SIGNATURE-----



More information about the WLANware mailing list