[WLANware] IP's für freie Netze

[Benjamin Hagemann]

re

* Florian E. Teply <usenet at teply.info> [2006-10-16 21:30]:
> Benjamin Hagemann wrote:
> 
> > 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.

Wenn ich mich in der deutschen Rechtssprechung nicht irre, ist der
admin-c der Verantwortliche. Bei einem PI Netz ist man selbst halt
admin-c bei PA space meistens, aber nicht zwingend der ISP.

Bei Problemen mit PI-Netzen kommt die Exekutive halt erst zu einem selbst
und fragt nach - ansonsten schaltet der ISP halt gleich die Leitung ab ;)

> >> 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.

naja, wir müssen es ja nicht gleich übertreiben ;)

> > 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...

äh, aber natürlich kannst du 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 ;-)

ähm, das macht man mit den Programmen totd und pTRTd.
Siehe http://www.join.uni-muenster.de/Dokumente/Howtos/Howto_TRT.php
Solche "Transport Relay Translator" bräuchte man dann an jedem Uplink.

> > 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.

na, auch hier mußt du nicht übertreiben ;) Ein AS kennzeichnet, dass es
eben zwei unabhängige Internetzugänge hat. Da du von 2 Tunnelservern
sprachst, ging ich von einem AS aus. Btw. öffentliche AS werden dann
auch wieder vom RIPE verwaltet :)
[http://de.wikipedia.org/wiki/Autonomes_System]

> > 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.

ja, aber wie dir der Kollege schon sagte, da sollte man dann eine
ordentiche Cisco oder vergleichbares hinstellen. Wie gesagt: ISP Kosten,
Hardware Kosten + Know How.

> > 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.

Du kommst doch aus Berlin :) Geh doch mal zum CCC Berlin und frag mal
nach den Jungs vom Congress NOC und laß dir ein paar Geschichten
erzählen :)

> >> 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

äh, nein - ich sag mal im wLAN pro HOP 2-3 ms. Bei meinen IPv6 Tunnel
Geschichten über normales DSL war ich bei gut 25-30 ms am Tunnel
Endpunkt und dann geht es von dort erst über die IPv6 Wege ans Ziel -
meist auch nochmal je nach Ziel schätzungsweise 20-40 ms. Selbst wenn du
nur einen anderen Teilnehmer über den den selben Tunnel-Provider
erreichen möchtest mußt du ja schon die 25-30 ms über dessen DSL-Leitung
addieren.

Von meinem Router hier habe ich z.B. 5-8 ms bis www.heise.de

> 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,

Ich meinte weniger die reine Umwandlung, als die reale Weglänge von
einem IPv6 request auf einen IPv4 Webserver.

> 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...
> 
> >> "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

Wie gesagt TRT.

> 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.

argh, ich weiß nicht, ob du das einem Routingprotokoll so ohne weiteres
beibringen kannst ;)

-- 
ciao, Benny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mailman.freifunk.net/pipermail/wlanware-freifunk.net/attachments/20061016/b231de8f/attachment.pgp>