Beiträge von ::1

Hier zur Illustration mal der Paketmitschnitt eines etwa 6-stündigen Kampfes meiner damaligen Fritzbox 7590 um den Bezug von IPv6-Adressen (IPv4 war damals ebenfalls betroffen). Ich hatte vorab (30.09.2022, ~20:00) bemerkt, dass die IPv4- bzw. IPv6-Internetverbindungen (zeitlich abwechselnd) zur DG zickten und geistesgegenwärtig den FB-Paketmitschnitt gestartet, um das Drama als Beweisstück live mitzuschneiden:

(Wireshark-Ansichtsfilter: "dhcpv6.xid==0x1bb801" + obfuscated):
No.	Time						Source						Destination					Protocol	Length	Info
57	2022-09-30 22:51:45,913383	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
58	2022-09-30 22:51:46,965400	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
59	2022-09-30 22:51:48,993437	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
60	2022-09-30 22:51:53,141353	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
61	2022-09-30 22:52:01,373383	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
	[Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL)]
62	2022-09-30 22:52:17,757382	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
63	2022-09-30 22:52:50,557403	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
64	2022-09-30 22:53:56,149385	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
65	2022-09-30 22:56:07,357499	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
67	2022-09-30 23:00:29,789523	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
69	2022-09-30 23:09:14,685490	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
70	2022-09-30 23:26:44,509363	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
74	2022-10-01 00:01:44,189357	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
75	2022-10-01 00:58:32,317417	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
76	2022-10-01 01:02:32,337991	fe80::ff:fe05:101			fe80::9a9b:cbff:feNN:NNNN	DHCPv6		100		Advertise XID: 0x1bb801 CID: 00030001989bcbNNNNNN 
77	2022-10-01 02:00:30,057495	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
	[Internetverbindung IPv6: DHCPv6-Fehler mit Fehlergrund 8 ()]
78	2022-10-01 02:58:00,285604	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
	[Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL)]
79	2022-10-01 03:57:15,293478	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
80	2022-10-01 04:58:33,057486	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
81	2022-10-01 04:58:33,073026	fe80::ff:fe05:101	fe80::9a9b:cbff:feNN:NNNN			DHCPv6		223		Advertise XID: 0x1bb801 CID: 00030001989bcbNNNNNN IAA: 2a00:6020:1000:42::WXYZ 
82	2022-10-01 04:58:33,073502	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		227		Request XID:   0x1bb801 CID: 00030001989bcbNNNNNN IAA: 2a00:6020:1000:42::WXYZ 
83	2022-10-01 04:58:34,021499	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		227		Request XID:   0x1bb801 CID: 00030001989bcbNNNNNN IAA: 2a00:6020:1000:42::WXYZ 
85	2022-10-01 04:58:34,238941	fe80::ff:fe05:101	fe80::9a9b:cbff:feNN:NNNN			DHCPv6		223		Reply XID:     0x1bb801 CID: 00030001989bcbNNNNNN IAA: 2a00:6020:1000:42::WXYZ 
	[Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2a00:6020:1000:42::WXYZ]
	[IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:46PQ:RS00::/56]

Besonderheiten:

• Die Eventlog-Messages meiner Fritzbox habe ich jeweils in [ ] unter die Mitschnitt-Zeilen geschrieben, deren Uhrzeit mit der Uhrzeit der Eventlog-Message übereinstimmen.
• Die "Advertise"-Message (No. 76) enthielt den DHCPv6-Status-Code "UnspecFail"

Man sieht sehr schön, dass die Fritzbox die Zeitabstände, beginnend mit 1s, zwischen den Wiederholungen ihrer DHCPv6-Solicits stets verdoppelt ("exponential backoff": 1, 2, 4, 8, 16, ..., 2048) und anschließend (ab No. 75) in konstanten Abständen von ~1h sendet.

Ob die Eventlog-Message "DHCPv6-Fehler mit Fehlergrund 8" (No. 77), die auch der OP erwähnt, in meinem Fall aufgrund des vorangegangenen "UnspecFail"-Advertise oder aufgrund der schon lange verstrichenen Zeit (~3,5h) erfolgloser Bemühung angezeigt wird, vermag ich nicht zu beurteilen. Überhaupt ist das Fehlermitteilungsverhalten der Fritzbox sehr sparsam und kryptisch ...

Ich hatte den DG-GF-Anschluss damals seit etwa einem Jahr - in dieser Zeit kam es gelegentlich zu solchen Ausfällen, deshalb war ich auch schon entsprechend sensibilisiert. Seitdem läuft mein Anschluss aber stabil, und ich hoffe, das bleibt auch so (klopf auf Holz).

Zitat von CityCobra

IPv6-Adresse: 2a00:6020:1000:xxx
IPv6-Präfix: 2a00:6020:b40f:da00::/56

Der Anschluss müsste somit am "BNG-Cluster 4" Düsseldorf hängen ("alte" IPv6-Provisionierung, u.a. auch zuständig für den Block 2a00:6020:b400::/41) - dieser taucht in Inbound-Traceroutes mit der Adresse 2a00:6020:ffff:ffff::3 auf.

Die WAN-Adresse müsste genauer in 2a00:6020:1000:1a::/112 liegen (die letzten 4 Ziffern sind individuell für deinen Anschluss, genauso wie die Ziffern "0f:da" deines Anschlusses im /56-Präfix)

Nachtrag:

Dieser Traceroute bestätigt es:

Dein WAN-Interface lässt sich auch anpingen - Standard bei Fritzboxen.

Zitat von pufferueberlauf

Dass die DG momentan ihre IPv6-Provisionierung aendert ist kein Geheimnis und auch nicht, dass das nicht so geschmeidig und unauffaellig ablaeuft wie man sich das wuenschen wuerde.

Nach meinen Beobachtungen aufgrund der vielen Fälle, die wir hier im Forum schon hatten, stellt man bisher offenbar keine Bestands-Anschlüsse um, die nach alter IPv6-Provisionierung funktionieren (erkennbar an den WAN-Port-Adressen aus 2a00:6020:1000::/48 bzw. genauer 2a00:6020:1000:XX::/112, wobei XX eine spezifische 2-stellige Kennung des BNG-Clusters ist).

Die neue Provisionierung erfolgt bisher offenbar nur für IPv6-Ranges, die bisher nicht für Bestandsanschlüsse mit Alt-Provisionierung verwendet wurden - hier eine (sicherlich unvollständige) Liste aus meiner Statistik (wie bei der Alt-Provisionierung sind es jeweils /41-Ranges pro BNG-Cluster), Stand 20.08.2026:

Diese Ranges kommen vorrangig in BW, teilweise auch in RP und SL zum Einsatz, also grob im Südwesten der Republik.

Ob IPv6 beim Anschluss des OP nach neuer IPv6-Provisionierung erfolgt, wissen wir leider nicht, solange der zugeordnete IPv6-Präfix bzw. die WAN-Port-Adresse nicht bekannt sind.

Nachtrag 20.06.2026:

Entgegen meiner Aussage oben scheint DG nun doch auch Bestandsanschlüsse mit "alter" IPv6-Adress-Provisionierung" auf die "neue" umzustellen. Das kann man z.B. an der RIPE-Atlas-Probe #53717 (NW: PLZ 41472) sehen, die heute um ~ 08:10 (UTC) vom alten IPv6-Präfix 2a00:6020:a302:5100::/56 (am BNG 100.124.1.60/2a00:6020:ffff:ffff::41) auf den Präfix 2a00:6020:6940:9::/64 (!) umgestellt wurde (/64 statt /56 folgere ich mit hoher Wahrscheinlichkeit aus der "kaputten" ":9::" im Präfix - neue IPv6-Adress-Provisionierung aus dem Auftauchen der "BNG-Verschleierungsadresse" fc00::1 in Traceroutes "von außen" zur Netzadresse des Anschlusses)

Prompt sendet die Probe ab Umstellung keine IPv6-Daten mehr:

Zitat von ctr

Meine Interface IP hat sich vom Block `2a00:6020:1000:41::` in `2a00:6020:1000:40::`und das announcte Präfix von `2a00:6020:5080::/41` in `2a00:6020:5000::/41` (41bit maske laut info von user ::1) geändert

Wie man mit dieser RIPE-Abfrage ermitteln kann, werden beide Blöcke (aggregiert: 2a00:6020:5000::/40) durch den "Frankfurt-BNG-Cluster1" bedient:

Die Wartung bestand wohl u.a. darin, die DG-Kundenanschlüsse Cluster-intern umzuverteilen ...

Diese RIPE-Atlas-Probe (2a00:6020:50c7:5f00:a2f3:c1ff:fec4:5c01) müsste am selben BNG (2a00:6020:ffff:ffff::e, 100.124.1.11) hängen wie dein Anschluss - sie ist allerdings "connected" und liefert IPv6-results. Es scheinen also nicht alle Anschlüsse an diesem BNG betroffen zu sein.

Zitat von ctr

Derzeit habe ich noch eine Interface IP aus dem 2a00:6020:1000:41:: Block und quasi-statische IPv6.

Da müsstest du so im PLZ-Gebiet 66xxx/67xxx (SL/RP) liegen (IPv6-Range 2a00:6020:5080::/41) - ich habe noch nicht gesehen, dass dort auf das "neue" Adresskonzept umgestellt wird.

Korrektur:

In SL gibt es tatsächlich eine RIPE-Atlas-Probe (#29306), die an einem DG-Anschluss mit "neuem" Adresskonzept hängt (IPv6-Range 2a00:6020:5380::/41).

Zitat von ctr

Die Gegenstelle sendet NS und und NA

Ist denn in den NA der Gegenstelle das R-Flag gesetzt? Ich vermute mal, nein. Denn andernfalls hätte die Unify-Selbst-Konstruktion der Gateway-Adresse evtl. funktioniert.

Zitat von ctr

Die default route kam trotzdem per RA

Wieso "trotzdem"? In Verbindung mit DHCPv6 (das im Gegensatz zu DHCPv4 keine "Gateway-Option" kennt), muss die Default-Route immer aus RA gelernt werden. Wenn die Gegenstelle keine sendet (=> Problem liegt auf DG-Seite), dann hast du eben kein Default-Gateway.

Sendet die Gegenstelle denn NS und antwortet sie mit NA auf die von deinem Router gesendeten NS?

Man könnte zur Grobmessung der Bandbreite der LAN-Verbindung zwischen PC und Fritzbox eine iperf-Messung durchführen:

• In der Fritzbox: Hilfe und Info | FRITZ!Box Support (ganz unten links) | Durchsatzmessungen:
  Hier die Option "Messpunkt für einen Iperf-Client im Heimnetz aktivieren, Port 4711 für TCP und UDP" aktivieren
  und auf "Einstellungen übernehmen" klicken.
• Am Windows-PC: Download von "iperf2" von hier: https://sourceforge.net/projects/iperf2/ - die herunter geladene Datei "iperf-2.2.1-win64.exe" im Download-Ordner zweckmäßigerweise in "iperf.exe" umbenennen.
• In eine Eingabeaufforderung (Windows-Terminal) in den Download-Ordner wechseln und folgendes Kommando ausführen:
  iperf -c fritz.box -p 4711

In meinem Fall (Fritzbox 5590) mit Gigabit-Ethernet zu meinem LAN-Windows-PC erhalte ich folgendes Ergebnis:

D:\Downloads\Software\Tools\IPerf\V.2.2.1>iperf -c fritz.box -p 4711
------------------------------------------------------------
Client connecting to fritz.box, TCP port 4711
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  1] local 192.168.178.10 port 63404 connected with 192.168.178.1 port 4711
[ ID] Interval       Transfer     Bandwidth
[  1] 0.00-10.02 sec  1.06 GBytes   912 Mbits/sec

Der Wert unter "Bandwidth" sollte nicht deutlich kleiner als 1000 Mbit/s sein.

Vielleicht klappt es mit der automatischen Geschwindigkeitsaushandlung zwischen LAN-Adapter des PC und dem LAN3-Port der FB nicht so recht. Deshalb in den Treiber-Einstellungen des LAN-Adapters versuchsweise mal von "Automatisch" auf "1 GBit/s full duplex" umstellen.

Zitat von HubeBube

Nur Clients, die DNSSEC validierende DNS-Server in ihrer Konfiguration (üblicherweise im Router) hatten sind auf die Probleme gestoßen.

Zumindest wurde somit offenbar, dass die dynamisch von der DG zugewiesen DNS-Server (richtiger ist eigentlich der Begriff "DNS-Resolver") dnscache001.dg-w.de (185.22.44.50, 2a00:6020:100::1) und dnscache002.dg-w.de (185.22.44.50, 2a00:6020:200::1) validierende Resolver sind (was ja sehr gut ist). Denn mit diesen hatte ich das Problem gestern auch (aber erst, nachdem "de"-Einträge in deren Cache nach TTL-Ablauf gelöscht wurden), mit meinem lokal am Client installierten und für die DNS-Auflösung benutzten validierenden Resolver "unbound" bemerkte ich das Problem hingegen früher.

Hier der Erklärbar von Heise per Video.

Versuche es in den IPv6-Einstellungen mal mit der Konfiguration "Native IPv4-Anbindung verwenden" - das ist die empfohlene Einstellung an einem DG-Anschluss (ändert nur die Reihenfolge: erst IPv4 via DHCP, dann IPv6 via DHCPv6 - so gefällt es DG besser, andersherum dauert es erfahrungsgemäß deutlich länger).

Aber ja: Die DHCP-/DHCPv6-Fehlermeldungen deuten klar auf eine Fehlersituation bei der DG hin, sofern du deinerseits zuvor nichts geändert hast.

Zitat von Ralle52

Heute neue Anweisung von Deutsche Glasfaser bekommen und direkt ausprobiert:
Öffnen Sie die Benutzeroberfläche, indem Sie http://fritz.box in Ihrem Browser eingeben.
Melden Sie sich mit Ihrem FRITZ!Box-Passwort an.
Gehen Sie zu Internet → Zugangsdaten → IPv6.
Aktivieren Sie IPv6:

Setzen Sie ein Häkchen bei „IPv6-Unterstützung aktiv“
Wählen Sie „Native IPv6-Anbindung verwenden“
Falls dies nicht angezeigt wird, wählen Sie „IPv6-Anbindung über Tunnelprotokoll“ (z.?B. 6to4)
Klicken Sie anschließend auf Übernehmen.

Alles anzeigen

Das ist also eine Anweisung der "Deutsche Glasfaser" - die sollte eigentlich wissen, dass keine der Tunnel-Lösungen an ihrem Anschluss funktionieren würde:

• 6to4 (RFC3056, RFC3068) funktioniert nicht an IPv4-Anchlüssen hinter einem CGNAT (wie es bei DG der Fall ist). Das ginge höchstens mittels "6to4-PMT" (RFC6732) - das dazu erforderliche 6to4-PMT-Relay müsste DG für seine Kunden betreiben. Das wird DG als nativer IPv6-Anbieter aber sicherlich nicht tun.
• Auch im Fall von 6rd (das ist die bessere Alternative zu 6to4-PMT, weil per se CGNAT-kompatibel) müsste DG für seine Kunden ein 6rd-Relay betreiben, tut dies als nativer IPv6-Anbieter aber sicherlich ebenfalls nicht. Außerdem hätte DG dann dem Kunden auch die 6rd-Konfigurationsparameter mitteilen müssen, die im Router einzutragen wären (die in der Fritzbox vorbelegten Werte entsprechen 6to4 - und das würde nur in Verbindung mit 6to4-PMT funktionieren - siehe letzter Spiegelstrich).

Mit scheint, der Service-Mitarbeiter der DG hat hier eine KI-Antwort einfach ohne irgendeinen Funken von Verständnis an seinen Kunden weitergegeben - schöne neue Welt.

Zitat von samael

aber hab deinen Text in chatGPT reingeworfen plus meine "ip a" Ausgabe

Na, dann hoffe ich mal, dass das, was immer du als Ergebnis der KI-Aktion irgendwo konfiguriert hast, auch von Dauer ist.

Ehrlich gesagt: Mich gruselt es vor einer Zukunft, in der Menschen auf Basis irgendwelcher KI-Ergebnisse, die sie nicht verstanden haben, irgendetwas produzieren, das sie genauso wenig verstehen, geschweige denn in der Lage wären, Fehler, die dieses KI-generierte Produkt seinerseits produziert, mangels Wissen bzw. Verständnis zu analysieren und zu beheben.

Eine Fritzbox richtet eine Freigabe anhand dessen ein, was sie als sog. "IPv6-Interface-ID" des freizugebenden Gerätes (falls man es anhand seines Gerätenamens auswählt) interpretiert. Seitdem man aus Gründen vermeintlicher Privacy jedoch seitens der Geräte zunehmend die Verwendung von aus einer festen Geräte-MAC-Adresse abgeleiteten "Modified EUI64" als IPv6-Interface-ID vermeidet (erkennbar an der Zeichenkette "ff:fe" in deren Mitte), ist für die Fritzbox leider nicht mehr klar, welche der mehreren Interface-IDs die richtige ist.

Korrekt wäre die "IPv6-GUA", aber leider kann das bei fehlender "ff:fe"-Zeichenkette auch der Identifier sein, den die Fritzbox als "IPv6-GUA-Temporary" führt.

Man muss deshalb am freizugebenden Gerät selbst ermitteln, was deren permanente globale IPv6-Adresse ist und deren Interface-ID (die hinteren 64 Bits) manuell in der Fritzbox in der Heimnetz-Konfiguration des Gerätes als deren IPv6-Interface-ID eintragen (d.h. überschreiben, falls abweichend).

Sodann muss man noch hoffen, dass das Gerät es mit der Privacy nicht auf die Spitze treibt und auch noch in bestimmten Zeitabständen und/oder nach Neustarts ihre MAC-Adresse und somit ihre "permanente" IPv6-Interface-ID ständig ändert. Das wäre "der Tod" jeder Freigabe in einem vorgelagerten Internet-Router, denn die lebt davon, dass sich zumindest die "IPv6-Interface-ID" des freizugebenden Gerätes niemals ändert.

Falls das Ziel direkt mit der IPv6-Adresse angesprochen wird, darauf achten, dass die Adresse in [] gesetzt werden muss:

http://[2a00:...]:12947

Zur DHCPv6-Leasedauer:

An meinem DG-Anschluss (nach "altem" Adress-Standard) zeigt ein Paketmitschnitt den folgenden Inhalt einer DHCPv6-Reply-Message:

DHCPv6
    Message type: Reply (7)
    Transaction ID: 0x1855ea
    Client Identifier
    Server Identifier
    Identity Association for Non-temporary Address
        Option: Identity Association for Non-temporary Address (3)
        Length: 40
        IAID: 553eb839
        T1: 1800 <--
        T2: 2880 <--
        IA Address
            Option: IA Address (5)
            Length: 24
            IPv6 address: 2a00:6020:1000:██::████
            Preferred lifetime: 3600 <--
            Valid lifetime: 3600     <--
    DNS recursive name server
    Identity Association for Prefix Delegation
        Option: Identity Association for Prefix Delegation (25)
        Length: 41
        IAID: 553eb839
        T1: 1800 <--
        T2: 2880 <--
        IA Prefix
            Option: IA Prefix (26)
            Length: 25
            Preferred lifetime: 3600 <--
            Valid lifetime: 3600     <--
            Prefix length: 56        <--
            Prefix address: 2a00:6020:4███:██00::

Sowohl für die WAN-Port-Adresse des Routers (IA_NA) als auch für den LAN-PD-Block (IA_PD) gilt:

Leasedauer = "Preferred lifetime" = "Valid lifetime" = 3600s.

Laut DHCPv6-Standard ergeben sich daraus die folgenden Werte für den ...

• Renew-Timer T1 = 0.5 * Leasedauer = 1800s
• Rebind-Timer T2 = 0.8 * Leasedauer = 2880s

Die IA_PD "Prefix length" beträgt standardmäßig /56

Zur Erinnerung:

Um zu verhindern, dass die Leasedauer abläuft und die IPv6-Adressen damit ungültig werden, sendet der Router rechtzeitig (nach Ablauf von T1) einen DHCPv6-Renew-Request, der vom DHCPv6-Server (der die Lease zugeteilt hat - wie unter "Server Identifier" angegeben) üblicherweise mit einem DHCPv6-Reply beantwortet wird. Das setzt die Leasedauer wieder auf den Maximalwert.

Erhält der Router keine Antwort, so sendet er nach Ablauf von T2 einen DHCPv6-Rebind-Request, der sich diesmal jedoch unspezifisch an alle erreichbaren DHCPv6-Server richtet (sofern es mehrere gibt), in der Hoffnung, dass evtl. ein anderer DHCPv6-Server die Lease verlängert (habe ich in Paketmitschnitten am DG-Anschluss auch schon gesehen).

Erst wenn auch ein DHCPv6-Rebind-Request unbeantwortet bleibt, läuft die Leasedauer ab, und der Router verliert seine IPv6-Adressen. Er startet anschließend einen neuen DHCPv6-Exchange - aber es kommt bis zum Erhalt neuer Adressen zu einer Netzunterbrechung.

Eine kurze Leasedauer von 600s skaliert entsprechend auch T1 (300s) und T2 (480s) nach unten. Es läuft dann im Vergleich zum Standardfall eben alles 6-fach öfter.

----------------------------------------------------------------------------------

Warum DG an neueren Anschlüssen die Leasedauer so signifikant absenkt und auch nur noch einen LAN-PD-Block der Größe /64 spendiert, erscheint mir rätselhaft. Auch die quasi-permanente Adresszuweisung scheint hier wegzufallen, alle paar Tage werden geänderte Adressen zugewiesen.

Zitat von themaze

Ich habe gerade festgestellt das meine Leitung von ehemals 1000/500 MBit zu 50/25 Mbit.

Das liegt am relativistischen Effekt der Zeit-Dilatation im Wurmloch.

Zitat von themaze

Also habe ich gerade Schrödingers Internetanschluss. Keine Ahnung wie, von wem und warum aber irgendwie (noch) da.

Der Transitionsprozess ist vermutlich in einem Wurmloch stecken geblieben. Jetzt sind beide Zugängen auf ewig miteinander verschränkt.