Telekom hilft Labor: IPv6 im Mobilfunknetz

Gelöst
Community Managerin

Update 30.08.2018: die Abfrage ist beendet

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

 

Hallo liebe Community,
hallo liebe Testinteressierte,

gemeinsam mit euch möchten wir im Telekom hilft Labor wieder ein neues Feature vor Launch testen! Dieses Mal geht es um IPv6 im Mobilfunknetz.

Es ist kein Geheimnis, dass bereits 2011 die letzten freien IPv4-Adressen von der IANA (Internet Assigned Numbers Authority) vergeben wurden. Dem gegenüber steht allerdings der extrem wachsende Bedarf an IP-Adressen. Gerade durch die stark wachsende Anzahl der mobilen Internetnutzer wächst dieser Bedarf rasant. Es ist daher notwendig, dass der Zugang zum Mobilfunknetz vorzugsweise über IPv6 erfolgen soll. Eine Kommunikation über IPv4 wird natürlich weiterhin unterstützt.

In unserem Mobilfunknetz bereiten wir die Umstellung auf IPv6 nun vor. Wir suchen 20 Testerinnen und Tester mit einem Android-Smartphone oder -Tablet, die unterwegs viel und vorwiegend über das mobile Datennetz der Telekom surfen und nicht nur über WLAN Zwinkernd Gesurft werden soll möglichst innerhalb Deutschlands. Wenn ab und zu Roaming dabei ist, wäre es aber auch interessant für uns.

Teststart: voraussichtlich Anfang September
Dauer: 4 Wochen
Voraussetzung: Telekom Mobilfunkvertrag, Smartphone oder Tablet mit Android ab Version 7

Du bist bereit und möchtest mitmachen? Dann hier bewerben: [Link entfernt]

Wir freuen uns auf deine Nachricht!

Viele Grüße
Schmidti

 

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

edit 30.08.2018 Schmidti: die Abfrage ist beendet, Link zum Formular entfernt

2 AKZEPTIERTE LÖSUNGEN
Lösung
Community Managerin

Hallo zusammen,

 

vielen Dank für euer großes Interesse an diesem Test! Die Abfrage ist jetzt beendet. Jeder Interessent erhält spätestens am kommenden Montag per E-Mail eine Information, ob es mit der Teilnahme klappt oder nicht.

 

Grüße von

Schmidti

Lösung in ursprünglichem Beitrag anzeigen  

Lösung
Telekom Experte

Hallo,

 

wir würden gerne erstmal mit Android-basierten Sytemen starten, da die technische Implementierung für die dann genutzte Zugangstechnologie nur über IPv6 dort anders (einfacher) gelöst ist als bei iOS-basierten Systemen.

 

Apple-Mobilgeräte haben wir allerdings nicht vergessen und würden sie dann zu einem späteren Zeitpunkt einbeziehen.

 

Viele Grüße!

Lösung in ursprünglichem Beitrag anzeigen  

Als ITler interessiert mich das schon beruflich.

Vor allem interessiert mich, ob die VPN Einwahl in die Firma dann noch funktioniert.

Die läuft leider noch nicht über IPv6.

Die Bewerbungen über Twitter wurden ja eröffnet. Ich vermute doch, dass hier recht viele teilnehmen werden. Wenn wirklich nur 20Tester gesucht werden würden, gehe ich davon aus das man dann kein Post auf Twitter gemacht hätte.

Hallo,

 

Kann man als Businesskunde auch teilnehmen? Wenn ja würde ich das auch gerne machen, um zusehen ob es mit den Diensten z.B VPN oder andere Server die ich benutze funktionieren.

 

 

Viele Grüße

Hallo liebes Telekom Hilft Labor Team,

 

ich besitze eine Samsung Galaxy s8+ mit Android 8. Ich surfe überwiegend im Deutschen Mobilfunk Netz. Ich hätte Interesse das reine IPv6 Netz zu testen. Ich bin Technik begeistert und mich würde es sehr interessieren wie weit man heute mit IPv6 kommt. Ich besitze natürlich auch ein Magenta Mobil Vertrag.

 

Also meldet euch bei mir Fröhlich

 

Mit freundlichen Grüßen 

Patrick Hemmer

Der Witz an der Sache wird dann ja sein, dass es über ein NAT64 läuft in Kombination mit DNS64. Sprich, wenn ihr versucht eure VPNs direkt über die IPv4 Adresse zu erreichen wird es nicht klappen. Nutzt ihr aber die Domain, die auf eine IPv4 Adresse zeigt, so gibt der DNS64 Server der Telekom euch eine IPv6 Adresse zurück die, die IPv4 Adresse enthält z.B. 64:ff9b::192.0.2.1. Diese Adressen werden dann an das NAT64 Gateway geschickt und dort wird die IPv4 Adresse aus der Destination IPv6 wieder extrahiert und von der Telekom an den entsprechenden IPv4-only Server gesendet. Das Antwortpaket landet dann wieder bei der Telekom und wird an die IPv6 Adresse deines Endgeräte weitergeleitet.

 

Was mir nur nicht ganz klar wird ist der Mehrwert an der ganzen Sache. Aktuell wird eine private IPv4 zugeteilt, die aktuell auch schon über das NAT der Telekom läuft (je nach APN), und man hat eine Public IPv6 Adresse mit Firewall davor. Wo ist jetzt der Mehrwert, wenn man IPv6Only nutzt, außer verärgerte Kunden, die nicht mehr direkt ohne DNS auf ihre IPv4 Adressen zugreifen können? Oder versucht man damit schlicht IPv6 voranzutreiben, da so die Endgeräte mehr oder weniger Providerseitig gezwungen werden können IPv6 zu nutzen?

 

Weiterhin wäre es interessant zu wissen, wie es mit der Firewall aussieht. Wird diese auch weiterhin aktiviert sein bei NAT64, um die Endgeräte zu "schützen"? Interessant fände ich hier eine optionale Deaktivierung. @Gelöschter Nutzer

@Waishon Ich vermute, dass ein extra APN dazu gedacht ist auch von außen erreichbar zu sein. Aktuell geht das nur mit dem Test APN internet.t-d1.de. Ich vemute also, dass man nicht nur eine IPv6 Adresse bekommt sondern z.B. ein /64 oder /56 Netz. Dadurch ist es möglich von außen auf z.B. sein NAS was im Wohnmobil unterwegs ist zuzugreifen. Tatsächlich wird sowas häufig benötigt.

 

Aber ja, ohne eine Firewall wie im Test APN internet.t-d1.de würde ich als Alternative sehr gut finden!

Angemeldet mit Nexus 6P.

 

Wäre interessant zu Erfahren was passiert. Als IT Berater für Privatleute ist es gut solche Infos zu haben.

Schade nur das die LTE Router der Telekom kein ipv6 können... 

Der Vorteil ist eben der, dass es sich um eine Vereinfachung imt Zugangsnetz handelt. Statt Dualstack wieder Singlestack.

Vor zehn Jahren hat man eigentlich darüber nachgedacht die Dualstackphase wegzulassen. Einige Provider im Ausland haben das auch gemacht. Hatten dann wohl aber doch Ärger mit einigen Apps, die nicht NAT64 überwinden konnten. (der Klassiker im negativen Sinne war Skype)

Heute ist die Sitauation anders. Bei Google/Android gibt es als Hilfestellung clat (als Teil einer Rückübersetzung - vollständig nennt man das 464xlat) und bei ios werden Apps, die nicht mit NAT64kompatibel sind vom Appstore ferngehalten.

 

Ich bin übrigens im Testzeitraum eine Woche in Spanien.

@zimso  schrieb:

Hallo @Schmidti,

hier wird über euch schon berichtet...

https://www.heise.de/amp/meldung/IPv4-Daemmerung-Telekom-testet-IPv6-only-Kommunikation-im-Mobilfunk...


und hier auch 

https://www.teltarif.de/telekom-ipv6-test-anmeldung/news/73798.html 

 

und die weiteren "üblichen Verdächtigten" werden sicherlich folgen ...

Lösung
Community Managerin

Hallo zusammen,

 

vielen Dank für euer großes Interesse an diesem Test! Die Abfrage ist jetzt beendet. Jeder Interessent erhält spätestens am kommenden Montag per E-Mail eine Information, ob es mit der Teilnahme klappt oder nicht.

 

Grüße von

Schmidti


@Waishon  schrieb:

Der Witz an der Sache wird dann ja sein, dass es über ein NAT64 läuft in Kombination mit DNS64. Sprich, wenn ihr versucht eure VPNs direkt über die IPv4 Adresse zu erreichen wird es nicht klappen.

Das ist ein Nachteil der reinen IPv6-only-Lösung Stand von vor ca. 5 Jahren. Damit hat man ca. 1-2% der Applikationen (je nach User...) nicht abdecken können. Die Lösungen dazu existieren mittlerweile, sind jedoch in den beiden vorherrschenden Smartphone-Betriebssysten unterschiedlich implementiert.

 

Android nutzt das CLAT-Verfahren. Hierbei wird auf dem Gerät ein virtuelles IPv4-Interface (Adresse 192.0.0.4) angelegt, das alle IPv4-Pakete von Applikationen abfängt, in IPv6 umsetzt und ans NAT64-Gatway schickt. Bei testipv6.de erreichen wir damit 10/10 Punkten, da wird auch die Erreichbarkeit von IPv4-Zielen ohne DNS geprüft. Das Gesamtverfahren heißt dann 464XLAT. Das CLAT ist seit Android 4.4 Bestandteil des Systems.

 

Apple geht einen anderen Weg. Seit Juni 2016 läßt Apple nur noch Applikationen zu, die eine Netzwerk-API nutzen, die adreßfamilienunabhängig ist. Das bedeutet, die Applikation muß sich gar nicht mehr um die Adreßfamilie scheren, sondern kann die IP-Adresse (v4, v6) oder den DNS-Namen nutzen, und das Betriebssystem nutzt je nach vorhandener Anbindung die passende IPv4- oder IPv6-Kommunikation. Details sind von Apple hier veröffentlicht.

 

Mit beiden Systemen werden IPv4-Ziele erreichbar sein, auch wenn man nur eine IPv4-Adresse (und keinen Hostnamen) angibt.

 

Weiterhin wäre es interessant zu wissen, wie es mit der Firewall aussieht. Wird diese auch weiterhin aktiviert sein bei NAT64, um die Endgeräte zu "schützen"? Interessant fände ich hier eine optionale Deaktivierung. @Gelöschter Nutzer


Am Pfad IPv6 Ende-zu-Ende wird sich gegenüber der aktuellen Implementierung bei Dualstack nichts ändern.

 

Welche Use Cases würden denn eingehenden IPv6-Verkehr benötigen bei einem dynamisch vergebenen /64-Präfix?

 

@leuchterDDynDNS geht auch bei IPv6 ohne Probleme, wodurch auch ein wechselndes /64 Netz keine Probleme bereitet. Wenn wir z.B. unterwegs sind würde ich gerne per VPN auf ein Tablet/NAS oder sonstewas zugreifen können welches im Mobilfunknetz liegt. Aktuell geht das im APN internet.t-d1.de mit IPv4 ohne Probleme. Mit IPv6 wäre das somit auch kein Problem, man bräuchte nur die Option die Firewall, genau wie bei dem eben genannten APN auszuschalten.

 

Aber den Weg, den Apple geht, löst doch nicht das IPv6-Only Problem. Ja, die stellen sicher, dass die Appentwickler ihre Backends auf mit IPv6 Aufrufbar machen, aber was passiert z.B. bei FTP Apps, wo User defined IP-Adressen eingetragen werden? Ein User trägt hier eine IPv4 Adresse ein, da iOS aber kein CLAT macht wird es auch nicht in IPv6 umgesetzt und die Verbindung schlägt fehl. Oder haben die sich da noch einen eigenen Standard ausgedacht?

 

Edit:

Ah ok, Apple hat eine Methode implementiert, die von IPv4 Adressen die entsprechende IPv6 Adresse zurück gibt. Gut das ist bei Apple mit ihrem Restriktiven OS so machbar, aber dennoch finde ich den Weg, den Android geht, das auf Systemebene zu machen schon sinnvoller

Die deutsche Telekom nutzt im Netz schon IPv6 only in UK (mit EE)  sowie Tmobile US.

Dabei wird bei den kompatiblen Geräte das IPv6 only APN hinterlegt. Als ich dieses Jahr in Edinburgh war, habe ich mir deshalb ein EE SIM geholt um das 464xlat zu probieren. Leider war ich nicht in einer passen enden Gegend.

Ich habe dann bei mir zuhause ein IPv6 only Netz aufgebaut. Nachdem mein ISP kein IPv6  kann, war das Ergebnis etwas eigen hat aber alles funktioniert.

Der post dazu aus einem anderem Forum:

 

Ausgangssituation:
PFsense:
WAN IPv4 only.
LAN ipv6 2001:db8:caff:XXXX::/86
ipv4 192.168.11.1/24

NAT64 (tayga)/DNS(bind9) über Ubuntu VM
OPT1 ipv6 only: 2001:db9:caaa::1/48
ipv4 192.168.254.1/32

TP Link WLAN AP: 
Netz aus dem Bereich von OPT1
kein IPv4


Aufbau 1:
Windows 10 Laptop ist mit OPT1 verbunden
Ergebnis: nur IPv4 only Seiten können erreicht werden, sobald IPv6 taugliche Ressourcen eingebunden sind kommt es zu Fehlern:

Edit: falsches Bild

00fc2d31-c30d-44e1-9a0f-21833c33932a.png

Richtiges Bild

320c2e03-6a9c-4755-8e97-88e7ddf6aa7f.png

 

 


Aufbau 2:
TPLink AP ist mit OPT 1 Verbunden
Android Smartphone, OnePlusOne ist mit WLAN mit TPLink AP verbunden.
Laptop ist mit USB Tethering (ipv4 only) mit dem Android Smartphone verbunden.
Ergebnis: am Smartphone sowie am Laptop können alle Internetdienste verwendet werden. IPs aus den privaten Bereichen werden vom NAT64 Server blockiert.
 00fc2d31-c30d-44e1-9a0f-21833c33932a.png

 

 

 

Traceroute Windows:

 

a3c4937b-53d8-410a-8e8b-043c0496bf24.png

 

 

Android, IP Adressen, die IPv4 Adresse hat sich das Gerät selbst zugeteilt:

Android, IP Adressen, die IPv4 Adresse hat sich das Gerät selbst zugeteilt:

bca4bb69-ff33-4a68-bfe3-90939c424ad3.png

 

 

 

So sieht es für IPv4 APPs aus:

 

 

20904424-9769-4a02-aa92-56e64ba57c30.png

 

 


Warum der 2. Aufbau funktioniert kann ich mir nur zum Teil erklären.

Das am Laptop alle IPv4 tauglichen Seiten erreichbar sind, macht Sinn, da dieser nur eine IPv4 Verbindung hat. Die IPv4 Adressen werden von Android mit 464xlat umgesetzt auf die passenden IPv6 Adressen vom NAT64 Server.
DNS64 ermöglicht dem Windows PC im Aufbau 1 die IPv4 only Seiten zu erreichen, was dem erwarteten Ergebnis entspricht. Zugriffe über die IPv4 Adresse waren nicht möglich.

Jedoch erklärt das nicht, warum unter Android auch die DualStack Seiten erreichbar sind, da bei diese doch IPv6 bevorzugt werden müsste, was jedoch bei der WAN Verbindung nicht vorhanden ist. IPv6 Internetzugriff war definitiv nicht vorhanden, six.heise.de war auch nicht erreichbar.

Eigentlich wäre damit IPv6 only im Mobilfunk problemlos möglich. Die IPv4 Geräte landen in einem eigenem IPv4 only APN, bzw die IPv6 only tauglichen Geräte in einem IPv6 only APN.
NAT64/DNS64 ist sehr schnell eingerichtet, 464XLAT erkennen die unterstützten Geräte voll automatisch. Ich musste bei meinem Smartphone nichts ändern, dies fand nach ein paar Sekunden den NAT64 Server und emulierte eine IPv4 Verbindung
 

Klar geht das, wie Du selbst schreibst machen EE und TMUS das ja schon länger. Der Friendly User Trial dürfte dazu dienen, herauszufinden ob es trotzdem noch edgecases gibt in denen Probleme auftreten.

 

Den NAT64 Server findet das Handy übrigens per DNS, google mal nach "ipv4only.arpa".


@IT-FreakAT  schrieb:
Jedoch erklärt das nicht, warum unter Android auch die DualStack Seiten erreichbar sind, da bei diese doch IPv6 bevorzugt werden müsste, was jedoch bei der WAN Verbindung nicht vorhanden ist. IPv6 Internetzugriff war definitiv nicht vorhanden, six.heise.de war auch nicht erreichbar.

Wow, da hast Du ja das IPv6-only-Setup gut nachgebaut! Auch Apple liefert ein Szenario, wie man das selbst emulieren kann.

 

Warum auch die DualStack-Seiten erreichbar waren, läßt sich mit "Happy Eyeballs" erklären. Hierbei probiert der Browser IPv4 und IPv6 schnell hintereinander. Die erste Verbindung gewinnt, wobei IPv6 einen gewissen zeitlichen "Vorsprung" bekommt. Damit sieht der Beobachter im Falle des IPv6-Ausfalls im Server die Seite trotzdem über IPv4 ohne sichtbare Verzögerung.

 

Wie die IPv6-only-Strategie bei EE aussieht, weiß ich leider auch nicht (unter welchen Umständen IPv6-only vergeben wird). Definitiv ist das aber eine Einstellung am Endgerät, die das bedingt.

 

 

Community Managerin

Hallo zusammen,

 


@Schmidti  schrieb:

 

Jeder Interessent erhält spätestens am kommenden Montag per E-Mail eine Information, ob es mit der Teilnahme klappt oder nicht.


es gibt eine kleine Verzögerung. Die Benachrichtigungen werde ich morgen verschicken.

 

Bis dahin,

viele Grüße

Schmidti

Danke für die info, ipv4only.arpa kannte ich nicht. Jedoch was bringt es dem Geräte die IP vom NAT64 Server zu wissen? Es braucht doch das Prefix, oder?


@IT-FreakAT  schrieb:

Danke für die info, ipv4only.arpa kannte ich nicht. Jedoch was bringt es dem Geräte die IP vom NAT64 Server zu wissen? Es braucht doch das Prefix, oder?


Guten Morgen,

 

das Gerät benötigt für die IP-Address Synthese, also das künstliche Einfügen und Extrahieren der IPv4 Adresse in eine und aus einer IPv6 Adresse die Information wie dies zu geschehen hat damit das NAT64 Gateway dies versteht und damit das Endgerät weiß, welche IP-Adressen (die es in Paketen vom NAT64 Gateway bekommt) synthetisiert sind.

 

Die hinter ipv4only.arpa hinterlegten IPv6 Adressen sind dann der Prefix.

 

Allerding steckt da noch die Information drin WO innerhalb der 128 Bits der IPv6 Adresse sich die 32 bittige IPv4 Adresse befindet.

 

Wenn du das genauer nachlesen möchtest:

https://tools.ietf.org/html/rfc6052#section-2 https://tools.ietf.org/html/rfc7050

 

Man kann dabei das Well-Known-Prefix 64:ff9b::/96 verwenden dann sieht z.b. die IP-Adresse des Google 8.8.8.8 DNS Servers so aus:

64:ff9b::0808:0808. 

Es gibt aber auch noch die möglichkeit dem NAT64 Gateway ein anderes/eigenes Prefix zuverpassen (Siehe NSP). 

 

vgs

 

Community Managerin

Hallo zusammen,

 

die Benachrichtigungen sind verschickt. Jeder, der das Formular ausgefüllt hat, sollte jetzt eine E-Mail bekommen haben. Da es sehr viel mehr Interessenten als Plätze gab, sind auch einige Absagen verschickt worden.

 

Es kommt immer mal wieder vor, dass im laufenden Test nachgerückt werden kann. Sollte das der Fall sein, findet ihr eine Info dazu auf der Laborstartseite.

 

Grüße von

Schmidti

Yo, würde mich freuen Schmidti  

Danke für die Antwort. 

Jetzt mit der RFC verstehe ich, wie es funktioniert. Die Idee dahinter ist ja einigermaßen Simple aber effektiv.

Bei mir läuft es mit dem Well Known Prefix.

 

Gibt es auch schon Pläne IPv6 only für Festnetz?

Für das TV VLAN könnte das doch interessant sein, oder?