Hey Zusammen,
ich habe einen Glasfaseranschluss bei der Telekom und nutze IPv6. Bei den WAN Einstellungen habe ich folgendes: wan.png
Ich habe noch die MTU angepasst etc. und bisher läuft alles. Ich habe noch als Fallback einen IPv4 DHCP und dort ist auch mein AdGuard als DNS Server eingetragen. Leider kriege ich es nicht hin, diesen auch bei den IPv6 zu konfigurieren, sodass meine Clients diese nicht nutzen.
Wie kriege ich das hin?
Danke für die Hilfe :-)
Moin,
schaue mal hier (https://docs.opnsense.org/manual/radvd.html) rein. In IPv6 werden DNS Server entweder auch über dhcpv6 oder bei slaac über routing advertisements verteilt. Die wan Konfiguration ist übrigens relativ egal, wichtig ist wie es auf den internen Schnittstellen konfiguriert ist
Alternativ, solltest Du dnsmasq für dhcpv6 konfiguriert haben, must Du in der Konfiguration von dnsmasq ra einschalten, in den Optionen von dnsmasq eine DHCPv6 Option dns-server mit der IP Adresse des adguard Servers eintragen und in den Services radvd deaktivieren....
Gruß
Danke für den Hinweis. Habe die Einstellung gefunden. Der DNS Server ist in einem anderen Netz/Interface, wo auch meine anderen Server über IPv4 zu erreichen sind. Beim RA muss ich natürlich eine IPv6 Adresse angeben. Jetzt muss ich schauen, was die beste Lösung ist. Aktuell fallen mir drei Optionen ein:
1. AdGuard im ADMIN Netzwerk zur IPv4 auch eine IPv6 vergeben
2. AdGuard ins LAN Netzwerk verschieben
3. ADMIN Netzwerk auf IPv6 umstellen
Die Liste ist priorisiert und ich muss mal schauen, wie ich AdGuard im IPv4 ADMIN Netz eine zusätzliche IPv6 Adresse geben, damit ich diese dann im RA eintragen kann. Meine Annahme ist, dass ich dem Server manuell eine IPv6 konfiguriere, entsprechende Regeln in der FW konfigurieren muss und dann sollte es gehen. Werde mich dem mal morgen annehmen.
Quote from: n3 on January 10, 2026, 11:59:33 PM1. AdGuard im ADMIN Netzwerk zur IPv4 auch eine IPv6 vergeben
Meine Annahme ist, dass ich dem Server manuell eine IPv6 konfiguriere, entsprechende Regeln in der FW konfigurieren muss und dann sollte es gehen. Werde mich dem mal morgen annehmen.
Hängt davon ab wie die IPv6 Adresse des Admin Netz Interfaces der Opnsense vergeben wurde... Manuell oder per Track Interface... eine feste IP kannst Du bei adguard aber nur über das darunter liegende System vergeben
Zwei Hinweise:
1. Nicht alle Geräte akzeptieren die Angabe des DNS-Servers per SLAAC, manche brauchen DHCPv6 dazu. Das ist der Grund, weshalb der RA-Mode "Assisted" existiert - dabei wird die IPv6 per SLAAC und nur der DNS-Server per DHCPv6 übergeben.
2. Eigentlich braucht es bei Dual-Stack den IPv6-DNS-Server nicht - es ist sogar eher schädlich, denn jeder DNS-Server kann auch IPv6 auflösen (also reicht der IPv4-Server) und welcher priorisiert wird, falls beide angegeben wurden, ist nicht definiert.
Ergo: In meinem Guide empfehle ich deshalb, gar keinen DNS-Server per IPv6 zu verteilen, also RA-Mode "Unmanaged" (oder wie auch immer das beim verwendeten RA-Daemon heißt) siehe: https://forum.opnsense.org/index.php?topic=45822.0, Note 6.
Quote from: s.meier68 on January 11, 2026, 08:59:01 AMHängt davon ab wie die IPv6 Adresse des Admin Netz Interfaces der Opnsense vergeben wurde... Manuell oder per Track Interface... eine feste IP kannst Du bei adguard aber nur über das darunter liegende System vergeben
Das ADMIN Netz hat nur IPv4. Sprich mein gesamtes Netzwerk ist eigentlich IPv4 via DHCP und die Clients aus dem LAN-Netz habe ich auf IPv6 umgestellt. Ich würde entsprechend dem AdGuard Server manuell eine IPv6 Adresse vergeben. Diese könnte ich dann im RA als DNS Server angeben und das ganze als "Assisted", richtig?
Quote from: meyergru on January 11, 2026, 09:26:18 AM1. Nicht alle Geräte akzeptieren die Angabe des DNS-Servers per SLAAC, manche brauchen DHCPv6 dazu. Das ist der Grund, weshalb der RA-Mode "Assisted" existiert - dabei wird die IPv6 per SLAAC und nur der DNS-Server per DHCPv6 übergeben.
Danke für den Hinweis. Was spricht gegen dieses Vorgehen?
Quote from: meyergru on January 11, 2026, 09:26:18 AM2. Eigentlich braucht es bei Dual-Stack den IPv6-DNS-Server nicht - es ist sogar eher schädlich, denn jeder DNS-Server kann auch IPv6 auflösen (also reicht der IPv4-Server) und welcher priorisiert wird, falls beide angegeben wurden, ist nicht definiert.
Ergo: In meinem Guide empfehle ich deshalb, gar keinen DNS-Server per IPv6 zu verteilen, also RA-Mode "Unmanaged" (oder wie auch immer das beim verwendeten RA-Daemon heißt) siehe: https://forum.opnsense.org/index.php?topic=45822.0, Note 6.
Gilt das auch für AdGuard? Ich möchte das meine Clients alle über AdGuard laufen und aktuell verteile ich keinen DNS-Server über IPv6 und daher greift mein AdGuard nicht.
Wenn deine Clients dual stack sind, können sie AdGuard über IPv4 nutzen. Sind sie IPv6 only, dann brauchen sie natürlich einen IPv6-DNS-Server.
Patrick liegt richtig...
Zu 1:
Ich schrieb das, weil hier empfohlen wurde, den DNS-Server über SLAAC zu verteilen. Wie gesagt, das wirkt nicht immer, weil manche Clients das nicht übernehmen und DHCPv6 dazu benötigen.
Zu 2.
Ich kenne AdGuard nicht, aber theoretisch kann jeder DNS-Server (ob selbst per IPv6 oder IPv4 betrieben) sowohl IPv4 als auch IPv6 auflösen. Du musst hier streng unterscheiden zwischen dem Protokoll, mit dem Du den DNS-Server ansprichst und den Adressen, die er Dir zurückliefern kann.
Angeblich kann Adguard schon lange IPv6: https://adguard.com/en/blog/dns-ipv6-support.html
Wenn Du also per DHCPv4 bereits den Adguard-Server an die Clients annoncierst, wozu brauchst Du dann einen zweiten Server per IPv6? Vor allem: Wenn das unterschiedliche Server wären, ist undefiniert, welches Ergebnis ggf. genutzt würde.
Zusammengefasst:
Wenn man Dual Stack nutzt und somit sowieso (irgend) einen IPv4-DNS-Server per DHCPv4 anbietet, würde ich überhaupt keinen IPv6-DNS-Server verteilen, weder über SLAAC, noch über DHCPv6. Und dann braucht man auch weder DNSv6 noch DHCPv6, sondern nur SLAAC für IPv6, was garantiert mit jedem Client funktioniert, wenn er denn überhaupt IPv6 kann. So steht es auch im HOWTO.
Einen DNS-Server per IPv6 zu annoncieren, brächte nur etwas, wenn man IPv6-only hätte und dann bräuchte man eben den "Assisted" Mode für komplette Abdeckung. Inwieweit IPv6-only aber überhaupt Sinn macht, soll jeder selbst bewerten - ich halte nichts davon, weil man dann für IPv4-only Services im Internet (und davon gibt es reichlich, beispielsweise github.com) wieder irgendwelche IPv6-to-IPv4 Brückenlösungen benötigt.
Ich bin ein Fan von Ockhams Rasiermesser...
Quote from: Patrick M. Hausen on January 11, 2026, 02:05:59 PMWenn deine Clients dual stack sind, können sie AdGuard über IPv4 nutzen. Sind sie IPv6 only, dann brauchen sie natürlich einen IPv6-DNS-Server.
Vielleicht liege ich ja falsch. Ich gehe davon aus, dass meine Clients im Dual-Stack, denn im LAN-Netz wo sich die Clients befinden läuft ein IPv4 DHCP und sie kriegen auch eine IPv6. Auf meinem Rechner hier zeigt ipconfig folgendes
ipconfig.png
Der der Client eine IPv6 hat, nutzt er diese und geht damit direkt ins Netz am AdGuard vorbei. Erst wenn IPv6 nicht geht, springt er auf IPv4 und nutzt dann den DNS. Das Problem ist also, dass immer wenn IPv6 geht, der AdGuard nicht genutzt wird. Also fast immer.
Oder verstehe ich etwas falsch?
Ja, so ist es. Du zeigst in Deinen Screendumps ja gar nicht, welchen DNS-Server Du verwendest. Ruf mal "ipconfig /all" auf, dann sieht Du es.
Dort sollte, wenn es nur einen per DHCPv4 verteilten Server gibt, auch nur eine IPv4 dafür geben.
Wenn dein Client nur genau einen IPv4-DNS-Server kennt, benutzt er auch nur den. Dann sorg dafür, dass das dein AGH ist und das Problem ist gelöst. Habe ich hier überall genau so am laufen.
Spätestens wenn man IPv6-Only Preferred aktiviert ist der Ansatz, DNS nur über IPv4 abzuwickeln auch in Dual Stack-Netzen hinfällig. Und ich habe den Eindruck, dass das gerade Fahrt aufnimmt. MikroTik hat es seit ein paar Tagen in der Beta. [Verwechslung] Freifunk rollt es hier in KA gerade großflächig öffentlich aus. Man hat dann immer noch IPv4 für Geräte, die darauf angewiesen sind, viele Clients (z. B. Android) verwenden nun aber ausschließlich IPv6 - auch für DNS.
Bei Anschlüssen mit dynamischem Präfix hat es sich bewährt, auf den LAN-Interfaces zusätzlich Virtual IPs (IP Alias) mit ULAs zu konfigurieren. So bekommt jedes Gerät automatisch auch eine ULA (über SLAAC). Die ULA des DNS-Servers kann man dann über RAs und DHCPv6 verteilen.
@meyergru Der RA-Mode "Assisted" ist für den Fall, dass zusätzlich zu SLAAC auch per DHCPv6 Adressen verteilt werden. Was Du meinst ist "Stateless", dabei werden über DHCPv6 nur Optionen wie DNS verbreitet, aber keine Adressen vergeben.
Grüße
Maurice
Quote from: Maurice on January 11, 2026, 04:15:38 PMviele Clients (z. B. Android) verwenden nun aber ausschließlich IPv6 - auch für DNS.
Wie denn, wenn es keinen lokalen Server auf IPv6 gibt und man DNS ausgehend sperrt? Was man natürlich tun sollte, wenn man OPNsense, AGH etc. am Start hat, um zu filtern.
Stimmt, ich meinte Stateless.
Wie geht denn "IPv6-only preferred"? Sowie ich DS habe, weil einige Clients es brauchen, muss ich doch zwangsläufig DHCPv4 machen und auch einen DNSv4 haben - das würde aber von allen Clients genutzt, oder? Die IPv4-only Clients können dann aber die IPv6-only Services / Geräte nicht nutzen, richtig?
Anders gesagt: Mal mal ein Bild, wie sich das genau zusammensetzt. Ich verstehe ja noch IPv6-only, wobei mich daran schon stört, dass ich:
a. Eine Bridge-Technologie für den externen IPv4-Zugang (z.B. github) brauche und
b. bei dynamischen IPv6-Präfixen zusätzlich noch ULAs für den internen Netzwerktraffic benötige (wobei die dann niedriger priorisiert sind als GUAs, ich also sehr aufpassen muss, dass NUR die ULAs im internen DNS auftauchen).
Das wäre dann schlicht eine Fehlkonfiguration. Wenn man IPv6-Only Preferred verwendet (also die entsprechende Option im DHCPv4-Server konfiguriert), dann muss sichergestellt sein, dass ein DNS-Server über IPv6 erreichbar ist und über RAs und ggfs. DHCPv6 bekannt gegeben wird. Das ist nicht anders als in einem "echten" IPv6-only-Netz. Ist das nicht der Fall, dann haben Clients, die IPv6-Only Preferred unterstützen kein DNS.
@meyergru Das ist jetzt vielleicht nicht der richtige Ort, um IPv6-Only Preferred im Detail zu erläutern; ist auch umfassend dokumentiert.
Kurzform: Dual Stack-Netz mit zusätzlich DNS64 und NAT64. Der DHCPv4-Server teilt den Clients mit, dass in diesem Netz IPv6-only bevorzugt wird. Clients, die das unterstützen brechen DHCPv4 dann ab und verwenden ausschließlich IPv6. Clients, die das nicht unterstützen verwenden ganz klassisch IPv4.
Quote from: Maurice on January 11, 2026, 04:32:41 PMWenn man IPv6-Only Preferred verwendet (also die entsprechende Option im DHCPv4-Server konfiguriert
Jetzt verstehe ich was du meinst. Ein designiertes "IPv6 mostly" Netzwerk. [1]
Aber das habe ich halt nicht. Und auch meine Empfehlung dem OP gegenüber basiert auf der Annahme, dass man DHCPv4 und SLAAC im betrachteten Netz vollständig kontrolliert und dann ist dual stack einfach gut nachvollziehbar und bequem.
[1] https://www.ietf.org/archive/id/draft-link-v6ops-6mops-01.html
@Patrick Ja richtig, das meinte ich. Und stimmt, IPv6-Only Preferred ist nur der Name der DHCPv4-Option, was natürlich nur ein Baustein des ganzen ist. Sorry für die Konfusion.
Auch wenn man das jetzt noch nicht hat, dann ist es doch nur eine Frage der Zeit. Falls man nicht direkt auf IPv6-only mit DNS64 / NAT64 geht. Wieso es dann nicht gleich richtig machen und DNS auch über IPv6 ermöglichen?
Wir wollen doch nicht die nächsten 20 Jahre weiterhin klassisches Dual Stack fahren.
Das mit dem klassischen Dual-Stack sehe ich auch noch so wie Patrick.
Darüber hinaus haben meine Experimente mit der DHCP option 108 (RFC 8925 (https://www.rfc-editor.org/rfc/rfc8925.html)) mit Kea zumindest bei Windows 11 (noch) und bei Ubuntu 24.04.3 nicht funktioniert. Die Client-PCs holen sich immer (auch) eine IPv4.
Wenn das besser unterstützt würde, könnte man drüber nachdenken. Allerdings muss man dann im internen DNS beide Varianten (IPv4/6) pflegen, damit alle Clients die Services finden - also Mehraufwand.
Das zeichnet IPv6-Mostly ja aus (jetzt verwende ich den richtigen Namen): Es funktionieren alle Clients, auch die, die die DHCPv4-Option noch nicht unterstützen oder noch kein CLAT haben (Windows) und sogar die, die gar kein IPv6 unterstützen. Man muss daher mit dem Rollout nicht warten, bis alle Clients IPv6-only unterstützen.
In der internen DNS-Zone benötigt man natürlich A- und AAAA-Records, das ist nicht anders als im öffentlichen DNS.
Oha. Da kommt aber (theoretisch) viel Arbeit auf einen zu, wenn man dem internen DNS die IPv6 (und zwar aus den genannten pragmatischen Gründen ULAs) hinzufügen will:
a. Wie ich gerade feststelle, wird die IPv6 bei Windows aus einer (zufälligen) DUID abgeleitet. Das bedeutet, ich kann die ULA nicht einmal aus den vorhandenen MAC-Daten für die DHCPv4-Reservierungen ableiten. Es sei denn, ich ändere auf den Windows-Clients per Registry-Setting die Einstellungen so, dass die Ableitung aus der MAC erfolgt, so dass man zumindest die EUI-64 vorab zentral kennt. Das könnte im Extremfall bedeuten, dass ich die DNSv6-Einträge alle nochmal händisch erfassen muss, nachdem ich auf jedem Client die tatsächliche ULA ausgelesen habe. Keine Ahnung, wie Android das macht, aber IOS nimmt m.W. auch eine zufällige EUI-64, wenn man es nicht abschaltet (und das nicht nur für ausgehende Verbindungen mit privacy extensions).
b. Automatisiert kann man die Einträge sowieso nicht so einfach erzeugen, weil man für Nicht-IPv6-fähige Geräte und Services keine DNSv6-Einträge machen will - sonst würden die IPv6-only Clients auf Fehler laufen, weil sie ja dann bevorzugt IPv6 versuchen würden. Wobei: das gälte nur für GUAs, siehe nächster Punkt.
c. Bei ULAs ist es so, dass die ja überraschenderweise niedriger priorisiert werden als IPv4. Wenn also beide Einträge existieren, bringt das rein gar nichts, denn die IPv4 wird der ULA IPv6 immer vorgezogen. IPv4-only Clients nehmen sowieso nur IPv4, und solange diese noch existieren, werden die IPv4-DNS-Einträge auch noch gebraucht - es wäre nicht einmal eine Option, die Einträge exklusiv nur für IPv4 oder IPv6 zu machen.
d. Differenzieren müsste man für echte Services sowieso, denn wenn die per DHCP-Option 108 IPv6-only gesetzt werden, sind sie für IPv4-only Clients nicht mehr erreichbar. M.W. unterstützt Kea DHCP auf OpnSense eine Client-spezifische Steuerung der Option 108 nicht - solche Services müssten also statisch auf Dual-Stack konfiguriert werden.
Ergo: Alle Clients nutzen sowieso nur den IPv4-Teil des DNS-Eintrags. Dann kann ich mir die lokalen IPv6-Einträge im DNS also gleich sparen.
Offenbar wird das also nix bei mir mit "IPv6-mostly" - m.E. klappt das erst gut mit "IPv6 only".
Sorry für Off-Topic, aber wie gesagt, ich versuche nur gerade, das Big Picture zu erfassen (die klassische Version mit internem IPv4 kenne ich).
Wenn Du in einer Windows-Domäne lebst, werden die Clients authentifiziert DNS-Updates an die Domänen-Controller schicken. Ich nehme fest an, das schließt heutzutage auch IPv6 ein.
Kea unterstützt DDNS-Updates ebenfalls für beide Protokolle, wobei ich noch nicht recherchiert habe, ob RFC 2137 auch AAAA Records einschließt, Kea für IPv6 was eigenes macht, oder es einen Nachfolger/Ergänzung für RFC 2137 gibt ...
Spannendes Thema. :-)
Quote from: meyergru on January 11, 2026, 02:29:47 PMJa, so ist es. Du zeigst in Deinen Screendumps ja gar nicht, welchen DNS-Server Du verwendest. Ruf mal "ipconfig /all" auf, dann sieht Du es.
Dort sollte, wenn es nur einen per DHCPv4 verteilten Server gibt, auch nur eine IPv4 dafür geben.
OK, habs eben geprüft und als DNS ist einmal die IPv4 vom ADG und einmal die IPv6 vom LAN-Interface (also die IPv6 die ich im Dashboard der opnsense auch unter dem LAN-Interface sehe)
Quote from: Patrick M. Hausen on January 11, 2026, 02:36:07 PMWenn dein Client nur genau einen IPv4-DNS-Server kennt, benutzt er auch nur den. Dann sorg dafür, dass das dein AGH ist und das Problem ist gelöst. Habe ich hier überall genau so am laufen.
Ja mit IPv4 war das auch so und lief ohne Problem. Da meine Clients nun IPv6 haben, habe ich eben gesehen, dass das LAN Interface als DNS eingetragen ist und somit geht es am ADG vorbei.
Quote from: Maurice on January 11, 2026, 04:15:38 PMBei Anschlüssen mit dynamischem Präfix hat es sich bewährt, auf den LAN-Interfaces zusätzlich Virtual IPs (IP Alias) mit ULAs zu konfigurieren. So bekommt jedes Gerät automatisch auch eine ULA (über SLAAC). Die ULA des DNS-Servers kann man dann über RAs und DHCPv6 verteilen.
Ja ich glaube das geht in die Richtung, wie ich es dachte. Nur wollte ich die IPv6 am Server vergeben. Mit ULAs klingt es sauberer. Verstehe ich das Richtig, dass meine Clients im LAN eine temporäre IPv6 über das WAN bekommen. Diese Adresse ist eher für das Internet gedacht. Lokal nutze ich aktuell IPv4, aber mit ULAs gebe ich den Clients im LAN und im ADMIN Netz lokal IPv6 Adressen zu lokalen Kommunikation. Die ULA vom ADG konfiguriere ich dann als DNS über RAs im Modus Stateless.
Richtig?
Ich versuche eurer Diskussion zu folgen, aber es ist schwer, wenn man das Thema nur privat verfolgt. Ich könnte bei mir auch komplett auf IPv6 sogar mit einer festen IPv6 gehen, aber dann ist das Thema mit Datenschutz im privaten Umfeld so eine Sache.
@n3: Im RADVD (falls Du den nutzt) kannst Du die Option "Do not send any DNS configuration to clients" setzen - wie gesagt, ich nehme nur SLAAC, keinen DHCPv6. Damit kommt dann kein DNSv6-Server mehr an. So auch das oben verlinkte HOWTO. Das funktioniert - alles, was wir hier diskutieren, ist offenbar komplexer als man sich das so zuerst vorstellt. Mir fehlt bislang jedenfalls das HOWTO, das das lückenlos beschreibt.
Und: Die ULA wird bei DS-Betrieb nie verwendet, solange der Name auch auf eine IPv4 auflöst... das würde m.E. nur mit IPv6-only funktionieren, nicht mit IPv6 mostly. Solange Du dynamische IPv6-Präfixe und IPv4-only Clients hast, wird das nix.
@Patrick: Ich nutze weder Windows-Domänen noch DHCPv6. M.W. unterstützen Android-Clients (und manche andere) auch nur SLAAC für die IPv6-Zuweisung - ich weiß allerdings nicht, ob das aktuell immer noch so ist. D.h., aktuell arbeite ich mit einer festen Reservierung MAC -> IPv4. IPv6 wird eigentlich nur für Outbound genutzt, inbound nehme ich sowieso meist einen Reverse Proxy, deshalb brauche ich da die IPv6 selten.
Quote from: n3 on January 11, 2026, 06:36:37 PMund einmal die IPv6 vom LAN-Interface (also die IPv6 die ich im Dashboard der opnsense auch unter dem LAN-Interface sehe)
Aber warum, das solltest Du ja verhindern, in dem Du die Sense entsprechend konfigurierst.
Du kannst natürlich dem AGH auch eine ULA geben, aber auch die müsstest Du dann verteilen und die Sense entsprechend konfigurieren, im Endeffekt nicht einfacher, eher das Gegenteil.
@meyergru
Ich habe dein HowTo damals verwendet und eben die Option im RA aktiviert. Der DNSv6 wird nicht mehr ausgeliefert und es scheint alles über den ADG zu gehen.
Somit sollte es jetzt passen.
Aber damit ich es richtig verstehe... Ich rufe z.B. eine Webseite auf und die Kommunikation läuft eigentlich über IPv6. Dennoch geht mein Client über IPv4 an den ADG da dieser als DNSv4 konfiguriert und bekannt ist und löst auch entsprechend auf. Ich dachte, dass wenn die Kommunikation über IPv6 läuft, der DNS auch über v6 bekannt sein muss.
Quote from: meyergru on January 11, 2026, 06:11:10 PMWie ich gerade feststelle, wird die IPv6 bei Windows aus einer (zufälligen) DUID abgeleitet.
Zufälliger
Interface Identifier, der bei der Installation der NIC generiert wird. DUID ist der Device Identifier für DHCPv6.
Quote from: meyergru on January 11, 2026, 06:11:10 PMDas könnte im Extremfall bedeuten, dass ich die DNSv6-Einträge alle nochmal händisch erfassen muss, nachdem ich auf jedem Client die tatsächliche ULA ausgelesen habe.
Man benötigt doch nicht für jeden Client DNS-Einträge, sondern nur für Dienste, die im lokalen Netzwerk angeboten werden. Möchte man aus grundsätzlichen Überlegungen alle Clients zentral erfassen, dann gibt es dafür bessere Mechanismen, wie das von Patrick genannte AD mit DNS- und DHCPv6-Integration oder eine dedizierte Device Management-Lösung.
Quote from: meyergru on January 11, 2026, 06:11:10 PMBei ULAs ist es so, dass die ja überraschenderweise niedriger priorisiert werden als IPv4.
Kommt auf die konkrete Implementierung an, ist aber zum Teil leider so. Das ist aber nicht in Stein gemeißelt; es gibt neuere RFCs, die das ändern möchten.
A-Records benötigt man nur für Dienste, auf die wirklich noch per IPv4 zugegriffen werden muss. Und möchte man ganz konsequent sein, dann verwendet man kein IPv6-Mostly, sondern separate Single Stack-Netze für IPv6 und IPv4. So habe ich es bei mir im Heimnetz gelöst.
Quote from: meyergru on January 11, 2026, 06:11:10 PMDifferenzieren müsste man für echte Services sowieso, denn wenn die per DHCP-Option 108 IPv6-only gesetzt werden, sind sie für IPv4-only Clients nicht mehr erreichbar.
Server wird man in der Regel statisch konfigurieren. Falls man dafür DHCPv4 verwenden möchte, dann könnte man auf den betroffenen Servern den DHCP-Client so konfigurieren, dass er Option 108 ignoriert.
Quote from: n3 on January 11, 2026, 06:36:37 PMVerstehe ich das Richtig, dass meine Clients im LAN eine temporäre IPv6 über das WAN bekommen. Diese Adresse ist eher für das Internet gedacht. Lokal nutze ich aktuell IPv4, aber mit ULAs gebe ich den Clients im LAN und im ADMIN Netz lokal IPv6 Adressen zu lokalen Kommunikation. Die ULA vom ADG konfiguriere ich dann als DNS über RAs im Modus Stateless.
Ja richtig, bzw. eigentlich im Modus "Unmanaged". Falls Du "Stateless" verwenden möchtest, dann muss zusätzlich noch der DHCPv6-Server entsprechend konfiguriert werden.
Quote from: n3 on January 11, 2026, 06:36:37 PMIch könnte bei mir auch komplett auf IPv6 sogar mit einer festen IPv6 gehen
Falls Du die Möglichkeit hast ein statisches IPv6-Präfix zu bekommen, dann solltest Du das auf jeden Fall tun. Das erspart auch an vielen anderen Stellen Kopfschmerzen.
Quote from: n3 on January 11, 2026, 07:16:12 PMIch dachte, dass wenn die Kommunikation über IPv6 läuft, der DNS auch über v6 bekannt sein muss.
Das ist unabhängig voneinander. Der Client kann einen DNS-Server auch über IPv4 nach einem AAAA-Record fragen. Also Kommunikation zwischen Client und DNS-Server über IPv4 und dann Kommunikation zwischen Client und z. B. Web-Server über IPv6.
Andere Lösungen heißt zumindest bei mir: zusätzliche Lösungen. Ich habe kein Problem damit, die Mechanismen von IPv4 auf IPv6 umzustellen, wenn das aber bedeutet, für alle möglichen Features zusätzliche Mechanismen oder spezifische Geräte-Konfigurationen (Umstellung von DHCP-Verhalten am Server, Registry-Edits auf Windows-Clients, Umstellungen an Android und/oder IOS-Geräten, separate IPv4- / IPv6-Netze) einsetzen zu müssen, bin ich aus Aufwandsgründen raus - für mich persönlich besteht der Ansatz dann den Lackmustest nicht. Mal ganz abgesehen davon, dass zumindest Ubuntu 24.04.3 und Windows 11 Professional die DHCP Option 108 einfach ignorieren.
Das mag in Business-Umgebungen anders sein, wo AD, LDAP, Windows-Domänen, 802.1x oder IPAM sowieso schon am Start sind. Bei mir ist das mit "IPv4 im LAN" und "IPv6 outbound only" aber anders: Da brauche ich - und zwar nur auf der OpnSense - eine einfache Zuordnung MAC -> IPv4 -> DNS-Einträg(e) und kann damit alles erschlagen.
Es wäre wahrscheinlich auch anders, wenn sich die ISPs nicht auf diese blöde dynamische IPv6-Zuweisung eingeschossen hätten oder langfristiger, wenn IPv6-only eine echte Option darstellt.
Quote from: Maurice on January 11, 2026, 07:43:08 PMFalls Du die Möglichkeit hast ein statisches IPv6-Präfix zu bekommen, dann solltest Du das auf jeden Fall tun. Das erspart auch an vielen anderen Stellen Kopfschmerzen.
Im betrieblichen Kontext verstehe ich das, aber im privaten Kontext verlieren ich dann viel an Privatsphäre.
wenn dir deine Privatsphäre wichtig ist, versuche einfach IPv6 over NAT.
läuft bei mir im Dualstack und Dual WAN Poblemlos auch mit DHCv6 ULA und Adguard ULA.
Das wird bei der Verschleierung der IPv6 kaum helfen, wenn die ersten 64 Bits der nach außen sichtbaren IPv6 immer die selben sind.
Trotzdem kaufe ich das Privacy-Argument nicht wirklich, weil die IP schon länger nicht mehr das entscheidende Kriterium ist, beispielsweise eine spezifische Browser-Instanz zu identifizieren, siehe hier (https://ingestlabs.com/mobile-device-id-tracking-guide/) (Mobile Device ID) oder hier (https://amiunique.org/fingerprint) (Browser fingerprinting), von Cookies mal ganz zu schweigen. Schließlich ist die IPv4 ja auch meist volatil.
Ich stimme @Maurice zu, ich hätte trotz Privacy-Erwägungen lieber feste IPs - insbesondere bei IPv6.
Welchen Vorteil siehst du bei einer festen IP?
Du kannst deine internen Interfaces alle statisch konfigurieren, Router Advertisments/SLAAC anknipsen und es wird einfach magisch alles funktionieren ohne weitere Verrenkungen.
Genau so ist IPv6 gedacht. Den Erfindern kam nicht im Traum in den Sinn, dass jemand ein Prefix auf einer Leitung periodisch durchrotieren würde. Es ist einfach komplett blödsinnig.
Wenn man sich die frühe Literatur über IPng wie das damals noch hieß durchliest, dann war ein automatischer Prefixwechsel natürlich geplant. Aber in den Beispielszenarien findet man dann z.B. den Wechsel von Internet-Anbieter A zu Internet-Anbieter B. Man hängt beide Uplink-Router parallel ins Netz, wobei man dem neuen eine niedrigere Priorität gibt. Wenn die ersten Tests gut aussehen, vertauscht man die Prioritäten. Am nächsten Tag schaltet man den alten Router ab. Dazu ist das gedacht ... nicht dazu, dass der ISP dir alle 24h ein neues Prefix rein drückt.
Grüße
Patrick
Richtig.
Beispielsweise kann man mit dynamischen IPv6 nur sehr schwer DNS-Eintragungen machen - dazu braucht es ja bekannte IPs. Meist wird dann empfohlen, für den internen DNS ULAs zu verwenden, was aber wiederum bei Dual Stack nicht funktioniert, weil die IPv4 höher priorisiert werden als ULA IPv6, wie bereits dargestellt.
Die Identifizierbarkeit eines Clients (z.B. in Firewall-Logs) anhand der IPv6 könnte man mittels DHCPv6 auch leicht erreichen. Ist mit dynamischen IPv6 de facto ausgeschlossen, weil die Leases mit DHCPv6 ggf. zu lange gültig wären. Das ist ja der Grund, wieso ich im IPv6 HowTo SLAAC-only vorschlage. Nur geht damit wieder keine DNS-Registrierung und die IPs sind quasi zufällig.
Selbst Firewall-Regeln für IPv6 kann man nur mit zwei Tricks machen: Entweder dynamische IPv6 Aliases, die auf bekannten EUI-64 basieren (was wie bereits diskutiert bei Windows, IOS und Android nur mit speziellen Einstellungen geht, wenn man SLAAC macht) oder, man macht Firewall-Regeln für IPv6 auf Basis der MAC...
Von Docker mit IPv6 und dynamischen Präfixen ganz zu schweigen. Wer mal versucht hat, mit Uptime Kuma eine IPv6 zu überwachen, weiß, was ich meine: geht nur per Proxy.
Alles blöde Ausweichlösungen, um nicht vorhandene statische Präfixe irgendwie zu umschiffen - und funktionieren tut es nur sehr bedingt. Mit statischen IPv6-Präfixen und DHCPv6 wäre das alles kein Problem. Dann rückt - bis auf LAN-Serverdienste (die DS-fähig sein sollten) und eine notwendige Brückenlösung für IPv4 im Internet - sogar IPv6-only im LAN in Reichweite.
Quote from: meyergru on January 12, 2026, 09:53:19 PMweil die IPv4 höher priorisiert werden als ULA IPv6, wie bereits dargestellt.
Das war mir bisher tatsächlich neu, danke dafür!
Quote from: s.meier68 on January 13, 2026, 02:10:20 PMQuote from: meyergru on January 12, 2026, 09:53:19 PMweil die IPv4 höher priorisiert werden als ULA IPv6, wie bereits dargestellt.
Das war mir bisher tatsächlich neu, danke dafür!
Da gehts aber nur um die DNS Auflösung, wenn ein Name IPv6 GUA, IPV4 und IPv6 ULA hat, dann wird der Name in der Priorität aufgelöst bzw. vom Client in der Priorität benutzt.
Ist aber für DNS Infrastruktur kein Problem, DNS Server werden dem Client per IP mitgeteilt, dementsprechend ist IPv6 ULA zumindest dafür eine valide Lösung.
Dafür bräuchte es überhaupt keine ULA, die LL-Adresse würde ja genauso funktionieren, genauso wie für das Gateway. Mal ganz abgesehen davon, dass der DNS-Server genauso gut per IPv4 genutzt / adressiert werden könnte - aber falls sowohl IPv4 als auch IPv6 angegeben werden, ist die Frage, welcher Server dann genutzt wird, undefiniert. All das gilt für Dual-Stack.
ULAs werden normalerweise nicht wegen der Angabe des DNS-Servers, sondern in dem Bestreben genutzt, bei dynamischen IPv6 Präfixen und gewünschtem weitgehenden Verzicht auf (legacy) IPv4 eine DNS-Eintragung vornehmen zu können - weil das mit den (dynamischen) GUAs eben nicht geht. Meine Bemerkung wies lediglich darauf hin, dass genau das bei Dual-Stack trotzdem nicht funktioniert, weil IPv6 ULAs bei gleichzeitiger Verfügbarkeit von IPv4 für DNS-Einträge aufgrund der geringeren Priorisierung gar nicht genutzt werden (viele denken, IPv6 würde "immer" vorgezogen - dem ist nicht so).
Kurz gesagt: Die Verwendung von ULA wird bei dynamischen IPv6-Präfixen immer als "Lösung" angepriesen, funktioniert aber bei Dual-Stack nicht, sondern nur mit IPv6-only.
Sehe ich genauso :) . Ich benutze auch selbst keine ULAs mehr, IPv4 tuts genausogut.
Man sollte für den DNS Server keine link-local Adressen verwenden. Sobald ein Client in mehreren Netzwerken gleichzeitig ist und mehrere link-local Adressen hat, ist das Verhalten nicht definiert. Zu welchem Interface sollen DNS Anfragen gesendet werden? Eine Scope ID wird ja nicht mitgegeben in der DHCPv6 oder RDNSS option.
Das stimmt so nicht:
Die Scope ID wird beim Gateway auch nicht mitgegeben - geht ja auch nicht, weil der SLAAC- oder DHCP-Server die Scope ID des Clients ja nicht kennt. Der Client erzeugt sich die selbst anhand des Interfaces, wo er die Angabe herbekommt. Gerade eben probiert mit RADVD und "fe80::1" als DNS-Server. Ergebnis unter Windows:
2026-01-13 16_15_23-mRemoteNG - confCons.xml - baremetal.png
Dann ist wohl nur die Frage ob alle Clients so schlau sind wie Windows.
Linux (Ubuntu 24.04.3 mit systemd-resolvectl) ja:
#resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 192.168.10.2
DNS Servers: 192.168.10.2
DNS Domain: xxx yyy zzz
Link 2 (eth0)
Current Scopes: DNS
Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.10.2
DNS Servers: 192.168.10.2 fe80::1
DNS Domain: xxx yyy zzz
Bei iOS und Android ergibt sich die Frage praktisch nicht - mit wie vielen WLANs will man gleichzeitig verbunden sein? In meinem iPhone habe ich keine Scope-ID gesehen, für das Gateway allerdings auch nicht.
Klingt nach viel Theorie....
Die Praxis sieht so aus:
ich habe Vlans und dual Stack, verteile per DHCP/Assestiert +RA UlA's mit Statischen Adguard DNS ip4 und 6.
und nutze IP6 over NAT.
Sehe überhaupt keinerlei Probleme weder mit DNS Prio oder irgenwelchen Zugriffen, es wird IP6 fleissig von Clients Verwendet und auch Portweiterleitung/Redirect zu ULA ist Problemlos.
Aber Aufgrung des tieferens einsteigens in die thematik IP6 würde ich NIEMALS GUA Lokal verwenden und trotz der Privacy extensions nach Draussen Strippen.
Quote from: Zapad on January 13, 2026, 04:46:40 PMAber Aufgrung des tieferens einsteigens in die thematik IP6 würde ich NIEMALS GUA Lokal verwenden und trotz der Privacy extensions nach Draussen Strippen.
Wieso?
Ich habe mal etwas weitere recherchiert und bin u.a. auf diesen Artikel gestoßen: https://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html
Dort wird ja auch mehr oder weniger von NAT abgeraten. Ich tendiere nun doch zu einem festen IPv6-Anschluss, da ich in meinem Homelab mehrere Netze segmentiere und Services wie Nextcloud oder HomeAssistant kontrolliert von außen erreichbar machen kann. Eine feste IPv6 gibt mir stabile Prefixe und vereinfacht Firewall-Regeln, Routing und Betrieb, was für meinen privaten Einsatz von Vorteil ist. Will wenig Maintenance.
Intern würde ich Services und Außengeräte ausschließlich über ULA adressieren und sie nicht direkt global erreichbar machen. Nur ein Reverse Proxy hätte eine globale IPv6 und terminiert TLS für alle öffentlichen Dienste. Somit kann ich die Services nicht zufällig exposen.
DAs Client-Netzwerk nutzen IPv6 für ausgehende Verbindungen. Da Android keine IPv6 Privacy Extensions unterstützt, würde ich für mobile Clients bei Bedarf VPN einsetzen, um Tracking und direkten Internetzugriff zu vermeiden.
Klingt doch sinnvoll, oder?
Ja. Dann brauchst Du aber auch keine ULA - Du würdest ja nur die IPv6 der OpnSense erreichbar machen und den Rest per Reverse-Proxy oder bei sehr speziellen Anwendungen NAT64 in eine DMZ (was sowieso für exponierte Geräte und Services eine gute Übung ist).
Die anderen Geräte können auch intern ruhig GUA benutzen, die Firewall blockt ja den Zugriff von außen (abgesehen davon, dass man die internen GUAs nicht erraten oder scannen kann, selbst, wenn man den Präfix kennt - 2^64 IPs sind ein bisschen zu viel zum Raten).
Für Android-Geräte gibt es m.W. inzwischen auch die Möglichkeit der MAC Randomization und wie gesagt, die IP ist inzwischen nicht mehr das relevante Kriterium zum Erkennen eines spezifischen Geräts.
Quote from: Zapad on January 13, 2026, 04:46:40 PMAber Aufgrung des tieferens einsteigens in die thematik IP6 würde ich NIEMALS GUA Lokal verwenden und trotz der Privacy extensions nach Draussen Strippen.
Dann kann der Einstieg so tief nicht gewesen sein.
Täglich wechselnde Präfixe haben ISPs ersonnen, um statische Präfixe als "Business-Feature" teuer verkaufen zu können. Das Privacy-Argument ist nur vorgeschoben. Wie @meyergru schon sagte sind Cookies, Fingerprinting etc. in dieser Hinsicht viel relevanter als ein statisches IPv6-Präfix.
Quote from: n3 on January 13, 2026, 07:52:08 PMQuote from: Zapad on January 13, 2026, 04:46:40 PMIntern würde ich Services und Außengeräte ausschließlich über ULA adressieren und sie nicht direkt global erreichbar machen. Nur ein Reverse Proxy h
So mache ich das auch, Intern ULA nach draussen NAT.
ich habe nie gesagt das ich am WAN gegen feste IP weäre... wenn es aber
nach ginge würde ich jeden Tag eine andere IP6 haben wollen, aber mein Provider hat mir Quasi feste vergeben.
Quote from: Maurice on January 14, 2026, 02:15:14 AMDann kann der Einstieg so tief nicht gewesen sein.
Tief genug um zu wissen warum IP6 sei 30j schatten dasein führt.
Werden die Private Extensions etwa über Zufallsgeneratoren generiert? die ja bekannte massen bug habe und berechenbar sind?
Es würde mich nicht wundern.
Alle sprechen über "kein NAT bei IP6" aber keiner hat je Probleme damit beschrieben.... es gibt in der Paxis nähmlich keine die man merkt/sieht....
Vorteile mein internes Netzwerk bleibt konsistent und kein Provider(wechsel) wurschtelt da rum.
Quote from: bimbar on January 13, 2026, 02:16:39 PMDa gehts aber nur um die DNS Auflösung, wenn ein Name IPv6 GUA, IPV4 und IPv6 ULA hat, dann wird der Name in der Priorität aufgelöst bzw. vom Client in der Priorität benutzt.
Ist aber für DNS Infrastruktur kein Problem, DNS Server werden dem Client per IP mitgeteilt, dementsprechend ist IPv6 ULA zumindest dafür eine valide Lösung.
Ich will ja garnicht unbedingt klugscheißern, aber Nö. Wie meyergru auch schon schrieb, geht es um die grundsätzliche Priorisierung der Nutzung der entrsprechenden IP-Adresse durch den Netzwerkstack. IPv6 > IPv4 > IPv6 ULA. Das wirkt sich dann natürlich auf die Nutzung der vom DNS-Server zurückgelieferten IP aus.Diese wird vom Stack dann in der Priorität genutzt. Das gilt, wenn der Client sowohl ULA, GUA und IPv4 hat,auch für die IP-Adresse des DNS-Servers und damit für die Namensauflösung.
Der DNS-Infrastruktur ist das egal, ja.
Quote from: meyergru on January 13, 2026, 03:08:57 PMMal ganz abgesehen davon, dass der DNS-Server genauso gut per IPv4 genutzt / adressiert werden könnte - aber falls sowohl IPv4 als auch IPv6 angegeben werden, ist die Frage, welcher Server dann genutzt wird, undefiniert. All das gilt für Dual-Stack.
Undefiniert ist das nicht, sondern beruht auf der Prio des jeweiligen Stacks des Betriebssystems. Es wird ipv6 bevorzugt.
Quote from: meyergru on January 13, 2026, 03:08:57 PMULAs werden normalerweise nicht wegen der Angabe des DNS-Servers, sondern in dem Bestreben genutzt, bei dynamischen IPv6 Präfixen und gewünschtem weitgehenden Verzicht auf (legacy) IPv4 eine DNS-Eintragung vornehmen zu können - weil das mit den (dynamischen) GUAs eben nicht geht. Meine Bemerkung wies lediglich darauf hin, dass genau das bei Dual-Stack trotzdem nicht funktioniert, weil IPv6 ULAs bei gleichzeitiger Verfügbarkeit von IPv4 für DNS-Einträge aufgrund der geringeren Priorisierung gar nicht genutzt werden (viele denken, IPv6 würde "immer" vorgezogen - dem ist nicht so).
Genau aus dem Grund benutze ich ULA auch und hatte schon ein paar Merkwürdigkeiten mit IPv4 und den ULA,s die sich jetzt erklären
https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/
Hallo Patrick,
der Beitrag ist durchaus bekannt. :) ...keine ahnung wer der "experte" ist....
Es kommt drauf an wie du Google fütterst so kriegts du auch Antworten...
ULA useless, ULA usefull etc.
So wie ich Verstanden habe will TE eine Öffentliche IP6 über reverse Proxy an interne ULA's verdrahten...
Vor/Nachteile Reverse Proxy vs NAT!?
Es gibt ja noch NPTv6, Vor/nachtele vs NAT?
Wie hält man sein IP6 Netzwerk übersichtlich und konsistent? wenn zb Proveder wechsel etc.? Vlan Routing etc...
Bilder sprechen mehr als Wörter...
ip6.jpg
Quote from: Zapad on January 14, 2026, 08:23:39 AMder Beitrag ist durchaus bekannt. :) ...keine ahnung wer der "experte" ist....
https://labs.ripe.net/history-of-networking/behind-the-iron-curtain-ivan-pepelnjak/
Quote from: Zapad on January 14, 2026, 08:23:39 AMWie hält man sein IP6 Netzwerk übersichtlich und konsistent? wenn zb Proveder wechsel etc.? Vlan Routing etc...
Meine Antwort kennst du: statische Adressen, SLAAC und kein NAT.
Quote from: Patrick M. Hausen on January 14, 2026, 08:06:23 AMhttps://blog.ipspace.net/2022/05/ipv6-ula-made-useless/
Ich bin mir dessen durchaus bewusst. Beruflich verzichte ich auf ULA's und setze auf einen festen Ipv6 Prefix. Wenn ich aber privat Dienste freigeben möchte (DynDNS) und auch IPv6 filtern möchte, habe ich kaum eine andere Chance. Dynamische Prefixe sind mindestens genauso großer Mist wie ULAs. Ein fester IPv6 Prefix ist mir privat dann zu teuer....
Quote from: s.meier68 on January 14, 2026, 07:54:32 AMQuote from: bimbar on January 13, 2026, 02:16:39 PMDa gehts aber nur um die DNS Auflösung, wenn ein Name IPv6 GUA, IPV4 und IPv6 ULA hat, dann wird der Name in der Priorität aufgelöst bzw. vom Client in der Priorität benutzt.
Ist aber für DNS Infrastruktur kein Problem, DNS Server werden dem Client per IP mitgeteilt, dementsprechend ist IPv6 ULA zumindest dafür eine valide Lösung.
Ich will ja garnicht unbedingt klugscheißern, aber Nö. Wie meyergru auch schon schrieb, geht es um die grundsätzliche Priorisierung der Nutzung der entrsprechenden IP-Adresse durch den Netzwerkstack. IPv6 > IPv4 > IPv6 ULA. Das wirkt sich dann natürlich auf die Nutzung der vom DNS-Server zurückgelieferten IP aus.Diese wird vom Stack dann in der Priorität genutzt. Das gilt, wenn der Client sowohl ULA, GUA und IPv4 hat,auch für die IP-Adresse des DNS-Servers und damit für die Namensauflösung.
Der DNS-Infrastruktur ist das egal, ja.
Ja, aber, die einzige Situation, wo das typischerweise relevant ist, ist im DNS Fall, wenn es für einen Namen Einträge für all diese Adresstypen gibt.
...die Du brauchst, wenn das Gerät/Service auch für IPv4-only Clients genutzt werden soll. Und dann nehmen bei ULAs alle Clients die IPv4.
Sortieren wir es mal, es gibt drei Situationen:
1. Feste IPv6-Präfixe, so wie von der IETF vorgesehen. Man braucht keine ULAs, nur GUAs und IPv4-only Clients werden eben per Dual-Stack bedient (also interner DNS mit IPv4 und IPv6-Adressen bestückt). Alles ist gut - nur nicht für Hardware-Privacy-Experten, die dann auch noch ihre EUI-64 verschleiern wollen. Die Welt ist für die meisten Anderen schön.
2. Dynamische IPv6-Präfixe, aber keine Legacy-Clients: Dann kann man den internen DNS mit IPv6-only bestücken, was aber aufgrund der dynamischen Präfixe sinnvoll nur mit (festen) ULAs geht. Für Outbound IPv6 kann man zusätzlich GUAs verwenden, solange diese nicht im internen DNS auftauchen oder alternativ NAT64 machen (igitt). Ich mach' mir die Welt schön.
3. Dynamische IPv6-Präfixe und vorhandene IPv4-only Clients. Problematisch, außer mit internem IPv4 und outbound IPv6. Der interne DNS wird nur mit IPv4-Adressen gefüttert, weil das mit jedem Client geht. Andere Ansätze mit ULA usw. sind aufgrund der Priorisierung IPv4-vor-ULA unwirksam und clumsy, wie bereits dargestellt. Weil man diesen Ansatz eigentlich in allen drei Situationen fahren kann, ist das meine präferierte "Fits all"-Lösung (https://forum.opnsense.org/index.php?topic=45822.0) (deswegen steht im Titel "just works"). Die Welt ist immer noch schön, aber nicht "modern".
Variante 4, und die Welt ist Wwunderbar...
ip6.jpg
Quote from: bimbar on January 14, 2026, 10:00:22 AMJa, aber, die einzige Situation, wo das typischerweise relevant ist, ist im DNS Fall, wenn es für einen Namen Einträge für all diese Adresstypen gibt.
Es ist doch insgesamt relevant wenn mit ULAs gearbeitet wird? Wenn ein interner Dienst (DNS, sonst irgendeiner) eine ULA und eine IPv4 hat, wird der IP-Stack des anfragenden Clients beim Neuaufbau der Verbindung den Aufbau über IPv4 bevorzugen.
Für ausgehende Verbindungen in das Internet. Der Client wird bei AAAA und A Records die IPv4 des Zielsystems benutzen. Wenn jetzt der Server im Internet nur einen AAAA Record hat, wird der Client mit seiner ULA bis zum DefaultGateway kommen....
Wenn intern Wenn man also mit ULA's arbeitet um das Problem mit dynamischen Prefixen zu umgehen, muss man halt entsprechend aufpassen. Andersherum kann man aber von der externen öffentlichen IPv6 auf die interne ULA NAT machen. Der IP-Stack wechselt die IP Variante nicht.
Quote from: s.meier68 on January 14, 2026, 10:58:29 AMQuote from: bimbar on January 14, 2026, 10:00:22 AMJa, aber, die einzige Situation, wo das typischerweise relevant ist, ist im DNS Fall, wenn es für einen Namen Einträge für all diese Adresstypen gibt.
Es ist doch insgesamt relevant wenn mit ULAs gearbeitet wird? Wenn ein interner Dienst (DNS, sonst irgendeiner) eine ULA und eine IPv4 hat, wird der IP-Stack des anfragenden Clients beim Neuaufbau der Verbindung den Aufbau über IPv4 bevorzugen.
Für ausgehende Verbindungen in das Internet. Der Client wird bei AAAA und A Records die IPv4 des Zielsystems benutzen. Wenn jetzt der Server im Internet nur einen AAAA Record hat, wird der Client mit seiner ULA bis zum DefaultGateway kommen....
Wenn intern Wenn man also mit ULA's arbeitet um das Problem mit dynamischen Prefixen zu umgehen, muss man halt entsprechend aufpassen. Andersherum kann man aber von der externen öffentlichen IPv6 auf die interne ULA NAT machen. Der IP-Stack wechselt die IP Variante nicht.
Das Szenario mit den mehreren Adresstypen gibt es halt normalerweise nur bei DNS.
Intern ULA only mit NAT halte ich für keine gute Idee, da ist es besser, ULA und GUA zu kombinieren, auch wenn die GUAs dynamisch sind.
Quote from: Zapad on January 14, 2026, 10:45:30 AMVariante 4, und die Welt ist Wwunderbar...
ip6.jpg
Das erklärt nichts. Zu welcher Situation ist das eine Lösung?
a. Hast Du IPv4-only-Clients?
b. Was trägst Du im internen DNS ein? IPv4-only, ULA-only oder beides?
Wahrscheinlichster Fall:
Falls a = ja und b = beides (was dann nötig ist), werden Aufrufe der internen DNS-Bezeichnungen immer dazu führen, dass die IPv4 genutzt wird, nie die ULA. Somit bleiben die ULAs für den internen DNS wirkungslos. Stattdessen erhöhst Du die Komplexität, weil Du für den externen IPv6-Zugriff nun auch noch NAT64 benötigst. Was gewinnst Du also nochmal genau gegenüber Variante 3 durch die ULAs?
Und make no mistake: Deine Grafik aus #32 beweist lediglich, dass Deine Clients IPv6 nutzen. Ich vermute, das sind (externe) GUAs, keine ULAs - denn: interne Zugriffe müssten so zwangsläufig auf die IPv4 des Service laufen.
Quote from: meyergru on January 14, 2026, 11:48:08 AMUnd make no mistake: Deine Grafik aus #32 beweist lediglich, dass Deine Clients IPv6 nutzen. Ich vermute, das sind (externe) GUAs, keine ULAs - denn: interne Zugriffe müssten so zwangsläufig auf die IPv4 des Service laufen.
Natürlich ist WAN GUA, die Clients intern nutzen ULA über Sense KEA mit RA.
wenn die Clients IP4 DNS abfragen sollen wie denn? natürlich IP6 DNS.
...aber wenn es deine Welt durcheinander bringt....
ad.jpg
@meyergru Es gibt noch eine weitere Variante: DNS so konfigurieren, dass Clients, die Queries per IPv6 schicken nur AAAA-Records genannt bekommen. Das umgeht u. A. das Problem der Priorität von IPv4 vs. ULAs.
Gelöst habe ich das bei mir so:
Die internen DNS-Zonen sind in Bind (OPNsense-Plugin) angelegt. Dort gibt es AAAA-Records (ULAs) und A-Records (RFC1918).
Als Rekursiver Resolver läuft Unbound, mit Forwardings zu Bind für die internen Zonen. DNS64 und AAAA-only-Modus sind aktiv.
Über RAs und DHCPv6 wird die IPv6-Adresse von Unbound als DNS-Server verteilt. IPv6-Clients bekommen somit ausschließlich AAAA-Records (der AAAA-only-Modus filtert A-Records).
Über DHCPv4 wird die IPv4-Adresse von Bind als DNS-Server verbreitet, IPv4-Clients befragen also direkt Bind und bekommen somit auch A-Records.
Die NAT64-Aversion wirst Du auch noch überwinden, mittelfristig kommt ohnehin niemand daran vorbei. ;)
Ich habe für NAT64 noch nie einen guten Nutzen gefunden.
Interne v4 only Server werden bei mir per reverse Proxy erreicht.
Für mich zumindest eine spannende Diskussion. Meine Idee mit en ULA war, dass ich kein IPv4 mehr habe. Vielleicht ist das untergegangen. Hier mal eine Visualisierung:
ipv6.jpg
Die ULA nutze ich für interne Kommunikation zwischen Reverse Proxy und Services, sodass diese Dienste nicht über ihre globale Adresse angesprochen werden müssen.
Dadurch sind interne Abhängigkeiten unabhängig vom ISP-Prefix.
Zusätzlich reduziert ULA das Risiko, dass Services durch Fehlkonfigurationen versehentlich öffentlich erreichbar werden, da sie intern nur auf ULA lauschen.
Die GUA dient ausschließlich für kontrollierten ausgehenden Traffic, während eingehender Zugriff zentral über den Reverse Proxy erfolgt.
Das war die Überlegung hinter den ULAs. Macht das Sinn? Ich befürchte nur, dass ich einige Geräte habe, die nur IPv4 können und dann ist das hinfällig, oder?
Bzgl. der festen IP. Diese würde mich 5€ mtl. mehr kosten. Aber es scheint egal welche Lösung man fährt, wäre eine feste IP besser.
@bimbar Ein Reverse Proxy mag für manche interne Dienste eine Alternative zu NAT64 sein, löst aber nicht das Problem, dass es noch ein klein wenig dauern wird, bis sämtliche Services im Internet über IPv6 erreichbar sein werden. Ohne NAT64 wirst Du daher noch bis zum Sankt-Nimmerleins-Tag Dual Stack im LAN fahren müssen.
@Maurice: Klar, mit Tricks geht das. Aber 1. sind wir da wieder bei komplexen Umgehungslösungen und b. funktioniert auch das nur bedingt, siehe unten...
@Zapad: Das beweist wieder nichts. Ich streite dich nicht ab, dass Deine Clients IPv6 nutzen - und wenn sie nur ULAs haben, dann auch nur diese. Aber: sie nutzen die ULAs nicht für intra-LAN- oder (mutmaßlich) für inter-VLAN-Traffic!
Nochmal ganz simpel erklärt - mach mal einen Test: Trage eins Deiner Geräte mit IPv4 und IPv6 ULA in den DNS ein, sagen wir:
smtp.xyz -> 192.168.10.100 und fd05::100
Dann versuchst Du, auf irgendeinem IPv6-fähigen CLient den Namen aufzulösen:
#nslookup smtp.xyz
Server: 192.100.10.1
Address: 192.168.10.1#53
Non-authoritative answer:
Name: smtp.xyz
Address: 192.168.10.100
Name: smtp.xyz
Address: fd05::100
Fein. Und dann kontaktierst Du den Server:
#ping smtp.xyz
PING smtp.xyz (192.168.10.100) 56(84) bytes of data.
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=2 ttl=64 time=0.034 ms
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=3 ttl=64 time=0.052 ms
Wie? Wieso IPv4? Wie gesagt, das ist das Standardverhalten. IPv4 wird den ULAs vorgezogen. Wenn Du also nicht ausschließlich ULAs (und keine IPv4) im DNS-Reply zurückbekommst, wird nur die IPv4 verwendet. Den Trick, den Maurice nennt, mal außen vorgelassen - dabei würdest Du den ULA-Clients die IPv4 niemals zeigen. Das bedeutet natürlich auch, dass diese Clients niemals irgendwelche IPv4 gezeigt bekommen - Zugriff auf IPv4-only Geräte im IoT Netz (z.B. schaltbare Steckdosen) ist damit dann per DNS-Name nicht mehr drin.
Über die IPv4-only Clients müssen wir nicht diskutieren, die nehmen ohnehin nur die IPv4-Adresse. Also:
Deine ULAs nutzen im LAN nichts - sie werden schlicht ignoriert, Du kannst sie ebensogut aus dem internen DNS löschen. Du nutzt bei LAN-internem Traffic de facto ausschließlich IPv4 - zumindest, wenn Du es "normal" per DNS probierst. Die Rahmenbedingungen habe ich in den Varianten genannt.
Den einzigen Effekt, den Du erzielst, ist, dass Du im LAN GUA vermeidest und stattdessen NAT66 benötigst. Warum das nützlich ist, ist mir immer noch unklar (außer, man will IPv6-only im LAN und muss dann für Github und andere IPv4-only Websites NAT machen).
Quote from: bimbar on January 14, 2026, 02:44:20 PMIch habe für NAT64 noch nie einen guten Nutzen gefunden.
ich weiss nicht woher NAT64 (pfui) aufkommt aber in meinem Kontext habe ich immer NAT66 gemeint.
@n3
nutze die ULAS so wie du mags wenn es funktioniert und wenn ein ULA doch noch internet braucht kannst du ja immernoch NAT66 dazuschalten.
@n3 Kannst Du so machen, wobei Du dann auch im Client-Netz GUA + ULA verwenden solltest.
IPv4-only-Clients am besten in ein eigenes IPv4-only-LAN packen. Über Tayga kannst Du dann die Brücke zu den IPv6-LANs herstellen.
Für einen Fünfer mehr würde ich definitiv das statische GUA-Präfix nehmen. Das hast Du zwar auch nicht bis in alle Ewigkeit, anders als z. B. eine Telefonnummer kann es nicht "portiert" werden und ist spätestens beim Provider-Wechsel weg. Aber ein manuelles Renumbering alle paar Jahre ist etwas völlig anderes als ein sich ständig änderndes dynamisches Präfix.
@meyergru
Quote from: meyergru on January 14, 2026, 03:09:58 PMDen Trick, den Maurice nennt, mal außen vorgelassen - dabei würdest Du den ULA-Clients die IPv4 niemals zeigen. Das bedeutet natürlich auch, dass diese Clients niemals irgendwelche IPv4 gezeigt bekommen - Zugriff auf IPv4-only Geräte im IoT Netz (z.B. schaltbare Steckdosen) ist damit dann per DNS-Name nicht mehr drin.
Doch, natürlich. DNS64 (Unbound-Feature) synthetisiert AAAA-Records, falls es nur A-Records gibt. Und NAT64 (Tayga-Plugin) übersetzt zwischen IPv6 und IPv4. Mein Smartphone im IPv6-only-Netz greift so z. B. problemlos auf Smart Home-Kram im IPv4-only-Netz zu.
@Maurice: Das hast Du aber einen ganz hübschen Stapel von Mechanismen beisammen, um "modern" zu sein. Bin gespannt auf das HOWTO dazu... ;-)
Bitte ein paar beispiele für IP6-only Clients?
Bitte keine wo man Dualstack manuell deaktiviert.
Mmn. gibs es nur IP4-Only clients, zb meine Reolink Cams....
und wenn man Dualstack sowieso hat, ist man frei intern alles zu benutzen was man will.
Schlimm wenn es nicht die eine Lösung gibt ;-) Verstehe ich es grob richtig, dass aktuelle zwei Ansätze diskutiert werden. Der eine zielt möglichst auf IPv6 only ab und bindet IPv4 dort ein, wo nötig. Führt aber zu einer komplexeren Konfiguration.
Der andere Ansatz ist Dual-Stack, was vielleicht nicht optimal ist, jedoch einfacher zu konfigurieren/betreiben.
Welche Vorteile hat Ansatz 1 und welche Nachteile Ansatz 2?
Gibt es einen Favoriten für mein Szenario (der initiale Aufwand mal außen vor gelassen):
- HomeLab
- Feste/Dynamisch IP Adresse möglich
- Mehrere Interfaces (Consumer-Clients, Server, Kameras, Außennetzwerk)
- proxmox mit opnsense, homeassistant, nextcloud, AdGuard, etc.
- Consumer-Clients sollten von am besten nahtlos von Außen auf homeassistant, nextcloud zugreifen können
- nextcloud sollte aber auch für Dritte verfügbar sein
- Prio 1 Sicherheit, Prio 2 Stabilität und Prio 3 Maintenance
P.S. Hab mich geirrt. Die feste IP kostet 10€ und ab dem 7. Monat dann 23€/mtl.
Hast du DS-Lite?
kannst du ip4 nicht richtig nutzen? vllt. wäre sowas für dich nützlich:
https://www.feste-ip.net/fip-box/allgemeine-informationen/
Quote from: n3 on January 14, 2026, 04:33:50 PMSchlimm wenn es nicht die eine Lösung gibt ;-) Verstehe ich es grob richtig, dass aktuelle zwei Ansätze diskutiert werden. Der eine zielt möglichst auf IPv6 only ab und bindet IPv4 dort ein, wo nötig. Führt aber zu einer komplexeren Konfiguration.
Der andere Ansatz ist Dual-Stack, was vielleicht nicht optimal ist, jedoch einfacher zu konfigurieren/betreiben.
Welche Vorteile hat Ansatz 1 und welche Nachteile Ansatz 2?
Gibt es einen Favoriten für mein Szenario (der initiale Aufwand mal außen vor gelassen):
- HomeLab
- Feste/Dynamisch IP Adresse möglich
- Mehrere Interfaces (Consumer-Clients, Server, Kameras, Außennetzwerk)
- proxmox mit opnsense, homeassistant, nextcloud, AdGuard, etc.
- Consumer-Clients sollten von am besten nahtlos von Außen auf homeassistant, nextcloud zugreifen können
- nextcloud sollte aber auch für Dritte verfügbar sein
- Prio 1 Sicherheit, Prio 2 Stabilität und Prio 3 Maintenance
P.S. Hab mich geirrt. Die feste IP kostet 10€ und ab dem 7. Monat dann 23€/mtl.
Wenn Du ein von außen erreichbares Homelab betreiben willst wäre eine feste IP von Vorteil (aber nicht zwingend - ich habe keine, nutze nur DynDNS für IPv4 und IPv6, da full Dual Stack). Ich betreibe alle die von Dir beschriebenen Sachen wie im Howto beschrieben. Sicherheit durch Betrieb der von außen erreichbaren Services in einer separaten DMZ, außerdem in den meisten Fällen per Reverse Proxy. Falls kein HTTPS, über Port forwarding (IPv4 und IPv6). Dadurch sind nur WAN IPv4 und IPv6 exponiert. Im LAN keine ULA, nur GUA per SLAAC und IPv4 ("old style"). Konkret über RADVD und Kea DHCP mit Unbound.
Das erlaubt IPv4-only Clients (und Server - die müssen bis auf nicht-proxy-fähige Dienste ja sowieso nur IPv4 können, weil ich im Reverse Proxy eh nur IPv4 nach innen nutze).
Sicher, keine Tricksereien, kein Tayga, kein NAT66, VLANs straightforward mit IPv4/24 und IPv6/64, keine Pflege von internem DNS mit IPv6 (nur IPv4). Funktioniert auch für IPv4-Clients.
Potentielle Nachteile:
a. Geräte, die keine Privacy Extensions unterstützen, telefonieren mit Ihrer festen EUI-64 nach außen
b. old style, d.h. nicht "IPv6 first"
DS-Lite ist ein separates Thema, weil man sich dann Gedanken machen muss, wie man Dienste nach außen per IPv4 verfügbar macht, was auf Tunnellösungen hinausläuft.
Quote from: meyergru on January 14, 2026, 03:35:20 PMDas hast Du aber einen ganz hübschen Stapel von Mechanismen beisammen, um "modern" zu sein.
"Modern zu sein" ist nicht die Motivation. Es geht darum, frühzeitig Erfahrungen mit Technologien zu sammeln, die mittelfristig unser aller Alltag sein werden. Und es hilft dabei, ein kleiner Teil der Lösung zu sein und nicht des Problems. Das Problem ist, dass zu viele warten, bis andere vorangehen und die Steine aus dem Weg räumen. So kommen wir aber nicht voran. Und gerade das Heimnetz / Home Lab ist prädestiniert für Bleeding Edge, denn kritische Infrastruktur ist das eher selten.
Quote from: meyergru on January 14, 2026, 03:35:20 PMBin gespannt auf das HOWTO dazu.
Das How-to zu DNS64 / NAT64 mit Tayga und Unbound habe ich vor Jahren geschrieben, das ist Teil der OPNsense-Doku (https://docs.opnsense.org/manual/how-tos/tayga.html).
Die Geschichte mit BIND als authoritativem DNS-Server für die internen Zonen und Unbound als rekursivem Resolver mit DNS64 und Forwarding zu BIND ist fast trivial, aber vielleicht ist das nur die Innenperspektive. ;)
Der Weg war tatsächlich steinig, so manches OPNsense-Feature musste erst implementiert und der eine oder andere Bug gefixt werden. Im jetzigen Zustand ist es aber relativ einfach zu konfigurieren. Vielleicht schreibe ich mal ein How-to für das Gesamtpaket.
Quote from: n3 on January 14, 2026, 04:33:50 PMSchlimm wenn es nicht die eine Lösung gibt
Die Qual der Wahl. Es gibt mehrere passable Lösungen und viele schlechte. ;)
Quote from: n3 on January 14, 2026, 04:33:50 PMVerstehe ich es grob richtig, dass aktuelle zwei Ansätze diskutiert werden. Der eine zielt möglichst auf IPv6 only ab und bindet IPv4 dort ein, wo nötig.
Richtig.
Quote from: n3 on January 14, 2026, 04:33:50 PMFührt aber zu einer komplexeren Konfiguration.
Einerseits komplexer durch DNS64 / NAT64 und ggfs. etwas mehr DNS-Konfiguration, andererseits einfacher dadurch, dass es in jedem Netz nur
einen Stack gibt -
entweder IPv6
oder IPv4. D. h. jeweils nur
ein Satz Firewall-Regeln,
entweder RAs + ggfs. DHCPv6
oder DHCPv4 etc. Was man unterm Strich präferiert ist eine individuelle Entscheidung.
Quote from: n3 on January 14, 2026, 04:33:50 PMDer andere Ansatz ist Dual-Stack, was vielleicht nicht optimal ist, jedoch einfacher zu konfigurieren/betreiben.
Es ist die konservativere, etablierte Lösung.
Quote from: n3 on January 14, 2026, 04:33:50 PMWelche Vorteile hat Ansatz 1 und welche Nachteile Ansatz 2?
Möchtest Du zwei Schritte vorausgehen und nimmst dafür den etwas holprigeren Weg auf dich? Dann Ansatz 1.
Gehst Du lieber zwei Schritte hinterher und hast dafür eine gut dokumentierte, ausgereifte Konfiguration? Dann Ansatz 2.
Beide Wege sind legitim.
Quote from: n3 on January 14, 2026, 04:33:50 PMDie feste IP kostet 10€ und ab dem 7. Monat dann 23€/mtl.
Wäre mir persönlich auch zu teuer, ist aber wieder eine individuelle Entscheidung. Privat habe ich momentan auch nur ein dynamisches Präfix, einzig aus Kostengründen. Das erfordert schon einige Klimmzüge mit ULAs, DynDNS etc. Bei meinem vorherigen ISP hatte ich ein quasi statisches Präfix und das war wirklich wesentlich einfacher zu handhaben.
Quote from: meyergru on January 14, 2026, 05:55:34 PMnutze nur DynDNS für IPv4 und IPv6
Von außen ist mein Heimnetz ausschließlich über IPv6 erreichbar (zur Zeit ebenfalls per DynDNS). Macht es auch wieder einfacher und reicht für meine Anforderungen völlig, spätestens seit es IPv6 hierzulande in allen Mobilfunknetzen gibt. Und falls mein ISP morgen auf DS-Lite umstellt bzw. €€€ für "Premium Dual Stack" möchte, dann bin ich tiefenentspannt und sage: Mach doch, kannst IPv4 gerne abschalten.
Danke euch beiden für die zwei Beiträge. Das hilft es besser einordnen zu können. Viele Wege führen nach Rom und so kann man besser einschätzen, welchen Weg man gehen möchte. Aktuell läuft mein System wie im HowTo von @meyergru beschrieben. IPv6 First klingt interessant, weil ich in vielen Fällen gerne ein e
Early Adopter bin, aber ich muss schauen, ob mir der Mehraufwand es wert ist.