Da christoph lösch (= der knotenbetreiber der diese IPs announct) im whois dieser IP steht, halte ich die diskussion darüber für absolut entbehrlich.
lg Markus 2014-11-27 3:01 GMT+01:00 Erich N. Pekarek <[email protected]>: > 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 >
-- Discuss mailing list [email protected] https://lists.funkfeuer.at/mailman/listinfo/discuss
