Deutsche Glasfaser + Routerwechsel (Bintec) + kein IPv6

Hallo Forum,

nach einem Routerwechsel (jeweils kundeneigener Router) am Anschluss der Deutschen Glasfaser erhält der neue Router kein IPv6 Präfix bzw. Adressen. Die IPv4 Konnektivität hingegen funktioniert. Alter Router (Bintec be.IP) und neuer Router (Bintec RS123) sind identisch konfiguriert.

Scheinbar akzeptiert der DHCPv6 Server den neuen Router (bzw. dessen neue DUID) nicht. Man munkelt ja hier und da von einer „One Device Policy“ des Providers…

Was kann man tun?

Nachfolgend noch ein paar Einträge aus dem Log des Routers. Neben den darin gelisteten „No IA_NA-opt in Reply“ gibt es zeitweise auch noch „No IA_PD-opt in Reply“.

1 2021-12-05 17:40:14 Error INET6 DHCPv6-client(en1-4): No IA_NA-opt in reply
2 2021-12-05 17:40:14 Error INET6 DHCPv6-client(en1-4): Received status: 3
1 2021-12-05 17:38:43 Information INET6 DHCPv6-client(en1-4): Sending Request-messages
2 2021-12-05 17:38:42 Information INET6 DHCPv6-client(en1-4): Sending Solicit-messages
3 2021-12-05 17:38:42 Information INET6 DHCPv6-client(en1-4): Starting
4 2021-12-05 17:38:42 Information INET6 DHCPv6-client(en1-4): Stopping
5 2021-12-05 17:38:42 Error INET6 DHCPv6-client(en1-4): Max number of Request-transmissions exceeded
6 2021-12-05 17:35:52 Information INET6 DHCPv6-client(en1-4): Sending Request-messages
1 2021-12-05 17:34:53 Error INET6 DHCPv6-client(en1-4): No IA_NA-opt in reply
2 2021-12-05 17:34:53 Error INET6 DHCPv6-client(en1-4): Received status: 1
3 2021-12-05 17:34:53 Error INET6 DHCPv6-client(en1-4): No IA_NA-opt in reply
4 2021-12-05 17:34:53 Error INET6 DHCPv6-client(en1-4): Received status: 1
5 2021-12-05 17:34:51 Information INET6 DHCPv6-client(en1-4): Sending Solicit-messages
6 2021-12-05 17:34:51 Information INET6 DHCPv6-client(en1-4): Starting
7 2021-12-05 17:34:38 Information INET6 NDISC: <en1-4>: Looking for routers
8 2021-12-05 17:34:38 Information INET6 NDISC: <1040000>: [fe80::2a0:f9ff:fe6a:4da6]: Auto-config succeeded (no conflicts detected)
9 2021-12-05 17:34:35 Information INET6 Interface <en1-4> becomes 'routable'

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 1607161510

Url: https://administrator.de/contentid/1607161510

Ausgedruckt am: 22.11.2024 um 02:11 Uhr

20 Kommentare

Neuester Kommentar

Scheinbar akzeptiert der DHCPv6 Server den neuen Router (bzw. dessen neue DUID) nicht.

Das könnte man rausfinden, indem man (ggf. entgegen des Protokoll) die alte DUID im neuen DHCPv6-Client nutzt. Wäre zumindest für den Test interessant.
Sonst: Ticket beim Provider aufmachen und den Fall schildern. Ist ja eigentlich so nicht gewünscht.

Das ist bei der DG fast Normalzustand, der DHCPv6 bei denen ist ziemlich lahm und regiert oft erst nach 5-10 Minuten wenn die MAC des Devices sich geändert hat mit einer Antwort. Abhilfe schafft oft ein aus- und einschalten des NT.

@Windows10Gegner
Ich habe leider noch keine Möglichkeit gefunden, im RS123 die DUID des Clients zu ändern. Ist das bei dem Gerät denn möglich, ggf via SNMP Ansicht?

Ticket ist bereits erstellt (mit detaillierter Fallschilderung inklusive vermuteter Ursache etc) mit Bitte um Weiterleitung in die Fachabteilung. In der Hoffnung, dass der 1st Level Support das nicht abwimmelt.

@149569
Für den DHCPv4 Server war es erforderlich, den alten Router zunächst vom ONT zu trennen und dem neuen erst nach einer Stunde anzuschließen. Ohne diese Unterbrechung gab es keine IPv4 für den neuen Router ;)

Bzgl DHCPv6 hat sowohl diese Stunde Trennung vom ONT, also auch 24 Stunden DHCPv6 Client deaktivieren als auch ONT für 1 Minute vom Strom trennen nicht geholfen

Hast du denn überhaupt Port 546 UDP eingehend in der Firewall am WAN für die Source fe80::/10 mit HopLimit 255 geöffnet? Diese Freigabe ist für die Funktionalität von DHCPv6 zwingend erforderlich, da die Antworten stateless vom DHCPv6 Server am WAN eintreffen.
Das würde ich auf jeden Fall als erstes kontrollieren.

Nur zur Info, bin selbst bei der DG, und an meinem Standort steigt seit zwei drei Tagen die IPv6 Verbindung laut log auch immer mal wieder für 5-10 Minuten aus. Die machen ja gerne mal unangekündigte Wartungen und verhunzen dabei oft Einstellungen so mein Gefühl.

@149569
Bist du dir da sicher mit dem UDP 546 eingehend? Am alten Router war nämlich keine solche Freigabe in der Firewall erforderlich…

Deaktiviere doch mal temporär die FW oder lasse alles, was Multicast ist, explizit durch. Aktiviere zudem Logging und schaue, ob die FW ein entsprechendes Paket blockiert.

Zitat von @B787zzz:
@149569
Bist du dir da sicher mit dem UDP 546 eingehend? Am alten Router war nämlich keine solche Freigabe in der Firewall erforderlich…

Absolut zu 100% !! Schau dir einfach mal das DHCPv6 Protokoll an dann weist du wieso! Die meisten Plaste-Elaste-Router zeigen diese Firewall-Regel oft nur dem User nicht an weil sie diese im Background schon für den User anlegen, damit dieser sich damit nicht auseinandersetzen muss weil er meistens eh keine Ahnung davon hat. Auch eine pfSense versteckt diese Regel vor dem User, wenn man sich aber die Regeln auf der Konsole mit pfctl man anzeigen lässt dann siehst du diese.
Trotzdem sollte man sicherstellen das der Port auch wirklich offen ist. Dieser muss wie gesagt nur für ein Hoplimit von 255 angelegt sein (kann also nicht geroutet werden) und für eine fe80::/10 source address (gilt also nur für Hosts aus der link local area des Providers)

Guckst du hier die versteckten Regeln bei einer pfSense

Bist du dir da sicher mit dem UDP 546 eingehend?

Ganz sicher ! Kollege @149569 hat da Recht. Das ist DHCPv6 und musst du bei einem Cisco_Router in dessen Firewall auch zwingend machen ! Ansonsten scheitert die Prefix Delegation auf dem WAN Port.
ipv6 access-list ALLOWv6
sequence 10 permit udp any eq 547 any eq 546

@Windows10Gegner @149569
Mit aktivierter Firewall sehe ich keine geblockten 546/547 Pakete im Log...

Habe trotzdem die IPv6 Firewall mal komplett ausgeschaltet fürs WAN Interface, da ändert sich aber nichts... Weiterhin gleiche Einträge im Log ("no IA_NA-opt in reply", "no IA_PD-opt in reply") und kein IPv6.

Oder wieviel "Zeit" sollte ich dem ganzen mit deaktivierter Firewall geben, bis ggf. die Prefix Delegation ausgeführt wird?

Noch eine andere Idee, um die Ursache einzugrenzen:
Man könnte ja testweise mal einen Windows10 Client direkt an den ONT hängen, um zu schauen, ob dieser IPv6 Konnektivität erhält. Wären hierfür besondere Schritte erforderlich außer:

- 1 Stunde warten zwischen Trennung bisheriger Router und Anschluss Windows10 Client
- LAN Interface IPv4 und IPv6 auf DHCP Client stellen

Denn wenn dieser dann auch keine IPv6 bekommt würde das ja die "One Device Policy" als Ursache des Problems untermauern...

Wenn ich hier an meinem Mikrotik am WAN die MAC/DUID ändere dauert es keine 10 Minuten bis ich vom DHCP der DG eine neue Lease erhalte, häng dich einfach mal per Wireshark an den WAN. Früher ging es auch mal Instant, aber seitdem die da mal wieder ein Update gefahren haben ist es mit der Lease-Vergabe nachvollziehbar schlimmer geworden. Sowas wie eine dauerhafte One-Device Policy gibt es bei der DG nicht, wäre je bei Routerwahlfreiheit auch Blödsinn.
Entweder dein NT ist hinüber oder arbeitet mit einer veralteten Firmware.
Jepp häng dich mal mit nem Lappi direkt an den NT und mach immer mal wieder ein renew.

Auf die Nokia ONTs kommt man auch via Telnet wenn man die Glasfaser vom NT absteckt und sie neu startet. Da würde ich dann mal die Firmware-Version notieren.

@149569
Also scheinbar hat mein Anschluss da ein anderes Setup: Nach mehr als 15 Minuten und mehreren /renew hat die Windowskiste immer noch keine IP (weder v4, noch v6) bekommen. Also nächster Versuch: Router vom ONT trennen, eine Stunde warten, Notebook dran hängen (die Stunde war beim Routerwechsel auch erforderlich damit es wenigstens eine v4 gibt).

Mist, nach einer Stunde "Trennung" erhält das Notebook wie erwartet eine IPv4 und nach einigen "ipconfig /renew6" wider Erwarten auch eine IPv6 (2a00:6020:xxxx). Also ist doch der Router das Problem. Schade.

Zitat von @B787zzz:

Mist, nach einer Stunde "Trennung" erhält das Notebook wie erwartet eine IPv4 und nach einigen "ipconfig /renew6" wider Erwarten auch eine IPv6 (2a00:6020:xxxx). Also ist doch der Router das Problem. Schade.

Mach doch mal einen Wireshark Trace damit man sehen kann was der Router so in den Äther blässt und ob er die Anfrage für eine IA_NA (Adresse für den Router) und IA_PD (Prefix) als einzelne oder gemeinsame Nachricht verschickt.
Das separate Verschicken mag der DHCP der DG wohl nicht so gerne, weiß der Geier warum die da so einen Müll einsetzen und sich nicht an Standards halten...
Braucht man nur mal DG-TV ansehen, da produzieren die genau so einen Müll der nicht funktioniert.

@149569
Hab da mal was rausgefischt... Wenn ich das richtig interpretiere:
- Wird beim Advertise ein richtiges Präfix sowie Nameserver übermittelt
- Ist die Option "64" beim Solicit und Request vielleicht das Problem? DG ist doch gar kein "Dual Stack Lite"...

### Request
Option Request
    Option: Option Request (6)
    Length: 6
    Requested Option code: DNS recursive name server (23)
    Requested Option code: Identity Association for Prefix Delegation (25)
    Requested Option code: Dual-Stack Lite AFTR Name (64)
Identity Association for Prefix Delegation
    Option: Identity Association for Prefix Delegation (25)
    Length: 41
    IAID: 00000001
    T1: 0
    T2: 0
    IA Prefix
        Option: IA Prefix (26)
        Length: 25
        Preferred lifetime: infinity
        Valid lifetime: infinity
        Prefix length: 56
        Prefix address: ::

### Advertise
DNS recursive name server
    Option: DNS recursive name server (23)
    Length: 32
     1 DNS server address: 2a00:6020:100::1
     2 DNS server address: 2a00:6020:200::1
Identity Association for Prefix Delegation
    Option: Identity Association for Prefix Delegation (25)
    Length: 41
    IAID: 00000001
    T1: 1800
    T2: 2880
    IA Prefix
        Option: IA Prefix (26)
        Length: 25
        Preferred lifetime: 3600
        Valid lifetime: 3600
        Prefix length: 56
        Prefix address: 2a00:6020:xxxx:xxxx::

### Solicit
Option Request
    Option: Option Request (6)
    Length: 6
    Requested Option code: DNS recursive name server (23)
    Requested Option code: Identity Association for Prefix Delegation (25)
    Requested Option code: Dual-Stack Lite AFTR Name (64)
Identity Association for Prefix Delegation
    Option: Identity Association for Prefix Delegation (25)
    Length: 41
    IAID: 00000001
    T1: 0
    T2: 0
    IA Prefix
        Option: IA Prefix (26)
        Length: 25
        Preferred lifetime: infinity
        Valid lifetime: infinity
        Prefix length: 56
        Prefix address: ::	
Rapid Commit
    Option: Rapid Commit (14)
    Length: 0

Zitat von @B787zzz:

@149569
Hab da mal was rausgefischt... Wenn ich das richtig interpretiere:
- Wird beim Advertise ein richtiges Präfix sowie Nameserver übermittelt
- Ist die Option "64" beim Solicit und Request vielleicht das Problem? DG ist doch gar kein "Dual Stack Lite"...

Wenn der Router auf eine AFTR Adresse besteht und deswegen das Advertisement nicht annimmt dann musst du deinem Router das konfigurieren das er keine DualStack Lite (AFTR) Anfrage senden soll.
Ergo ist deine Router Konfigurationen schuld an der Misere da ja das Advertisement mit korrekten Daten bei ihm ankommt.

An der Request - Option 64 liegt es definitiv nicht, denn die macht eine be.IP plus bei meinem Kunden auch und es läuft trotzdem.

Zitat von @Kalle2013:

An der Request - Option 64 liegt es definitiv nicht, denn die macht eine be.IP plus bei meinem Kunden auch und es läuft trotzdem.

Wenn der Bintec aber so konfiguriert wäre das er einen AFTR-FQDN erhalten muss und deshalb den Prefix nicht annimmt dann wäre das schon ein Grund, deswegen der Hinweis nachzusehen ob es diesbezüglich eine Config-Option gibt.