IPv6 im Heimnetz mit pfSense und dynamischer Prefix Delegation – Teil 1

Vielleicht ist der Titel etwas verwirrend, denn ob der Begriff “dynamische Prefix Delegation” überhaupt existiert, ist mir nicht wirklich bekannt. Gemeint ist die dynamische Adressvergabe seitens des Providers, der nach der hierzulande bei DSL-Anschlüssen üblichen Zwangstrennung sowohl neue IP-Adressen als auch mittels Prefix Delegation ein jeweils neues IPv6-Netz zur Verfügung stellt. Bei meinem Provider NetCologne erhält man sowohl eine /64-Adresse, als auch ein /48-Netz, das wiederum zur Aufteilung in 65536 /64-Netze und deren 18 Komma ein paar zerquetschte Trillionen IPv6-Adressen genutzt werden kann. Das sollte für ein Heimnetz vielleicht gerade so reichen.

IPv6 im Heimnetz – ja, aber…

Zugegebenermaßen hatte ich IPv6 mit seinen Fantastilliarden IP-Adressen bis vor kurzem weitestgehend ignoriert. Schließlich war IPv4 so schön einfach, und alle relevanten privaten IP-Adressen ließen sich leicht merken. Irgendwann siegte jedoch die Neugier auf etwas Neues, und so habe ich mich ein wenig mit der Thematik beschäftigt. Das Ziel war, im heimischen Netzwerk die vom Provider zur Verfügung gestellten IPv6-Adressen zu nutzen, und zwar mit möglichst wenigen Änderungen an der bislang verwendeten Hard- und Software sowie deren Konfiguration. Ganz hat das nicht geklappt, aber dazu später.

Ein Hinweis am Rande – in diesem Artikel werde ich nicht die Grundlagen von IPv6 erläutern. Dazu gibt es nicht nur Unmengen Beiträge in Zeitschriften, Dokumentation von Router-Systemen, Blogs etc., sondern auch wirklich gute Videos auf diversen Kanälen bei YouTube. Mir haben diese beim Einstieg in die Thematik sehr geholfen, daher beschränke ich mich hier auf den Weg hin zu einer bei mir aktuell laufenden IPv6-Konfiguration.

IPv6 – Wunsch(konfiguration)…

Zunächst zu den Gegebenheiten. Als erste Instanz dient die Fritz!Box, die per PPPoE die Verbindung zum Provider herstellt, den IP-Verkehr hinein- und wieder heraus routet, und nebenbei noch ein paar Telefone verwaltet. Daran sollte sich nichts ändern. Insbesondere sollte die Fritz!Box weiterhin die erste Bastion des heimischen Netzes darstellen, d.h. es sollte kein PPPoE-Passthrough stattfinden, bei dem der nachfolgende Router die PPPoE-Verbindung hergestellt hätte. Denn einen solchen gab es ebenfalls, und zwar in Form eines bzw. zweier Thin-Clients mit OPNsense. Die Konfiguration entsprach dem System einer Router-Kaskade mit unterschiedlichen privaten IPv4-Netzen, doppeltem NAT, der einen oder anderen Port-Weiterleitung etc., das letztlich seit geraumer Zeit problemlos und stabil lief.

Als zweite Instanz stand somit ein System mit OPNsense, das – wie zuvor ebenfalls – für die Vergabe von IP-Adressen, Routing zwischen internem Netz und Fritz!Box, Firewall usw. zuständig sein sollte. Nur eben nicht mit IPv4-Krücken wie NAT, sondern mit IPv6-Hausmitteln wie Prefix Delegation, Router Advertisement, SLAAC, aber auch DHCPv6, da nicht nur die Betriebssysteme Linux, Windows, MacOS und Android im Heimnetz Verwendung finden, sondern ich es auch für eine nette Idee hielt, wenn einige der im Netz vorhandenen VMs mit Server-Diensten eine (bis auf den Prefix) statische IPv6-Adresse zugewiesen bekommen.

Kurzum – die Fritz!Box stellt die Verbindung zum Provider her, erhält das /48-Netz, OPNsense besorgt sich von der Fritz!Box ein entsprechendes Prefix für ein eigenes Subnetz. Für dieses eigene Subnetz übernimmt OPNsense alle notwendigen Dienste, also Routing, IPv6-Adressvergabe usw.. Damit könnte die Geschichte bereits zu Ende sein, denn nach gefühlten 20, aber realistischeren drei Stunden war die Erstkonfiguration erledigt, so dass nicht nur die OPNsense-Maschine mit “echten” IPv6-Adressen ausgestattet war, sondern auch alle anderen Rechner im lokalen Netz.

…und Wirklichkeit

Die einzelnen Netzwerk-Ports werden bei OPNsense wie auch bei pfSense innerhalb der “Interfaces”-Einstellungen den jeweiligen Bereichen zugeordnet. Zwingend notwendig sind die Bereiche “WAN” und “LAN“, auf weitere, inkl. der zuvor bereits konfigurierten Hochverfügbarkeit (“PFSYNC“) habe ich zunächst verzichtet. Am Interface “WAN” ist somit die Fritz!Box angeschlossen, während “LAN” an einen Switch geht, an dem sich die Maschinen im lokalen Netzwerk befinden. Und genau dabei stellten sich erste Probleme ein. Denn während die WAN-Schnittstelle auch nach der nächtlichen Zwangstrennung mit einem neuen Prefix und somit einer neuen IPv6-Adresse versorgt wurde, bekam der LAN-Anschluss davon nichts mit. Auf diesem war nach wie vor das alte Prefix und somit eine nun nicht mehr gültige IPv6-Adresse vorhanden. Das führte dazu, dass alle Rechner im Netz nach dem Prefix-Wechsel keine gültige IPv6-Adresse mehr besaßen, insofern keine Verbindung zu externen IPv6-Adressen mehr möglich war. Trotz intensiven Suchens und unzähligen Konfigurationsversuchen fand sich jedoch keine Lösung. Das Problem wird an einigen Stellen, unter anderem auch in einem Bericht auf GitHub beschrieben, die dort vom Autor genutzte Lösung, OPNsense mittels PPPoE die Verbindung herstellen zu lassen, wollte ich jedoch ausdrücklich nicht einsetzen.

Nun stammt OPNsense von pfSense ab, und mancherorts finden sich Hinweise, dass pfSense vermeintlich besser bzw. stabiler laufen soll. Zwar wollte ich mich an dieser Diskussion nicht beteiligen, aber da ich noch einen ähnlichen Thin-Client-Rechner ungenutzt im Regal hatte, fiel der Entschluss, pfSense eine Chance zu geben. Also flugs installiert und konfiguriert, dann testweise die Fritz!Box eine neue Verbindung herstellen lassen – und siehe da – es zeigte sich genau dasselbe Verhalten. Nach Verbindungstrennung und Vergabe eines neuen Prefix war die WAN-Schnittstelle aktualisiert, während beim LAN-Interface nach wie vor das alte Prefix festgezimmert war. Nach dem üblichen Dreiklang aus Recherche (Google, Lesen), Konfigurationsoption ändern und Testen – und das ganze wieder von vorne, war pfSense zwar soweit funktionsfähig, um nicht zu sagen “optimiert”, dass “irgendwann” auch das LAN-Interface das neue Prefix, ergo eine neue IPv6-Adresse erhielt, aber genau diese Verzögerung konnte kaum im Sinne des Erfinders sein. Denn bei dieser Zeit handelte es sich um die Lease Time des DHCPv6-Servers. Deren Default liegt bei 7200 Sekunden, insofern dauerte es maximal knapp zwei Stunden, bis die LAN-Schnittstelle und damit auch alle angeschlossenen Rechner eine neue und somit gültige IPv6-Adresse erhielten.

Bevor ich zu einer bzw. zu meiner Lösung komme, möchte ich zunächst die hier verwendete pfSense-Konfiguration im Folgenden aufzeigen und kurz erläutern.

IPv6-Konfiguration mit pfSense im Detail

Im Bereich “System” -> “Advanced” -> “Networking” muss zunächst “Allow IPv6” aktiviert sein. Ansonsten wurden die Default-Einstellungen beibehalten, die Option “DHCPv6 Debug” diente – wie die Bezeichnung nahelegt – zu Debug-Zwecken und kann letztlich im produktiven Betrieb deaktiviert werden:

Interessanter wird es bei der Konfiguration der Interfaces. Die Zuweisung von Netzwerk-Port zum Interface wird unter “Interfaces” -> “Assignments” vorgenommen, bei meiner Hardware ist der erste Port der Netzwerkkarte (“igb0“) das WAN-Interface, während der eingebaute Netzwerk-Port des Thin-Clients mit der Bezeichnung “re0” das LAN-Interface darstellt.

IPv6 – WAN-Interface

Für jedes so zugewiesene Interface findet sich unter “Interfaces” -> “<NAME>” eine Seite zwecks Konfiguration. Zunächst das WAN-Interface:

Der Übersicht halber habe ich dem Interface den Namen “WAN_FritzBox” gegeben, dabei handelt es sich jedoch um eine Bezeichnung, die grundsätzlich frei gewählt werden kann. Die Fritz!Box ist für die Umsetzung der internen, privaten IPv4-Adressen in die öffentliche IPv4-Adresse zuständig, was ganz klassisch per NAT passiert. An der LAN-Schnittstelle liegt das erste, private IPv4-Netz an, die IP-Adresse ist dabei statisch eingestellt. Was an der Fritz!Box an der LAN-Schnittstelle heraus geht, kommt beim pfSense-System somit an der WAN-Schnittstelle an, und umgekehrt. Die IPv4-Adresse des WAN-Interfaces ist somit statisch definiert, konfiguriert unter “Static IPv4 Configuration” mit einer IPv4-Adresse aus demselben Netz, als “Upstream-Gateway” dient konsequenterweise die Adresse der Fritz!Box.

Bei IPv6 wird es schon interessanter, denn die Fritz!Box soll die zur Verfügung stehenden öffentlichen IPv6-Netze anhand des Prefix an pfSense weitergeben, und da sich der Prefix nach der Verbindungstrennung nun einmal ändert, kommt bereits DHCPv6 auf Seiten der Fritz!Box zum Einsatz. Auf deren Einstellungen werde ich weiter unten noch kurz eingehen.

Die WAN-Schnittstelle von pfSense muss daher alle notwendigen Daten per DHCPv6 beziehen. Sobald dieser “Configuration Type” gewählt ist, öffnet sich ein Bereich für dessen Konfiguration im Detail. Die erste aktivierte Einstellung lautet “Request only an IPv6 prefix“. Die pfSense-Maschine soll keine IPv6-Adresse von der Fritz!Box erhalten, sondern nur das Prefix vermittelt bekommen, so dass sie sich eine IPv6-Adresse “aussuchen” bzw. generieren kann.

Prefix Delegation Size Verwirrungen

Einiges Ausprobieren erforderte die Einstellung der “DHCPv6 Prefix Delegation Size“. Die Prefix-Länge ist hier auf 57 eingestellt, obwohl der Provider doch ein /48-Netz anbietet, wie im folgenden Screenshot zu erkennen ist:

Wie passt das nun zusammen? Tatsächlich habe ich darauf keine eindeutige Antwort, sondern würde es am ehesten mit “Fritz!Box-Magie” umschreiben. Zwar benötigt die Fritz!Box auch eigene IPv6-Netze, etwa für das Gastnetz, aber alles andere könnte sie doch weitergeben, so meine Annahme. Also wenn sie ein /48-Netz erhält, müsste sie daraus zwei /49-Netze machen können, von denen sie sich auch gerne eines schnappen, aber das andere weiterreichen könnte. Genau das funktionierte jedoch nicht. Es stellte sich heraus, dass der kleinstmögliche Prefix, und somit die größtmöglichen Netze die Delegation Size von 57 hatten. Alles unter 57, d.h. von der minimal wählbaren Größe 48 bis hin zu 56 führte dazu, dass das WAN-Interface von der Fritz!Box keine IPv6-Adresse erhielt. Alles ab der Delegation Size von 57 bis hin zu 64 funktionierte jedoch, wobei die 64 noch eine Besonderheit zeigte, und zwar wurde beim LAN-Interface von pfSense dabei plötzlich eine Prefix-Länge von 62 angezeigt, während diese bei allen anderen Delegation Sizes 64 betrug.

Die Dokumentation von AVM führte hingegen nur zu größerer Verwirrung, denn auf der Wissensbasis-Seite “IPv6-Subnetz in FRITZ!Box einrichten” wird zwar im Detail beschrieben, wie die Voraussetzungen auf Seiten der Fritz!Box sind, also dass vom Provider ein Prefix größer als 64 Bit, insofern kleiner als /64 geliefert werden muss. Unten im Bereich “IPv6-Router einrichten” bin ich jedoch über den folgenden Satz gestolpert “Jetzt ist der Router für den Einsatz mit eigenem IPv6-Subnetz eingerichtet und erhält von der FRITZ!Box per DHCPv6 Prefix-Delegation ein /62-Präfix.” Warum gibt AVM hier einen /62-Prefix an? Ein /62-Prefix hätte laut IPv6-Subnet-Calculator nur vier /64-Netze. Kann die Fritz!Box mit mehr Netzen nicht umgehen, gleichgültig, wie viele der Provider anbietet? Und falls dies zutreffen sollte, warum funktioniert die Anforderung dann bis zur Delegation Size von 57 mit immerhin 128 Netzen? Vielleicht ist aber auch nur die Wissensbasis-Seite nicht mehr aktuell…

Das Häkchen bei “Send IPv6 prefix hint” ist zwingend notwendig, denn, wenn dieser nicht gesendet wird, passiert rein gar nichts. “Do not wait for a RA” habe ich ebenfalls aktiviert. Damit wäre die Konfiguration des WAN-Interfaces bereits abgeschlossen. Nach dem Speichern und Aktivieren sollte pfSense ein Prefix bezogen und somit bereits eine öffentlich geroutete IPv6-Adresse besitzen. Diese kann z.B. auf der Dashboard-Seite in der Box “Interfaces” eingesehen werden.

IPv6 – LAN-Interface

Nun zur Konfiguration des LAN-Interfaces von pfSense:

Die Bezeichnung ist wieder frei wählbar, ich habe es bei “LAN” belassen. Auch die IPv4-Adresse im LAN ist als statisch eingerichtet, schließlich soll der Router für die Rechner im LAN immer unter derselben Adresse verfügbar sein. Tatsächlich nutze ich inzwischen für die meisten Rechner bzw. VMs zwar die Adressvergabe per DHCP, die Zuordnung der IPv4-Adressen für die als Server (etwa DNS, Mail, NAS, PV-Wechselrichter etc.) genutzten Systeme erfolgt jedoch anhand deren MAC-Adressen mittels statischer Leases. Die Angabe eines speziellen Gateways für IPv4 ist hier nicht notwendig, da das Default-Gateway für IPv4 genutzt wird, was gleichwohl die IPv4-Adresse der Fritz!Box ist.

Wiederum wird es beim “IPv6 Configuration Type” interessanter. Da die IPv6-Adressen im LAN abhängig sind von der Zuweisung des Prefixes seitens der Fritz!Box an das WAN-Interface, ist hier “Track Interface” anzugeben. Statische IPv6-Adressen kommen aufgrund der Verbindungstrennung mit neuer Adressvergabe nicht in Frage, und DHCPv6 sowie SLAAC würden sich auf weitere Router innerhalb des LANs beziehen, jedoch sind solche genau nicht vorhanden, schließlich soll pfSense diese Aufgabe übernehmen. Und Tunnel-Lösungen waren von vornherein ausgeschlossen, da ich die IPv6-Netze des Providers nutzen wollte. In den “Track IPv6 Interface“-Optionen weiter unten muss somit das bereits konfigurierte WAN-Interface ausgewählt werden. Die “IPv6 Prefix ID” verbleibt einfach in der Default-Einstellung 0, denn zumindest in den Einstellungen der Fritz!Box habe ich keinerlei Eingabemöglichkeit für eine solche ID, während in den meisten Konfigurationshinweisen ebenfalls angegeben wird, dass die 0 die richtige Wahl sei. Korrektur: Wie netterweise im ersten Kommentar angemerkt wurde, dient die IPv6 Prefix ID dazu, das Subnetz zu definieren, das vom Router am LAN-Interface bedient wird.

Nun müssen die Einstellungen nur noch mit “Save” gespeichert und “Apply” aktiviert werden. Daraufhin wird das LAN-Interface neu konfiguriert, dabei werden auch alle abhängigen Dienste neu gestartet, dazu später mehr. Die Ergebnisse können unter “Status” -> “Interfaces” betrachtet werden, wobei dort nur jeweils eine “Link-Local”-IPv6 und IPv6-Adresse angezeigt werden, weshalb ich die direkte Ausgabe des Kommandos “ifconfig” bevorzuge. Diese kann etwa auf der Kommandozeile oder unter “Diagnostics” -> “Command Prompt” durch Eingabe des Kommandos “ifconfig” bei “Execute Shell Command” angezeigt werden:

Sollte an dieser Stelle beim LAN-Interface keine IPv6-Adresse angezeigt werden, deren Prefix mit dem vom WAN-Interface übereinstimmt, gab es irgendwo in der Konfiguration einen Fehler.

Oft handelt es sich dabei um ein Problem mit der Prefix-Länge, die von der Fritz!Box weitergegeben wird. Ein wenig Ausprobieren kann dabei helfen, siehe in den Erläuterungen weiter oben. Ebenfalls sollte in der WAN-Konfiguration die Option “Send IPv6 prefix hint” gesetzt sein, zumindest bei den meisten Prefix-Längen. Tatsächlich waren die Ergebnisse hier ein wenig uneinheitlich. Wurde die Delegation Size 57 angefordert, aber ohne den Prefix Hint zu setzen, erhielt das LAN keine IPv6-Adresse. Wurde eine Delegation Size 64 angefordert und kein Hint gesendet, erhielt das LAN-Interface zwar eine IPv6-Adresse, aber mit dem Hinweis “prefixlen 62“.

DHCPv6 und Router Advertisements

Nachdem nun WAN- als auch LAN-Schnittstelle IPv6-Adressen bzw. -Netze erhalten haben, müssen nur noch die Rechner im lokalen Netzwerk davon erfahren, um ihrerseits IPv6-Adressen zu erhalten. Dies passiert mit DHCPv6 und/oder Router Advertisements, beides wird konfiguriert im Bereich “Services” -> “DHCPv6 Server & RA“. Zur Frage, was davon genutzt werden sollte, meint eine bekannte KI Folgendes:

Beide Protokolle, IPv6 Router Advertisement (RA) und Dynamic Host Configuration Protocol Version 6 (DHCPv6), bieten eine Möglichkeit, IPv6-Adressen und -Konfigurationen an Geräte im Netzwerk zu verteilen. Es gibt jedoch einige Unterschiede und Gemeinsamkeiten zwischen diesen Protokollen.

IPv6 RA ist ein unidirektionales Protokoll, das von Routern verwendet wird, um Geräten im Netzwerk Konfigurationsinformationen und IPv6-Adressen bereitzustellen. RA funktioniert, indem der Router periodisch “Router Advertisements” an Geräte im Netzwerk sendet, um ihnen zu sagen, wie sie sich konfigurieren sollen. Geräte können ihre IPv6-Adresse durch die Verwendung von Stateless Address Autoconfiguration (SLAAC) oder DHCPv6 konfigurieren.

DHCPv6 hingegen ist ein bidirektionales Protokoll, das von einem DHCPv6-Server verwendet wird, um IPv6-Adressen und Konfigurationsinformationen an Clients im Netzwerk zu verteilen. Im Gegensatz zu RA bietet DHCPv6 mehr Flexibilität und Kontrolle über die Adressvergabe und Konfiguration, einschließlich der Zuweisung spezifischer IPv6-Adressen und der Bereitstellung zusätzlicher Konfigurationsinformationen wie DNS-Servern oder NTP-Servern.

Die Wahl zwischen RA und DHCPv6 hängt von den Anforderungen des Netzwerks ab. Wenn eine einfache, automatisierte Konfiguration ohne zusätzliche Konfigurationsinformationen gewünscht wird, kann RA mit Stateless Address Autoconfiguration (SLAAC) eine gute Option sein. Wenn jedoch mehr Kontrolle und Flexibilität über die Adressvergabe und Konfiguration benötigt werden, ist DHCPv6 die bessere Wahl. Einige Netzwerke verwenden auch eine Kombination von RA und DHCPv6, um eine optimale Konfiguration und Adressvergabe zu erreichen.

(Quelle: ChatGPT, Antwort vom 27.03.2023)

Zwecks Unterstützung aller möglichen und unmöglichen Clients fiel die Entscheidung für den kombinierten Einsatz von DHCPv6 und Router Advertisements leicht. Darüber hinaus sollten einige Rechner im LAN mit quasi statischen IPv6-Adressen ausgestattet werden, so dass diese bis auf den sich ändernden Prefix immer dieselbe Adresse erhalten. Dazu können per DHCPv6, genau wie bei DHCPv4, statische Mappings genutzt werden.

DHCPv6

Zunächst im Überblick die DHCPv6-Konfiguration:

Auch wenn in diesem Formular sehr umfassende Einstellungsmöglichkeiten vorhanden sind, bleiben die meisten Optionen in ihrer Standard-Einstellung. Das Subnetz mit ihrem delegierten Prefix und die Subnetz-Maske lassen sich nicht ändern. Als Range sollen Adressen von :1000 bis :2000 genutzt werden, somit bleiben mehr als ausreichend Adressen für das statische Mapping. Und die Informationen über den oder die DNS-Server sollen ebenfalls per DHCPv6 an die Clients verteilt werden. Das war es auch schon. Im unteren Bereich der Seite können statische Mappings hinzugefügt werden, darauf gehe ich jedoch hier nicht weiter ein.

Router Advertisements

Auch bei den Router Advertisements verbleiben die meisten Optionen in ihrer Standard-Einstellung:

Die wichtigste Option ist der “Router mode“. Schaut man sich ein wenig in anderen Anleitungen und Hinweisen diverser Quellen um, scheint sich hier keine eindeutige Präferenz abzubilden. Bereits mit der Einstellung “Unmanaged” ist SLAAC aktiv, so dass die Prefix-Informationen an die Clients verteilt werden und sich diese eine IPv6-Adresse vergeben können. Unter “Managed” wird hingegen verstanden, dass die gesamte Konfiguration per DHCPv6 erfolgt. Um die unterschiedlichsten Clients zu unterstützen, habe ich mich somit für “Assisted” entschieden, damit sollten sowohl SLAAC als auch DHCPv6 möglich sein. Zumindest im praktischen Betrieb mit Linux-Clients und einem Windows-PC war diese Konfiguration erfolgreich.

Die “Router priority” habe ich auf “High” gesetzt, im Netz soll pfSense einfach die entscheidende Instanz sein. Alle weiteren Optionen sind Standard, einzig ganz unten bei der “DNS Configuration” ist bei “Settings” definiert, dass dieselben Einstellungen wie beim DHCPv6-Server genutzt werden sollen.

Werden nun auch diese Services gespeichert und aktiviert, sollten in kürzester Zeit die Clients ihre IPv6-Adresse bzw. ihr /64-Subnetz erhalten. Somit müsste alles in Butter sein, und pfSense sowie Clients im LAN lebten fortan glücklich und zufrieden in voller Einigkeit mit ihren IPv4- und IPv6-Adressen…

Dynamische Probleme

Naja, beinahe. Wie eingangs erwähnt funktionierte diese Konfiguration wunderbar, doch eben nur bis zu besagter nächtlichen Verbindungstrennung inklusive neuer IPv6-Prefix-Vergabe. Denn obwohl die Bezeichnung “Track Interface” in den IPv6-Einstellungen innerhalb der LAN-Interface-Konfiguration die Vermutung nahe legt, dass eben genau das passiert, also dass die LAN-Schnittstelle den Einstellungen des WAN-Interfaces “folgt” und somit eine Änderung der IPv6-Adresse bzw. des -Prefixes mitbekommen müsste, geschieht genau das nicht. Oder genauer – es passiert nur einmal, zumindest bis der Timeout zuschlägt und für die Aktualisierung der IPv6-Adressen des LAN-Interfaces sorgt, wonach auch die angeschlossenen Clients mit neuen IPv6-Angaben bestückt werden.

Die entscheidende Konfigurationsdatei des Router Advertisements ist dabei unter /var/etc/radvd.conf zu finden, die beispielsweise wie folgt aussieht (IP-Adressen geändert):

# Automatically Generated, do not edit
# Generated for DHCPv6 Server lan
interface re0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvDefaultLifetime 1800;
        AdvLinkMTU 1500;
        AdvDefaultPreference high;
        AdvManagedFlag on;
        AdvOtherConfigFlag on;
        prefix 2a0a:ABCD:XYZ:80::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
                AdvValidLifetime 86400;
                AdvPreferredLifetime 14400;
        };
        route ::/0 {
                AdvRoutePreference high;
                RemoveRoute on;
        };
        RDNSS 2a0a:ABCD:XYZ:80:1000:2000:3000:4000 {
                AdvRDNSSLifetime 1800;
        };
        DNSSL geschke.net  {
                AdvDNSSLLifetime 1800;
        };
};

Zwar wird diese Datei beim Speichern der Angaben des LAN-Interfaces neu erzeugt, aber da das LAN-Interface von der Änderung des Prefixes nach der Verbindungstrennung nichts erfährt, bleiben die Angaben darin zunächst erhalten. Somit verbleiben auch die bisherigen, und folglich nun alten und ungültigen IPv6-Adressen bei den Clients. Diese Adressen werden jedoch nicht mehr geroutet, so dass die Verbindung per IPv6 fortan fehlschlägt.

Wir können auch anders…

Auch nach etlichen Versuchen, Konfigurationsänderungen, Reboots und noch mehr leise bis etwas lauter ausgestoßenen Flüchen ist es mir nicht gelungen, mit den Standard-Mitteln von pfSense bzw. auch OPNsense eine Konfiguration aufzubauen, die die Verbindungstrennung so übersteht, dass die Clients in adäquater Zeit ihre aktualisierte IPv6-Adresse mit neuem Prefix erhalten.

Das wäre jedoch ein recht enttäuschendes Ergebnis nach dieser Odyssee und inzwischen sehr lang geratenen Beschreibung. Außerdem war ich an einem Punkt, an dem Googlen, Lesen, Probieren, Testen usw. keine Besserung versprach, insofern musste eine andere Lösung gefunden werden. Diese werde ich im zweiten Teil dieses Artikels erläutern. Als Preview die Idee in Kurzform: Wenn beim Speichern der LAN-Interface-Einstellungen alle relevanten Dienste neu konfiguriert bzw. neu gestartet werden, müsste es doch auch möglich sein, dies zu automatisieren, nachdem die Verbindungstrennung zu einem neuen IPv6-Prefix geführt hat.

In PHP-Code gegossen findet sich diese Lösung nun bei GitHub: ccw-ipv6. Mehr dazu im nächsten Teil.