DS-Lite (Dual Stack)

Es wurden schon viele Artikel über die "Sparversion" von DSL-Anschlüssen aufgrund der IPv4-Adressenknappheit geschrieben. Daher beschränke ich mich hier auf einige Quellen und meine eigenen Erfahrungen mit Problemen im IT-Umfeld.

Grundlagen

Wurden in der Anfangszeit noch ganze IPv4-Subnetze an Kunden verteilt, so war es schon lange üblich an Nutzer und Konsumenten ohne eigene Dienste nur maximal eine IPV4-Adresse zu vergeben. Die hat dann noch der DSL-Router oder der Einwahl-PC für die Zeit der Verbindung oder maximal 24 Stunden bekommen. Der Client hat zuhause seine private IPv4-Adresse z.B. der Fritz!Box genutzt, die dann die Adressen auf die eine externe Adresse umgesetzt hat.

Alle privaten PCs haben sich also die eine PublicIPv4 geteilt, die der Provider zugewiesen hat. Sie kennen natürlich die Nachteile von NAT, d.h. dass es nur 65535 Ports gibt, was für eine Familie aber kein Problem sein dürfte. Die meisten DSL-Router unterstützen eh nur ein paar tausend gleichzeitige Verbindungen. Es ist eher eine Verschwendung so wenige Ports bei einer IPv4-Adresse zu nutzen. Interne PCs sind aber ohne besondere Steigbügel aus dem Internet nicht erreichbar. Das ist gut aber nicht mit einer Firewall zu verwechseln.

Mit der IPv4-Adressknappheit, haben einige Provider versucht zu tricksen, um bei der IPv6-Einführung noch etwas Zeit zu haben. Sie haben einfach den Kunden eine private IPv4-Adresse zugewiesen und ihrerseits noch mal ein NAT gemacht. Das habe ich einige Zeit z.B. mit Mobilfunkverbindungen gesehen, dass mein Telefon eine IPv4-Adresse aus dem Bereich 10.x.x.x bekommen hat.

Der Provider muss natürlich aufpassen, dass er für seien gelben Bereich Adressen wählt, die der Kunde selbst nicht hat. Solange die Provider aber die DSL-Router stellen und alle Hersteller im Bereich 192.168.x.x unterwegs sind, kann der Provider im gelben Netzwerk durchaus mit 10.x.x.x arbeiten. Über den Trick kann ein Provider dann z.B. 100 Kunden mit vielleicht 500 gleichzeitigen Verbindungen hinter einer öffentlichen IPv4-Adresse verstecken, die ja 65535 Ports unterstützt. Schön ist das aber auch nicht.

Mittlerweile ist IPv6 aber nichts Exotisches mehr sondern in der Welt des Internet angekommen. Hier gibt es viel mehr Adressen und Netzwerke, so dass jeder Kunde nicht mehr nur eine öffentliche IP-Adresse auf dem DSL-Router bekommen kann, sondern sogar tausende komplette Subnetze dahinter. Das Problem mit IPv6 ist aber, dass solche Clients auch nur IPv6-Gegenstellen erreichen können. Sobald die Gegenstelle aber nur eine IPv4-Adresse hat, muss etwas eine IPv6 auf IPv4 Adresse umsetzen. Hier gibt es dann zwei Szenarien:

  • Client kann IPv6
    Wenn der interne Client selbst eine IPvv6-Adresse hat, dann wird er per DNS einen IPv6-DNS-Server abfragen. dieser DNS-Server des Providers kann nun erkennen, dass die Gegenseite nur IPv4 kann. Über DNS64 kann er dann dem Client eine IPv6-Proxy-Adresse geben, die vom Provider dann auf die IPv4-Zieladresse umgesetzt wird (NAT64). Das Verfahren nutzt z.B. auch Direct Access.
  • Client kann nur IPv4
    Wenn der Provider aber gar keine IPv4-Adressen mehr nutzt, dann muss der DSL-Router die weiterhin intern vergebenen privaten IPv4-Adressen irgendwie über IPv6 zu einer Gegenstelle tunneln, die dann wieder per NAT eine der kostbaren öffentlichen IPv4-Adressen umsetzt. Hier nutzen natürlich mehrere Kunden diese IPv4-Adresse gemeinsam.

Das Problem bei dem Tunnel ist die MTU-Size, die auf dem WAN eine Obergrenze hat. Werden die IPv4-Pakete nun in einen IPv6-Paket eingepackt, dann müssen die IPv4-Pakete kleiner sein, damit keine Fragmentierung erforderlich ist. Dazu gibt es das Verfahren MTU-Disccovery (Siehe Maximum Transmission Unit (MTU) und Fragmentierung). Wenn die Gegenstelle aber ein "ICMP Frame Size Exceeded" senden kann, dann kommt das Paket nicht an

In beiden Fällen ist die IPv4-Adresse nicht mehr genau einem Kunden zugeordnet und vor allem kann der Kunde, selbst wenn er es wollte, keine eingehende Veröffentlichung einrichten. Der Trick einen Server zuhause mit einem "DynDNS"-Namen zu veröffentlichen, geht hier nicht. Der Provider macht die Umsetzung. Wenn der Kunde aber eine echte IPv6-Adresse auf dem DSL-Router hat und bei entsprechender Konfiguration vom Provider sogar ein Subnetz bekommt, dann können Sie zumindest eine IPv6-Erreichbarkeit ermöglichen.

IPv6 auf dem Client

Bei der Telekom mit einer Fritz!Box und aktiviertem IPv6 sehen Sie dies in der Verbindungsdaten. Ich habe hier auch noch eine IPv4-Adresse, also kein DS-Lite.

Ein IPCONFIG auf meinem internen Client zeigt die mit zugewiesene IPv6-Adresse

Mein Computer wäre also zu der Zeit unter der Adresse auch von extern erreichbar. Das ist interessant, weil insbesondere Skype/Teams-Calls damit einen direkt erreichbaren Kandidaten haben. Auf der anderen Seite gibt es aber keine "Firewall" von extern und der Schutz basiert letztlich auf drei Komponenten

  • Auf meinem Client sollten keine angreifbaren Server-Dienste laufen, der auf IPv6 Anfragen annehmen.
    Bei einer Momentaufnahme waren durchaus einige Dienste zu einer eingehenden Verbindung per IPv6 bereit
  • Die Windows Firewall sollte Zugriffe von extern unterbinden.
    Ein Client startet von sich aus die Verbindung und muss eigentlich nicht von extern erreicht werden. Das stimmt aber nicht mehr, wenn Sie in einem Firmen-LAN sind und z.B. aus der Ferne den PC steuern, mit Updates versehen oder ein legitimer Service läuft. So etwas sollte nicht ungeschützt ohne Firewall betrieben werden. Die Fritz!Box sichert das aber schon alleine ab:

    Quelle: https://avm.de/service/fritzbox/fritzbox-6360-cable/wissensdatenbank/publication/show/845_IPv6-Freigaben-in-FRITZ-Box-einrichten/
  • Niemand kennt mein IPv6-Netzwerk, Security by Obscurity.
    An der Statusseite der Fritz!Box sehen Sie, dass ich eine öffentliche IPv4 Adresse habe. Davon gibt es echt genug. Ich habe aber auch ein /56er Subnetz und könnte also 8Bit (=256 Netze) verwenden. Die Telekom hat aber vermutlich ein /32er Netzwerk und damit noch 24bit für Kunden frei. Das ist eine verdammt große Zahl an möglichen Adressen die per "Scan" kaum zu ermitteln sind. zudem ändert sich diese Adresse natürlich nach einer Zwangstrennung.

Ein Sicherheitsrisiko kann ich bei korrekter Funktion von DSL-Router und Client nicht erkennen.

Skype for Business und ICE

Wer mit VoIP hantiert, weiß um die Besonderheiten bei der Übertragung von Audio und Video. Die Qualität hängt nicht nur von der verfügbaren Bandbreite, sondern auch von der Laufzeit der Pakete an. Jeder Umweg und Umpacken oder VPN-Tunnel hat meist einen negativen Einfluss auf die Qualität. Ideal ist eine direkte Verbindung zwischen den beiden Endpunkten. Nur wenn Firewalls und NAT-Router eine Verbindung verhindern, dann bedienen sich die Clients so genannter TURN-Server

Die beiden Endpunkte versuchen am Start einer Verbindung die möglichen IP-Kandidaten zu ermitteln und tauschen diese über den Vermittlungsserver aus. Hier sehen Sie einen ausgehenden INVITE meines Home-Office Clients mit IPv6

  • Grün/dunkelblau: Direkte Kandidaten
    Natürlich bietet mein Client die auf den lokalen Schnittstellen erreichbaren IP-Adressen mit dynamisch geöffneten Port an. Damit könne ein Partner im gleichen gerouteten Netzwerk mich direkt erreichen. Auf dem Homeoffice ist das natürlich unwahrscheinlich.
  • Rot/Hellbau: Relay-Adressen
    Mein Skype for Business Benutzer nutzt Office 365 und bedient sich daher der Edge-Server in der Cloud um auf jeden Fall öffentlich erreichbare Kandidaten zu erhalten. Sie sehen hier aber auch, dass die Gegenseite auch Daten ein eine IP6-Addresse "2603:1037:0:9b::40" senden darf. Der Edge Server dahinter liefert die Pakete dann an die 52.112.12.251 sendet. Dazu gibt es einen passenden Eintrag in Magenta
  • Magenta
    Mein Client hinter einer Fritz!Box mit echtem IPv4 kann ausgehend eine Verbindung zum Edge Server der Cloud (52.112.12.251) aufbauen und damit dem gegenüber diese Paarung anbieten. Pakete an die 52.112.12.251 werden dann auf meine interne private Adresse (192.168.178.50) über den bereits etablierten NAT-Kanal gesendet.

Eine direktes IPv6-Angebot zur Gegenseite gibt es hier nicht. Meine Fritz!Box hat ja auch keine "Veröffentlichung" um von extern erreichbar zu sein.

Etwas anders sieht es mit einem DS-Lite-Anschluss von 1&1 aus. Hier sehen Sie die angebotenen SDP-Kandidaten.

Auch hier sehen sie am Anfang wieder die direkten IPv4 und IPv6 Kandidaten. Der Client hat also selbst eine IPv6-Adresse aus dem Netzwerk 2a0a:a541:1725:0. Wir sehen aber auch hier keine direkten IPv6 Kandidaten. Die TURN (relay) Einträge fehlen hier, weil der Edge-Server auf der anderen Seite keine IPv6-Adressen anbietet. So kann der Client nur über die IPv4-Schiene die Edge-Server erreichen. Das System mit der 89.1.211.231 gehört zu NetCologne und dürfte ein DS-Lite NAT-System sein:

inetnum: 89.1.192.0 - 89.1.223.255
netname: NC-DIAL-IN-POOL
descr: NetCologne dynamic IP Pool
descr: Am Coloneum 9
descr: D-50829 Koeln
Quelle: https://apps.db.ripe.net/db-web-ui/query?searchtext=89.1.211.231

Und hier kommt dann wieder das Thema Maximum Transmission Unit (MTU) und Fragmentierung auf Spielfeld. Der Client sendet gerne seine Daten aber mit DS-Lite muss der Client seine IPv4-Pakete an den DSL-Router senden, der diese dann in einem IPv6-Paket einpackt und an den DS-Lite-Server beim Provider sendet. Der Provider packt das Paket aus und sendet es mit seiner IPv4-Adresse weiter.

Auf dem Hinweg muss der lokale DSL-Router dem Client aber mitteilen, wie groß das Paket maximal denn sein darf. Auf der DSL-Seite gibt es ja eine Maximalgröße (MTU Size) und davon muss noch das IPv6-Frame abgezogen werden. Die wenigsten Router und DS-Lite Systeme unterstützen Fragmentierung, denn das will niemand, das sein etwas zu großes Paket in ein großes und ein kleinen Paket aufgeteilt wird, welches von der anderen Seite wieder zusammengesetzt wird. Also sendet der DSL-Router ein "ICMP Frame Size Exceeded" an den Client, der dann kleinere Pakete sendet.

Das gleiche Spiel passiert aber auch auf der Rückrichtung. Der Server auf der Seite sendet seinerseits die Pakete weg und auf dem Weg zum DS-Lite-System gibt es auch Grenzen. Insbesondere das DS-Lite-System muss der Gegenseite über ein "ICMP Framesize exceeded" sagen, dass die Pakete durch den Tunnel kleiner sein müssen.

Und hier hängt es nun an der Firewall der anderen Seite ab. Viele Administratoren haben eingehendes ICMP geblockt, weil Sie damit ein "Ping" aus dem Internet aus Sicherheitsgründen verhindern wollen. ICMP ist aber nicht nur PING sondern steht für "Internet Control Message Packet (ICMP)". Darüber steuern sich auch Netzwerke.

Genau das war bei einem Kunden der Fall mit dem Effekt, dass Audio (kleine Pakete) funktioniert hat, aber große Pakete (Video und vor allem Desktop Sharing) nicht oder nicht lange funktioniert haben. Das Problem ist dabei nicht der Anwender mit DS-Lite und auch nicht der Carrier sondern die IPv4-Gegenseite, die ICMP-Pakete verwirft und damit die Grundfunktion des Internets nicht verstanden hat. Es fällt halt erst auf, wenn eine Teilstrecker nicht die üblichen 1492/1500 Bytes unterstützt.

DS-Lite und Glasfaser

Die Funktion DS-Lite hat nichts mit "DSL" zu tun. Auch eine Internetanbindung per Glasfaser, z.B. über Deutsche Glasfaser, hat auch das Problem, dass die Kunden nicht mehr eine öffentlichen IPv4-Adresse bekommen. Gerade jüngere Provider haben viel weniger IPv4-Adressen zur Verfügung als die alt eingesessene Telekom. Daher müssen Sie auch entsprechend "Dual Stack" fahren. Eine Fritz!Boy mit Internet per Glasfaser bekommt auf der WAN-Seite dann ebenfalls IPv6-Adressen und vielleicht noch eine

Die IP-Adresse "100.72.12.20" sieht erst einmal aus wie eine öffentliche Adresse. Sie ist aber speziell für die Kommunikation innerhalb eines ISPs reserviert und nicht aus dem Internet erreichbar.

Diese Adressen werden also nie im Internet verwenden und können daher auf der inneren Seite eines NAT-Systems genutzt werden. Auf der anderen Seite ist es unwahrscheinlich, dass diese Adressen bei Kunden genutzt werden, die bislang nur die Bereich 10.x.x.x/172.16.x.x-17.31.x.x/192.168.x.x und 169.254.x.x kennen.

DS-Lite Server Probleme

Die Vermittlerfunktion der IPv6/IPv4-Umsetzer bei DS-Lite ist nur erforderlich, wenn Client und Server keine IPv6-Verbindung aufbauen können. Wenn der Client eine IPv4-Verbindung nutzen muss, weil die Gegenstelle eben nur IPv4 anbietet, dann kann der Provider nur entweder den IPv6-Tunnel anbieten oder NAT46/DNS64 (Siehe auch Tunnelkomponenten) machen.

Einige Probleme waren nur zu bestimmten Zeiten aktiv. Anscheinend hat auch Corona und die immense Zunahme der Homeoffices mit VPNs, die auch lange beständig sind, hier das ein oder andere System erfordert. Leider und verständlicherweise veröffentlichen die DSL-Anbieter keine Kennzahlen ihrer DS-Lite Systeme. Ich habe aber manchmal den Eindruck gewonnen, dass hier temporäre Engpässe nicht auszuschließen sind.

Interessant ist hier, dass einige Kunden bei genug "Problemen" dann doch zusätzlich eine IPv4-Adresse auf ihren DSL-Router geschaltet bekommen und dann wieder klassisch mit lokalem NAT weiter arbeiten. Meist sind diese Funktionen aber "Business-Kunden" vorbehalten.

Fortsetzung folgt

Ich werde die verschiedenen Support-Tickets mit DS-Lite Kunden weiter verfolgen

Weitere Links