Moin, nur um die Zahl möglicher Fehlerquellen auf ein Minimum zu reduzieren, schlage ich testweise folgendes Minimal-Setup vor:
Naja, ich gehe mal nicht davon aus, dass da "Stümper am Werk" sind. Ich denke, die haben die BNG-Interfaces outbound bewusst so konfiguriert, dass ICMPv6-TimeExceeded Fehlermeldungen (zur Bedienung von Traceroutes von außen) einheitlich mit der Quell-ULA fc00::1 versehen werden, um die tatsächliche IPv6-Adresse des jeweiligen BNG zu verstecken.
Die Alternative wäre, gar keine ICMPv6-TimeExceeded Fehlermeldungen zu schicken - da finde ich das Senden mit Quelladresse fc00::1 doch besser, denn so weiß ich, dass sich hinter dem Traceroute-Hop der BNG verbirgt und der nächste Hop der Kundenrouter ist (wenn der denn antwortet).
Und ja, sowohl fc00::/8 (registrierte ULA), als auch fd00::/8 (unregistrierte ULA) sollte man als Quelladressen im Internet nicht sehen - aber was soll's. Und die Thematik "registrierte ULA" besteht sowieso nur als Idee und wird in der Praxis nicht gelebt.
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!
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.
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.
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.
DS-Lite (mit oder ohne public IPv4)
sorry, das ist nonsense.
Der Unterschied besteht in den Intentionen, für die sie trainiert wurden:
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.
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.
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
