OPNsense Forum

International Forums => German - Deutsch => Topic started by: AlexanderB on July 25, 2026, 01:50:35 PM

Title: IPv6 SLAAC als eierlegende Wollmilchsau, oder auch andere Verfahren verwenden?
Post by: AlexanderB on July 25, 2026, 01:50:35 PM
Hallo zusammen,

ich habe aktuell einige kleine und große Probleme bei der vollständigen Umstellung auf IPv6.
Ziel:
Meine lokale Netzwerkarchitektur vollständig auf IPv6 umstellen. (Eventuell hab ich noch den einen oder anderen Teilnehmer, der nur IPv4 spricht, da bleibt IPv4 an)

Meine größten Probleme sind:
1. Ich checke aktuell überhaupt nicht, wie ich die Teilnehmer, die sich per SLAAC eine Adresse holen, mit meinen DNS Server (Technitium) mit einem Domainnamen greifbar mache.
2. Ich checke auch überhaupt nicht, wie ich Übersicht über Netzwerkteilnehmer behalte, die sonst durch DHCP in "dnsmasq dns & dhcp" zu sehen waren und von dort auch statisch gemacht werden konnten. SLAAC bedeutet wohl auch, dass die Privatsphäre der einzelnen Teilnehmer so privat ist, dass der übergeordnete Admin nicht mehr weiß wer in seinem Netzwerk überhaupt vorhanden ist?

Macht es denn keinen Sinn SLAAC für einfach alle Teilnehmer zu verwenden? Sollte ich DHCPv6 verwenden um Übersicht zu behalten, wobei ich auch gelesen habe, dass z.B. Android nur SLAAC kann und sonst nix.
Es muss doch doch bestimmt nicht jeder Host, den ich erreichen will, eine statische Adresse haben? Was ist denn da der Standard?
Wie schreibe ich denn Firewall-Regeln, wenn die IPv6 eine SLAAC ist und ihre Adresse sich regelmäßig ändert?

Das einzige IPv6 was bisher schick funktioniert hat, war die DynDNS Funktion und das Updaten meiner IPv6 WAN-IP bei Hetzner im AAAA Record. Wobei ich ja dann für die Services nicht meine WAN-IP mitteile, sondern die SLAAC-IPv6 des einzelnen Servers (+SRV Record für den Port? (Wobei Browser ja SRV nicht richtig lesen können)

Soweit verstanden kann ich im Grunde die globale IPv6 des Dienstes direkt routen, ohne Proxy und ähnliches, was noch bei IPv4 notwendig war.
Mein nächstes Problem ist dann sicher, wenn ein Server (Eine IPv6), mehr als nur einen Dienst (mehr als einen Port) im Internet verfügbar haben soll.

Ich sitze hier schon gut ein paar Wochen und ich komme so ewig langsam voran.

Gibt es für meine aktuellen Probleme die richtigen standardisierten Lösungen? Oder gibt es da nur Meinungen wie man es machen könnte mit dann in Zukunft auftretenden Problemen?

Aktuell bin ich mit einem Netzwerk (Schnittstelle VLAN-Gerät) bereits voll auf IPv6, aber jetzt hab ich das Problem, dass ich von dort nicht auf die Teilnehmer eines anderen Netzwerkes mehr zugreifen kann, die noch in IPv4 hängen und irgendwie nicht selbstständig sich auf IPv6 umstellen (Auch wenn diese Teilnehmer bereits sich eine SLAAC IPv6 generiert haben und ich ihnen die IPv4 Verbindung getrennt habe).

Vielleicht weiß hier ja jemand mehr.

Vielen Dank schonmal und ein schönes Wochenende!
Title: Re: IPv6 SLAAC als eierlegende Wollmilchsau, oder auch andere Verfahren verwenden?
Post by: meyergru on July 25, 2026, 02:48:45 PM
Es kommt sehr darauf an, wozu Du IPv6 tatsächlich nutzen willst. Sicher, man kann sich als Ziel setzen "IPv6-only" (oder -mostly) - nur: warum?

Das erste Problem bei den meisten Providern ist, dass die zugewiesenen GUAs einen dynamischen Präfix haben. Man kann natürlich für einzelne Clients DynDNS machen, das kann sogar die OpnSense stellvertretend tun. Nur: Willst Du das für alle Clients pflegen, nur damit sie im LAN adressierbar sind? Wohl eher nicht.

Ein oft vorgeschlagener Ausweg ist, dass man für die interne Adressierung ULAs zusätzlich verwendet. Das wirft aber das Problem auf, dass diese bei DNS-Auflösung niedriger priorisiert werden als IPv4-Adressen, also gar nicht wirklich genutzt werden, solange man DualStack verwendet, was oft notwendig ist.

Wenn Du die Clients in Logs anhand ihrer IPv6 identifizieren willst, gibt es auch diverse Probleme, denn die niedrigen 64 Bits können zwar, müssen aber nicht aus der MAC abgeleitet werden - es kann auch eine zufällige DUID sein (z.B. Windows) und die kann auch wechseln (mal ganz abgesehen davon, dass manche Clients sogar die MAC anonymisieren (z.B. iOS). Außerdem gibt es noch IPv6 privacy extensions.

DHCPv6 hilft gegen all das nur sehr bedingt - zudem Android es beispielsweise gar nicht unterstützt.

Ich verwende für interne Adressierung IPv4 und sorge dafür, dass IPv6-fähige Clients ausgehende Verbindungen auch per IPv6 nutzen können. Für den Zugriff von außen nach innen kann man mit Dynamischen Host-Aliasen und DynDNS den Zugriff erlauben oder einen Reverse Proxy einsetzen. Ist alles hier (https://forum.opnsense.org/index.php?topic=45822.0) beschrieben.
Title: Re: IPv6 SLAAC als eierlegende Wollmilchsau, oder auch andere Verfahren verwenden?
Post by: AlexanderB on July 25, 2026, 03:11:11 PM
Vielen Dank für die schnelle Antwort.

Ich bin auf den Zwang zur IPv6 aufmerksam geworden, als das Problem von CG-NAT aufkam und DynDNS mir da nicht weiter half. Und da ich jemand bin, der gerne die Dinge gleich richtig macht, dachte ich, ich mach das jetzt alles gleich mit IPv6 richtig. Weil, warum IPv4 und IPv6 pflegen, wenn IPv6 IPv4 ablösen soll.

Ja genau, MAC-Adressen die sich ändern und Interface Identifier (Geräte/Suffixe) die sich ändern und dann noch der prefix der sich ändert, macht die ganze Sache etwas aufwendiger. Und im Grunde muss es ja dafür Lösungen geben, sonst haben die ja was eingeführt, was unbeherrschbar ist. Das einzige was bei mir aktuell statisch ist, ist die Subnetz-ID.

Der dynamische Präfix sollte nicht das Problem sein, denn wie schon geschrieben, da läuft der DynDNS Dienst ja schon zuverlässig.

Die Frage wäre, warum ULA, wenn die GUA im Grunde ausreichend ist? Oder ist die GUA doch nicht ausreichend? Ich hab ja in jedem Fall noch die Link-Lokal-Adresse, wenn ich lokal auf etwas zugreifen will. Und wenn alles nicht funktioniert, könnte ich die LLA ja routen. Aber das ist doch nicht der Sinn der Sache, oder?
Title: Re: IPv6 SLAAC als eierlegende Wollmilchsau, oder auch andere Verfahren verwenden?
Post by: meyergru on July 25, 2026, 03:32:05 PM
Lies mal den Artikel.

Link-Local kannst Du vergessen, weil Du dazu sogar das Interface angeben musst (z.B. ping "fe80::xxxxx%eth0", etwas anderes funktioniert nicht), außerdem: die können nicht geroutet werden, funktionieren also nicht über VLAN-Grenzen hinweg.

Mit ULA hast Du lokal das IPv6-Äquivalent für RFC1918 bei IPv4 - allerdings nur, wenn es NUR IPv6 im lokalen DNS gibt. Außerdem: Wie regelst Du Verkehr zu IPv4-only Clients (ich habe noch einige)? An Dualstack führt also wenig vorbei.

Title: Re: IPv6 SLAAC als eierlegende Wollmilchsau, oder auch andere Verfahren verwenden?
Post by: Patrick M. Hausen on July 25, 2026, 04:07:34 PM
Kurzfassung: alles, was ein "Client" ist, wechselt die Adressen munter durch und braucht ja auch keinen DNS-Eintrag. Alles, was ein "Server" oder "Dienst" ist, und im DNS stehen soll, konfiguriert man statisch. Oder halt per SLAAC, Server würfeln die Adressen nicht.

Firewall-Regeln auf IP-Adress-Basis für "Clients" macht man nicht. Alles mit identischem Vertrauens-Niveau ins selbe VLAN, gleiche Regeln für alle.

Das Problem das du mit der Kombination von SLAAC und DynDNS hast, ist, dass sich die Entwickler von IPv6 nicht vorstellen konnten, dass ISPs so bekloppt sein würden, "dynamische Prefixe" zu vergeben. Das ganze Konzept ist, endlich wieder eine eindeutige Adresse für jedes Gerät zu haben. 🤷
Title: Re: IPv6 SLAAC als eierlegende Wollmilchsau, oder auch andere Verfahren verwenden?
Post by: meyergru on July 25, 2026, 04:26:57 PM
Ja, aber dem ursprünglichen Konzept widersprachen dann zwei Dinge (in absteigender Wichtigkeit für diejenigen, die es hätten umsetzen müssen):

1. Die ISPs möchten zur Monetarisierung von Business-Anschlüssen keine festen IPs jedweder Art beim Privatanschluss, weil damit ja Dienste bereitgestellt werden können und da möchten sie auch extra abkassieren.

2. Schmackhaft machen können sie es dem geneigten Privatkunden damit, dass wechselnde Präfixe ja die Anonymität erhöhen, damit die bösen Internet-Riesen keine Benutzerprofile anlegen können.

Ergo: Wechselnde Präfixe. Die selben Gründe sorgen übrigens auch dafür, dass CG-NAT für die ISPs gar kein echtes Problem ist, sondern eher eine brauchbare Lösung darstellt. Bei manchen ISPs bekommt man eine routebare IPv4 ja nicht mal gegen Einwurf von Scheinen.