Hallo!
Am 2014-05-22 12:39, schrieb Matthias Šubik:
Hallo,
On 22.05.2014, at 10:37, Erich N. Pekarek wrote:
...
Am 2014-05-22 10:02, schrieb Matthias Šubik
...
On 22.05.2014, at 01:06, Erich N. Pekarek wrote:
...
Wo noch nicht geschehen, wäre es sinnvoll hier auch gleich link-local
169.254.0.0/16 hinzuzufügen, da diese IPs bei dem einen oder anderen Node
vorkommen können, wenn z.B. Interfaces durcheinander gekommen sind, oder
ähnliches.
Soweit mir bekannt ist, wird die 169.254.0.0/16 nur vom experimentellen
Autoconfig-/Remoteconfig-Dienst verwendet, der bei der Ersteinrichtung helfen
soll - in diesem Fall kommt der in der OLSR-Tabelle vor. Je nach Firmware-Stand
sind diese Regeln in der Grundkonfiguration enthalten oder auch nicht.
...
Ich weiß nicht, ob es sinnvoll ist und habe diesen Range absichtlich nicht
erwähnt.
Reine APIPA-Ranges (also 169.254.0.0/16) haben, wenn etwas "durcheinander
kommt" meines Erachtens im Mesh-Routing sonst nichts verloren.
Weißt Du mehr als ich? Wenn ja, pls --verbose.
ich weiss von zwei Gründen für "APIPA"-Ranges:
Unkonfigurierte DHCP(cd) Interfaces haben die, d.h. wenn z.B. bei einem Linux
PC nach Umbau ethN/wlanN usw. durcheinander kommen, könnte es sein, dass so ein
headless-Node trotzdem wartbar bleibt.
Nun, ein linklokaler Link sollte eben nur dies sein: Linklokal. Es
besteht keine Veranlassung diese Adresse einem Routingprotokoll zuzuführen.
Detto vorerst einmal für ipv6-linklokale Prefixes.
Da diese Adresse idR nicht im Nameservice registriert ist, ist es auch
nicht zweckmäßig, so zu verfahren.
Zur Verbesserung der Wartbarkeit empfiehlt sich eher ein VAP mit
Wartungsinformationen oder ein Wartungs-VLAN oder beides.
Knoten bei denen das vorkommen könnte, haben meiner Erfahrung nach
ohnedies mehrere Devices zur Verfügung. D.h., diese sind schon jetzt idR
wartbar.
Zweiter Grund ist, dass es bisher kaum Probleme damit gibt sie zu erlauben, und
das öffnet die Zukunft der Auto-Konfiguration.
Dass Du keine Probleme damit kennst, bedeutet nicht, dass andere keine
damit haben. ;-)
Beweise durch vollständige Induktion!
Wie die meisten OS (Desktop/Mobil) könnte man alle Interfaces immer
aktiveren, und hat sofort eine Möglichkeit die Links sofort zu verwenden (z.B.
zu messen), ohne auf eine IP zu warten.
Das ist zwar ein Argument, aber auch dafür sind die Firewalls bislang
nicht vorbereitet und machen NAT-Beschränkungen haben sowohl
APIPA-spezifische als auch RFC1918-typische Ranges drinnen, andere
nicht. Ich denke, dass gerade die Registrierung von IPs, die ja mit dem
Namen verbunden ist, uns hier vor Schaden und Unfug bewahrt, respektive
derartige Vorfälle nachvollziehbar macht - was im Falle
dynamisch-automatischer Zuweisungen eben nicht der Fall ist.
Einige OS sind schon dazu übergegangen wie bei IPv6 neben einer
öffentlichen/privaten IP immer eine Auto-Conf-IP zu aktivieren.
Dem stehe ich kritisch gegenüber.
D.h. Du kannst möglicherweise sogar via APIPA herausfinden, welche (nicht
kompatible) IP auf dem Interface rennt.
...
LG
Erich
bG
Matthias
ps: im Grunde ziehen wir bei v4 nur ein sinnvolles v6 Verhalten nach.
--
Discuss mailing list
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/discuss
