Unitymedia DOCSIS 3.0 IPv4 / IPv6 Durcheinander

[SpaceRat]

Ich meine mich zu erinnern, dass es für die VPN MTU einen separaten Eintrag in der Config gibt.

Ich sehe da keinen.

Ich weiß auch nicht, wieso Du soviel Energie in dieses Thema investierst.
Es gibt eine wunderbare Lösung und die heißt OpenVPN auf Raspberry Pis.

Damit kriegt man wunderbar alle drei Standorte vernetzt und man kriegt von unterwegs auch problemlos Zugriff auf sein(e) Heimnetz(e).
Wenn man will, dann kann man sich so sogar seinen eigenen IPv6-Tunnel für's Smartphone basteln, um auch bei Mobilfunk-Anbietern ohne Internet (Also o2 und Vaderphone) unterwegs Internet (Also IPv6) auf's Smartphone zu kriegen.
Dazu funktioniert das Ganze auch noch so wunderbar, daß man anders als beim integrierten VPN nicht vom Smartphone vorgeschrieben bekommt, wie man den Sperrbildschirm zu entsperren hat, es geht weiterhin auch reines Wischen.

Das AVM-VPN hat hingegen genau gar keinen Vorteil (Ok, man muß die paar Euros für einen notfalls gebrauchten Pi nicht investieren), es ist zudem auch noch schnarchlahm.

Für mich ist das, was Du hier machst, Jammern auf allerhöchstem Niveau.
Du hast offenbar genug Geld für drei Internetanschlüsse (und damit auch genug Geld für die drei Standorte), eine aktuelle Fritz!Box 7580, usw. usf.
Es fällt mir schwer zu glauben, daß es jetzt an 100 EUR bis maximal 210 EUR für drei Pis scheitert.

Und um mal ein paar der IPv4-Heulsusen zu schockieren:
Ihr könnt meine IPv4 haben und noch Eintausend Euro oben drauf, wenn Ihr mir dafür an meinem Wohnort einen Anschluß von Glasfaser Deutschand (Hat CGNAT, also auch keine IPv4) beschafft.

Ich sch... nämlich auf die IPv4. Aber worauf ich nicht sch... ist der enorme Datenverlust, den ich vor ein paar Tagen erlitten habe, weil dieser verk.... Kabel-R0tz-Anschluß keinen Upstream hat und mein Online-Backup ständig um Monate bis Jahre hinterherhinkt.
Der Aufwand den ich hier treiben muß, um trotz fehlendem Upstream halbwegs aktuelle Sicherungen zu haben ist in Geld gar nicht aufzuwiegen. Hier noch ein Verzeichnis aus der Sicherung ausschließen, weil sich der Inhalt zu schnell ändert, da noch eine externe Platte dranhängen und immer wieder prüfen, abstöpseln, wegräumen, austauschen, ...

Ich würde jubeln, wenn ich meine blödsinnige IPv4 "verlieren" dürfte, weil ich endlich Glasfaser mit 100-1000 MBit/s Upstream kriegen könnte.

Naja, ich hoffe, daß sich das mit den mittelmäßigen 40 MBit/s bei VDSL wenigstens etwas lindern wird.

 

[Andreas1969]

Ich mag halt die Fritzboxen (all in one)

 

[SpaceRat]

Ich mag halt die Fritzboxen (all in one)

Ja, und?

Wo ist das Problem, an die Witz!Boxen noch einen Raspberry Pi zu stöpseln?

Drucker, Fernseher, Computer, Smartphone, usw. hast Du ja wohl auch nicht in der Witz!Box drin.

 

[Andreas1969]

Ja, und?

Wo ist das Problem, an die Witz!Boxen noch einen Raspberry Pi zu stöpseln?

In der Tat, an Standort B habe ich sogar einen, nur an A und C noch nicht.

 

[Andreas1969]

Die Ursache für das nicht funktionierende VPN ist ja folgende (hatte ich vor längerer Zeit schon mal ausgeführt):

Ich versuche das Ganze jetzt einmal so zu erklären, daß es auch jeder versteht und um auch ein bisschen Licht ins Dunkle zu bringen.

Ich wollte mich nicht einfach damit zufriedengeben, daß die VPN-Verbindung nicht möglich ist, da ich ja mit meinem Notebook und mit einem Smartphone von der DSLITE Box aus den VPN Tunnel zur IPV4 Box aufbauen kann. Und da wird auch kein anderes Protokoll genommen.
Auf dem Notebook läuft der Fritz Fernzugang mit der erzeugten config Datei aus der Fritz! Fernzugangssoftware, womit auch die configs für die Boxen erzeugt werden und auf dem Smartphone habe ich den NCP VPN Client installiert. Beide Tunnel laufen tadellos.

Dann die berechtigte Frage:
Warum geht es da, und zwischen den beiden Boxen nicht ???

Um das Ganze zu analysieren musste ich mich auch erst einmal in die ganze Materie etwas einlesen.
Bei beiden Boxen wird das MSS Clamping-Verfahren (Maximum Segment Size) eingesetzt.
Dadurch wird der maximal mögliche MTU Wert automatisch ermittelt.
Dieser ist bei beiden Boxen 1500, IPV4 sowie DSLITE.

Jetzt kommt das wichtige:
Bei der IPV4 Box steht der MTU Wert 1500 komplett für IPV4 zur Verfügung, da ja IPV4 nicht getunnelt wird.
Bei der DSLite Box sieht es nun folgendermaßen aus:
IPv6: mtu 1500
IPv4: ds-lite only 2a02:908:4001 (de-pad09a-cr01.aftr.umkbw.net)
IPv4: ip 192.0.0.2 mask 0.0.0.0 gw 192.0.0.1 dhcp mtu1460
Wie man hier sehen kann, ermittelt die Box die max. MTUvon 1500, welche aber für IPV6 gilt.
Allerdings steht für IPV4 nur eine maximale MTU von 1460 zur Verfügung, das bekommt die Box
auch vom AFTR mitgeteilt, wie man in folgendem Log sehen kann:

21.08.16 16:26:46 Internetverbindung wurde erfolgreich hergestellt. 
IPv4 wird über DS-Lite genutzt. 
AFTR-Gateway: (de-pad09a-cr01.aftr.umkbw.net), IPv4-MTU: (1460)

Also weiß die DSLite Box, das für eine IPV4 Verbindung eine maximale MTU von 1460 möglich ist,
da sie ja auch für die lokalen IPV4 Clients eine MTU von 1460 zur Verfügung stellt.

Nun passiert beim Tunnelaufbau der beiden Boxen folgendes:
Beim aushandeln der maximal möglichen MTU meldet die IPV4 Box 1500, was ja auch richtig ist.
Allerdings greift die DSLite Box bei der übermittlung der max. möglichen MTU auf die per MSS Clamping-Verfahren ermittelten MTU zurück (1500 für IPV6) und nicht auf die vom AFTR-Gateway gemeldete MTU von 1460, welche auch für das lokale IPV4 Netz der DSLite Box gilt.
Genau das ist der Bug !!!

Die beiden Boxen einigen sich also beim Aufbau des Tunnels auf eine MTU von 1500.
Das kann man hier schön sehen:
XXXXXXXXXXXX.myfritz.net: pmtu 0 mtu 1500 dpd_supported dont_filter_netbios remote_nat

Richtig wäre aber eine MTU von 1460, da ja per IPV4 auf der DSLite Seite nicht mehr zur Verfügung steht.
Zur Erinnerung: IPV6 Protokoll = 40 Byte 1500-40=1460 Byte.

Durch diesen Umstand kommt es jetzt natürlich zur Fragmentierung der Pakete, welches eigentlich jeden Tunnel zerschießt.
Das kann man in folgendem Log sehr schön sehen:
2016-08-24 15:30:48 avmike:XXXXXXXXXXXX.myfritz.net
fehlerhafte Paketlaenge: Hdr-length > read-Data

Jetzt wird eigentlich auch der Rest logisch:

Vom Notebook und Smartphone klappt der Tunnel, da die Netzwerkadapter der Geräte von der DSLIte
Box für das lokale IPV4 Netz eine max. MTU von 1460 mitgeteilt bekommen.
Somit wird beim Tunnelaufbau eine max. MTU von 1460 ausgehandelt und die Paketdaten werden nicht mehr fragmentiert. Der Tunnel läuft sauber.

Wenn man nat_t deaktiviert, wird der Tunnel zwar aufgebaut, aber es fließen keine Daten.
Das ist auch logisch, da hier ESP als Protokoll portlos läuft und nicht in UDP gekapselt ist.
Dert Tunnel wird zwar aufgebaut, da beim Aushandeln der Verbindung keine großen Datenmengen fließen, aber die Nutzdaten werden verworfen, da sie fragmentiert sind. 

Wenn nat_t aktiviert ist, bricht der Tunnel sofort wieder zusammen.
Das ist auch logisch, da hier ESP in UDT gekapselt ist und die Nutzdaten in den Tunnelaufbau mit reinfliessen.

Es gibt ja auch diverse Meldungen im Netz, daß der Tunnel zwar aufgebaut wird, aber keine Daten fließen.
Das ist genau der Fall, wenn auf mind. Einer Seite nat_t deaktiviert ist.

Dann gibt es Meldungen von Usern, die mit DSLite garkeine Probleme haben.
Das ist genau so richtig, die haben nämlich auf der IPV4 Seite, das scheint wohl Anbieterabhängig zu sein,
eine max. MTU, die kleiner ist, als die max. MTU, welche vom AFTR gemeldet wird. In diesem Fall also 1460 oder kleiner. Da läuft der Tunnel dann.

Was mich jetzt wirklich an dieser Geschichte wundert, ist, daß bisher niemand so richtig das VPN Problem mit DSLite Angegangen ist, da es ja schon länger besteht.
Alle Berichte hierzu, die man findet, enden irgendwann und es gibt keine Statusmeldung, ob das Problem gelöst wurde.
Alle diese Nutzer müssen wohl irgendwann resigniert haben.

Ich hoffe auch, daß das jetzt einigermaßen verständlich war.

 

[Andreas1969]

Hier hatte ich wohl einen Knoten im Kopp :wand:
Des Rätsels Lösung ist mal wieder relativ einfach, ich habe wohl den Wald vor lauter Bäumen nicht mehr gesehen.
Die Fritzbox interpretiert ja die MTU für die VPN-Verbindung bei DSLITE-Anschlüssen falsch.
Wenn man jetzt ne zweite Fritzbox (im Routermodus) hinter die DSLITE Box knallt, dann bekommt die ja als Netzwerkgerät hinter der DSLITE-Box eine MTU von 1460 für IPV4.
Jetzt sollte auch die VPN-Verbindung zu einer IPV4 Box funktionieren. :winken:

 

[un1que]

Ich habe da noch kein Polster drin, aber das braucht man vielleicht auch nicht, denn:
Viele Dienste, die hohen Traffic mitbringen, gibt es auch per IPv6: Youtube und Netflix mal als Beispiel. D.h. solcher Traffic, obwohl er momentan v4 Traffic ist, liefe dann garnicht über den AFTR. Und in Zukunft wird immer mehr Traffic von v4 in Richtung v6 wandern, so dass es gut sein könnte, dass auch bei insgesamt steigendem Traffic eine geringe Menge AFTRs weiter ausreichend sind.

Denk dran, es gibt ein Haufen falscher Konfigurationen, wo einfach mal ein anderer Router dahinter geschaltet wird (bzw. die Endgeräte nur IPv4 können) und plötzlich läuft der ganze IPv6 Traffic über die AFTR's. Also so einfach bzw. reibungslos läuft es mit der Umstellung auf IPv6 sowieso nicht.

Will ich das mit 10GBit/s Maschinen machen, brauche ich mindestens 100 Stück, das sind dann 500k€.
[...]
Aber zur Sicherheit verdoppeln wir einfach die Menge. Dann gibt UM 1M€ für 200 AFTRs aus.
[...]
Auf eine Million mehr oder weniger kommt es dabei wohl nicht an

Ich kann mir kaum vorstellen, dass man bei UM so einfach mit Geld umherschmeißen kann. Ganz im Gegenteil, es wird an jeder Ecke gespart - siehe die Technikerproblematik, welche hier immer öfter angesprochen wird und auch die ständige Tariferneuerungspolitik (inkl. Tariferhöhungen, welche es bereits 2-3 mal gab), wo man sich über jedes € erfreut. Ich bleibe da bei meiner Meinung, dass UM nicht zuletzt wegen Kosteneinsparung die IPv4 Adressen nicht weggenommen hat (auch wenn sich deine Rechnung plausibel anhört und es dann "nur" 1Mio € wären).

 

[un1que]

Hier hatte ich wohl einen Knoten im Kopp :wand:
Des Rätsels Lösung ist mal wieder relativ einfach, ich habe wohl den Wald vor lauter Bäumen nicht mehr gesehen.
Die Fritzbox interpretiert ja die MTU für die VPN-Verbindung bei DSLITE-Anschlüssen falsch.
Wenn man jetzt ne zweite Fritzbox (im Routermodus) hinter die DSLITE Box knallt, dann bekommt die ja als Netzwerkgerät hinter der DSLITE-Box eine MTU von 1460 für IPV4.
Jetzt sollte auch die VPN-Verbindung zu einer IPV4 Box funktionieren. :winken:

Was genau erhoffst du dir mit dieser "tollen" Lösung? Ich meine da kannst du dir genau so den vorgeschlagenen Pi hinstellen und hast mehr davon (z.B. OpenVPN) bei geringeren Kosten (denn es müsste schon ein halbwegs aktuelleres FB Modell sein, damit du die ab-5Mbit-Upload per VPN stemmen kannst).

 

[Andreas1969]

Was genau erhoffst du dir mit dieser "tollen" Lösung?

Den VPN Bug in den Fritten nachweisen und an AVM mit der Bitte um Abstellung melden.
Ich habe hier in der Gegend einige Leute, die froh wären, wenn es endlich funktionieren würde, ohne zusätzliche Hardware einzusetzen. :winken:

 

[un1que]

Ok, hat sich für mich so angehört, als es ob DIE Lösung für dein Problem wäre :zwinker:
Darum sagte ich auch, dass ich dann doch lieber einen Pi hinstellen würde, statt einer zweiten FB.

 

[ctvrgdr]

Ich wollte nur mal auf die folgende Möglichkeit hinweisen:

Man kann z.B. bei Netcup einen VPS für 2-3€ im Monat mieten, der hat eine feste IPv4-Addresse und mehrere IPv6-Adressen.

Von Zuhause aus kann man dann via SSH über IPv6 einen Reverse Tunnel aufbauen, z.B. von einem Raspberry Pi aus, so dass die Daten dann transparent und verschlüsselt direkt nach Hause geleitet werden.

Auf dem RaspberryPi wäre dann ein Befehl z.B. `ssh -6 -R 0.0.0.0:80:192.168.1.11:8080:[VPS-IPv6-Adresse]%eth0` für den Tunnelaufbau nötig.

Alternativ wäre auch `ssh -R 0.0.0.0:80:192.168.1.11:8080:[VPS-IPv4-Adresse]%eth0`möglich, dann wird aber alles zusätzlich über den Gateway von UM laufen.

Wenn auf dem VPS dann aus dem Internet eine IPv4 Verbindung zu Port 80 aufgebaut wird (welcher auf der Adresse 0.0.0.0 hört, da ansonsten localhost benutzt wäre, und dieser Port somit auf dem VPS nicht für das Internet nutzbar ist), dann wird diese an den Port 8080 des Servers 192.168.1.11 im Heimnetz aufgebaut.

Das steigert zwar die Latenz, aber dafür hat man dann auch einen Server in der Cloud mit dem man rumspielen kann. SSH ist ein mächtiges Tool.

PS: Das geht nur mit TCP. Es kann auf dem VPS also nicht an einem UDP-Port gehört werden.

Dankesspenden an
IOTA-Addresse BTRUCJKGCMOK9FNRAKMPLLZUZRGYJYLLVUCL9LINXKUJDJGPWUDIHKTAQGWTOLYZWMISYGIKQELQQJEIDNHDY9XNGB
ETH-Addresse 0x29AFCEBCfDDe6bABcEa02BEFF3fc8BDFE47D05AA

 

[addicted]

`ssh -6 -R 0.0.0.0:80:192.168.1.11:8080:[VPS-IPv6-Adresse]%eth0`

Das Interface (der Teil "%eth0") brauchst Du bei global routebaren Adressen nicht, wenn Du kein besonderes Routing machst. Jemand, der besonderes Routing macht, nimmt bestimmt keinen SSH-Tunnel.
Besser, Du lässt unnütze Sachen weg, es gibt sonst einfach mehr Fehlerquellen.

Dankesspenden an

Ernsthaft?

 

[ctvrgdr]

Wollte nur mal einen Nachtrag machen, da ich mich heute in der misslichen Lage sah, dass ich auf DS-Lite heruntergestuft wurde.

Sache war die, dass ich ein Upgrade bestellt hatte, gestern die Hardware ankam und ich vor dem Aktivierungstermin "30.01" mal schauen wollte, was das neue Modem so macht, wenn ich es einfach mal in eine freie Dose stecke . Schwups wurde mein altes Modem blockiert, und das neue provisioniert. Da Wochenende, wird sich natürlich bis Montag-Dienstag die Dual Stack-Sache nicht erledigen. Mein Problem: Remote-Wohnung verbindet sich per IPv4 mit meinem VPN-Server, und wird so in's Netz meiner Wohnung integriert. Sie sendet Sensordaten wie Stromzähler (Solaranlage/Heizung), Wetterstation zu meinen Server. Zum Glück hatte ich das VPN über TCP laufen, auch mit DNS-Eintrag, so dass ich es nun mal ausprobiert habe.

Es klappt. Aber: in der sshd_config-Datei auf dem VPS muss man `GatewayPorts yes` eintragen, damit die Ports auch öffentlich zugänglich sind.

 

[Andreas1969]

Wollte nur mal einen Nachtrag machen, da ich mich heute in der misslichen Lage sah, dass ich auf DS-Lite heruntergestuft wurde.

Da bist Du anscheinend heute nicht der Einzige. :winken:
Gibt es hierfür eigentlich ein Schema :kratz:
In letzter Zeit passiert das ja immer öfters

 

[MartinDJR]

auf DS-Lite heruntergestuft

Kommt darauf an, welchen Anwendungsfall man hat:

Wenn man IPv6 verwendet (z.B. die neuste Spielkonsolengeneration eines bestimmten Herstellers), ist DS-Lite ein echter Vorteil gegenüber nativem IPv4.

Remote-Wohnung verbindet sich per IPv4 mit meinem VPN-Server, und wird so in's Netz meiner Wohnung integriert.

Wenn du VPN verwendest: Hat die "Remote-Wohnung" Dual-Stack (z.B. Telekom-Anschluss)?

Falls ja, kannst du die VPN-Verbindung über IPv6 machen...

Da bist Du anscheinend heute nicht der Einzige.
Gibt es hierfür eigentlich ein Schema
In letzter Zeit passiert das ja immer öfters

Bei einer Änderung des Vertrages (z.B. mehr Bandbreite) wird UM das wohl ab sofort machen - oder sogar machen müssen.

 

[Andreas1969]

Bei einer Änderung des Vertrages (z.B. mehr Bandbreite) wird UM das wohl ab sofort machen - oder sogar machen müssen.

Meinst Du, man wäre irgendwann gezwungen, auf Business zu wechseln :kratz:
Dann müssten aber bei Business noch ordentlich die Preise purzeln :winken:

 

[MartinDJR]

Bei einer Änderung des Vertrages (z.B. mehr Bandbreite) wird UM das wohl ab sofort machen - oder sogar machen müssen.

Meinst Du, man wäre irgendwann gezwungen, auf Business zu wechseln :kratz:
Dann müssten aber bei Business noch ordentlich die Preise purzeln :winken:

Nicht unbedingt: Ich kann mir auch vorstellen, dass innerhalb der nächsten Monate irgendein Ereignis kommt, das sowohl Provider als auch Hoster dazu zwingt, schneller als geplant auf IPv6 umzustellen.

Das Problem "IPv4-Adresse" wäre dann vom Tisch...

 

[Andreas1969]

Ich kann mir auch vorstellen, dass innerhalb der nächsten Monate irgendein Ereignis kommt, das sowohl Provider als auch Hoster dazu zwingt, schneller als geplant auf IPv6 umzustellen.

Wie muss ich das denn verstehen :kratz:
Weißt Du da schon was konkretes?

 

[MichaelBre]

Nicht unbedingt: Ich kann mir auch vorstellen, dass innerhalb der nächsten Monate irgendein Ereignis kommt, das sowohl Provider als auch Hoster dazu zwingt, schneller als geplant auf IPv6 umzustellen.

Und so entstehen Gerüchte...

 

[ctvrgdr]

Gibt es hierfür eigentlich ein Schema :kratz:
In letzter Zeit passiert das ja immer öfters

Glaube nicht, dass mich das betrifft. Ich hatte diese Woche das Upgrade bestellt, und im Chat explizit das Thema Dual Stack angesprochen, und mir wurde zugesichert, dass ich das auch haben werde.

Die Sache war ja die, das mein "Umschaltungstermin" der 30. Januar ist und ich das neu angekommene Kabelmodem (Connect Box ersetzt Cisco) einfach mal an's Kabelnetz angeschlossen habe, was dann die Umschaltung automatisch triggerte, so dass das Cisco nicht mehr nutzbar war, die Connect Box nun aktiviert war. Provisioniert wurde es mit der generischen 150-10-DS-Lite-Datei und ich gehe davon aus, dass die Techniker die Dual Stack-Konfiguration manuell zuweisen werden. Da aber Wochenende ist...

Ich mache mir da vorerst keine Gedanken.

auf DS-Lite heruntergestuft

Kommt darauf an, welchen Anwendungsfall man hat:

Wenn man IPv6 verwendet (z.B. die neuste Spielkonsolengeneration eines bestimmten Herstellers), ist DS-Lite ein echter Vorteil gegenüber nativem IPv4.

Naja, Dual Stack hat ja auch eine reine IPv6.

Remote-Wohnung verbindet sich per IPv4 mit meinem VPN-Server, und wird so in's Netz meiner Wohnung integriert.

Wenn du VPN verwendest: Hat die "Remote-Wohnung" Dual-Stack (z.B. Telekom-Anschluss)?

Falls ja, kannst du die VPN-Verbindung über IPv6 machen...

Es war so eingerichtet, dass die Remote-Wohnung sich bei mir einloggt, und ich kann da nicht so auf die schnelle hingehen und Konfigurationen ändern. Insofern war DNS-Eintrag auf den VPS richten und von mir aus dorthin einen Reverse Tunnel aufzubauen die einzige Möglichkeit, die Wohnung wieder einzubinden. Ich könnte jetzt die Konfiguration ändern, werde aber erstmal abwarten, bis ich die IPv4 habe.

Ich glaube die Remote-Wohnung, die bei der Telekom bedient wird, hat Dual Stack, da es anfangs Probleme mit der SIP-Telefonie gab, und ich denen ein Ultimatum stellte, entweder sie ermöglichen es mir SIP zu benutzen, oder ich kündige (noch in der ersten 2-Wochen-Frist). Da haben die dann von DS-Lite auf Dual Stack umgestellt. Allerdings wechselt dort die IP wöchentlich (müsste also dynamisches DNS nutzen), was bei Unitymedia nicht der Fall war.

Als ich vor ca 1.5 Jahren mal ausprobierte bei mir in der Wohnung IPv6 zu nutzen, was wegen meines Doppel-Nat nicht ganz so trivial war und letztendlich daran scheiterte, dass das Cisco-Kabelmodem kein IPv6 Prefix Delegation unterstützte (andere Lösungen kommen aus Sicherheitsgründen nicht in Frage), hatte ich das Gefühl, dass das mir zugewiesene IPv6-Subnetz sich änderte. Ich dachte da an einen Zusammenhang mit IPv6 Privacy Extension, bin mir da aber nicht ganz sicher. Jedenfalls ist es für mich ungemein komplizierter was über IPv6 aufzubauen als über IPv4, und in der Konfiguration der Remote-Wohnung, die auch im Doppel-Nat läuft, möchte ich noch weniger ändern, da, wenn ich mich dort aus versehen ausschließe (falsche Route oder sonstwas), ich eine Reise antreten muss nur um etwas Rückgängig zu machen.

Also ist grad das VPN über einen halben Remote SSH Tunnel eine gute Lösung für mich. Sollte die Connect Box IPv6 Prefix Delegation unterstützen, und ich immer das gleiche Subnetz verwenden können, dann werde ich das mal ausprobieren.

In letzter Zeit passiert das ja immer öfters

Bei einer Änderung des Vertrages (z.B. mehr Bandbreite) wird UM das wohl ab sofort machen - oder sogar machen müssen.

Also mir wurde es vor Vertragsabschluss am Dienstag zugesichert (per Chat), sonst hätte ich kein Upgrade gemacht. Ich mache mir da keine großen Sorgen.

In meinem Produkt-Listing im Kundencenter steht unter Produktart auch Dual Stack drin.

 

[MartinDJR]

Ich kann mir auch vorstellen, dass innerhalb der nächsten Monate ...

Und so entstehen Gerüchte...

Erstens: Ich habe geschrieben: "Nicht unbedingt" und "ich kann mir auch vorstellen".

Zweitens: Ist eigentlich nur die Frage, wie viele Monate die "nächsten Monate" sind:

Mehrfach vergebene Adressen haben bereits Mitte 2015 dazu geführt, dass ein ganzer Provider plötzlich keine Verbindung mehr in bestimmte Länder hatte. Und im verlinkten Bericht steht auch, dass davon ausgegangen wird, dass diese Probleme mit knapper werdenden Adressen zunehmen werden.

Vor diesem Hintergrund bin ich mir absolut sicher, dass sich IPv4 nicht dauerhaft im Internet halten kann. Ist halt die Frage, ob 2 oder 20 Jahre.

Naja, Dual Stack hat ja auch eine reine IPv6.

Ach so. Ich dachte du hättest vorher IPv4-only gehabt. Echten Dual-Stack haben wohl nur sehr wenige UM-Kunden bekommen...

 

[Andreas1969]

Ich glaube die Remote-Wohnung, die bei der Telekom bedient wird, hat Dual Stack, da es anfangs Probleme mit der SIP-Telefonie gab, und ich denen ein Ultimatum stellte, entweder sie ermöglichen es mir SIP zu benutzen, oder ich kündige (noch in der ersten 2-Wochen-Frist). Da haben die dann von DS-Lite auf Dual Stack umgestellt.

Bei der Telekom gibt es kein DSLITE :winken:
Die schalten nur Dual Stack oder bei Altkunden IPV4 only.

Also mir wurde es vor Vertragsabschluss am Dienstag zugesichert (per Chat), sonst hätte ich kein Upgrade gemacht. Ich mache mir da keine großen Sorgen.

Die würde ich mir aber schon machen. Von automatisch stellt sich das nicht wieder um.

 

[ctvrgdr]

Ich sehe grad, dass man bei der Telekom folgendes einstellen kann:

Telekom Privacy Policy:
Off
Level 1
Level 2

Gibt es so was auch bei Unitymedia? Hat man bei UM auch ein wirklich statisches IPv6-Subnetz, oder verändert es sich regelmäßig?

https://imgur.com/a/G9EHZ

 

[Conan179]

bei um bekommt man einen /56 block ztugewiesen.

 

[ctvrgdr]

Ich glaube die Remote-Wohnung, die bei der Telekom bedient wird, hat Dual Stack, da es anfangs Probleme mit der SIP-Telefonie gab, und ich denen ein Ultimatum stellte, entweder sie ermöglichen es mir SIP zu benutzen, oder ich kündige (noch in der ersten 2-Wochen-Frist). Da haben die dann von DS-Lite auf Dual Stack umgestellt.

Bei der Telekom gibt es kein DSLITE :winken:
Die schalten nur Dual Stack oder bei Altkunden IPV4 only.

Hmm, wusste ich nicht, ich dachte es hätte damit was zu tun gehabt. Dann hab ich nun gar keine Ahnung, wieso die SIP-Verbindung zu Sipagate nach ein paar Minuten immer abbrach. :kratz:

Also mir wurde es vor Vertragsabschluss am Dienstag zugesichert (per Chat), sonst hätte ich kein Upgrade gemacht. Ich mache mir da keine großen Sorgen.

Die würde ich mir aber schon machen. Von automatisch stellt sich das nicht wieder um.

Ich habe denen gestern ein "/services/kontakt/allgemeine-anfrage/"-Formular mit der Problemschilderung geschickt, und werde auch Montagmorgen mit denen Chatten (Telefon-Kontakt ist ja fast nicht hinzubekommen). Aber Danke für den Heads-Up.