[IPv6-wien] Migration IPv6 auf v642
Christoph Loesch
(spam-protected)
Wed Mar 15 19:03:33 CET 2017
Vor allem wenn v6 im funkfeuer netz noch nicht so breit deployed ist wie v4.
Ich weiss es zwar nicht, würde aber stark vermuten, dass man die benötigten Personen, die momentan v6olsrd betreiben, auf ein-zwei Händen abzählen kann und es ziemlich sicher kein Problem wäre, für v6olsrd2 den v6olsrd abzudrehen.
Abgesehen davon, letztes Jahr hatten wir auf duer9 (an dem genug andere hängen bzw hauptabhängig sind) den v6tunnel vom Stefan versehentlich paar Wochen nicht aktiv, wodurch kein v6 ging und aufgefallen ist es nur dem Stefan...
Also sehe ich wenig Grund dafür v6 migrieren zu müssen, imho infomail an ~5user und v6 rennt auf olsrd2..
Am 15. März 2017 18:41:59 MEZ schrieb Alexander Biringer <(spam-protected)>:
>
>Die Frage die sich mir noch nicht erschließt ist, warum soll man es
>komplexer machen, als es unbedingt sein muss. Für den Traffic werden
>wir eine höhere Latenz haben, da die Umsetzung sicher Zeit frist.
>
>Über die Lösung im Fall von Site-to-Site, VPN Tunnel bin ich gespannt
>und natürlich helfe ich gerne beim Testen . . . die Frage stellt sich
>nur, warum man sich diese ganze Arbeit antut, wenn man alles parallel
>betreiben kann?
>
>Derzeit haben wir den großen Vorteil, dass wir beides parallel laufen
>lassen können.
>Wir benötigen auf größeren Standorten nur eine IP und nicht für jede
>Antenne eine.
>Bugs in der Antennenfirmware sind uns egal, da diese bei größeren
>Knoten hinter den EdgeRoutern hängen. (Man bedenke nur den Ubnt Bug als
>Funkfeuer quasi tot war, das kann uns bei einer anderen Software auch
>passieren) Mit unserem EdgeRouter Setup hatten wir keine Probleme.
>
>lg
>
>Alex
>
>-----Ursprüngliche Nachricht-----
>Von: (spam-protected) [mailto:(spam-protected)] Im
>Auftrag von Wolfgang Nagele
>Gesendet: Mittwoch, 15. März 2017 18:24
>An: Christoph Loesch <(spam-protected)>
>Cc: (spam-protected); Alexander Biringer
><(spam-protected)>; Bernhard Marker <(spam-protected)>
>Betreff: Re: [IPv6-wien] Migration IPv6 auf v642
>
>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.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/ipv6-wien/attachments/20170315/e3dff42b/attachment-0001.html>
More information about the IPv6-wien
mailing list