RE: Namensauflösung für Router IPv6

Tim Niemeyer tim at tn-x.org
Mo Mär 5 22:16:42 CET 2018


Hi

Am 5. März 2018 22:11:39 MEZ schrieb mail at adrianschmutzler.de:
>Hallo,
>
>> -----Original Message-----
>> From: franken-gateway [mailto:franken-gateway-bounces at freifunk.net]
>On
>> Behalf Of Tim Niemeyer
>> Sent: Montag, 5. März 2018 21:37
>> To: franken-dev at freifunk.net; franken-gateway at freifunk.net
>> Subject: Re: Namensauflösung für Router IPv6
>> 
>> 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
>
>das ist eine andere Sache.
>
>Mir ging es gerade darum, dass man die Hood NICHT wissen muss, sondern
>nur die MAC-Adresse, um auf den Router zu gelangen. Ich habe das nur
>per DNS gelöst, weil mir nichts anderes eingefallen ist.

DNS mag da ne gute Lösung sein. Aber es müsste ab dem keyXchangev2 vom Knoten aus gemanaged werden, weil nur der Knoten weiss in welcher Hood er ist. Das war ein langer wer den wir gemeinsam bestritten haben und nun sollten wir die Information auch da nutzen, wo sie hingehört, nämlich auf den Knoten.

Generell bin ich eher dagegen es pauschal für alle Knoten unabhängig von der Hood zu machen. Das hat jetzt weniger ein technischen als mehr einen sozialen Grund. Immerhin neigen viele Routeraufsteller dazu sich nicht um die Knoten zu kümmern und erst recht nichts von dem Netz verstehen zu wollen. Ich möchte aber, dass die Leute sich damit beschäftigen müssen. Die Hood wegzuabstrahieren würde das Gegenteil bewirken.

Tim


>Grüße
>
>Adrian
>
>> 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


Mehr Informationen über die Mailingliste franken-dev