[Problem] KabelBW/Unitymedia: IPv6 mit Technicolor Modem und FB7390

[TheMagican]

Hallo allerseits,

ich bin Unitymedia-(Privat-)Kunde und komme deshalb nicht mehr durch Nachfrage an eine eigene IPv4 Adresse (ist wohl seit April nur noch mit Business-Anschlüssen möglich). Mein Plan war daher, per IPv6 auf mein Heimnetz zuzugreifen und IPv4-Verbindungen über meinen vServer laufen zu lassen.
Mein Problem ist jetzt, dass durch meine FritzBox 7390 (Freetz Trunk mit dnsmasq) hinter dem Technicolor-Modem von Unitymedia kein IPv6 möglich ist. Ich bekomme mit meinen Geräten eine globale IPv6 zugewiesen (2a02: ...), jedoch sind keine IPv6 Verbindungen möglich: wget --inet6-only bricht mit einem Timeout ab und der Google IPv6-Test bestätigt mir auch, dass IPv6 nicht möglich sei.

Ich habe jetzt in einem KabelBW-/Unitymedia-Spezifischen Forum nachgeforscht und dort konnte mir der Grund für das Problem erklärt werden: Das Problem ist nicht die FB sondern das Technicolor Modem, was effektiv eben kein Modem sondern ein Router ist. Dieses Teil ist - nennen wir es "ungeschickt" konfiguriert. Ich versuche es mal mit meinem Beschränkten IPv6-Wissen zusammenzufassen, in der Hoffnung dass es verständlich bleibt, ansonsten bitte in oben verlinktem Thread nachlesen
Das Modem gibt grundsätzlich nur /64 Adressen heraus und führt eben keine Prefix Delegation für andere Router durch. Dementsprechend erhält die FB und auch alle anderen, direkt mit dem Modem verbundenen Clients eine gültige IPv6-Adresse, jedoch erhält die FB eben keinen Präfix, mit dem sie weitere LAN Geräte versorgen kann. Beispielsweise bekommt die FB die IP 2a02:XXXX:XXXX:1400:XXXX:XXXX:XXXX:XXXX, zeigt im WebInterface als Präfix jedoch 2a02:XXXX:XXXX:1480::/64 an und gibt diesen auch ins LAN weiter - ich frage mich jedoch, wie genau der Präfix bei fehlendem Prefix Delegation zustande kommt. Mit den so vergebenen IPs kommt dann keine IPv6-Verbindung zustande.

Bei OpenWRT gibt es für das Problem einen Workaround:

Was OpenWRT da macht ist jenseits der Specs. Die Community macht sowas, aber ein Router-Hersteller normalerweise eher nicht.
[...]
udhcpc ist unter Linux die Standardkomponente für den Adressbezug.
OpenWRT ersetzt diese durch odhcpc/odhcpd, wobei odhcpc/odhcpd bei fehlender Präfix-Delegation einen nicht ganz normkonformen Trick anwendet - es re-announced einfach das selbe Präfix das es auf WAN-Seite gelernt hat auch LAN-seitig.
Damit ist der so laufende OpenWRT-Router zwar de facto kein Router mehr (Er und seine Clients befinden sich IPv6-mäßig im selben Netz wie der vorgeschaltete Router, was bei einem Router gar nicht sein dürfte), aber - wenn die IPv6-Firewall, das DNS-Relay usw. in Betrieb bleiben - immer noch mehr als ein reiner Access Point.

Weiß jemand vielleicht, ob das mit den in Freetz vorhandenen Bordmitteln auch möglich ist?


Vorab vielen Dank!

 

[TheMagican]

Ich habe jetzt selbst mal etwas experimentiert. Was ich hier schreibe sind größtenteils Vermutungen und Halbwissen, korrigiert mich also, wenn ich falsch liege...

Wie ich das sehe, hat die FB ein virtuelles Netzwerkgerät "lan" um das wir uns kümmern müssen. Entsprechend der Konfiguration der FB wird dieses wohl aus den verschiedenen physikalischen Geräten (LAN-Anschlüsse, WLAN) von multid zusammengebaut. Multid ist dabei auch für die IP-Adressvergabe zuständig. Multid geht wohl davon aus, dass man von einem vorgeschalteten Router mindestens ein /56 Netz bekommt (?); dementsprechend setzt es die IP-Adresse des lan Devices bspw. auf 2a02::1180:..., wenn es vom Kabelmodem die IP-Adresse 2a02::1100:... bekommen hat, und verwendet dies auch als Präfix für die IPv6-Adressen im LAN. Vermutlich verwirft das vorgeschaltete Kabelmodem jedoch sämtliche Pakete aus 2a02::1180:/64 , da es die IPs nicht kennt bzw. keine Route hat (Vermutung!).

Um das, was OpenWRT macht, abbilden zu können, müssen wir also auf dem lan Device Router Adveritsements schicken, die in dem vom Kabelmodem zugewiesenen "Präfix" liegen. In einem ersten Versuch habe ich das mit dnsmasq gemacht. Hierfür muss man zunächst den IPv6-DHCP Server der FB deaktivieren und dann dnsmasq entsprechend konfigurieren. Man hat hier die Wahl zwischen einer statischen Konfiguration des Präfixes oder man holt sich den Präfix von einem bereits konfigurierten Device. Hierbei ergibt sich das Problem, dass die IP-Adresse des lan Geräts durch multid verwaltet wird. Multid beharrt auch auf diese Konfiguration, so dass man dem lan Device keine andere IP als die von Multid berechneten zuweisen kann. Macht man es trotzdem, wird die neue IP von Multid nach einigen Sekunden automatisch wieder gelöscht. Korrekterweise / Leider weigert sich jedoch dnsmasq einen Präfix auf einem Device zu verteilen, das selbst keine IP in diesem Präfix hat, weshalb man so leider trotzdem nur IPs im falschen Präfix bekommt.

In einem zweiten Versuch habe ich radvd anstatt dnsmasq verwendet, da man hierzu auch deutlich mehr Infos im Netz findet. Radvd ist hierbei so nett, und gibt angeschlossenen Geräten tatsächlich eine IP im konfigurierten, "korrekten" Präfix, den das Kabelmodem auch akzeptieren würde, gleichzeitig vergibt es aber auch IPs im "falschen" Präfix des lan Devices. Radvd kümmert sich hier auch gleichzeitig darum, dass das lan Device eine IP im "korrekten" Präfix bekommt - welche multid dann auch sofort wieder löscht. Dementsprechend bekommen Clients dann zwei IPs, eine im korrekten und eine im falschen Präfix, IPv6 Verbindungen sich jedoch trotzdem nicht möglich

Ich vermute, dass eine Lösung mit der dauerhaften Zuweisung einer "korrekten" IPv6-Adresse an das lan Device und vermutlich auch noch der Anpassung von Routen steht oder fällt. Hat da jemand vielleicht Erfahrungen, wie man das schaffen könnte? Leider kenne ich mich mit den FB-Internas zu wenig aus