[IPv6-wien] Migration IPv6 auf v642

Wed Mar 15 13:04:10 CET 2017

Hallo!

Am 2017-03-15 um 12:33 schrieb Wolfgang Nagele:
> Das Problem bietet sich nur fuer Knoten die auch ueber den tunnel6
> angebunden werden wollen.
Also http://tunnel6.funkfeuer.at/, richtig?
>   Insofern kann man diese dort ablesen.
Das wäre dann:
http://tunnel6.funkfeuer.at/tunnel6.php
>   Es
> handelt sich im Moment nach einem schnellen Check um 15 die
> entsprechend gerouted werden muessten. Zusaetzliche einfuegen ist auch
> super easy.
1. Bitte - Könnt Ihr das bitte formularbasiert teilautomatisieren?
Es müssten ja im Grunde nur geprüfte Parameter (devicename, local 
endpoint, remote endpoint, prefix) zur Ausführung von "ip" abgelegt 
werden, die dann ein Cronjob verarbeitet. Der Device-Name könnte dabei 
den Username oder den Knotennamen beinhalten, damit es übersichtlich bleibt.

2. Problemstellungen, die zu erörtern sind.
Problematisch ist aber weiterhin, dass nicht jede Firewall Protokoll 41 
durchlässt, falls dieser Tunnel zur Verbindung mit einer „echten“ 
Funkinsel mit statischer IP dienen würde - was ja momentan nicht 
vorgesehen ist, aber grundsätzlich praktisch wäre.
„Echte“ Funkinseln mit dynamischer IP oder bei „mobilem Breitband“ als 
Hauptanbindung sind hier weiter im Nachteil, weil diese in den meisten 
Fällen (kein „Open IP“ beim Gros der Angebote) zwar Protokol 41 
eventuell nützen könnten, aber keinen öffentlich erreichbaren Endpunkt 
bieten. Hier bleibt weiterhin nur die Alternative von UDP-Tunneln, die 
entweder über OpenVPN oder etwa mittels socat realisiert werden könnten. 
Für letzteres bräuchte man allerdings für den statischen Endpunkt noch 
eine Art „Triggermechanismus“.
Ich denke, wenn man das jetzt noch einbaute, sparte man sich später 
Administrationsaufwand für andere Tunnellösungen.

3. Alternativen?
Aber darf ich eine andere provokative Frage in den Raum stellen? 
Anstelle von Transitionsmechanismen, die im worst case über andere 
Tunnel laufen und so Overhead und in der Folge MTU-Probleme aufwerfen 
(@Wolfgang wir beide haben darüber ja schon ein paar wenige Gedanken 
ausgetauscht), könnte man doch auch gleich Layer2-Tunnel nützen und so 
nativen Dual-Stack-Betrieb ermöglichen.

Ich würde Euch ersuchen, in den Punkten 2+3 nichts aus zu überhasten, 
auch, wenn zum kommenden Mitgliederversammlung, die ja recht bald 
stattfinden wird, Vorzeigbares schon nett wäre - aber das darf nicht 
ausschlaggebende Kriterium sein.

>
> Ich persoenlich finde das der Vorteil das Leute beim Umstellen auf
> v642 nicht renumbern muessen wesentlich hoeher ist als ein paar Routen
> bei uns flippen zu muessen. Das braucht 5 Sekunden.

Sprichst Du dabei den Aufwand für die User oder den Aufwand für die 
Routingadministration an?
Gerade im von mir angesprochenen Szenario mit v1+v2 könnte es zu 
unerwartetem Fehlverhalten kommen, das durch unterschiedliche 
Adressbereiche weitestgehend ausgeschlossen wäre. (Ansonsten sind die 
Anforderungen an die Handhabung von Policy Routing weitaus größer - 
womit die Komplexität stiege).
Man sollte mE die Hürden für die Knotenbetreiber stets niedriger halten.
>
> lg
LG
Erich
>
> 2017-03-15 12:23 GMT+01:00 Christoph Loesch <(spam-protected)>:
>> Hi,
>>
>> woher wisst ihr, welche prefixes bereits "vergeben" sind?
>>
>> Wir haben das bisher über den v6 calculator berechnet und einfach auf den
>> Routern eingetragen wobei es (seit bekanntmachung des v642 projekts) auch
>> Router geben könnte, wo wir das (noch) nicht eingetragen haben, daher
>> prefixes für diese Knoten nicht pingbar sind und somit nicht "vergeben"
>> obwohl normal n Verwendung.
>>
>> Lg
>>
>> Am 15. März 2017 08:59:05 MEZ schrieb David Hopfmueller
>> <(spam-protected)>:
>>> Guten Morgen ipv6-wien,
>>>
>>> Ich schreibe Euch, um Euch um Eure Meinung und Zustimmung zu bitten:
>>>
>>> Der derzeitige IPv6-Betrieb laeuft ja derzeit laut dem Konzept-2013 [1]
>>> als 6-in-4 ueber den tunnel6.
>>>
>>> Im Rahmen des v642-Projekts, das ja bei einem v6-Treffen Anfang 2016
>>> geboren wurde, haben wir das bestehende Konzept in ein paar Punkten
>>> ueberarbeitet, um IPv6 als natives Protokoll optimal nutzen zu koennen.
>>> Das Ergebnis wurde um den Mai 2016 herum ausgeschickt und ist unter [2]
>>> einsehbar. Die wesentlichen Punkte wurden uebernommen, insbesondere die
>>> User-Prefixes (nnnnri), denn ein wichtiges Ziel war, dass die bisherigen
>>> IPv6-User beim Wechsel auf v642 nicht um-adressieren muessen
>>> (renumbering).
>>>
>>> Wir sind jetzt mit v642 soweit, dass die ersten OLSRv2-Nachbarschaften
>>> stehen [3]. Damit das Netz nutzbar wird, wuerden wir gerne das Routing
>>> des Prefixes 2a02:60:100::/40 aendern, das ist der Bereich, in dem alle
>>> bisher genutzten Adressen liegen. Davon ausgenommen waeren alle bereits
>>> vergebenen Knoten-Prefixes sowie das IPv4-Mapping (Seite 4 in [1]).
>>> Diese Bereiche wuerden weiterhin zum tunnel6 geroutet.
>>>
>>> Fuer Euch ergaebe sich dadurch keine Aenderung. Die bisher genutzten
>>> Tunnel + die gemappten IPv4-Adressen bleiben, wie sie sind. Ihr koenntet
>>> sogar parallel dazu OLSRv2 in Betrieb nehmen, da fuer das grundlegende
>>> Routing andere Adressen genutzt werden (die Loopback-Adressen in [2]).
>>> Sobald v642 bei Euch stabil laeuft, gebt ihr Bescheid, damit wir fuer
>>> Euer Knoten-Prefix (nnnnri) die Route zum tunnel6 raus nehmen. Ab diesem
>>> Zeitpunkt bekommt ihr dieselben IPv6-Adressen, nur eben nativ ueber IPv6
>>> und nicht mehr via tunnel6.
>>>
>>> Am Status Quo wuerde sich fuer Euch also nichts aendern. Ich schreibe
>>> Euch trotzdem, weil ihr viel Arbeit in den IPv6-Aufbau gesteckt habt und
>>> ich nicht will, dass der Eindruck entsteht, dass da "einer kommt und
>>> alles aendert". Die Alternative ist, dass wir fuer v642 ein komplett
>>> neues Prefix nutzen (z.B. 2a02:60:200::/40), das wuerde aber eben bei
>>> einer Migration auf v642 ein Renumbering nach sich ziehen.
>>>
>>> Bitte gebt mir Bescheid, wie ihr das seht und ob ihr damit einverstanden
>>> waeret.
>>>
>>> Danke,
>>> David
>>>
>>> P.S. Fuer Interessenten an v642: Die Koordination findet ueber Matrix
>>> [4] statt, hier kommt ihr direkt zum Raum:
>>> https://riot.im/app/#/room/#0xff-v642:hopfmueller.at
>>>
>>> [1] http://www.ipv6.wien.funkfeuer.at/download/konzept20130321.pdf
>>> [2] https://wiki.funkfeuer.at/wiki/IP-Adresskonzept
>>> [3] MailScanner warning: numerical links are often malicious:
>>> http://78.41.119.44/olsrv2status/
>>> [4] https://wiki.funkfeuer.at/wiki/Chat
>>>
>> --
>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>>
>> _______________________________________________
>> IPv6-wien mailing list
>> (spam-protected)
>> https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien
>>
> _______________________________________________
> IPv6-wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/ipv6-wien/attachments/20170315/6146bf69/attachment-0001.html>