Namensauflösung für Router IPv6

[Tim Niemeyer]

Moin

Am Montag, den 05.03.2018, 16:13 +0100 schrieb Adrian Schmutzler:
> Hallo zusammen,
>  
> ich hatte gerade eine verrückte Idee und würde mich für eure Meinung
> interessieren:
>  
> Durch die neuen fd43… Adressen kann man zwar in alle Hoods kommen,
> aber man muss immer irgendwoher das Prefix kopieren (ich kann mir das
> nicht merken) und die richtige Nummer der Zielhood (bzw. in welcher
> Hood der Router ist) kennen.
Das Prefix is wirklich ziemlich schwer zu merken. Aber natürlich macht
es irgendwie immer Sinn, wenn man weiß in welcher Hood sich sein
eigener Knoten so befindet. Theoretisch kann es zwar sein, dass der
rumhüpft, aber dann sollte man sich das doch ganz dringend mal
angucken.

> Mir kam gerade die Idee, ob es nicht einen Mechanismus geben könnte,
> nur mit der MAC-Adresse (ohne weitere „Informationen“) auch Hood-
> übergreifend den Router anzusprechen.
> Routing-technisch sehe ich da keinen Weg, aber man könnte ja
> netzINTERN eine Namensauflösung einrichten nach der Art:
>  
> MAC address: aa:99:88:77:66:55
>  
> DNS Name: aa9988776655.fff -> IPv6: fd43:5602:29bd:21::aa99:8877:6655
>  
> Eine TLD fff gibt es scheinbar nicht, insofern machen wir da auch
> nichts kaputt.
TLD's zu klauen ist keine gute Idee. Da sind schon Leute bitter auf die
Schnauze gefallen, weil die TLD dann doch plötzlich gekauft wurde.

Dann lieber auf den Vorschlag von Mayosemmel zurückgreifen.

> Über die Idee hinaus kann ich natürlich kaum die technische
> Machbarkeit / den Aufwand beurteilen. Von den MS Servern kenne ich es
> so, dass die Geräte im Active Directory ihre DNS Einträge
> selbstständig aktualisieren. Vll. gibt es bei Linux/LEDE einen
> entsprechende Mechanismus. Vll. könnte man auch einfach die Gateways
> eine MAC-Liste der Router aus Batman generieren lassen und das dann
> turnusmäßig an irgendeinen FFF DNS Server weitergeben.
Ich würde vorschlagen, dass man einen kleinen DNS Server schreibt, der
stumpf
aa9988776655.hood.fff -> IPv6: fd43:5602:29bd:${hood-id}::aa99:8877:6655
ausgibt. Man müsste nur die Hood-ID irgendwo her bekommen.

Der Vorteil wäre, dass man nicht wissen müsste ob der Knoten existiert
oder nicht und die Auflösung immer gelingt.

Weiter wäre es ein guter Zeitpunkt nochmal ein wenig rumzugucken. Hat
schon mal jemand recherchiert, was es für Lösungen gibt? Mir fällt
spontan mdns und kadnode ein. Ob das taugt weiß ich nicht, sollte aber
mal betrachtet werden bevor einfach _irgendwas_ umgesetzt wird.

> Wie gesagt, alles nur eine verrückte Idee, keine Ahnung ob das
> praktikabel ist.

Natürlich ist das irgendwie praktikabel.

Ich finde es auch sehr gut, dass wir hier gemeinsam eine Idee
diskutieren, um dann gemeinsam eine gute Lösung zu finden. Schön, dass
du die Diskussion angestoßen hast.

Was mir gar nicht gefällt, dass mal eben hinter unser aller Rücken im
IRC bereits eine Monitoring-API gebaut wurde und quasi schon alle
Knoten in irgendwelche DNS Server geschüttet wurden. Das ist eben genau
nicht die Zusammenarbeit, wie ich sie mir hier in der Community
vorstelle.

Technisch bin ich ziemlich enttäuscht, dass schon wieder weitere
Dienste an das Monitoring angebaut werden. Wir haben damals beim Netmon
eine ganz bittere Erfahrung gemacht, und gelernt, dass es keine gute
Idee ist irgendwelche Dienste von dem Monitoring System abhängig zu
machen. Die Argumentation "das ist ja nur Zusatz und alles total
unkritisch" lasse ich nicht gelten, weil DNS ein Basis Dienst ist und
sich irgendwann Leute darauf verlassen werden. Die Diskussion hier hat
nicht mal richtig angefangen und schon wird wieder jegliche wichtige
Architektur-Erfahrung über Board geworfen und gute Ideen haben
überhaupt keine Chance mehr auf Umsetzung. Das ist Erdbeerkäse!

Grüße
Tim
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 488 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20180305/02323f63/attachment.sig>