[Berlin-wireless] Autokonfiguration eines IPv6-Meshes

[Henning Rogge]

2009/12/1 Rolf Pfeiffer <ropf at o2online.de>:
> Am Montag, den 30.11.2009, 22:13 +0100 schrieb Henning Rogge:
>> Also mindestens 128 Bit... vielleicht sogar mehr. Wenn wir genug davon
>> haben kann man sich, wenn man seiner alten Identität müde geworden ist ja
>> auch ne neue holen.
> So sehe ich das auch.
Auf Wikipedia gibt es zur Wahrscheinlichkeit von Hashkollisionen eine
gute Tabelle:
http://en.wikipedia.org/wiki/Birthday_problem#Probability_table

Bei einer Kollisionswahrscheinlichkeit von 10E-12 sollten wir schon
128 Bit nehmen, 64 Bit reichen sonst nur für 6000 Teilnehmer. (ich
betrachte 10 hoch -12 als "wird nicht passieren")

>> Sobald wir IPv6 haben können wir die Interfaces einfach mit
>> Linklocal-IPs belegen. Solange die MACs unique sind geht
>> das ganz fix... und wenn sie es nicht sind haben wir so
>> oder so Probleme.
> Die Probleme haben wir. Hatte mal ein paar Motorola WR850G - da stehen
> die Lan- und Wan-Macs im NVRAM - und werden von der Firmware erst
> gesetzt. Das gibt lustige Effekte, zB haben die nach einem Update der
> (Hersteller-)Firmware alle die gleichen Mac-Adressen auf Lan und Wan.
Naja, wenn dieses Problem auftritt sollte man eher überlegen ob man
den Link komplett killt. Wenn der Layer 2 nicht geht ist auf Layer 3
nicht viel zu retten.

Ein Hilferuf an den lokalen User wäre aber angebracht.

>> Ein Knoten braucht sowieso irgendeine Art von Addresse, die man ihm
> zuordnen
>> kann, oder halt mehrere. Ob man sie von Zeit zu Zeit wechseln will ist
>> ne andere Frage.
> Ja - und das betrifft nicht nur IP-Adressen, sondern auch Namenseinträge
> im (welchen auch immer) DNS-System. Das menschliche Hirn ist in dieser
> Sache weniger kreativ als ein guter Zufallsgenerator ;)
>
> Konstruiertes Beispiel: ich drucke etwas direkt auf den Drucker von
> Alex, den er als "Alex_Drucker.olsr" im ff-Netz freigegeben hat.
>
> Nun gibt es ein merge mit einem Wölkchen, in dem es (bisher ohne
> Probleme) ebenfalls einen "Alex_Drucker.olsr" gibt - und der topologisch
> näher zu mir liegt.
Eventuell könnte man im DNS-System erkennen das hier eine Kollision
vorliegt, kommt auf die Implementierung an.

> Dann landet mein Druckauftrag nicht dort wo ich es erwarte - und das
> kann evtl >SEHR< peinlich werden.
>
> Eine knotenbezogene ID im DNS-Record gibt uns Chance, das aufzulösen -
> und sei es nur durch einen Warnhinweis.
>
> Noch etwas weiter phantasiert: Irgendein(e) kluge(r) Kopf(in) findet
> eine Lösung für automatisches Subnetting - was die Routentabellen extrem
> verschlankt. Dann würden bei einem Merge ganze Wolken ip-mässig
> umsortiert werden ...
Was natürlich ein Problem wäre für jeden, der einen externen Dienst
anbieten will. Obwohl man das Problem wohl mit nem IPIP-Tunnel lösen
kann. Jede Node hat dann halt eine Mesh-IP und eine oder mehrere
"externe IPs"... geroutet wird nur über die Mesh-IP, der Rest wird
über Tunnel gemacht. Dann könnte man die Mesh-IP ohne Probleme
jederzeit wechseln.

Wobei dieses umsortieren der Wolke auch nicht trivial ist. Aber auf
jeden Fall ein interessantes Problem.

> Ich bin der Meinung, wenn doppelte/wechselnde IPs oder Namenseinträge
> auftreten >KÖNNEN< - sollten wir das als generelles Problem behandeln -
> das ständig und jederzeit auftreten kann.
Vor allem braucht die die Firmware eine Art "Kommunikationskanal" zum
lokalen User, der unabhängig von irgendwelchen Servern ist. Meine Idee
war damals für sowas nen RSS-Feed zu nehmen, das ist leicht zu
implementieren und die User können sich den dann lokal abonieren um zu
sehen ob in ihrem Router was schiefgeht.

Henning

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