Mobilfunknetze als Akzeptanzbeschleuniger

Wie das mobile Internet IPv6 vorantreibt

| Autor / Redakteur: Ralf Gehrke / Andreas Donner

In einem durchgängigen IPv6-Bereitstellungsmodell müssen nur die Requests auf reinen IPv4-Content durch NAT64-Server (IPv6 to IPv4 Network Address Translation) geleitet werden.
In einem durchgängigen IPv6-Bereitstellungsmodell müssen nur die Requests auf reinen IPv4-Content durch NAT64-Server (IPv6 to IPv4 Network Address Translation) geleitet werden. (Bild: Akamai)

Unternehmen, in denen mobile Performance eine wichtige Rolle spielt, sollten sicherstellen, dass ihre Apps sowohl im reinen IPv6- als auch im Dual-Stack-Betrieb arbeiten. In Mobilfunknetzen ist IPv6 bereits weit verbreitet und das Internetprotokoll bietet zudem in einigen Netzen schon eine höhere Geschwindigkeit als IPv4.

Apple setzt die Standards. Seit dem 1. Juni 2016 müssen im App Store eingereichte Programme einen reinen IPv6-Betrieb ermöglichen. Bereits im Sommer letzten Jahres hatte das Unternehmen auf seiner Worldwide Developers Conference auf diesen Termin hingewiesen. Entwickler müssen daher sicherstellen, dass ihre Apps in reinen IPv6-Umgebungen mit NAT64 und DNS64 arbeiten. NAT64 übersetzt die per IPv6-Protokoll gesendeten Nachrichten in IPv4 und DNS64 liefert zusätzlich zur IPv4- eine IPv6-Adresse.

Da sich der IPv6-Rollout über Jahrzehnte hinziehen könnte, herrscht oft die Meinung vor, dass IPv6 bislang noch kaum verbreitet sei. In vielen Regionen der Welt ist dieser Eindruck aber falsch. Als erster deutscher Mobilfunkanbieter hat die Telekom in ihrem Netz IPv6 im Sommer 2015 aktiviert. Die US-Tochter T-Mobile war schon drei Jahre früher dran. Vodafone will noch im Laufe des Jahres IPv6 zunächst für „LTE Zuhause“-Kunden anbieten. Für den Dual-Stack-Betrieb mit IPv6 parallel zu IPv4 ist in Deutschland ein LTE-fähiges Mobilgerät nötig. Den kompletten Umstieg von IPv4 auf IPv6 plant aktuell allerdings noch keiner der Mobilfunk-Provider.

Die Vorgabe von Apple, im App Store nur noch IPv6 zu unterstützen, wird die Verbreitung von IPv6 weiter fördern. Aktuelle Android-Geräte und Windows-Phones enthalten eine Software namens 464XLAT CLAT, die Rechnern in IPv6-Netzwerken den Zugriff auf Internetdienste ermöglichen, die nur via IPv4 erreichbar sind, beispielsweise Skype. Der Datenverkehr wird dabei durch ein NAT64-Gateway geleitet. Bei iOS 9 fehlt diese spezielle Funktionalität, das Betriebssystem unterstützt dafür aber „Bump-in-the-API“. Dabei erfolgt eine Übersetzung zwischen APIs, die es ermöglicht, IPv4-Applikatonen zu nutzen, die über IPv6 kommunizieren.

Die meisten Mobilfunk-Provider der Welt haben ihren Vorrat an frei verfügbaren IPv4-Adressen weitgehend aufgebraucht und die größeren Betreiber bedienen mehr Geräte als sie mit ihren RFC1918-Adressen unterstützen können. Dies führt einerseits zu einer höheren Komplexität bei der Wiederverwendung verfügbarer IPv4-Adressen und andererseits zur kostspieligen Infrastruktur-Implementierung einer Stateful IPv4 to IPv4 Network Address Translation (NAT44).

In einem durchgängigen IPv6-Bereitstellungsmodell müssen nur die Requests auf reinen IPv4-Content durch NAT64-Server (IPv6 to IPv4 Network Address Translation) geleitet werden, während der Zugriff auf Dual-Stack-Content ohne Übersetzung direkt ins Internet gehen kann. Da es immer mehr Dual-Stack-Content gibt, können die Betreiber von Mobilfunknetzen zunehmend auf NAT64-Infrastrukturen verzichten. Ein weiterer Antriebsfaktor für reines IPv6 in Mobilfunknetzen: IPv6 wurde zeitlich vor IPv4v6 spezifiziert und verfügt über eine umfangreichere Unterstützung bei Netzwerkausrüstern.

IPv6 kann in Mobilfunknetzen schneller sein als IPv4

Die einfachere Netzwerk-Architektur für nativen IPv6-Traffic in Mobilfunknetzen – es werden weniger Vermittlungsstellen zwischen dem Endgerät und dem Internet benötigt – ermöglicht eine höhere Performance. In einigen reinen IPv6-Netzen sowie in einigen Dual-Stacked-Mobilfunknetzen, die den IPv4-Traffic über einen IPv6-Tunnel in ein NAT44-Gateway leiten, gelangt der IPv6-Traffic direkt ins Internet. Der IPv4-Traffic dagegen wird über ein NAT-Gateway vermittelt. Diese Network Address Translation führt zu längeren Übertragungszeiten und bedeutet für ISPs, dass sie bei einem steigenden Bedarf auf Seiten der User mehr Kapazitäten vorhalten müssen.

Facebook und LinkedIn haben Real-User-Measurements (RUM) durchgeführt, bei denen die relative Performance zwischen IPv6 und IPv4 in Dual-Stacked Mobile Devices gemessen wurde. In diesen Studien zeigten sich deutliche Performanceverbesserungen von IPv6 im Vergleich zu IPv4 in den Netzen der vier größten Mobilfunkanbieter in den USA. Die Ladezeiten für Seiten waren mehr als zehn Prozent schneller. Die Bereitstellung von Content über IPv6 führt also zu einer besseren User Experience und einem höheren User Engagement.

Auch Akamai hat mit seiner eigenen RUM-Lösung Performanceunterschiede zwischen IPv4 und IPv6 in den vier größten US-Mobilfunknetzen gemessen. Beim Performancevergleich zwischen Legacy IPv4 und Dual-Stacked IPv6 wurden die folgenden Metriken verwendet: die DNS Lookup Time, die Latenz zwischen Client und Server und die Page Load Time. Enduser sehen primär die Page Load Time, wobei diese durch die beiden anderen Faktoren beeinflusst wird.

Android und iOS haben das DNS Lookup unterschiedlich implementiert: Android führt die Looks für IPv6 (AAAA Record) und IPv4 (A Record) sequentiell durch und wartet auf die Ergebnisse, während iOS parallel arbeitet und die TCP-Verbindungen initiiert, sobald die Ergebnisse vorliegen. Die unterschiedlichen Implementierungen zeigen sich auch in den gemessenen Zeiten für die DNS Lookups.

Abhängig vom Carrier benötigen Android-Geräte zur Ermittlung einer IPv6-Adresse zwischen elf und 47 Prozent länger als für eine IPv4-Adresse. Bei iOS ergab sich eine um 58 Prozent geringere Lookup-Zeit. Der Performanceverlust bei Android ist auf die IPv6-Connectivity der Geräte zurückzuführen, die selbst dann genutzt wird, wenn der AAAA Record reinen IPv4-Content enthält. Bei den Client-Server-TCP-Verbindungen ergaben sich bei der medianen Latenz keine bedeutenden Unterschiede. Lediglich im 95-Prozent-Perzentil, also am oberen Ende des Leistungsspektrums, zeigten sich leicht bessere Ergebnisse für IPv6, die vermutlich darauf zurückzuführen sind, dass der IPv6-Traffic über NAT-Server läuft.

Vorteile von Dual-Stacking-Content

Wollen Content Provider ihre Inhalte über IPv6 und die Akamai Intelligent Platform ausliefern, genügt es in den meisten Fällen, die Option „IPv4+IPv6 Dual Stack“ auszuwählen. Dabei ist es nicht erforderlich, am Ausgangspunkt über eine IPv6-Verbindung zu verfügen, da IPv4- und IPv6-Verbindungen am Edge terminiert werden und von dort eine IPv4-Verbindung zum Ausgangspunkt hergestellt wird. Mit dem Akamai AnswerX DNS Resolver lassen sich DNS64-Umgebungen und eine Dual-Stack-Umgebung implementieren, bei denen die Plattform als DNS Resolver für reine IPv6-Umgebungen auf der Client-Seite agiert und mit den DNS Authorities über IPv4 und IPv6 kommuniziert.

Ralf Gehrke.
Ralf Gehrke. (Bild: Akamai)

Es ist sicherlich noch ein weiter Weg bis zur vollständigen Umstellung auf IPv6 im Internet zurückzulegen, auch wenn in den letzten Jahren deutliche Fortschritte in den Fest- und Mobilfunknetzen erzielt wurden. Das gilt auch für die Zahl der Endgeräte, die IPv6 unterstützen. Die verbesserte Performance in Mobilfunknetzen – unter anderem bedingt durch eine geringere Zahl von NAT-Gateways – wird den Trend Richtung IPv6 weiter fördern.

Über den Autor

Ralf Gehrke ist Director EMEA Pre Sales bei Akamai.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44270416 / IPv6)