Es wäre schön, wenn es etwas mit dem IPv6-Routing zu tun hätte.
Werden wir sehen: Wenn sich nach Störungsende plötzlich alle IPv6-Geschädigten über ein funktionierendes IPv6 freuen können, wird es wohl was damit zu tun gehabt haben.
In der Tat ist eine inzwischen 3 Tage offene Störung m.E. schon ungewöhnlich.
Gibt es eigentlich Ideen was fuer BNGs die DG verwendet?
Das kann sicherlich nur ein Insider sagen.
Ich habe in einem Paketmitschnitt am WAN-Port meines Routers (in einer DHCPv6-Fehlersituation) mal eine DHCPv6-Nachricht von einem anderen (als dem üblichen) DHCP-Server der DG erhalten, dessen MAC-OUI (innerhalb der Server-DUID) auf Cisco-Equipement deutete - aber das sagt vermutlich nichts über die eingesetzten BNGs aus (nämlich dann, wenn diese nur die Rolle eines DHCP/DHCPv6-Relays haben, wovon ich ausgehe) - und die müssen ja auch nicht flächendeckend einheitlich sein.
Ich habe die Ursache des Problems gefunden:
Es hat nichts mit DNSsec zu tun, sondern mit einem Mismatch von "Glue-Records" für den Nameserver "ns3.nshost2.net" in der Parent-Zone "net." für die Delegierung der Zone "nshost2.net."
Die korrekten IPv4/IPv6-Adressen von "ns3.nshost2.net" lauten:
C:\>nslookup -q=A+AAAA ns3.nshost2.net.
Server: localhost
Address: ::1
Nicht autorisierende Antwort:
Name: ns3.nshost2.net
Addresses: 2a0a:4cc0:c1:660:880a:29ff:feb2:ada5
152.53.140.148Frage ich nun aber einen DNS-Server (z.B. "g.gtld-servers.net."), der autoritativ für "net." ist, nach den IPv4/IPv6-Adressen von "ns3.nshost2.net", so erhalte ich falsche Glue-Werte (falsch: 2a01:50c0:1001:1::5:4 statt korrekt 2a0a:4cc0:c1:660:880a:29ff:feb2:ada5 bzw. falsch 89.107.184.91 statt korrekt 152.53.140.148) zurück:
C:\>nslookup -q=A+AAAA ns3.nshost2.net. g.gtld-servers.net.
(root) nameserver = i.root-servers.net
(root) nameserver = j.root-servers.net
(root) nameserver = k.root-servers.net
(root) nameserver = l.root-servers.net
(root) nameserver = m.root-servers.net
(root) nameserver = a.root-servers.net
(root) nameserver = b.root-servers.net
(root) nameserver = c.root-servers.net
(root) nameserver = d.root-servers.net
(root) nameserver = e.root-servers.net
(root) nameserver = f.root-servers.net
(root) nameserver = g.root-servers.net
(root) nameserver = h.root-servers.net
Server: UnKnown
Address: 2001:503:eea3::30
Name: ns3.nshost2.net
Served by:
- ns2.nshost2.de
nshost2.net
- ns1.nshost2.de
nshost2.net
- ns3.nshost2.net
2a01:50c0:1001:1::5:4
89.107.184.91
nshost2.netWarum ist das nun ein Problem?
Die autoritativen Nameserver für die Zone "glasfaserforum.de." sind:
C:\>nslookup -q=NS glasfaserforum.de.
Server: localhost
Address: ::1
Nicht autorisierende Antwort:
glasfaserforum.de nameserver = ns5i.nshost2.net
glasfaserforum.de nameserver = ns4i.nshost2.deUm https://www.glasfaserforum.de auflösen zu können, muss der Resolver also zunächst die IPv4/IPv6-Adressen von ns4i.nshost2.de und/oder ns5i.nshost2.net ermitteln.
Um ns5i.nshost2.net aufzulösen, muss er wiederum einen der autoritativen Nameserver von nshost2.net befragen. Das ist einer der folgenden Nameserver:
C:\>nslookup -q=NS nshost2.net.
Server: localhost
Address: ::1
Nicht autorisierende Antwort:
nshost2.net nameserver = ns1.nshost2.de
nshost2.net nameserver = ns2.nshost2.de
nshost2.net nameserver = ns3.nshost2.netWählt mein Resolver dummerweise den ns3.nshost2.net zur Adressauflösung von ns5i.nshost2.net aus, so erhält er als dessen Adressen aus der Parent-Zone lediglich die falschen Glue-Werte 2a01:50c0:1001:1::5:4 und 89.107.184.91 - von diesen Adressen kommen aber keine DNS-Antworten.
Nach etwa 1 Minute versucht es mein Resolver dann endlich mit einem der beiden anderen Nameserver ns1.nshost2.de bzw. ns2.nshost2.de. Hierfür erhält er von einem autoritativen Nameserver der übergeordneten "de."-Zone (z.B. "f.nic.de") folgende Delegierungsinformationen:
C:\>nslookup -q=NS de.
Server: localhost
Address: ::1
Nicht autorisierende Antwort:
de nameserver = a.nic.de
de nameserver = f.nic.de
de nameserver = l.de.net
de nameserver = n.de.net
de nameserver = s.de.net
de nameserver = z.nic.de
C:\>nslookup -q=A+AAAA ns1.nshost2.de. f.nic.de.
Server: UnKnown
Address: 2a02:568:0:2::53
Name: ns1.nshost2.de
Served by:
- ns1.nshost2.de
89.107.184.116
nshost2.de
- ns2.nshost2.de
89.107.185.20
nshost2.de
- ns3.nshost2.net
nshost2.deHier stimmen zumindest die Glue-Werte für die IPv4-Adressen von "ns1.nshost2.de" (89.107.184.116) und "ns2.nshost2.de" (89.107.185.20) mit den tatsächlichen Adressen dieser beiden Nameserver überein:
C:\>nslookup -q=A+AAAA ns1.nshost2.de.
Server: localhost
Address: ::1
Nicht autorisierende Antwort:
Name: ns1.nshost2.de
Addresses: 2a01:50c0:1001:1::3:4
89.107.184.116
C:\>nslookup -q=A+AAAA ns2.nshost2.de.
Server: localhost
Address: ::1
Nicht autorisierende Antwort:
Name: ns2.nshost2.de
Addresses: 2a01:50c0:1001:1::4:4
89.107.185.20In den Delegierungsinformationen in der Zone "de." fehlen allerdings die IPv6-Adressen von "ns1.nshost2.de" und "ns2.nshost2.de".
Aber immerhin kann mein Resolver über die IPv4-Adressen von "ns1.nshost2.de" und "ns2.nshost2.de" die IPv4/IPv6-Adressen von ns4i.nshost2.de und ns5i.nshost2.net ermitteln und schließlich über deren Adressen "https://www.glasfaserforum.de" auflösen.
Lazze :
Ich würde mich mal freundlich an den/die Admin(s) von "nshost2.net" und "nshost2.de" wenden, um
Gibt es eigentlich Ideen was fuer BNGs die DG verwendet? Vielleicht ist das ja ein bekannter Fehler bei bestimmten BNG Versionen von einem der Ausruester?
Ich würde nicht sagen, dass es am BNG-Cluster liegt, eher an der DG-Infrastruktur "dahinter" (aus Kundensicht), in der das (Rückwärts-) Routing der einzelnen /56-PD-LAN-Präfixe zum "richtigen" BNG-Cluster nicht zu funktionieren scheint (wie im hier vorliegenden Fall).
Ja, wenn eine Anwendung das Prinzip von "Happy Eyeballs, RFC6555" nicht beherzigt, können solche Effekte auftreten.
Solange IPv6 DG-seitig nicht geroutet wird, würde ich dir daher empfehlen, IPv6 LAN-seitig einzuschränken, indem du am Router die RA so konfigurierst, dass nur das ULA-Präfix, nicht jedoch das globale Präfix der DG in deine LAN-Segmente announced wird. Die LAN-Clients können dann keine globalen IPv6-Adressen per SLAAC autokonfigurieren, sondern maximal ULA. Damit sollten die von dir erwähnten Apps dann sofort via IPv4 zugreifen.
Andere Frage: Du ( ::1) bist auch bei der DG soweit ich das verstanden habe, bist aber (noch) nicht von dem Problem betroffen?
Ja, ich bin dort Privat-Kunde seit 10/2021 mit dem "alten" DG-Classic-Tarif (400/200). Die IPv6-Adressierung basiert bei diesen "Alt"-Anschlüssen (noch) nach dem Alt-Konzept, erkennbar daran, dass die Router-WAN-Adresse in 2a00:6020:1000::/48 liegt, und diese, ebenso wie das PD-LAN-Präfix "quasistatisch" sind (die wechselten bei mir nur nach einem Routertausch, sowie ein anderes Mal nach einer DG-Wartung).
IPv6-Nichtverfügbarkeits-Probleme gab es an meinem Anschluss auch schon, allerdings nur für maximal etwa 5 Stunden außerhalb regulärer Wartungszeit bzw. 2 Tage nach einer DG-Wartung (dafür habe ich sogar eine Entschädigung bekommen).
Nach Anzahl der Fälle hier im Forum scheint das IPv6-Nichtverfügbarkeits-Problem vor allem die (neueren) DG-Anschlüsse mit "neuem" IPv6-Adressierungskonzept zu betreffen (erkennbar an: Nach Reconnect häufig wechselnde IPv6-Adressen, Zwangstrennungen (?), Router-WAN-Adresse nicht in 2a00:6020:1000::/48, sondern im ersten /112-Block zu Beginn eines /41-Blocks, der einem BNG-Cluster zugeordnet ist, und aus dem theoretisch bis zu 32767 (Privat-)Kundenanschlüsse bedient werden können [2^(56-41)-1], BNG-Cluster-Adresse taucht in Traceroutes als "fc00::1" auf).
Bisher habe ich folgende /41-Ranges bzw. BNG-Cluster mit neuem IPv6-Adresskonzept in meiner Sammlung:
In einem Teil dieser Ranges liegen so manche Privatkunden-Anschlüsse, deren Inhaber sich hier im Forum mit IPv6-Problemen gemeldet haben.
Es steht zu vermuten, dass die Dunkelziffer recht hoch ist, denn Normal-User mit funktionierendem IPv4 bemerken die Nichtfunktion von IPv6 nicht unmittelbar (Eipivau was? - wieso, das Internet geht doch), höchstens evtl. an gelegentlichen Verzögerungen beim Verbindungsaufbau zu Internet-Services (Stichwort "Happy Eyeballs"), wenn ihrem Anschluss zwar IPv6-Adressen zugewiesen, diese im DG-Infrastruktur-Backend jedoch nicht geroutet werden.
Du kannst es ja auch mal mit/bei "Vorsicht, Kunde!" oder "teltarif hilft" probieren. Derart negative Publicity möchte sicherlich auch eine "Deutsche Glasfaser" vermeiden.
Aber wo müssen sie hin, um physikalisch eindringlich auf das Problem aufmerksam zu machen?
Sternmarsch nach
Deutsche Glasfaser Holding GmbH
Am Kuhm 31
46325 Borken
Es werden zwar noch eine IPv6-Adresse (2a00:6020:9800::xxx/64) und ein IPv6-Präfix (2a00:6020:9841:2a00::/56) zugewiesen, wird aber netzseitig nicht gerouted.
Da kannst du dich mit themaze (siehe dieser Thread) zusammentun, der hängt mit seinem DG-Anschluss am selben BNG-Cluster wie du mit deinem (/56-PD-LAN-Präfixe aus 2a00:6020:9800::/41 = 2a00:6020:9800:100::/56 - 2a00:6020:987f:ff00::/56, WAN-Adressen aus 2a00:6020:9800::/112).
Mir ist auf dem Weg zu der Firewall Einstellungen so viele Aktive private Netzwerke.
Diese Beobachtung wirkt auf mich auch irritierend!
Eine Nachfrage bei Tante Google ("Windows Firewall zeigt mehrere aktive private Netzwerke mit gleichem Namen an") ergab die KI-Antwort:
Wenn die Windows-Firewall mehrere aktive private Netzwerke mit demselben Namen anzeigt (z. B. "Netzwerk 1", "Netzwerk 1"), liegt meist eine fehlerhafte Registrierung von Netzwerkprofilen nach Treiberupdates, VPN-Nutzung oder Adapterwechseln vor . Ein Neustart, das Löschen der Netzwerkprofile über die Registrierung (Registry) oder die Neuinstallation der Netzwerkadapter im Geräte-Manager schafft Abhilfe.
Lösungsmöglichkeiten:
- Netzwerkadapter zurücksetzen: Öffnen Sie den Geräte-Manager, deinstallieren Sie die Netzwerkadapter (WLAN/LAN) und starten Sie den PC neu, damit sie frisch erkannt werden.
- Netzwerkprofile löschen (Registry):
- regedit in die Windows-Suche eingeben und starten.
- Navigieren zu: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles.
- Die dort aufgelisteten Schlüssel (Ordner) können gelöscht werden. Nach einem Neustart wird das Netzwerk neu erkannt.
- Netzwerkverbindungen bereinigen: Deaktivieren Sie nicht benötigte virtuelle Adapter (z. B. von VirtualBox, VMware oder VPN-Software), die als separate Netzwerke erscheinen könnten.
- IP-Stack zurücksetzen: Öffnen Sie die Eingabeaufforderung als Administrator und führen Sie netsh int ip reset aus, gefolgt von einem Neustart.
Diese Schritte führen dazu, dass Windows die Duplikate entfernt und die Netzwerkkonfiguration bereinigt
Ich würde insbesondere mal das Löschen der Netzwerkprofile per Registry durchführen: Also alle "Unterordner/Schlüssel" {...} in der linken Baumstruktur unterhalb "Profiles" löschen:
Grandiose, aber wahrscheinlich unbeliebte Idee: Fritzbox-Einstellungen sichern, Fritzbox dann auf Werkseinstellungen zurücksetzen, dann die Sicherung wieder einspielen könnte helfen.
Das Problem tritt bei mir erst seit einigen Tagen und nur sporadisch an jenen meiner PC auf, auf denen ich den validierenden Resolver unbound verwende. Und es hilft dann immer ein Neustart des unbound-Dienstes, vermutlich weil dadurch dessen Resolver-Cache geleert wird, der zuvor vermutlich einen Sperreintrag (does not exist) für "glasfaserforum.de" enthielt.
Ich würde vermuten, dass das Problem mit jedem validierenden Resolver auftreten könnte, und das sollten heutzutage eigentlich alle Resolver sein, die von Internet-Providern zur Nutzung durch deren Kunden bzw. von den big Playern wie Google u.s.w. für die allgemeine Verwendung bereitgestellt werden.
Ich stecke jetzt fachlich nicht so tief im DNSsec, aber ich deute die Situation so, dass die NSEC3-Einträge in der de-Domain die Nicht-Existenz der Child-Domain "glasfaserforum.de" behaupten. Andererseits nutzt "glasfaserforum.de" selbst kein DNSsec (vielleicht einführen?). Wie da genau die Regeln der Delegierung von signierten Parent- (de) zu nicht-signierten Child-Zonen (glasfaserforum.de) aussehen müssen, damit validierende Resolver bzw. deren Nutzer keine Probleme bekommen (sprich ein NXDOMAIN zurückgeben bzw. erhalten), vermag ich an dieser Stelle auch nicht zu sagen.
Wie groß ist denn der DHCP-Pool in der Fritzbox? (von: ? bis ?)
Als würde der DHCP-Server der Fritzbox per DHCP NAK die angeforderte/erneuerte IPv4-Adresse ablehnen ...
Also ich hätte zu Analyse eine Idee, ist aber leider etwas aufwändig:
Man würde sich wünschen, man könnte per Wireshark den Netzwerk-Traffic während der Netzinterface-Initialisierung (LAN oder WLAN) mitschneiden. Das ist leider so nicht möglich.
Aber es funktioniert mit folgendem Trick (aber sehr aufwändig):
Installiere dir auf einem betroffenen Windows-PC eine virtuelle Maschine (z.B. mittels "Virtualbox") mit Windows und konfiguriere den virtuellen LAN-Adapter der VM in "Bridge-Modus" (verbunden mit dem LAN- oder WLAN-Adapter auf dem Windows-Host).
Jetzt kannst du auf dem Windows-Host einen Wireshark-Mitschnitt starten (entweder für den LAN- oder WLAN-Adapter, ja nachdem, welchen die VM nutzt) und die VM hochfahren. Dann siehst du im Mitschnitt anschließend den gesamten Initialisierungs-Traffic des virtuellen VM-Adapters, woraus man im besten Fall erkennen könnte, wo das Problem liegt (erfordert allerdings tiefes Netzwerk-Know-how).
Da ist das Setup im höchsten Maße strubbelig.
Eigentlich nicht, er bekommt nur keine IPv4-Adressen via DHCP, und es wäre zu klären, warum die Windows-Clients den DHCP-Server der FB nicht erreichen, bzw. dieser die DHCP-Requests der Windows-Clients nicht beantwortet.
Ich habe ja immer noch eine falsche WLAN-Konfiguration im Verdacht, deswegen wäre interessant, an einem Windows-Client das WLAN mal abzuschalten und ihn per LAN-Kabel direkt an die FB anzuschließen.
Die IPv6 DNS Server sind nämlich nicht die von Deutsche Glasfaser sondern eigene im Heimnetz:
DNSServer : fd3f:347a:fd1f:0:ab6:57ff:fe8c:2df2
2a00:6020:461b:a300:ab6:57ff:fe8c:2df2
Ja, das ist doch normal: Eine FB gibt immer sich selbst als DNS-Server an die LAN-Clients bekannt. Sie arbeitet schließlich als DNS-Proxy/Forwarder. Nur sie selbst verwendet die in ihr konfigurierten Resolver (z.B. die von DG) zur DNS-Weiterleitung.
Ich vermute mal, dass diese Seite funktioniert: https://test-ipv6.com/
ja genau die Seite funktioniert.
Das erstaunt mich, denn "test-ipv6.com" ist ausschließlich über IPv4 erreichbar [Begründung]
C:\>nslookup -q=A test-ipv6.com
Server: localhost
Address: ::1
Nicht autorisierende Antwort:
Name: test-ipv6.com
Address: 139.162.169.184
C:\>nslookup -q=AAAA test-ipv6.com
Server: localhost
Address: ::1
Name: test-ipv6.comWie konnte also die Seite erreicht werden, wenn IPv4 gar nicht funktioniert (bzw. nur APIPA-Adressen 169.254.x.x. vorhanden sind)?
Langfristig macht das alleine Finanziell Sinn, vielleicht endet es ja in einer Sonderkündigung und einem Wechsel.
1&1 macht, wenn ich nicht irre, aber DS-Lite over PPPoE - das muss dein Router dann können.
Würde ich auch so sehen aber was mich stutzig macht, dass es jetzt echt lange alles geklappt hat und plötzlich auf allen Windows PC's im Netzwerk die Probleme sind
Sind die Windows-PC über LAN oder WLAN angebunden? Falls über WLAN, kannst du es mal testweise für einen dieser PC mit Anbindung über LAN-Kabel versuchen?
Falls über WLAN: Hast du evtl. ein anderes Gerät im Netz, das als WLAN-Station (aber ohne DHCP-Serverfunktion) dient, und das dummerweise dieselbe SSID verwendet wie die Fritzbox?
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