Beiträge von ::1

Wie hast du denn in deinem "UCG-Ultra" die AFTR-Konfiguration für DS-Lite durchgeführt? Dynamisch per DHCPv6 oder stattdessen statisch durch Angabe der IPv6-Adresse bzw. des FQDN des AFTR?

Ich kenne mich auch nicht mit UCG aus, diese Beschreibung scheint mir allerdings hinreichend, um das Ding für "DS-Lite Over PPPoE" zum Fliegen zu bekommen.

Das Pendant zur oben gezeigten, nachträglich aktivierten TP-Link-LAN-Konfiguration wäre in der verlinkten Beschreibung der Abschnitt "IPv6 Local (LAN) Configuration | Advanced", laut dem ich intuitiv die Methode "Client Address Assignment = SLAAC" mit aktiven "Router Advertisement (RA)" konfigurieren würde.

IPv6 war mit UCG ja allerdings nicht das Problem (die Clients im LAN verfügten ja über globale IPv6-Adressen aus den delegierten IPv6-LAN-Präfix), sondern der vermutlich fehlende IPv4 over IPv6-Tunnel via DS-Lite ...

#94 und #100 entnehme ich, dass du eine "Unifi UCG-Ultra" an einem GigaNetz-Anschluss betreibst und in diesem Router versuchst, DS-Lite via PPPoE zum Laufen zu bekommen. Die bisherigen Ergebnisse deuteten darauf hin, dass dabei nur eine IPv6-Verbindung zustande kommt, nicht aber der per DS-Lite gewünschte IPv4 over IPv6-Tunnel. Die Traceroute-Tests sollten eigentlich für diesen "Versuchsaufbau" erfolgen, um diese Vermutung zu belegen.

Nun verwirrst du mit dem TP-Link-Router anstelle des Unifi UCG-Ultra. Der scheint wiederum von IPv6 unbeleckt zu sein und nur für IPv4 an einem CGNAT-Anschluss via PPPoE konfiguriert zu sein - offenbar unterstützt Giganetz diese Variante ebenfalls.

Aber: Was ist denn nun dein Ziel?

Btw.:

Für Chrome (->), Firefox (->) und Edge (->) (Safari: Fehlanzeige) gäbe es eine schöne Web-Browser-Erweiterung namens "IPvFoo" (dieser Link leider nur via IPv4 erreichbar), mit der man anzeigen lassen kann, welche Bestandteile einer aufgerufenen Website (Haupt-URL und einbezogene Neben-URL) via IPv4 bzw. IPv6 verbunden sind.

Zitat von kostolany25

Da siehtst Du mal, wie verzeifelt ich bin

Verzweiflung ist ein schlechter Berater.

Ruf an einem Windows-PC doch einfach mal eine Eingabeaufforderung (neudeutsch: "Terminal") auf und zeige die Ergebnisse der folgenden beiden Kommandos:

1. tracert -d 2a00:1450:4001:831::200e
2. tracert -d 142.250.186.142

Es handelt sich hierbei jeweils um die IPv6- bzw. IPv4-Adresse von "google.com".

Vermutlich wird nur 1. bis zum Ziel führen und 2. so gut wie nichts anzeigen, weil du gar keine IPv4-Verbindung zum Internet hast.

Zitat von kostolany25

Habe mir ein Tracerouting-Programm fürs iPad heruntergeladen und werde nachher auf dem Sofa immer mal wieder testen

... oder eben so - in Apple-Haushalten gibt es vermutlich keinen Windows-PC.

kostolany25

Die Nutzung von "https://www.heise.de/netze/tools/traceroute" ist an dieser Stelle natürlich sinnfrei.

Die musst den Traceroute an einem lokalen Rechner in deinem LAN ausführen/starten - etwa mit dem Windows-Befehl "tracert" in einer Windows-Eingabeaufforderung.

Zitat von HubeBube

Dual Stack Lite (DS-Lite): PPoE over DS-Lite

"DS-Lite over PPPoE" ist m.E. richtiger.

Sind im Router 1.1 1 1 und 8.8.8.8 als zu verwendende DNS-Resolver konfiguriert? Falls ja, würde ich mal versuchen, diese festen Resolver zu löschen oder zumindest durch deren IPv6-Pendants zu ersetzen: 2606:4700:4700::1111, 2001:4860:4860::8888. Ist meinerseits aber auch nur ein Schuss ins Blaue.

Zitat von flassi

Internet -> Zugangsdaten -> IPv6 -> IPv6-Anbindung -> IPv6-Anbindung mit Tunnelprotokoll verwenden sowie Verbindungseinstellungen -> 6to4

1. Das ergibt keine IPv6-Adresse, die dir DG zuweisen würde, sondern nur eine aus deiner WAN-IPv4-Adresse abgeleitete IPv6-Adresse.
2. Damit das funktioniert (geroutet und via IPv4 getunnelt wird), muss deine WAN-IPv4-Adresse allerdings öffentlich sein. Ist sie aber nicht (sondern eine aus dem Space 100.64.0.0/10 - quasi privat).

Fazit: Das ist keine Lösung. Und selbst, wenn sie funktionierte, wäre sie ohnehin grottig.

jokolautus :

Falls du einen Paketmitschnitt in deiner Fritzbox (FB) durchführen möchtest, hierfür eine Anleitung:

1. Starte an einem LAN-PC eine Eingabeaufforderung und setzte dort einen Dauerping auf Google ab: ping -6 -t google.com. . Damit das Ergebnis im Falle eines Nachweises gegenüber DG etwas repräsentativer ist, starte noch zwei weitere Eingabeaufforderungen und setze jeweils einen weiteren Dauerping auf Facebook (ping -6 -t facebook.com.) und Wikipedia (ping -6 -t wikipedia.org.) ab.
2. Starte den Paketmitschnitt in deiner FB über den Link http://192.168.178.1/html/capture.html (Adresse ggf. anpassen), indem du dort auf den Button "Start" neben "1. Internetverbindung" klickst. Es ist hierbei wichtig, dass du deine FB über ihre IPv4-Adresse 192.168.178.1 (bzw. angepasst an die tatsächliche IPv4-Adresse deiner FB) aufrufst! Die FB generiert eine Mitschnitt-Datei mit Endung *.eth und fragt dich, wo du sie auf der Festplatte deines Rechners speichern möchtest.
3. Melde dich ein zweites Mal in einem zweiten Browser-TAB an deiner FB via http://192.168.178.1 an (Adresse ggf. anpassen) und klicke unter "Internet | Online-Monitor | Verbindungsdetails" auf die Schaltfläche "Neu verbinden".
4. Warte den Aufbau der neuen Internetverbindung deiner FB ab und lasse den Paketmitschnitt danach noch etwa 5 Minuten laufen.
5. Beende den Paketmitschnitt, indem du in dem ersten Browser-TAB (falls dort von der FB inzwischen abgemeldet, öffne die Paketmitschnitt-Seite erneut via http://192.168.178.1/html/capture.html) neben "1. Internetverbindung" auf "Stopp" klickst. Hier bitte Geduld, bis der Mitschnitt wirklich beendet und die *.eth-Datei geschlossen wurde - dies wird dadurch signalisiert, dass der "Start"-Button wieder aktiv wird. Den Browser keinesfalls vorher schließen!
6. Beende die Dauerpings in deinen drei Eingabeaufforderungen.
7. Falls nicht installiert, installiere Wireshark (die dabei angebotenen Komponenten Npcap und USBPcap bitte nicht mit installieren - Wireshark wird nur zur Analyse der Mitschnitt-Datei *.eth benötigt).
8. Öffne die Mitschnitt-Datei *.eth mit Wireshark und schreibe in die oberste Zeile "Ansichtsfilter ..." den folgenden Filter:
   icmpv6 || dhcpv6 || dhcp || dns.
   Poste hier anschließend einen Screenshot dessen, was Wireshark nun anzeigt.

Falls die Ausgabe für einfaches Posten hier im Forum zu lang ist, speichere die gezeigte Filteransicht, indem du in Wireshark auf "Datei | Ausgewählte Pakete exportieren..." klickst, in dem erscheinenden Dialogfenster alle Voreinstellungen belässt und einen Dateinamen eingibst. Die so generierte *.pcap-Datei kannst du mir dann gerne über eine persönliche Konversation (die zwei Sprechblasen oben rechts neben der Lupe) zur Auswertung/Analyse zukommen lassen.

Eine andere Ursache könnte sein, dass die DG-Gegenstelle keine RA sendet, oder nur solche, in denen die "Router-Lifetime" auf 0 gesetzt ist. Und noch eine Möglichkeit ist, dass DG deine IPv6-Pakete in ihrer internen Netzinfrastruktur einfach nicht oder nicht korrekt weiterleitet.

Um sich der Problemursache zu nähern, wirst du wohl nicht um einen Paketmitschnitt am WAN-Port der FB herum kommen.

Deinem Screenshots entnehme ich, dass dein LAN-Präfix 2a00:6020:9440:b600::/56 lautet. Damit liegt dein Kundenanschluss an einem BNG, das für den IPv6-Block 2a00:6020:9400::/41 zuständig ist.

Wenn deine WAN-Adresse die Form 2a00:6020:9400::WXYZ hat, dann handelt es sich hier um einen der IPv6-Blöcke, in denen die DG ein gegenüber früheren Anschlüssen geändertes Adress-Konzept einführt.

Wir haben hier im Forum inzwischen 'zig Fälle von DG-Kundenanschlüssen in IPv6-Bereichen mit diesem neuen Adress-Konzept, bei denen IPv6 nicht funktioniert, obwohl erfolgreich IPv6-Adressen zugewiesen werden.

In diversen hier durchgeführten Analysen zu Paket-Mitschnitten am WAN-Port des Routers stellte sich heraus, dass häufig Probleme mit der MAC-Adressauflösung (bei IPv6 mittels ND = Neighbor Discovery Protocol) bestehen, für die DG verantwortlich ist (indem DG z.B. die vom Router gesendeten NS nicht per NA beantwortet). In der Folge kann der Router ausgehende IPv6-Pakete nicht in Ethernet-Frames verpacken, weil ihm die dafür benötigte MAC-Zieladresse der DG-Gegenstelle fehlt.

Führe bitte mal folgende einfachen Tests durch:

1. Notiere dein aktuelles LAN-Präfix (2a00:6020:94PQ:RS00::...) und deine aktuelle WAN-Adresse 2a00:6020:9400::WXYZ).
2. Starte an einem PC in deinem LAN einen IPv6-Dauerping auf google.com: ping -6 -t google.com (der wird zunächst negative Ergebnisse zeigen - bitte trotzdem laufen lassen).
3. Gehe in dein Fritzbox-Web-GUI und klicke unter "Internet | Online-Monitor | Verbindungsdetails" auf die Schaltfläche "Neu verbinden" (ganz unten auf der Seite)

Nachdem dein Router eine neue Internet-Verbindung aufgebaut hat, schau bitte:

• Funktioniert der noch laufende Ping nun? Falls ja, warte etwa 1 Minute: Bricht der Ping nach einer Weile (so 40 Sekunden) mit Fehler ab?
• Haben sich dein LAN-Präfix (...PQ:RS...) und die WAN-Adresse ::WXYZ geändert?

Falls du beide Fragen bejahen kannst, liegt ziemlich sicher das oben von mir beschriebene Problem vor. Exakt ließe sich das allerdings nur über einen Paketmitschnitt belegen.

Die Kombination SLAAC over PPP für den WAN-Port in Verbindung mit DHCPv6-PD für das LAN ist prinzipiell möglich.

Nur scheint das 1&1 nicht zu unterstützen und verweigert die Zuweisung eines LAN-Präfix per DHCPv6-PD, wenn die WAN-Adresse zuvor per SLAAC zugewiesen wurde.

Umgekehrt scheint Unify DHCPv6 over PPP nicht zu unterstützen, was für 1&1 vermutlich die Voraussetzung dafür ist, einen LAN-Präfix per DHCPv6-PD zuzuweisen.

Zitat von vrcca

Es ist nicht möglich ein IPv6 zu bekommen (Ich habe versucht DHCPv6 zu konfigurieren, aber ohne Erfolg), nur IPv4.

Bei IPv6 Connection statt "SLAAC" mal "DHCPv6" ausprobieren?

Zitat von ::1

Du bekommst nach einem Reconnect wieder dieselben IPv6-Adresswerte zugewiesen (WAN: 2a00:6020:9a80::172, LAN: 2a00:6020:9ac3:6b00::/56). Ist das immer so, oder wechseln Adressen auch mal?

Zitat von Slience

Meinst du die IPV6 Adresse (Präfix) bei der Fritzbox unter Verbindungsdetails (diese hat sich von ....:6boo::/56 zu b800::/56 geändert oder wo finde ich die für LAN?

Deine FB-Ereignisanzeige in #427 gibt die Antwort:

• 10.10.25 15:07:44 IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out)
• 10.10.25 15:07:44 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:9ac3:b100::/56
  
• 10.10.25 16:07:44 IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out)
• 10.10.25 16:07:44 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2a00:6020:9a80::330
• 10.10.25 16:07:44 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:9ac3:7500::/56
  
• 10.10.25 17:07:44 IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out)
• 10.10.25 17:07:44 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:9ac3:b800::/56

Du bekommst ständig wechselnde /56-LAN-Präfixe. Ob sich die WAN-Adressen auch ändern, kann ich leider nicht sehen, da die FB diese nur einmal anzeigt (2a00:6020:9a80::330).

Wie du siehst, passieren diese Fehlereinträge (Fehlergrund: 4000 (lease timed out)) exakt in Stundenabständen.

Ursache:

Die deinem Router per DHCPv6 zugewiesenen IPv6-Adressen (WAN-Adresse + /56-LAN-Präfix) werden seitens DG nicht verlängert (die FB versucht vor Ablauf der Leasedauer durch Senden von "DHCPv6-Renew" und ggf. zusätzlich "DHCPv6-Rebind", die Leasedauer der zuletzt erhaltenen IPv6-Adressen zu verlängern, der DHCPv6-Server der DG beantwortet diese Verlängerungsversuche jedoch nicht).

Die Leasedauer beträgt bei DG 3600s = 1h. Läuft sie ab, erzeugt die FB in ihrem Event-Log den Eintrag "IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out)". Anschließend fordert sie in einer neuen DHCPv6-Transaktion eine neue DHCPv6-Lease an.

Dass die DHCPv6-Leases nicht verlängert werden, ist ein weiterer Fehler seitens DG. Und dass du jedes Mal neue IPv6-Adressen bekommst, ist ebenfalls nicht normal.

Insofern gilt das Fazit des ähnlich gelagerten Falles #93 analog auch für dich - ich kopier's dir nochmal hierher und passe es unter Ergänzung des DHCPv6-Problems für deinen Fall an:

Fazit:

Zusammenfassend lassen sich folgende Fehler festhalten, für die allein DG verantwortlich ist:

• Es gelingt zwar, dem Router IPv6-Adressen zuzuweisen - diese wechseln jedoch mit jedem Reconnect. An DG-Privatanschlüssen sind die IPv6-Adressen quasistatisch (aber nicht garantiert), ein Wechsel der Adressen bei jedem Reconnect deutet erfahrungsgemäß auf einen seitens DG nicht funktionierenden IPv6-Zugang hin. Auffällig sind hier immer wieder jene IPv6-Ranges (hier 2a00:6020:9a80::/41 mit WAN-Adressen in 2a00:6020:9a80::/112), in denen DG aktuell ein neues Adressierungsschema einführt.
• Die Versuche des Routers, die IPv6-Adressen für LAN und WAN vor Ablauf der Leasedauer (1h) per DHCPv6-Renew bzw. ggf. zusätzlich per DHCPv6-Rebind zu verlängern, werden seitens der DG-Gegenstelle (DG-DHCPv6-Server) nicht beantwortet. In der Folge laufen die DHCPv6-Leases nach Ablauf einer Stunde regelmäßig aus. Der Router fordert anschließend in einer neuen DHCPv6-Transaktion eine neue Lease an, erhält dabei in der Regel allerdings andere Adressen, als die jeweils vorherigen Lease. Auch dieses Verhalten deutet erfahrungsgemäß auf einen seitens DG nicht funktionierenden IPv6-Zugang hin.
• Die DG-Gegenstelle (hier fe80:22) beantwortet generell keine NS, die per Multicast an ihre SNMA (solicited node multicast address, hier: ff02::1:ff00:22) gesendet werden. NS, die sie per Unicast (an fe80::22) erhält, werden offenbar nach einer bestimmten Zeit ebenfalls nicht mehr beantwortet. Dies führt dazu, dass dem Kundenrouter die MAC-Adresse der DG-Gegenstelle abhanden kommt, und er in der Folge keine IPv6-Unicast-Pakete mehr ausgehend Richtung Internet senden kann.
• Da erfolgreich an die DG übermittelte PINGv6-Pakete (ICMPv6 Echo Request) zu allgemein pingbaren Internet-Zielen (z.B. facebook.com = 2a03:2880:f176:181:face:b00c:0:25de) nicht per ICMPv6 Echo Reply beantwortet werden, ist anzunehmen, dass die IPv6-Adressen des Kundenanschlusses innerhalb der DG-Netzinfrastruktur nicht korrekt geroutet werden (vermutlich nicht funkionierende IPv6-Rückwärts-Routen zum Kundenanschluss).

Zitat von JaFr

Die Nachrichtenlänge ist bei der DG auf 2000 Zeichen begrenzt, nicht viel um einen komplexen Sachverhalt darzustellen.

Naja, den Sachverhalt könntest du ja umfänglicher mit einer Textverarbeitung erstellen, als PDF speichern und als Attach anfügen. Im Ticket selbst dann nur eine Zusammenfassung mit Verweis auf den Anhang.

Habe deine Mitschnitt.zip mal mit dem Ansichts-Filter ipv6 || dhcp angeschaut (Screenshot-Datei und pcap für die Filtersicht als ZIP im Anhang):

Das ist ziemlich identisch zu #93 (Analyse des Paketmitschnitts) in Verbindung mit #91 (Wireshark-Darstellung des Paketmitschnitts) und #88 (Beschreibung des Ablaufs für die Erstellung des Paketmitschnitts).

Der Fazit-Block in #93 (Analyse des Paketmitschnitts) passt auch für deinen Fall, allerdings mit folgenden Unterschieden:

• Du bekommst nach einem Reconnect wieder dieselben IPv6-Adresswerte zugewiesen (WAN: 2a00:6020:9a80::172, LAN: 2a00:6020:9ac3:6b00::/56). Ist das immer so, oder wechseln Adressen auch mal? Falls nicht, gilt der erste Aufzählungspunkt des Fazits in #93 nicht für deinen Fall - du wärst dann in der schon besseren Situation, wenigstens stets dieselben IPv6-Adresswerte zu bekommen.
• Aber auch deine IPv6-Adressen liegen in einem Block, in dem DG ein neues Adresszuweisungskonzept einführt; es ist nur ein anderer Block als im Fall #93, nämlich 2a00:6020:9a80::/41 (LAN-Adressbereich für Kundenanschlüsse 2a00:6020:9a80:100::/56 - 2a00:6020:9aff:ff00::/56, WAN-Adressen in 2a00:6020:9a80::/112, also Adressen der Form 2a00:6020:9a80::xxxx). IPv6-Ranges dieser Art sind offenbar anfällig für IPv6-Probleme.

Vielleicht noch folgende Tipps für dein nächstes Ticket an die DG:

• Ich würde meinen Fazit-Block in #93 kopieren und direkt in das Ticket schreiben. Als Referenz würde ich Links auf #93 (Analyse des Paketmitschnitts), #91 (Wireshark-Darstellung des Paketmitschnitts) und #88 (Beschreibung des Ablaufs für die Erstellung des Paketmitschnitts) beifügen.
• Den Paketmitschnitt würde ich als ZIP-Datei beifügen - allerdings nicht die vollständige eth-Datei, sondern nur den extrahierten View des Ansichtsfilters "icmpv6": Menü Datei | Ausgewählte Pakete exportieren: Im angezeigten Dialog alle Voreinstellungen belassen und Namen für die zu speichernde Datei mit der voreingestellten Erweiterung .pcap speichern. Diese Datei anschließend zippen und die ZIP-Datei dem Ticket beifügen.

Zitat von JaFr

Ihnen steht bei Deutsche Glasfaser ein CGN Dualstack Lite Anschluss zur Verfügung

Das ist falsch! Es ist ein Dualstack-Anschluss, allerdings mit IPv4 hinter einem CGNAT und daher einer nicht-öffentlichen IPv4-Adresse für deinen Router aus 100.64.0.0/10 (= Range 100.64.0.0 - 100.127.255.255).

Bei einem DS-Lite-Anschluss hätte dein Router gar keine IPv4-Adresse.

DG sollte seine Textbausteine überarbeiten.

Zitat von JaFr

Darf ich deine Ausführungen für eine weitere Beschwerde (die 4.) bei der DG verwenden?

Na klar - nur zu! Würde mich freuen, wenn das bei DG zu deinem Vorteil tatsächlich eine Wirkung hätte. Ich befürchte nur, dass man dich am anderen Ende nicht zu jenem Backend-Support durchlassen wird, der diese Analyse nachvollziehen könnte. Abgesehen davon, dass man DG-seitig ein hauseigenes Problem ungern zugeben wird, sonst kommen die betroffenen Kunden noch auf die dumme Idee, Regressforderungen zu stellen.