Hallo!
Am 2014-11-26 um 21:59 schrieb Matthias Šubik:
Hallo Erich,
danke für den Input,
hier ein paar Notizen, wenn sich da jemand mit weiter beschäftigen will:
On 25.11.2014, at 23:58, Erich N. Pekarek wrote:
...
Bei Durchsicht der Routing-Tabelle meines Tunnel-Client entdecke ich einige
Adressen, die eigentlich im Funkfeuer-Netz nichts verloren haben:
128.0.0.0?
Meinst Du eine 128.0.0.0/1 Route? Dann solltest Du der Vollständigkeit halber
auch eine 0.0.0.0/1 finden.
Ich bin über den aktuellen Stand nicht informiert, aber dass macht man, um
"fremde" 0/0 (default) Routen mit einer spezifischeren Route zu überbieten.
...
Danke, gefunden und geklärt! Danke v.a. auch an Gottfried!
[RFC1918 Adressen] ... Wenn also diese Adressen, wenn auch nur auf das
Funkfeuer-Netz beschränkt, angekündigt werden, kann es sehr leicht zu
Kollisionen mit bereits benutzten Ranges kommen.
Eigentlich sollte es nicht zu Kollisionen kommen, weil der "ordentliche" Router die
lokale Route immer der "fernen" vorziehen sollte.
An sich sollte man das vermuten. Die Praxis zeigt, dass solcherlei
Routen, beim Debuggen schon einmal zu fehlerhaften Annahmen verleiten
können. Siehe "lokaler" 3G-Stick, 10.0.0.0/8 und Ankündigung einer
potentiell identischen 10.0.0.0-Adresse .... detto mit 10.0.0.138 und
Telekom-Modems, ...
Ich sehe hier eher das Problem dass wenn sich jemand auf so eine Ankündigung verlässt,
dass die dann plötzlich nicht mehr geht, oder nur zeitweise geht. IP Adressen sollten
halt eindeutig sein, auch RFC1918-Adressen halt pro "administrativer Einheit".
Wir haben das seinerzeit im Zusammenhang mit der "Zusammenschaltung mit
anderen Communities" erörtert; obgenannte Beispiele treten hinzu.
Ich würde IMHO nach keine Ankündigungen für RFC1918 ohne Ankündigung und
Ansprechpartner in der Gemeinschaft machen, aber ich sehe durchaus Nutzen, es
spricht für das Netz, wenn das so funktioniert.
Mit den Ansprechpartnern ist das so eine Sache. Ein Newbie wird
beispielsweise die Liste der Bridges auf 192.168.222.0/24 weder aktiv
suchen, noch erwarten.
Die Abstimmung über eine Zuteilung muss auch im Worst case
(Kommunkationsdefizite) funktionieren. Das zu erreichen ist schwierig.
(Es gab auch schon mal die Idee, wenn reine Relay-Knoten nicht mehr extern
sichtbar sind, weil externe Erreichbarkeit dort nicht unbedingt notwendig ist.
Das wäre aber nur eine spezifische Entscheidung zugunsten einer Nutzung von
RFC1918-Adressen).
Ich mache gerne "Wartungsvlans" mit Adressen aus 172.16.0.0/12, aber
diese anzukündigen liegt mir fern, auch, wenn es praktisch wirken mag.
Anders verhält es sich mit solchen Adressen, die dem AS eines Providers
gehören, wie z.B.:
86.59.13.172 (sil ip range) -> mh
86.59.13.173 (sil ip range) -> mh
86.59.13.174 (sil ip range) -> mh
Das ist eine interessante Frage, ich würde hier unterscheiden, zwischen
statischen Adressen, und echten dynamischen, z.B. von chello. Weil wenn ein
Knotenbetreiber seine statischen Adressen so erreichbar machen will, ist das
erstens eine Vertrauensentscheidung in das mesh-Netz, und zweitens leicht via
WHOIS nachvollziehbar.
Im Prinzip würde ich Dir in diesem Fall zustimmen, muss Dich aber mit
Deinen eigenen Argumenten konfrontieren:
Diese Ranges wurden a) vom jeweiligen AS-Inhaber nicht für Zweck einer
zusätzlichen Ankündigung gegenüber unbeteiligten Dritten überlassen, und
sie sind b) meines Erachtens gegenüber anderen Funkfeuer-Nutzern als ein
Eingriff in fremdes Routing zu werten und daher weder vom PPA gedeckt,
noch aus diesen Gründen netzneutral. Du wirst jetzt meinen, dass es sich
ja nur um ein Wien-weites Netz ohne BGP-Announcement handelt. Ein Nutzer
der Infrastruktur muss von dieser Manipulation aber nichts wissen.
Und spielen wir den Gedanken weiter: nicht auszudenken, wenn jemand in
böswilliger Absicht IPs eines Bankinstitutes oder sonstiges ankündigt.
Ein Router unter fremder Kontrolle reicht da wohl. Sicher, man kann den
wahren Inhaber der IP ausfindig machen ... und den Betreiber des
entfremdeten Routers auch ... wird das etwas bringen?
Eine dynamische Adresse die automatisch angekündigt wäre vergleichbar, aber
wenn die IRGENDWO via copy--n-paste in einer mesh-Router-Konfiguration landet,
ist die bei einem allfälligen IP-Adressenwechsel für den nächsten Nutzer nicht
mehr erreichbar. Das darf nicht sein. Damit sind dynamische Adressen riskant,
und schwer nachzuvollziehen, wer jetzt dafür verantwortlich ist.
Wer soll das im Einzelnachprüfen?
Im Vorstand könnten wir gerne nach Vorlage durch die Community eine Richtlinie
daraus machen. Aber ich sehe hier halt durchaus Anwendungsfälle für solche
Routen. Allerdings gibt es auch neue Gefahren, falls mal jemand
194.232.104.0/24, 173.194.0.0/16, 17.0.0.0/8 oder einen Ausschnitt daraus
ankündigt. Und schon sind wir beim Thema RPKI.
Wir haben beide diese Gefahr skizziert. Wie überträgt man eine BPG-RPKI
auf OLSR?
Ich denke, dass eine Einigung über die (Nicht-)nutzung erforderlich ist.
Anregungen, freiwillige Meldungen usw. von RPKI-Interessenten bitte in der
Diskussion ausloten. Hier wäre auch ein Ausblick auf die mit IPv6
allgegenwärtigen Link-Layer IP-Adressen sinnvoll, weil in IPv4 das inzwischen
auch in vielen Netzen bereits gemacht wird.
Vielleicht darf ich Dich dazu einladen, RPKI-Überlegungen und
diesbezügliche Probleme auf discuss -unter Zuhilfenahme des Wiki- zu
skizzieren?
Vorerst würde ein Vorschlag zu einer Entscheidung in der Sache "fremde
Ranges" schon genügen.
Sollte eine fremde Route plötzlich aufscheinen, kann man das in der
Zwischenzeit sicherlich leichter handhaben, wenn die zulässigen Netze
überschaubar sind (quasi eine Whitelist).
bG
Matthias
LG
Erich
--
Discuss mailing list
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/discuss
