Noch als Nachtrag: es scheint am Browser zu liegen. Safari scheint auf die offizielle AVM Seite zu gehen.
Firefox geht auf die Oberfläche der Fritzbox.
Ja, die Browser dieser Welt bieten inzwischen fast alle Einstellungen zur Verwendung von DoH an. Allerdings wundert mich dein Safari-Ergebnis, denn lt. Google-Suche (https://www.google.com/search?q=DNS+over+HTTPS+Safari) sollte Safari DoH gar nicht unterstützen.
Eine FRITZ!Box hat immer 2 LAN-IPv6-Adressen:
Diese beiden Adressen bekommt man auch angezeigt, wenn man "fritz.box" unter Verwendung eben dieses DNS-Forwarders (z.B. dessen IPv4, in meinem Fall 192.168.178.1) auflöst:
Hier mit nslookup unter Windows:
C:\>nslookup fritz.box. 192.168.178.1
Server: UnKnown
Address: 192.168.178.1
Name: fritz.box
Addresses: fdXX:XXXX:XXXX:0:9a9b:cbff:feZZ:ZZZZ
2a00:6020:PQWX:YZ00:9a9b:cbff:feZZ:ZZZZ
192.168.178.1Die hier verwendete Traceroute-Software scheint das zu erkennen (wie auch in dem Google-Beispiel) und zeigt das an, schließlich muss sie ja eine Auswahl treffen, welche der aufgelösten IPv6-Adressen sie für den Traceroute verwenden will.
Es muss nichts bedeuten, aber auffällig ist, dass in allen hier aktuell diskutierten Fällen mit IPv6-Problemen von gordrin , webwe und DrFroeschle die PD-Blöcke in 2a00:6020:7300::/40 bzw. sogar genauer in 2a00:6020:73d0::/44 liegen und die zugehörigen WAN-Port-Adressen in 2a00:6020:7380::/112. Ist evtl. ein neuer Block, den DG aktuell für Neuanschlüsse verwendet. Neu ist hier auch die Zuordnung der WAN-Port-Adresse zum PD-Block: An älteren Anschlüssen, z.B. denen mit PD-Blöcken aus 2a00:6020:4000::/36 liegen die zugeordneten WAN-Port-Adressen in 2a00:6020:1000::/48. In Traceroutes zu Zielen an diesen älteren Anschlüssen sieht man als letzte Etappe vor dem Kunden-Router Adressen aus 2a00:6020:ffff:ffff::/64 (lt. RIPE-DB als "BNG-Cluster-DHCPv6-Link-Address" benannt), diese habe ich in Traceroutes zu Zielen an den oben genannten Adressblöcken der neueren Anschlüsse noch nie gesehen.
DG hat hier offenbar ein anderes Nummerierungs-Schema eingeführt, und man könnte vermuten, dass damit evtl. auch eine geänderte Access-Infrastruktur einher geht.
Liegen die Anschlüsse im selben Ausbaugebiet oder zumindest in benachbarten PLZ-Bereichen?
Andererseits bleibt es bei der Beobachtung, dass das Paket die Fritzbox wieder verlässt.
Insofern halte ich die These des "droppenden DG-Routers" für nicht plausibel und sehe die Ursache des Problems eher doch lokal auf Kundenseite.
Ja, auf der Suche nach möglichen lokalen Ursachen hat sich meine These der zwei unterschiedlichen MAC-Adressen am WAN-Port (einfach spekulativ aus der Angabe, dass es ein aus LAN1 umkonfigurierter WAN-Port ist) als nicht haltbar ergeben.
Bleibt noch:
Hier besteht ein gewisses Restrisiko, dass die Annahme falsch ist. Das hast du bislang nur von deinem merkwürdigen Bridgekonstrukt überprüft, von dem wir nicht wissen, wie es den Verkehr beeinflusst.
Vielleicht sollte man dieses Bridgekonstrukt tatsächlich mal entfernen, um es als Fehlerursache auszuschließen.
Was allerdings hilft, ist ein nslookup auf fritz.box von einem der Clients im Heimnetz. Da bekomme ich dann von dem FB dnsmasq die Adresse ausgehändigt. Mit dieser habe ich dann vom VPS Server im Internet aus einen traceroute6 gemacht:
Und diese Adresse ist dann:
root@vmdabcdef:/etc# traceroute6 2a00:6020:73d7:xxxx:3ea6:2fff:fe44:zzzz
Es ist also eine Adresse aus dem PD-Block 2a00:6020:73d7:5900::/56, die zur Fritzbox gehört.
Andererseits lautet die IPv6-Adresse deines Test-Webservers im LAN 2a00:6020:73d7:5900:223:55ff:fe:fc:5155, liegt also auch im PD-Block 2a00:6020:73d7:5900::/56, nur eben nicht auf der Fritzbox.
Jetzt haben wir die Beobachtung:
Werden die beiden Adressen von außen angesprochen, dann ...
Wenn nun die These ist, dass im DG-Netz irgendein Router im ersten Fall das Antwort-Paket droppt, frage ich mich anhand welchem Kriteriums er das tun sollte. Die These war ja: Immer wenn die Adresse zu Fritzbox gehört, wird gedroppt, sonst nicht. Woran soll aber die droppende Instanz im DG-Netz erkennen, dass 2a00:6020:73d7:5900:3ea6:2fff:fe44:zzzz zur Fritzbox, 2a00:6020:73d7:5900:223:55ff:fe:fc:5155 aber zu einem Webserver im LAN gehört? Es sind einfach zwei Adressen aus dem PD-Block 2a00:6020:73d7:5900::/56.
Insofern halte ich die These des "droppenden DG-Routers" für nicht plausibel und sehe die Ursache des Problems eher doch lokal auf Kundenseite.
Wie und warum sollte ein Router ein Paket droppen? Das kann nur die Firewall machen. Oder worauf willst du hinaus?
Exakt!
Ich gehe aber nicht davon aus, dass ein ISP, der ja im Wesentlichen nur Traffic zwischen dem Internet und seinen Kunden routen soll, Firewalls im Datenstrom platziert. Jedenfalls nichts, was "State" und "Sessions" halten muss (außer bei CGNAT, da sind NAT-Sessions halt ein notwendiges Übel). Wenn überhaupt, dann sind vielleicht Paketfilter im Spiel, die stateless arbeiten, und in einem Router vielleicht Pakete droppen, die z.B. als Ergebnis eines Reverse-Path-Forwarding-Checks "zum falschen Interface" herein kommen.
Aber gut, ich habe keine Einblicke in das Innenleben eines ISPs - falls du oder sonst jemand da Erfahrungswerte liefern kann, gerne mehr.
Ich meine schon: Es würde deine Vermutung entkräften, weil es dann keinen zu haltenden "State für diese IP" gibt. Bitte Worte wie "Haarspalterei" vermeiden, kommt nicht gut.
OK, dann wird der DG-Router den State für diese IP nicht halten und das Paket verwerfen, da es zu keiner initiierten Session passt.
Ein Router ist keine Firewall ...
Und wenn du von einem IPv6-fähigen LAN-Client einen IPv6-Ping auf ein beliebiges Internet-Ziel absetzt (und dabei einen Trace am WAN-Port laufen lässt), wird dieses ICMPv6-echo auch mit der Source-MAC-Adresse 3c:a6:2f:44:18:37 weitergeleitet (damit wollte ich es vergleichen)?
DG akzeptiert am DG-Anschluss ja nur eine einzige MAC-Adresse.
Blöde Idee:
Falls deine Fritzbox in Antwortpaketen zu Requests aus dem Internet (zu Diensadressen auf der Fritzbox selbst) eine andere MAC-Adresse als für Weiterleitungspakete von Clients/Servern in deinem LAN verwendet, würden diese vom "DG-Router" gedropt. Das würde zumindest das beobachtete Verhalten erklären.
Man könnte das durch Paketmitschnitte am WAN-Port der Fritzbox herausfinden (vergleiche den Trace mit den gedropten SYN/ACKs mit dem ausgehenden Traffic von Clients).
Nachtrag:
Und falls dem so ist, könnte es evtl. daran liegen, dass LAN1 hier als Ersatz für einen echten WAN-Port herhalten muss - das mag dann zu solchen Effekten führen.
Alle diese Pakete gehen mit der 2a00:6020:7380::1735 als Source IP ab.
Also, wenn ich für diese WAN-Port-Adresse deiner Fritzbox dieselben Traceroute-Tests durchführe, die ich hier bezogen auf das Problem von gordrin durchgeführt habe, dann erhalte ich auch dieselben (negativen) Ergebnisse, wie dort beschrieben:
Mit fällt auf, dass deine WAN-Port-Adresse "ungewöhnlich ist": In allen Fällen, die ich bisher gesehen habe, liegen die WAN-Port-Adressen von DG-Anschlüssen im Range 2a00:6020:1000::/48
Ergänzung:
Tscha, und was soll ich sagen, hängt am gleichen Hop wie wenn ich die dedizierte FB IPv6 Adresse verwende. Und wie ich in meinem eigenen Forumsthread schon geschrieben hatte: Wenn ich einen Webserver im "Heimnetz" einrichte und diesen per IPv6 an der Fritzbox freischalte, dann kann ich auf diesen zugreifen. Nur die Rückrouten direkt für die Fritzbox-Services werden am DG Router geblockt (meine Vermutung).
Aus deinen Angaben reime ich mir trotz "Obfuskierung" zusammen:
Dein PD-Block ist 2a00:6020:73d7:5900::/56. Und egal, ob es in diesem Block einen nach außen freigeschalteten Webservice gibt oder nicht, sollte ein Traceroute von außen für jede beliebige Adresse von 2a00:6020:73d7:5900:0:0:0:0 bis 2a00:6020:73d7:59ff:ffff:ffff:ffff:ffff als letzte Etappe vor deinem Router eine Adresse aus 2a00:6020:ffff:ffff::/48 aufweisen, so zumindest das Ergebnis meiner Traceroute-Analysen zu vielen anderen DG-Kundenanschlüssen. Das sehe ich für den PD-Block deines Anschlusses allerdings nie: Egal, welche beliebige Adresse aus dem Block ich wähle, das Traceroute-Ergebnis ist stets so, wie für deine WAN-Port-Adresse 2a00:6020:7380::1735 oben beschrieben.
Aber gut, vielleicht ist es unzulässig, meine Beobachtungen zu verallgemeinern, und für neuere Anschlüsse mögen sie nicht mehr zutreffen.
Nur noch eine Idee:
Ist in deiner Fritzbox der "Stealth Mode" (Diagnose | Sicherheit | Filter) aktiv? Falls ja, könnte es helfen, den mal zu deaktivieren. Dann könnte man evtl. auch die WAN-Port-Adresse deiner Fritzbox in Traceroutes sehen.
gordrin :
Hi again,
ich habe mal, auch weil es mich selbst interessiert, Traceroutes zu diversen DG-IPv6-Zielen an anderen Kundenanschlüssen durchgeführt, und zwar ...
Als Kandidatenliste von IPv6-Zielen an Kundenanschlüssen habe ich mir RIPE-ATLAS-Probes ausgewählt (solche mit Eintrag 60294 in der Spalte "ASN v6", dann dem Link in der Spalte "ID" folgen, um im "Network"-Tab der probe-site deren IPv6-Adresse zu erfahren, manche sind sogar von außen anpingbar).
Ergebnisse:
Im Fall 1 (heise online-Traceroutes aus dem Internet) sehe ich stets ...
Im Fall 2 (Traceroute von meinem Desktop-PC am DG-Kundenanschluss) sehe ich stets ...
Wenn ich nun die beiden Traceroute-Varianten für deine IPv6-Adresse am WAN-Port deiner Fritzbox durchführe (wie in einem früheren Post erwähnt, kann ich die jeweils aktuelle ermitteln), komme ich abweichend zu folgenden Ergebnissen:
Im Fall 1 (heise online-Traceroutes aus dem Internet) sehe ich ...
Im Fall 2 (Traceroute von meinem Desktop-PC am DG-Kundenanschluss) sehe ich ...
Das betätigt nochmals aus einer weiteren Perspektive, dass in der DG-Netzinfrastruktur (zumindest) das Rückwärts-Routing zu den IPv6-Adressen an deinem DG-Anschluss nicht funktioniert.
Vielleicht müsste DG einfach mal meine Geräte aus deren Infrastruktur reseten?
Ich denke nicht, dass die DG pro Kunde dedizierte "Geräte in ihrer Infrastrukur" betreibt. Auch der "letzte" Router Richtung Kunden-Access-Struktur wird vermutlich mehrere Kundenanschlüsse aggregieren. Es ist vermutlich eher ein Konfigurationsproblem in deren Infrastruktur, wie ich's oben schon mal formuliert habe:
Meine Interpretation: DG schafft es nicht, für deinem Anschluss feste (oder sagen wir: "quasistatische", denn echt "fest" ist nicht garantiert) IPv6-Adressen (IA_NA, IA_PD) zu reservieren, geschweige denn, in der DG-Netzinfrastruktur für den jeweils zugewiesenen PD-Block bzw. die WAN-Port-Adresse eine (Rückwärts-)Route über deine WAN-Leitung zu deinem Router zu generieren.
Das ist zumindest das, was man aus dem bei dir sicht- und analysierbaren Verhalten an deinem Anschluss folgern kann.
Das Problem wird sein, den DG-Support davon zu überzeugen, dass die Problemlösung in deren Infrastruktur zu suchen und zu beheben ist.
gordrin: In deiner aktuell vorliegenden Konstellation wird deinen LAN-Clients vorgegaukelt, sie könnten neben IPv4 auch vollwertig IPv6 nutzen. Dort, wo "Happy Eyeballs" nicht greift, wird sich ggf. eine schlechte User Experience einstellen, nämlich immer dann, wenn zunächst bevorzugt versucht wird, eine IPv6-Verbindung aufzubauen, um nach dem zwangsläufigen Scheitern dieses Versuchs es mit einer IPv4-Verbindung zu versuchen - Ergebnis: Eine als zu lang empfundene Aufrufdauer. Bezogen auf einen Webbrowser an einem Client kann man das Verhalten bzgl. "Happy Eyeballs" hier mal testen.
Es wäre aktuell ggf. empfehlenswert, in der Fritzbox die IPv6-Unterstützung vorerst zu deaktivieren und sie von Zeit zu Zeit nur zu Testzwecken anzuschalten. um zu prüfen, ob das Problem auf DG-Seite denn nun gelöst wurde, bevor sie dann wieder dauerhaft aktiviert bleiben kann. Das aus meiner Sicht derzeit beste Testwerkzeug für IPv6 am Client: https://test-ipv6.com/
Noch ein Nachtrag:
Die eben erwähnte Testseite https://test-ipv6.com/ enthält oben rechts noch den schönen Link "Für den Helpdesk". Klickt man den, dann gelangt man auf eine Seite, auf der unten ein Link auf das Testergebnis angegeben ist. Den könntest du z.B. auch dem DG-Support zukommen lassen. Vielleicht hilft es ...
Danke schon jetzt für eure Unterstützung. Anbei hab ich den WAN-Port mitschnitt. In diesen ist auch ein dhcpv6 rebind gefallen. Soweit ich das sehe ist die RA gut, die Router Lifetime sitzt auf 4500.
Hier ist der FritzBox WAN Mitschnitt:
Ein Grund für den DHCPv6 Lease-Timeout ist vermutlich, dass die bestehende Lease seitens DG nicht mehr zu verlängern war, weil dein Anschluss andere IPv6-Adressen bekommen sollte: Die neue WAN-Port-Adresse hat als letzte Ziffer anstelle einer 2 nun eine 7. Im LAN-Prefix hat sich eine Ziffer von 5 auf a geändert. In der Regel bekommt man an stabil funktionierenden Anschlüssen stets dieselben Adressen zugewiesen. Bei meinem Anschluss haben die sich bisher nur nach einer DG-Wartung einmal geändert.
Wäre mal interessant zu beobachten, ob dein Router nach jedem Lease-Timeout mit anschließender Neuaushandlung einer Lease geänderte IPv6-Adressen bekommt.
gordrin: Deinem Mitschnitt konnte ich eine Information entnehmen (keine Sorge: die vergesse ich auch wieder), die es mir ermöglicht, die aktuell deinem WAN-Port zugeordnete Adresse zu ermitteln und damit meine noch offene Frage selbst zu beantworten:
Demnach weist DG deinem Anschluss eine DHCPv6-Lease (WAN-Adresse + /56-PD-Block für's LAN) mit der Leasedauer 1h zu, die aber per DHCPv6-Renew/Rebind nicht verlängert wird. Nach einer Stunde, also Ablauf der Leasedauer, bezieht die Fritzbox eine neue Lease und erhält dabei jedes Mal eine andere WAN-Port-Adresse (und ich gehe davon aus, auch einen anderen PD-Block). Das Ganze wiederholt sich jede Stunde (etwa um XX:09 Uhr) - müsste im Eventlog des Routers auch angezeigt werden.
Meine Interpretation: DG schafft es nicht, für deinem Anschluss feste (oder sagen wir: "quasistatische", denn echt "fest" ist nicht garantiert) IPv6-Adressen (IA_NA, IA_PD) zu reservieren, geschweige denn, in der DG-Netzinfrastruktur für den jeweils zugewiesenen PD-Block bzw. die WAN-Port-Adresse eine (Rückwärts-)Route über deine WAN-Leitung zu deinem Router zu generieren.
Ich nehme mal an, der vom DG-Support vorgeschlagene ONT-Reset hat nichts gebracht?
Das Problem ist hier doch partiell auf Layer 3 (IPv4, IPv6) des Netzwerk-Stacks zu verorten, und IPv4 funktioniert ja einwandfrei. Wofür nun eine Maßnahme auf Layer 1+2 (Optik <-> Elektronik + Ethernet), nämlich ein Reset des ONT, gut sein soll, weiß wohl nur der Support auf Layer 8. Oder anders: Läge dort das Problem, würde IPv4 auch nicht funktionieren. Aber ich lasse mich hier gerne eines Besseren belehren.
ONT-Reset habe ich auch schon mal gemacht. Ging immer gut und war auch nie Ursache des Problems (hatte zeitweise auch schon IPv4 und/oder IPv6-Konnektivitätsausfälle - allerdings maximal nur für ein paar Stunden - inzwischen läuft mein Anschluss sehr stabil).
Ich habe mal einen Blick auf den Mitschnitt geworfen. Zu DHCPv6 (Ansichtsfilter "dhcpv6" setzen): Ja, man sieht mehrere Rebind-Requests, die von der DG-Gegenstelle jedoch ignoriert werden. Am Ende (also nach Ablauf der Leasedauer) leitet die Fritzbox (fe80::d624:ddff:febd:b46b) dann mit einer DHCPv6-Solicitatation eine neue Transaktion (neue XID) zum Bezug einer neuen Lease ein, die erfolgreich von der Gegenstelle mit einem Reply abgeschlossen wird (Rapid Commit aktiv). Das stimmt mit dem oben gezeigten Eventlog überein.
Was aber bzgl. RA merkwürdig ist: Diese sollten normalerweise von der DG-Gegenstelle an die Multicast-Adresse ff02::1 gesendet werden. In deinem Trace sieht man (Filter icmpv6.type==134 setzen) jedoch ausschließlich unzählige RA-Unicasts an einzelne linklokale Ziele (fe80::...), bei denen die Adresse deiner Fritzbox (s.o.) auch zweimal dabei ist. RA-Unicasts werden normalerweise nur als Reaktion auf vorausgegangene Router-Solicits (RS) gesendet, solche (Filter icmpv6.type==133) sind in dem Mitschnitt aber nicht zu finden. Überhaupt sollten am LAN1-Port, der hier ja als Ersatz-WAN-Port fungiert, nur genau eine MAC-Adresse bzw. die dazu gehörige linklokale IPv6-Adresse sichtbar sein. Es sieht irgendwie so aus, als würdest du auf deiner WAN-Leitung lauter RA sehen, die für andere DG-Kundenanschlüsse gedacht sind.
Die IPv6-Kommunikation beschränkt sich auf den Austausch von ND-Paketen (NS, NA, RA) mit der DG-Gegenstelle (fe80::22). Auch hier auffällig: Du erhältst unzählige Neighbor-Advertisments (NA) als Unicasts an linklokale IPv6-Adressen, die vermutlich nicht zu deinem Anschluss gehören, und die als "solicited reply" geflagt sind, obwohl von deinem Router zuvor keine dazu passenden Neighbor-Solicit (NS) gesendet wurden. Korrekt sind dabei nur die NS/NA-Transaktionen, die dein Router initiiert hat (Filter "(icmpv6.type==135 || icmpv6.type==136) && ipv6.addr==fe80::d624:ddff:febd:b46b" <-- alles zwischen "" kopieren).
Sieht mir irgendwie nach einem Problem auf DG-Seite aus.
Noch zwei Ergänzungen:
Ein Grund für den DHCPv6 Lease-Timeout ist vermutlich, dass die bestehende Lease seitens DG nicht mehr zu verlängern war, weil dein Anschluss andere IPv6-Adressen bekommen sollte: Die neue WAN-Port-Adresse hat als letzte Ziffer anstelle einer 2 nun eine 7. Im LAN-Prefix hat sich eine Ziffer von 5 auf a geändert. In der Regel bekommt man an stabil funktionierenden Anschlüssen stets dieselben Adressen zugewiesen. Bei meinem Anschluss haben die sich bisher nur nach einer DG-Wartung einmal geändert.
Wäre mal interessant zu beobachten, ob dein Router nach jedem Lease-Timeout mit anschließender Neuaushandlung einer Lease geänderte IPv6-Adressen bekommt.
Man sieht ferner, dass dein Router ausgehenden IPv6-Traffic korrekt zur MAC-Adresse 20:00:00:00:10:82 der DG-Gegenstelle routet, nur kommt von da nie was zurück (Ansichtsfilter eth.addr==d4:24:dd:bd:b4:6b && ipv6). Externe IPv6-Zieladressen wurden dabei zuvor über IPv4 aufgelöst. Ausgehende TCP-Verbindungen kommen so über SYN nicht hinaus, DNS- und NTP-Queries bleiben unbeantwortet. Dies ist ein weiteres Indiz für ein Problem auf der DG-Seite.
Und noch eine Ergänzung:
Aus den Ziel-MAC-Adressen der am WAN-Anschluss erhaltenen NA- und RA-Unicast-Pakete lassen sich ja die OUI-Anteile (die ersten 24 Bits, z.B. d4:24:dd) und somit die Hersteller der Geräte, an die das jeweilige Paket gerichtet ist, ablesen (Wireshark zeigt das zweckmäßigerweise gleich mit an). Dabei sind alle RA-Zieladressen (die seltener auftauchen) eine Teilmenge der NA-Zieladressen. Wenn ich letztere auszähle kommen ich auf 55 AVM-Router und 37 Sagemcom-Router (die man von DG als Homerouter beziehen kann). Abzüglich dem eignen (AVM-Router) sieht man hier also fehlgeleitete Pakete von 91 fremden Kundenanschlüssen auf der WAN-Leitung, sofern meine Deutung richtig ist. Dass man die im Trace überhaupt sieht, liegt vermutlich daran, dass das WAN-Interface während des Mitschnitts in den "promiscuous mode" gesetzt wird.
Wenn zwar per DHCPv6 IPv6-Adressen (WAN-Port + LAN-Präfix) zugewiesen werden (auch wenn es offenbar nicht klappt, eine bestehende Lease per DHCPv6-Renew bzw. ggf. auch DHCPv6-Rebind zu verlängern; nach dem Ablauf der Lease wird ja erfolgreich sofort eine neue Lease angefordert), man dann aber nicht auf das Internet via IPv6 zugreifen kann, könnte es daran liegen, dass die DG-Gegenstelle keine Router-Adversements (RA) sendet. Oder es werden zwar RA gesendet, im RA ist die Router-Lifetime jedoch auf "0" gesetzt.
Ein Paket-Mitschnitt am WAN-Port der Fritzbox könnte hier weiterhelfen.
Length: 48 ist hier die Länge der IA_PD-Option und nicht die angeforderte Prefix-Länge - die war 56. Aber vielleicht stören die angeforderten Preferred lifetime: infinity und Valid lifetime: infinity. Denn die wird der DHCPv6-Server ablehnen.
Nachträge:
Immerhin hat es ja geklappt, die beiden DNS-Serveradressen zu bekommen. Wenn ich aber das DHCPv6-Solicit-Paket anschaue und mit meinen Solicit-Paketen (am WAN-Port einer Fritzbox 7590) vergleiche, sind folgende Unterschiede festzustellen:
Mir scheint, dass die Konfiguration nachgebessert werden muss.
Nachtrag 2;
Der folgende Teil der Konfiguration fordert vermutlich eine IPv6-Adresse via SLAAC für das WAN-Interface an:
ipv6 {
address {
autoconf
}
dup-addr-detect-transmits 1
}DG ordnet die WAN-Adresse jedoch per DHCPv6 zu.
Vermutlich wäre stattdessen folgende Konfiguration richtiger:
ethernet eth0 {
address dhcp
address dhcpv6
...Ich kenne Ubiquiti jedoch nicht und weiß daher nicht, ob das Kommando "address dhcpv6" in dieser Form existiert.
Das würde die fehlende IA_NA-Option im DHCPv6-Solicit erklären.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum