Beiträge von ::1

Zitat von themaze

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:

• 2a00:6020:5c80::/41
• 2a00:6020:7380::/41
• 2a00:6020:7680::/41
• 2a00:6020:7800::/41
• 2a00:6020:7880::/41
• 2a00:6020:8f00::/41
• 2a00:6020:9100::/41
• 2a00:6020:9400::/41
• 2a00:6020:9480::/41
• 2a00:6020:9800::/41
• 2a00:6020:9a80::/41
• 2a00:6020:9c80::/41
• 2a00:6020:bb00::/41
• 2a00:6020:c700::/41

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.

Zitat von Phino

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

Zitat von early.camp7097

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).

Zitat von lukas52

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:

Zitat

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):
  1. regedit in die Windows-Suche eingeben und starten.
  2. Navigieren zu: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles.
  3. 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).

Zitat von HubeBube

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.

Zitat von HubeBube

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.

Zitat von HubeBube

Ich vermute mal, dass diese Seite funktioniert: https://test-ipv6.com/

Zitat von lukas52

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.com

Wie konnte also die Seite erreicht werden, wenn IPv4 gar nicht funktioniert (bzw. nur APIPA-Adressen 169.254.x.x. vorhanden sind)?

Zitat von themaze

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.

Zitat von lukas52

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?

Zitat

Ich verstehe deren System nicht.

Siehe hierzu die Hinweise von HubeBube in #10: Ticket via DG Portal offen halten durch den Punkt "Nachfrage zu Ticket #...".

Bei denen ist jedes Ticket immer ein neues Problem ...

Zitat

Ich kann in eine Nachricht im Ticketsystem nicht mal alles Schreiben was ich an Details gesammelt haben und übermitteln möchte. Auch den Packet-Capture kann ich nicht als pcap oder zip sondern nur als Textdatei anhängen.

PDF als Attach werden m.W. akzeptiert: Du kannst das Problem z.B. in einem Word-Dokument ausführlich beschreiben (und den Packet-Capture als Bild dort einfügen, das ist aussagekräftig genug) und dieses als PDF speichern. Im Ticket dann nur eine Kurz-Darstellung mir Verweis auf das PDF.

Lazze : Mit dem DNSsec-Validator (https://dnsviz.net/d/www.glasfaserforum.de/dnssec/) wird mir aktuell folgendes Problem angezeigt:

Mit einem Mouseover auf NSEC3 bekommt man sinngemäß die Diagnose:

"NSEC3 record(s) proving non-existence (NODATA) of glasfaserforum.de/DS"

Es liegt vermutlich daran, dass "glasfaserforum.de" an meinem Windows-PC mit dem dort verwendeten DNSsec-validierenden Resolver unbound zeitweise nicht auflösbar ist (ich muss den unbound-Dienst dann immer stoppen und neu starten ).

Zitat von themaze

In der Tat habe ich ein komplexeres Netzwerk aber nur einen OPNsense Router welcher direkt am Modem hängt mit mehreren Netzwerke. Das mit den Interfaces ist soweit kein Problem bei wechselnden Adressen. Nur Jetzt wo IPv6 ins und vom Internet Tot ist, ist das nervig.

Vielleicht noch ein Hinweis, aber vermutlich muss ich dir das gar nicht erzählen:

Ich würde parallel zu dynamisch zugewiesenen globalen IPv6-Adressen im LAN noch permanent ULA (fd00::/8 -> fdxx:xxxx:xxxx::/48 (xx:xxxx:xxxx auswürfeln) -> LAN1: fdxx:xxxx:xxxx:1::/64, LAN2: fdxx:xxxx:xxxx:2::/64, LAN3: fdxx:xxxx:xxxx:3::/64, ...) verwenden.

Die sind fest und immer verfügbar. Sie werden bei rein LAN-interner Kommunikation bevorzugt genutzt und sind dynamisch in einem lokalen DNS-Server registrier- und somit in einer LAN-internen DNS-Domain komfortabel auflösbar . Voraussetzung ist bei allen Endgeräten allerdings eine aktuelle Default Policy Table (kann man sich unter Windows via netsh int ipv6 show pref anzeigen lassen), die einen Eintrag für fc00::/7 enthält - zur Not muss man diesen von Hand ergänzen, falls das jeweilige System dafür eine Schnittstelle bietet (problematisch bei IOT-Geräten wie Druckern usw., aber die spricht man halt zur Not ausschließlich via IPv4 an)

So könntest du das Inside-Interface deines Proxies (falls "one-armed" ULA als secondary IPv6 address) stets über eine feste ULA adressieren.

Zitat von themaze

Gibt es Business Tarife (von der DG) mit fixen Prefixen für Ottonormalos?

Kann ich nicht sagen - aber DG berät dich hier bestimmt hervorragend bei der Auswahl eines geeigneten Business-Tarifs.
Mir ist jedenfalls nicht bekannt, dass DG gegen einen geringfügigen Aufpreis feste IPv6-Adressen an Privat-Anschlüssen bereitstellt.

Das ist dann wohl das LAN-Interface deines Routers.

Hier das Ping-Ergebnis an meinem DG-Anschluss

Und so sieht es aus Sicht von London und Amsterdam aus:

Aber es bestätigt meine Vermutung aus #11.