• Als Spam markieren
• Beitrag melden

• 
  Diese Gruppe Alles

• Archiv
• RSS-Feeds

• Kontakt
• Hilfe
• Impressum
• Datenschutz

IPv6-Artikel aus aktueller c't

Johannes Endres, Reiko Kaps
Ende der Enge
Das Internet-Protokoll Version 6 löst
Probleme und schürt Ängste
Version 6 des Internet-Protokolls vergrößert den Adress-
raum ins Unermessliche. Na und? Die Reaktionen von
Administratoren und Anwendern auf IPv6 reichen
von Schulterzucken bis zu tiefem Misstrauen. Dabei
löst IPv6 Internet-Probleme, die jeder Nutzer erlebt —
auch wenn er es noch nicht unmittelbar bemerkt hat.

Wenn man bei einem VoIP-Telefonat sein Gegenüber nicht hört,
wenn in einem Spiel der Kontakt zu anderen Zockern über das
Internet nicht klappt, wenn Peer-to-Peer-Downloads stocken
oder der Dateitransfer im Chat-Programm nicht klappt, iegt
die Schuld meist in der Network Address Translation (NAT).
Denn der Heim-Router hat auf seiner Internet-Seite nur eine
einzige Adresse und muss die interne Adresse des PC im loka-
len Netzwerk darauf übersetzen. Dazu führt er eine Tabelle,
welche interne Adresse eine Verbindung zu einem externen
Rechner aufbaut. Solange der seine eigene feste Adresse hat,
wie bei Servern üblich, funktioniert die Sache einigermaßen.
Doch wenn auch der Kommunikationspartner hinter einer NAT
sitzt, fehlt dort der Tabelleneintrag und der Verbindungsauf-
bau schlägt fehl. Dummerweise ist das eigentlich immer der
Fall, wenn zwei Internet-Nutzer direkt miteinander kommuni-
zieren wollen: bei Instant Messengern, Voice over IP, Video-
konferenzen, Peer-to-Peer-Dateitausch, Online-Spielen oder
Remote-HilfeSitzungen zum Schwiegervater, um nur einige zu
nennen.
Außerdem kann der Router nur beim Protokoll TCP seine NAT
-Tabelle richtig pflegen, weil es eine Verbindung in mehre-
ren Schritten auf- und abbaut. Diese Schritte beobachtet
der Router, um NAT-Einträge anzulegen und zu löschen. Die
weiteren Pakete, die zu dieser Verbindung gehören, kann er
dann erkennen und richtig umschreiben.
Bei verbindungslosen Protokollen wie UDP geht das nicht so
einfach und der Router muss anhand von Aktivitäts-Timern
raten, ob ein Eintrag gebraucht wird, weil noch weitere
Päckchen dieser Art vorbeikommen werden. Liegt er dabei
falsch und verwirft einen NAT-Eintrag zu früh, führt das
bei UDP-Anwendungen wie VoIP, Online-Spielen und Streaming
gelegentlich zu Abbrüchen.
Beim Dateitransfer mittels FTP handeln Client und Server
neben dem Kommando-Kanal eine zusätzliche Verbindung aus.
Damit diese zwischen zwei NAT-behinderten Rechnern zu Stande
kommt, muss mindestens einer der Router die FTP-Konversation
mitlesen und auswerten, um den passenden NAT-Eintrag zu er-
zeugen.
Manche Protokolle funktionieren grundsätzlich nicht, wenn
ihre Datenpakte bei der Gegenstelle mit einer anderen Absen-
deradresse ankommen, als sie abgeschickt wurden. So benötigt
das VPN-Protokoll IPSec eine hässliche Erweiterung namens
NAT-Traversal.
Dieses Problem betrifft nicht nur Heimrouter mit dynamischer
NAT, sondern auch die AdressUmschreiber in den Netzen der Pro-
vider. Beispielsweise beim Internet-Zugang per UMTS ist die
NAT recht offensichtlich, denn die IP-Adresse des mobilen
Rechners und die beim Server ankommende unterscheiden sich,
wie sich zum Beispiel mit dem Dienst „Meine IP-Adresse" auf
heise Netze prüfen lässt (siehe Link am Artikelende).
Ein zweiter dicker Stolperstein für Direktverbindungen sind
die dynamischen IP-Adressen, die der Provider bei jeder In-
ternetEinwahl neu zuteilt. Auch wenn man gestern den eigenen
HeimServer mit den Urlaubsfotos noch erreichen konnte, hat
er heute wahrscheinlich eine andere Adresse bekommen.
Beide Kommunikationshindernisse lassen sich nur mit Netz-
werkgefummel oder mit Softwaretricks umgehen. Entweder
schlägt sich der Anwender selbst mit Port-Forwardings und
-Triggern, mit dynamischem DNS und handgetunten DHCP-Servern
herum oder er überlässt die Kontrolle einer Automatik. Zur
Wahl stehen ein schon vom Design her unsicherer Teil des
Protokolls Universal Plug and Play (UPnP) oder Programme,
die selbst versuchen, die NAT zu überlisten, zum Beispiel
Skype oder die Instant Messenger. Dazu brauchen sie einen
externen Server, zu dem beide Partner eine Verbindung auf-
bauen, um dann die so erzeugten NAT-Tabelleneinträge zum direkten
Kontakt zu benutzen. Dem Betreiber dieses Servers muss man
dabei bedingungslos vertrauen, wenn das Protokoll verschlüs-
selt und undokumentiert abläuft wie bei Skype.

Solche Tricks funktionieren meistens, aber beileibe nicht
immer. Und wenn die Programmierer nicht mit viel Mühe sol-
che Maßnahmen eingebaut haben, um die Daten an den mit NAT
heraufbeschworenen Einschränkungen vorbeizumogeln, geht gar
nichts. So ist es nahezu unmöglich, eine Remote-Hilfe-Sit-
zung mit den Windows-Bordmitteln aufzubauen, wenn der Hilfe-
suchende per NAT-Router am Internet hängt.

Mangelwirtschaft

Dynamische Adressen und NAT sind nur Symptome des Mangels an
IPv4-Adressen, den die Internet-Pioniere schon 1991 zum zehn-
ten Geburtstag von IP vorhersahen. Gleichzeitig mit der Ent-
wicklung von HTTP, HTML und Browsern, die dem Internet sein
rasantes Wachstum bescheren sollten, wurde daher schon an der
Erweiterung des zu knapp bemessenen Adressraums gearbeitet.
Die umfassende Lösung kam Ende 1995 im RFC 1833 als IPv6 mit
viel mehr Adressen. Dank des riesigen Adressraums hat es NAT
nicht nötig. Von drei vorgeschlagenen Protokollen setzte sich
damals das durch, das sich am wenigsten von seinem Vorgänger
IPv4 unterscheidet. Die Hoffnung dabei war, dass der Umstieg
leichter fallen würde, wenn Netzwerker fast nichts dazulernen
müssten. So gab es außer dem von 32 Bit auf 128 Bit vergrößer-
ten Adressfeld nur minimale Änderungen.
Doch fatalerweise rollte da der Internet-Boom schon und der
Netzbedarf wurde durch die Installation der etablierten IPv4-
Gerätschaften gedeckt. Um das Internet gleich auf die richtige
technische Basis zu stellen, war IPv6 minimal zu spät als Pro-
dukt verfügbar - heute unser Pech. Denn eineinhalb Jahre vor
dem ersten IPv6-Standard wurde NAT im RFC 1631 beschrieben.
Die Autoren schlugen es als schnellen Ausweg vor, der die Ad-
ressverknappung bei IPv4 kurzfristig lösen sollte. Langfris-
tig müsse ein neues Internet-Protokoll mit größerem Adress-
raum her.
Die RFC-Autoren erwähnen sogar das oftmals vorgebrachte
Argument, NAT erhöhe die Privatheit der per NAT abgetrennten
Internet-Rechner. Der gleiche Mechanismus erschwert aber die
Suche nach Fehlern und Sicherheitslöchern, fügten sie bereits
damals hinzu. Als negative Auswirkung nennt schon der RFC den
hohen Aufwand bei der Verwaltung der NAT-Tabellen in Routern,
ein hohes Risiko der Fehladressierung von Internet-Rechnern,
die Verkomplizierung von Internet-Anwendungen und -Diensten
sowie diverse Probleme mit dem Domain Name System oder Proto-
kollen wie SNMP.
In den 15 Jahren seitdem hat sich NAT als besonders zählebi-
ges Provisorium erwiesen. Derzeit enthalten über 370 RFCs ei-
nen Bezug zu NAT. Das bedeutet in der Regel, dass sie eine
Methode beschreiben, Protokolle trotz NAT zum Laufen zu bekom-
men.
Dass eine ganze Generation von Netzwerkadmins lernte, mit der
Krücke zu leben, liegt auch daran, dass die Killerapplikation
des frühen Internet kein NAT-Problem hat: E-Mail. Der senden-
de Sever baut eine TCP-Verbindung zum empfangenden auf und
schickt seine Daten hindurch; die IP-Adressen spielen keine
Rolle, es gibt nur eine Verbindungsrichtung und der empfan-
gende Server braucht ohnehin eine feste Adresse (für den MX
-Record).
Auch das ursprüngliche WWW geht sauber durch die Adressen-
übersetzung: Der Browser spricht den Server an und saugt
Daten. Doch mit Web 2.0 beginnt auch hier der Ärger. Denn
die schicken interaktiven Anwendungen bauen Dutzende Verbin-
dung zwischen Browser und Server auf, um Daten nachzuladen.
Dabei laufen immer häufiger die NAT-Tabellen über, und zwar
auch bei den Geräten in den Provider-Netzen. So berichtete
Thorsten Dahm von Google beim IPv6-Kongress Ende Mai in
Frankfurt, dass Google-Maps-Anwender immer wieder über
fehlende Kacheln in den Landkarten klagen, weil einzelne
Verbindungen aus einer NAT-Tabelle geflogen waren.

Auf einer ganz anderen Ebene betrifft die IPv4-Adressknappheit
Unternehmen, die im Web Geld verdienen wollen. Der Plan, nach
dem die letzten freien Adressblöcke an die kontinentalen Ver-
walter verteilt werden sollen, steht fest. Dabei haben sich
Nordamerika (ARIN) und Europa (RIPE) im Laufe der letzten 25
Jahre mit ausreichend IPv4-Adressen versorgt. Für die Nach-
zügler in Afrika (AfriNIC) und Lateinamerika (LACNIC) blieb
da nicht viel übrig. Zwar fehlen in diesen Regionen meist
noch die nötigen Leitungen, doch selbst wenn diese einmal
verlegt sind, kämen Rechner mangels Adressen nicht mehr mit
IPv4 ins weltweite Netz. Dort ist also der Druck, auf Ipv6
zu setzen, viel höher. Web-Anbieter in Europa und Nordame-
rika, die nur per IPv4 erreichbar sind, bleiben für die
reinen IPv6-Surfer unsichtbar und verbergen ihre Seiten
vor potenziellen Kunden.


Zufälliger Schutz

NAT hat jedoch auch einen positiven Nebeneffekt. Sie wirkt
wie eine halbe Firewall, weil an einem NAT-Gerät alle Daten-
pakete abprallen, für die es keinen Eintrag in der Überset-
zungstabelle gibt. Eher zufällig verhindern daher die meis-
ten Heimrouter, dass aus dem Internet initiierte Angriffe
einen PC im LAN erreichen. Ohne NAT kann eine genauso kon-
figurierte Firewall für diesen Schutz sorgen, die Technik
dafür ist vorhanden. Zumindest für Heimrouter liegt es beim
Hersteller, die richtigen Voreinstellungen zu treffen. Wer
dann den Kontakt zu einem seiner Rechner erlauben möchte,
muss ein zusätzliches Loch in seine Firewall bohren, statt
ein Port-Forwarding (also einen NAT-Eintrag für eingehende
Pakete) einzurichten.
Die Oberfläche dafür könnte genauso aussehen wie bei Port
-Forwardings. Und die Fummelei an den Ports für zickigere
Anwendungen wäre dieselbe wie jetzt. Wer diesem Problem
häufiger begegnet, wird wahrscheinlich den Router offener
konfigurieren und die Firewalls auf den einzelnen Rechnern
nutzen - eine Möglichkeit, die er mit NAT und mehreren PCs
nicht hat.

Mit IPv6 überwacht

Auch die dynamischen IPv4-Adressen der Internet-Zugänge für
Privatkunden haben einen Vorteil. Da sie sich bei jeder Ein-
wahl ändern können, fällt es Datensammlern schwer, einen Nut-
zer anhand seiner Internet-Adresse wiederzuerkennen. Zwar
vermerken viele Foren und Wikis die Adresse, von der ein
Beitrag oder eine Änderung kam. Auch E-Mails enthalten im
Header die IP-Adresse des Absenders. Anhand dieser Adressen
lässt sich also feststellen, dass eine Nachricht aus einem
bestimmten Netzwerk kam und dass daher eventuell hanschen
@sorglos.de in irgendeiner Beziehung zum Foren-Troll Anony-
mous steht - sofern sich die Adresse zwischen den beiden
Nachrichten nicht geändert hat.

IPv6 bietet so viele Adressen, dass jeder Internet-Nutzer,
jeder PC und jedes Gerät gleich einen ganzen Adressblock für
sich allein haben kann - dauerhaft. Wenn man mit solchen fes-
ten Adressen ins Internet geht, ist es für Schnüffler wesent-
lich einfacher, beispielsweise die Daten von verschiedenen
Besuchen auf einer Webseite einander zuzuordnen.
Doch die Vorstellung von einer einzelnen, persönlich zuord-
baren IPv6-Nummer ist nicht ganz richtig. Denn wie bei Ipv4
identifiziert auch bei IPv6 die Adresse den Rechner, auf dem
sie konfiguriert ist. Außerdem werden die Adressen nicht ein-
zeln zugeteilt, sondern in Blöcken, den sogenannten Präfixen.
Die heißen so, weil sie den ersten Teil einer Ipv6-Adresse
und dessen Länge enthalten. So umfasst der Präfix 2001:DB8/32
alle Adressen, die mit diesen 32 Bit beginnen. Kurz spricht
man bei so einem Adressblock von einem „32er-Präfix".

Üblicherweise erhalten Kunden vom Provider einen 64er-Präfix,
also 264  Adressen. Eine Methode, wie man in diesem Bereich
die Rechneradresse variieren kann, beschreibt der RFC 4941,
„Privacy Extension for Stateless Autoconfigation in Ipv6".
Unter Windows ist dieses Verfahren per Vorgabe aktiv. Damit
kann ein Datensammler am Präfix nur noch erkennen, dass er
es mit demselben Netzwerk zu tun hat. Aus Privacy-Sicht än-
dert sich also für die Netze nichts, die heute per NAT über
eine feste IPv4-Adresse ans Internet angebunden sind, wie
bei Firmennetzen üblich.
Für Privatkunden mit bisher dynamischer IP-Adresse besteht
zumindest die Chance, den Status quo zu erhalten, denn IPv6
muss keineswegs zwingend mit festen Präfixen betrieben wer-
den. Beim IPv6-Kongress 2009 berichtete Karsten Fleischhauer
über die IPv6-Pläne der Deutschen Telekom, dass die Entschei-
dung für feste oder dynamische Adressen noch nicht gefallen
sei.
Doch wer plant, von einer dynamischen IPv4- auf einen stati-
schen IPv6-Präfix umzusteigen, muss genau abwägen. Einerseits
gewinnt er einigen Komfort, weil er seine PCs und Geräte jetzt
leichter erreichen kann. Doch andererseits gibt er den Daten-
sammlern einen weiteren Baustein für sein Online-Profil in die
Hand. Je weniger Rechner und Personen in einem Netzwerk aktiv
sind, desto genauer lassen sie sich am Präfix wiedererkennen.
Wenn ein Server anhand des festen Präfix erkennt, dass der
Zugriff von einem PC aus einem Unternehmen mit einigen hundert
Arbeitsplätzen kommt, ist die Information ziemlich nutzlos.
Bei einer Kleinfamilie ist das schon ein Einbruch in die
Privatsphäre.
Doch die dynamischen Adressen garantieren keineswegs Ano-
nymität. Schon jetzt bringen Datensammler Cookies, Web-Bugs
und per Flash auf seinem PC gespeicherte Daten in Stellung,
um automatisch Einblick in die Vorlieben eines Surfers zu
erhalten. Auch gegen die vermutete staatliche Datensammel-
wut ist   man damit nicht gefeit. Schließlich schaffen Tele-
kommunikationsgesetz (TKG) und Telekommunikations-Überwach-
chungsverordnung (TKÜV) schon seit Jahren die Voraussetzun-
gen für das Überwachen der Kommunikation. Und wer wann welche
dynamische IP-Adresse genutzt hat, lässt sich derzeit durch
die umstrittene Vorratsdatenspeicherung nachvollziehen. Eine
fester IPv6-Präfix vereinfacht also die Datensammlung, die
ohne ihn aber durchaus möglich ist.  Wer wirklich anonym
bleiben möchte, braucht ein Netzwerk wie Tor, das die IP
-Adressen verschleiert, und muss in seinem Browser alle
Methoden zum Speichern von Daten deaktivieren, nicht nur
die Cookies.

Los! Jetzt!

IPv6 schafft die Adressknappheit und damit viele Netzwerkpro-
bleme aus der Welt. Internet-taugliche Spiele, Messenger und
VoIP-Clients kämen ohne Netzwerktricks und den für die NAT
-Umgehung nötigen Code aus. Das ursprüngliche Paradigma der
Ende-zu-Ende-Kommunikation gilt damit wieder für jeden Nut-
zer im Internet.
Das nicht mehr ganz neue Protokoll soll IPv4 aber nicht
schlagartig ersetzen, denn die Mehrheit aller Dienste und
Anwendungen spricht weiterhin nur das alte Protokoll. Doch
der Weg zum sanften Umstieg ist klar: beide Versionen des
IP lassen sich parallel betreiben. Netzwerker reden vom
Dual-StackBetrieb.
Windows XP, Vista, Mac OS X, Linux und andere Unixe bringen
Netzwerktreiber mit, die beide Protokolle nebeneinander ein-
setzen. Ähnlich sieht es bei den meisten Netzwerk- und Server-
programmen aus: So sprechen die allermeisten Dienste (Datei-
freigabe, Remotedesktop) unter Vista IPv6 und nutzen es wann
immer möglich. Der Nachfolger Windows 7 geht noch weiter: Es
nutzt endlich einigen Techniken, die eigentlich schon in Vista
und zum Teil sogar in XP stecken. Unter anderem beruhen die
Homegroups zur einfachen Einrichtung eines Heimnetzwerks
ebenso auf IPv6 wie die neue, Easy Connect genannte Methode,
um Remote-Hilfesitzungen aufzubauen. Weil die ganze übrige
Branche noch fester geschlafen hat, kann sich Microsoft mit
seinem konsequenten Schritt zu IPv6 auch 14 Jahre nach dessen
Erfindung zu Recht als Technik-Pionier sehen.
In solchen Peer-to-Peer-Anwendungen spielt IPv6 seine ganze
Kraft aus. Seiten wie www. six.heise.de  anzusurfen geht zwar
auch, ist aber ganz klar nicht die „Killerapplikation" für
IPv6. Wer dennoch IPv6-taugliche Websites sucht, findet bei
www.sixy.ch   eine gute Quelle. Die Datenbank nimmt Einträge
mit einer Kurzbeschreibung und Tags entgegen und liefert sie
über eine Suchfunktion aus. Aktuell listet sixy.ch circa 1700
Websites.
I m LAN sprechen die aktuellen Betriebssysteme automatisch
IPv6, Windows sogar bevorzugt. Doch die großen deutschen Pro-
vider bieten bislang kein IPv6-DSL an. Einzig einige weniger
bekannte wie Spacenet, Rh-tec, Tal.de und Titan Networks lie-
fern IPv6 als Zugabe (siehe Link). Die größeren Anbieter wie
Telekom oder Vodafone berichteten zwar auf dem Ipv6-Kongress
über ihre Ausbaupläne und Testinstallationen. Doch Termine
oder gar Preise nannten sie nicht. Dass es auch anders geht,
zeigt das Beispiel des französischen DSL-Anbieters Free, der
seine zwei Millionen Kunden in nur wenigen Wochen ans Ipv6
-Internet angeschlossen hat.
Wer seinen Provider nicht wechseln möchte, kann sich Ipv6
über kostenlose Tunnel, zum Beispiel von Sixxs.net, Hurricane
Electric oder Hexago, mit dem IPv6-Netz verbinden oder die von
Microsoft entwickelte Technik Teredo benutzen. Links zu den
Anbietern und zu Konfigurationsanleitungen auf heise Netze
finden Sie über den Link am Artikelende.
Beim Dual-Stack-Betrieb behindert ein Geburtsfehler das Ipv6:
Die Funktionsaufrufe sind so definiert, dass der Programmierer
festlegen muss, ob er eine IPv4- oder IPv6-Verbindung aufbauen
möchte. Damit liegt auch die Prüfung in seiner Hand, ob Ipv6
überhaupt korrekt funktioniert. Viel vernünftiger ist der Weg,
den einige Laufzeitumgebungen wie Java und das aktuelle Win-
dows anbieten: Der Programmierer wünscht sich per Funktions-
aufruf einfach „eine Verbindung zu www.heise.de Port 80" und
überlässt der Laufzeitumgebung die Wahl der besten Protokoll-
version. Doch bis sich dieses Muster durchsetzt, heißt es Aus-
schau nach IPv6-tauglichen Applikationen halten und die nöti-
gen Häkchen manuell setzen.

Zugangszögerlichkeit

Eigentlich erstaunt es, dass ausgerechnet die Zugangsprovider
so zögerlich umstellen. Denn gerade sie konnten seit langem
beobachten, dass die Adressen für die Einwahl zur Neige gehen.
Doch sie haben wohl nur auf den Termin zur Verteilung der
letzten freien IPv4-Blöcke gestarrt, die derzeit für Mitte
2011 prognostiziert wird. Aber die Einführung braucht eine
mehrjährige Dual-Stack-Phase, bis kein einziges Angebot mehr
IPv4-only ist.
In dieser Zeit wird der Bedarf an alten Adressen weiter
steigen, und dafür reichen die restlichen Pools nicht aus.
In der Diskussion sind zwei Übergangsmodelle: Noch mehr NAT,
also eine zusätzliche Übersetzungsstufe innerhalb der Netze.
Oder ein dreister Bit-Diebstahl: Die 32 Bit des Adressfelds
genügen nicht, doch die 16 Bit im Port-Feld bei Dank Ipv6
hat die Remote-Unterstützung von Windows 7 keine Probleme
mehr mit NAT-Routern.
TCP und UDP sind mehr, als ein Server normalerweise braucht.
Selbst 256 Ports sind auf kaum einem Rechner offen, man könn-
te also die Hälfte der Port-Bits klauen und als zusätzliche
Adressierung benutzen. Da weder Client noch Server etwas
davon merken sollen, ist das eine Art NAT in die Breite,
die allein neu zu installierende Netzwerkkomponenten erledi-
gen müssen. Bei der Vorstellung rollen sich dem Netzwerker
die Zehennägel hoch, doch wahrscheinlich wird das Verfahren
aus purer Not eingeführt, um irgendwie über die Dual-Stack
-Phase zu kommen. Die Verfechter dieser Krücke zur Krücke
versprechen, dass es aber wirklich nur eine kurzfristige
Übergangslösung sei - wie es auch der NAT-RFC von 1994
versprach.
Immerhin scheint IPv6 in diesem Jahr endlich Fahrt aufzuneh-
men. Die großen Provider werfen keine hinhaltenden Sprach
-Nebelkerzen mehr, sondern sprechen deutlich über die tech-
nische Seite ihrer Pläne. Mit dem D-Link DIR-825 ist der
erste IPv6-taugliche Heimrouter auf den deutschen Markt
gekommen und für mehrere FritzboxModelle bietet AVM immerhin
die Beta-Version einer IPv6-Firmware an. Große Hoster bauen
IPv6 in ihre Netze ein und testen bereits mit „Friendly Cus-
tomers", also technisch versierten Kunden, die nicht zu viel
plaudern.
Doch so richtig will niemand losstürmen, alle warten auf die
jeweils anderen Mitspieler. Die üblichen Ausreden lauten „Kein
Kunde fragt nach IPv6" und „Wir sind dabei, aus IPv6 ein Pro-
dukt zu machen". Beides geht in die falsche Richtung, denn die
Endkunden sollten sich eigentlich nicht mit der Version ihres
Internet-Protokolls herumschlagen müssen. Es fragt ja auch
niemand nach „DIN IEC 60038". Die legt fest, dass der Strom
aus der Steckdose 230 Volt und 50 Hz hat. Genauso sollte Ipv6
eigentlich schon längst unbekannt und zuverlässig das Internet
tragen.
(je/rek)

Antworten