IPv6 Universität Kaiserslautern

Transkript

1 IPv6 Universität Kaiserslautern Patrick Koppen September September 2004

2

3 IPv6 Universität Kaiserslautern Patrick Koppen September 2004 AG Integrierte Kommunikationssysteme (ICSY) Fachbereich Informatik Universität Kaiserslautern Betreuer: Prof. Dr. Paul Müller Dipl.-Inform. Claudia Baltes Dipl.-Inform. Bernd Reuther Dipl.-Phys. Brian Worden

4 2

5 Zusammenfassung Im Rahmen dieser Projektarbeit wurde das Netzwerk der Universität Kaiserslautern um das IPv6 Protokoll ergänzt. Dies umfasste sowohl die Beschreibung der Grundlagen, eine Bestandsaufnahmen sowie die Entwicklung von Konzepten für Routing, DNS und Sicherheit. Die Umsetzung dieses Konzeptes enthielt die Konfiguration der Rechner und Router, den Anschluss an das DFN, Erweiterung des DNS- und des Accountingsystems sowie Tests und Benutzerbetreuung. 3

6 4

7 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung 7 2 IPv6 Grundlagen Header Extension Header Adressen Allgemeines Adressformat Aggregierbare globale Unicast Adressen Link- und Site-Local Adressen IPv4 Abbildungen to4 Adressen ISATAP Adressen Anycast Adressen Multicast Adressen Notwendige Adressen ICMPv Fehlermeldungen Informationsmeldungen Automatische Konfiguration Neighbor Discovery Path MTU Discovery DHCPv Routing Protokolle RIPng OSPFv IS-IS BGP DNS Migration Dual-Stack IPv6 über IPv Dedizierte IPv6 Leitungen Zusammenführung von Netzen Multihoming Bestandsaufnahme an der Universität Kaiserslautern Accounting Sicherheit Randbedingungen seitens des RHRK Hardware und Infrastruktur

8 Inhaltsverzeichnis 5 Konzept 39 6 Implementierung Adress- und Sicherheitskonzept Accounting DNS Erweiterung der Infrastruktur Anschluss an das DFN Tests Abschluss der Erprobungsphase Zusammenfassung und Ausblick 51 A Accounting Programm 57 6

9 1 Einleitung Das Rechenzentrum der Universität Kaiserslautern ist seit der Gründung an Innovationen und neuen Technologien im Bereich Netzwerke interessiert. Von den Anfängen der ersten vernetzten Computer bis zum heutigen Internet wurden schon die verschiedensten Techniken eingesetzt. Ausgehend von einem Yellow Cable Backbone entwickelte sich das Netz schnell zu einem FDDI basierten Backbone, dann weiter zu ATM mit LAN-Emulation und schließlich zu einem GigabitEthernet-Backbone. Als Protokolle kamen unter anderem IPv4, IPX, DECNet und Appeltalk zum Einsatz. So lag es nahe, dass auch IPv6 den Nutzern des Netzes der Universität zugänglich gemacht wurde. Im Sommer 2003 wurden die Hardwarevorraussetzungen geschaffen, um erste Schritte in Richtung IPv6 zu unternehmen und Erfahrungen in diesem Bereich zu sammeln. Somit ist das Rechenzentrum vorbereitet, wenn der IPv6 Boom einsetzt. Diese Projektarbeit beschreibt den Aufbau der IPv6 Infrastruktur an der Universität Kaiserslautern. Besonderes Augenmerk wird hierbei auf die nahtlose Integration in das Universitätsnetz, den Parallelbetrieb von IPv4 und IPv6 und das Sicherheitsund Zugangskonzept des Rechenzentrums gelegt. Neben einigen Grundlagen zum Thema IPv6 werden im Detail die Konzeption von IPv6 an der Universität und die Integration in den Bereichen DNS, Accounting, Sicherheit, DHCP und Routing beschrieben. Daneben werden auch die Bereiche Wartbarkeit und Netzwerkpflege sowie Benutzerfreundlichkeit berücksichtigt. Im Rahmen der Projektarbeit wurden die Router und Switches der Universität konfiguriert und das Accountingsystem erweitert. Die Projektarbeit umfasst zusätzlich noch eine kurze Auswertung einer mehrmonatigen Testphase und zeigt auf, welche Schwächen in Konzeption und Implementation entdeckt wurden und an welchen Stellen Überarbeitung notwendig ist. 7

10 8

11 2 IPv6 Grundlagen Das Internetprotokoll wurde Anfang der siebziger Jahre für das ARPANET (Advanced Research Projects Agency) entwickelt. Im Laufe der Zeit ist das Netz immer mehr gewachsen, bis schließlich das heutige Internet entstand. Anfang der neunziger Jahre erkannte man den langsam einsetzenden Mangel an Adressen und die zunehmende Komplexität der Netzwerkstruktur. Zum einen wurde verschwenderisch bei der Adressvergabe umgegangen, zum anderen werden im Internet viele Netze ohne eine hierachische Struktur geroutet, so dass die Tabellen der Internet Backbone Router zunehmend größer wurden. Anfang der neunziger Jahre begann die Internet Engineering Task Force (IETF) mit der Entwicklung eines neuen Protokolls, das dieser Entwicklung Rechnung tragen sollte. Dies war die Geburtsstunde des heutigen IPv6. IPv6 sollte dabei einige wichtige Verbesserungen bringen. Seine Adressen sollten hierachisch sein, um einfach und ressourcenschonenend routen zu können. Es sollte die Adressknappheit lösen, dynamische Konfiguration gerade im mobilen Bereich bieten, den erhöhten Sicherheitsbedürfnissen der Anwender gerecht werden und das Problem von Bandbreitenreservierungen lösen. Bei aller Innovation muss ein weicher Übergang von IPv4 zu IPv6 bzw. die Koexistenz beider Protokolle möglich sein, um dem Anwender die Migration zu erleichtern. Die wichtigsten Änderungen kann man wie folgt beschreiben: Der Adressbereich wurde auf 128 Bit erweitert und Mechanismen zur automatischen Konfiguration wurden vorgesehen. Das Headerformat wurde vereinfacht, um so die Arbeit der Router zu vereinfachen und zu beschleunigen. Zu diesem Zweck besitzt IPv6 einen Header mit einer festen Länge von 40 Bytes, der im Gegensatz zum IPv4-Header nur noch die Quell- und Zieladresse und einige wenige Felder enthält. Um weiterhin optionale Felder im Header zu unterstützen, wurden Erweiterungsheader eingeführt, die optional zwischen dem Header und den Daten eingefügt werden können. So können die Header in Zukunft leicht erweitert werden, ohne die Routingfunktionalität zu beeinflussen. Desweitern wurde ein Flow-Label eingeführt, um zusammengehörige Pakete zu klassifizieren und gesondert zu behandeln. Dies könnte in Zukunft für Multimediaanwendungen genutzt werden. Um das wachsende Sichheitsbedürfnis zu befriedigen, unterstützt IPv6 Mechanismen für Authentifizierung, Datenintegrität und Verschlüsselung der Daten. 9

12 2 IPv6 Grundlagen 2.1 Header Die Header von IPv4 und IPv6 weisen auf den ersten Blick viele Gemeinsamkeiten auf, jedoch wurde der neue IPv6-Header (RFC 2460 [1]) bzgl. der hardwareunterstützten Verarbeitung im Rechner/Router optimiert. Zu diesem Zweck wurden nur die wichtigsten Felder übernommen. Alle optionalen Felder wurden in sogenannte optional Headers ausgelagert. Im eigentlichen IPv6-Header sind nur noch die Felder Version, Traffic Class, Flow Label, Payload Length, Next Header, Hop Limit, Source und Destination Address vorhanden (siehe Abbildung 1). Der Ethernet Typ für IPv6 ist 0x86DD (RFC2464 [9]). Version Traffic Class Flow Label Payload Length 16 Next Header 8 Hop Limit 8 Source Address 128 Destination Address 128 Abbildung 1: IPv6 Header Das Versionsfeld enthält zwingend einen Wert von 6 als Bezeichnung für IPv6. Das Feld Traffic Class ersetzt das Type of Service Feld bzw. das DiffServ Feld von IPv4. Der Einsatz dieses Feldes ist in RFC 2474 [10] beschrieben. Hierbei handelt es sich um Per-Hop-Behavior (PHB), d.h. das Feld wird auf dem Weg zum Ziel von jedem Router angeschaut, ausgewertet und gegebenenfalls sogar verändert. Neu hingegen ist das Flow Label (RFC 3697 [14]). Hierbei handelt es sich um ein Label, das auf dem gesamten Weg unverändert weitergeleitet wird. Ursprünglich wurde in IPv4 ein Flow durch ein 5-Tupel gekennzeichnet. Dieses Tupel besteht aus Quell- und Zieladresse, Quell- und Zielport und Typ des Transportprotokolls. Einige Implementierungen verwenden noch zusätzliche Felder wie z.b. das ToS Feld. Bei IPv6 reicht mit Hilfe des Flow Labels ein 3-Tupel, dessen Werte zusätzlich noch an festen Stellen im Header stehen. Dieses Tupel besteht lediglich aus Quell- und Zieladresse und Flow Label. Insbesondere ist die Erkennung des Flows unabhängig von höheren Protokollschichten. Das Gerät, das eine Verbindung aufbaut, wählt dabei ein für sich eindeutiges Label. Geräte ohne Flow Label Unterstützung müssen den Wert auf Null setzen. Router leiten dieses Feld unverändert weiter, können es aber unter Hinzunahme der Quell- und Zieladresse für Routingentscheidungen zur 10

13 2.2 Extension Header Hilfe nehmen. Im Normalfall verfällt ein Flow, sobald für einen Zeitraum von 120 Sekunden keine Daten gesendet wurden. Weitere Gemeinsamkeiten von IPv4 und IPv6 sind das TTL-Feld, das hier Hop Limit genannt wird und lediglich ein Zähler für die Anzahl der erlaubten Router auf dem Weg enthält. Jeder Router vermindert den Wert des Feldes beim Weiterleiten um eins. Das Feld Payload Length enthält die Länge der Daten nach dem Header. Im Unterschied zu IPv4 wird der IPv6 Header nicht in die Berechnung einbezogen, da er ein feste Größe besitzt. Allerdings werden hier optionale Header mitgezählt. Im Feld Next Header befindet sich ein Verweis auf den Typen des nächsten (optionalen) Headers bzw. der engültigen Payload. Am Ende des IPv6 Headers befinden sich Absender- und Zieladressen. 2.2 Extension Header IPv6 Header Next Header = TCP TCP Header + Data IPv6 Header Next Header = Routing Routing Header Next Header = TCP TCP Header + Data IPv6 Header Next Header = Routing Routing Header Next Header = Fragment Fragment Header Next Header = TCP Fragment of TCP Header + Data Abbildung 2: IPv6 Optional Headers Die optionalen Felder von IPv6 wurden in so genannte Extension Headers (Abb. 2) verlagert, die sich zwischen Header und Layer-4 Payload befinden. Dazu gibt es im Header das Feld Next Header, dessen Wert Aufschluss über den Typ des Extension Headers gibt. Im Extension Header verweist ein solches Feld wiederum auf den nächsten Extension Header, bis schließlich der Typ auf ein Layer-4 Protokoll verweißt. Dieses Feld 11

14 2 IPv6 Grundlagen entspricht dem Protocol Type im IPv4-Header. Neben den schon bekannten Protokolltypen für TCP (6) und UDP (17) wurden noch folgenden Typen für IPv6 Extension Headers definiert: Wert Beschreibung 0 Hop-By-Hop Option Header 43 Routing Header 44 Fragmentation Header 50 Encrypted Security Payload Header 51 Authentication Header 58 ICMPv6 60 Destination Options Header Tabelle 1: Werte im Next Header Feld Die Reihenfolge der Extension Headers ist in RFC 2460 [1] vorgegeben. Im allgemeinen kann man sagen, dass routingspezifische Optionen vor hostspezifischen Optionen stehen. 2.3 Adressen Bei der Entwicklung von IPv6 hat man beim Gestalten der Adressen (RFC 3513 [3]) ein Augenmerk auf die Hierachie und die benötigten Funktionen gelegt. So gibt es wie bei IPv4 Unicast- und Multicastadressen, wobei die Multicastfähigkeit grundlegend für die Funktionalität von IPv6 geworden ist. Der große Adressraum von 128 Bit lässt zudem noch einen hierachiechen Aufbau zu. Man spricht hier im Gegensatz zu den Netzen bei IPv4 von Prefixen, die ein klassisches Netz beschreiben. Die so entstehenden Netze sind geographisch und/oder logistisch hierachisch geordnet und können sich so zum Teil nicht mehr frei an jeder Stelle des Internets befinden. Bestimmte Prefixe wurden dabei für spezielle Aufgaben reserviert. Weiterhin wurde wie im Folgenden gezeigt wird, die Möglichkeit zur Abbildung alter IPv4-Adressen und sogar von MAC-Adressen in IPv6-Adressen geschaffen, um eine Migration bzw. Autokonfiguration zu erleichtern. Zusätzlich wurde ein in der IP-Welt bisher nahezu unbekannter Typ von Adressen, die sogenannten Anycastadressen (RFC 1546 [22]), eingeführt. Auf Broadcastadressen wurde wurde verzichtet Allgemeines Adressformat Der auffälligste Unterschied zwischen IPv4 und IPv6 Adressen (Abb. 3) ist die neue hexadezimale Schreibweise. Um trotz 128 Bit nicht den Überblick zu verlieren, werden IPv6 Adressen ähnlich wie IPv4 Adressen in einzelne Zahlen unterteilt, die hier 12

15 2.3 Adressen Global routing prefix length = n bits Subnet ID m bits Interface ID 128 n m bits Abbildung 3: Allgemeines Adressformat jedoch durch einen Doppelpunkt getrennt werden. Dabei wird nach jedem 16. Bit ein Doppelpunkt eingefügt. Die Adresse wird außerdem in drei Teile unterteilt: den Routingprefix, die Subnet ID und die Interface ID. Der Globale Routingprefix dient zur Lokalisierung der Organisation, der die Adresse zugeteilt wurde. Die Subnet ID beschreibt ein lokales Netz innerhalb der Organisationseinheit und die Interface ID beschreibt das Interface eines Rechners. Sie muss in einem Subnet eindeutig sein. Ein Beispiel für eine Adresse ist: FE80:0000:0000:0000:0201:33FF:FE22:0001 Zur Vereinfachung können bei IPv6 Adressen in jedem Block führende Nullen weglassen werden. Genau ein Mal pro Adresse ist es erlaubt, aufeinanderfolgende Blöcke von Nullen durch zwei Doppelpunkte zu ersetzen. Für das obige Beispiel ergibt sich dann: FE80::201:33FF:FE22:1 Die Schreibweise von IP-Adresse und Netzwerkmaske wurde bei IPv6 vollständig durch die Prefix-Notation ersetzt (RFC 3513 [3]). Sie entspricht der Classless Interdomain Routing (CIDR) Notation von IPv4. Die Länge des Prefixes in Bits wird mit einem Schrägstrich an die IPv6-Adresse angehängt. In diesem Beispiel eine Prefixlänge von 10 Bits: FE80::/10 Weiterhin werden in RFC 3513 [3] bestimmte Prefixe und deren Bedeutung definiert. Die folgende Tabelle gibt einen Auszug aus diesen Definitionen: Die unspezifizierte Adresse, die Loopback Adresse und spezielle Adressen, die IPv4 Adressen enthalten, wurden aus dem Pool mit dem Prefix genommen. 13

16 2 IPv6 Grundlagen Verwendungszweck Binary Prefix Hex Prefix Reserved ::0/128 Reserved for NSAP Allocation ::/7 Reserved for IPX Allocation ::/7 Aggregatable Global Unicast Addresses ::/3 Link-Local Unicast Addresses FE80::/10 Site-local Unicast Addresses FEC0::/10 Multicast Addresses FF00::/8 Abbildung 4: Liste zugewiesener Prefixe Aggregierbare globale Unicast Adressen Aggregierbare globale Unicast Adressen werden in RFC 3587 [2] definiert. Die Adresse wird in einen öffentlichen, einen lokalen und einen Interfacebereich aufgeteilt. Der öffentliche Teil, der sogenannte globale Routingprefix, dient dazu einzelne Organisationen zu beschreiben. Innerhalb einer Organisation wird der Subnet Identifier dazu benutzt um das Netz zu strukturieren. Auf dem lokalen Link dient dann der Interface Identifier um die einzelnen Netzwerkkomponenten voneinander zu unterscheiden. Für den Prefix gibt es jedoch einige Einschränkungen. Zum einen beginnen alle zur Zeit vergebenen Prefixe mit binär 001 bzw. mit hex 2 oder hex 3, zum anderen muss der Interface Identifier bei diesen Prefixen eine Länge von 64 Bits haben und nach dem modifizierten EUI-64 Format (siehe Abbildung 13 auf Seite 22) erzeugt werden. Bei Adressen, die nicht mit 001 beginnen, gilt die Längenbeschränkung nicht. Außerdem gibt RFC 3177 [15] einige Richtlinien, wie Prefixe von Providern vergeben werden sollen. Grundsätzlich soll immer ein /48 Prefix vergeben werden, außer wenn es sich um sehr große Teilnehmer handelt. Ein /64 Prefix soll nur vergeben werden, wenn nur genau ein Subnetz benötigt wird und ein /128 Prefix wenn nur genau ein Rechner angeschlossen ist. Die Empfehlungen gehen sogar so weit, dass jedem Heimanwender ein eigener /48 Prefix gegeben werden soll. Die Prefixlänge 48 wurde gewählt, weil viele spezielle Adressen, die in den folgenden Abschnitten beschrieben werden, einen 48-Bit Prefix besitzen Link- und Site-Local Adressen Link- und Site-Local Adressen (Abb. 5) haben, wie der Name schon sagt, einen eingeschränkten Gültigkeitsbereich und sind nur innerhalb eines Links bzw. innerhalb einer Organisation gültig. Die Site-Local Adressen sind am ehesten mit den private Adressen (RFC1918 [23]) von IPv4 zu vergleichen. Link-Local Adressen wurden eingeführt, um auf Linkebene Autokonfiguration und 14

17 2.3 Adressen HEX: FEC Subnet ID HEX: FE Interface ID 10 bits 38 bits 16 bits 64 bits Site Local Adressen 0 Interface ID 10 bits 54 bits 64 bits Link Local Adressen Abbildung 5: Site- und Link-Local Adressen Neighbor Discovery durchzuführen. Damit können zwei Rechner direkt miteinander kommunizieren, ohne dass ein Router oder manuelle Konfiguration notwendig sind. Es ist möglich zwei Rechner mit einem Crosskabel zu verbinden und sie über Link- Local Adressen gegenseitig anzusprechen. Routern ist es verboten, Pakete mit einer Link-Local Absender- oder Zieladresse weiterzuleiten. Site-Local Adressen können zum Routen innerhalb einer Organisation genutzt werden, wenn man keinen globalen Prefix hat oder ihn nicht nutzen möchte. Router dürfen Pakete zu diesen Adressen nicht über Organisationsgrenzen hinwegleiten. An den Grenzen zu anderen Netzen wäre dann eine Umsetzung in globale Adressen notwendig. An dieser Stelle wird der Grund für die Empfehlung an Kunden /48 Prefixe zu vergeben deutlich. Auch Site-Local Adressen haben einen 48-Bit Prefix. Somit ist es möglich, den Site-Local Prefix durch einen globalen Routing Prefix auszutauschen, falls eine Organisation erst nachträglich an das Internet angeschlossen wird IPv4 Abbildungen Um den langwierigen Migrationsprozess von IPv4 zu IPv6 zu unterstützen, wurden zwei spezielle Adresstypen (Abb. 6) eingeführt (RFC 3513 [3]). Dies sind zum einen die IPv4-compatible IPv6 addresses, die es Routern ermöglichen, dynamisch IPv6 Pakete über IPv4 Infrastukturen zu routen. Die IPv6 Adresse besteht dabei aus einem 80 Bit Null-Prefix, 16 Bit Nullen und 32 Bit IPv4 Adresse. Zum anderen gibt es die IPv4-mapped IPv6 addresses, die genutzt werden um Rechner, die nur IPv4 unterstützen, an IPv6 Netze anzuschließen. Diese Adressen unterscheiden sich von den kompatiblen Adressen, indem 16 Bit Einsen an Stelle der Nullen benutzt werden. 15

18 2 IPv6 Grundlagen bits bits IPv4 address 32 bits IPv4 compatible IPv6 address bits FFFF IPv4 address 16 bits 32 bits IPv4 mapped IPv6 address Abbildung 6: IPv6 Adressen mit eingebetteten IPv4 Adressen to4 Adressen 6to4 Adressen (RFC 3056 [5]) bieten eine Migrationsmöglichkeit, zwei IPv6 Netze über ein IPv4 Netz (z.b. das Internet) ohne einen expliziten Tunnel zu verbinden. Hierzu wurde ein spezieller /48 Prefix (Abb. 7) geschaffen, an dem Router beim Übergang von IPv6 zu IPv4 merken, dass sie eine Umsetzung machen sollen. Der Prefix besteht aus 0x2002 (FP und TLA) und der IPv4 Adresse (V4ADDR) des Routers. Erreicht solch ein Paket den für die Umsetzung zuständigen Router, extrahiert dieser die IPv4 Adresse seines Gegenübers aus der IPv6 Zieladresse und schickt das Paket an diese Adresse. So wird zum Beispiel aus der Routeradresse der Prefix 2002:c0a8:6301::/ x0002 FP TLA V4ADDR SLA ID 3 13 bits 32 bits 16 bits Interface ID 64 bits Abbildung 7: 6to4 Adressen Der Site-Level Aggregation Identifier (SLA) wird benutzt um innerhalb einer Organisation eine hierachische Adressstruktur aufzubauen und um einzelne Subnetze zu beschreiben ISATAP Adressen Intra-Site Automatic Tunnel Addressing Protocol (DRAFT-ISATAP [16]) ist ein automatischer Tunnelmechanismus, bei dem einem Client ähnlich wie bei DHCP dynamisch eine IPv6-Adresse zugewiesen wird. Hierbei wird ein Router als Tunnelendpunkt mit einem /64 Prefix (Abb. 8) konfiguriert. Der Client verbindet sich über 16

19 2.3 Adressen ein IPv4-Netzwerk zum Router, der dem Client wiederum den Prefix mitteilt. So ist auf Clientseite lediglich die eigene IPv4-Adresse und die des Routers zu konfigurieren. Die IPv6 Adresse des Clients wird danach aus dem Prefix, einem festen Teil (0000:5EFE) und der IPv4 Adresse des Clients gebildet. Im folgenden ein Beispiel um dies zu verdeutlichen: Prefix E FE Interface ID 64 bits 32 bits 32 bits Abbildung 8: ISATAP Adressen Ein Client hat die IPv4 Adresse und der Router benutzt für ISA- TAP den Prefix FEC0:0815::/64. Daraus wird nach Aufbau des Tunnels eine Client IPv6 Adresse von FEC0:0815::0000:5EFE: An dieser Stelle ist die Mischung aus hexadezimaler und dezimaler Schreibweise erlaubt Anycast Adressen Anycast Adressen (RFC 3513 [3]) dienen dazu, einen Dienst von mehreren Servern unter der gleichen Adresse zur Verfügung zu stellen. Dabei werden Anfragen für diese Adresse zu dem nächsten Servern weitergeleitet, welcher durch das Routingprotokoll bestimmt wird. Da Anycast Adressen (Abb. 9) aus demselben Bereich wie Unicast Adressen stammen, sind sie von diesen nicht zu unterscheiden. Routern muss deswegen explizit mitgeteilt werden, dass es sich bei Adresse auf ihrem Interface um eine Anycast Adresse handelt. Im Routingprotokoll tauchen diese Adressen als Host-Routen auf. Eine spezielle Anycast Adresse ist die Subnet-Router Anycast Adresse, die immer vorhanden sein muss. Subnet Prefix length = n bits length = 128 n bit Abbildung 9: Subnet Router Anycast Adresse Sie besteht aus der Unicast Adresse des Interfaces eines Routers, bei der der Interface Identifier auf Null gesetzt wurde. Diese Adresse muss von Routern unterstützt werden und kann von Rechnern benutzt werden um mit einem der verfügbaren Router zu kommunizieren. 17

20 2 IPv6 Grundlagen Subnet Prefix 64 bits Anycast ID 57 bits 7 bits Interface identifier in EUI 64 format Subnet Prefix n bits n bits Anycast ID 7 bits Abbildung 10: Anycast Adresse Other interface identifier formats Um dem Mangel an Erfahrungen mit Anycast Adressen Rechnung zu tragen, wurden im gleichen RFC einige Einschränkungen beschrieben, an die man sich, bis mehr Erfahrungen gesammelt wurden, halten soll. Zum einen darf eine Anycast Adresse nicht als Absender in einem Paket stehen und zum anderen dürfen Anycast Adressen nur an Router, nicht aber an einzelne Rechner vergeben werden. RFC 2526 [4] beschreibt den generellen Aufbau der Anycast Adressen, die aus einem Prefix, einer Reihe von Einsen und einer 7-Bit Anycast ID besteht. Hierbei muss zwischen /64 Prefixen mit Interface Identifier im EUI-64 Format und anderen Prefixen unterschieden werden. Bei einem /64 Prefix muss im Interface Identifier das Universial/Local Bit auf 0 gesetzt werden Multicast Adressen Multicast Adressen (RFC 3513 [3]) werden benutzt, um mehr als einen Rechner anzusprechen. Sie sind in IPv4 schon seit längerem gebräuchlich, haben aber in IPv6 eine zentrale Bedeutung. Im Gegensatz zu IPv4 sind sie hier nicht mehr optional sondern für jeden Teilnehmer zwingend vorgeschrieben. So wurde die Nachbarfindung mittels ARP durch eine Multicastlösung ersetzt. Multicast Adressen haben bei IPv6 den reservierten Prefix FF00::/8. Das zweite Byte enthält zum einen Flags über die Art der Adresse und zum anderen einen Scope-Wert der Aufschluss über die Reichweite der Adresse gibt. Bei den Flags sind zur Zeit die ersten drei Bits reserviert und müssen mit 0 initialisiert werden. Das 4. Bit, das sogenannte T-Bit, gibt an, ob es sich bei der Adresse um eine permanent vergebene Adresse ( well-known, T=0) oder eine nicht permanent vergebene Adresse ( transient, T=1) handelt. Der Scope-Wert gibt die gewünschte Reichweite der Pakete an. In dem RFC sind 18

21 2.3 Adressen T flgs scop 8 bits 4 bits 4 bits group id 112 bits Abbildung 11: Multicast Adresse die möglichen Bedeutungen dieses Wertes definiert. Gebräuchlich sind die Werte für alle direkt angeschlossenen Geräte (link-local) und alle Geräte innerhalb der Organisation (site-local). Wert Typ 1 interface-local scope 2 link-local scope 4 admin-local scope 5 site-local scope 8 organization-local scope E global scope Rest reserved/unassigned Tabelle 2: Multicast Scope Beispiele für Multicast Adressen sind die All Nodes Addresses mit den Adressen FF01::1 (Interface-Local) und FF02::1 (link-local) und die All Routers Addresses mit den Adressen FF01::2 (Interface-Local), FF02::2 (Link-Local) und FF05::2 (Site-Local). Interface-Local Daten bleiben auf dem jeweiligen Gerät, Link-Local Daten erreichen Geräte an dem gleichen logischen Segment und Site-Local steht für eine Organisationseinheit. Eine weitere notwendige Adresse ist die Solicited-Node Multicast Adresse. Diese Adressen werden aus der Unicast und Anycast Adresse berechnet, in dem man die letzten 24 Bit der jeweiligen Adresse an den Prefix FF02:0:0:0:0:1:FF00::/104 hängt. Ein Rechner muss Mitglied der daraus resultierenden Gruppe werden Notwendige Adressen Jeder IPv6 Teilnehmer muss bestimmte Adressen unterstützen bzw. auf diese Antworten, um erfolgreich am Netzwerkgeschehen teilzunehmen. Ein Rechner muss folgende Adressen kennen: eine Link-Local Adresse für jedes Interface 19

22 2 IPv6 Grundlagen eine Unicast oder Anycast Adresse für jedes Interface die Loopbackadresse die All-Nodes Multicastadresse die Solicited-Node Multicast Adresse für jede Unicast und Anycast Adresse die Multicast Adressen für alle Gruppen, zu denen der Rechner gehört Ein Router muss zusätzlich folgende Adressen kennen: die Subnet-Router Anycast Adresse für alle Interfaces, die am Routing teilnehmen alle Anycast Adressen, die für diesen Router konfiguriert wurden die All-Routers Multicast Adresse 2.4 ICMPv6 Das von IPv4 bekannte Internet Control Message Protocol (ICMP) wurde bei der Entwicklung von IPv6 erweitert und an die neuen Bedürfnisse angepasst (RFC 2463 [8]). Es dient wie bei IPv4 zur Übermittlung von Status- und Fehlermeldungen sowie zur Netzwerkdiagnose (ping). Als Erweiterung wurden unter anderem das Internet Group Management Protocol (IGMP) in ICMPv6 aufgenommen. Außerdem wurde das Address Resolution Protocol (ARP), mit dessen Hilfe IP Adressen auf Layer2 Adressen abgebildet werden, durch Neighbor Discovery (ND) ersetzt und in ICMPv6 integriert. Ein ICMPv6 Header (Abb. 12) besteht aus einem Typenfeld, einem Codefeld, einer Checksumme und dem sogenannten Messagebody und befindet sich hinter dem IPv6 Header bzw. hinter einem oder mehreren Extension Headern. Der Next-Header Wert für ICMPv6 ist 58. Type Code Checksum 8 bits 8 bits 8 bits Message Body variabel Abbildung 12: ICMPv6 Header Format 20

23 2.4 ICMPv6 Der Inhalt des Message Bodys ist abhängig von Typ und Code. Das Gesamtpaket sollte aber die garantierte MTU von 1280 Bytes nicht überschreiten. ICMPv6 Meldungen kann man in zwei Klassen unterteilen. Die erste Klasse umfasst die Fehlermeldungen, die zweite Klasse enthält Informationsmeldungen Fehlermeldungen Fehlermeldungen haben einen Typ von Sie dienen dazu, Fehler bei der Übertragung zu signalieren, und müssen von jedem Gerät unterstützt werden. Die in RFC 2463 definierten Fehlermeldungen sind Destination Unreachable (1), Packet Too Big (2), Time Exceeded (3) und Parameter Problem (4). Jeder Typ hat einen oder mehrere Codes, um das Problem näher zu spezifizieren. Destination Unreachable und Time Exceeded funktionieren ähnlich wie bei IPv4 und kennen Codes für die Unerreichbarkeit von Rechnern, Ports und Zieladressen. Neu ist Packet Too Big, was bei der MTU Path Discovery verwendet wird, und Parameter Problem, was auf einen Fehler in den IPv6 Headern hindeutet Informationsmeldungen Informationsmeldungen haben einen Typ von In RFC 2463 werden die Typen Echo Request (128) und Echo Reply (129) definiert. Weitere Typen umfassen die Nachbar- und Routererkennung, Teilnahme an Multicastgruppen und Typen zur Unterstützung von Mobile IP Automatische Konfiguration Ein viel gepriesener Vorteil von IPv6 ist die automatische Konfiguration der Endgeräte. Der Adminstrator muss lediglich auf dem Router einen Prefix definieren und sowohl Router als auch Endgeräte ermitteln selbstständig ihre globalen IPv6 Adresse. In RFC 2462 [7] wird dieser Mechanismus unter dem Begriff Stateless Address Autoconfiguration beschrieben. Zuerst einmal muss zwischen stateful und stateless Autokonfiguration unterschieden werden. Bei stateful Autokonfiguration bekommt der Rechner seine Adresse von einem Server (z.b. DHCP), der eine Datenbank von allen vergebenen Adressen besitzt und so unter anderem eine doppelte Vergabe von Adressen verhindert. Der Server hat die Kontrolle über die Adressen und jedem Rechner lässt sich, wenn gewünscht, eine bestimmte feste Adresse zuweisen. 21

24 2 IPv6 Grundlagen IPv6 verfolgt mit der stateless Konfiguration einen etwas anderen Ansatz. Wenn es nicht notwendig ist, dass jedem Rechner eine bestimmte Adresse (auch aus einem definiertem Pool) zugewiesen wird, reicht die stateless Konfiguration aus. Bei diesem Ansatz wählt jeder Rechner eine eindeutige, routebare Adresse. Lediglich das Netzwerk wird vom Router vorgegeben. Es ist weiterhin möglich beide Ansätze zu kombinieren um die Adresse stateless zu erhalten, aber Parameter wie den DNS-Server stateful von einem zentralen DHCP- Server zu bekommen. Die Gültigkeitsdauer einer per stateless Konfiguration gewählten Adresse ist wie beim stateful Ansatz einstellbar. Sie wird nur für einen gewissen Zeitraum gewährt und muss regelmässig erneuert werden. Neu bei IPv6 ist jedoch, dass ein Interface zur selben Zeit mehr als eine Adresse haben kann. Normalerweise wird ein Adressraum bevorzugt (preferred). Man kann jedoch einen Adressraum als deprecated markieren und gleichzeitig einen neuen, bevorzugten Adressraum wählen. In diesem Fall können beide Adressen von einem Rechner benutzt werden, die deprecated Adresse soll jedoch bei neuen Verbindungen vermieden werden. Somit ist eine Neuaddressierung eines Netzes ohne Zutun des Endanwenders zur Laufzeit möglich. MAC 00:00:0c:11:22:33 EUI :0cff:fe11:2233 universial/local Bit invertiert Abbildung 13: EUI64 Wenn es sich bei dem zu konfigurierenden Gerät um einen Router handelt, reicht es auf einem Interface statt der vollständigen Adresse lediglich den Prefix zu konfigurieren. Der Router bildet dann aus dem Prefix und der MAC Adresse des Interfaces eine Adresse nach dem modifizierten EUI-64 Format. Der 64-Bit Extended Unique Identifier (EUI-64) wird zusammengesetzt aus dem 24-Bit Organizationally Unique Identifier (OUI) und dem 40-bit Extension Identifier. Für den Einsatz bei IPv6 wird dieser Identifier leicht modifiziert indem das universal/local Bit der MAC-Adresse invertiert wird. Bei Interfaces, die nicht über einen EUI-64 Identifier verfügen, wie zum Beispiel IEEE 48bit MAC Identifier, wird dieser aus den verfügbaren Daten generiert. Im Fall des 48bit MAC Identifier erfolgt die Berechnung des EUI-64 Wertes durch Aneinanderhängen von OUI, dem Wert 0xFFFE und dem Extension Identifier, wobei 22

25 2.4 ICMPv6 das universal/local Bit invertiert wird. Aus einem Interface mit der MAC Adresse 00:00:0c:11:22:33 wird ein Interface Identifier 0200:0cff:fe11:2233 (Abb. 13). Bei anderen Interfacetypen werden andere Werte zur Berechnung genommen. Bei Interfaces ohne eigene Adresse kann dabei auch auf manuelle Konfiguration, die Seriennummer oder andere gerätespezifische Werte zurückgegriffen werden. Die automatische Konfiguration von Endgeräten verläuft ähnlich, wenngleich der Administrator hier nicht den Prefix konfigurieren muss. Stattdessen werden spezielle ICMPv6 Pakete verschickt, um den Prefix zu erfahren. Um dies zu ermöglichen, wird zuerst eine Link-Local Adresse nach dem modifizierten EUI-64 Format mit dem Prefix FE80::/16 gebildet und dem Interface zugewiesen. Über den Mechanismus der Neighbor Discovery verifiziert der Rechner die Eindeutigkeit der Adresse auf dem Link. Sollte eine doppelte Adresse erkannt werden, ist eine manuelle oder nicht näher spezifizierte automatische Konfiguration notwendig. Das Endgerät kann nun über die Link-Local Adresse mit anderen lokalen Geräten kommunizieren. Um eine globale IPv6 Adresse zu erlangen, hört das Endgerät auf Router Advertisements, die von Routern periodisch verschickt werden. Alternativ kann das Endgerät ein oder mehrere Router Solicitations an die ALL-ROUTERS Multicast Gruppe schicken. Diese werden dann mit Router Advertisements beantwortet. Router Advertisements enthalten Angaben, ob das Endgerät eine stateful oder stateless Autokonfiguration durchführen soll oder ob das Endgerät seine Adresse stateless beziehen, aber weitere Konfigurationsdaten stateful anfragen soll. Neben diesen Daten enhalten die Router Advertisements auch einen oder mehrere bevorzugte (preferred) und abgelaufe (deprecated) Prefixe. Das Endgerät bildet mit diesem Prefix und seinem modifizieren EUI-64 Identifier eine globale IPv6 Adresse Neighbor Discovery Neighbor Discovery (RFC 2461 [6]) wurde in IPv6 implementiert, um eine Reihe von Funktionen, die bei IPv4 auf verschiede Protokolle aufgeteilt sind, zusammenzufassen. Geräte bestimmen mit Hilfe der Neighbor Discovery, welche anderen Geräte sich am gleichen Link befinden und welche von ihnen Router sind. Für die Neighbor Discovery werden ICMPv6 Pakete verwendet mit Typen größer als 128. Neighbor Discovery (Abb. 14) definiert Funktionen und Mechanismen, mit denen sich Geräte, die sich einen gemeinsamen Link teilen, finden und Daten zur Initialisierung austauschen: Router Discovery: Endgeräte ermitteln Router 23

26 2 IPv6 Grundlagen Router Advertisement (type=135, prefix, default route,...) Neighbor Solicitation Neighbor Advertisement Abbildung 14: IPv6 Neighbor Discovery Prefix Discovery: Endgeräte ermitteln, welche Prefixe auf dem direkt angeschlossenen Link vorhanden sind (Routingendscheidung und Autokonfiguration) Parameter Discovery: Parameter wie MTU und HOP-Limit Address Autoconfiguration: automatische Konfiguration von Adressen und anderen Parametern Address Resolution: Abbildung von IPv6 Adresse zu MAC Adresse (an Stelle von ARP bei IPv4) Next-hop Determination: Algorithmus zur Ermittlung der Next-Hop Adresse für IP-Adressen (auch Defaultroute) Neighbor Unreachability Detection: Geräte können mit dieser Methode feststellen, ob ein Gerät nicht mehr erreichbar ist. Im Falle von Routern kann danach ein alternativer Weg gesucht werden. Duplicate Address Detection: Nachdem ein Gerät eine eigene Adresse ermittelt, muss mittels DAD überprüft werden, ob sie eindeutig ist. Redirect: Router können mittels Redirects einem Gerät mitteilen, dass ein besserer Next-Hop für ein bestimmtes Ziel existiert Path MTU Discovery Wenn ein Rechner große Mengen an Daten verschicken möchte, sollte er das in möglichst großen Paketen tun. Sollten diese Pakete größer als die MTU sein, können Router in IPv4 das Fragmentieren der einzelnen Pakete übernehmen. Um die optimale Größe zu ermitteln, so dass unnötiger Overhead durch Fragmentierung oder zu kleine Pakete vermieden wird, gab es bei IPv4 die Möglichkeit der Path MTU Discovery nach RFC 1191 [21]. Dabei wird bei den Paketen das Don t Fragment (DF) 24

27 2.5 DHCPv6 Bit gesetzt und auf eine Datagram Too Big Nachricht gewartet. IPv6 verwendet ein ähnliches Verfahren zur Path MTU Discovery (RFC 1981 [13]). Jedoch ist es bei IPv6 quasi Pflicht. Der Grund dafür liegt an einer wichtigen Einschränkung von IPv6. Router können keine Pakete fragmentieren, wodurch die Weiterleitung erheblich erleichtert wird. Zuständig für die Fragmentierung sind bei IPv6 die Endgeräte. Aus diesem Grund sollten sie MTU Path Discovery durchführen, um die optimale Paketgröße zu ermitteln. Sollte ein Gerät dieses Verfahren nicht unterstützen, kann es sich nur auf die bei IPv6 garantierte minimale MTU von 1280 Bytes verlassen. IPv6 setzt voraus, dass jeder Link eine MTU von 1280 Bytes oder größer besitzt. Bei Verbindungen, die dies nicht bieten, muss ein Protokoll unterhalb von IPv6 die Fragmentierung vornehmen. 2.5 DHCPv6 DHCPv6 wurde erst relativ spät in RFC 3315 [24] definiert. DHCPv6 ist ein Client/Server Protokoll, mit dem Geräte konfiguriert werden können. Das Protokoll wird sowohl zur Adresskonfiguration als auch zur Konfiguration einzelner Parameter wie DNS oder NTP genutzt. Trotz einiger Gemeinsamkeiten ist DHCPv6 nicht abwärtskompatibel zu DHCPv4. Clients und Server tauschen Daten wie bei DHCPv4 über UDP aus. Clients erwarten Nachrichten auf Port 546. Server und Relay Agents hören auf Port 547. Das verwendete Protokoll ist stateful. Clients können per DHCPv6 eine oder mehrere IP-Adressen von einem oder mehreren zentralen Servern beziehen. Im lokalen Netz verwenden die Clients dazu die Multicastadresse All DHCP Relay Agents and Servers FF02::1:2, um die verfügbaren Server zu ermitteln. Als Absenderadresse wird die zu der Zeit einzige bekannte Adresse, die Link-Local Adresse, benutzt. In späteren Anfragen wird dann die erhaltene globale Adresse benutzt. Sollte sich ein Server nicht innerhalb der Reichweite der Local-Link Multicast Adresse befinden, kann ein Router, in dem Fall Relay Agent genannt, die Nachricht entgegennehmen und sie an die Adresse All DHCP Servers weiterleiten. Hat der Client bereits eine Adresse über ICMPv6 bekommen, kann er den DHCP Server nach weiteren für ihn zum Betrieb notwendigen Parameter wie DNS Server oder NTP Server, fragen. Diese Anfragen müssen in Gruppen unterteilen werden. Bei Anfragen nach Parametern, reichen zwei Nachrichten zur Übertragung (Information-Request, Reply). Sollte der Client jedoch eine Adresse anfragen, so sind vier Nachrichten (Solicit, Advertise, Request, Reply) notwendig. DHCPv6 wurde im Vergleich zu DHCPv4 um einige wichtige Funktionen erweitert. Server können Clients bitten, eine neue Adresse zu beantragen. Somit ist eine Um- 25

28 2 IPv6 Grundlagen adressierung ganzer Netze in kurzer Zeit möglich, ohne vorher die Gültigkeitsdauer der Adressen zu verändern. Clients können die angeforderte Adresse ablehnen, wenn sie die zugewiesene Adresse mittels ICMPv6 als schon vergeben erkennen. Eine für ISPs gedachte neue Funktion ermöglicht es dem Client-Router, einen oder mehrere Prefixe bei der dynamischen Einwahl zu beantragen (RFC 3633 [25]). Der Einwahlrouter kann diese vorher dem Kunden zugeordneten Prefixe somit bei der Einwahl dynamisch routen. Ob DHCPv6 oder stateless Autokonfiguration zur Adressvergabe benutzt wird, hängt von den lokalen Gegebenheiten ab. Ein Beispiel ist das Zusammenspiel von DHCP und DNS im Fall, dass DNS-Einträge für alle Geräte erforderlich sind. Bei der Verwendung von DHCPv6 kann der Server entweder statische Einträge verwenden oder sie dynamisch an den DNS Server übermitteln. Bei stateless Autokonfiguration müsste jedem Client gestattet werden, seinen eigenen Eintrag beim DNS Server zu verwalten. 2.6 Routing Protokolle Routingprotokolle (Abb. 15) für IPv6 muss man wie bei IPv4 in zwei Gruppen unterteilen; in Interior Gateway Protocols (IGP) innerhalb eines autonomen Systems und in Exterior Gateway Protocols (EGP) zum Austausch zwischen autonomen Systemen (AS). Die Art und Weise, wie bei IPv6 der Weg ermittelt wird, hat sich nicht geändert. Es wird immer noch der Longest-prefix Match Routing Algorithm verwendet. Auch die Anforderungen an die Routingprotokolle haben sich nicht geändert. BGP+ RIPng OSPF I/IS IS RIPng OSPF I/IS IS Abbildung 15: IPv6 Routing Protokolle RIPng RIPng (RFC 2080 [34] ist eine Weiterentwicklung von RIP-2 und basiert auf den von IPv4 bekannten Techniken. Es ist ein Distance Vector Protokoll mit einem 26

29 2.6 Routing Protokolle Radius von 15 Hops. Zur Entscheidungsfindung wird die Anzahl der Hops zum Ziel genommen. Sonstige Funktionen wie Split Horizon und Poison Reverse werden weiterhin genutzt. Für IPv6 wurden lediglich Felder für IPv6 Prefix und IPv6 Next Hop definiert. Zur Verbreitung von Updates wird die All Rip Routers Multicast Gruppe (FF02::9) verwendet. Weiterhin wurde der Port von 520 auf 521 geändert OSPFv3 OSPF für IPv6 (RFC 2740 [35]) ist ein Link-State Protokoll. Es benutzt die gleichen Mechanismen wie OSPF für IPv4, wurde aber intern überarbeitet. So wurden alle IPv4 spezifischen Dinge entfernt. In IPv6 arbeitet OSPF Link orientiert und nicht mehr Subnet bezogen, damit sich Router, die nicht im selben IP-Netz, aber am gleichen Link befinden, trotzdem miteinander unterhalten können. Weiterhin wurden sämtliche semantischen Bedeutungen für Adressen aus den OSPF Paketen in den Datenteil verlagert. So erhält man einen vom Netzwerkprotokoll unabhängigen Kern. Die Router-ID wird zwar immer noch als 32-Bit Zahl angegeben, ist jedoch in ihrer Bedeutung keine IP-Adresse mehr. Die Reichweite der einzelnen Updates (Flooding Scope) wurde vereinheitlicht. Es gibt nur noch die Typen Link-local Scope, Area Scope und AS Scope. OSPF unterstützt mit diesen Neuerungen explizit die Möglichkeit, mehrere Instanzen auf einem Link zu haben. Ein Link kann somit zu zwei Areas gehören. Weitere Änderungen umfassen die einzelnen Paketformate und den Umgang mit bestimmten LSAs IS-IS ISIS (RFC 1142 [36] / ISO 10589) ist ein OSI Routingprotokoll für CLNS (Connectionless Network Services, ISO 8473). RFC 1195 [37] fügte die Erweiterungen für IP hinzu, die unter dem Namen Integrated IS-IS bekannt wurden. I/IS-IS gehört zur Familie der Interior Gateway Protokolle und ist ein Link-State Protokoll, das ähnlich aufgebaut ist wie OSPF. Es ist ein hierachisches Protokoll mit zwei Ebenen, das für alle unterstützten Protokolle in jeder Ebene den gleichen Shortest Path First Alghorithmus verwendet. Dies muss beim Netzwerkdesign berücksichtig werden. Durch die Verwendung von Type Length Value (TLV) Optionen ist es leicht erweiterbar. Draft draft-ietf-isis-ipv6-05 [33] definiert die Erweiterungen für IPv6. Es wurden zwei TLVs hinzugefügt: IPv6 Reachability TLV (0xEC oder 236) und IPv6 In- 27

30 2 IPv6 Grundlagen terface Address TLV (0xE8 oder 232). Der Protokoll Identifier hat einen NLPID Wert von 0x8E oder BGP4+ Das Exterior Gateway Protokoll BGP wurde durch Multiprotokoll Erweiterungen auf den Transport von Routinginformationen für mehrere Protokolle vorbereitet. RFC 2545 [38] beschreibt die Erweiterungen für IPv6. Diese neuen Attribute definieren die Network Layer Reachability Information (NLRI) und einen NEXT HOP, bei dem IPv6 Adressen benutzt werden. Als Transportmedium kann bei den von BGP verwendeten TCP-Verbindungen sowohl IPv4 als auch IPv6 genutzt werden. 2.7 DNS DNS für IPv6 ist eine Erweiterung (RFC 3596 [26]) des von IPv4 bekannten Systems. Man unterscheidet hierbei zwischen der Funktion des Servers und dem Transportmedium. Als Transportmedium kann sowohl IPv4 als auch IPv6 eingesetzt werden, vollkommen unabhängig ob IPv4 oder IPv6 Informationen abgefragt werden. Um Abfragen nach IPv6 zu ermöglichen, wurde DNS lediglich um einige Recordtypen erweitert. Die Schreibweise gleicht bis auf Details bei der reversen Adressauflösung der von IPv4. Für die Namensauflösung wurde der AAAA Typ eingeführt, der analog zum A Typ funktioniert: minnehaha IN A minnehaha IN AAAA 2001:638:208:9::116 Für die reverse Auflösung von IPv6 Adressen wird wie bei IPv4 der PTR Record verwendet. Die Schreibweise weicht hier von der gewohnten Schreibweise ab. Bei IPv4 Adressen wird der PTR Record mit einer 8-Bit (Byte) Trennung aufgeschrieben ( in-addr.arpa.). Bei IPv6 wird eine 4-Bit (Nibble) Trennung vorgenommen: $ORIGN ip6.arpa \ IN PTR minnehaha.rhrk.uni-kl.de. 28

31 2.7 DNS Die Verwendung von ip6.arpa wurde mit RFC 3152 [31] im August 2001 eingeleitet. Vorher benutzte man ip6.int was zu Verwechslungen mit der Topleveldomain int führte und seit diesem Zeitpunkt für neue Adressen unerwünscht ist. Neben AAAA wurden in RFC 2874 [27] noch zwei weitere Record Typen (A6 und DNAME) und das Bitstringformat definiert. Diese Typen konnten sich jedoch nicht durchsetzen und wurden durch RFC 3363 [28] und RFC 3364 [29] quasi abgeschafft. Sie existieren noch, sollen aber nicht mehr verwendet werden. 29

32 30

33 3 Migration Der Erfolg von IPv6 hängt in hohem Maße von den Migrationsmöglichkeiten ab. Der Übergang von IPv4 muss dabei für den Endnutzer so transparent wie möglich sein. Die Migration erfolgt langsam und kann zum Beispiel im Edgebereich beginnen. Diese IPv6-Inseln werden dann durch Tunnels miteinander verbunden, bis schließlich der Corebereich IPv6-fähig wird. Auch der umgekehrte Fall ist denkbar, bei dem die Kunden warten, bis die Providernetze vollständig IPv6-fähig sind, und sich erst dann für die Umstellung entscheiden. 3.1 Dual-Stack Endsysteme und Edgerouter werden um einen IPv6 Stack erweitert. Sie beherrschen somit sowohl IPv4 als auch IPv6. Hierbei kann jede Applikation für sich entscheiden, über welches der beiden Protokolle sie kommunizieren möchten. Diese Entscheidung wird meistens basierend auf einer DNS-Anfrage getroffen. DNS-Server antworten mit allen verfügbaren Adressen für das Zielsystem (IPv4 und IPv6). Die Applikation wählt dann das passende Protokoll aus. In der Regel wird IPv6 bevorzugt. Die Wahl des Protokolles ist dabei meist transparent für den Benutzer. Ein Nachteil dieser Methode ist die Fehleranfälligkeit. Sollte der IPv6 Stack irrtümlich oder fehlerhaft aktiviert sein, so kann der Verbindungsaufbau misslingen, ohne dass der Fehler offensichtlich ist, da IPv4 funktioniert. In diesem Fall sind dann beispielsweise Webseiten mit IPv6 Adressen nicht erreichbar, Webseiten mit IPv4 Adressen jedoch schon. In Routern führt diese Methode zu einem erhöhten Speicherbedarf, da sowohl Routinginformationen über IPv4 als auch über IPv6 gespeichert werden müssen. 3.2 IPv6 über IPv4 Eine weitere Methode zur Migration sind Tunnel, die das IPv6 Protokoll über IPv4 Netzwerke transportieren. Diese Tunnel können sowohl von Endsystemen in reinen IPv4 Umgebungen oder von Routern, die IPv6 Dual-Stack Inseln mit Hilfe eines Tunnels verbinden, aufgebaut werden. Folgende Tunnelmethoden sind für diesen Zweck implementiert worden: manuell konfigurierte IPv6 Tunnel, IPv6 über IPv4 GRE (Generic Router Encapsulation) Tunnel, automatische IPv4 kompatible Tunnel, automatische 6to4 Tunnel, ISATAP 31

34 3 Migration Tunnel (siehe Abschnitt 2.3.6) und Teredo Tunnel 1 ([17]). 3.3 Dedizierte IPv6 Leitungen Beim Einsatz von Framerelay, ATM (Asynchronous Transfer Mode), DWDM (Dense Wavelength Division Multiplexing) oder ähnlichen Layer 2 Technologien gibt es die Möglichkeit, eine virtuelle Verbindung dediziert für IPv6 zu schaffen. In diesem Fall werden zwei getrennte Netze für IPv4 und IPv6 aufgebaut, so dass es zu keiner gegenseiten Beeinflussung kommt. 3.4 Zusammenführung von Netzen Abbildung 16: Zusammenführung zweier Firmen Bei Zusammenführungen von Firmen und deren Netzen (Abb. 16) gibt es bei IPv4 immer wieder Konflikte wegen doppelt genutzter, privater IP-Adressen. An den ehemaligen Netzgrenzen muss deswegen eine Adressumsetzung stattfinden oder in ganzen Netzbereichen werden neue Adressen vergeben. Analog befürchtet man nun, dass die Verwendung von IPv6 Site-Local Adressen früher oder später zu ähnlichen Problemen führt. NAT (Network Adress Translation) sollte mit der Einführung des IPv6-Adressbereichs eigentlich nicht mehr notwendig sein. Aus diesem Grund gibt es zur Zeit Bestrebungen, die Site-Local Adressen durch Unique-Local Adressen zu ersetzen. Unique-Local Adressen sind, wie der Name schon andeutet, global eindeutig und müssen beantragt und zugeteilt werden. Sie werden jedoch im Internet nicht weitergeleitet und dürfen die Grenzen des eigenen Netzes wie Site-Local Adressen nicht überschreiten. Bei der Vergabe ist ein /48-Prefix geplant, um eine problemlose Integration in die Konzepte von IPv6 zu gewährleisten. 1 Tunneling IPv6 over UDP through NATs 32

35 3.5 Multihoming Eine Gefahr bei diesem Verfahren ist jedoch die Bequemlichkeit der Administratoren. Viele werden keinen Prefix beantragen, sondern einfach wie heute bei IPv4 irgendwelche Adressräume verwenden. So lange es Site-Local Adressen gibt, besteht zumindest die Hoffnung, dass diese von den meisten wie IPv4 private Adressen auch genutzt werden. Ein weiteres Problem wäre auch die Vergabe der Unique-Local Adressen selbst. Soll diese zentral oder dezentral geschehen? Kostet sie Geld? Muss man den Antrag regelmäßig erneuern oder sind die Adressen für immer vergeben? Doppelt genutzte Adressen führen nicht unmittelbar zu Konflikten und somit werden Administratoren aus Zeitgründen oder Bequemlichkeit vermutlich einfach einen beliebigen Prefix wählen. 3.5 Multihoming ISP A ISP B Abbildung 17: Multihoming Multihoming, das heißt eine Anbindung an mehrere Provider (Abb. 17), ist für Einzelunternehmen noch nicht vollständig geklärt. Ein Provider bekommt einen relativ kurzen Prefix zugeteilt. Dieser kann mehr oder weniger an einer beliebigen Stelle im Internet angeschlossen sein und wird mit Hilfe von BGP lokalisiert. Im Gegensatz zu IPv4 ist ein Endkunden Prefix (/48) in IPv6 immer genau einem Provider zugeordnet. Wenn ein Kunde nun den Anschluss an zwei Provider wünscht, bekommt er von beiden jeweils einen Prefix zugeteilt. Die einzelnen Rechner können so entweder an dem einen oder an dem anderen Provider angeschlossen werden oder müssen jeweils zwei IPv6 Adressen bekommen. Der Ausfall eines Providers führt so trotz 33