... sieht bisher alles mustergültig aus.
Aber wg. ULA und korrekter Quelladressauswahl bitte auch noch dieses:
netsh int ipv6 sh pref
Beiträge von ::1
-
-
Zeig bitte mal die Ausgabe von
netsh int ipv6 sh route
-
Just for Info: Diese RIPE-Atlas-Probe liegt auch im "Nuernberg-BNG-Cluster1" - IPv6 funktioniert dort einwandfrei. Ist also zumindest keine generelles Problem dieses BNG-Clusters
-
Was genau wird aus der ipconfig /all gebraucht?
Ich würde gerne sehen, welches IPv6-Standardgateway und welche IPv6-DNS-Server eingestellt sind.
Nachtrag: Und es sollte da natürlich (mindestens) eine IPv6-Adresse aus 2a00:6020:4628:700::/56 anliegen
-
Hi und welcome!
zeig doch mal eine paar (Test-)Ergebnisse, z.B. in einer Eingabeaufforderung an einem Windows-Rechner in deinem LAN, so du einen hast:
- nslookup www.google.com 2a00:6020:100::1
- ipconfig /all
-
Ein statisch formuliertes FW-Regelwerk auf Basis von IPv6-Adressen ist nun mal per se nicht mit dynamisch zugeordneten Adressen vereinbar. Manche FW unterstützen FQDNs statt IP/IPv6-Adressen, die sie dann per DNS auflösen. Da ist allerdings die Cache-Dauer des Auflösungsergebnisses kritisch zu sehen, denn falls sich die IP/IPv6-Adresse während der Cache-Dauer ändert, ist die aktuelle FW-Regel "falsch" mit entsprechend negativen Auswirkungen.
Eine Fritzbox trickst hier bei der Formulierung von Inbound-Rules (Internet->LAN), indem man den Ziel-Server im LAN nur anhand seines statischen Host-Identifiers (per EUI64 aus dessen MAC-Adresse gebildet) auswählen kann, und die Box den jeweils gerade aktuelle LAN-Präfix "hinzu montiert". Das ist schon recht clever gemacht von AVM.
-
Man kann Router so konfigurieren, dass sie solche ICMP Nachrichten nicht schicken.
Aber ein "ICMPv6 Echo Reply" schickte er bei Direktansprache der WAN-Portadresse schon ...
Nachtrag :
Es handelt sich um eine Fritzbox. Dort kann man allenfalls den sog. "Stealth Mode" aktivieren, um das Senden von ICMP- und ICMPv6-Error-Messages zu unterdrücken. In diesem Fall würde sie allerdings auch keine ICMPv6-Echo-Replies senden, was sie aber tat, wie der Traceroute zur WAN-Port-Adresse zeigt.
-
Also bei mir klappt es auch noch nicht.
Dein PD-Block 2a00:6020:76c1:1800::/56 liegt im Range 2a00:6020:7680::/41.
Die PD-Blöcke in den anderen Problemfällen, die nun gelöst zu sein scheinen, liegen jedoch in 2a00:6020:7380::/41.
-
sorry, falsches Paste, PD ist 2A00:6020:4722:7A00::/56
Für den Range müsstest du am BNG 2a00:6020:ffff:ffff::23 hängen und die WAN-Portadresse 2a00:6020:1000:44::226a haben (nach der Regel, die ich hier beschrieben habe), liege ich da richtig? Diese WAN-Portadresse erreicht man mit einem Traceroute:
Ein Traceroute für die Dummy-Adresse ::3 in deinem PD-Block zeigt hingegen dies:
Hier hätte ich als Hop 14 ein "ICMPv6: Destination unreachable" von deiner WAN-Portadresse 2a00:6020:1000:44::226a erwartet.
Das könnte tatsächlich darauf hindeuten, dass der BNG keine Route für deinen PD-Block 2a00:6020:4722:7a00::/56 besitzt. Dieser BNG bedient den Range 2a00:6020:4700::/40 im Raum Nürnberg, zumindest laut RIPE-netname="Nuernberg-BNG-Cluster2".
Für den gab es vom 04.02.2025 bis 06.02.2025 eine IPv6-Störung. Ich hänge mit meinem Anschluss auch an diesem BNG, IPv6 habe ich seit Störungsende auch wieder zur Verfügung.
Aber vielleicht ist da ja noch nicht alles behoben ...
Nachtrag:
Mit den anderen hier im Forum diskutierten IPv6-Problemen im Range 2a00:6020:7000::/36 hat dein Fall allerdings nichts zu tun, denn dein Anschluss liegt im Range 2a00:6020:4000::/36.
-
Die Probleme wären gelöst, wenn man endlich flächendeckend IPv6 ausgerollt hätte
Das geht halt nur Schritt fuer Schritt, ISP fuer ISP...
Das Problem hierbei sind nicht die ISPs - die sind damit eigentlich schon fertig. Die müssen eben "noch" IPv4 in Form von CGNAT-Krücken anbieten.
Das Problem sind die Enterprises, Behörden, bzw. allgemein die Institutionen, die Services im Internet bereitstellen - da sträubt sich die Mehrheit der Netz-Admins, in deren jeweils zugrunde liegenden Netzinfrastrukturen IPv6 einzuführen. Die meiden das, wie der Teufel das Weihwasser...
Bestes Beispiel: Dieses Forum ist noch immer nicht über IPv6 zu erreichen.
Hierzu ein unterhaltsamer Link. Und der hier ist auch nicht zu verachten.
-
Immerhin kommst du zu dem BNG (2a00:6020:ffff:ffff::23), an dem dein Anschluss hängt. Der nächste Hop wäre die WAN-Port-Adresse deines Routers (2a00:6020:1000:...).
Es könnte daran liegen, dass DG-seitig eine (aus DG-Sicht) Outbound-Route im BNG zu dem /56-PD-Block deines LAN-Bereichs fehlt.
Kann aber auch immer noch an deinem Router liegen ...
-
mir war anfangs nicht bewusst, dass selbstverständlich jeder Nutzer mit einer CGNAT-IP nur einen Teil der Ports der Public-IP zugewiesen bekommt.
Man kann auch sagen: CGNAT ist der Versuch, den (aus heutiger Sicht) mit <=2^32 zu kleinen Adress-Space von IPv4 auf Kosten von Quellports zu erweitern. Damit werden Quellports zu einem knappen Gut. Es ist eine Flickwerk-Lösung aus dem Reparaturbetrieb des kaputten IPv4-Internets.
-
Es ist ein echtes Dual Stack. Allerdings mit einer IPv4 aus dem CGNAT Range.
<Klugscheiß> :
Offiziell heißt der Range 100.64.0.0/10 "IPv4 shared address space" - er ist analog RFC1918-Adressen privater Adress-Space, der im Internet nicht geroutet wird, siehe WIKIPEDIA.
Offiziell heißt das Hintereinander von NAT am eigenen Router (übersetzt private RFC1918-Adresse aus dem LAN auf die WAN-Portadresse des Routers aus 100.64.0.0/10) und CGNAT beim ISP (setzt WAN-Portadresse des Routers aus 100.64.0.0/10 auf eine "echte" öffentliche IP-Adresse um) NAT444 (weil es 2x NAT44 ist). Das ist das Verfahren bei DG.
Das wird gerne mit DS-Lite verwechselt: Da bekommt man für den WAN-Port des Routers nur noch eine IPv6-Adresse (und keine IPv4-Adresse), sowie für das LAN einen delegierten IPv6-Block. z.B. einen /56. IPv4 ist LAN-intern beliebig definierbar, z.B. 192.168.1.0/24. IPv4 Kommunikation mit dem Internet funktioniert mit DS-Lite, indem IPv4-Pakete über die IPv6-Verbindung zu einem CGNAT-Router beim ISP getunnelt werden. Der übersetzt dann die private IPv4-Adresse in einem öffentliche IP-Adresse, wie gehabt. Zusätzlich muss sich der CGNAT-Router in diesem Szenario in seiner NAT-Session-Table noch merken, welchem IPv6-Tunnel die private IP-Adresse zuzuordnen ist, damit alles eindeutig bleibt (schließlich können andere Kunden ja auch mit privaten IP-Adressen aus dem Beispiel-Range 192.168.1.0/24 aufschlagen). Bei DS-Lite wird also nur 1x "ge-nat-tet", nämlich im CGNAT-Router des ISP.
</Klugscheiß>.
-
Es hängen nicht viele Hosts dran, evtl. ein Subnet mit vielleicht 100 Hosts.
Klingt nach einer kleinen Firma. Da ist ein Privat-Anschluss vielleicht nicht mehr so ganz angemessen. Mit einem Business-Vertrag bekämst du mindestens eine öffentlichen IP-Adresse ohne CGNAT bzw. nur 1x NAT (bzw. genauer PAT) an deinem Router und einem vollständigen Range von 65K TCP- bzw. UDP-Quellports.
Zitatwenn die DG wenigstens echtes Dual Stack anbieten würde, gerne auch für Mehrkosten...
Also, es gibt doch auch bei DG Geschäftskundenanschlüsse.
-
Zitat
root@g3-rig06:/home/marcel# netstat -rn
Kernel-IP-Routentabelle
Ziel Router Genmask Flags MSS Fenster irtt Iface
0.0.0.0 192.168.12.1 0.0.0.0 UG 0 0 0 enp2s0
192.168.12.0 0.0.0.0 255.255.252.0 U 0 0 0 enp2s0
root@g3-rig06:/home/marcel#192.168.12.0/22 mit 1022 möglichen IP-Adressen ist nun allerdings auch kein kleines Netz. Wie viele Clients gibt es denn in dem Netz?
-
Wireshark hab ich mal laufen lassen und der Host im Netz der DG 94.31.72.86 meldet "Destination unreachable" und bricht somindest die Verbindung ab.
Das dürfte dann dieser hier sein: 94.31.113.142
Das sind beides Adressen, die im CGNAT-Pool 94.31.64.0/18 (netname: DE-DGW-20100203) liegen. Wundert mich ein wenig, dass das Problem bei zwei CGNAT-Adressen auftritt. Welche Zeitspanne liegt denn zwischen den Beobachtungen der Verbindungsabbrüche bezogen auf diese unterschiedlichen CGNAT-Adressen? Normalerweise ist es so, dass man für relativ lange Zeiträume auf derselben CGNAT-Adresse hängt - in meinem Fall (94.31.113.235) z.B. seit 16.01.2025.
-
Das dürfte dann dieser hier sein: 94.31.113.142
Looks like ...
Dann kann ich mich ja freuen, hinter einem anderem CGNAT (94.31.113.235) zu hängen
-
Ich bin gerade auf der Suche nach Quellen, die das CGNAT-Thema beleuchten. Hier z.B. geht es um das Thema, von dem ich spreche. Und hier noch ein wenig RFC-Hintergrund.
Spamhaus spricht hier auch despektierlich von "Clown Grade NAT" ...
Hier noch was zu CGNAT aus ISP-Sicht: Im 4. Absatz werden "port-block exceeded errors" erwähnt.
-
... spreche vom CGNAT-Router in der Infrastruktur der DG:
Das ist der, der dir hier unter "Ihre IPv4 Internet-Adresse ist höchstwahrscheinlich ..." angezeigt wird
-
ein Router im Netz von DG meldet "host unreachable" und damit bricht die Verbindung ab. Schön zu sehen wenn man z.B. auf http://www.bild.de geht und dort viele kleine Werbeanzeigen bzw. externe Bilder geladen werden - ca. 50% der Bilder werden nicht geladen und mit einer Fehlermeldung markiert. Refresht man dann einfach werden genau diese Bilder dann geladen, andere dafür aber nicht d.h. es wird immer nur ein Teil geladen und die anderen requests abgebrochen.
Hm, das ist genau das, was auftreten kann, wenn am CGNAT-Router zuviele Clients (=DG-Kunden) auf eine öffentliche IPv4-Adresse gemappt werden. Da gehen dann irgendwann die maximal ~65k TCP-Quellports aus ...
