IP Version 6. Die Spatzen schreien es von den Dächern: der Adressraum im Internet wird knapp. Abhilfe existiert in Form von IP Version 6 (oder kurz: IPv6) schon seit 1995, aber in der Praxis merkt man davon herzlich wenig. Nach jahrelanger Flaute haben jetzt plötzlich große Routerhersteller offiziell IPv6-Support im Angebot, so daß sich eine nähere Betrachtung langsam zu lohnen beginnt. Der Adressraum des Internets hat Platz für über vier Milliarden Adressen. Bei einer Anfangspopulation von einer handvoll Maschinen erschien das unüberschaubar viel, und dementsprechend ist man damit umgegangen. Frühe IP-Benutzer wie Berkeley oder Digital haben mal eben 16 Millionen IP-Adressen zugewiesen bekommen. So ist es nicht erstaunlich, daß langsam ein Ende der freien Adressen absehbar wird (auch wenn wir davon noch relativ weit entfernt sind. TODO: RIPE nach aktuellen Zahlen fragen). Wenn demnächst Mobiltelefone, Autoradios, Kühlschränke und Videorekorder Internet-Zugang haben sollen, dann ist aber auch diese Reserve schnell verbraucht. Damit man auch in Zukunft wieder so verschwenderisch mit dem Adressraum umgehen kann wie man es anfangs mit IPv4 gemacht hat, ist bei IPv6 die Adressgröße nicht nur verdoppelt oder verzehnfacht worden, sondern gleich auf 2^128 erhöht. Diese Zahl ist astronomisch; es gibt viel mehr IPv6-Adressen als Atome im Universum (Schätzungen divergieren von 2^66 und ~2^80). Man kann also Verwaltung sparen und wieder verschwenderisch und ad-hoc mit Adressen umgehen. Und für den unwahrscheinlichen Fall, daß man irgendwann doch zu verschwenderisch war, sieht IPv6 auch noch automatische Umnumerierung vor (d.h. der IP-Bereich einer Organisation wird verschoben, ohne daß jemand alle Endgeräte anfassen muß). Nach Jahren der Erfahrung mit IPv4 stellte sich erfreulicherweise heraus, daß eigentlich alles ganz akzeptabel funktioniert. Das Internet ist immerhin größer geworden als seine Erfinder je gedacht hatten. Und dank der Nutzung privater IP-Netze, NAT, VPNs und Firewalls ist die genaue Zahl der IP-Adressen in Benutzung nicht einmal genau feststellbar. Trotzdem hat das Protokoll Runzeln und Warzen, die man bei einer Generalüberholung auch gleich mal entfernen kann. So sind z.B. bei IPv4 Router damit beschäftigt, Checksummen zu prüfen und Pakete zu fragmentieren. Das sind grundsätzlich keine schwierigen Aufgaben, aber bei dem enormen Durchsatz heutiger Leitungen ist es wichtig, die Arbeit des Routers zu minimieren. IPv6 hat daher keine Prüfsumme im IP-Header (sondern im TCP-Header, d.h. kaputte Pakete werden immer noch von den Endpunkten erkannt) und Router fragmentieren zu große Pakete nicht mehr, sondern schicken eine Fehlermeldung zum Endpunkt. Der kann dann die maximale Paketgröße ("MTU", Maximum Transmission Unit) entsprechend anpassen. Dieses Verfahren heißt Path MTU Discovery und es existiert in leicht abgewandelter Form auch in IPv4 (dort muß man ein "Don't Fragment" Bit setzen, um den Effekt zu erhalten). Dort ist dieses Verfahren zwar empfohlen aber es eben nicht Pflicht, im Gegensatz zu IPv6. Manchmal sorgen kaputte Firewalls oder Transfer-Netze mit reservierten IP-Adressen (10.*, 172.16.* und 192.168.*) dafür, daß ICMP-Meldungen komplett verloren gehen, wodurch die Path MTU Discovery fehlschlägt und TCP-Verbindungen "hängenbleiben". IPv4 definiert die kleinste MTU als 68 Bytes sehr klein. Wenn ein Host merkt, daß Path MTU Discovery fehlschlägt, muß er sich also auf 68 Bytes Paketgröße beschränken, was Router und Bandbreite unnötig belastet. Bei IPv6 ist die minimale MTU auf 1280 Bytes erhöht worden. Als weitere Maßnahmen zur Entlastung der Router ist die Header-Länge fest (bei IPv4 ist sie variabel lang) und die wichtigen Felder sind 64-bit aligned. Falsches Alignment bremst heutige Prozessoren beim Speicherzugriff um bis zu dem Faktor drei aus, das ist also eine sehr gute Maßnahme. Die Flags wurden ganz aus dem Header entfernt, und dafür kann man bei IPv6 Optionen in Zwischen-Headern zwischen IP und UDP/TCP einfügen. Außerdem ist das Feld "TTL" jetzt zu "Hop Limit" umbenannt worden, was ihrer Bedeutung auch bei IPv4 entspricht. Zusätzlich (siehe MPLS) gibt es ein "Flow Label" Feld, über das man viel schnelleres Routing hätte implementieren können, wenn es nicht kürzlich durch MPLS überflüssig gemacht worden wäre. Aber genug zu den Routern. Das Protokoll muß natürlich auch den Administratoren und Endbenutzern deutliche Vorteile bringen, damit es überhaupt eine Chance hat. Für beide Gruppen ist es wichtig, die Support-Probleme zu lösen, die IPv4 plagen, wenn Leute an ihren Rechnern Konfigurationen vornehmen müssen, um im Web surfen zu können. Die erste Idee war eine Anpassung des alten BOOTP-Protokolls. Herausgekommen ist DHCP, erstmal für IPv4. DHCP ist aber servergebunden, das ist noch nicht ausreichend. Die IPv6-Ingenieure haben augenzwinkernd zwei Szenarien definiert, die IPv6 lösen soll: a) eine Zahnarztpraxis, in der gerade zwei Rechner gekauft und zusammengestöpselt wurden und der Arzt will jetzt Daten zwischen beiden austauschen, und b) eine Messehalle mit 10000 Rechnern, die morgen früh um acht alle am Internet angeschlossen werden sollen. Es ist also eine Autokonfiguration gefragt, die völlig ohne Benutzereingaben auskommt. Und hier hat IPv6 in der Tat Pionierarbeit geleistet. Bei IPv6 hat man nicht nur eine IP-Nummer pro Interface, sondern es gibt Link-Local, Site-Local und ganz normale globale IP-Nummern. Der Clou ist, daß die Link-Local Adresse direkt aus der Ethernet (oder sonstigen Layer-2) MAC berechnet wird, d.h. jedes Gerät hat für jeden Link automatisch eine Link-Local-Adresse. IPv6 sieht auch noch eine Kollisionserkennung vor, die allerdings dann Rückfall auf manuelle Intervention zur Folge hat. Mit dieser Link-Local Adresse kann das Endgerät dann auf dem Link kommunizieren und z.B. per Multicast die Router finden. Wenn die Router bekannt sind, läßt sich das Endgerät von diesen seine globalen IP-Adressen geben. Bei IPv6 kann man pro Router mehrere IP-Adressen haben und über alle gleichzeitig erreichbar sein. Der Host sucht sich automatisch die richtige Route und den richtigen Router. Fehlt eigentlich nur noch das automatische Finden des Nameservers, und hier hat auch IPv6 keine Patentlösung. Es gibt verschiedene funktionierende Ansätze. So könnte z.B. der Host per Site-Local Multicast an eine definierte Gruppe die DNS-Server finden. Und es gibt auch noch eine Idee namens Anycast, bei der man eine IP-Adresse für den Nameserver vergibt, und wenn jemand ein Paket an diese IP-Adresse schickt, dann leiten die Router das an den nächsten DNS-Server weiter. Das heißt natürlich, daß der nächste DNS-Server auf dem Router konfiguriert werden muß, aber immerhin wird der Anwender nicht von Einstellungen verwirrt. Allein, es fehlt hier ein Machtwort der IETF. Überhaupt ist DNS das schwächste Glied bei IPv6. Lange Zeit gab es gar keine funktionierenden DNS-Server für IPv6, inzwischen tritt immerhin das Superschwergewicht BIND 9 an und Patches für djbdns sind in Arbeit. Und wenn man sich das Level der Dynamik und Automatismen in IPv6 anschaut, wird klar, daß dynamic DNS eine deutlich wichtigere Rolle zukommt als bei IPv4. Wenn die IP-Adresse schon automatisch konfiguriert wird, dann fällt allerdings auch bei DHCP der dynamische Part weg, d.h. man kann den DNS-Server natürlich per DHCP abfragen, ohne daß der DHCP-Server in einer Datenbank verwalten müßte, welchem Client er jetzt welche IP zugewiesen hat. So werden Synchronisationsprobleme zwischen DHCP-Servern vermieden, und bei Abstürzen des DHCP-Servers ergeben sich nie Inkonsistenten zwischen der Datenbasis und dem tatsächlichen Zustand. Um auf diesen Umstand noch einmal besonders hinzuweisen: bei IPv6 stellt man keine IP-Adresse ein. Man startet sein Endgerät und hat Zugang zum Netz. Wenn ein neuer Router im Netz installiert wird, stellt man nirgendwo irgendwas ein und man bootet auch nicht, es funktioniert einfach. Wenn ein Router entfernt wird, ebenfalls. Sogar wenn die Firma einen anderen IP-Bereich zugewiesen bekommt, funktioniert das einfach so auf allen Endgeräten. die Enduser merken nicht einmal, daß sich etwas geändert hat. Das sind Aussichten, bei denen heutigen Administratoren das Wasser im Munde zusammenläuft, stellen doch bereits subtilste Veränderungen in der Netzkonfiguration Supportabteilungen vor riesige Probleme. In manchen Firmen werden die Rechner sogar per zentralem Schalter an der Stromversorgung gebootet, damit sie sich morgens die aktuelle Konfiguration per DHCP geben lassen! Nun fragt man sich spätestens an dieser Stelle, wieso sich IPv6 noch nicht durchgesetzt hat. Die alleine hier einzusparenden Kosten amortisieren ja schon alleine in größeren Konzernen die Kosten für neue Router und andere Infrastruktur in nur wenigen Monaten. Die Antwort ist einfach: die Vorteile von IPv6 wurden der Reihe nach auf IPv4 zurückportiert, mit mehr oder weniger großem Erfolg. Bei der Adresskonfiguration gibt es inzwischen auch Regeln für IPv4, wie vorzugehen ist, wenn kein DHCP-Server gefunden wird. Diese Regeln sind sogar schon in Windows ME implementiert worden, d.h. Mainstream. Und ähnlich ist es auch fast allen anderen Features ergangen. Denn IPv6 bietet noch viel mehr als Autokonfiguration! So gibt es zum Beispiel eine Arbeitsgruppe bei der IETF, die sich mit Mobile IPv6 beschäftigt. Die Idee ist, daß man seinen Laptop auf einer Konferenz einfach wie gewohnt anstöpselt (oder, wie es heute üblich ist, per Funknetz Internet-Zugang bekommt) und dann mit seiner IP von zuhause weiterarbeitet. Wenn man den Laptop zuhause nicht ausgeschaltet sondern nur im Suspend-Modus schlafen gelegt hat, dann sollen sogar die TCP-Verbindungen noch bestehen! Alte Netzwerk-Hasen werden sich jetzt fragen, wie das mit Routing-Protokollen in Einklang zu bringen sein soll, die Adressen aggregiert betrachten und in arge Performance-Probleme geraden würden, wenn jede IP anders zu routen wäre. Die offensichtliche Lösung wäre der Aufbau von IP-Tunneln zwischen dem heimischen Netz und dem Konferenznetz, aber dann würde der Traffic ja doppelt über das Netz gehen. Bei IPv6 hat man daher extra für diesen Zweck eine ICMP-Umleitungsnachricht eingeführt, mit der der Laptop auf der Konferenz einen Agenten-Rechner im heimischen Netz mitteilen kann, unter welchen IPs er gerade erreichbar ist, und der Agent kann dann einkommende Verbindungen dorthin umleiten. Bei dieser Vorstellung stehen Sicherheits-Experten natürlich die Haare zu Berge, und böse Hacker freuen sich schon darauf, onlinebanking.grossebank.de zu sich nach Hause umleiten zu können. Es ist klar, daß der Agent nicht einfach auf Zuruf Verkehr umleiten wird oder kann, sondern hier muß mit kryptographischen Methoden für eine starke Authentisierung gesorgt werden. Zufällig ist auch kryptographische Authentisierung einer der vielen Vorteile von IPv6, gepaart mit Verschlüsselung zur Sicherung der Privatsphäre. Das Schlagwort hierfür ist IPsec, und auch IPsec ist inzwischen für IPv4 nicht nur definiert worden, sondern auch in regem Einsatz (wenn auch bislang hauptsächlich im Tunnel-Modus für VPNs und nicht Punkt-zu-Punkt, wie es bei IPv6 eigentlich gedacht ist). Und da IPv6 von Ingenieueren der IETF und nicht von der Marketing-Abteilung von Microsoft definiert wurde, kommt "richtige" Kryptographie zum Einsatz, d.h. die Verfahren sind offen, erprobt, und haben auch schon mehrere Jahre offen gelegen und sind in der Zeit von fast allen Experten eingesehen und kritisiert worden. Wenn man also von IPsec eine vernünftige Implementierung erwischt, gibt es auch für Berufsparanoiker keinen Grund für Mißtrauen dem Verfahren gegenüber. Als kleiner Anhaltspunkt sei hier nur genannt, daß DES sofort aus der Liste der symmetrischen Chiffren genommen wurde, als vor ein paar Jahren der Hardware-DES-Knacker der EFF publik wurde. Neben diesen für jedermann interessanten Features gibt es auch einige Neuerungen, die eher für große Firmen interessant sind (oder sehr langfristig auch für das Internet), aber keinen sofortigen Gewinn durch ihre bloße Anwesenheit erbringen: Multicast und Quality of Service. Natürlich sind auch Multicast und Quality of Service umgehend zu IPv4 zurück portiert worden, wo sie seit dem eine steigende Anhängerschaft genießen, wenn auch bisher vor allem bei Technikern und in großen Firmennetzen. Multicast ([Verweis auf Literaturliste/meinen Multicast- Artikel]) ist ein Verfahren zur effizienteren Bandbreitenausnutzung bei der Übertragung an mehr als einen Empfänger (d.h. besonders für Video- und Audio-Streaming mit hoher Bandbreite wichtig) und Quality of Service faßt Protokolle und Methoden zusammen, mit denen einzelne Datenströme bevorzugt behandelt werden können. Die Idee ist, daß der Anwender für den Radioempfang über IP bezahlt und den Datenstrom dann auch ohne Paketverlust, Rauschen oder Verzögerungen zugestellt bekommt. Aber auch für andere Anwendungen ist geringer temporaler Jitter wünschenswert, insbesondere bei den immer erfolgreicheren IP-Telefonen. Bei IPv6 hat Multicast dank der breiteren Adressen noch stärkere Flexibilität. So sind ganze 4 Bit der Adresse für den Scope reserviert, d.h. sagen aus, wie weit eine Multicast-Ausstrahlung propagiert werden soll. Man kann also relativ fein von "darf diese Node nicht verlassen" über "bleibt in der Firma" bis zu "weltweite Ausstrahlung" die Propagierung einschränken. Die Programmierer unter den Lesern werden sich langsam fragen, wie sich diese ganze zusätzliche Flexibilität in fürchterlich komplizierten APIs niederschlägt. Immerhin hat es im letzten Jahr eine deutliche Zunahme an offen IPv6 unterstütztenden Applikationen in der freien Softwareszene unter Unix gegeben, während es früher nur auf obskuren Sites im fernen Osten Patches mit japanischen Kommentaren gab, die man sich mühsam zusammensuchen mußte, um überhaupt in den Genuß von Anwendungen zu kommen, die IPv6 unterstützen. Wie gesagt, inzwischen sieht das anders aus. Es gibt FTP- und Webserver und -clients, openssh unterstützt IPv6, natürlich gibt es ping und traceroute für IPv6 und wie gesagt gibt es auch Nameserver mit IPv6-Support. Nun, das ursprüngliche socket-API von BSD ist relativ abstoßend zu benutzen, vor allem wegen inkompatibler Änderungen durch Normierungsgremien und Alleingänge von Betriebssystemherstellern (Stichwort: socklen_t). So hat man sich bei IPv6 entschlossen, das API möglichst vollständig beizubehalten und nur um einige Funktionen zu erweitern, die protokollunabhängig Namensauflösung erledigen und Dienstnamen auflösen. Insbesondere haben die API-Designer darauf geachtet, daß auf IPv6 umgestellte Software automatisch weiterhin IPv4 unterstützt. Nur so ist eine Umstellung zumutbar, und ein Software-Autor wird eher willens sein, Änderungen für IPv6-Unterstützung vorzunehmen. Wem die Liste der Vorteile von IPv6 vielleicht zu abstrakt ist, dem sei empfohlen, sich mal ncp anzuschauen (siehe Literaturliste). Dieses Programm benutzt Multicast und Link-Local Adressen, um völlig ohne Eingabe von Namen, IP-Nummern oder sonstiger Konfiguration Dateien zwischen Rechern in einem LAN zu übertragen. Während ncp auch in einem IPv4-Netz per Multicast oder Broadcast den anderen Sender finden kann, können inkompatible IP-Einstellungen dafür sorgen, daß die Rechner trotzdem keine TCP-Verbindung aufbauen können. Mehr Effizienz. Wie bereits erwähnt bringt IPv6 gravierende Effizienzsteigerungen für Router. Die Funktion des Flow Labels entspricht weitgehend dem, was man inzwischen über MPLS (siehe Literaturliste) auch prototollunabhängig erreicht. Sehr gewinnbringend ist auch, daß Router nicht mehr fragmentieren müssen. Aber das praktisch größte Problem wird durch die Fähigkeit, im laufenden Betrieb und ohne manuellen Eingriff des Administrators den Adress-Bereich zu verändern, aus der Welt geschafft. Die Routing-Tabellen könnten dadurch deutlich verkleinert werden, denn bei den IPv4 Routingtabellen gibt es fragmentierte Adressbereiche (d.h. der Gesamtbereich gehört ISP XY aber ein Unterbereich Z gehört einem Kunden, der inzwischen zu einem anderen ISP umgezogen ist, d.h. der nicht über ISP XY geroutet wird) und große Bereiche, die aus historischen Gründen jemandem gehören, der sie gar nicht oder nur sehr eingeschränkt nutzt. Wenn man diesen Bereich aber aufteilt, dann wäre er nicht mehr als Aggregat durch eine Route zusammenfaßbar und die weltweite Routingtabelle würde explodieren. Diese ganzen Kalamitäten vermeidet Renumbering sehr elegant. Aber nicht nur die Routing-Effizienz kann so gesteigert werden! Viele Kunden wechseln den ISP nicht, obwohl er schlechte Leistung zu überhöhten Preisen bietet, weil sie die Kosten für die Adressumstellung fürchten! Solche Kunden haben dem ISP gegenüber keinerlei Druckmittel in der Hand. Mit Renumbering ändert sich das. Aber auch im LAN bietet IPv6 Effizienzsteigerungen. So gibt es keinen Broadcast mehr. Alle früher über Broadcast abgewickelten Protokolle werden bei IPv6 über Multicast implementiert. Als Beispiel sei ARP genannt. ARP ist das Protokoll, mit dem man bei IPv4 die MAC-Adresse (d.h. die eindeutige Nummer der Ethernet-Karte) zu einer IP herausfindet. Bei IPv6 wird diese Funktionalität über Neighbor Solicitation Pakete implementiert. Das funktioniert dann so, daß man aus der IP-Adresse, zu der man die MAC-Adresse sucht, mittels einer Funktion aus dem Standard eine Multicast-Gruppe errechnet, und an diese schickt man dann die Anfrage. Jeder Host ist laut Standard gezwungen, sich bei der Multicast-Gruppe zu subscriben, die zu seiner IP gehört. Der Effekt ist, daß in großen geswitchten Ethernets Neighbor Discovery Pakete praktisch nur auf den Strängen zu sehen sind, bei denen der Host sich tatsächlich befindet. Das mag jetzt vielleicht wie eine unwichtige Detailverbesserung aussehen, aber es gibt durchaus Szenarien, in denen der ARP-Verkehr signifikante Bandbreite verbraucht. Angenommen, man verbindet ein sehr großes geswitchtes Ethernet mit einem Wireless LAN, welches nur ein hundertstel der Bandbreite hat. Dann kann es bei IPv4 schon einmal vorkommen, daß das Wireless LAN zu einem signifikanten Teil durch ARP-Anfragen gefüllt wird. Verschärft wird diese Situation durch Portscans, wie sie bei Hacker-Conventions und LAN-Parties üblich sind. In solchen Fällen sind Wireless LAN Anbindungen gewöhnlich vollständig mit ARP-Verkehr ausgelastet. Bei IPv6 stünde in diesem Fall die volle Bandbreite weiterhin zur Verfügung. Ähnlich elegant geht es bei der Selektion der Router zu (siehe Kasten "IPv6-Bootstrap"). Während man bei IPv4 IGMP als eigenes Protokoll neben ICMP umgesetzt hat, ist Multicast Listener Discovery ein Subtyp von ICMPv6. Bei IPv6 gibt es außerdem eine "Jumbogram" genannte Erweiterung für die Supercomputing-Fraktion. Die haben nämlich erwogen, für die Verbindungen zwischen den Teilen eines Clusters oder einer NUMA-Maschine IPv6 einzusetzen. Diese Verbindungen zeichnen sich durch eine enorme Bandbreite aus, so daß Paketgrößen größer 64 Kilobytes sinnvoll werden. Die Jumbogram-Extension erlaubt genau das. Übergangslösungen... Möglicherweise ist an dieser Stelle der eine oder andere überzeugt, sich einmal mit IPv6 zu beschäftigen. Wenn es sich um eine neue Version von IP handelt, muß man dann auf das alte IP verzichten? Wenn man IPv6 fertig angesehen hat, kann man dann wieder zurück? Muß man dann vielleicht sein Betriebssystem neu installieren? Kommt man überhaupt ins Internet mit IPv6? Diese Fragen beschäftigen diverse Gremien seit über zehn Jahren, insbesondere die NGtrans-Arbeitsgruppe der IETF (NG steht für "Next Generation", denn IPv6 lief anfangs unter dem Namen IPng). Die meisten Rechenzentren sind ihre gesamte Existenz über mit Umstellungen beschäftigt - IPX zu IP, Host zu Windows, Windows zu Linux, OS/2 zu Windows, SAP zu einer neueren Version, ... Kurz, das sind langwierige Prozesse, die viel Geld und Nerven kosten. Bei IPv6 war man sich daher einig, daß es nicht reicht, wenn IPv6 mit vielen Features überzeugt, sondern man muß auch dafür sorgen, daß der Übergang von IPv4 zu IPv6 besonders schmerzfrei von statten gehen kann. Insbesondere heißt das, daß man nicht eines nachts einen großen roten Schalter umwirft und ab dann IPv6 fährt, sondern daß der Übergang aus vielen kleinen Schritten besteht, die die Funktion der IPv4-Infrastruktur nicht beeinträchtigen, so daß zu keinem Zeitpunkt irgendwelche wichtigen Anwendungen spontan zu funktionieren aufhören. Auf IPv6 umgestellte Anwendungen sollen sogar auch in einer Umgebung funktionieren können, die kein IPv6 versteht! Wenn man schrittweise umstellt, fängt man gewöhnlich im LAN an. Dort gibt es an Infrastruktur grundsätzlich Geräte auf Layer 1 (z.B. Hubs), auf Layer 2 (Switches) und auf Layer 3 (Router). Layer 1 Geräten sind für IPv6 völlig transparent. Bei Layer 2 Geräten machte man sich anfangs Sorgen, weil Switches mit Multicast anfangs nicht zurecht kamen. Inzwischen ist anständiger Multicast-Support Standard und Switches, die in den letzten 10 Jahren gekauft wurden, unterstützten mit großer Wahrscheinlichkeit IGMP Snooping für IPv4-Multicast und ICMP-Snooping für IPv6-Multicast. Wenn man sich auf LANs beschränkt, markieren die Layer 3 Geräte meistens das Ende des Netzes und sind daher auch nicht wichtig. Man kann also heute im LAN prima mit IPv6 arbeiten, ohne irgendwelche Investitionen tätigen zu müssen. Auch von den wichtigsten Router-Firmen gibt es schon seit Jahren inoffiziell IPv6-Support in Form von Beta-Firmware, für die man dann ein NDA unterschreiben mußte. So war das jedenfalls bei Cisco, die kürzlich eine IPv6-Releaseversion zum Ende des Jahres angekündigt haben. Bei den wirklich großen Router-Eisen ist dank MPLS das geroutete Protokoll egal. Und bei den kleineren Routern gibt es inzwischen mehrere Angebote (siehe Literaturliste). Die Transitions-Arbeitsgruppe hat sich Gedanken gemacht, wie man auch mit Switches und Routern IPv6 betreiben kann, die nur IPv4 sprechen. Der hauptsächliche Mechanismus ist der Dual Stack, d.h. das Betriebssystem spricht IPv6 und IPv4. Der Standard sieht dann vor, daß man IPv4-Adressen einfach in IPv6-Adressen einbetten kann, indem man den Prefix ::ffff benutzt und dann die 32 Bits der IPv4-Adresse anhängt. Wenn eine IPv6-Anwendung zu so einer Adresse eine Verbindung aufbaut, dann sieht das Betriebssystem das und baut tatsächlich eine IPv4-Verbindung auf. Die Applikation arbeitet aber nach wie vor mit IPv6-Sockets und getpeername() und getsockname() liefern dann auch eingebettete IPv4-Adressen. So kann man eine IPv6-fähige Applikation einfach transparent für IPv4-Kommunikation benutzen, wenn das Umfeld es erfordert. Das erfordert natürlich erhöhte Aufmerksamkeit bei DNS-Anfragen oder bei der Umsetzung von Zugriffskontrolllisten (ACLs), weil man IPv4-ACLs dann ebenso auf eingebettete Adressen anwenden muß, und weil die DNS-Routinen gewöhnlich nicht mit eingebetteten Adressen klarkommen, ist auch hier etwas Handarbeit vonnöten. Diese kann man aber mittels geeigneter Abstraktionen weitgehend vom Programmier fernhalten. Die anderen Transitionsmechanismen beschäftigen sich damit, wie man IPv6 geschickt über IPv4-Infrastruktur tunneln kann, d.h. am besten so, daß sich die Tunnel automatisch selbst einrichten. Das erfordert aber gewöhnlich auf IPv4-Ebene Multicastfähigkeit, und die ist leider in der Praxis auch eher auf LANs beschränkt. Man kann relativ schmerzfrei mit ein paar statischen Tunnels IPv6-Inseln über das Internet verbinden. So ist das ja bereits mit Multicast-Inseln geschehen und in Anlehnung an diesen MBONE nennt sich das IPV6-Tunnelnetz 6BONE (siehe Literaturliste für URL). Und damit das auch mit dynamischen IPv4-Adressen funktioniert, sind die sogenannten Tunnel-Broker erfunden worden, bei denen man sich nach dem Einwählen automatisch seinen Tunnel aktivieren kann. Schade, daß die Breiten-ISPs so selten IPv6 anbieten, denn mit PPP kann man IPv6 fahren und die freien PPP-Dämonen unterstützten das auch bereits. Privatleute können sich zum Testen beim diversen Projekten kostenlos IPv6-Tunnel schalten lassen (u.a. http://www.freenet6.net/). Wo Licht ist, ist auch Schatten. IPv6 ist nicht gänzlich problemfrei. So sind Stellen der Spezifikation gegenüber früheren Versionen der Spezifikation deutlich verändert worden. Die dramatischste Änderung war sicherlich der Übergang zu EUI-64 (siehe Kasten "IPv6-Bootstrap"), aber auch die struct sockaddr_in6 (im BSD socket API das IPV6-Äquivalent zur sockaddr_in von IPv4) hat sich geändert; ein Feld "scope_id" ist dazu gekommen. Die wichtigste Bedeutung hat das Feld bei Kommunikation über Link Local Adressen. Aufmerksame Leser werden schon bemerkt haben, daß Link Local Adressen relativ zum Link sind. Das hat den Nachteil, daß eine Link Local Adresse alleine noch keinen Kommunikationsendpunkt definiert, sondern man auch noch dazu sagen muß, auf welchem Link denn diese IP liegt. Das ist zwar eigentlich nur wichtig, wenn man mehr als eine Netzwerkkarte hat, aber aktuelle Implementationen erlauben nur Kommunikation, wenn man die Interface-Nummer in das scope_id Feld eingetragen hat. Nun ist das an sich noch kein Problem, aber das Konzept der Interface-Nummern ist ein eher obskurerer Teil des socket APIs, der sich zu vielen Programmierern noch nicht herumgesprochen hat. Wer davon noch nie etwas gehört hat, dem sei hier die Lektüre der Dokumentation zu if_indextoname() und if_nametoindex() empfohlen. Das Hauptproblem ist allerdings, daß die Angabe einer IPv6-Adresse nicht mehr ausreicht, um mit einem Host eine Verbindung aufzubauen. Das ist schlecht, weil man z.B. im DNS nur die IP-Nummer unterbringen kann, nicht die Interface-Nummer. Und die meisten IPv6-Applikationen sind sich des Problemes nicht bewußt und haben daher überhaupt keine Möglichkeit vorgesehen, mit der man den Link spezifizieren könnte. OpenSSH hat z.B. an dieser Stelle ein Problem. Das äußert sich so, daß connect() den Fehler EINVAL zurückliefert. Bei Servern ist das noch relativ leicht zu beheben, weil man dort einfach von den einkommenden Paketen die scope_id übernehmen kann. Aber selbst wenn Software diese Problematik erkannt hat, kann es sein, daß die libc etwas älter ist und das scope_id Feld gar nicht in der Struktur definiert hat! Bei der GNU libc muß man z.B. mindestens Version 2.2 benutzen. Auch an anderer Stelle gab es durch die Volatilität der Standards und Implementationen Probleme. Welches ist z.B. die Fehlermeldung, wenn man mit socket() ein IPv6-Socket erzeugen will, aber der Kernel keinen IPv6-Support aktiviert hat? Linux hat früher EINVAL zurückgeliefert, heutige Kernels liefern EAFNOSUPPORT. Warum haben wir denn noch nicht alle IPv6? Die größten Vorteile von IPv6 sind: Autokonfiguration, Multicast, IPsec, Quality of Service, Renumbering, und die größeren Adressen. Bis auf die größeren Adressen und Renumbering gibt es das alles inzwischen auch für IPv4, und Renumbering läßt sich durch DHCP annähern. Es gibt daher für die meisten Leute keinen zwingenden Grund, zu IPv6 zu wechseln. Die einfachen Transitionsmechanismen haben außerdem den Eindruck erweckt, daß man sich damit heute noch nicht beschäftigen muß. Hinter den Kulissen tut sich allerdings einiges. Die freien Betriebssysteme sind inzwischen voll IPv6-fähig inklusive Clients und Servern für die meisten Dienste und Software wie dem Router Advertisement Daemon, Routing-Software und DNS-Server. Wer will, kann also heute relativ schmerzfrei auf IPv6 umsteigen. Es wird nur noch ein paar Jahre dauern, bis die Mehrheit des Internet IPv6 fährt. Kasten: Was ist eigentlich mit IPv5? Es gab nie ein IPv5. Im IP-Header gibt es ein Versionsfeld, das bei IPv4 4 und bei IPv6 6 enthält. Es gab ein experimentelles Protokoll für Echtzeit-Ströme, für das an dieser Stelle eine 5 reserviert wurde. Dieses Protokoll hieß ST-2 und ist von RSVP ersetzt worden. ST-2 sollte Audio- und Videosignale per Multicast übertragen können und die Bandbreiten-Reservierungsvorteile von ATM in IP-Netze bringen. Kasten: IPv6-Adressen. IPv6-Adressen haben 128 Bits und werden als Kette von 16-bit-Zahlen in Hexadezimal-Notation geschrieben, die durch Doppelpunkte getrennt werden. Folgen von Nullen können einmalig durch "::" abgekürzt werden. Beispiel: "::" ist die Adresse, die nur aus Nullen besteht. "::1" ist die Adresse, die aus Nullen und als letztem Bit einer 1 besteht. Das ist die Host Local Adresse von IPv6, äquivalent 127.0.0.1 bei IPv4. "fe80::0211:22FF:FE33:4455" ist eine typische Link Local Adresse, was man an dem Prefix "fe80" erkennt. In URLs kollidiert der Doppelpunkt mit der Portangabe, daher werden IPv6-Nummern in URLs in eckige Klammern gesetzt ("http://[1080::8:800:200C:417A]:80/"). Kasten: IPv6 Bootstrap. ::1 ist die Host Local Adresse (analog "127.0.0.1") Die Link-Local Adresse ist fe80::[EUI-64]. EUI-64 ist eine IEEE-Norm, die eine eindeutige 64-Bit Zahl definiert. Aus der Ethernet-Adresse 00:11:22:33:44:55 folgt z.B. fe80::0211:22FF:FE33:4455 als IPv6-Adresse. IPv6 hat anfänglich die Ethernet-Adresse einfach direkt übernommen aber als IEEE dann EUI-64 spezifizierte, stieg man darauf um, um nicht zu viele überlappende Standards zu haben. Per Neighbor Solicitation fragt der Host nach, ob diese Link Local Adresse bereits vergeben ist. Wenn eine Antwort (Neighbor Advertisement) kommt, schlägt der Standard manuelle Intervention vor. Das kann nur passieren, wenn mehr als ein Rechner die gleiche MAC-Adresse benutzt, und die soll ja dem Ethernet-Standard entsprechend auch eindeutig sein, das darf also eigentlich nicht vorkommen. Mit der Link Local Adresse kann der Host im LAN kommunizieren. Er kann sich also z.B. ein Kernel-Image aus dem Netz holen oder mit Routern sprechen. Der Host sendet Router Solicitation Pakete. Wenn kein Router antwortet, soll der Host DHCPv6 benutzen (das wird aber selten implementiert). Alle Router melden dem Host dann Prefixe mit Lease Timeouts, MTU und Hop Count. Die Idee ist, daß die EUI-64 aus der Link Local Adresse beibehalten wird und einfach als Suffix für alle IP-Adressen dieses Hosts benutzt wird. Netze werden also in Quanten von mindestens 64-Bit vergeben, damit die EUI-64 überhaupt Platz findet. Die Router müssen dem Host unter diesen Umständen also keine IP zuweisen, sondern nur den Prefix für ihr Netz. Der Host konstruiert sich seine IP-Adresse dann selber. Das hat den Vorteil, daß Router sich nicht merken müssen, welche IPs sie bereits vergeben haben und welche nicht. Dieser Prefix kann auch kleiner als 64 Bits sein, in welchem Fall einfach mit Nullen aufgefüllt wird. Es ist besonders beachtenswert, daß alle Prefixe eine Lebensdauer haben! Wenn diese abläuft, dann schmeißt der Host sie weg und fragt erneut mit Router Solicitation nach. So ergibt sich das Renumbering quasi von alleine. Man sagt den Routern einfach, daß sie den Prefix für das alte Netz nicht mehr announcen sollen und gibt ihnen dafür das neue Netz. Es gibt ein Protokoll (Router Renumbering, RFC 2894), mit denen sich Router unternehmensweit ihre Netze propagieren können, d.h. am Ende stellt der Administrator nur noch bei einem Zentralrouter die neue Konfiguration ein und der Rest der Router im weltumspannenden Riesen-Netz passen sich automatisch an. Der Hop Count wird direkt in die Routingtabelle übernommen und dient dazu, Routen zu prioritisieren. Routen mit kleinerem Hop Count werden bevorzugt benutzt. Die anderen kommen erst zum Tragen, wenn alle Routen mit kleinerem Hop Count ausgefallen sind. So implementiert man redundante Netzanbindung. Es ist bemerkenswert, daß die gesamte Prozedur ohne manuelle Intervention oder Konfiguration abläuft. Kasten: Welcher Prefix ist der richtige? Nach dem Bootstrap kennt der Host mehrere IP-Adressen und mehrere Prefixe für sich selber. Wenn er jetzt mit einem anderen Rechner kommunizieren will, woher weiß er dann, welcher Prefix der richtige ist? IPv6 geht wieder davon aus, daß die Intelligenz ruhig im Client sitzen soll, aber das Wissen im Router. Die Router kennen sich mit dem Netz genügend aus, um zu wissen, welcher Router zuständig ist. Der Client versucht es also einfach mit einem beliebigen Prefix. Wenn dieser nicht funktioniert oder nicht optimal ist für diese Gegenstelle, dann schickt der Router per ICMP ein Redirect-Paket an den Host. In diesem Paket steht drin, welcher Router eigentlich zuständig ist, und aus diesem Router folgt dann auch der zu verwendende Prefix. Zur Steigerung der Effizienz hält der Host einen Cache vor, in dem er sich für einige Ziel-IPs merkt, über welchen Router er dort hin kommt. Kasten: Wie sieht ein einfacher IPv6-Client aus? Die Wrapper-APIs sind so einfach zu benutzen, daß es keinen Sinn macht, einen reinen IPv6-Client zu schreiben. Das hier gezeigte Code-Fragment baut auf dem ersten verfügbaren Weg eine HTTP-Verbindung zu www.heise.de auf (das wird wahrscheinlich IPv4 sein), holt sich http://www.heise.de/newsticker/ und gibt das Ergebnis einfach aus. #include #include #include #include #include main() { struct addrinfo *ai; int res; int sockfd; if ((res=getaddrinfo("www.heise.de","http",0,&ai))) { fprintf(stderr,"Kann keine Verbindung aufbauen: %s\n",gai_strerror(res)); return 1; } while (ai) { if ((sockfd=socket(ai->ai_family,ai->ai_socktype,ai->ai_protocol))>=0) { if (!connect(sockfd,ai->ai_addr,ai->ai_addrlen)) { char buf[1024]; FILE *f=fdopen(sockfd,"r+"); fputs("GET /newsticker/ HTTP/1.0\r\nHost: www.heise.de:80\r\n\r\n",f); while (fgets(buf,1000,f)) fputs(buf,stdout); fclose(f); return 0; } else close(sockfd); } ai=ai->ai_next; } } Literaturliste: 1. Internet Engineering Task Force 2. mein Multicast-Artikel 3. mein MPLS-Artikel 4. gab es mal einen QoS-Artikel? 5. ncp: 6. Free S/WAN IPsec beta: http://www.ipv6.iabg.de/download/freeswan-1.8-ipv6-v011.tar.gz 7. Router mit IPv6-Support: http://www.ipv6forum.com/navbar/links/v6routerlist.htm 8. 6BONE: http://www.6bone.net/ TODO: "Dass IPv6 nicht nur anfangs v4 ergänzt und nicht "auf einen Schlag" ablöst. Es muss also niemand nutzen. Da wären ein, zwei ausblickende (Ab)Sätze zur Einführung auch ganz nett." "Eine kurze Beschreibung des Adressformats nach RFC 2373 und die Schilderung einer Beispieladresse wäre nützlich."