[IPv6-wien] Migration IPv6 auf v642

[Wolfgang Nagele]

Sure - ich schreib dich off-list an. Da gibts Optionen.

lg

2017-03-15 18:02 GMT+01:00 Alexander Biringer <(spam-protected)>:
> Hi Wolfgang,
>
> hast Du eine Idee, wie man das am besten angeht, wenn man auf den Provider bzw. dessen Hardware keinen Einfluss hat?
>
> Ich kann nur auf meiner Seite etwas konfigurieren, die andere ist leider nicht konfigurierbar.
> Zb alte Fortigates (15 Jahre alt), Fritzbox, A1 Cisco Lösung (die ich nicht mehr ändern kann) usw...
>
> lg
>
>
>
> Alexander Biringer
> Biricon IT Services
> Falkensteinerweg 16
> A-2345 Brunn am Gebirge
> Tel.: +43 676 3504044
>
>
> -----Ursprüngliche Nachricht-----
> Von: (spam-protected) [mailto:(spam-protected)] Im Auftrag von Wolfgang Nagele
> Gesendet: Mittwoch, 15. März 2017 17:57
> An: Alexander Biringer <(spam-protected)>
> Cc: (spam-protected)
> Betreff: Re: [IPv6-wien] Migration IPv6 auf v642
>
> Bitte um konkretere Setup Infos hier. Ich verwende genau das sowohl ueber DS-Lite UPC Leitung \in Wien daheim) als auch andere 4in6 Netze (Bei meinen Eltern mit einer Wimax Anbindung).
>
> Wenn das nicht geht dann ist Fragmentation falsch konfiguriert.
> Einfach DF bit clearen und dann koennen die Ingress/Egress Router die Pakete sich korrekt zuschnipseln. Helfe da gerne das zu loesen.
>
> lg
>
>
> 2017-03-15 17:43 GMT+01:00 Alexander Biringer <(spam-protected)>:
>> Hallo David,
>>
>>
>>
>> das Problem mit dem IPv4 over IPv6 Tunnel ist eine nicht mehr
>> funktionierende Funktionalität von PPTP und IPSec.
>>
>>
>>
>> Hierbei werden aufgrund des MTU Limits, Overheads plus dem NAT die
>> Pakete für die VPN Tunnel zu klein bzw. werden div. Protokolle
>> überhaupt nicht mehr geroutet.
>>
>>
>>
>> Dies würde für mich bedeuten, dass ich meine IPSec Tunnel nicht mehr
>> fahren kann und die Endpunkte sind leider nicht änderbar.
>>
>>
>>
>> d.h. zb A1 mit eigenem APN und einer Cisco Firewall, die nur IPSec
>> können plus noch andere alte Geräte.
>>
>>
>>
>> Ich persönlich wäre der Ansicht, dass wir IPv6 im OLSRv2 nativ fahren
>> sollten und IPv4 solange wir es benötigen mit OLSRv1. Dieses Setup
>> haben wir derzeit am laufen und dies läuft ohne Probleme. Der weitere
>> Vorteil dieses Setups ist, dass man sobald wir komplett auf OLSRv2
>> umstellen wollen, dies einfach in der Konfiguration bzw. bei unseren
>> EdgeRoutern im Wizard machen können. Ohne viel Aufwand und die Geräte
>> im Zuge der Umstellung über IPv6 weiterhin erreichbar bleiben.
>>
>>
>>
>> Ich kenne die Probleme mit den IPSec Tunnel über IPv4OverIPv6 von
>> meinen Kunden, dort müssen wir zb bei UPC IPv6 deaktiveren, da dort
>> ebenfalls IPv4 over IPv6 läuft und keine VPN Tunnel mehr möglich sind.
>> Im Zuge dieses Setups wird es interessant, wie man Endgeräte über
>> Mobilfunk anbindet, da dort IPv6 nicht verfügbar ist.
>>
>>
>>
>> Mit freundlichen Grüßen
>>
>>
>>
>>
>>
>>
>>
>> Alexander Biringer
>> Falkensteinerweg 16
>> A-2345 Brunn am Gebirge
>> Tel.: +43 676 3504044
>>
>>
>>
>> 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] http://78.41.119.44/olsrv2status/
>>
>> [4] https://wiki.funkfeuer.at/wiki/Chat
>>
>>
>>
>>
>> _______________________________________________
>> IPv6-wien mailing list
>> (spam-protected)
>> https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien
>>
>
> --
> This email was Anti Virus checked by Astaro Security Gateway with Sandbox technology. http://www.sophos.com