Beiträge von ::1

  • Mal wieder: Kein IPv6 bei Deutsche Glasfaser

    Zitat von TecCreator

    Um so weniger will es mir einleuchten, dass DG es nicht einfach "fixt", sondern stattdessen lieber mit seinem Kunden vor Gericht zieht.

    Die Probleme treten ja vor allem (wenn nicht sogar ausschließlich) bei Kundenanschlüssen an DG-BNG-Clustern auf, an denen die DG ein geändertes IPv6-Adresskonzept einführt (vgl. meine Ausführungen in #30). Mein DG-Anschluss nach "altem" IPv6-Adresskonzept, den ich seit etwa 4,5 Jahren nutze, läuft hingegen hochgradig stabil - da habe ich keinen Grund zur Klage. Und ich vermute, das gilt auch für alle Bestandsanschlüsse mit "altem" IPv6-Adresskonzept.

    Es ist bei einigen bezüglichen Fällen hier im Forum zu beobachten, dass IPv6 an diesen Anschlüssen irgendwann (nach einigen Wochen/Monaten) dann doch funktioniert.

    Mir scheint dahinter ein strukturelles Problem im Backend der DG zu stehen, das dazu führt, dass man Problemfälle einzelner Kunden nicht zeitnah und kundenspezifisch beseitigen kann - worin es besteht, darüber kann man freilich nur spekulieren.

    Man stelle sich nun vor, DG würde das strukturelle Backend-Problem mit IPv6 öffentlich zugeben - die (berechtigten) Regress-Anforderungen betroffener Kunden könnten eine derart große wirtschaftliche Bedrohung darstellen, dass man lieber die Kündigung einzelner Kundenanschlüsse oder gar die Prozesskosten von Streitfällen in Kauf nimmt. Und man scheint ja auch darauf zu setzen, dass die meisten Kunden das Problem aus Unkenntnis ohnehin nicht bemerken, da diese mit ihrem immerhin funktionierenden IPv4 noch alle Internet-Ressourcen von Relevanz uneingeschränkt nutzen können. Es betrifft ja "nur" ein paar Freaks, die gerne Inbound-Connections via IPv6 realisieren möchten. Der Kollateral-Schaden hält sich damit in Grenzen.

    Selbst die Bundesnetzagentur scheint ihnen gemeldete Kundenklagen über die Nichtverfügbarkeit des lt. AGB/Leistungsbeschreibung zugesagten IPv6 nicht sonderlich ernst zu nehmen, solange die Anschluss-Geschwindigkeit passt und das Internet (via IPv4) nutzbar ist.

  • Mal wieder: Kein IPv6 bei Deutsche Glasfaser

    Zitat von flamy

    Bin selbst seit ca. einem Monat bei 1und1 über den Anschluss von DG, Umstellung lief super und ich habe sogar eine wechselnde öffentliche ipv4 sowie funktionierendes ipv6

    Zitat von pufferueberlauf

    *) I1&1 setzt da auf ds-lite und ds-lite geht nur mit funktionierendem IPv6

    Wie passen diese beiden Aussagen zusammen?

    Mit DS-Lite hat man weder eine öffentliche, noch eine private (aus 100.64.0.0/10) IPv4-Adresse, sondern gar keine.

  • DNSsec-Validierung von "www.glasfaserforum.de" zeigt Probleme!

    Ein Teilerfolg:

    Das erste Problem (net. --- AAAA glue mismatch ---> nshost2.net.) wurde nun offenbar behoben - Applaus! :


    Für die noch ausstehende Beseitigung des 2. Problems (de. --- missing AAAA glue ---> nshost2.de.) gäbe es noch einen Extra-Applaus:


    Zur Erinnerung:

    "ns1.nshost2.de", "ns2.nshost2.de" und "ns3.nshost2.net" sind autoritativ für die DNS-Zonen "nshost2.de" und "nshost2.net" und werden benötigt, um die IPv4/IPv6-Adressen der beiden Nameserver "ns4i.nshost2.de" und "ns5i.nshost2.net" zu ermitteln, die ihrerseits autoritativ für die DNS-Zone "glasfaserforum.de" sind.

  • Deutsche Glasfaser IPv6 Routing Problem

    Zitat von themaze

    Ist das jetzt gut oder nicht so, dass fast jeder zweite "Deutsche Glasfaser" im Namen trägt ^^ .

    Immerhin lässt sich zu der Liste sagen, dass es sich (bis auf eine Ausnahme) bei den zugehörigen DG-Anschlüssen um solche nach "altem" Adresskonzept handelt und diese bzgl. Nichtverfügbarkeit von IPv6 keine Auffälligkeiten zeigen.

    Die eine Ausnahme ist Probe #1001325, die an einem DG-Anschluss nach "neuem" Adresskonzept (am BNG-Cluster für den Range 2a00:6020:c700::/41) hängt. Da wechseln die IPv6-Adressen relativ oft (d.h. rollieren durch den genannten /41-Range). Ansonsten scheint IPv6 an diesem Anschluss aber einwandfrei zu funktionieren.

  • Deutsche Glasfaser IPv6 Routing Problem

    Zitat von themaze

    Ich tracke seit dem IPv6 Debakel jetzt meinen Anschluss mit Pings zu Google alle 30 Sekunden, sodass ich ausfälle recht genau deuten kann mittels HomeAssistant

    Falls du Interesse hast: Beschaffe dir doch eine RIPE-Atlas-Probe (ich habe auch eine am Laufen). Damit bekommst du eine wunderschöne Datenbasis für den Test-Traffic, den die Probe generiert und kannst anhand der "Results" insbesondere zu den "Built-ins (v4)" und "Built-ins (v6)" (das sind jeweils die IPv4- und IPv6-Adressen der DNS-Root-Server) über die gesamte Laufzeit der Probe die Nichtverfügbarkeitszeiten von IPv6 und/oder IPv4 sehen.

    Zur Illustration hier mal die Sammlung von "public" Probes (mit Status "Connected") an DG-Anschlüssen (AS=60294) - Auswahl einer Probe anhand ihrer "ID" in der ersten Spalte.

  • Mal wieder: Kein IPv6 bei Deutsche Glasfaser

    Zitat von DeeJot

    Vermutlich muss ich wohl tatsächlich das SEPA-Mandat entziehen und auf manuelle (Teil-)Zahlung umstellen.

    Ja, leider wirkt bei denen nur die harte Methode - du hast Anspruch auf Entschädigung für den Zeitraum, in dem dir die per AGB/Leistungsbeschreibung zugesicherte Leistung (IPv6), für die du bezahlst, nicht geliefert wird.

    Wenn du eine Alternative hast, z.B. Wechsel zu 1&1 über die DG-Glasfaser, könntest du auch eine Kündigung androhen.

  • Webserver-Wechsel ist fertig

    Zitat von Lazze

    IPv6 haben wir soeben aktiviert!

    Leider muss ich einen Wermutstropfen hinzufügen: Mit dem Härtetest eines IPv6-only-Clients erreicht man das Forum leider nicht:

    Die Begründung ist in diesem Thead (#4, #6) nachzulesen.

    Das habe ich an meinem Windows-PC zwecks Test durchgeführt:

    • Cache des Web-Browsers geleert, Browser beendet.
    • In der LAN-Konfiguration des LAN-Adapters IPv4 deaktiviert.
    • DNS-Cache des Betriebssystems geleert (ipconfig /flushdns)
    • DNS-Cache meines unbound-Resolvers durch Dienst-Neustart geleert: (net stop unbound, net start unbound)
    • Web-Browser gestartet und https://www.glasfaserforum.de aufgerufen - Resultat: siehe oben.

    Noch ein Nachtrag:

    Falls jemand diesen Befund verifizieren möchte: Wenn man nur den Stub-Resolver des PC (also den mit dem Betriebssystem gelieferten) verwendet, der seinerseits direkt oder indirekt die DNS-Resolver des jeweiligen Providers oder der Big Player verwendet, wird das Problem nicht auftreten, da die Tausende/Millionen Mitnutzer dieser Resolver dafür sorgen, dass die relevanten IPv4- und IPv6-Adressen (von https://www.glasfaserforum.de und allen DNS-Nameserven, die man in Zwischenschritten befragen muss) stets in deren Cache zu finden sind. Das Problem wäre dort nur sichtbar, wenn alle DNS-Clients (inklusive der Resolver der ISPs und Big Playern) dieser Welt ebenfalls nur IPv6-only sprechen würden.

  • Mal wieder: Kein IPv6 bei Deutsche Glasfaser

    Zitat von DeeJot

    Für mich sieht das aus wie "Fritzbox gibt Lebenszeichen per v6 und bekommt garnix". Ist das richtig interpretiert?

    Da würde ich zustimmen.

    Als Besitzer eines DG-Mietrouters sollte es doch aber ein Leichtes sein, der DG per Ticket (immer alles schriftlich, Anrufe vermeiden) einfach einen Screenshot des Fritzbox-Web-GUI "Internet | Online-Monitor | Verbindungsdetails" zu schicken und zu argumentieren:

    "Seht her, hier leuchtet nur die IPv4-Lampe grün, die IPv6-Lampe ist und bleibt seit (Datum des ersten Tickets mit der Problemmeldung) grau. Für die (Fern-)Konfiguration des Mietrouters seid ihr (DG) zuständig - ich hätte als Entschädigung gerne anteilig für die Anzahl der Tage ohne IPv6 die Hälfte des Monatsbeitrags erstattet bekommen."

  • DNSsec-Validierung von "www.glasfaserforum.de" zeigt Probleme!

    Die Website https://wintelguy.com/dns-report.pl bietet eine DNS-Analyse und bestätigt meine Findings:

    DNS-Zone nshost2.net:

    Das Bild zeigt im oberen Teil die Delegierungs-Informationen der Parent-Zone "net." (ermittelt über deren autoritativen Nameserver "g.gltd-servers.net.") für die Child-Zone "nshost2.net."

    Im unteren Teil werden die autoritativen Nameserver der Child-Zone "nshost2.net." gelistet.

    Während die unteren A-RR und AAAA-RR für den Nameserver "ns3.nshost2.net." korrekt sind (aus autoritativer Quelle ermittelt), weist die Parent-Zone "net." falsche Glue-Records für "ns3.nshost2.net." auf.

    Die korrekten Adressen von "ns3.nshost2.net." kann ein Resolver hier nur dank der Nameserver "ns1.nshost2.de." bzw. "ns2.nshost2.de." ermitteln, da diese ebenfalls autoritativ für die Child-Zone "nshost2.net." sind.


    DNS-Zone nshost2.de:

    Das Bild zeigt im oberen Teil die Delegierungs-Informationen der Parent-Zone "de." (ermittelt über deren autoritativen Nameserver "n.de.net.") für die Child-Zone "nshost2.de."

    Im unteren Teil werden die autoritativen Nameserver der Child-Zone "nshost2.de." gelistet.

    Während die Glue-Records (A-RR) für beide Nameserver "ns1.nshost2.de." und "ns2.nshost2.de." korrekt in der Parent-Zone "de." vorhanden sind, fehlen dort hingegen die Glue-Records für deren IPv6-Adressen (AAAA-RR). Das ist derzeit zwar nur "unschön", solange fragende DNS-Resolver IPv4 und IPv6 sprechen können. Für einen IPv6-only DNS-Resolver wäre das allerdings fatal.

  • Deutsche Glasfaser IPv6 Routing Problem

    Zitat von tobix

    Bei mir steht bei jedem Login ins Kundenportal dran, dass aktuell Wartungsarbeiten durchgeführt würden...

    Ja, das scheint ein Bug im Kundenportal zu sein - wird bei mir auch immer angezeigt (seit gefühlt 1 Jahr), auch in Zeiten ohne Wartung.

    Aber eine Störung (ungeplant/jederzeit), wie im vorliegenden Fall ist keine Wartung (geplant, meist nachts, mit Vorankündigung per Mail an betroffene Kunden).

  • Deutsche Glasfaser IPv6 Routing Problem

    Zitat von pufferueberlauf

    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.

  • DNSsec-Validierung von "www.glasfaserforum.de" zeigt Probleme!

    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:

    Code
    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.148

    Frage 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:

    Warum ist das nun ein Problem?

    Die autoritativen Nameserver für die Zone "glasfaserforum.de." sind:

    Code
    C:\>nslookup -q=NS glasfaserforum.de.
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
glasfaserforum.de       nameserver = ns5i.nshost2.net
glasfaserforum.de       nameserver = ns4i.nshost2.de

    Um 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:

    Code
    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.net

    Wä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:

    Hier 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:

    In 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

    • in der Parent-Zone "net." die Glue-Records für ns3.nshost2.net. korrigieren zu lassen.
    • in der Parent-Zone "de." Glue-Records für die IPv6-Adressen (AAAA) von ns1.nshost2.de und ns2.nshost2.de ergänzen zu lassen.

  • Deutsche Glasfaser IPv6 Routing Problem

    Zitat von pufferueberlauf

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

  • Deutsche Glasfaser IPv6 Routing Problem

    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.

  • Deutsche Glasfaser IPv6 Routing Problem

    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.