<html><head></head><body>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.<br>
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!<br>
<br>
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!<br>
Denn UPC hat nicht mitgedacht und schaltet alle neuen Kunden (=dslite), die home office machen, wieder auf reines v4 zurück!<br>
<br>
Silverserver hat damals echtes dualstack angeboten wobei die SIL Kunden dann alle UPC dslite Kunden ausgelacht hat..<br>
<br>
Lg<br><br><div class="gmail_quote">Am 15. März 2017 17:57:02 MEZ schrieb Wolfgang Nagele <mail@wnagele.com>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Bitte um konkretere Setup Infos hier. Ich verwende genau das sowohl<br />ueber DS-Lite UPC Leitung \in Wien daheim) als auch andere 4in6 Netze<br />(Bei meinen Eltern mit einer Wimax Anbindung).<br /><br />Wenn das nicht geht dann ist Fragmentation falsch konfiguriert.<br />Einfach DF bit clearen und dann koennen die Ingress/Egress Router die<br />Pakete sich korrekt zuschnipseln. Helfe da gerne das zu loesen.<br /><br />lg<br /><br /><br />2017-03-15 17:43 GMT+01:00 Alexander Biringer <alexander@biringer.eu>:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Hallo David,<br /><br /><br /><br /> das Problem mit dem IPv4 over IPv6 Tunnel ist eine nicht mehr<br /> funktionierende Funktionalität von PPTP und IPSec.<br /><br /><br /><br /> Hierbei werden aufgrund des MTU Limits, Overheads plus dem NAT die Pakete<br /> für die VPN Tunnel zu klein bzw. werden div. Protokolle überhaupt nicht mehr<br /> geroutet.<br /><br /><br /><br /> Dies würde für mich bedeuten, dass ich meine IPSec Tunnel nicht mehr fahren<br /> kann und die Endpunkte sind leider nicht änderbar.<br /><br /><br /><br /> d.h. zb A1 mit eigenem APN und einer Cisco Firewall, die nur IPSec können<br /> plus noch andere alte Geräte.<br /><br /><br /><br /> Ich persönlich wäre der Ansicht, dass wir IPv6 im OLSRv2 nativ fahren<br /> sollten und IPv4 solange wir es benötigen mit OLSRv1. Dieses Setup haben wir<br /> derzeit am laufen und dies läuft ohne Probleme. Der weitere Vorteil dieses<br /> Setups ist, dass man sobald wir komplett auf OLSRv2 umstellen wollen, dies<br /> einfach in der Konfiguration bzw. bei unseren EdgeRoutern im Wizard machen<br /> können. Ohne viel Aufwand und die Geräte im Zuge der Umstellung über IPv6<br /> weiterhin erreichbar bleiben.<br /><br /><br /><br /> Ich kenne die Probleme mit den IPSec Tunnel über IPv4OverIPv6 von meinen<br /> Kunden, dort müssen wir zb bei UPC IPv6 deaktiveren, da dort ebenfalls IPv4<br /> over IPv6 läuft und keine VPN Tunnel mehr möglich sind. Im Zuge dieses<br /> Setups wird es interessant, wie man Endgeräte über Mobilfunk anbindet, da<br /> dort IPv6 nicht verfügbar ist.<br /><br /><br /><br /> Mit freundlichen Grüßen<br /><br /><br /><br /><br /><br /><br /><br /> Alexander Biringer<br /> Falkensteinerweg 16<br /> A-2345 Brunn am Gebirge<br /> Tel.: +43 676 3504044<br /><br /><br /><br /> Guten Morgen ipv6-wien,<br /><br /><br /><br /> Ich schreibe Euch, um Euch um Eure Meinung und Zustimmung zu bitten:<br /><br /><br /><br /> Der derzeitige IPv6-Betrieb laeuft ja derzeit laut dem Konzept-2013 [1]<br /><br /> als 6-in-4 ueber den tunnel6.<br /><br /><br /><br /> Im Rahmen des v642-Projekts, das ja bei einem v6-Treffen Anfang 2016<br /><br /> geboren wurde, haben wir das bestehende Konzept in ein paar Punkten<br /><br /> ueberarbeitet, um IPv6 als natives Protokoll optimal nutzen zu koennen.<br /><br /> Das Ergebnis wurde um den Mai 2016 herum ausgeschickt und ist unter [2]<br /><br /> einsehbar. Die wesentlichen Punkte wurden uebernommen, insbesondere die<br /><br /> User-Prefixes (nnnnri), denn ein wichtiges Ziel war, dass die bisherigen<br /><br /> IPv6-User beim Wechsel auf v642 nicht um-adressieren muessen (renumbering).<br /><br /><br /><br /> Wir sind jetzt mit v642 soweit, dass die ersten OLSRv2-Nachbarschaften<br /><br /> stehen [3]. Damit das Netz nutzbar wird, wuerden wir gerne das Routing<br /><br /> des Prefixes 2a02:60:100::/40 aendern, das ist der Bereich, in dem alle<br /><br /> bisher genutzten Adressen liegen. Davon ausgenommen waeren alle bereits<br /><br /> vergebenen Knoten-Prefixes sowie das IPv4-Mapping (Seite 4 in [1]).<br /><br /> Diese Bereiche wuerden weiterhin zum tunnel6 geroutet.<br /><br /><br /><br /> Fuer Euch ergaebe sich dadurch keine Aenderung. Die bisher genutzten<br /><br /> Tunnel + die gemappten IPv4-Adressen bleiben, wie sie sind. Ihr koenntet<br /><br /> sogar parallel dazu OLSRv2 in Betrieb nehmen, da fuer das grundlegende<br /><br /> Routing andere Adressen genutzt werden (die Loopback-Adressen in [2]).<br /><br /> Sobald v642 bei Euch stabil laeuft, gebt ihr Bescheid, damit wir fuer<br /><br /> Euer Knoten-Prefix (nnnnri) die Route zum tunnel6 raus nehmen. Ab diesem<br /><br /> Zeitpunkt bekommt ihr dieselben IPv6-Adressen, nur eben nativ ueber IPv6<br /><br /> und nicht mehr via tunnel6.<br /><br /><br /><br /> Am Status Quo wuerde sich fuer Euch also nichts aendern. Ich schreibe<br /><br /> Euch trotzdem, weil ihr viel Arbeit in den IPv6-Aufbau gesteckt habt und<br /><br /> ich nicht will, dass der Eindruck entsteht, dass da "einer kommt und<br /><br /> alles aendert". Die Alternative ist, dass wir fuer v642 ein komplett<br /><br /> neues Prefix nutzen (z.B. 2a02:60:200::/40), das wuerde aber eben bei<br /><br /> einer Migration auf v642 ein Renumbering nach sich ziehen.<br /><br /><br /><br /> Bitte gebt mir Bescheid, wie ihr das seht und ob ihr damit einverstanden<br /><br /> waeret.<br /><br /><br /><br /> Danke,<br /><br /> David<br /><br /><br /><br /> P.S. Fuer Interessenten an v642: Die Koordination findet ueber Matrix<br /><br /> [4] statt, hier kommt ihr direkt zum Raum:<br /><br /> <a href="https://riot.im/app/#/room/#0xff-v642:hopfmueller.at">https://riot.im/app/#/room/#0xff-v642:hopfmueller.at</a><br /><br /><br /><br /> [1] <a href="http://www.ipv6.wien.funkfeuer.at/download/konzept20130321.pdf">http://www.ipv6.wien.funkfeuer.at/download/konzept20130321.pdf</a><br /><br /> [2] <a href="https://wiki.funkfeuer.at/wiki/IP-Adresskonzept">https://wiki.funkfeuer.at/wiki/IP-Adresskonzept</a><br /><br /> [3] <a href="http://78.41.119.44/olsrv2status"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> http://78.41.119.44/olsrv2status</a>/<br /><br /> [4] <a href="https://wiki.funkfeuer.at/wiki/Chat">https://wiki.funkfeuer.at/wiki/Chat</a><br /><br /><br /><br /><br /><hr /><br /> IPv6-wien mailing list<br /> IPv6-wien@lists.funkfeuer.at<br /> <a href="https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien">https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien</a></blockquote><br /><br /><hr /><br />IPv6-wien mailing list<br />IPv6-wien@lists.funkfeuer.at<br /><a href="https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien">https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien</a><br /></pre></blockquote></div><br>
-- <br>
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.</body></html>