[IPv6-wien] Migration IPv6 auf v642

Wed Mar 15 18:41:59 CET 2017

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.