Beiträge von ::1

Ja, sieht ganz nach neuem Adress-Schema aus: In Traceroutes von extern taucht als BNG-Adresse fc00::1 auf - das ist für mich immer der Hinweis auf das neue Schema. Insbesondere, wenn auch die WAN-Adresse des Routers als Hop nach fc00::1 zu sehen ist und in dem passenden /112-Range liegt, ist es mit Sicherheit neues Adress-Schema. Dein UG schickt (leider oder gut) keine ICMPv6-TimeExceeded-Errors (als Voraussetzung für funktionierendes Traceroute) zurück.

Habe die Ranges mal in #104 ergänzt - vielen Dank für die Nennungen!

Zitat von darthi

Ich wundere mich nur, wieso der Unifi Gateway meint, er wäre mit /56 verbunden.

Vielleicht zeigt das UG an, was es angefordert hat, anstatt das, was es erhalten hat. Hast du konfiguriert, dass es einen /56 anfordern soll? Falls ja, nimm das mal raus und fordere besser keine Mindestlänge (= maximaler Range) an.

Dass DG bei IPv6-Anschlüssen nach neuer Adressvergabe-Systematik (vgl. #104 - liegt dein Adress-Range in einem dieser /41-Blöcke? - Falls nein, kannst du den Range bis zur 11. Stelle [z.B. bis zu und inklusive Stelle W in 2a00:6020:PQWX:YZnn::/64] nennen?) nicht immer korrekt arbeitet, sehen wir hier im Forum ja öfters - auch dass nur ein /64 (statt /56) delegiert wird. Für mich ist das ein Fehler.

Zitat von darthi

Seitdem bekomme ich laut Unifi Gateway zwar immer noch eine Prefix-Delegation mit /56, aber es kann nur noch ein VLAN mit einem IPv6-Subnetz ausgestattet werden.

Dann wirst du vermutlich von DG auch nur einen /64 delegiert bekommen haben. Ein Paketmitschnitt am WAN-Port während eines Reconnects müsste das auch zeigen.

Reasoning: Bekämst du tatsächlich einen /56 delegiert, wäre es ein lokales Problem deines Routers, wenn er damit nur ein VLAN bestücken könnte. Da wäre DG schuldlos.

DS-Lite:

Ein IP-Paket, das ein LAN-PC erzeugt, wird "as is" vom DS-Lite-Router in ein IPv6-Paket verpackt (getunnelt) und zur IPv6-Adresse des AFTR beim ISP geschickt. Die Quell-Adresse des LAN-Client (z.B. typischerweise 192.168.178.x mit einer Fritzbox als DS-Lite-Router) wird durch die Fritzbox (allgemein: den DS-Lite-Router) nicht(!) genattet (in was auch? Es gibt ja keine WAN-Port-IPv4-Adresse).

Sendet der Router selbst ein IPv4-Paket, dann verwendet er die (für alle DS-Lite-Router gleiche) Adresse 192.0.0.1 (habe ich jetzt nicht nachgeschlagen - müsste nochmal ins RFC schauen). [Nachtrag: Habe nachgeschaut: Tatsächlich ist es laut RFC6333 die Adresse 192.0.0.2]

Am AFTR angekommen, wird das IPv4-Paket entpackt und über die CGNAT-Instanz des AFTR Richtung Internet geforwardet. Das ist die erste und einzige Stelle, an der IPv4-NAT passiert.

Damit die Rückübersetzung funktioniert, muss der AFTR/CGNAT in der NAT-Sessiontable noch die IPv6-Adresse des Tunnels eintragen, denn die Quell-IPv4-Adressen alleine sind ja nicht eindeutig.

[Nachtrag 2]: Anhang B1/RFC6333 verdeutlicht die Abläufe sehr schön anhand eines Beispiels.

Dennoch ist die Formulierung "DS-Lite (mit oder ohne public IPv4)" falsch, denn sowas gibt es nicht.

Zitat von HubeBube

Wieso? Weil in vielen Fällen eine IPv4 aus einem nicht routbaren Adressbereich vergeben wird?

Nein, weil dem WAN-Interface des DS-Lite Home-Routers gar keine IPv4-Adresse zugewiesen wird. Es bekommt nur eine IPv6-Adresse.

Zitat von HubeBube

DS-Lite (mit oder ohne public IPv4)

sorry, das ist nonsense.

Der Unterschied besteht in den Intentionen, für die sie trainiert wurden:

• Eine KI will dir was verkaufen: 😊
• Eine KI will dich abwimmeln: 😠

Oder es ist ein lustiger DG-Fehler neuer Art...

Wenn die KI nur mit den üblichen Standardantworten ("Hammer") für jedwedes Problem (alles ist ein "Nagel") trainiert wurde, wird sie nicht viel bringen - als Kunde wird es nur mühseliger, den nicht zutreffenden Abfragebaum zu durchlaufen, bis man endlich frei formulieren kann, was das Problem ist, und vielleicht noch Dateien anhängen darf.

Traumhaft für DG: Die Rate der abgeschreckten Kunden dürfte steigen.

Kundenseitig wächst hingegen die Frustration in allen Fällen, in denen die "Hammer"-Lösung nichts zu Beseitigung von Problemen beiträgt, deren Ursache auf DG-Seite zu finden und zu beheben ist. Im Zweifelsfall wird man das durch den KI-Abwimmeler noch nicht mal mehr formulieren/mitteilen können.

Schöne neue KI-Welt: Im Service-Bereich (nicht nur bei DG) dürfte das zu enormem Wachstum der Service-Wüsten beitragen.

Auch mit dieser kaputten/verstaubten Krücke aus IPv6-Anfangstagen bekommst du nur eine Outbound IPv6-Connection - ich müsste vermutlich heutzutage ziemliche Kopfstände machen, um Teredo überhaupt zum Laufen zu bekommen.

Nö, nur wenn man die IPv6-Firewall (z.B. im Router und/oder Endgerät) dafür öffnet.

Ja , das ULA-Präfix der Fritzbox ist "fd26:f054:7320::/64". Die Adressen an deinem PC stammen aber aus "fded:e996:4e99:166::/64".

Also gibt es im LAN noch einen anderen RA-Funker.

Zitat von mbo77

Die spannendste Frage bleibt unbeantwortet. Was machen denn jetzt die Apps etc.?

Hat er doch schon in #117 beantwortet.

Tipp: Wenn du wissen willst, was passiert, mach an einem Windows-PC einen Paketmitschnitt per Wireshark (npcap mitinstallieren). Lass den so etwa 15 Minuten laufen.

Filtere anschließend das Ergebnis per icmpv6.type==134. Das zeigt dir alle empfangenen RA an.

Klappe alle ICMPv6-Inhalte eines RA auf und poste das Bild hier. Dann kann ich das mal erläutern.

Ja, ULA oder auch generell GUA können auch von einem DHCPv6-Server vergeben werden. Im Falle der Fritzbox (in der Rolle eines "stateful" DHCPv6-Servers) müsstest du dafür aber die Option "DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen" konfiguriert haben. Default ist hier aber die Option "DNS-Server und IPv6-Präfix (IA_PD) zuweisen" ("stateless" DHCPv6-Server und PD-Upstream-Router).

ok, kann sein, dass Deaktivieren von RA in der Fritzbox nur bedeutet, dass in den RA nur das globale Präfix der DG nicht announced wird, die ULA aber schon - ein Paketmitschnitt an einem LAN-PC würde das zeigen.

Aber ULA-Präfixe machen nichts, mit denen versucht ein LAN-Client jedenfalls nicht, eine Internetverbindung aufzubauen. Die werden nur für LAN-interne ULA-Zieladressen genutzt.

Nach dem Deaktivieren von RA in der Fritzbox bleiben die IPv6-Adressen an den LAN-Geräten bis zum Ablauf ihrer TTL (Time To Live) noch bestehen. Du müsstest jedes LAN-Gerät neu starten oder zumindest die Netzkarte neu initialisieren, damit die Adressen sofort verschwinden.

Zitat von mattes

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