Beiträge von ::1

sieht gut/normal aus -- Klare Bevorzugung von IPv6 gegenüber IPv4 und ohne Errors und Timeouts.

Generelle Bevorzugung von IPv6 gegenüber IPv4 bringt mich zu dem Ansatz, dass ein Download von einer Site, die ebenfalls dualstack ist, einerseits bevorzugt über IPv6 erfolgt, und andererseits nur halb so schnell, wie wenn sie über IPv4 erfolgen würde.

Und wenn dass für alle derartigen Download-Sites so ist, wäre der Denkansatz, dass die IPv6-Downloadrate im Vergleich zur IPv4-Downloadrate schon seitens des Providers 1&1 gebremst wird.

Müsste man durch Download-Tests derselben Test-Daten von mehreren DualStack-Sites, jeweils einmal per IPv4 und einmal per IPv6 (z.B. ein einem LAN-PC das jeweils anderen Protokoll deaktivieren) durchmessen, um diesen Verdacht zu erhärten.

Ist hier allerdings OT - vielleicht einen eigenen Thread aufmachen?

Zitat von mpexx

Ich habe aber ein ganz anderes Problem: Sobald / Solange ich IPv6 nutze habe ich nur gut 500 MBit/s im Downstream. Schalte ich IPv6 (am PC) ab, sind es 1000. Habe das auch mit verschiedenen Linux PCs und einem MAC nachstellen können.. 😵‍💫

Strange - was sagt denn der "Happy Eyeballs"-Test?

Zitat von mpexx

Mit DHCPv6 auf der WAN Schnittstelle, bekommt die Schnittstelle selbst keine IPv6, aber das o.g. Prefix zum Delegieren. Mit SLAAC ebenfalls das /56er Prefix und eine extra IPv6 fürs WAN Interface.

Das ist interessant - dass 1&1 hier für das WAN-Interface offenbar SLAAC statt DHCPv6 (IA_NA) verwendet. Ist aber auch eine zulässige Methode. Danke für diese Info!

Ja, das BNG (62.214.63.98, 2001:1438::62:214:63:98), an dem dein Anschluss hängt, scheint eines zu sein, das /56 delegiert, wie auch für diese (#32121) dort befindliche RIPE-Atlas-Probe bestätigt wird (deren PD-LAN-Block sich nach dem Muster 2001:16b8:35XX:XX01:: ändert).

Insofern widerspricht deine Meldung meiner These, dass "echte" Dual-Stack-Anschlüsse am BNG (62.214.63.216, 2001:1438::62:214:63:216) "gesammelt" werden.

Bleibt die Frage, ob sich das /64-Problem auf das letztgenannte beschränken lässt.

Falls von Interesse: Die RIPE-Atlas-Daten sind m.E. immer wieder "Gold" wert: Je nachdem, was man sucht, wird man in der Regel auch fündig - einstweilen erfordert das allerdings etwas detektivisches Gespür.

Wenn man sich bspw. für Latenzwerte aller aktiven RIPE-Atlas-Probes an Anschlüssen eines bestimmten Providers (Angabe durch AS-Nummer) interessiert (z.B. DG mit AS-Nummern 60294 für IPv6 und 8899 für IPv4), so kann man sich IPv6- bzw. IPv4-Traceroute-Messungen zu "well-known"-Zielen (hier: Google, Facebook, Wikipedia) heraussuchen, in die weltweit alle Atlas-Probes einbezogen sind, und die Ergebnisliste nach der gewünschten AS-Nummer filtern.

So kommt man für DG zu insgesamt 6 Listen mit jeweils etwa 50 Einträgen ("Records per Page" auf 100 umstellen), die die Latenzwerte (Spalte "Min RTT") in aufsteigender Reihenfolge anzeigen:

• Messung 86691235: IPv6-Traceroute zu google.com für ASN=60294
• Messung 86691225: IPv4-Traceroute zu google.com für ASN=8899
• Messung 86710364: IPv6-Traceroute zu facebook.com für ASN=60294
• Messung 86710104: IPv4-Traceroute zu facebook.com für ASN=8899
• Messung 86710304: IPv6-Traceroute zu wikipedia.org für ASN=60294
• Messung 86710103: IPv4-Traceroute zu wikipedia.org für ASN=8899

So kommt man für Google und Facebook (für beide Protokoll IPv4/IPv6) auf einen Latenz-Range von etwa 2 - 23 ms und für Wikipedia auf einen Latenz-Range von 9 - 33 ms für IPv6 und 4 - 26 ms für IPv4.

Ich denke, somit bekommt man ein ganz gutes Gefühl für die Einordnung gemessener Latenzwerte am eigenen DG-Anschluss (oder ggf. auch anderer ISP/AS-Nummern, z.B. AS8881 für 1&1). Und es zeigt sich eben auch, wie abhängig das vom Internet-Ziel ist, da Wikipedia doch deutlich gegenüber Google und Facebook abfällt. Auffällig auch, dass die IPv4-Werte für Wikipedia signifikant besser sind als deren IPv6-Werte.

Der Zack-Test von AVM ist zwar schon besser geworden (bisher hat er eher Mondergebnisse angezeigt) - ich mache lieber mehrere Tests mit einer repräsentativen Auswahl bewährter Tools (nPerf, Ookla, Breibandmessung, ...), die dann auch etwa gleiche Ergebnisse liefern.

Hier mal mein Waveform-Bufferbloat-Test zum Vergleich (DG-Classic-Tarif 400/200 mit FRITZ!Box 5590 an Nokia-ONT). Guess what: Ich arbeitete einfach mit dem FB-Standard-Profil "Deutsche Glasfaser"...

Auch wenn du Bandbreitentests kritisch siehst - mach doch mal einen (z.B. mit Breitbandmessung) - einfach nur, um mal zu sehen, ob die nominellen Werte erreicht werden.

Ist LAN1 im Powermode?

In BW findet man 4 aktive RIPE-Atlas-Probes an DG-Glasfaser-Anschlüssen (AS8899/AS60294):

• an einem Frankfurter BNG (100.124.1.10, 2a00:6020:ffff:ffff::d) der DG:
  #29444, PLZ 69242, IPv4/IPv6-Latenz Google: 4-5 ms
  #54467, PLZ 68789, IPv4/IPv6-Latenz Google: 5-8 ms
• am BNG 100.124.1.92, 2a00:6020:ffff:ffff::58 (Ort unbekannt) der DG:
  #29722, PLZ 68526, IPv4-Latenz Google: 4-5 ms (IPv6 inaktiv)
• an einem BNG mit neuem IPv6-Adressvergabeverfahren (Ort+Adressen versteckt):
  #1014883, PLZ 71083, IPv4/IPv6-Latenz Google: 18-19 ms

An meinem DG-Anschluss (BNG in Nürnberg) betrugen die Latenzwerte zu Google etwa 8-10 ms, seit etwa 3 Wochen besteht aber eine Verschlechterung auf 20-24 ms.

Hankoor : Sehr interessant: Du hängst am 1&1-BNG mit der IPv4-Adresse 62.214.63.216 und der IPv6-Adresse 2001:1438::62:214:63:216.

Genauso wie der oben von mir erwähnte 1&1-Kunde mit der RIPE-Atlas Probe #61286, der auch nur einen /64 anstelle eines /56 bekommt (das BNG sieht man, wenn man Traceroute-Results dieser Probe anschaut).

Vielleicht gilt das für alle Kunden, die an diesem BNG hängen.

Nachtrag:

Vielleicht ist das das Sammel-BNG für Kunden mir "echtem" DualStack (hier öffentliche IP-Adresse aus 94.134.144.0/20 direkt am eigenen Router-WAN-Port). Dafür gibt es zum Ausgleich auch nur einen /64 für IPv6 anstelle eines /56 ... 🤣

Zitat von pufferueberlauf

Jain, wegen CG-NAT sehe ich gerade bei der DG IPv6 als relativ wichtig an... boeten die oeffentliche IPv4 (auch gegen milden Aufpreis) an, waere das laufene IPv6-Trauerspiel irrelevanter.

Für mich als reiner Internet-Konsument (der keinerlei Inbound-Connections benötigt) ist das irrelevant / brauche keine öffentliche IPv4-Adresse. Aber ich schätze immerhin, Internetziele möglichst über IPv6 erreichen zu können, ohne andernfalls die CGNAT-Krücke nutzen zu müssen.

Zitat von Hankoor

Macht die pauschale Aussage des 1&1 Kundenservice zu fehlendem Einfluss auf IPv6-Adressen zumindest erklärungsbedürftig.

... war bestimmt nur eine Ausrede, um dich abzuwimmeln.

Zitat von pufferueberlauf

die DG bekleckert sich ja oft auch nicht gerade mir Ruhm

beschränkt sich allerdings auf IPv6 - IPv4 scheint sie zu beherrschen - und das ist Stand heute (leider) immer noch das wichtigere Protokoll.

Ja, lt. meinen diversen Beobachtungen und Traceroutes zu 1&1 (via DG)-Anschlüssen (AS8881) ist die DG da IP- bzw. IPv6-technisch (AS8899/AS60294) völlig raus.

Wie da technisch der Übergang (im BNG oder nachgelagert) aussieht, vermag ich nicht zu beurteilen - hierzu gibt es im Forum aber auch Experten, die sich evtl. äußern können.

Insofern sehe ich auch keinen Grund, bezüglich des IPv6 /64-Problems DG zu belästigen. Ist allein ein 1&1-Problem.

Zitat von pufferueberlauf

Was allerdings den "Vorteil" hat, dass 1&1 das nicht einfach aussitzen kann, zumindest nicht ohne Entschaedigung zahlen zu muessen, weil ohne IPv6 ist ds-lite komplett "tot".

Dann sind wir aber sogleich bei der juristischen Dimension (wo Recht haben und Recht durchsetzen zwei verschiedene Dinge sind) - dies zusammen mit dem Totalausfall des privaten Internetzugangs wäre vom Stress-/Ärgerpegel meiner Gesundheit eher abträglich. Eine Entschädigung, wenn man sie denn erhält, gleicht das nicht wirklich aus.

Zitat von Hankoor

Spricht aber auch eher dafür, dass ich darauf bestehen muss, dass mein nächstes Ticket bis zur DG durchgereicht werden muss.

In solchen Fällen nicht mit zwei Fronten kämpfen zu müssen, ist für mich ein wichtiges Argument, mich mit dem geringeren Übel des Verbleibs bei DG anstelle eines möglichen Wechsels zu 1&1 abzufinden.

DS-Lite via PPPoE mit Zwangstrennung alle 24h klingt auch nicht gerade verlockend: Ist IPv6 weg, dann auch implizit IPv4. Bei DG hat man bei IPv6-Problemen i.A. immerhin noch IPv4 zur Verfügung.

Zitat von Hankoor

Die DG teilt sich ja irgendwie ein Ticketsystem mit 1und1.

Die teilen sich offenbar auch dieselben Probleme - auch bei DG gibt es Kunden, die nur mit einem /64 abgespeist werden (stets im Kontext der "neuen" IPv6-Vergabepraxis an neueren Anschlüssen, vgl. hier). Es gab hier im Forum diesbezüglich schon Fälle, bei denen es vorrangig um IPv6-Probleme ging und ein zugeordneter /64 anstelle eines /56 zwar zur Kenntnis genommen aber nur von untergeordnetem Interesse war.

Mir scheint, dass das ein Konfigurationsfehler seitens 1&1 ist. Ich schließe das aus dem Muster, nach dem täglich die IPv6-LAN-Präfixe der folgenden 1&1-Kundennetze (via DG und ehemals DG - jetzt AS8881) mit RIPE-Atlas-Probes wechseln:

• #32121: Wechselmuster: 2001:16b8:35XX:XX01:: --> täglich neuer /56 - okay
• #61286: Wechselmuster: 2001:16b8:70XX:XXXX:: --> täglich neuer /64 - nicht okay
• #1015147: Wechselmuster: 2001:16b8:39XX:XX02:: --> täglich neuer /56 - okay

Da ist also auch ein Anschluss dabei, der nur mit /64 beglückt wird, während die anderen beiden zeigen, dass /56 ebenso möglich ist.

Zitat von fiberv6

Vielleicht ist das einfach das Verhalten bei neuen Anschlüssen, dass die Lease Time zunächst 10 Minuten, und dann ab dem ersten Renewal 1 Stunde beträgt.

Danke für das Feedback! Dann scheint DUID-Type 2 auch ok zu sein.

Vielleicht noch ein(e) Gedanke/Idee:

Dein vRouter verwendet für DHCPv6 einen Client-Identifier des DUID-Typs 2 (DUID-EN), vgl. RFC9915 (chapter 11). Der ist eher ungewöhnlich. Üblicher sind die Typen 1 (DUID-LLT) und 3 (DUID-LL). Der DHCPv6-Server verwendet seinerseits einen Server-Identifier des Typs 3.

Vielleicht ist es einen Versuch wert, wenn du den DUID-Typ mal auf Typ 1 oder Typ 3 umstellst, sofern das bei deinem System möglich ist?

Ergänzung:

Das wird nicht das IPv6-Routing-Problem lösen - aber möglicherweise funktionieren dann die DHCPv6-Renews auf Anhieb.