[Berlin-wireless] Gedanken zu reinem IPv6 Framework

[Sven-Ola Tuecke]

Hey,

paarmal Senf von mir (bin noch am RFC lesen *g*)

* die Minimalanforderungen fuer Mobile Geraete werden sicher steigen - aber 
die Mobilen Geraete werden auch besser mit der Zeit. Ich persoenlich vermute, 
dass es sowieso noch 2-4 Jahre dauern wird, bevor relevante Inhalte 
ausschlieszlich uber IPv6 erreichbar sind. Das sind 2 Geraete-Generationen 
(bei den ueblichen 24-Monats-Hardware-Sponsor-Abzahl-Vertraegen).

* fuer das Gateway-Wechsel-Problem koennen wir im Moment versuchen, uns nix 
einzutreten was moegliche Loesungen von einer neuen Welle Re-numbering 
abhaengig macht. 

* ich bin nicht sicher, aber die Sachen aus RFC 3041 sollten beruecksichtigt 
sein. Kurzinhalt: die 64-Bit Interface-ID sind weltweit eindeutig - und damit 
eine Benutzeridentifikation. Eingehende Verbindung ueber feste ID, ausgehende 
Verbindung uber temporaere ID. Implementation noch nicht ueberall (z.Bsp 
nicht in Kernel-2.4). Kann evnt. fuer Gateway-Switch-Tricks verwendet werden 
oder behindert eine entsprechende Loesung dieses Problems - hab's noch nicht 
wirklich durchdacht.

// Sven-Ola

Am Montag 26 Januar 2009 08:13:18 schrieb Henning Rogge:
> 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)