[Berlin-wireless] Autokonfiguration eines IPv6-Meshes

[Henning Rogge]

Am Freitag 27 November 2009 22:09:59 schrieb Rolf Pfeiffer:
> Am Freitag, den 27.11.2009, 07:18 +0100 schrieb Henning Rogge:
> > Jede IP die belegt ist muss als Route existieren... sonst ist sie nicht
> > wirklich belegt.
> Das sehe ich nicht so. Wir haben auch längerdauernde Fragmentationen.
> Sei es ein ausfallender Link, der erst nach 2 wochen repariert wird -
> oder irgendein Testsetup, das normalerweise getrennte Wolken plötzlich
> zusammenwachsen lässt.
Wobei selbst das nicht so wirklich kritisch ist. Kommt halt darauf an wie 
viele Nodes in der Zeit der Separierung neu dazu kommen. Das vermindert 
zumindest die Kollisionswahrscheinlichkeit.

> > Natürlich muss gerade für etwas fragilere Netze da ein Cache
> > her...
> Ausgezeichnete Idee.
Danke.

Eventuell wäre es sogar eine gute Idee wenn eine Node die neu dazu kommt ihre 
IPv4 Addresse nicht auswürfelt sondern einfach erstmal ein paar Broadcasts 
rausschickt, damit die Nachbarn ihr eine IP auswürfeln. Die haben dann nämlich 
meistens schon ne volle Routingtabelle. Jeder Nachbar antwortet dann mit der 
ausgewürfelten IP und der Anzahl der HNA-Einträge die er kennt, woraufhin sich 
die neue Node eine IP aussucht (möglichst eine von jemandem mit vielen HNA-
Einträgen).
 
> > > Für mich stellt sich die Frage: Wie erreiche ich einen bestimmten
> > > Knoten, dessen IP zufällig ist und evtl ab und zu wechselt?...
> > Die Antwort lautet wie im normalen Internet: über DNS.
> Im normalen Internet sorgt eine Domainregistratur für eindeutige Namen.
Klar, aber DNS-Namen sind mittelfristig gesehen eine gute Möglichkeit 
Eindeutigkeit zu gewährleisten. Und wenn es eine Kollision gibt kann man 
demjenigen ja einmal per Layer-8 fragen, warum er die gleiche DNS haben will.
 
> > > ... verlagerst die Eindeutigkeitsforderung nur von Nummern auf Namen -
> > > und brauchst wieder ne Kollisionsbehandlung ...
> > Wenn man das automatisch detektieren will braucht man das sowieso...
> Darauf will ich eigentlich hinaus. Wir brauchen IRGENDWAS Eindeutiges.
Stimmt. Wobei die Chance das eine ausgewürfelte IPv6 Addresse eindeutig ist 
ZIEMLICH hoch ist.
 
> Bis jetzt waren das die zentral vergebenen IPs, während das
> nameservice-plugin eher ein nettes Schmankerl war.
> 
> Wenn wir auf zufällige, oder gar dynamische IPs übergehen, wird der
> interne DNS zur zentralen Komponente mit erhöhten Anforderungen.
> 
> Wie wäre es also mit folgendem Ansatz:
> - wir erzeugen bei der Installation auf jedem Knoten eine Zufallszahl,
> genügend lang, um über Raum und Zeit "fast sicher" eindeutig zu sein.
Einfach zufällig eine IPv6 ULA auswählen und dann kurz mit den Nachbarn 
abchecken ob die Addresse okay ist. Für die Interfaces sollten aus den MAC-
Addressen generierte Linklocal-IPs reichen. Wenn man die gleiche MAC wie ein 
enger Nachbar hat gibts ganz andere Probleme als nur Autoconfig. ;)
 
> - Diese Zahl wird die lebenslange Knoten-ID und kann für viele Zwecke
> nützlich sein, zB als Primärschlüssel für eine zentrale Map.
> 
> - Die Knoten-ID wird im "dns-record" gespeichert. Treten
> Namensdopplungen auf, ist das der Haken um sie zu erkennen und zu
> behandeln.
> 
> - Eine "Behandlung" könnte darin bestehen, den zuletzt benutzten Eintrag
> zu verwenden, oder den geographisch Näherliegenden... auf jeden Fall
> lieber ein definiertes Verhalten als ein Zufälliges.
Der OLSR routet beispielsweise automatisch zum nächsten HNA-Eintrag. Einzig 
die Originator-IP muss gleich sein damit das Routing störungsfrei laufen kann.
 
> Ich denke, wenn wir das (oder etwas Ähnliches) mit der zufälligen
> Adresswahl kombinieren, könnte das was werden.
Ich sehe DNS in Zukunft einfach als ein Teil des Problems "Service-Discovery". 
Einen Service Eintrag den jede Node halt beschreibt ist "ich habe den DNS-
Namen xyz". Wenn wir das Problem gelöst bekommen mit der Service-Discovery 
fällt uns sowas "umsonst" in den Schoss.

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/20091128/5d494b36/attachment.pgp>