Datenschutzfreundliches IPv6 für Endkunden
Ich hatte mich weit aus dem Fenster gelehnt. IPv6 an Endkunden sollte mit zwei rotierenden, dynamischen Prefixen und einem Statischen ausgeteilt werden. So sollte der Endkunde vor einer Identifizierbarkeit anhand seiner IP-Adresse "geschützt" werden.
Zwei Aufträge
Zum einen wünschte ein Kunde, für den wir eine Broadband-Plattform betreuen, die Möglichkeit IPv6 auszuteilen. Er selbst mußte schon vor längerer Zeit für den Standardkunden auf CGN ausweichen. Allerdings unterstützte die dort eingesetzte kommerzielle Technik IPv6 nicht ausreichend.
Zum anderen wünschte der Veranstalter des IPv6-Kongresses einen Bericht über praktische Erfahrungswerte mit solch einem Setup.
Die anfängliche Euphorie, bei der Planung des Setups auftrat, verflog rasch.
Das größte Problem war die Auswahl der verwendbaren Technik. Alle kommerziellen Systeme machten nicht den Eindruck gern mit rotierenden oder gar mehreren Prefixen arbeiten zu wollen. Man würde tricksen müssen. Das bedeutet massive Änderungen an existierender Software und lange Debugsessions mit dem Hersteller der LNS-Systeme.
Alternativ stand eine Eigenentwicklung des Systems auf Basis von OpenSource zur Auswahl. Dort würde man Einkaufskosten gegen Entwicklungszeit tauschen. Dafür hätte man aber alle Bausteine in der Hand, um die Lösung so zu bauen, wie sie laufen solle.
Die Entscheidung fiel zugunsten von MPD auf FreeBSD. Der Weg war steinig, und es läuft nach wie vor nicht völlig rund.
Etwas Theorie
IPv6 auf PPP Verbindungen ist ganz anders als IPv4 auf PPP. Da IPv6 so viele schöne Eigenschaften aufweist, sucht sich jeder nur den Teil raus, der ihn gerade interessiert. So handelt IPv6CP nur Link-Local Adressen im PPP aus.
MPD liefert also nicht mehr als einen Link zum Endkunden auf dem beidseitig Link-Local Adressen gebunden sind. Alles weiter überläßt der MPD anderen Diensten.
Die typische Broadband-Implementiereung sieht dann so aus, daß Router-Advertisements auf diesen Link gesendet werden. Die announcieren, daß sich das Gerät bitte beim DHCPv6-Server melden möge, um den Rest zu erfahren.
Der DHCPv6 Server weist dann DNS und NTP-Server sowie die Prefixe für die Verwendung hinter dem Gerät zu.
Tückische Praxis
Unglücklicherweise bedarf Software wie radvd und dhcpd einer Liste der Interfaces an denen sie lauschen sollen. Diese ist aber gar nicht bekannt, da die Interfaces dynamisch bei der Einwahl eines Endkunden entstehen und auch wieder verschwinden.
Auch hier wieder stand die Entscheidung: Anpassen einer existierenden Software oder Neuentwickeln. Und wieder viel die Entscheidung zugunsten der Neuentwicklung aus.
FreeBSD bietet im ipfw-Code die Möglichkeit, anhand von Regeln Pakete auszuleiten. Mittels ipdivert können die Pakete an einen Userspace-Daemon übergeben werden. Das klang ideal.
add 9000 divert 12345 udp from fe80::/64 to ff02::1:2 dst-port 547 recv ng* in
Aber es kamen keine Pakete in meiner Software an. Denn das ipdivert-Modul kann nur IPv4-Pakete ausleiten.
Erst nach entsprechenden Patches meinerseits war ich in der Lage festzustellen, daß auch schon andere Leute dieses Problem erkannt und gepatcht (kern/128260) hatten. Und natürlich beinahe genauso.
Der entsprechende Code für einen DHCPv6 Server binnen zwei Wochen geschrieben. Diese Schnelligkeit basiert auf den bewährten Prinzipen: "Works for me" also "Entwickle nur, was gerade nötig ist" und "Not invented here" also "Lies nicht nach, was andere getan haben". Alles andere kostet nur Zeit. :)
Aber der Code funktionierte nicht! Er teilte IPv6 Prefixe zwar aus, aber die wurden nicht akzeptiert. Ebensowenig wurden Datenpakete von extern an die PPP-Ziele weitergereicht. Lokale pings gingen aber.
Es hat geschlagene zwei Tage gedauert, bis net.inet6.ip6.forwarding=1 von mir endlich gesetzt wurde. Schlichte Betriebsblindheit.
Der Grund für die Inakzeptanz meiner vorgeschlagenen Konfigurationen mußte durch systematisches Raten an einer Test-FritzBox ermittelt werden: Sie akzeptierte die zugewiesene IP Adresse nicht, weil sie dafür kein LAN-Interface fand. Sie sollte es ja auch an ein PPP-Interface binden, das braucht eigentlich kein ganzes Netz!
Im Gegenteil die Abstraktion, die PPP bzgl. IPv6 macht, ist nicht nur Link-Local-Adressen zu setzen, sondern den Link als LAN-Link anzusehen. müssen die zugewiesenen IP-Adressen "on-link" sein. Aber ich hatte selbst nur Link-Local-Adressen am MPD.
Da für andere Zwecke bereits ein Quagga lief, sollte der probeweise die IPs zuweisen und die Router-Advertisements verschicken. Glücklicherweise konnte er das mit mehreren tausend Interfaces. Die Vorkonfiguration kann statisch erfolgen. Problem solved.
Nun akzeptieren die Endgeräte auch IPv6-Prefixe und die gesamte Plattform hebt ab!
Erste Zahlen
Etwa 2% der Endkundengeräte verlangen und bekommen IPv6. Dies ist viel, da die Endkunden aktiv IPv6 auf den CPEs einschalten müssen.
Etwa 0,4% des Traffics ist nach einigen Stunden IPv6. Auch das ist viel: Die IPv6-aktivierterten Kunden haben also ca. 20% des Traffics per IPv6 abgewickelt.
Die Hauptgegenstellen sind
- die lokalen DNS Server (was zu erwarten war)
- eBay (Kleinanzeigen)
- FreeMail Provider per SMTP und IMAP(S).
Insgesamt ist also der Rollout erfolgreich. Details erzähle ich später mal.
1 Kommentare