[IPv6-wien] Migration IPv6 auf v642

[Wolfgang Nagele]

Hey,

> 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.
Korrekt.

> 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.
Auch korrekt - und würde auch vorschlagen dort L2TP und ähnliches in
Erwägung zu ziehen. Überlasse es aber den zukünftigen Tunnel Server
Maintainern da Vorschläge zu machen.

> 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?
Kannst du mir das Szenario bitte genauer erläutern? Villeicht ein
Traffic Flow Path - kann aus diesem Text nicht ganz verstehen was du
meinst.

> 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.
Yep kann man viel auf ICMP PMTU Ebene machen das man dem Enddevice
beibringt was es auf einem Link eigentlich machen kann. Oder wir
nutzen die 7k Frames die 802.11n aufwärst kann und machen FunkFeuer
Jumbo Frames? :)

> 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.
Dazu bräuchte ich das konkrete Szenario das du vorschlägst. S.o.


> 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.
Klingt lösbar/testbar. Müsste man bei jeder neuen Variante sich anschauen.

> 3.) Ein zentraler Transition Server ist ein SPoF. Verteilte Lösungen wären
> IMO zu bevorzugen.
Jein. Wir haben es - siehe v642 Doku im Wiki so gemacht das wir uns
für non-stateful Packet Translations entschieden haben. D.h. wir
können Translation Server per Anycast ins Netz announcen und damit den
SPoF wegnehmen.

lg