[Berlin-wireless] Gedanken zu reinem IPv6 Framework

Henning Rogge hrogge
Mo Jan 26 08:13:18 CET 2009


Kurz als Anmerkung, ich habe diese Mail schon am Freitag letzte Woche
verfasst, habe sie leider aber von der falschen Addresse geschickt, so
das sie die Mailingliste nicht erreichte...
-----------------------------

Hallo,

nachdem ihr euch Gedanken über die Zukunft von Freifunk, OLSR und IPv6 macht
möchte ich auch ein paar Gedanken preisgeben die ich mir mit ein paar Kollegen
auf der Arbeit zu dem Thema gemacht habe.

Zum einen wäre es aus meiner Sicht gut, wenn wir den Punkt mobiler Geräte
nicht aus den Augen verlieren bei den zukünftigen Konzepten. Es sollte immer
noch möglich sein mit PDAs, Smartphones und Netbooks auf ein Freifunknetz
zuzugreifen (sofern die Betreiber des Netzes das wollen).
Der Unterschied zu normalen Stationen liegt in der Konfiguration. Einen
OpenWRT-Router können wir ohne Probleme mit komplexer Konfiguration inklusiv
spezieller Kernelmodule und ähnlichem Ausstatten. Ein PDA kann vielleicht
maximal seine IP festlegen und einen OLSR starten...

Unser anderer Gedanke ging in Richtung IPv6. Der Schritt der mit dem Kernel
Modul seet gefällt eigentlich allen denen ich auf der Arbeit davon erzählt
habe gut, das ganze macht ein IPv6 Transportnetz deutlich unproblematischer !
Aber wir haben heute mal ein wenig über einen weiteren Schritt bezüglich IPv6
nachgedacht, was kommt auf uns zu wenn es endlich mal bezahlbare IPv6 DSLs
gibt ?

Dazu sind uns ein paar Szenarien eingefallen:
(von utopisch bis beängstigend)

1.) Der beste Fall wäre wenn die Provider jedem User ein /48 Netz geben (16
Bit Netz plus 64 Bit für jeden Computer wegen Autoconfig) und auch erlauben
weitere Routen in das BGP Netz des Providers einzuschleusen. Damit könnten wir
intern einen eigenen Public-IPv6 Addressbereich fahren und Antworten kämen
dann einfach über irgendein Gateway zurück... nicht optimal aber trotzdem
klasse... bleibt meiner Meinung nach aber ein Wunschtraum.

2.) Vermutlich geben die Provider aber einfach nur einen /48 oder auch nur /64
Bereich an den DSL User raus. In diesem Fall können wir Public-IPv6 nicht so
einfach nach außen nutzen. Also brauchen wir dann etwas wie "NAT". Unsere
Überlegung war dafür folgende... wenn wir sicherstellen können das jeder
Teilnehmer des OLSR-Netzes einen eindeutigen 64-Bit Identifier am Ende seiner
IPv6 Addresse hat können wir eine Art "stateless NAT" fahren, entweder auf den
Gateways oder auf den Clients.

Stateless NAT auf dem Gateway sähe so aus das einfach der 64-Bit Präfixteil
der OLSR-IPv6 Addresse durch den Präfix des DSL-Providers ausgetauscht... und
umgekehrt. Dabei haben wir natürlich wieder das Problem der sich ändernden
Gateways und abreißender TCP/HTTP-Verbindungen. Dazu weiter unten mehr.

"Stateless NAT" auf dem Client könnte die Form eines IPv6-Renumberings
annehmen. Jeder OLSR-Knoten fährt seinen eigenen kleinen DHCP-Server, der den
Client in der IP-Addresse so konfiguriert das sein Präfix genau dem DSL-Präfic
des Gateways entspricht. Damit hat der Client immer die richtige IP-Addresse
um Antworten über das DSL-Gateway zu bekommen. Im Grunde könnten wir damit so
eine Art "Lose Source Routing" nutzen, das Gateway am Client also auch direkt
addressieren.
Problem bei dieser Lösung sind die kleinen Geräte wie PDAs... die werden wohl
nicht auch noch ein eigenes DHCP fahren wollen, ob sie IPv6 Renumbering
unterstützen ist auch fraglich. Könnte vielleicht der nächste feste OLSR-
Knoten für solche Geräte ein "NAT" bilden ?

3.) Der Worst-Case wäre das die Provider ein /128 Netz abgeben... also nur
eine Addresse. Eigentlich geht das laut IPv6 RFC nicht, aber es wird schon im
dunklen über IPv6-NAT geredet. Wenn es soweit kommt hilft nur auf der Straße
protestieren, den Provider wechseln oder leise fluchen. Bei diesem Szenario
ändert sich bezüglich NATs nichts, wir haben nur innerhalb des OLSR-Netzes
mehr (interne) Addressen zur Verfügung.

==================
Eine Idee die mein Kollege zum Thema Gateway-Wechsel hatte. Jedes mal wenn ein
Gateway gewechselt werden soll/muss gibts Ärger wegen den HTTP/TCP-
Verbindungen. Theoretisch wäre es gut wenn man für die bestehenden
Verbindungen noch das alte Gateway nutzen würde, für den Rest aber die neuen.
So würde sich das Problem mit der Zeit beheben. Für wie realistisch haltet ihr
die Idee das ein Internet-Gateway einen Tunnel zu einem anderen Internet-
Gateway aufbaut um die alten Verbindungen über dieses Gateway fortzuführen bis
sie endlich vorbei sind ? Das würde zwar zusätzlichen Up/Downstream kosten,
aber der scheint schneller zu wachsen als die Kapazität unserer OLSR-Netze.
(Vermutlich haben andere Leute, z.B. von Batman oder Babel die Idee auch schon
gehabt, ich wollte sie aber trotzdem nochmal erwähnen)


Soviel zu den Ideen die ich in dieser Mamut-Mail verpackt habe... viel Spass
beim lesen (und eventuell antworten). Ich werd die nächste Woche noch mit dem
Prototyp unserer Linklayer-DB für OLSR beschäftigt sein, damit wir endlich mit
Metriken aus Signalstärke und Unicast-Sendebandbreite experimentieren können.

Henning (OLSR.org Entwickler)




-- 
"Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand
ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt
Marti)
-------------- nächster Teil --------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkl6BasACgkQcenvcwAcHWdY+wCgjb/7WzpnoDw1bpizQ9wJewld
ycIAoIfMiSLkUks8+k1MLK7wH+ln8LGA
=EjBJ
-----END PGP SIGNATURE-----



Mehr Informationen über die Mailingliste Berlin