Ist ein Cisco Secure Client mit AnyConnect.
Also, den habe ich auch auf meinem Dienst-Notebook am heimischen DG-Anschluss - Gegenstelle bei meinem AG ist ein Cisco-ASA-Cluster, der natürlich auch für IPv6 für das "äußere" Protokoll konfiguriert ist. Verwendet wird SSLvpn (mit DTLS und möglichem Fallback auf TLS). Funktioniert bei mir sowohl mit IPv4 (+CGNAT) als auch mit IPv6.
Auf der Website meiner RIPE-Atlas-Probe (ist doch gut, so ein Ding zu haben), sehe ich für meinen DG-Anschluss (Raum Fürth - PLZ 9061X) einen IPv4-Ausfall von ~ 12:32 bis ~ 13:04 UTC, also MESZ: 14:32- 15:04:
Und ich kann diesen Post hier jetzt nur schreiben, weil IPv4 aktuell wieder funktioniert.
Wie schön wäre doch, wenn ww.glasfaserforum.de endlich auch via IPv6 erreichbar wäre!
Danke euch für die Nachhilfe!
Da nochmal weiter in die Zukunft gefragt: Wenn man in einem MFH mit FTTB+DPU künftig/nachträglich Glasfasern (in Ablösung von Telefon-Leitungen) bis in die Wohnungen verlegt, durch was müsste dann die DPU ersetzt werden?
Noch eine Frage dazu: Ist folgende Aussage in etwa zutreffend?
"Was der DSLAM bei FTTC, ist die DPU bei FTTB"?
Wenn im Keller ein DPU haengt (G.fast, oder VDSL), dann brauchst Du auch einen Router (oder ein bridged Modem) das ebenfalls G.fast oder VDSL "sprechen" kann. Das ist allerdings bei EFH extrem unueblich und wird gerade mal bei MFH gemacht (die meisten DPU haben wohl 8 oder 16 Ports und waeren eine Verschwendung fuer ein EFH).
Jain, G.fast wird schon auch von ISPs fuer FTTB verwendet (z.B. bei NetCologne und wohl auch bei der Telekom) allerdings meist/nur? in MFHs Ja, das ist letztlich eine Spielart von DSL aber nur fuer kurze Strecken.
Danke für die Erläuterung - jetzt habe ich's auch begriffen. Hatte diese Inhouse-"Verteilvariante" nicht im Blick bzw. nicht aus der ursprünglichen Fragestellung darauf geschlossen.
Nicht ganz, bei FTTB und vielen Teilnehmer in Gebäuden mit vorhanden LAN-Kabel wird es häufig eingesetzt. Erspart Bautätigkeiten.
FTTB-Ausbau mit G.fast | Stiegeler
Na gut, aber von der Verwendung von Telefonkabeln hat der OP nichts gesagt:
Von da aus haben wir ein Netzwerkkabel (Cat7) angeschlossen und dieses läuft nun ein Stockwerk höher in unsere Uralt-Fritzbox.
Also G.fast ist eine Technik im DSL-Bereich, das hat mit deiner Fragestellung so gar nichts zu tun.
Design-technisch ähnelt das obige Bild des ONT einigen Modellen von FiberHome, z.B. HG6019A (GPON), HG6119A (GPON) und HG5852SA (XGSPON). Es könnte sich evtl. um eine Auftragsfertigung dieses Herstellers speziell für DG handeln.
Diese Geräte sind aber zugleich auch Router. Bei dem oben abgebildeten ONT deutet die Lampe "INTERNET" (die ich an einem ONT nicht erwarten würde) darauf hin, dass es sich tatsächlich um einen Router handeln könnte, der aber evtl. in einem vorkonfigurierten Bridge-Mode betrieben wird.
Also, dass selbst die Zuweisung einer IPv4-Adresse per DHCP scheitert, kenne ich von meinem DG-Anschluss auch, der Spuk hatte aber jeweils nach ein paar Stunden eine Ende.
Erneut per Rückfrage geöffnet und auf Traceroute hingewiesen und darauf, dass das Problem beim Routing in der DG-Infrastruktur liegt und nicht der Adresszuteilung.
Um nachzuweisen, dass dein Router zwar IPv6-Pakete in Richtung DG/Internet senden kann, von dort aber niemals Antworten zurückkommen, wäre es (neben deinen Traceroutes) evtl. hilfreich, einen Wireshark-Screenshot (und ggf. eine dazu gehörige gezipte pcap-Datei) eines Paketmitschnitts am WAN-Port deiner Fritzbox mitzuschicken, den du aufzeichnest, während du an einem Windows-LAN-PC folgende Aktivitäten durchführst (pro Aktivität eine separate Command-Shell deiner Wahl starten, die NSLOOKUPs können natürlich alle in derselben Command-Shell erfolgen - ich gehe hier davon aus, dass DNS-Requests via IPv6-Transport an die DNS-Resolver der DG auch nicht beantwortet werden !?):
Damit der Wireshark-Screenshot nur die relevanten Daten zeigt, wäre dort folgender Ansichtsfilter sinnvoll:
ipv6 && dns || icmpv6.type == 128 || icmpv6.type == 1
Über "Datei | Ausgewählte Pakete exportieren..." kannst du diese gefilterte Ansicht dann auch ein eine separate pcap-Datei exportieren, damit du der DG nicht das vollumfängliche Original schicken musst.
Falls du den Direktzugriff (ohne VPN, oder mit VPN-Tunnel, der am NAS terminiert) auf dein NAS via IPv6 ins Auge fasst, möchte ich zu bedenken geben, dass QNAP seit Firmware QTS 5.2.5.3145 build 20250526 (Release Notes) an der IPv6-Implementierung herum geschraubt und diese leider wie folgt "verschlimmbessert" hat:
Bei IPv6-Konfiguration des NAS-Netzwerk-Interfaces per SLAAC ("Stateless Address Autoconfiguration") wird keine permanente Interface-ID mehr generiert!
Zur Erläuterung:
Im LAN hinter einer Fritzbox an einem DG-Anschluss wird dein NAS bei Konfiguration via SLAAC eine IPv6-Adresse der Form
[PREF]:[IID]
aufweisen, wobei PREF das LAN-Präfix 2a00:6020:PQWX:YZ00 (das prinzipiell wechseln kann, bei DG aber in aller Regel quasi-statisch ist) und [IID] die schon erwähnte Interface-ID ist, die das NAS nach einem Algorithmus u.a. aus der eigenen MAC-Adresse generiert. Beide Adress-Bestandteile sind mit jeweils 64 Bits gleich lang.
Für den IPv6-Zugriff auf das NAS muss in der Fritzbox-Firewall inbound eine Freigabe für die IPv6-Adresse des NAS (+ entsprechende Ziel-Ports) eingerichtet werden. Diese Freigabe erfolgt aber ausschließlich anhand der [IID] des NAS, denn [PREF] kann sich ja prinzipiell ändern - die Fritzbox ist dann so smart, die Freigabe für das geänderte LAN-Präfix dynamisch anzupassen.
Voraussetzung dafür ist aber, dass [IID] konstant ist und sich nie ändert. Das ist aber leider seit Firmware QTS 5.2.5.3145 build 20250526 nicht mehr der Fall! Es werden nur noch temporäre [IID] mit begrenzter zeitlicher Dauer erzeugt, auch nach jedem Neustart des NAS ändert sich die [IID].
{Nachtrag: Offensichtlich haben die QNAP-System-Engineers hier nur gemäß RFC8981 implementiert und sich entsprechend dem dort enthaltenen Passus "This document does not imply or require the configuration of stable addresses; thus, implementations can now configure both stable and temporary addresses or temporary addresses only." für "temporary addresses only" entschieden. Ich vermute, sie wollten damit die Privacy des NAS "verbessern" für den Fall, dass es ständig durch irgendwelche offenen WLANs vagabundiert 
- ich weiß nicht so recht, was die vorher geraucht haben. Für server-like Systeme, wie einem NAS, das eigentlich permanent in einer vertrauenswürdigen Umgebung wie dem Home-LAN residiert, ist das doch jedenfalls ein ziemlicher Unsinn. Sie hätten da besser doch gemäß RFC7217 implementiert!}
Außerdem benötigst du eine stabile [IID] auch für manche DynDNS-Lösungen (z.B. DynV6), bei denen du auf deren Web-Site einen Host (hier NAS) anhand seiner [IID] konfigurieren musst. Die Fritzbox würde in einem DynDNS-Update dann nur den [PREF] liefern. Der DynDNS-Anbieter "montiert" beides zu [PREF]:[IID] zusammen und registriert die Adresse unter deinem Wunsch-FQDN im DNS.
Ein Workaround wäre daher, von SLAAC (heißt dort "Automatische Stateless-Konfiguration") für dein NAS abzusehen:
Du kannst den Zugriff von außen (z.B. via Smartphone mit abgeschaltetem WLAN, sofern du von deinem Mobilfunkanbieter IPv6 bekommst) auch ohne DynDNS ausprobieren, indem du im Adressfeld anstelle eines FQDN (den du noch nicht hast) unmittelbar die IPv6-Adresse des NAS verwendest, wichtig ist dabei, dass du sie in eckige Klammern setzen musst:
[2a00:6020:PQWX:YZ00::1]
Ok, gehört also zu 2a00:6020:9c80::/41 - deine WAN-Adresse sollte dann wohl in 2a00:6020:9c80::/112 liegen, also die Form 2a00:6020:9c80::WXYZ haben - right?
Nur mal interessehalber: Liegt dein LAN-Präfix in einem der von mir gelisteten IPv6-Ranges?
Falls nein, würdest du mir den Range bis zur 11. Stelle (2a00:6020:XYZ) verraten? Ich muss für Z nur wissen, ob <8 bzw. >=8.
Als ich noch parallel den DSL-Anschluss bei meinem Vorgängerprovider Inexio hatte, der ja inzwischen auch zur DG gehört, endeten Traces von dort zu meinem DG-Anschluss auch bei fc00::1.
Ja, alle alten Inexio-Anschlüsse scheinen in Bezug auf IPv4 zum AS8899 zu gehören, während sie in Bezug auf IPv6 im AS60294 liegen. Die CGNAT-Adressen dieser Anschlüsse scheinen nach meinen Beobachtungen stets im Range "DGW-FTTH-DYNAMIC-FRA1" = 94.31.96.0/20 zu liegen.
Bezüglich der ULA fc00::1 in Traceroutes von "außen" zu DG-Anschlüssen bin ich empirisch inzwischen zu folgender Erkenntnis gelangt:
Für neuere DG-Kundenanschlüsse mit IPv6-Adresszuweisung nach offenbar geändertem/neuen Konzept gilt augenscheinlich, dass in Traceroutes zu diesen Anschlüssen der vorletzte Hop (unmittelbar vor dem Kunden-Router, somit also der BNG) stets mit fc00::1 adressiert ist. Das gilt auch für "funktionierende" DG-Anschlüsse. Man kann aus dem Erscheinen von fc00::1 im Traceroute also nicht auf eine Fehlkonfiguration schließen.
Erstaunlich ist die Sichtbarkeit von IPv6-Paketen mit ULA-Source-Adressen im Internet (hier ICMPv6-Time-Exceeded von fc00::1) allerdings schon: Bei guter Administration des eigenen AS sollten die eigenen eBGP-Router derlei eigentlich filtern bzw. droppen.
Nach meinen Beobachtungen wird derzeit für DG-Kundenanschlüsse in folgenden IPv6-Ranges (ohne Anspruch auf Vollständigkeit) das neue IPv6-Konzept verwendet:
In diesen Ranges ist der jeweils erste /56-Block ausgenommen, weil aus diesem Range die WAN-Port-Adressen der Kundenrouter gebildet werden. Diese WAN-Port-Adresse ist an funktionierenden Kundenanschlüssen der letzte Hop in Traceroutes - Fritzboxen in der Standardeinstellung liefern hier brav Antworten und sind WAN-seitig auch anpingbar.
Der Outbound IPv6-Traffic geht korrekt zur MAC der Gegenstelle, die sich als Router announced hat. Es kommt nur Nichts zurück, und dann sieht man Retransmits.
Ok - dann ist das Problem hier anders gelagert: Die DG-Infrastruktur routet deine IPv6-Adressen nicht. Hatten wir hier im Forum auch schon.
dass das Problem weiterhin besteht, also ping und traceroute auf die IPv6 von außen nicht gehen
Wäre es evtl. nicht erst mal naheliegender nachzuweisen, dass IPv6 outbound ebenfalls nicht funktioniert?
Möglicherweise hat das ja in deinem Fall dieselben Ursachen, die ich in #381 beschrieben habe. Falls so, wäre es aus meiner Sicht viel effizienter, die eigentliche Ursache des Problems konkret zu benennen: Nämlich, dass die Hardware-Adressauflösung für IPv6 (per NS/NA) outbound nicht funktioniert, weil die DG-Gegenstelle die von deinem Router gesendeten NS nicht per NA beantwortet.
Alles Andere (nämlich, dass IPv6 outbound und inbound nicht oder ggf. nur sporadisch funktionieren) wäre dann nur eine Folge des Kernproblems.
Freilich müsste man das für deinen Fall erst Mal durch einen Paketmitschnitt am WAN-Port verifizieren - möglicherweise liegen deinem Problem ja doch andere Ursachen zugrunde, als dem von Luki .
Es kann auch sinnvoll sein, aus Platzgründen oder weil die Editier-Möglichkeiten im Kontaktformular für die Ticket-Erfassung recht "elementar" sind, das Problem ausführlich in einem Word-Dokument zu beschreiben, das man als PDF speichert und als Attach beifügt. So kann man den Beschreibungstext des Tickets sehr kurz halten und auf die ausführliche Beschreibung im angehängten PDF verweisen.
(Packet Captures kann man ja nicht anhängen)
müsste als komprimierte ZIP-Datei schon möglich sein.
Seit wann die Telefonie ebenfalls via IPv6 möglich ist, weißt Du nicht zufällig?
Mein ältester Paketmitschnitt, in dem ich das verifiziert hatte, stammt vom 01.09.2022. Den Anschluss habe ich seit 10/2021.
Ich vermute mal, die Aussage "geht nur via IPv4" resultiert daraus, dass "dg.voip.dg-w.de" nur nach IPv4 auflöst (185.22.44.186).
Ich habe auch erst durch Paketmitschnitte mitbekommen, dass der SIP-Service via SRV-RR erfragt wird, siehe meine NSLOOKUP-Ausgabe im letzten Post, die das Verhalten der Fritzbox (wie per Paketmitschnitt ermittelt) nachbildet.
