[Berlin-wireless] Gedanken zu reinem IPv6 Framework

[Henning Rogge]

On Montag 26 Januar 2009 10:13:53 Sven-Ola Tuecke wrote:
> 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).
Meine Überlegung geht eher dahin das wir auf fixen OLSR-Knoten mit Freifunk-
Firmware eine Menge an "Custom Software/Configuration" vorraussetzen können... 
auf kleinen Mobilgeräten wollen wir eher möglichst ein "just works". Das 
sollte man nicht aus den Augen verlieren.

> * 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 denke IPv6 hat da den Vorteil das wir NEUE Nummern vergeben und keine 
alten abschalten müssen. Wenn wir diese Nummern sogar in den Geräten 
automatisch generieren können um so besser.

> * 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.
Könntest du kurz erklären was du mit "ausgehenden/eingehenden" IPs meinst ?

On Montag 26 Januar 2009 10:33:47 Alina Friedrichsen wrote:
> Hallo Henning,
>
> in dem Konzept sind schon viele Gedanken vertreten, wie in dem das ich
> vertrete, nur liesse sich das weit aus eleganter ohne NAT implementieren.
> Bei IPv6 ist es nichts ungewoehnliches, das ein Interface auch mehrere
> IP-Adressen hat und diese sich auch sehr schnell aendern koennen.
Bzw. sogar von einem DHCP6-Server auf der OLSR-Node automatisch zuweisen. 

> Anstatt die IP-Adressen in das Prefix des Internet-Gateways symmetrisch zu
> NATen, waere es wesentlich eleganter und unproblematischer wenn der Node
> einfach eine IP-Adresse im Prefix des naechsten Internet-Gateways zu seinen
> Buendel aus IP-Adressen hinzufuegt und diese dann als Host-Route im Mesh
> ankuendigt.
Das war es was ich mit "Stateless NAT Clientseitig" meinte... im Grunde ändert 
der Client einfach sein Präfix passend zum gewählten Gateway, alte IPs bleiben 
erhalten (und werden weiter geforwarded) bis die letzte Verbindung weg ist.

> Unter Verwendung des 2.6er Kernels liesse sich damit das
> NatThreshold-Problem ein fuer alle mal loesen, was als positiven
> Nebeneffekt auch Routing-Loops reduzieren helfen sollte.
Weil wir eben ein wenig Source-Routing betreiben...

> (Bin grade dabei u.a. den freien Broadcom-Treiber Mesh-tauglich zu machen,
> damit dieser 2.4er Mist endlich ein Ende hat.)
Ja, gerade die Broadcom-Treiber brauchen glaube ich noch ein wenig Pflege... 
aber sobald die soweit sind und gerade wenn unsere Änderungen zurück in den 
Kernel fließen (ich beobachte die Mails auf der linux-wireless Liste recht 
genau ;) ) sind wir einen guten Schritt weiter.

Henning

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 197 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20090126/37dc8a8a/attachment.pgp>