Beiträge von ::1

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.

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.

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.

Zitat von TecCreator

Mir ist es doch wurscht, über welches Protokoll ich meine Technik daheim erreiche.

Dir schon, aber evtl. mag dein Home-Router die jeweilige Technik nicht unterstützen, z.B. DS-Lite over PPPoE.

Zitat von pufferueberlauf

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

Zitat von flamy

Ich habe definitiv Dual-stack, warum weshalb keine Ahnung, aber laut Support, bleibt das so. Ich will mich mal nicht beschweren

Fazit:

Es ist also vorab nicht klar, was man bei einem Wechsel von DG zu 1&1 via DG-Glasfaser bekommt - das würde man doch gerne vorher wissen.

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.

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.

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.

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.

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.

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.

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

Zitat von Lazze

IPv6 haben wir soeben aktiviert! DNS-Einträge können bis zu 24 Std dauern, bis die IPv6 Erreichbarkeit gegeben ist. Beste Grüße!

mein Web-Browser zeigt (Erweiterungen "IPvFoo" und "SixOrNot"):

Besten Dank!

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.

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

Zitat von themaze

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.

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.

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

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

Warum 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.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:

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:

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

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:

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

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.

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

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.