Beiträge von ::1

Zitat von topas-rec

Meine Router Software (NetworkManager) nimmt aber keine RA an, wenn die Verbindung auf DHCP steht.

Das wäre allerdings nicht standard-konform: Bei einer dynamischen Interface-Konfiguration per DHCPv6 müssen auch RA angenommen werden, denn das wäre die einzige Möglichkeit, dem Interface ein IPv6-Standardgateway und ggf. per PIO-Option (ohne gesetztes A-Flag) eine Prefix-Länge mitzuteilen. Für diese beiden Werte gibt es bei DHCPv6 (im Gegensatz zu DHCPv4) keine entsprechenden Optionen: Sie müssen aus RA gelernt werden, DHCPv6 vergibt nur IPv6-Host-Adressen (=/128).

Zitat von topas-rec

Nachdem ich alles wieder zurückgebaut hatte (zurück von DHCP auf SLAAC und von DUID-LLT auf NetworkManager-Standard DUID Einstellung) und den Router neu gestartet habe, lief die Verbindung auch wieder mit SLAAC (inklusive Präfix-Auslieferung).

Verstehe ich das richtig (?):

Dein Router am DG-Anschluss benutzt für die Konfiguration einer WAN-Port-Adresse SLAAC? Und dein Präfix für das LAN fordert er per DHCPv6-PD (IA_PD) an? Ich wusste bisher nicht, dass DG für die WAN-Port-Konfiguration überhaupt SLAAC unterstützt. Das widerspräche auch den Informationen, die DG in einem RA sendet: Dort steht das M-Flag auf 1 (=heißt: mach bitte DHCPv6), und es enthält auch keine PIO-Option, aus der dein Router per SLAAC eine globale IPv6-Adresse generieren könnte.

Oder ist es so, dass dein Router gar keine globale WAN-Port-IPv6-Adresse hat, sondern dort nur über eine link-lokale fe80-Adresse verfügt? Das wäre ja auch denkbar. Globale IPv6-Adressen hättest du dann nur auf der LAN-Seite, und wenn dein Router selbst ins Internet spricht, verwendet er seine LAN-Adresse als Source.

Zitat von kammann

Um mal wieder auf die Störung bei der DG zurückzukommen: Wo macht denn eigentlich die DG ihr CGNAT für IPv4? Ist das immer noch zentral in Frankfurt und Düsseldorf für alle DG Kunden in ganz Deutschland? Bei der Telekom ist das dezentral über ganz Deutschland verteilt. Mein DG Anschluss im südlichen Bayern wird über die (interne) DG-IP 100.124.1.24 (1. Hop nach dem Router) geroutet. Habt ihr aus anderen Regionen andere Adressen?

Die Adressen aus 100.64.0.0/10 (100.64.0.0 - 100.127.255.255) sind ja nicht öffentlich, sondern "IPv4 shared address space". Der nächste Hop nach deinem Router (bei dir 100.124.1.24, bei mir: 100.124.1.26 - Raum Nürnberg/Fürth) müsste das BNG sein, an dem dein Anschluss hängt. Ob das BNG selbst bereits (dezentral) CGNAT durchführt (ich vermute es), ist anhand der Traceroutes leider nicht zu erkennen. Es könnte auch einer der beiden nächsten Hops sein, von denen man im Traceroute nur "Zeitüberschreitungen" sieht - ich gehe davon aus, dass diese Hops noch zur DG-Infrastruktur gehören.

Zitat von HubeBube

und einer ASA (gibt es die überhaupt noch bzw. noch Support?)

ASA lebt als "Cisco Secure Firewall" weiter - ist einfach nicht tot zu kriegen.

Zitat von HubeBube

mit Microsoft Direct Access gab es keine Probleme

Soweit ich mich mal damit befasst und es hoffentlich einigermaßen richtig verstanden habe (es gab dazu mal Vorträge auf einem der "IPv6-Kongresse" in Frankfurt, die der Heise-Verlag so zwischen 2008 und 2014 veranstaltet hat), baut MS-DA extrem stark auf IPv6-Tansition-Technologien auf. Bei reinen IPv4- oder IPv6-Szenarien sah es mit MS-DA dann recht mau aus. Ist mein Eindruck richtig?

Zitat von HubeBube

Ich sehe in den Logs/Ereignissen meiner Glasfaserfritze an der Faser nichts, was auf einen Ausfall hindeutet. Noch nicht einmal ein neues Lease in dem erwähnten Zeitraum.

Ist bei meiner Fritze auch so - die Störung lag folglich ausschließlich innerhalb der DG-Infrastruktur. Die IPv4-DNS-Resolver der DG waren bspw. erreichbar.

Zitat von user

wenn man sich auf https://stat.ripe.net/resource/AS60294#tab=measurements wahllos Probes anschaut, wird es eine deutschlandweite(?) Störung gewesen sein.

Hinweis: Bezüglich IPv4 laufen viele Probes an DG-Anschlüssen im AS8899. Nur bzgl. IPv6 liegen sie (bisher) stets im AS60294.

Zitat von HubeBube

Hm, egal ob DS-Lite, DS mit oder ohne CGNAT, keine Remote Dial-In/VPN Lösung sollte damit ein technisches Problem haben.

Da habe ich gegenteilige Erfahrungen aus früheren Zeiten: Da gab es mit einem IPsec-VPN-Client via IPv4 (+CGNAT) Verbindungsabbrüche.

Ich habe es mir so erklärt:

Mit NAT (am Heimrouter) und CGNAT (beim ISP) muss IPsec mit "NAT-Traversal", also ESP/UDP/IPv4 bzw. IKE/UDP:4500 arbeiten. Dazu müssen aber die Timeouts der UDP-NAT-Sessions im heimischen NAT-Router bzw. im CGNAT beim ISP länger sein, als die Zeitintervalle zwischen zwei Keep-Alives, die die VPN-Peers untereinander senden, um die ESP-SAs am Leben zu erhalten. Auf die UDP-Session-Timeouts am CGNAT habe ich aber keinen Einfluss. Vermutlich ist die UDP-Sessiondauer am CGNAT im Vergleich zum Zeitintervall zwischen zwei Keep-Alives kürzer gewesen ...

Zitat von Dringi

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?

1. Wäre das dann ein (aktiver?) optischer Verteiler, der die Datenströme der einzelnen Wohnungsanschlüsse wie zuvor die DPU auf die (eine) Uplink-Glasfaser des FTTB-Anschlusses multiplext?
2. Oder schießt man nachträglich pro Wohneinheit weitere Glasfasern "in das Haus", so dass jede Wohneinheit einen "echten"/dedizierten FTTH-Anschluss erhält?
3. Oder kann es auch eine Mischung aus 1. und 2. sein - Variante 2. dann nur für Wohnungsbesitzer, die ihren Vertrag explizit auf FTTH umstellen?

Noch eine Frage dazu: Ist folgende Aussage in etwa zutreffend?

"Was der DSLAM bei FTTC, ist die DPU bei FTTB"?

Zitat von pufferueberlauf

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

Zitat von pufferueberlauf

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.

Zitat von Phino

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:

Zitat von flo0193847

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.

Zitat von olifre

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 !?):

• ping -t 2a00:1450:4001:81d::200e (= IPv6-Adresse von google.com)
• ping -t 2a03:2880:f13f:83:face:b00c:0:25de (= IPv6-Adresse von facebook.com)
• ping -t 2a02:ec80:300:ed1a::1 (= IPv6-Adresse von wikipedia.org)
• nslookup google.com. 2a00:6020:100::1 (= Auflösungsversuch durch Anfrage beim DG-Resolver dnscache001.dg-w.de)
• nslookup google.com. 2a00:6020:200::1 (= Auflösungsversuch durch Anfrage beim DG-Resolver dnscache002.dg-w.de)
• nslookup facebook.com. 2a00:6020:100::1 (= Auflösungsversuch durch Anfrage beim DG-Resolver dnscache001.dg-w.de)
• nslookup facebook.com. 2a00:6020:200::1 (= Auflösungsversuch durch Anfrage beim DG-Resolver dnscache002.dg-w.de)
• nslookup wikipedia.org. 2a00:6020:100::1 (= Auflösungsversuch durch Anfrage beim DG-Resolver dnscache001.dg-w.de)
• nslookup wikipedia.org. 2a00:6020:200::1 (= Auflösungsversuch durch Anfrage beim DG-Resolver dnscache002.dg-w.de)

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:

1. Du könntest die IPv6-Adressvergabe in deinem LAN in der Fritzbox auf DHCPv6 umstellen (in den IPv6-Einstellungen die Option "DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen" aktivieren). Im NAS konfigurierst du für IPv6 den Verbindungstyp "Automatische Stateful-Adress-Konfiguration" mit "DNS-Server-Verbindung" = Automatisch.
   
   Welche IPv6-Adresse und mithin welche [IID] der DHCPv6-Server der Fritzbox dann deinem NAS zuweist, kannst du anschließend in der Fritzbox oder im NAS nachschauen. Hier musst du allerdings darauf bauen, dass der DHCPv6-Server dem NAS stets dieselbe [IID] zuweist. Ich habe diesbezüglich keinerlei Erfahrungswerte.
   
2. Ansonsten bliebe nur, dein NAS bzgl. IPv6 statisch zu konfigurieren ("Statische IP-Adresse verwenden"), d.h. selbst eine feste [IID], hier z.B. "0:0:0:1" (kurz: "::1") vorzugeben:
   
   Feste IP-Adresse: 2a00:6020:PQWX:YZ00::1
   Präfixlänge: /64
   Standardgateway: fe80:... (hier bitte die fe80-Adresse deiner Fritzbox eintragen, die wird dir z.B. unter Windows mit dem Kommando "ipconfig" unter "Standardgateway" angezeigt.
   DNS-Server: Hier entweder deine Fritzbox (siehe Ausgabe des Windows-Kommandos "ipconfig /all" und dort: "DNS-Server": fd...) oder andere DNS-Server deiner Wahl (z.B. Google: 2001:4860:4860::8888 + 2001:4860:4860::8844) eintragen.
   
   Hier hättest du nun zwar einen festen [IID] = 0:0:0:1, den du für die Freigabe-Konfiguration in der Fritzbox und ggf. auch für DynDNS verwenden kannst. Allerdings besteht hier der Nachteil, dass sich das LAN-Präfix nicht ändern darf (in diesem Fall musst du die statische IPv6-Konfiguration deines NAS manuell nachziehen - Fritzbox-Freigabe und DynDNS müssen nicht geändert werden) - aber das kommt an DG-Anschlüssen so gut wie nie vor.

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?