[IPv6-wien] Migration IPv6 auf v642

Wed Mar 15 18:24:26 CET 2017

Hallo,

Leute ihr vergleichts hier zwei Sachen die so nicht vergleichbar sind. :(

In unserem Falle ist Ingress/Egress von uns verwaltbar und dadurch
koennen wir die Fragmentierungs Problematik in den Griff bekommen.
Fragmentierung ist im Internet Alltag - leider eines der komplexeren
Themen im IP Stack aber auch durchaus etwas was man verstehen und
verwenden kann.

Ich schlage vor das wir dieses spezifische Problem mit dem ersten v642
Link Metalab <-> Krypta angehen und dann zeigen wir wie man das
Problem dort loesen kann.

UPC hat das Problem weil sie eben nicht zulassen das ihr den Ingress
Punkt bei ihnen aendert wenn ein Paket vom Internet zu eurer Leitung
kommt. Das koennten die sehr wohl auch loesen.

lg

2017-03-15 18:10 GMT+01:00 Christoph Loesch <(spam-protected)>:
> Bin hier Alex' Meinung, echtes dualstack statt dslite! Das sag ich schon die
> ganze Zeit seit dem Moment als v642 geboren wurde, hat aber nicht viel
> Beachtung bekommen.
> Für den 0815 Internet Surfer ist dslite kein Problem.. Für den etwas mehr
> advanced user, der home office macht und mit VPN in die arbeit verbindet,
> wird das kein Spass!
>
> My2cent: wer mit dslite (wie UPC) auf die Schnauze fallen will, soll es tun,
> aber sich bitte auch eine Lösung für die homeworker vorbereiten!
> Denn UPC hat nicht mitgedacht und schaltet alle neuen Kunden (=dslite), die
> home office machen, wieder auf reines v4 zurück!
>
> Silverserver hat damals echtes dualstack angeboten wobei die SIL Kunden dann
> alle UPC dslite Kunden ausgelacht hat..
>
> Lg
>
> Am 15. März 2017 17:57:02 MEZ schrieb Wolfgang Nagele <(spam-protected)>:
>>
>> 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] MailScanner warning: numerical links are often malicious:
>>> 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
>>
>>
>>
>> ________________________________
>>
>> IPv6-wien mailing list
>> (spam-protected)
>> https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien
>
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.