[Discuss] [Wien] 169.254.0.0/16 war:[0xFF-OS/BFV]: Firewall und neue IP-Ranges

[Erich N. Pekarek]

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.