Beiträge von ::1

  • Kein Traffic über IPv6 möglich (Deutsche Glasfaser)

    Ich will jetzt nicht belehrend wirken, aber einige Punkte deiner Darstellung sind nicht so ganz eindeutig oder ein Fehler:

    Zitat

    3. Gateway fe80::22 (MAC: 20:00:10:38:40:93) leitet KEINE Pakete weiter

    Kann sein (in ausgehender Richtung zum Internet). Möglich ist aber auch, dass das Gateway deine ausgehenden Daten zum Internet-Ziel weiterleitet, aber die Antworten vom jeweiligen Internet-Server zwar bis zum AS60294 der DG zurück gelangen, im Netz der DG aber nicht zu deinem BNG/Anschluss zurück geroutet werden.

    Zitat

    5. Ständige Neighbor Solicitation-Wiederholungen

    Das ist kein Fehler.

    Zitat

    Das Gateway antwortet auf Neighbor Discovery, aber routet keine Pakete.
    Dies ist ein BNG/ONT-Konfigurationsproblem, NICHT ein Router-Problem.

    wie oben (5.) Es ist vermutlich auch kein BNG/ONT-Problem, sondern ein (Rückwärts-)Routing-Problem innerhalb des DG-Netzes (aus deiner Sicht "hinter" dem BNG)

    Nachtrag:

    Insbesondere wäre auch der /64 als PD-LAN-Präfix zu monieren (sollte doch wohl ein /56 sein), und die extrem kurzen Leasedauern von nur 10min für WAN-IPv4 und WAN-IPv6/PD-LAN - das ist nicht normal.

  • Kein Traffic über IPv6 möglich (Deutsche Glasfaser)

    sh0rty :

    Habe deinen Paketmitschnitt angeschaut.

    Ergebnisse:

    • Deine Router-WAN-Adresse ist vermutlich von außen erreichbar - ich konnte es allerdings nicht verifizieren. Möglicherweise, weil dein WAN-Interface keine Pings beantwortet, oder weil die WAN-Adresse aus dem Paketmitschnitt nicht mehr aktuell ist.
    • Dein LAN-Präfix scheint hingegen in der DG-Infrastruktur nicht zu dem BNG geroutet zu werden, an dem dein Anschluss hängt. Folgen: Dein LAN ist von außen nicht erreichbar und ausgehender IPv6-Traffic zu Internet-Zielen wird von denen sicherlich beantwortet, gleichwohl "versacken" die Antworten in der DG-Infrastruktur, weil sie dort eben nicht zu deinem BNG/Anschluss geroutet werden. Sämtliche Pings zu "dns.nextdns.io", die du gesendet hast, bleiben also unbeantwortet.

    Ansonsten sehr ungewöhnlich:

    Du bekommst für's LAN nur einen PD-Block der Größe /64 - üblich wäre ein /56. Auch sind die Leasedauern für WAN-Adresse und LAN-Präfix mit 600s (10min) extrem kurz, so dass sie alle paar (5) Minuten per DHPv6-Renew erneuert werden müssen.

    DHCPv6-Verlauf und RS/RA (Router lifetime = 4500s, M-Flag gesetzt) sind soweit normal, da gäbe es nichts zu beanstanden - allenfalls, dass das erste (und im Mitschnitt einzige) RA erst nach 16s zu sehen ist, nachdem dein Router 4 RS im Abstand von 4s gesendet hat.

    Nachtrag:

    • In deinem LAN scheint es ein Gerät zu geben, das 1x pro Sekunde einen Ping auf 10.8.0.1 absetzt - solche Pings Richtung Internet sind natürlich sinnlos.
    • Auch bei IPv4 ist die DHCP-Leasedauer für die WAN-IPv4-Adresse mit 600s (10min) gleich kurz wie bei DHCPv6/IPv6.

  • Deutsche Giganetz + eigener Fritzbox 7530AX Router + Windows VPN Client IKEv2

    Seid ihr hier nicht ein wenig auf dem Holzweg?

    Wenn über die Fritze nur die VPN-Verbindung sporadisch nicht aufgebaut werden kann, man ansonsten aber auf das Internet zugreifen kann - dann sollte bei der D.Giga doch die WAN-MAC-Adresse der Fritze bekannt und akzeptiert sein (sofern diese überhaupt erforderlich ist), denn andernfalls wäre die direkte Internetnutzung doch auch nicht möglich.

    Wie ist denn in der Windows-Konfiguration der VPN-Verbindung der Peer-Server in der Firma angegeben: Als Domain-Name oder als IP-Adresse?

    Wenn die VPN-Verbindung nicht aufgebaut werden kann:

    • Falls der VPN-Server als Domain-Name angegeben ist, kann er denn korrekt in seine IP-Adresse aufgelöst werden? In einer Eingabeaufforderung wie folgt zu testen: nslookup [Domain-Name] - dabei ist [Domain-Name] durch die Angabe in der VPN-Verbindungs-Konfiguration zu ersetzen.
    • Ist die aufgelöste IP-Adresse oder die in der VPN-Verbindungs-Konfiguration eingetragene IP-Adresse des VPN-Servers anpingbar? Test mit ping [IP-Adresse]. Wenn hier keine Antwort kommt, kann es allerdings auch sein, dass es dem VPN-Server per Konfiguration nicht erlaubt ist, auf Ping zu antworten (ggf. indirekt durch eine vorgelagerte Firewall). Aber das kann man ja beim VPN-Admin der Firma erfragen.

  • Mal wieder: Kein IPv6 bei Deutsche Glasfaser

    Zitat von TecCreator

    Wobei die Nutzbarkeit via IPv4 zwar grundsätzlich gegeben, aber nicht vollkommen unberührt ist, wenn Du eine IPv6 Adresse zugeteilt bekommst, der Traffic aber nicht läuft. Ich kann mich speziell daran erinnern, dass vom Start des Mailclients, bis zum "Handshake" mit dem Server doch eine spürbar lange Zeit verging, bis man sich einig wurde. Ein Phänomen, welches bei funktionierendem IPv6 (oder eben NUR IPv4) nicht vorhanden ist.

    Ja klar, Stichwort "Happy Eyeballs" (RFC6555) - deshalb solltest du IPv6 im LAN deaktivieren (z.B. das Senden von IPv6-RA im Router abschalten, so dass die LAN-Clients keine globalen IPv6-Adressen per SLAAC autokonfigurieren können), solange IPv6 DG-seitig nicht funktioniert.

  • Deutsche Giganetz + eigener Fritzbox 7530AX Router + Windows VPN Client IKEv2

    Zitat von paddy

    also IPV6 unterstützt der VPN Client definitiv.

    Und der VPN-Server in der Firma auch?

    IKEv2 bzw. besser gesagt IPsec ist so eine Sache, wenn die IPsec-Verbindung mit IPv4 über einen Internet-Provider erfolgt, der ein CGNAT betreibt. In diesem Fall greift der "NAT-Traversal"-Mechanismus, d.h. die ESP-Pakete der IPsec-Verbindung werden zusätzlich in UDP verpackt und am CGNAT-Router des Providers muss dazu eine UDP-NAT-Session am Leben erhalten werden. Gelingt das nicht (zu großer Zeitabstand zwischen Keepalive-Packets/oder kein Senden von Keepalives versus UDP-Session-Timeout am CGNAT-Router), bricht die IPsec-Verbindung weg.

    Deshalb wäre es besser, sofern der IPsec-Peer in der Firma IPv6 unterstützt, den IPsec-Client (was ist denn das für einer?) so zu konfigurieren, dass er bevorzugt die Verbindung zum Firmen-Peer per IPv6 aufbaut - dort gibt es die NAT-Problematik nicht und ESP-Pakete können direkt in IPv6 enkapsuliert werden.

    SSLvpn statt IPsec wäre eine Alternative, die mit IPv4/CGNAT besser klar kommt (ggf. Verwendung von TLS statt DTLS).

    Allerdings muss ich zugestehen, dass es merkwürdig ist, dass das Log des Firmen-Peers noch nicht mal den initialen Request des Clients anzeigt, denn der sollte dennoch sichtbar sein.

  • 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."