Gibts da Stichwörter mit denen ich zu einem kompetenterem Servicelevel weiter komme oder muss ich es einfach immer wieder versuchen?
Vielleicht nutzt es, die Fritzbox-Hilfetexte zu den beiden Fehlermeldungen zu zitieren. Die müssten ja sinngemäß darauf hinweisen, dass das Problem beim ISP liegt.
Und das wirst du vermutlich mehfach wiederholen müssen...
Wir lehnen uns in dieser Diskussion ohnehin weit aus dem Fenster, weil wir die Effekte dem beobachteten Augenschein nach versuchen zu erklären und zu bewerten. Wie so eine BNG-Implementierung bei DG genau aussieht, wissen wir nicht. Moderne Architekturen basieren heutzutage bspw. auf EVPN/VXLAN und so ein BNG wird vermutlich redundant als Cluster ausgelegt sein. Wir beobachten dabei nur das Verhalten des virtuellen "Overlays".
Ja, aber wenn das unterbunden ist,
Eben, man muss es aktiv unterbinden - gute Switches bieten dafür eine Reihe von Konfigurationsoptionen. Wäre doch aber Extra-Aufwand, der vermeidbar ist, indem man die L3-Trennung der einzelnen Kundenrouter-Anbindungen aufrecht erhält.
Also, wenn die Kundenrouter an einem BNG tatsächlich untereinander via L2 direkt erreichbar wären, gäbe es eine Fülle von Angriffsszenarien (eben via ARP-Spoofing genau das: "den L2 Traffic meiner Nachbarn vorsaetzlich umlenken/kapern" oder ein paar DHCP-Angiffe) - will man nicht.
Du musst dem DG-Service beweisen, dass die Problemursache nicht auf deiner Seite liegt.
Dafür ist ein Traceroute von innen nach außen (allein) nicht hinreichend!
Ein Traceroute von außen (siehe #101) hingegen schon: Es zeigt: Dein Router (IPv6-WAN-Port-Adresse) ist von außen erreichbar, dein IPv6-LAN-Präfix jedoch nicht. Somit kommen eben auch keine IPv6-Antworten aus dem Internet zu deinem LAN zurück.
Und das ist aber eben auch das Schwierige:
In geschätzten 99,9% aller Kundenmeldungen zu Internetverbindungsproblemen, die im DG-Support aufschlagen, "sitzt das Problem vermutlich vor dem Rechner" (oder "Problem auf Layer 8") - die fertigt man eben mit Standard-Antworten ab.
Du gehörst nun zu den 0,1%, die aus dem üblichen Rahmen fallen - da wird es schwer durchzudringen.
Wobei: Bei der Fülle von IPv6-Problemfällen dieser Art müsste der Satz vermutlich signifikant größer als 0,1% sein. Es wird eben nur vielen Kunden nicht auffallen, dass ihr IPv6 nicht funktioniert (IP... was?). Sie wundern sich dann nur über schlechte Performance ihrer Webanwendungen (z.B. langsamer Aufbau von Webseiten).
Ja, ein 10.64.0.0/10 reicht theoretisch nur für 2^22 Kundenanschlüsse. Aber, man kann ja, wenn nötig, mehrere solcher 10.64-Domänen etablieren. Eine (direkte, NAT-freie) Lateral-Kommunikation zwischen zwei Kundenanschlüssen in verschiedenen 10.64-Domänen ist dann aber nicht mehr möglich.
Ich wüsste nicht, weshalb das je BNG exklusiv sein muss.
Ja, müsste eigentlich nicht exklusiv sein, aber dann wäre auch keine (direkte, NAT-freie) Lateral-Kommunikation zwischen zwei Kundenanschlüssen an zwei verschiedenen BNG innerhalb derselben 10.64-Domäne möglich. Das widerspricht aber der Erfahrung.
Nachtrag:
Zu "Das widerspricht aber der Erfahrung." ist anzumerken, dass ich eine Lateral-Kommunikation zwischen zwei Kundenanschlüssen an zwei verschiedenen BNG bisher nur für IPv6 verifizieren konnte. Für IPv4 ist das nicht möglich, da ich natürlich nicht an die WAN-IPv4-Adresse eines anderen Kundenrouters heran komme, wenn mir diese der Besitzer nicht mitteilt. WAN-IPv6-Adressen von ausgewählten DG-Kundenanschlüssen kann ich jedoch relativ leicht über öffentlich zugängliche Informationen von RIPE-Atlas-Probes an DG-Anschlüssen in Verbindung mit externen Traceroutes ermitteln.
muß das Gateway hier doch eine Art proxy-arp machen. Da kann man sich schon fragen, warum und wozu?
Ja, so sieht es aus.
Es ist aber irgendwo auch unerheblich:
Wenn du einen Nachbar-Router an einem anderen Kundenanschluss (= Punkt-zu-Punkt-Verbindung zwischen Kundenrouter und BNG) am selben BNG, an dem auch dein Router hängt, erreichen willst, muss dein Router das IP-Paket in einen Ethernet-Frame mit der MAC-Zieladresse des Gateways verpacken. Die Proxy-ARP-Funktion erspart deinem Router dabei die Arbeit, zuvor noch die MAC-Adresse des Gateways aus dessen IP-Gateway-Adresse aufzulösen (sofern nicht im ARP-Cache) - ist insofern sogar von Vorteil.
Nachtrag:
Sorry - hier die bessere Antwort: Dem Gateway bleibt auch nichts anderes üblich, als Proxy-ARP zu machen, wenn es die WAN-Adresse mit der Netzmaske /20 zuweist und so die Illusion erzeugt, man befände sich mit seinem WAN-Anschluss im Netz 100.123.96.0/20 (100.123.96.1-100.123.111.254). Somit interpretiert jeder Router einen Nachbar-Router im selben "Netz" so, als könne er ihn direkt erreichen. Er wird dann nur einen ARP-Request für die Nachbaradresse absetzen, den der Nachbarrouter aber nicht beantworten kann, da er de facto eben doch nicht "benachbart" (also via Ethernet-Broadcast), sondern nur über das Gateway erreichbar ist. Deshalb muss das Gateway den ARP-Request via Proxy-ARP mit seiner MAC-Adresse beantworten.
Nachtrag2:
Zur (naheliegenden) Frage: Wieso wird eine Netzmaske /20 vegeben?
Meine Antwort: Formell und der physischen Realität von Punkt-zu-Punkt-Verbindungen zwischen Kundenrouter und Gateway entsprechend, müsste das Gateway die IPv4-WAN-Adresse mit der Maske /31 zu weisen. Die jeweils zweite Adresse würde dann das Gateway selbst innerhalb dieser Punkt-zu-Punkt-Verbindung adressieren. Das wäre aber eine riesige Adressverschwendung, denn dann könnte man nur den halben 100.64.0.0/10-Adress-Space für Kundenrouter nutzen, die andere Hälfte ginge für die Adressierung der Gateways drauf.
Indem man hier einen /20 zuweist, braucht man für alle Kundenrouter in diesem Präfix (hier: 100.123.96.0/20) hingegen nur eine Gateway-Adresse (hier: 100.123.96.1)
Ergibt doch Sinn, oder?
Muesste dann nicht die DG ein flaches Subnetz nutzen, bei dem jede 100.er Adresse nur einmal im gesamten DG Netz verwendet wird?
Nö, warum? Ich sehe es so: Der 100.64.0.0/10-Space zerfällt in überlappungsfreie Pools, wobei jedem BNG ein eindeutiger Pool zugeordnet wird, aus dem er IP-Adressen zur Zuweisung an die WAN-Ports der Kundenrouter auswählt.
Die BNG und vorgelagerte interne Router müssen dann (zweckmäßigerweise über ein dynamisches Routing-Protokoll) untereinander nur wissen/lernen, welcher Pool auf welchem BNG liegt, um IP-Pakete mit IP-Zieladressen aus so einem Pool ebenda hin zu routen.
Heute um 7:30 kam eine E-Mail von DG:
"... Ich möchte Sie darüber informieren, dass ich eine systemseitige Synchronisierung durchgeführt habe. Ihre IPv6 ist jetzt aktiv. ..."
Was immer man bei DG unter "systemseitiger Synchronisierung" versteht (ich deute es mal eher als L2-Thematik, also auf die physische Glasfaserverbindung bezogen), es scheint so völlig am Problem vorbei zu gehen, sowohl den Layer betreffend (hier L3-Problem auf IP/IPv6-Ebene, kein L2-Problem auf Glasfaser-Ebene), als auch die Lokalisierung der Problemursache (muss am Kundenrouter bzw. dessen vermuteter Falschkonfiguration liegen). Die durchgeführte oder die bei "eigenem Kundenrouter" vorgeschlagene vermeintliche Lösung hat dann immer was von dem Spruch mit "dem Hammer und dem Nagel".
In deinem Ticket an DG solltest du natürlich zumindest erwähnen, dass die Ursache nicht in deinem Router, sondern in der (kaputten) IPv6-Infrastrukur der DG zu finden und zu beheben ist. Die Kernaussage dabei ist, dass dein IPv6-LAN-Präfix, den du dynamisch zugewiesen bekommst, in der internen Netzinfrastruktur der DG nicht zu dem BNG geroutet wird, an den dein Anschluss angebunden ist. Als Nachweis kannst du auf IPv6-Traceroute-Messungen von außen verweisen, wie ich sie in #101 gezeigt habe.
Und das wirst du in der langen Kette der zu erwartenden Ticket-Orgie stets gebetsmühlenhaft wiederholen müssen.
Deutsche Glasfaser, das ist jetzt nicht euer Ernst, ich kann deine Adresse anpingen:
Ja - das ist offenbar prinzipiell über die Access-Infrastruktur der DG möglich. Die BNG scheinen intern über ein Backbone-Netz (ich nenne es mal "BB") miteinander verbunden zu sein (folgt aus Traceroutes):
Kunde1 (K1) und Kunde2 (K2) am selben BNG:
K1 <---> BNG <---> K2
Kunde1 (K1) und Kunde2 (K2) an verschiedenen BNG (1/2):
K1 <---> BNG1 <--|BB|--> BNG2 <---> K2
Die in jeden BNG integrierte CGNAT-Funktion ist dabei nicht involviert, weil die IP-Zieladressen der anderen Kunden ebenfalls in 100.64.0.0/10 liegen.
Vielleicht sollte ich nochmal erläutern, was es mit der Deaktivierung von "Router Advertisement im LAN aktiv" auf sich hat (für jemanden, der sich mit IPv6 noch nicht gut auskennt):
RA (Router Advertisements) sind bei IPv6 elementar wichtig für eine dynamische IPv6-Konfiguration der LAN/WLAN-Clients (via DHCPv6 oder SLAAC (stateless address autoconfiguration)).
Schaltet man das Senden dieser RA ab, so haben die LAN/WLAN-Clients (außer einer linklokalen IPv6-Adresse fe80...) keine IPv6-Adresskonfiguration mehr (keine Adressen, kein Gateway, keine DNS-Server), sondern nur noch eine IPv4-Konfiguration (hier via DHCPv4).
Sieht man, wenn man z.B. an einem Windows-Client mal "ipconfig /all" absetzt und sich die Netzkonfiguration anzeigen lässt.
Im Ergebnis kommen die LAN/WLAN-Clients so nicht in Versuchung, IPv6 für die Internet-Kommunikation zu verwenden, die im vorliegenden Fall nicht funktioniert, weil die DG das (Rück-)Routing des IPv6-PD-LAN-Präfix in ihrer zentralen Infrastruktur nicht auf die Reihe bekommt.
Die beobachteten Verzögerungen bei Anwendungen spiegeln die Zeitdauer wieder, die es braucht, bis die jeweilige Anwendung auf IPv4 zurückfällt, nachdem sie zuvor erfolglos IPv6 probiert hat. Ist andererseits auch ein Indikator dafür, dass die jeweilige App bzw. das darunter liegende System (Android) die Prinzipien von "Happy Eyeballs" schlecht oder gar nicht umgesetzt haben.
Logisch, deine LAN-Clients haben dann keine IPv6-Adressen.
Und die Android-Probleme?
Kannst du alternativ evtl. den folgenden Haken entfernen?
Das käme de facto auch einer IPv6-Deaktivierung gleich.
Achso, war mir nicht klar, dass es eine Mietbox ist, sorry.
Im Frühling hatte das noch funktioniert. Aber jetzt wird IPv6 automatisch wieder aktiviert.
?
Ich meinte mit "IPv6 deaktivieren", mal den folgenden Haken zu entfernen:
Nur 1/3, da man per IPv4 ja genattet wird, und nicht von Außen erreichbar ist
schon richtig - leider kann man auf IPv4 heute noch nicht verzichten, solange noch nicht alle Internet-Services via IPv6 nutzbar sind. Ohne IPv6 ist nur unschön, ohne IPv4 ist eine Katastrophe.
Das weiß auch DG und nutzt es dreist aus - und für die Bundesnetzagentur ist das auch keine großartige Sache - da scheint man IPv6 für einen im Zweifelsfall verzichtbaren Luxus zu halten.
Hast du testweise mal IPv6 deaktiviert bzw. würdest das mal tun, um zu schauen, ob deine Android-Probleme damit verschwinden?
Schöne Sch...ße, was ist das beste Vorgehen in dem Fall? Über den Support kommt man offensichtlich nicht weiter...
Tja, Abwarten und Tee trinken. Irgendwann scheint IPv6 dann auch bei diesen Anschlüssen zu funktionieren.
Mir ist ein Rätsel, was DG da treibt - es scheint, als stecke da ein systematischer Fehler drin, bei dem Kundenanschlüsse an neu ausgerollten BNG, die bzgl. IPv6 nach neuem Adressvergabe-Konzept arbeiten sollen, erst mal nur mit funktionierendem IPv4 versorgt werden können, und IPv6 später "nachgereicht" wird.
Laut AGB zahlst du auch für IPv6, im Grunde steht dir also eine Minderung des monatlichen Beitrags um die Hälfte für nur "halbes" Internet via IPv4 zu. Nur, die Problemverursachung durch DG nachzuweisen, dürfte schwierig bis teuer werden.
Ziemlich ähnlich zu #101.
2a00:61e0::/32 scheint jetzt das neue (Unglücks-)Präfix zu sein, aus dem man IPv6-Adressen für Anschlüsse nach neuem IPv6-Adressvergabe-Konzept vergibt, die erst mal nicht funktionieren.
Wenn es bisher funktionierte, hattest du vermutlich IPv6 nach "altem" Adresskonzept. Man scheint nun also auch Bestandsanschlüsse umzustellen, vgl. #104
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
