[Berlin-wireless] Autokonfiguration eines IPv6-Meshes

[Henning Rogge]

Am Donnerstag 26 November 2009 22:26:14 schrieb Alexander Morlang:
> >> Aber das Problem stellt sich doch eigentlich gar nicht so schwierig.
> >> Irgendwo in der Firmware gibts nen Knopf "würfel mir eine IPv4 aus"...
> >> zu dem Zeit läuft dann das Routing ja schon im IPv6-Betrieb. D.h. man
> >> kann sehen "ahh, die IP darf ich nicht nehmen, da gibts schon ne Route
> >> für".
> >>
> >> Die Kollision würde also nur auftreten wenn zwei Knoten praktisch
> >> gleichzeitig eine neue IP auswürfeln UND die gleiche IP nutzen. DAS ist
> >> ziemlich unwahrscheinlich.
> >
> > Langsam gefaellt mir die Idee immer besser. Ich wuerde es so
> > implementieren. Beim ersten Booten wird einmal eine IPv4 ausgewuerfelt,
> > danach laeuft ein Script im Hintergrund das z.B. ein mal in der Minute
> > sich die Topologie von olsrd runterlaed und auf Kollisionen untersucht.
> > Tritt eine auf, wird eine neue IPv4 ausgewuerfelt. So wuerde eine
> > Kollision maximal eine Minute lang bestehen, was kein Problem bei HNAs
> > darstellen duerfte.
> 
> Wenn du und henning dann noch das "problem" der temporär fragmentierten
> wolken und der zusammenwachsenden wolken löst, also dann auftretenden
> adresskonflickten löst, währ das wirklich toll.
Nunja, wenn jeder Knoten bei seiner IPv4 Addresse hängen bleibt wird das 
Fragmentierungsproblem nicht wirklich groß. Eventuell sollte man zusätzlich 
einen Cache in jeden Knoten einbauen wo er sich die benutzten IPs der letzten 
24 Stunden merkt, so das diese definitiv nicht genommen werden.

Konflikte können dabei nur bei Knoten auftreten die während der 
Fragmentierungszeit eine neue IP brauchten, was vermutlich deutlich weniger 
als die 500-1000 sind, die in der Wolke existieren. Wenn diese dann noch beim 
Eintritt ins Netz ihre Nachbarn fragen können "gabs diese IP die letzten 24 
Stunden noch" oder einfach den "genutzte IP Cache" kopieren sollte die 
Kollisionswahrscheinlichkeit echt klein werden. Im Ernstfall muss nach dem 
zusammenfügen der Wolke einer der Knoten wechseln.

Wenn dann noch jeder Knoten weis wie lange er die IP schon hat und bei 
längerem Besitz das wechseln etwas verzögert hätten wir automatisch, das die 
"neuen" Knoten der Kollision freiwillig auf eine andere IP wechseln.

Was mir an dem Verfahren besser gefällt als AHCP ist, das es keinerlei 
Konfiguration benötigt. Bei AHCP müssen, sobald jemand einen zusätzlichen 
AHCP-Server aufstellen will, vermutlich einige alte Server (oder gar alle) 
nochmal umkonfiguriert werden.

Wenn ich mit AHCP unrecht habe lasse ich mich gerne eines besseren belehren.

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