IPv6: Schwere Geburt

In den letzten Monaten wird verstärkt für IPv6 geworben und es entsteht der Eindruck, dass man völlig veraltet ist, wenn man nicht ein IPv6 taugliches Netz hat. Und in der Tat ist ein Umstieg bzw. Parallelbetrieb von IPv6 absolut richtig im Hinblick auf den gewollten Umstieg.

Aber irgendwie wird es nicht leicht gemacht.

Bedingt durch die Arbeit und den Aufbau einer neuen Firewall mit OpenWRT hatte ich beschlossen, dass es Zeit für IPv6 wird. Wenn nicht so ein Neuaufbau dazu genutzt wird, was dann?

Deshalb habe ich gleich bei der Strukturplanung Subnetze für v6 vorgesehen. Nach anfänglichen Verständnisproblemen bei der Konfiguration von OpenWRT bekamen dann die Subnetze tatsächlich vom OpenWRT ihre vorgesehenen Subnetze mit der definierten ULA (Unique Local Address) mitgeteilt.

Das ging aber, wie sich schnell gezeigt hat, nur, weil IPv6 so viel automatisch macht. Wirklich gezielt war da noch nichts: neighbor solicitation hatte da nur gearbeitet.

Erst die Installation des "radvd", also des "Router Advertisement Daemon" brachte hier wirklich eine bewusste Konfiguration. Aber bis dahin immer nur ULA, also lokale Adressen.

Nun sollte der Router doch aber die IPv6 Prefixe vom ISP bekommen und daraus dann Subnetze bilden, die dann exakt mit der gewünschen Subnetznummer per Router Advertisement auf dem passenden Ethernetport gesendet werden sollten. Wie testet man das ohne die laufende Firewall abzuklemmen?

Und wie macht das das dynamisch, da der Prefix sich zum einen ändern kann (danke ISPs, dass ihr da wie bei IPv4 ständig die Adressen ändert) und man zum anderen ISP-Unanhängig bleibt (danke ISPs, das macht den Wechsel zu einem anderen Anbieter viel leichter)?

Lange Rede, kurzer Sinn: Erst die Installation eines DHCPv6 Servers auf einem 2. System, das dann als WAN an die Firewall angeschlossen wurde, half. Dann hat die Magie das Prefix tatsächlich verteilt.

So weit die schöne Welt.

Als nächstes dachte ich dann, dass IPv6 zuhause sicherlich auch nicht so schwer werden kann. Da gibt es keine Subnetze, muss doch viel einfacher sein. Eine Fritzbox und ein DHCPv4 auf einem Raspberry, damit DNS-Server auf einen eigenen zeigen, damit die Geräte im LAN auch Namen haben. Doch ein simpler Aufbau.

Tja, das Prefix wird von der Fritzbox auch wunderbar per Router Advertisement verteilt. Entweder bauen sich die Hosts dann daraus selbst ihre Adresse als 64er Netz oder man aktiviert auf der Fritzbox den DHCPv6. Die verteilt dann auch gleich den eigenen DNS-Server.

Zu dumm.

Wie arbeitet man nun mit Hosts im LAN? Früher, mit IPv4 gab es DNS. Gibts natürlich immer noch. Früher, mit IPv4 hat man temporäre Systeme auch mal schnell mit der IP-Adresse erreicht. Das will man wohl nicht mit den v6 Monstern.

Da ist es also die beste Lösung, für die Systeme im LAN die Namen im DNS zu hinterlegen. Der DNS-Server, der eigene, wurde deshalb per eigenen DHCPv4 Server verteilt.

Also wäre es wohl nötig, einen DHCPv6 Server aufzusetzen, da die Fritzbox nunmal nur sich selbst bzw. den ISP als DNS-Server verteilt. Da kann man nur froh sein, dass der DHCPv6-Server abschaltbar ist.

Doch der DHCPv6 macht ja eigentlich noch was ganz anderes: er verteilt das Prefix! Und woher soll man das nun bekommen? Sieht man sich die IPv6 RFCs zu "Prefix delegation" an, steht da wirklich nur DHCPv6? Eigentlich ja, RFC 6603 ist optional laut Wikipedia. Sicherlich nirgendwo implementiert. Achso, und es ist eine DHCPv6 Option! Schon wieder DHCP.

Das heißt: diese Fritzbox sendet entweder kein Prefix oder auch gleich sich als DNS-Server. Herzlichen Glückwunsch.

Allerdings, denkt man darüber weiter nach, bekommt man sowieso noch mehr Sorgen:

Welche Adresse sollte man in seinen DNS eigentlich eintragen? Die ULA? Die globale (Global Unicast, ich nenne sich weiterhin nur global)? Konsequent wäre die globale v6 IP. Wäre da nicht dieses Prefix, dass sich jederzeit ändern kann. Oder wäre da auch mal gar kein Prefix, weil der ISP gar keins geliefert hat, da die Verbindung gestört ist.

Unter IPv4 wäre das konsequenterweise eine private Adresse gewesen (192.168/16 oder 10/8), mit IPv6 wäre das ja nicht nötig.

Hätte man nun irgendwie das Prefix und irgendwie den richtigen DNS-Server im LAN verteilt, dann müsste das Zone-File irgendwie auch noch angepasst werden - damit es die globale Adresse hat, keine ULA. Will man dann noch etwas strukturierte Adresse statt der EUI aus der Mac-Adresse haben, müsste der DHCPv6 Server diese auch verteilen. Oder aber irgendwie müssten die Hosts anhand eines konfigurierten Hostansteils und des verteilten Prefix ihre Adresse bilden - wie sie es bei der EUI ja auch schaffen.

Und dann müsste ein DNS-Server oder Dyn-DNS-Service das neue Prefix auch noch erfahren und ebenfalls seine DNS-Einträge anpassen.

Denkt man darüber nach, lässt man IPv6 wohl erstmal sein:

  • mir ist noch keine Syntaxbeschreibung geschweige denn eine Beschreibung, dass es das überhaupt gibt untergekommen, die es erlaubt, den Hostadressenanteil zu konfigurieren, aus der sich dann das System selbst seine Adressen (ULA, Global, vielleicht sogar die Link-Local?)
  • AAAA: ja, macht Spass da eine Adresse im DNS einzutippen. Inklusive Prefix, macht wohl bei ULA noch Sinn, bei dynamischen Global Unicast Prefixen wohl nicht
  • Dyn-DNS-Services können wohl schon IPv6 DNS, aber eher so wie bei v4; man könnte auch sagen, nicht drüber nachgedacht.

Aber mit den Sorgen stehe ich wohl nicht alleine da:

Klar, die ganzen Kühlschränke, Steckdosen, Lichtschalter, usw., die alle ja irgendwann im Netz sein sollen und eine eigene IP-Adresse haben sollen, werden wohl ohnehin aktiv eine Verbindung zu einem Server aufbauen. Dafür brauchen sie dann nun aber doch kein IPv6 in der jetzigen Form. Dafür hätte es auch eine Umsetzung wie bei v4 getan: Eine Adresse für den dummen User und NAT auf seinem Router.

Und die ganzen Firmen, die irgendwann solche Kühlschränke verkaufen, die sich bei deren Server melden sollen? Naja, die müssen halt einen Vertrag bei einem ISP abschließen, der für teures Geld eben nicht ständig das Prefix ändert. Dann bekommt der ISP dann sogar extra Geld dafür, dass er das Random-IP-Script nicht laufen lässt. Er bekommt dann dafür Geld, dass in seiner Kunden-Datenbank im IP-Prefix-Feld eben diese Adresse steht.

Oder die Firmen kaufen sich gleich ein komplettes /32 Netz. Das bräuchten sie ja eigendlich gar nicht, wenn die Software wirklich IPv6 untersützen würde. Also wirklich-wirklich. Nicht nur von der Syntax und den neuen System-APIs her. Sondern auch vom Konzept her.

Ist doch optimal: es werden weltweit einige Millionen der Internetfähigen Mikrowellen verkauft. Davon schaffen es 80% der Kunden wirklich, diese ans Netz zu bringen. Eine kleine Serverfarm von 5-10 Hosts, ist dabei sicherlich die meiste Zeit unbeschäftigt. Also 5-10 IP-Adressen. Damit diese aber wirklich konstant bleiben, d.h. auch ein festes Prefix haben, also eine globale Adresse die man nur 1x im DNS-Server eintragen muss, bekommt man 18.446.744.073.709.551.616 Adressen - dumm wie ich bin würde ich diese 18000 Billiarden nennen weil ich mir mit Trillionen nicht sicher bin. Nach Aussen wäre wohl sogar nur eine Adresse sichtbar, Stichwort Load Balancer.

Und trotzdem wird diese Firma in ihrem Büro ein dynamischen Prefix von ihrem ISP haben und ihren lokalen Mailserver wohl nur per ULA ansprechen (im DNS).

Toll!

Und der private Netzanwender? Vielleicht wird der sich davon abwenden oder wird irgendwie über Foren, Open Source Entwicklung oder sonstwas versuchen, genau diese fehlenden Konzepte in die Software zu bringen. Um so um die Einschränkungen drumherum zu arbeiten, die durch das Unverständnis des Konzepts entstehen.

Achso, noch so ein paar Dinge:

  • Einige ISPs schalten statt Dual-Stack bei aktivierten IPv6 im Kundenkonto echtes IPv4 ab, es gibt dann dort nur noch NAT.
  • Diese dynamischen Prefixe verdanken wir wohl auch der Sicherheitssorge einiger Leute: durch nicht immer gleiche IP denke diese annonym bleiben zu können - das wurde aber schon zu IPv4 Zeiten umgangen, trotz dynamischer IP.
  • Die privacy extension, die den Hostanteil der IPv6-Adresse zufällig setzen soll, ist auch nur lächerlich: Zum einen wegen dem Punkt drüber, zum anderen wegen des Prefix: der ist 24 Stunden gleich, ausreichend für das Tracking.

Und ich?

Mal sehen, was sich noch findet. Vielleicht sind die Tools ja doch schon klüger als sie es bisher scheinen und können doch so gut mit Prefixen umgehen. Positiv denken!