[IPv6-wien] ipv6 bei der upc

[Erich N. Pekarek]

Hallo!

Am 2014-09-09 um 14:19 schrieb Matthias Šubik:
...
> Also wer von Euch UPC nutzt, anscheinend kann diese Konfiguration bei fast allen Modems ausgeteilt werden, überlegt es Euch.
>
> Ich will nicht mehr zurück, Laptop dran, plopp alles online. Kein NAT mehr!
Aufgrund dessen, dass bei weitem noch nicht alle Provider ipv6 
unterstützen, hätte ich derzeit noch Bedenken (v.a. wegen 
Wartungszugang), mache mir dazu aber auch meine Gedanken:
Ein Workaround in solchen Fällen könnte Teredo sein, das unter Linux in 
der Implementierung "miredo-client" verfügbar ist. Es ist auch im 
Repository von Barrier Breaker 14.07 rc3 (OpenWRT) verfügbar, unter 
Windows sowieso.
> Da es jetzt IPv6 nativ beim größten Provider der Stadt gibt, sollten wir vielleicht auch mal überlegen, ob wir nicht auch einen Stichtag für IPv6 als Standard überlegen sollten (auch bei ggf. Verzicht auf natives v4.). DSLite oder ähnliche Verfahren könnten hier zum Einsatz kommen. Weil CGN kann ja auch 1:1 angewendet werden.
Da bleibt immer noch das Problem der alten WRTs/Buffalos und nicht so 
perfekt gewarteter (auch anderer) Router. Eine solche Umstellung kann 
daher -je nachdem- ein Befreiungsschlag oder ein Desaster werden. Zwar 
gibt es inzwischen ein besseres 5GHz-Backbone mit zu nativem v6 
befähigten Geräten als bei unserer letzten Diskussion darüber verfügbar, 
lückenlos ist dieses aber noch nicht und wird es ohne Masterplan und 
flächendeckende Beteiligung der Community nicht werden.
Carrier Grade NAT ist nicht zwangsläufig erforderlich: Theoretisch 
könnte man mit Tayga, kmod-nat46, totd (je nach Bedarf) arbeiten, um 
innerhalb des eigenen Prefix einzelne oder alle v4-Ranges abzubilden. 
Andere Möglichkeiten gibt es auch:

Varianten zur Umsetzung:
a) Teredo am Client
     Zuweisung aus dem Range 2001:0::/32; externe v6-IP des jeweiligen 
Teredo-Servers; subsidär gegenüber nativem v6. Probleme mit OLSR, daher 
nur am
     Client.
b) Teredo abseits der Spezifikation mit eigenen Teredo-Servern (entweder 
1x zentral, oder Anycast von eigenen Teredo-Servern auf performanten 
v6-Nodes) mit
     einem eigenen Prefix z.b: 2a02:61:feed::/32 (Standard: 2001:0::/32).

    /Wobei dieser Betriebsmodus für OLSR ungeeignet ist, -obwohl eine
    /128 theoretisch als Routingadresse ausreichend wäre (der
    zugewiesene Node-Prefix, respektive das Node-Device-Interface-Prefix
    wäre per HNA zu announcen)- da leider der Miredo Server selbst eine
    Art Nat64 und Nat46 betreibt und daher keine OLSR-Kommunikation auf
    seinem Tunnel-Interface selbst möglich ist. Zudem sind diese
    "transition mechanisms" meist subsidiär ausgelegt, d.h. sie treten
    aufgrund ihrer gewählten Metrik hinter native v6-Verbindungen zurück
    (und die hätten wir mit der Zuweisung aus 2a02:60/29 dem Router
    vorgegaukelt) . Soweit meine Erkenntnisse aus abgebrochenen
    Experimenten und Recherchen dazu. /

c) Auf allen Backbone-Strecken, die über roofnode/krypta/(nessus) 
erreichbar sind v6 implementieren und zusätzlich Tayga 
<http://www.litech.org/tayga/> und OLSRv4 fahren, um die v4-only 
Teilstrecken innerhalb des eigenen Prefix zu bedienen. Wächst der 
Strecke ein neuer v6 Node an, der noch Kontakt zu v4 halten muss, muss 
dieser ebenso verfahren.

c2) Für Endgeräte sollte 0xFF-Firmware denselben Mechanismus ohne OLSR 
bereitstellen.
Ich spiele mich gerade mit einer Firmware dieser Art basierend auf 
OpenWRT BB14.07rc3 - Benutzung auf eigene Gefahr. Ich stehe damit noch 
am Anfang, und die Sources sind freigeben und oder dokumentiert. Es soll 
Jeder, der das möchte, wahlweise den ImageBuilder nutzen oder den Tree 
nach Belieben selbst kompilieren - es wird also eine echte Community 
Firmware.
DNSmasq und Totd konkurrieren in 0.1.0 auf Port 53, d.h. die 
Namensauflösung klappt noch nicht. 
https://drive.google.com/folderview?id=0B4y0xd6CC7JtaC0xY2stcVNOTTg&usp=sharing
Ich wäre über Feedback jeder Art dankbar. Die Erkenntnisse aus diesem 
Zweig sollen in 0xFF-OS einfließen.
Diese Firmware hat zram-swap aktiviert, um so auch auf älteren Bullet, 
Nanostations, etc ohne "M", mit nur wenig Ram funktioniert.

d) Sonstiges Tunneling: möchte ich vermeiden, da es Teilinformationen 
über den Zustand des Netzes verschleiert.
>
> bG
> Matthias
>
LG
Erich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/ipv6-wien/attachments/20140909/9b7bfeef/attachment.html>