Aus meinen Augen ist jeder selbst schuld wenn man für 5€ weniger zu 1&1 wechselt. Der Laden ist von vorne bis hinten auf Gewinnoptimierung ausgelegt. Egal ob Festnetz oder Mobilfunk, die Qualität bleibt da auf der Strecke.
Aber Werbung können sie. Gut bekommen dafür auch regelmäßig Abmahnung. 
Sowohl IPv4 als auch IPv6 sind Versatel/1&1 zugeordnet... ich wuerde vermuten DG und 1&1 verwenden einen L2-Tunnel (oder einen L3 Tunnel) und damit sollte die Provisionierung der DG weniger relevant sein?
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.
Aus meinen Augen ist jeder selbst schuld wenn man für 5€ weniger zu 1&1 wechselt.
Weiss nicht, die DG bekleckert sich ja oft auch nicht gerade mir Ruhm, was die Provisionierung angeht (was das kernigste Kerngeschaeft eines ISPÜs ist, fuer Internetzugang braucht es Internet-Protokolle).
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.
Das sieht für mich auch danach aus, als würde DG bei meinem Anschluss die physische bzw. Layer-2-Zugangsplattform stellen, während die IP-Session und das Routing über 1&1/Versatel laufen?
Macht die pauschale Aussage des 1&1 Kundenservice zu fehlendem Einfluss auf IPv6-Adressen zumindest erklärungsbedürftig. Aber ich kenne mich bei den Hardwaremodellen von Providern und geteilten Netzen natürlich auch nicht aus.
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.
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. Aber das ist natuerlich aus meiner Nerd-Sicht, m ir ist schon klar, dass viele Nutzer das aktuell gar nicht bemerken duerften (solange das nicht Dank HappyEyeballs zu Verzoegerungen kommt).
Macht die pauschale Aussage des 1&1 Kundenservice zu fehlendem Einfluss auf IPv6-Adressen zumindest erklärungsbedürftig. Aber ich kenne mich bei den Hardwaremodellen von Providern und geteilten Netzen natürlich auch nicht aus.
Anything goes 
theoretisch koennte man bestimmt etwas stricken wo 1&1 der DG ein Kontingent an IP Adressen zuweist, die die DG dann 1&1 Endkunden zuweist, aber Sinn macht das keinen...
war bestimmt nur eine Ausrede, um dich abzuwimmeln.
das waere auch mein Verdacht...
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.
Für mich als reiner Internet-Konsument (der keinerlei Inbound-Connections benötigt) ist das irrelevant / brauche keine öffentliche IPv4-Adresse.
Na ja, viele Wissen gar nicht ob sie das brauchen oder nicht... und z.B. fuer SIP/VoIP waere das "nice to have" aber fast alle SIP/VoIP Loesungen haben Work-Arounds fuer das Problem finden muessen (und z.B. O2 nutzt nur IPv4 fuer VoIP macht aber auch DualStack mit oeffentlicher IPv4).
Aber ich schätze immerhin, Internetziele möglichst über IPv6 erreichen zu können, ohne andernfalls die CGNAT-Krücke nutzen zu müssen.
Auch das ein Vorteil der in der Spitzenlastzeit Verzoegerungen vermeiden helfen kann.
Hoffe stark, dass auch die DG ihr neues Provisionierungschema irgendwann debugged bekommt und ab dann ganz langweilig zuverlaessiges IPv6 liefert, so wie in der Vergangenheit ja auch?
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 ... 🤣
Dafür gibt es zum Ausgleich auch nur einen /64 für IPv6 anstelle eines /56
Irgendwoher müssen die ganzen IPv4-Adressen ja herkommen. /s
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 ... 🤣
Das ist eine interessante These!
Wenn noch weitere 1&1über DG Kunden ihre traceroute Ergebnisse zu den Google DNS Servern Posten würden und dabei vermerken würden, ob Dual Stack oder DS-Lite zum Einsatz kommt, könnte man diese These erhärten oder wiederlegen.
Hallo zusammen,
ich nutze ebenfalls 1&1 im DG Netz (Saarland) mit richtigem Dual Stack.
Hier ein traceroute (linux) von mir:
❯ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 unifi (192.168.10.1) 0.160 ms 0.112 ms 0.139 ms
2 fra1813aihr001.versatel.de (62.214.63.98) 7.991 ms 7.881 ms 7.912 ms
3 62.72.71.113 (62.72.71.113) 12.936 ms 12.966 ms 5.820 ms
4 162.158.84.195 (162.158.84.195) 5.489 ms 5.795 ms 5.737 ms
5 162.158.84.194 (162.158.84.194) 12.079 ms 12.114 ms 12.153 ms
6 162.158.84.78 (162.158.84.78) 5.228 ms 4.813 ms 162.158.84.79 (162.158.84.79) 4.843 ms
7 162.158.84.251 (162.158.84.251) 6.128 ms 162.158.84.221 (162.158.84.221) 6.293 ms 162.158.84.133 (162.158.84.133) 5.608 ms
8 one.one.one.one (1.1.1.1) 5.300 ms 5.309 ms 5.201 ms❯ traceroute dns.google
traceroute to dns.google (2001:4860:4860::8844), 30 hops max, 80 byte packets
1 unifi (2001:16b8:359b:9200::1) 0.233 ms 0.262 ms 0.202 ms
2 2001:1438::62:214:63:98 (2001:1438::62:214:63:98) 12.600 ms 12.651 ms 12.661 ms
3 2001:1438::62:214:42:131 (2001:1438::62:214:42:131) 6.042 ms 6.263 ms 6.295 ms
4 2001:4860:1:1::6e9 (2001:4860:1:1::6e9) 5.798 ms 2001:4860:1:1::3ca5 (2001:4860:1:1::3ca5) 5.949 ms 2001:4860:1:1::6e9 (2001:4860:1:1::6e9) 5.816 ms
5 2001:4860:1:1::3ca4 (2001:4860:1:1::3ca4) 5.822 ms 2001:4860:1:1::6e8 (2001:4860:1:1::6e8) 6.128 ms 2001:4860:1:1::3ca4 (2001:4860:1:1::3ca4) 5.840 ms
6 2001:4860:0:1::86a7 (2001:4860:0:1::86a7) 6.272 ms 2001:4860:0:1::8677 (2001:4860:0:1::8677) 7.193 ms 2001:4860:0:1::86a7 (2001:4860:0:1::86a7) 5.509 ms
7 2001:4860:0:1::77f (2001:4860:0:1::77f) 5.250 ms 2001:4860:0:1::500d (2001:4860:0:1::500d) 5.434 ms 2001:4860:0:1::1589 (2001:4860:0:1::1589) 5.360 ms
8 dns.google (2001:4860:4860::8844) 5.522 ms 5.476 ms 5.230 msEs sieht so aus, als bekäme ich ein /56 Prefix, wenn ich das korrekt sehe:
WAN-Diag(ppp1): res-interfaces: Adding PD prefix 2001:16b8:359b:9200::/56 with lifetime 172790/259190 to interface ppp1
WAN-Diag(ppp1): prefix-delegation: Adding PD prefix 2001:16b8:359b:9200::/56 with lifetime 172790/259190 to interface ppp1Ich nutze eine UDM Pro.
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.
OT:
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.. 😵💫
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.
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!
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?
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?
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
