[IPv6-wien] Migration IPv6 auf v642
Erich N. Pekarek
(spam-protected)
Wed Mar 15 21:01:48 CET 2017
Lieber Wolfgang!
Erst vor wenigen Tagen haben wir in kleinerer Gruppe hinsichtlich
Tunneln E-Mails gewechselt, Du schriebst:
"Aso du meinst den Traffic der Inseln die zurueck ins Funknetz gehen? Ja
das wird dann wohl so ausschauen. Ist halt nur fuer non-native Traffic
relevant der ohnehin zurueckgehen wird. Ideal ist was anders in der Tat.
Bessere Ideen willkommen."
Ich erachte u.a. folgende Szenarien für problematisch - vielleicht
kannst Du mir konkrete Lösungen aufzeigen oder etwaige Missverständnisse
ausräumen?
1.) „Echte Funkinseln“: Momentan sind Funkinseln über einen OpenVPN
IPv4-only Tunnel angebunden. Im Falle, dass dies über Mobiles Internet
passiert, tritt - außer bei Spezialtarifen- genau die zuvor
angesprochene PMTUd-Problematik (wegen der Blackholes) auf. Bei OpenVPN
würde üblicherweise die Fragmentgröße angepasst. IPSec hast Du ja schon
geklärt.
Eine direkte Verwendung der sit-Tunnel zur Anbindung von Funkinseln ist
momentan nicht vorgesehen und auch würde nur statischer IP Sinn ergeben,
da sonst ein öffentlicher Endpunkt fehlt.
Es bliebe also in diesen Fällen nur OpenVPN mit geroutetem V6-Netz
(wurde wegen alter Hardware und oder zu wenig Manpower ausgeschlossen)
oder ein sit-Tunnel (6in4) über OpenVPN IPv4 UDP. Ein solcher Knoten
bräuchte dann ohnedies OLSRv1 + v2 oder statische Routen. Da wäre die
Benutzung von EoIP, L2TP oder sonst einen Pseudowire mit Dual-Stack in
der beschriebenen Weise womöglich sinnvoller und effizienter.
Jetzt stellt sich aber noch das Problem, dass das bestehende OpenVPN mit
olsrv1 eine IPv4-Adresse aus dem Funkfeuer-Range nützt, darüber der 6in4
Tunnel mit 4in6 gefahren würde - wie sieht da bitte der plangemäße
Lösungsansatz aus? Wurde daran gedacht? Wie regelt man die Problematik
der Retour-Routen (Tunnel/Mesh/Transition)? Manuell? Metriken? Policy
Routing?
Szenarien mit der MTU:
a) Über Mobilfunknetze - wahrscheinlich - kann gerade nicht ohne
Fragmentierung testen, im Normalfall: 1492 Bytes (1500 - PPP).
b) DSL: Bezüglich Clemens Behauptung ("<1500") ist anzumerken, dass A1
Telekom bei eigenen Produkten sehr wohl 1500 ermöglicht (habe gerade
über eine A1 Kombi auf ADSL2 mit don't Fragment getestet - 1472 + 8 +20
= 1500). Lediglich bei einigen ISPA-Providern spielt der L2TP mit
typischerweise 40 Byte eine Rolle, sodass effektiv nur 1460 Byte (v4)
funktionieren, was auch kein Problem ist, solange PMTUd funktioniert,
oder der Gateway vor dem TA-Access Concentrator schon die MTU reduziert
hat. Die dadurch entstehenden Fragmente bei v4 bewirken allerdings
notwendigerweise auch eine erhöhte Systemlast bei den beteiligten
Geräten. IPv6 sieht in der Regel keine Fragmentierung vor. Das wäre an
sich ohne Bedacht auf sonstige Umstände ein Argument für v6-only.
Also in diesem Beispiel mit Mobilfunk wäre der Worst Case an Overhead
des abstrusen Tunnelns im Tunnel: 1492 - 20(IP) - 8 (UDP OpenVPN) - 20
(IP Protocol 41) - 40 (IPv6 Header) - 20 (4 over 6 IPv6 Typ 41). = 108
Byte, Rest 1384. Habe ich etwas vergessen? Wahrscheinlich ja - bitte
korrigieren.
2.) Über das Mesh:
Einige Knoten, etwa alle von Akku (laut ihm selbst), unterstützen kein
IPv6. Überall, wo die Strecke über den Funklink zum zentralen
Translator ginge, wären sit-Tunnel über v4 über WLAN vonnöten. Es ist
nicht gewährleistet, dass das überall funktioniert. Es gab zahlreiche
Knoten mit Devices unter OpenWRT oder Bubbles, die in der Zone 0xFF
natten anstatt zu routen. In der Standardkonfiguration sind nämlich die
Beschränkungen für NAT auf private Netze nicht eingetragen. Das kann
Blackhole-artige Zustände bewirken, deren Auswirkungen auf Prot. 41 noch
zu testen wären.
3.) Ein zentraler Transition Server ist ein SPoF. Verteilte Lösungen
wären IMO zu bevorzugen.
LG
Erich
Am 2017-03-15 um 19:02 schrieb Wolfgang Nagele:
> Hallo Alex,
>
> Ein Dual-Stack Netz ist nicht unbedingt einfacher. Weil dort eben
> beide Konfigurationen auf allen Knoten gefahren werden müssen.
> Wohingegen - und darum wurde diese Option im v642 Projekt avisiert -
> in diesem Falle bei den meisten Knoten nur ein Router eine 4in6 Config
> braucht und auch das nur wenn jemand eine IPv4 Adresse haben will.
>
> Wo ein Dual Stack Netz einfacher ist ist im initialen Rollout - weil
> sich die Netze irgendwann anfangen zu überlappen und zu vermeshen. Das
> wurde im v642 Projekt auch alles besprochen. Wenn nötig sollten wir
> das nochmals aufmachen aber bitte die dzt. Doku dazu im Wiki
> entsprechend lesen und dann machen wir wieder ein v642 Meeting wo wir
> die Optionen durchgehen.
>
> Mein Vorschlag:
> a) Wir nehmen den Krypta <-> Metalab Link um das dzt. Konzept
> detailliert zu testen. Da zeigen sich sicher noch mehr Sachen die man
> lösen muss.
> b) Am nächsten monatlichen MoMo machen wir eine Vorstellung von v642
> wie es im Moment steht - und dann schauen wir ob die Rationale für
> alle neu dazugekommenen auch Sinn macht.
>
> Sounds good?
>
> lg
>
>
> 2017-03-15 18:41 GMT+01:00 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.
> _______________________________________________
> 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/b2319056/attachment-0001.html>
More information about the IPv6-wien
mailing list