<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Lieber Wolfgang!<br>
<br>
Erst vor wenigen Tagen haben wir in kleinerer Gruppe hinsichtlich
Tunneln E-Mails gewechselt, Du schriebst:<br>
<br>
"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."<br>
<br>
Ich erachte u.a. folgende Szenarien für problematisch - vielleicht
kannst Du mir konkrete Lösungen aufzeigen oder etwaige
Missverständnisse ausräumen?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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? <br>
<br>
Szenarien mit der MTU:<br>
a) Über Mobilfunknetze - wahrscheinlich - kann gerade nicht ohne
Fragmentierung testen, im Normalfall: 1492 Bytes (1500 - PPP).<br>
<br>
<font size="-1">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.</font><br>
<br>
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.<br>
<br>
2.) Über das Mesh:<br>
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.<br>
<br>
3.) Ein zentraler Transition Server ist ein SPoF. Verteilte
Lösungen wären IMO zu bevorzugen.<br>
<br>
LG<br>
Erich<br>
<br>
Am 2017-03-15 um 19:02 schrieb Wolfgang Nagele:<br>
</div>
<blockquote
cite="mid:CAK6j62znwTYY02bOdbLwJ=G1Ain9G0a6K05j+PXKFhBc19RFmg@mail.gmail.com"
type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:alexander@biringer.eu"><alexander@biringer.eu></a>:
</pre>
<blockquote type="cite">
<pre wrap="">
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: <a class="moz-txt-link-abbreviated" href="mailto:wolfgang.nagele@gmail.com">wolfgang.nagele@gmail.com</a> [<a class="moz-txt-link-freetext" href="mailto:wolfgang.nagele@gmail.com">mailto:wolfgang.nagele@gmail.com</a>] Im Auftrag von Wolfgang Nagele
Gesendet: Mittwoch, 15. März 2017 18:24
An: Christoph Loesch <a class="moz-txt-link-rfc2396E" href="mailto:mail@chil.at"><mail@chil.at></a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:ipv6-wien@lists.funkfeuer.at">ipv6-wien@lists.funkfeuer.at</a>; Alexander Biringer <a class="moz-txt-link-rfc2396E" href="mailto:alexander@biringer.eu"><alexander@biringer.eu></a>; Bernhard Marker <a class="moz-txt-link-rfc2396E" href="mailto:bernhard@cybercomm.at"><bernhard@cybercomm.at></a>
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 <a class="moz-txt-link-rfc2396E" href="mailto:mail@chil.at"><mail@chil.at></a>:
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:mail@wnagele.com"><mail@wnagele.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">
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 <a class="moz-txt-link-rfc2396E" href="mailto:alexander@biringer.eu"><alexander@biringer.eu></a>:
</pre>
<blockquote type="cite">
<pre wrap="">
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:
<a class="moz-txt-link-freetext" href="https://riot.im/app/#/room/#0xff-v642:hopfmueller.at">https://riot.im/app/#/room/#0xff-v642:hopfmueller.at</a>
[1] <a class="moz-txt-link-freetext" href="http://www.ipv6.wien.funkfeuer.at/download/konzept20130321.pdf">http://www.ipv6.wien.funkfeuer.at/download/konzept20130321.pdf</a>
[2] <a class="moz-txt-link-freetext" href="https://wiki.funkfeuer.at/wiki/IP-Adresskonzept">https://wiki.funkfeuer.at/wiki/IP-Adresskonzept</a>
[3] MailScanner warning: numerical links are often malicious:
<a class="moz-txt-link-freetext" href="http://78.41.119.44/olsrv2status/">http://78.41.119.44/olsrv2status/</a>
[4] <a class="moz-txt-link-freetext" href="https://wiki.funkfeuer.at/wiki/Chat">https://wiki.funkfeuer.at/wiki/Chat</a>
________________________________
IPv6-wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IPv6-wien@lists.funkfeuer.at">IPv6-wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien">https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien</a>
</pre>
</blockquote>
<pre wrap="">
________________________________
IPv6-wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IPv6-wien@lists.funkfeuer.at">IPv6-wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien">https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien</a>
</pre>
</blockquote>
<pre wrap="">
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
_______________________________________________
IPv6-wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IPv6-wien@lists.funkfeuer.at">IPv6-wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien">https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien</a>
</pre>
</blockquote>
<br>
</body>
</html>