Subneting - IP4-IP6

Überblick über die Hauptunterscheidungsmerkmale zwischen IPv4 und IPv6

Handout zum Referat als Leistungsnachweis

Hochschule Bremerhaven

Fachbereich 1

Studiengang Medizintechnik

Axel Newe

23619

Markus Rehrs

23175

Bremerhaven, 12. Mai 2005

2

Inhalt

1. Einleitung............................................................................................................................3 1.1. Begriffserläuterungen .................................................................................................3 1.2. Historisches.................................................................................................................3

2. Neuheiten im IPv6 und Unterschiede zum IPv4.................................................................4 2.1. Der Adressraum ..........................................................................................................4 2.2. Aufteilung des Adressraums.......................................................................................5

2.2.1. Kompatibilitätsadressen......................................................................................5 2.2.2. Unicast-Adressen ................................................................................................5 2.2.3. Unique local address („ULA“, Unicast) .............................................................6 2.2.4. Multicast-Adressen .............................................................................................6 2.2.5. Anycast-Adressen ...............................................................................................7 2.2.6. Broadcast-Adressen ............................................................................................7 2.2.7. Zusammenfassung der Adressräume ..................................................................7

2.3. („Statuslose“) Autokonfiguration ...............................................................................8 2.3.1. Grundlagen der Autokonfiguration.....................................................................8 2.3.2. Neighbor Discovery Protocol .............................................................................9 2.3.3. Mechanismen des Neighbor Discovery Protocol..............................................10 2.3.4. Eingriffe in die Autokonfiguration ...................................................................11 2.3.5. Umnummerierung, Re-Adressierung................................................................11

2.4. Header.......................................................................................................................11 2.4.1. Basisheader .......................................................................................................11 2.4.2. Erweiterungsheader ..........................................................................................12

2.5. Sicherheit ..................................................................................................................13 2.5.1. Authentifizierung der Daten .............................................................................14 2.5.2. Verschlüsselung der Daten ...............................................................................14 2.5.3. Address Privacy ................................................................................................15

2.6. Mobile IPv6 ..............................................................................................................16 3. Glossar ..............................................................................................................................20 4. Quellennachweis...............................................................................................................22 Tabellen

Tabelle 1 : Adressräume im IPv6 ...............................................................................................7 Tabelle 2 : Aufbau eines IPv6-Basis-Headers ..........................................................................12 Tabelle 3 : Felder eines IPv6-Basis-Headers ............................................................................12 Tabelle 4 : IPv6-Erweiterungs-Header .....................................................................................13 Tabelle 5 : Transportmodus : IP-Datenpaket vor Einfügen eines Authentication Headers......14 Tabelle 6 : Transportmodus : IP-Datenpaket nach Einfügen eines Authentication Headers....14 Tabelle 7 : Tunnelmodus : IP-Datenpaket nach Einfügen eines Authentication Headers........14 Tabelle 8 : Transportmodus: IP-Datenpaket ohne Verschlüsselung.........................................15 Tabelle 9 : Transportmodus: : IP-Datenpaket mit Verschlüsselung .........................................15 Tabelle 10 : Tunnelmodus : IP-Datenpaket nach Einfügen eines Authentication Headers......15 Abbildungen

Abbildung 1: Normaler Betrieb an der Home Address ............................................................17 Abbildung 2: Binding Update...................................................................................................17 Abbildung 3: Binding Acknowledgement ................................................................................18 Abbildung 4: Handover ............................................................................................................18 Abbildung 5: Folgender Datenverkehr .....................................................................................19

1. Einleitung 3

1. Einleitung

Diese Arbeit soll die Hauptunterscheidungsmerkmale zwischen den Internetprotokollen der Version 4 und der Version 6 aufzeigen.

Dabei wird hauptsächlich auf die für den Endanwender interessanten Merkmale eingegangen; tiefergehende technische Details werden bewusst nur am Rande genannt, da sie den Rahmen dieser Arbeit sprengen würden.

1.1. Begriffserläuterungen

Das Kürzel „IP“ steht für „Internet Protocol“. Ein Protokoll im Sinne eines Netzwerkprotokolls ist eine Konvention zum Austausch von Daten zwischen Computern (oder auch anderen Geräten). Das „IP“ tritt in der Regel zusammen mit dem „Transmission Control Protocol“ TCP als TCP/IP auf. Das TCP ist dabei für die OSI-Schicht 4 (Transport) zuständig und setzt auf das IP (OSI-Schicht 3 – Vermittlung) auf.

Ein weiteres wichtiges Protokoll für den Netzwerkverkehr ist das Internet Control Message Protocol (ICMP), das zwar eigentlich in der OSI-Schicht 4 angesiedelt, jedoch im IP integriert ist. Dieses Protokoll dient zum Austausch von Kontroll-, Fehler- und Steuerdaten. Das einfachste Beispiel für den Einsatz des ICMP ist der Ping-Befehl : eine ICMP-Nachricht „Echo request“ wird mit einer ICMP-Nachricht „Echo reply“ beantwortet.

Alle Standards, die das Internet betreffen, sind in den sogenannten RFCs definiert. RFC steht für „Request for Comments“. Hierbei handelt es sich um eine Dokumentensammlung, die von der Internet Engineering Task Force (IETF) und der Internet Engineering Steering Group (IESG) geführt wird.

1.2. Historisches

Der erste brauchbare Standard für ein Internet-Protokoll war das IPv4 (v4 steht für „Version 4“), das 1981 mit dem RFC 791 definiert wurde. (TCP : RFC 973, ebenfalls 1981). Es löste das „DoD standard Internet Protocol“ („IPv3“, RFC 760) von 1980 ab und verhalf nicht nur dem Internet zum Durchbruch, sondern ist derzeit auch DAS Netzwerkprotokoll überhaupt – nicht nur für das Internet, sondern auch für Intranets. Es hat praktisch alle anderen Netzwerkprotokolle (z.B. IPX) weitgehend verdrängt.

Der Erfolg des IPv4 war aber auch gleichzeitig dessen größtes Problem: die zunehmende Verbreitung und immer wichtiger werdende Sicherheitsanforderungen machten schon Anfang der 90er klar, dass ein neues Protokoll von Nöten ist. Ab 1993 begann die IETF dann ernsthaft damit, ein neues Protokoll auszuarbeiten, bis schließlich 1998 das IPv6 (RFC 2460) veröffentlicht wurde (v6 steht – wer hätt’s gedacht – für „Version 6“). Ein zwischenzeitlich

1. Einleitung 4

entworfenes IPv5 stellte sich als Totgeburt heraus, vor allem, weil die großen Soft- und Hardware-Hersteller aus Kostengründen nicht bereit waren, diesen Standard zu unterstützen.

Mittlerweile haben aber auch die „Großen“ die Notwendigkeit eines neuen Standards eingesehen, so dass IPv6 langsam auf dem Vormarsch ist. Windows XP bietet die Umsetzung dieses neuen Protokolls beispielsweise ab dem Service Pack 2, Linux ab der Kernel-Version 2.6 und MacOS ab der Version 10.2.

2. Neuheiten im IPv6 und Unterschiede zum IPv4

2.1. Der Adressraum

Eine IPv4-Adresse setzt sich aus 32 Bit zusammen, die üblicherweise in 4 Gruppen zu je 8 Bit notiert werden. Die einzelnen Gruppen sind dabei durch einen Punkt getrennt; die Notierung erfolgt mittels Dezimalzahlen. Beispiel : 192.168.0.1

Die 32 Bit ermöglichen 232 = 4.294.967.296 = 4,3 x 109 eindeutige Adressen. Für die Anfangszeit des Internet mit wenigen hundert oder tausend verbundenen Computern erschien das mehr als ausreichend. Heutzutage stößt man damit aber in einigen Regionen bereits an damals nicht vorherzusehende Grenzen.

Daher ist die bedeutendste Neuerung im IPv6 die Erweiterung des Adressraumes auf 128 Bit. Damit stehen 2128 = 3,4 x 1038 eindeutige Adressen zur Verfügung. Eine unglaublich große Zahl, die man sich nicht wirklich vorstellen kann – daher ein kleiner Vergleich: innerhalb des IPv6-Adressraumes wäre es möglich, jedem einzelnen Atom der Erdoberfläche rund 25.000 Adressen zuzuweisen!

Es sei noch erwähnt, dass selbst über diese Größe innerhalb der IETF lange keine Einigkeit herrschte. Ein Teil der Mitglieder wollte den Adressraum auf 64 Bit begrenzen, ein anderer Teil wollte sich gar nicht festlegen und mit variabler Länge arbeiten, um das Problem des Adressmangels ein für alle Mal zu lösen.

Die herkömmliche Notation in 8-Bit-Gruppen wäre für IPv6-Adressen sehr lästig. Es müssten immerhin 16 Gruppen geschrieben werden! Daher wurde folgende Vereinbarung getroffen : die Adressen des IPv6 werden zu 16-Bit-Gruppen zusammengefasst und diese in Hexadezimaler Form notiert. Beispiel : 243F:6A88:85A3:08D3:1319:8A2E:0370:7344. Als Gruppentrennzeichen dient - wie man sieht - der Doppelpunkt. Da aber der Informatiker an sich ein recht fauler Zeitgenosse ist, beschloss man zwei Vereinfachungen:

• Führende Nullen einer Gruppe können entfallen: 00B0 wird zu B0

• Einzelne oder aufeinander folgende Gruppen, die nur aus Nullen bestehen, können weggelassen und durch einen doppelten Doppelpunkt ersetzt werden. Um die Eindeutigkeit zu wahren, ist dies aber pro Adresse nur einmal möglich :

2. Neuheiten im IPv6 und Unterschiede zum IPv4 5

o ::1319:8A2E:0370:7344 = 0:0:0:0:1319:8A2E:0370:7344

o 243F:6A88::8A2E:0370:7344 = 243F:6A88:0:0:0:8A2E:0370:7344

o 243F::85A3::0370:7344 ist nicht möglich !

2.2. Aufteilung des Adressraums

Genau wie im IPv4 wird eine IPv6-Adresse in die Netz-Adresse und die Host-Adresse unterteilt. Dies geschieht über das NetPrefix, das durch ein Schrägstrich („Slash“) getrennt der eigentlichen Adresse folgt. Bewährtes wurde also beibehalten: die Adresse

243F:6A88:85A3:08D3:1319:8A2E:0370:7344/16

bedeutet also, dass 243F die Netz-Adresse und 6A88:85A3:08D3:1319:8A2E:0370:7344 die Host-Adresse darstellt. Ist kein NetPrefix angegeben, so gilt standardmäßig /64.

Die aus dem IPv4 bekannte Einteilung in Netzwerkklassen (Class A, B, C) entfällt im IPv6 – hier ist die Aufteilung um einiges differenzierter (RFC 2373, siehe folgende Unterkapitel). Verantwortlich für die Verwaltung der Adressräume ist die „Internet Assigned Numbers Authority“ („IANA“, RFC 1881).

In der Regel erkennt man an der ersten Zahlengruppe, um was für eine Art Netz bzw. Adresse es sich handelt. Im Folgenden sollen nun einige der reservierten Adressräume des IPv6 herausgestellt werden.

2.2.1. Kompatibilitätsadressen

Adressen der Form ::FFFF:xxxx:xxxx bilden IPv4-Adressen ab, die unverändert (nur in hexadezimaler Form) in die letzten beiden Gruppen eingefügt werden. Beispiel :

IPv4 Adresse : 213.168.202.37 (dezimal) = D5.A8.CA.25 (hexadezimal)

IPv6-Adresse : 0000::FFFF:D5A8:CA25

Auch zulässig ist eine gemischte Schreibweise: 0000::FFFF:213.168.202.37

Weiterhin sind Kompatibilitätsadressen für das IPX-Protokoll und das NSAP-Protokoll vorgesehen (für letztere allerdings mit RFC 4048 schon wieder verworfen).

2.2.2. Unicast-Adressen

Unter einem Unicast versteht man Daten, die von einem bestimmten Punkt an genau einen anderen Punkt verschickt werden. Dies ist die häufigste Form der Datenübermittlung.

Globale Unicast-Adressen („Unique Global Address“, also Adressen, die weltweit eindeutig sind) beginnen mit den ersten 3 Bits 001. Damit stehen theoretisch alle Adressen von 0200:… bis 03FF:… zur Verfügung. In der Praxis werden diese Netze aber noch weiter unterteilt, so dass z.B. ganze Adressräume an Internet-Service-Provider vergeben werden und diese


wiederum Adressräume an ihre Kunden weitergeben, welche ihr Netz dann in Subnetze unterteilen können…

Diese Adressen sind vergleichbar mit den normalen, nicht reservierten Adressen des IPv4.

Weitere Unicast-Adresstypen sind die „link local“- und die „site local“-Adressen. Diese haben nur in ihrem eigenen Subnetz (link local), bzw. im eigenen Netz (site local) Gültigkeit und werden von Routern nicht außerhalb ihres Gültigkeitsbereiches verfügbar gemacht. Man kann sie mit den „privaten“ Netzwerkadressen des IPv4 vergleichen (z.B. 192.168.x.x).

Die „site local“-Adressen wurden mit RFC 3879 verworfen, da mit den „Unique Local Addresses eine bessere Alternative definiert ist.

2.2.3. Unique local address („ULA“, Unicast)

Wie der Name schon andeutet sind ULAs Adressen, die zwar privat, also auf ein bestimmtes Netz beschränkt, aber dennoch weltweit eindeutig sind. Die Idee dazu erwuchs im Wesentlichen aus Sicherheitsbedenken. Im IPv4 waren die privaten Adressen immer gleich (192.168.x.x oder 10.x.x.x), so dass diese Adressen für Angriffe von außen relativ leicht zu erraten waren. Außerdem bestand die Gefahr der Verwechslung bei Verbindungen zwischen zwei oder mehreren privaten Netzen (bei Fehlkonfigurationen wäre es möglich, dass beispielsweise unter der Adresse 192.168.0.3 mehr als ein Host angesprochen wird, da in jedem der privaten Netze dieser Host vorkommen könnte). Da die ULAs jedoch zusätzlich eine eindeutige Netz-ID beinhalten bestehen diese Gefahren im IPv6 nicht mehr.

Der Hauptunterschied zwischen den ULAs und den „site local“-Adressen ist also, dass ULAs von einer übergeordneten Stelle vergeben (und somit weltweit eindeutig) sind, „site locals“ hingegen praktisch nach Belieben von Netzwerkadministratoren vergeben werden dürfen.

Aufgrund des „privaten“ Charakters dieser Adressen lassen sie sich im IPv4 am ehesten mit den dortigen privaten Netzen (z.B. 192.168.x.x) vergleichen.

2.2.4. Multicast-Adressen

Dieser Adresstyp fasst eine ganze Gruppe von Empfängern zusammen, so dass es möglich wird, Daten in einem Rutsch an mehr als einen Empfänger zu senden, z.B. für Konferenzschaltungen, Bildübertragungen (Internet-TV) oder ähnliches. Auch hier können wieder verschiedene Gültigkeitsbereiche unterschieden werden. Es existieren derer fünf:

• knotenlokal (auf den Knoten beschränkt)

• linklokal (auf ein Subnetz beschränkt)

• sitelokal (auf ein Netz beschränkt)

• organisationslokal (auf eine bestimmbare Gruppe von Netzen beschränkt)

• global (keine Beschränkung, weltweiter Multicast)


2.2.5. Anycast-Adressen

Während es Unicast- und Multicast-Adressen auch im IPv4 gibt, sind die so genannten Anycast-Adressen ein echtes Novum im IPv6. Mit derart adressierten Datenpaketen wird ähnlich wie im Multicast zunächst einmal wieder eine ganze Gruppe von Empfängern angesprochen. Das besondere ist hier allerdings, dass sich nur einer der Empfänger tatsächlich angesprochen fühlt – nämlich derjenige, der als erster darauf reagiert.

Prinzipiell ist daher eine Anycast-Adresse genauso aufgebaut wie eine Unicast-Adresse; nur ist diese Unicast-Adresse mehreren Geräten zugeordnet, von denen sich dann aber nur eines wirklich dafür interessiert.

Ein Beispiel für die Anwendungsmöglichkeit von Anycast-Gruppen wären DNS- oder Webserver.

2.2.6. Broadcast-Adressen

Die aus IPv4 bekannten Broadcast-Adressen gibt es im IPv6 nicht mehr. Zur Erinnerung: eine Broadcast-Adresse war im IPv4 die höchste verfügbare Adresse im lokalen Netz (z.B. 192.168.255.255/16) und war nicht einem einzigen Gerät zugeordnet, sondern diente als Rundruf-Adresse an alle Netzwerkteilnehmer.

2.2.7. Zusammenfassung der Adressräume

Die folgende Tabelle soll einen kurzen Überblick über die wichtigsten Adresstypen gemäß RFC 2373 geben. Wie man erkennen kann, ist bisher nur ein sehr kleiner Teil der möglichen Adressen spezifiziert (weniger als 15 %), so dass noch reichlich Möglichkeiten für zukünftige Erweiterungen verfügbar sind.

Verwendung Adressbereich Anzahl Adressen

Anteil am Adressraum

Undefinierte Adresse 0000::0 1 Loopback, Local host 0000::1 1 Abbildung von IPv4-Adressen 0000::FFFF:… 4,3 x 109 < 0,001 % Abbildung von NSAP-Adressen 0200:… bis 03FF:… 2,6 x 1036 0,781 % Abbildung von IPX-Adressen 0400:… bis 05FF:… 2,6 x 1036 0,781 % Unicast : Unique global address 2000:… bis 3FFF:… 4,3 x 1037 12,500 % Unicast : Link local adress FE80:… bis FEBF:… 3,3 x 1035 0,098 % Unicast : Site local adress (überholt, abgelöst von ULA)

FEC0:… bis FEFF:… 3,3 x 1035 0,098 %

Unicast : Unique Local Address, ULA FC00:… und FC01:…

1,0 x 1034 0,003 %

Multicast FF01:… 1,3 x 1036 0,391 %

Tabelle 1 : Adressräume im IPv6


2.3. („Statuslose“) Autokonfiguration

2.3.1. Grundlagen der Autokonfiguration

Ein besonderes Schmankerl des IPv6 ist die Autokonfiguration (auch: Statuslose Autokonfiguration). Ein IPv6-Knoten (Computer, Drucker, Router) ist in der Lage, aus seiner 48-Bit-MAC-Adresse selbständig eine linklokale Adresse (FE80:...) zu erstellen, um sich damit bei anderen Rechnern oder einem Router in seinem Subnetz anzumelden. Das aus IPv4 bekannte Address Resolution Protocol (ARP) zur Abgleichung von IP- und MAC-Adresse wird damit überflüssig.

Ist kein Router vorhanden (mithin kein Anschluss ans Internet), so ist die Adress-Konfiguration damit schon abgeschlossen.

Ist jedoch ein IPv6-fähiger Router vorhanden, der in Verbindung mit anderen Netzen, bzw. dem Internet steht, so kann dieser dem neuen Netzmitglied eine Unicast-Adresse zuweisen, so dass dieses mit dem Internet in Verbindung treten kann. Alternativ muss ein IPv6-Router dafür Sorge tragen, dass Knoten mit linklokaler Adresse nicht über ihr Subnetz hinaus mit anderen Knoten kommunizieren können, falls sie keine Unicast-Adresse erhalten dürfen oder sollen.

Diese Zuweisung von Unicast-Adressen kann sowohl vom Knoten (Host) als auch vom Router eingeleitet werden. Im ersten Fall macht sich der Knoten mittels „Router Solicitation“ von sich aus auf die Suche nach einem Router. Im zweiten Fall reagiert der Knoten auf so genannte „Router Advertisements“. Darauf wird aber im nächsten Kapitel noch detaillierter eingegangen.

Dass alles funktioniert vollautomatisch – eine aufwändige „Von-Hand“-Konfiguration durch Administratoren oder gar technisch unbedarfte Endnutzer ist nicht nötig.

Beim IPv4 ist das deutlich komplizierter, da IPv4-Geräte von sich aus keine IP-Adresse generieren können (zur Erinnerung: die MAC-Adresse ist 48 Bit lang, die IPv4-Adresse hingegen nur 32 Bit). IP-Adresse und Subnetzmaske (bzw. Netzpräfix /x) müssen also manuell festgelegt werden, was besonders bei größeren Netzen mit zahlreichen Geräten mit erheblichem administrativem Aufwand verbunden ist – zumal sich viele Geräte (z.B. Drucker, Druckerserver oder Router) nicht so einfach konfigurieren lassen wie ein PC. Außerdem kann eine fehlerhafte Konfiguration im schlimmsten Fall das ganze Netz lahm legen.

Mit dem DHCP (Dynamic Host Configuration Protocol) steht zwar auch im IPv4 ein gewisser Grad an Automatisierung für die Zuweisung von Adressen zur Verfügung. Größter Nachteil ist jedoch, dass für das DHCP ein Server benötigt wird, der die IP-Adressen vergibt und verwaltet. Fällt dieser Server aus, so ist das Netz im schlimmsten Fall nicht mehr funktionsfähig.


DHCP funktioniert zwar auch mit IPv6, sollte aber zugunsten der Autokonfiguration zurücktreten. Nur wenn ein Netzwerkadministrator verstärkt auf die Adressvergabe Einfluss nehmen will, ist die Nutzung von DHCP auch im IPv6 sinnvoll, da die Einflussmöglichkeiten im Rahmen der Autokonfiguration sehr beschränkt sind.

Eine weitere wichtige Neuerung im IPv6 ist die zeitlich begrenzte Gültigkeitsdauer von IP-Adressen. Dadurch bedingt muss jeder Knoten die Autokonfiguration in bestimmten (definierbaren) Abständen erneut durchlaufen. Damit werden Änderungen an den Netzwerkparametern (z.B. Berechtigungen) spätestens nach diesem definierten Zeitraum für alle Knoten wirksam.

2.3.2. Neighbor Discovery Protocol

Die Spezifikationen für die unter 2.3.1. aufgeführten Funktionen der Autokonfiguration finden sich im Neighbor Discovery Protocol (NDP) gemäß RFC 2461. Es übernimmt Aufgaben, für die im IPv4 noch mehrere Protokolle nötig waren: u.a. ARP (Address Resolution Protocol), DHCP (Dynamic Host Configuration Protocol), ICMP Router Discovery und ICMP Redirect. Das NDP definiert folgende Funktionen:

• Router Discovery: Verfahren zum Auffinden von Routern in einem Link.

• Prefix Discovery: Verfahren zur Ermittlung des Netzwerk-Prefix und zur Ermittlung von link-Lokalität und site-Lokalität

• Parameter Discovery: Verfahren zur Ermittlung von Netzwerkparametern (z.B. Hop Limits)

• Address Autoconfiguration: Verfahren zur Ermittlung der link-lokalen IP-Adresse aus der MAC-Adresse

• Address Resolution = Umkehr der Address Autoconfiguration: Verfahren zur Ermittlung der MAC-Adresse aus der link-lokalen IP-Adresse

• Next Hop Determination: Verfahren zur Ermittlung des jeweils nächsten Ziel-Knotens für Datenpakete, die über mehrere Hops laufen

• Neighbor Unreachability Detection: Verfahren zur Erkennung nicht erreichbarer Knoten

• Duplicate Address Detection: Verfahren zum Ausschluss doppelter Adressvergabe.

• Redirect: Verfahren zur Optimierung von Hop-Routen

Für die praktische Ausführung dieser Funktionen sind im NDP fünf ICMP-Pakettypen definiert:


• Router Solicitation: Anforderung eines Router Advertisement

• Router Advertisement: Bereitstellung von Konfigurationsinformationen durch den Router, s. nächstes Kapitel

• Neighbor Solicitation: Anforderung eines Neighbor Advertisement, s. nächstes Kapitel

• Neighbor Advertisements: Antwort auf eine Neighbor Solicitation, s. nächstes Kapitel

• Redirect Message: Nachricht zur Durchführung eines Redirect, s. nächstes Kapitel

2.3.3. Mechanismen des Neighbor Discovery Protocol

Router Solicitation / Router Advertisement

(Aus dem Englischen : „Solicitation“ = „Bewerbung“ / „Advertisement“ = „Ankündigung“)

Router-Advertisement-Datenpakete werden in regelmäßigen Abständen (i.d.R. alle 600 Sekunden) ausgesendet. Sie enthalten alle Daten, die die Knoten für die Autokonfiguration benötigen (z.B. Hardware-Adresse des Routers, Prefix, Hop Limit, Lifetime...).

Wenn ein Knoten keine Lust hat, im schlimmsten Fall bis zu 600 Sekunden auf das nächste Router Advertisement zu warten, so kann er eine Router Solicitation aussenden. Diese geht an die Multicast-Adresse FF02::2 und erreicht damit alle lokalen Router, die dann veranlasst werden, sofort ein Advertisement loszuschicken. Im Gegensatz zu den regelmäßigen Advertisements geht dieses aber direkt an den anfordernden Knoten und nicht an alle.

Neighbor Solicitation / Neighbor Advertisement

Die Neighbor Solicitation dient hauptsächlich zur Ermittlung der MAC-Adresse eines anderen Knotens im selben Link. Sie wird aber auch genutzt, um die Erreichbarkeit eines bekannten Knotens zu überprüfen oder für die Ermittlung, ob eine IP-Adresse bereits vergeben ist.

Die Antwort des angesprochenen Knotens erfolgt durch das Neighbor Advertisement (oder halt nicht, falls die Ziel-Adresse nicht vergeben oder nicht erreichbar ist).

Redirect Messages

Da kein Router auf die Idee kommen würde, möglichst viel Datenverkehr an sich zu reißen, gibt es im IPv6 einige Mechanismen, um Anfragen abzuwimmeln.

Das einfachste Szenario wäre die Reduktion von Traffic im eigenen Knoten. Ist ein Router vorhanden, so läuft der Verkehr überlicherweise über ihn. Sendet aber nun ein Knoten Daten an einen anderen Knoten desselben Links, so ist es natürlich Unsinn, diese Daten auch über den Router zu leiten. Ein schlauer IPv6-Router merkt dies und teilt dem absendenden Knoten per Redirect Message mit, dass sein Ziel im eigenen Link liegt und liefert die MAC-Adresse gleich mit. So kann folgender Verkehr direkt zwischen den beiden betreffenden Knoten ablaufen.


Ein anderer Einsatz von Redirect Messages findet sich in Netzen mit mehreren Routern. Ist ein Router überlastet oder ein „Umweg“ für die über ihn laufenden Datenpakete, so kann er den angeschlossenen Knoten Alternativ-Router zuweisen, um den Datenverkehr zu optimieren.

2.3.4. Eingriffe in die Autokonfiguration

Die Autokonfiguration läuft zwar – wie man anhand des Namens annehmen sollte – weitgehend automatisch ab, dennoch kann in gewissem Rahmen Einfluss genommen werden. Da die meisten Aufgaben der Autokonfiguration von den Routern übernommen werden, kann das Netzwerk dort durch Einstellung bestimmter Parameter angepasst werden. Dies betrifft z.B. die Einstellung der Frequenz der Router Advertisements, Prefixe, Adressräume usw.

2.3.5. Umnummerierung, Re-Adressierung

Aus den oben beschriebenen Vorgängen bei der Autokonfiguration wird deutlich, dass eine komplette Re-Adressierung eines Netzes (z.B. bei Provider- oder Adressraumwechsel) unter IPv6 kein Problem mehr darstellt. War dies unter IPv4 noch eine sehr aufwändige Angelegenheit, bei der im schlimmsten Fall alle Adressen von Hand geändert werden mussten, so werden unter IPv6 einfach einige Parameter im zuständigen Router angepasst. Spätestens nach dem nächsten turnusmäßigen Durchlauf der Autokonfiguration (nach Ablauf der Gültigkeit einer IP-Adresse) ist das komplette Netz wieder auf dem aktuellen Stand.

2.4. Header

2.4.1. Basisheader

IP-Datenpakete bestehen aus einem oder mehreren „Headern“ (frei übersetzt “Einleitungen”) und dem „Payload“, den eigentlichen Daten. Wie diese Header im IPv6 auszusehen haben, ist im RFC 2460 definiert. Während es im IPv4 nur den Header gab, unterscheidet man bei IPv6 zwischen einem Basisheader und einem oder mehreren optionalen Erweiterungsheadern. Die Definition von neuen Headern war allein schon deshalb nötig, weil die neuen IPv6-Adressen in den alten IPv4-Headern nicht ohne weiteres unterzubringen waren.

Der Basisheader muss jedem IPv6-Datenpaketes vorangehen, hat eine feste Größe und ist wie folgt aufgebaut:


4 Bit 4 Bit 4 Bit 4 Bit 4 Bit 4 Bit 4 Bit 4 Bit Version Class Flow Label

Payload Length Next Header Hop Limit

Source Address

Destination Address

Tabelle 2 : Aufbau eines IPv6-Basis-Headers

Dabei haben die einzelnen Felder folgende Bedeutungen:

Version: Enthält die Versionsnummer des Internet-Protokoll und ist 4 Bit lang (bei IPv6: 0110). Dieses Feld ermöglicht die Unterscheidung und damit den parallelen Betrieb der verschiedenen Internet Protokolle wie IPv4 und IPv6.

Class: Ist ein 8 Bit langes Feld, welches die Priorität des Datenpaketes enthält. Die Priorität wird vom Absender angegeben und dient den Routern des Transportweges dazu, Pakete je nach Netzauslastung auf unterschiedlichen Wegen zum Empfänger zu senden oder sogar zu verwerfen.

Flow Label: Enthält eine 20 Bit lange Identifikationsnummer, die dafür genutzt wird, um Pakete zu kennzeichnen, bei denen eine besondere (z.B. bevorzugte) Behandlung durch IPv6 Router gewünscht wird. Ein denkbarer Anwendungsfall liegt bei Verbindungen mit Echtzeitanforderung (z.B. für Videokonferenzen) vor.

Payload Length: Gibt die Größe des auf den Header folgenden Nutzdaten-Paketes in Octets an (16-Bit-Zahl, max. Größe: 65536 * 1 Byte = 64 kByte).

Next Header: 8-Bit-Wert. Identifiziert – falls vorhanden - den Typ des ersten Erweiterungsheaders (s.u.).

Hop Limit: Ebenfalls ein 8-Bit-Wert. Legt fest, über wie viele Zwischenstationen ein IP-Paket maximal laufen darf. Dieser Wert wird von jedem Router, den das Paket passiert um eins heruntergezählt und ggf. verworfen, wenn er Null erreicht hat.

Source Address: Enthält die 128 Bit lange Adresse des Absenders Destination Address:

Enthält die 128 Bit lange Adresse des Empfängers

Tabelle 3 : Felder eines IPv6-Basis-Headers

2.4.2. Erweiterungsheader

Zusätzlich zum Basisheader können einem IPv6-Datenpaket ein oder mehrere Erweiterungsheader zugeordnet sein. Sie werden zum Transport zusätzlicher Informationen


verwendet und zwischen dem Basisheader und dem Payload (Nutzdaten) eingefügt. Im IPv4 waren diese Zusatzinformationen noch im normalen (und einzigen) Header eingefügt, wodurch die Länge eines IPv4-Headers variabel war und in einem Feld („Internet Header Length“, IHL) definiert werden musste.

Zur Zeit sind für IPv6 sechs Erweiterungsheader definiert:

Hop-by-Hop Options Header Enthält Optionen die bei jeder Zwischenstation des Paketes auf dessen Weg durch das Netz abgearbeitet werden müssen.

Routing Header Beeinflusst den Weg, den ein Datenpaket auf dem Weg vom Absender zum Empfänger durch das Netz nimmt ( Mobile IPv6, Kap. 2.6.).

Fragment Header IPv6-Router dürfen im Gegensatz zu IPv4-Routern Datenpakete nicht fragmentieren (aufsplitten). Die Pakete müssen stattdessen vom Absender selbst fragmentiert werden. Mit Hilfe der im Fragment-Header enthaltenen Informationen ist es dem Empfänger möglich, diese Datenpakete dann wieder richtig zusammenzusetzen..

Authentication Header Gibt dem Empfänger die Möglichkeit, festzustellen, ob ein Datenpaket tatsächlich vom angegebenen Absender stammt, oder ob es unterwegs verändert wurde.

Encapsulating Security Payload Header

Wird zur Verschlüsselung des Pakets per IPSec benötigt.

Destination Options Header Enthält Informationen, die nur vom Zielknoten ausgewertet werden.

Tabelle 4 : IPv6-Erweiterungs-Header

Sollten mehrere Erweiterungsheader benötigt werden, so müssen sie in der o.a. Reihenfolge angeordnet sein. Jeder Header enthält dabei in einem Feld „Next Header“ einen Verweis auf den nächsten Header, bzw. auf den Payload, falls keine weiteren Header folgen.

Durch die Einführung von Erweiterungsheadern wird das IPv6 deutlich flexibler und skalierbarer als IPv4. Bedingt durch die Größe des IHL-Feldes des IPv4-Headers kann dieser maximal 15 x 4 = 60 Bytes groß werden. Im IPv6 hingegen gibt es keine Beschränkung nach oben, da theoretisch beliebig viele Erweiterungsheader definiert und eingefügt werden können.

Auch den gestiegenen Sicherheitsanforderungen wird mit dem neuen Header-Konzept Rechnung getragen, da wichtige Funktionen schon tief im Protokoll verankert sind.

2.5. Sicherheit

Beim Entwurf von IPv4 spielten Sicherheitsbetrachtungen keine wesentliche Rolle. Bei IPv6 hingegen wurde diese Problematik sehr ausgiebig diskutiert. Die Entwicklungen von Sicherheitserweiterungen für IPv4 (IPSec) und die Implementierung von Sicherheitsstandards in IPv6 gingen nahezu parallel vonstatten, so dass sich beide Systeme sehr ähnlich sind.


2.5.1. Authentifizierung der Daten

Mit Hilfe des Authentication Headers (einer der Erweiterungsheader, definiert in RFC 2402) ist es möglich, die Echtheit eines Datenpaketes zu überprüfen und sicherzustellen, dass das Paket während dem Transport nicht manipuliert wurde. Das Verfahren ist im Großen und Ganzen recht kompliziert, kurz gefasst kann man sagen, dass über eine den Inhalt eines Datenpaketes eine Prüfsumme gebildet wird, die vom Empfänger „zurückgerechnet” wird.

Man unterscheidet bei der Authentisierung (wie auch später bei der Verschlüsselung) zwischen zwei Verfahren: dem Transportmodus und dem Tunnelmodus.

Beim Transportmodus wird lediglich ein Datenpaket einer Verbindung gesichert (bzw. jedes Datenpaket einzeln). Der Authentication Header schützt in diesem Modus alle Felder, die während des Transports nicht verändert werden dürfen (das Hop Limit Feld z.B. darf natürlich verändert werden – muss es sogar).

Basis-Header

ggf. andere Erweiterungs-Header

Payload

Tabelle 5 : Transportmodus : IP-Datenpaket vor Einfügen eines Authentication Headers

Basis-Header

ggf. andere Erweiterungs-Header

AuthenticationHeader

ggf. weitere Erweiterungs-Header

Payload

Tabelle 6 : Transportmodus : IP-Datenpaket nach Einfügen eines Authentication Headers

Beim Tunnelmodus wird die gesamte Verbindung abgesichert, indem eine sog. Punkt-zu- Punkt („Point to Point“, PPP) Verbindung eingerichtet wird. Dies wird in der Regel dann angewendet um zwei Punkte des Internets so zu verbinden, als befänden sich die beiden Rechner in einem Lokalen Netzwerk. Dazu wird das gesamte IP-Datenpaket in ein neues Datenpaket geschrieben, welches dann mit einem Authentication Header gesichert wird.

Neuer Payload

OriginalBasis-Header

ggf. Original Erweiterungs-

Header

Original Payload

Neuer Basis-Header

ggf. neue Erw.-Header

Authentication Header

ggf. weitere

neue Erw.-

Header

Tabelle 7 : Tunnelmodus : IP-Datenpaket nach Einfügen eines Authentication Headers

2.5.2. Verschlüsselung der Daten

Wenn man nicht nur sichergehen will, dass Daten unversehrt ankommen, sondern zusätzlich auch verhindern möchte, dass Unbefugte in diesen Daten herumschnüffeln, so ist eine Verschlüsselung nötig. Im ursprünglichen IPv4-Protokoll ist eine Verschlüsselung gar nicht vorgesehen, im Protokoll IPv6 hingegen schon (RFC 2406). Auch hierfür wird ein Erweiterungsheader verwendet. Dieser nennt sich “Encapsulating Security Payload Header”


oder kurz „ESP“, was auf Deutsch etwa soviel heißt wie: “Lasst uns sicherheitsrelevante Nutzlast einigeln”.

Die genauen Verfahren zur Durchführung der Verschlüsselung und Authentifizierung sind nicht Bestandteil von IPv6 und - aus leicht einsichtigen Gründen - selbst ein ausgesprochen komplexes Thema. Daher soll an dieser Stelle nicht weiter darauf eingegangen werden. Es sei nur noch erwähnt, dass man auch bei der Verschlüsselung zwischen einem Transport- und einem Tunnelmodus unterscheidet. Es gelten die gleichen Rahmenbedingungen wie bei der Authentifizierung der Daten.

Basis-Header

ggf. andere Erweiterungs-

Header Payload

nicht verschlüsselt

Tabelle 8 : Transportmodus: IP-Datenpaket ohne Verschlüsselung

Basis-Header

ggf. andere Erweiterungs-

Header

ESP Header

ggf. Destination Options-Header Payload

nicht verschlüsselt verschlüsselt

Tabelle 9 : Transportmodus: : IP-Datenpaket mit Verschlüsselung

Neuer Payload

Original

Basis-

Header

ggf. Original

Erweiterungs

-Header

Original

Payload

Neuer

Basis-

Header

ggf. neue

Erweiterungs-

Header

ESP

Header

ggf.

Destination

Options-

Header

nicht verschlüsselt verschlüsselt

Tabelle 10 : Tunnelmodus : IP-Datenpaket nach Einfügen eines Authentication Headers

2.5.3. Address Privacy

Ein weiteres Sicherheitsproblem - oder vielmehr ein Problem des Datenschutzes - bei IPv6 liegt in der automatischen Generierung von IPv6-Adressen aus der MAC-Adresse des Netzwerkgerätes, wie in Kapitel 2.3. (Autokonfiguration) beschrieben.

Kurze Erinnerung zum Thema MAC-Adresse: Die MAC-Adresse ist eine weltweit eindeutige Geräte-Identifikationsnummer für Netzwerkgeräte. Sie besteht aus 48 Bit, üblicherweise gruppiert zu sechs jeweils 8-Bit langen Hexadezimalzahlen (z.B. 00-06-F4-06-9F-8E). Die ersten drei Gruppen geben dabei den Hersteller des Gerätes an, die letzen drei Gruppen die


eigentliche Seriennummer. Ein Netzwerkgerät mit der oben genannten MAC-Adresse wäre daher als Gerät der Firma „Prime Electronics“ (Hersteller-Code 00-06-F4) zu identifizieren.

Wenn ein Nutzer über seinen Router eine Webseite anfordert, und der Router hat eine ausschließlich aus seiner MAC-Adresse generierte IP-Adresse, dann kann der Webseitenbetreiber mühelos feststellen, über welche Hardware der Besucher auf seine Webseite gekommen ist.

Damit das nicht passiert, wurden mit dem RFC 3041 die „Privacy Extensions for Stateless Address Autoconfiguration in IPv6“ eingeführt – kurz als „IPv6 Address Privacy“ bezeichnet. Bei diesem Verfahren wird die IP-Adresse nicht ausschließlich aus der MAC-Adresse gebildet, sondern aus der MAC-Adresse und einer Pseudo-Zufallszahl. Dadurch wird die (sonst einfach zu errechnende) MAC-Adresse verschleiert.

Im IPv4 gibt es derartige Sicherheitsprobleme nicht, da MAC-Adresse und IPv4-Adresse nicht voneinander abhängen, sondern quasi-beliebig von Routern, DHCP oder Administratoren zugeordnet werden können.

2.6. Mobile IPv6

Eine weitere Verbesserung des IPv6 gegenüber IPv4 ist im RFC 3775 definiert : „Mobility Support in IPv6“. Dieses RFC basiert auf den Erfahrungen, die mit „IP Mobility Support for IPv4“ (RFC 3344) gemacht wurden und fügt Verbesserungen und neue Features hinzu. Außerdem ist es von vorneherein in IPv6 integriert und nicht bloß ein Zusatz wie in der alten Version 4.

Mobile IPv6 ermöglicht die weltweite Erreichbarkeit unter einer einzigen IP-Adresse – egal wo der betreffende Knoten tatsächlich ans Internet angeschlossen wird. Damit wird der zunehmenden Anzahl von Notebooks (und damit von mobilen Internetnutzern) Rechnung getragen. Zwar ist es auch heute (für den User halbwegs problemlos) möglich, sich von verschiedenen Orten aus ins Internet einzuloggen, wie z.B. an der Hochschule. Dazu ist aber einiges an Verwaltungsaufwand nötig (sowohl auf Seiten des Netzbetreibers als auch auf der Seite des Nutzers); außerdem können sich die Zugangsarten an verschiedenen Orten stark unterscheiden, so dass für jede Örtlichkeit eine eigene Software nötig ist (vgl. Zugang über VPN-Client an der Hochschule Bremerhaven).

Unter IPv6 funktioniert das so: jedem Knoten (z.B. einem Notebook) ist zunächst einmal eine

Heimatadresse („Home Address“, „HA“) zugewiesen. Dies sollte eine weltweit eindeutige Adresse sein, also entweder eine Unique Global Address oder eine Unique Local Address. Befindet sich der Knoten im Heimatnetz, ist alles gut und er kann ganz normal über seinen Heimatrouter angesprochen werden.


Abbildung 1: Normaler Betrieb an der Home Address

Verlässt der Knoten aber das Heimatnetz und wird anderswo ans Internet angekabelt (oder gewirelesst), dann wird’s spannend.

Auch im aktuellen, heimatfernen Netz erhält der Knoten natürlich eine IP-Adresse. In diesem Fall wird sie als „Care of Address“ („CoA“) bezeichnet. Nun schickt der Knoten ein „Binding Update“-Datenpaket an den Heimatrouter, der normalerweise für ihn zuständig wäre. Dieses Datenpaket enthält unter anderem die CoA.

Abbildung 2: Binding Update


Der Heimatrouter wird dadurch zum „Home Agent“ befördert und antwortet mit einem „Binding Acknowledgement“-Datenpaket. Dadurch teilt er dem mobilen Knoten mit, dass die Umleitung aktiviert und er nun wieder unter seiner Heimatadresse erreichbar ist.

Abbildung 3: Binding Acknowledgement

Will nun ein anderer Knoten Daten an den mobilen Knoten senden, so werden diese Daten zunächst einmal vom Home-Agent-Router unter Verwendung eines „Routing“-Erweiterungsheaders an die Care of Address weitergeleitet (sog. „Handover“).

Abbildung 4: Handover


Dabei wird die Adresse des Absenders mit durchgereicht, so dass der mobile Knoten für den folgenden Datenverkehr direkt mit ihm in Verbindung treten kann und nicht mehr auf die Dienste des Home Agent zurückgreifen muss.

Abbildung 5: Folgender Datenverkehr

Jetzt wird auch deutlich, warum die „Home Address“ eine Unique Address sein sollte. Würde es sich um eine dynamische, temporäre Adresse handeln, so würde sie vom Router wieder gelöscht und für andere Nutzungen freigegeben werden, sobald der Knoten die Verbindung mit ihm verliert. Der Router könnte also ein Binding Update nicht zu einem lokalen Knoten zuordnen und wüsste daher nicht welche Datenpakete er umleiten soll.

Nicht vergessen darf man hier die Gefahr durch Angriffe von Hackern, die bei der Umleitung von Datenpaketen immer gegeben ist. Daher sind beim Einsatz von Mobile IPv6 einige Sicherheitsmechanismen (Header Sending Authentication, Data Integrety Protection, Replay Protection) unbedingt einzusetzen.

3. Glossar 20

3. Glossar

Care Of Address, CoA : Momentane Nicht-Heimatadresse eines mobilen Gerätes

Handover : Weiterleitung von Daten an eine CoA

Home Address : Heimatadresse eines mobilen Gerätes

Home Agent : Router, der Mobiliutäts-Management übernimmt

Hop : Weiterleitung eines Datenpaketes über einen Router

Hop Limit : Maximale Anzahl von Hops

Host : ein Node, der nicht Router ist

IANA : Internet Assigned Numbers Authority

ICMP : Internet Control Message Protocol

IETF : Internet Engineering Task Force

IESG : Internet Engineering Steering Group

IP : Internet Protocol

IP-Adresse : Nummer zur Identifizierung eines Nodes im Internet-Verkehr

IP-Header : Teile eines IP-Paketes mit Steuer- und Kontrollinformationen

IP-Paket : Datenfolge aus IP-Header(n) und Payload

IPSec : Internet Security Protocol

Knoten : siehe Node

Link : lokaler Zusammenschluss von Nodes ohne Verbindung zur „Außenwelt“

Link local : auf den eigenen Link beschränkt

MAC-Adresse : Nummer, die die Hardware eines Nodes weltweit eindeutig identifiziert

Neighbors : alle Nodes, die in einem Link zusammengeschlossen sind

NetPrefix : Code für die Unterteilung von IP-Adressen

Netz : siehe Site

Node : ein Netzwerkgerät. Ein Knoten kann ein PC, ein Router, ein Terminal, ein Drucker, ein PDA oder irgendein anderes netzwerkfähiges Gerät.

Octet : Gruppee von 8 Bits; wurde eingeführt, da nicht in allen Computersystemen 8 Bits = 1 Byte gilt

OSI : Open Source Initiative

OSI-Schichtenmodell : Modell für die Organisation von Kommunikationstechnik

3. Glossar 21

Payload : Teil eines IP-Paketes mit den eigentlich zu übertragenden Nutzdaten

Prefix : siehe NetPrefix

Pseudozufallszahl : technische erzeugte Zahl, die nicht tatsächlich rein zufällig ist, aber ähnliche Eigenschaften hat

RFC : „Request for Comment“ – Dokumentensammlung mit Internet-Standards

Router : ein Gerät, dass Datenpakete steuert, weiterleitet und weitere Management-Aufgaben übernimmt

Site : lokaler Zusammenschluss von mehreren Links ohne Verbindung zur „Außenwelt“

Site local : auf die eigene Site beschränkt

Subnetz : siehe Link

TCP : Transfer Control Protocol

4. Quellennachweis 22

4. Quellennachweis

Folgende Internet-Quellen wurden zur Erstellung dieser Arbeit herangezogen :

http://www.ipv6-net.de/

http://de.wikipedia.org/

http://www.rfc-editor.org/

http://www.fh-fulda.de/~klingebiel/nbs-kolloquium/ipng1/

http://www.iana.org/

http://www.computerlexikon.com/

Folgende RFCs wurden zur Erstellung dieser Arbeit herangezogen :

RFC 791 : Internet Protocol

RFC 793 : Transmission Control Protocol

RFC 1881 : IPv6 Address Allocation Management

RFC 2373 : IP Version 6 Addressing Architecture

RFC 2402 : IP Authentication Header

RFC 2406 : IP Encapsulating Security Payload (ESP)

RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification

RFC 2461 : Neighbor Discovery for IP Version 6 (IPv6)

RFC 3041 : Privacy Extensions for Stateless Address Autoconfiguration in IPv6

RFC 3344 : IP Mobility Support for IPv4

RFC 3513 : Internet Protocol Version 6 (IPv6) Addressing Architecture

RFC 3775 : Mobility Support in IPv6

RFC 3879 : Deprecating Site Local Addresses

Subneting - IP4-IP6

Documents