IPv4 und IPv6 - Informatik 4 - RWTH
Werbung
Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol IPv4 und IPv6 Proseminar: Kommunikationsprotokolle SS 03 Jacob Palczynski Matrikelnummer: 209337 Betreuung: Dirk Thißen Lehrstuhl für Informatik IV, RWTH Aachen Inhaltsverzeichnis 1 Einleitung 1 2 Kommunikation in Netzen 1 2.1 Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 IPv4 3 4 3.1 Paketstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1 Klassenbehaftete Adressierung . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2 Subnetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.3 CIDR – klassenlose Adressierung . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.4 NAT (Network Address Translation ) . . . . . . . . . . . . . . . . . . . . . . 12 Paketfragmentierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 4 IPv6 4.1 4.2 4.3 16 Paketstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.1 Extension Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2.1 Route Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Konversion von IPv4 zu IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5 Kontrollprotokolle 5.1 5.2 21 ICMP (Internet Control Message Protocol ) . . . . . . . . . . . . . . . . . . . . . . 21 5.1.1 ICMPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1.2 ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 ARP (Address Resolution Protocol ) . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6 Zusammenfassung 24 ii 1 Einleitung Die Vernetzung von Computern hat seit ihren Anfängen in den 1960ern bedeutende Fortschritte gemacht und macht diese weiterhin. Seit der Installation des ersten IMP (interface message processor, frühe Bezeichnung für Switches) am 01.09.1969 an der UCLA durch Kleinrock [KUR03] bis zu den heute möglichen mobilen Zugriffen auf das weitgespannte Internet war es ein weiter Weg. Im Zuge dieser Entwicklung entstanden (und verschwanden) viele Konzepte der Kommunikation von Computern untereinander, die wiederum eine Vielzahl an Kommunikationsprotokollen hervorbrachten. Thema dieser Abhandlung sind die Protokolle IPv4 und IPv6 (Internet Protocol version x ), zwei Protokolle, die eine bedeutende Rolle in der Kommunikation in heterogenen Netzen spielen, bzw. spielen sollen. Vor allem IPv4 ist das schnelle und in diesem Maße nicht vorhergesehene Wachstum des Internets zu verdanken. IPv6 soll diese Erfolgsgeschichte in Zukunft weiterführen. In diesem Sinne bietet Kapitel 2 einen Überblick über den aktuellen Stand der Kommunikation in Netzen. Diese wird mit verschiedenen Protokollen realisiert und geregelt, deren Funktionalität durch Schichtenmodelle strukturiert wird. In Kapitel 3 wird das aktuell im Internet vorherrschende IPv4 im Detail vorgestellt. Einen Schwerpunkt dieses Kapitels bildet die Problematik der Verknappung der IP-Adressen und verschiedene Ansätze, diese zu beheben. Sowohl diese Problematik, als auch weitere Schwächen von IPv4, die im Laufe der Zeit hervortraten, führten zur Entwicklung von IPv6, welches in Kapitel 4 behandelt wird. Dieses Protokoll soll mittelfristig seinen Vorgänger IPv4 ablösen. Hier wird unter anderem auch die Konversion von IPv4 zu IPv6 betrachtet. Zwei zusätzliche Protokolle werden in Kapitel 5 vorgestellt. Dies ist zum einen ARP, welches die Übersetzung von Netzwerk- in Ethernetadressen ermöglicht, zum anderen ICMP, das ein Kontrollprotokoll zum Austausch von Statusmeldungen darstellt. Kapitel 6 faßt die gewonnenen Erkenntnisse abschließend zusammen und gibt einen Ausblick auf die weitere Entwicklung. 2 Kommunikation in Netzen Wie die meisten Computernetze ist auch das Internet kein reines Netz von Computern untereinander, sondern stellt ein Netz aus vielen LANs (local area network ) dar. Das heißt, daß viele lokal von unterschiedlichen Organisationen verwaltete Netze durch einige definierte Knoten (Router ) zu einem größeren Netzwerk verbunden werden. Die Verbindung zwischen diesen übernehmen wiederum weitere Router. Die Kommunikation der einzelnen Anwendungen in Computernetzen spielt sich lediglich zwischen den Endsystemen (Hosts ) ab. Das heißt insbesondere, daß die Nichtendsysteme (Router und Switches) nicht für deren Verarbeitung zuständig sind. Dementsprechend sind nur die Hosts für die Verarbeitung der Daten und für ihre Einspeisung ins Netz verantwortlich. Router hingegen kann man als auf die Weiterübermittlung von Informationen spezialisierte Rechner ansehen. Grundlegend ist eine im folgenden beschriebene hierarchische Netztopologie (Abb. 1). Man erkennt die einzelnen LANs, die mittels Routern zum WAN (wide area network ) verbunden sind. Die Router 1 Router / Switch Host Abbildung 1: Hierarchische Netztopologie der höheren Hierarchieebenen sind ihrerseits untereinander teilvermascht. Es läßt sich erkennen, daß es für den problemlosen Betrieb entscheidend ist, daß ein zum Informationsaustausch eingesetztes Protokoll von der Topologie der einzelnen LANs und WANs unabhängig sein muß. Das alles berechtigt durchaus die Bezeichnung Netz der Netze“ für das Internet, wenn auch in einem anderen Sinne ” als üblich. Festzuhalten ist ferner, daß man im Zusammenhang mit Datenübertragung im Internet ein Datagrammnetzwerk1 vorliegen hat. Dieses ist insbesondere paketvermittelt, das heißt, daß die zu übermittelnde Information in Pakete aufgeteilt wird, und diese dann in das Netz eingespeist werden. Für ihre Übermittlung ist es nicht notwendig, eine Leitung zwischen den Hosts zu unterhalten2 , was eine größere Flexibilität und günstigere Auslastung des Netzes ermöglicht. Die Pakete werden dann von Router zu Router weitergereicht. Bei einem Datagrammnetzwerk wird an jedem Knoten des Netzes lediglich anhand der Zieladressinformation, die das Datenpaket liefert, der nächste Empfängerknoten ermittelt. Weitere mögliche Netzarten sind in Abbildung 2 dargestellt, einen kurzen Überblick findet man unter anderem in [KUR03]. Jegliche Kommunikation braucht ein Protokoll, um richtig zu funktionieren. Als Beispiel sei hier die zwischenmenschliche Kommunikation betrachtet. So wird mit der Begrüßung einerseits festgestellt, ob die prinzipielle Bereitschaft zum Gespräch besteht. Ferner einigt man sich auf eine Sprache. Natürlich kann man auch als Mensch anderes kommunizieren. Einen Redner interessiert es am Anfang seiner Rede nicht unbedingt, ob im Publikum die Bereitschaft besteht, ihm zuzuhören. Ähnlich ist die Situation bei der Kommunikation zwischen Rechnern. Es gibt verbindungsorientierte 1 2 im folgenden werden Datagramm und Datenpaket synonym verwendet wie beim Telefonnetz 2 Telekommunikations− netzwerke leitungs− vermittelt FDM TDM paket− vermittelt VC−Netzwerke Datagramm− netzwerke Abbildung 2: Klassifizierung von Telekommunikationsnetzen Protokolle, wie z.B. TCP, bei denen sich Sender und Empfänger wie im ersten Beispiel verhalten. Erst wird der Kontakt zwischen den Partnern hergestellt (handshake ), dann werden die Daten übertragen. Zusätzlich bietet TCP noch Fluß- und Störungskontrolle (s. [RFC793]). Dem gegenüber stehen verbindungslose Protokolle, z.B. UDP (s. [RFC768]), welches diese Kontrollen nicht bietet, aber dadurch schnellere Kommunikation ermöglicht. Bei beiden Versionen von IP handelt es sich um verbindungslose Protokolle. 2.1 Schichtenmodell Um der großen Zahl an Protokollfunktionalitäten und der daraus resultierenden Komplexität der Netzwerkarchitektur Herr zu werden, benutzt man sogenannte Schichtenmodelle; eins davon ist das vierschichtige TCP/IP-Modell in Tabelle 1. Eine einzelne Schicht stellt definierte Dienste die jeweils nächsthöhere Schicht zur Verfügung, ihre Art der Implementierung spielt dabei für die anderen Schichten keine Rolle. Diese Modularität erleichtert es auch, die Implementation der einzelnen Schichten im Zuge der Anpassung an neue Gegebenheiten zu verändern. Schicht Anwendungschicht Transportschicht Internetschicht Host-zu-Netzwerk-Schicht Funktion Unterstützung von Netzwerkanwendungen Client-Server-Kommunikation von Anwendungen globale Adressierung und Routing von Datenpaketen Datenübertragung zwischen benachbarten Rechnern Protokolle HTTP, FTP TCP, UDP IPv4, IPv6 Ethernet, X.25 Tabelle 1: TCP/IP-Schichtenmodell (Protokolle ohne Anspruch auf Vollständigkeit) Beim Versand wandern die Daten durch die Schichten nach unten, jede Schicht verpackt die entgegengenommenen Daten in ein Paket, das Informationen für das jeweilige Protokoll enthält, und reicht dieses dann an die nächste Schicht weiter. Beim Empfang wandern die Daten von unten nach oben, in jeder Schicht werden die Informationen des Pakets ausgewertet, und sein Inhalt diesen entsprechend an ein Protokoll der höheren Schicht weitergereicht. IP bildet den Kern der Internetschicht, deren Komponenten in Abbildung 3 dargestellt sind. Die Transferprotokolle definieren: 3 Transportschicht Routingprotokolle Transferprotokoll Internetschicht Kontrollprotokolle ARP Forwarding−Tabelle Host−zu−Netzwerk−Schicht Abbildung 3: Internetschicht • das Format der Datenpakete, • die globale Adressierung in der Internetschicht, • das Verhalten von Routern und Endsystemen entsprechend der Felder der Datenpakete. Durch die Routingprotokolle wird bestimmt, auf welche Art und Weise der Weg der Datenpakete durch das Netz ermittelt wird. Die Interfaces, durch welche die Pakete den Router verlassen, sind in der Forwarding-Tabelle3 festgehalten. In dieser werden Einträge der Form (this-network, host ) einem Interface zugeordnet, das mit dem eigenen Netz verbunden ist; Einträge der Form (network, 0 ) hingegen gehören zu einem Interface, welches die Verbindung zu dem übergeordneten Netz unterhält. Die dritte Komponente sind Protokolle zur internen Informationsübermittlung in der Internetschicht, insbesondere sind hier Protokolle zur Fehlerbehandlung, Konfiguration, etc. enthalten. Beide IP-Versionen sind Transferprotokolle und werden in den folgenden Kapiteln vorgestellt; eine Vorstellung zweier für IP relevanter Kontrollprotokolle folgt darauf. Routingprotokolle werden bewußt ausgeklammert, da sie den Rahmen dieser Abhandlung sprengen würden4 . 3 IPv4 IPv4 ist das aktuelle Internetschichtprotokoll; seine Aufgaben wurden bereits in Kapitel 2.1 beschrieben. Definiert wurde es bereits im Jahre 1981 in [RFC791]. Daß es heute, nach über 20 Jahren teilweise explosionsartigen Wachstums des Internets, immer noch den Standard darstellt, spricht für die Mächtigkeit dieses Protokolls. Vor allem ermöglichten die Eigenschaften von IPv4 erst dieses Wachstum, denn im Gegensatz zu der wachsenden Anzahl der Protokolle der Anwendungs- und Transportschicht, die nur auf den Endsystemen laufen, erfordert ein Wechsel des Internetschichtprotokolls zusätzlich die Aktualisierung der Router. 3 4 auch: Routingtabelle Ferner bilden sie im Rahmen dieses Proseminars ein eigenes Thema. 4 3.1 Paketstruktur Die Struktur des Datenpakets ist in Abbildung 4 dargestellt. Es besteht aus einem Header und seiner Existenzberechtigung: den Daten, die es von der Transportschicht erhalten hat (Payload ). Der Header hat eine Länge, die zwischen 20 und 60 Byte liegt, davon entfallen bis zu 40 Byte auf das OptionsFeld. Die Länge der Nutzdaten ist in gewissen Grenzen variabel, sie wird unter anderem durch die Paketgröße des Transportschichtprotokolls bestimmt. 32 bit Version 8 8 IHL Type of Service Identification Time to Live Flags Protocol Source Address Destination Address 8 Total Length Fragment Offset Header Checksum Header 8 Options (optional) Payload Abbildung 4: Struktur des IPv4-Datenpakets Der Header besteht aus folgenden Feldern (s.a. [RFC791] und [TAN03]): Version (4 bit): Dieses Feld hält nach, welcher IP-Version (hier: 4) das Datenpaket zugeordnet ist. Dieses Feld ermöglicht unter anderem einen gleitenden Übergang zwischen Protokollversionen (s.a. 4.3). IHL (4 bit): Die Internet Header Length gibt die Länge des Headers in 4-Byte-Worten an. Der minimale Wert beträgt 5 (keine Optionen), der maximale 15. Die daraus resultierende Beschränkung des Option-Felds auf 40 Bytes macht mittlerweile manche Optionen, z.B. Aufzeichnung der Route des Pakets, unbrauchbar. Type of Service (8 bit) dient zur Unterscheidung der verschiedenen Classes of Service, die unterschiedliche Ansprüche an Verzögerung, Durchsatz und Zuverlässigkeit stellen. Dieses Feld ist aus dem 3-Bit-Feld Precedence, welches die Priorität des Pakets von 0 (Routine) bis 7 (Netzwerkkontrolle) angibt, und den drei Flags Delay, Throughput und Reliability aufgebaut. Mit den Flags werden die Anforderungen an die Übertragungsgüte angegeben. Die letzten zwei Bits waren für kommende Zwecke reserviert. Aktuell wird dieses Feld überwiegend für experimentelle Zwecke eingesetzt, bei denen alternative Konzepte zur Servicequalität im Internet untersucht werden. Total Length (16 bit) gibt die Gesamtlänge5 des Datenpakets in Bytes an (maximal 64 kByte). Dieses Feld ist zusätzlich zur IHL notwendig, da die Längen sowohl des Headers, als auch der Nutzlast variabel sind. 5 Header und Payload 5 Identification (16 bit), Flags (3 bit), Fragment Offset (13 bit) dienen der Fragmentverwaltung und werden in 3.3 vorgestellt. Time to Live (8 bit): Ursprünglich war hier die verbleibende Lebenszeit des Datenpakets in Sekunden angegeben; mittlerweile wird der Wert von jedem Knoten beim Weiterreichen einmal dekrementiert. Erreicht dieses Feld den Wert 0, wird das Paket verworfen und eine Fehlermeldung an den sendenden Host gesandt (s.a. 5.1). Der Sinn dieses Feldes liegt darin, zu verhindern, daß Pakete unter Umständen ewig im Netz herumwandern. Protocol (8 bit) beschreibt das Transportschichtprotokoll, an das die Daten beim Empfänger weitergegeben werden sollen. Die Nummern werden von der IANA (Internet Assigned Numbers Authority ) verwaltet [IANAprot]. Header Checksum (16 bit) ist eine Kontrollsumme, um von Routern verursachte Fehler zu entdecken. Die ankommenden 16-Bit-Wörter des Pakets werden im 1-Komplement aufsummiert, vom Ergebnis wiederum das 1-Komplement gebildet. Stimmt der berchnete Wert nicht mit dem übertragenen überein, so wird das Paket verworfen. Zu beachten ist, daß jeder Router diese Summe neu berechnen muß, da sich das Time-to-Live-Feld verändert. Source Address (32 bit): Senderadresse (s. 3.2). Destination Address (32 bit): Empfängeradresse (s. 3.2). Options (0 bis 320 bit): Ursprünglich waren die in Tabelle 2 angegebenen Optionen vorgesehen. Mittlerweile wurden weitere definiert, die Liste wird von der IANA verwaltet [IANAip]. Option Security Strict source routing Loose source routing Record route Timestamp Beschreibung Spezifiziert die Geheimhaltungsstufe das Pakets (wird ignoriert) Sequenz von IP-Adressen, die exakt eingehalten werden muß Reihenfolge mindestens zu besuchender IP-Adressen Jeder besuchte Router fügt seine Adresse an wie Record route, zusätzlich wird ein 32-Bit-Timestamp angefügt Tabelle 2: Ursprüngliche IPv4-Optionen 3.2 Adressen Wie in 3.1 erwähnt sind IPv4-Adressen 32 bit lang, d.h. der Adressraum umfaßt insgesamt 232 = 4294967296 Adressen. Angesichts der Tatsache, daß diese nicht jeweils für ein System (Host, Router) zugeteilt werden, sondern jedes Interface zwischen dem System und einem Netz6 eine Adresse benötigt, werden die Grenzen des Wachstums auf der Basis von IPv4 deutlich. Erschwerend kommen weitere Beschränkungen der ursprünglichen Definition hinzu, die man später versuchte zu umgehen. Dies wird im weiteren Verlauf dieses Kapitels diskutiert. Viele Beispiele zu diesen Themen finden sich in [SEM96], einer umgfangreichen Darstellung der IP-Adressierung. 6 Router haben notwendigerweise mehrere Interfaces, da sie zwischen Netzen kommunizieren 6 Um die Lesbarkeit für Menschen zu erhöhen, werden IPv4-Adressen oft nicht in binärer Form geschrieben, sondern als vier durch Punkte getrennte Dezimalzahlen (dotted-decimal notation ). Dabei wird jedes Byte durch den entsprechenden Wert ersetzt (Beispiel s. Tab. 3). 11000001.00100000.11011000.00001001 193 . 32 . 216 . 9 Tabelle 3: Beispiel für die Darstellung von IPv4-Adressen Die Adressen werden zentral von der ICANN (Internet Corporation for Assigned Names and Numbers ) verwaltet, die diese an einzelne ISPs (Internet Service Provider ) verteilt. Ein System, das an ein Netz angeschlossen wird, erhält seine Adresse auf eine von zwei Arten: • Manuelle Konfiguration. Der ISP vergibt eine feste Adresse aus dem ihm verfügbaren Adressraum, die vom Administrator manuell eingepflegt wird. • DHCP (Dynamic Host Configuration Protocol ) [RFC2131]. Der ISP betreibt einen DHCPServer, durch den die Host-Konfiguration automatisch erfolgt. Aufgrund der großen Gesamtzahl von Endnutzern werden die Adressräume der ISPs meist dynamisch verwaltet, d.h. die Adressen werden nur temporär zugeteilt. Dies wird dadurch ermöglicht, daß bislang wenige Nutzer eine IP-Adresse auf einmal benötigten, und diese dann nur für kurze Zeit. Dies hat den Vorteil für den ISP, daß er mit einem deutlich kleineren Adressraum seine Kunden bedienen kann. Durch die fortschreitende Verbreitung von Breitbandzugängen mit Flatrates, bzw. Volumentarifen ändert sich das Kundenverhalten hin zum ständigen Verbundensein mit dem Internet, wodurch diese Praxis der ISPs nicht mehr lange durchführbar sein wird. 3.2.1 Klassenbehaftete Adressierung Eine IPv4-Adresse ist unterteilt in Netzwerkpräfix und Hostnummer; alle Hosts in einem Netz haben den gleichen Präfix, der somit das Netz identifiziert. Der IPv4-Adressraum ist in fünf Klassen aufgeteilt, um unterschiedlich große Netze zu ermöglichen. Realisiert wird das durch die Definition von verschieden Netzwerkpräfixlängen, die durch die ersten Stellen der Adresse kodiert sind (Abb. 5). Die Klassifizierung erleichterte in den frühen Jahren das Routing, da die ersten Router so die Präfixlänge feststellen konnten. In jedem Netz sind zwei Adressen für besondere Zwecke reserviert. Zum einen die Hostnummer, die nur aus Nullen besteht; sie steht für das Netzwerk selbst. Zum anderen die, die nur aus Einsen besteht: eine Broadcast-Adresse, mit der jeder Host im Netz erreicht wird. Klasse A: Eine Adresse der Klasse A besteht aus einer führenden 0, gefolgt von einer 7 bit langen Netznummer. Aus diesem Grund spricht man auch von /8-Netzen. Da die Adressen 0.0.0.0 und 127.0.0.0 reserviert sind (für Standardroute und Loopback), ergibt sich somit die maximale Anzahl von /8-Netzen zu 27 − 2 = 126. Da die Hostnummer drei Bytes lang ist, kann somit jedes /8-Netz 224 − 2 = 16777214 Hosts 7 8 bit Klasse A 0 8 bit 8 bit Netzwerk B 10 C 110 8 bit Host Netzwerk Host Netzwerk Host D 1110 Multicasting Adresse E 1111 reserviert Abbildung 5: IPv4-Adressklassen enthalten. Der /8-Adressblock enthält 231 = 2147483648 Adressen und somit die Hälfte aller IPv4Adressen. Klasse B: Im Unterschied zur Klasse A besteht der Netzpräfix einer Adresse aus diesem Adressblock aus einem 01, gefolgt von der 14 bit langen Netznummer; analog zum oben dargestellten Fall spricht man von /16-Netzen. Es können somit 214 = 16384 Netze definiert werden. Jedes davon kann maximal 216 − 2 = 65534 Hosts enthalten. Der /16-Block belegt somit ein Viertel aller IPv4-Adressen (230 = 107371824 Adressen). Klasse C: Adressen der Klasse C werden auch /24-Adressen genannt, da sie nach einem 110 eine 21 bit lange Netznummer haben. Somit können 221 = 2097152 Netze adressiert werden, die dann allerdings nur 28 − 2 = 254 Hosts enthalten können. /24-Adressen belegen somit ein Achtel des IPv4-Adressraums. Klassen D und E: Die Klassen D und E sind spezielle Klassen. D dient dem Multicasting, d.h. dem Versand eines Datenpakets an eine Gruppe von Hosts, E war für experimentelle Zwecke reserviert. Beide Klassen belegen jeweils ein Sechszehntel aller Adressen. Auch wenn diese Unterteilung in Klassen anfangs nützlich war, da sie einfach zu verstehen und zu implementieren war, so führte sie zu einer ineffizienten Belegung des IPv4-Adressraums. Ein Grund dafür ist das Fehlen einer Klasse für mittlere Netze. So sind die vielen /24-Netze mit 254 Hosts zu klein, um ein Netz zu unterhalten, das eventuell auf mehrere hundert Hosts anwachsen könnte. In der Vergangenheit wurden dafür /16-Blöcke beantragt, die wiederum völlig überdimensioniert sind. Da man damals allerdings nicht mit einem solch starken Wachstum des Internets gerechnet hat und der Adressraum beinahe unerschöpflich schien, wurden diese Blöcke auch zugeteilt, die dann zu einem großen Teil brachlagen. Später ist man dazu übergegangen, für mittlere Netze mehrere /24-Blöcke zuzuteilen, was aber zu einem starken Wachstum der Routing-Tabellen führte. Die Folgen dieser Praxis wurden unter anderem durch die ARIN (American Registry for Internet Numbers ) 1996 dokumentiert [ARIN96]. So waren zu dem Zeitpunkt bereits alle /8-, 62% der /16-, sowie 37% der /24-Adressen vergeben. 8 3.2.2 Subnetting 1985 wurde in [RFC950] Subnetting definiert. Es ermöglicht den zu einer Netzwerknummer gehörenden Adressraum in mehrere kleinere Teile aufzuteilen. Damit sollte vor allem zwei Problemen im wachsenden Internet begegnet werden: • Anwachsen der Routing-Tabellen. • Administratoren lokaler Netze mußten eine weitere Netznummer beantragen, bevor sie ein neues Netzwerk zu ihrem Netz anfügen konnten. Um diese Probleme zu entschärfen, wurde die in 3.2.1 beschriebene 2-Ebenen- zu einer 3-EbenenHierarchie verfeinert, in der die Hostnummer in einen Subnet- und einen Hostteil aufgeteilt wurde (s. Abb.6). Dabei werden Netzwerkpräfix und Subnetnummer zum erweiterten Netzwerkpräfix zusammengefaßt. Internetrouter verwenden weiterhin nur den normalen Netzwerkpräfix, während die internen Router des unterteilten Netzes den erweiterten nutzen, um Datenpakete weiterzuleiten. Netzwerkpräfix Netzwerkpräfix Hostnummer Subnetnummer Hostnummer Abbildung 6: Adressenhierarchie mit Subnetting Durch Subnetting wird die Struktur eines lokalen Netzes für die Aussenwelt verborgen, alle Unternetze sind über den Netzwerkpräfix erreichbar. Damit werden beide oben erwähnten Probleme eingedämmt, denn der Administrator eines lokalen Netzes kann die Komplexität und Struktur des selbigen verändern, ohne weitere Netznummern beantragen zu müssen. Dadurch tauchen die Unternetze auch nicht in den Routingtabellen im WAN auf, die Effizienz des Routings wird nicht vermindert. Ein weiterer Vorteil des Subnettings ist, daß Veränderungen der Routen innerhalb des lokalen Netzes zwischen den Unternetzen nicht mehr an die Router im Internet weitergegeben werden müssen, und so der Verwaltungsaufwand gering gehalten wird. Die Routingtabellen im LAN verändern sich ebenfalls; es kommen Einträge der Form (this-network, subnet, 0 ) und (this-network, this-subnet, host ) hinzu, die die (this-network, host ) ersetzen. Damit wird auch im LAN die Anzahl der Einträge verringert. Ein grundlegendes Beispiel für Subnetting findet man in Abb. 7: ein Router, der unter der /16-Adresse 130.5.0.0 für das Internet sichtbar ist, verwaltet mehrere Unternetze. Feste Subnetmaskenlänge Die Länge des erweiterten Netzwerkpräfix wird im Allgemeinen durch die Subnetmaske angegeben. Diese ist wie die IPv4-Adresse 32 bit lang, enthält aber an den Stellen, die in der Adresse dem erweiterten Netzwerkpräfix entsprechen, eine 1, sonst eine 0. Demnach entspricht einem 22 bit langen Präfix die Subnetmaske 255.255.252.0, der Maske 255.255.255.64 ein 25 bit langer Präfix. Aus diesem Grund findet man oft die Schreibweise [IPv4-Adresse]/[Länge des 9 Internet 130.5.0.0 130.5.32.0 130.5.64.0 130.5.96.0 130.5.128.0 130.5.160.0 130.5.192.0 130.5.224.0 Abbildung 7: Beispiel für Subnetting Präfix] (z.B. 130.5.5.25/24). Man sollte sich bei dieser Vereinfachung aber immer vor Augen halten, daß in den Routingtabellen immer die komplette Maske abgespeichert wird. Alte Routingprotokolle wie RIP-1 [RFC1058] lassen, da sie in ihren Aktualisierungsbenachrichtigungen keine Informationen über die Subnetzmaske übertragen konnten, nur eine Subnetzmaske pro Netzwerknummer zu. Router, die sich dieser Protokolle bedienen, wenden nur ihre eigene Maske auf neu erlernte Routen an. Damit kann der Administrator seinen Block nur in gleich grosse Teile zerlegen. Variable Subnetmaskenlänge 1987 wurde in [RFC1009] mit VLSM (Variable Length Subnet Masks ) unter anderem spezifiziert, wie mehrere Subnetmasken in einem Netz verwendet werden können. Die Vorteile der Zuweisung mehrerer Subnetmasken zu einer Netzwerknummer liegen auf der Hand: Effizientere Nutzung des verfügbaren Adressraums Die Subnetze können besser an die Erfordernisse angepaßt werden. Hat der Administrator die voraussichtlichen Größen der Netze abgeschätzt, kann er die Masken so wählen, daß die jeweilige maximale Anzahl der Hosts der nächstgrößeren Zweierpotenz entspricht. Route Aggregation Bei einem rekursiven Aufbau des Netzes trägt Route Aggregation dazu bei, die Routingtabellen weiter zu verkleinern. In einem rekursiven Aufbau eines Netzes werden Subnetze nach Bedarf wiederum in Subsubnetze aufgeteilt, usw.. Routen in ein Netz einer tieferen Ebene werden dann zusammengefaßt und zu dem übergeordneten Router geleitet. Ein Beispiel dazu findet sich in Abbildung 8. Dafür müssen allerdings drei Voraussetzungen erfüllt sein: 1. Die Routingprotokolle müssen den erweiterten Netzwerkpräfix bei der Bekanntmachung von Routen mitübertragen. 2. Alle Router müssen einen Algorithmus nutzen, der auf dem longest match basiert, das heißt, daß Pakete an den Router weitergegeben werden, dessen Adresse die längste Übereinstimmung mit der Zieladresse hat. Passiert dies nicht, können Pakete an falsche Subnetze weitergegeben werden. 10 23.2.0.0/16 23.3.0.0/16 23.1.1.0/24 23.1.2.0/24 23.0.0.0/8 23.1.0.0/16 23.254.0.0/16 23.1.254.0/24 Internet 23.53.0.0/16 23.53.32.0/19 23.53.64.0/19 23.53.192.0/19 23.1.253.0/24 23.1.253.32/27 23.1.253.64/27 23.1.253.96/27 23.1.253.128/27 23.1.253.160/27 23.1.253.192/27 Abbildung 8: Beispiel VLSM 3. Die Adressenverteilung muß der Netztopologie entsprechen. Sind Adressen von Hosts wahllos über das Netz verteilt, können diese in den Routingtabellen nicht zusammengefasst werden. 3.2.3 CIDR – klassenlose Adressierung Wie schon in 3.2.1 angedeutet, warf die klassenbehaftete Adressierung Probleme auf, die bereits Anfang der 1990er erkennbar waren: • der kurzfristig zu erwartende Verbrauch des gesamten /16-Adressraums, • das starke Wachstum der Anzahl der Einträge in den Routingtabellen, • der eventuelle Verbrauch des gesamten IPv4-Adressraums. Während letzteres eher auf lange Sicht zu erwarten war, mussten die beiden anderen Probleme schnell angegangen werden. Dies geschah 1993 mit der Entwicklung von CIDR7 (Classless Inter-Domain Routing ), welches in [RFC1517] bis [RFC1520] definiert wurde. Zwei wichtige Merkmale, von denen das Internetrouting profitiert, sind: 1. Das Konzept der drei Klassen wird verworfen. 2. Route Aggregation wird eingeführt. 7 ausgesprochen: cider (engl. Apfelwein) 11 In CIDR wird ein verallgemeinertes Konzept des Netzwerkpräfix eingeführt. Statt die Länge des Präfix durch die ersten Bits der Adresse zu ermitteln, wird diese durch eine Bitmaske der Länge 32 dargestellt, die in den Routinginformationen mitgeführt wird. Somit sind beliebige Präfixlängen möglich und die Vergabe von Adressen ist flexibler. Das Konzept erinnert stark an VLSM, denn auch bei CIDR können mehrere Netzmasken verwaltet werden und die Anforderungen an Routing und Adressvergabe sind die gleichen. Der entscheidende Unterschied ist, daß VLSM in schon vergebenem privaten Adressraum angewandt wird und so für das restliche Internet nicht sichtbar ist. CIDR dagegen erlaubt die rekursive Vergabe von Adressraum an ISPs aller Ebenen und auch an private Netze; die Auswirkungen sind somit auch im Internet nachvollziehbar. Durch den Wechsel von Kunden mit ihren Netzen zu anderen Providern kann allerdings Route Aggregation unterminiert werden, falls der Kunde nicht alle seine Adressen an die des neuen Providers anpassen will. Damit die Pakete immer noch bei dem Kunden ankommen, muß der Provider dessen Netzwerkpräfix bekannt machen, da er nicht zu seinem eigenen passt. Würde dies nicht geschehen, kämen diese Pakete immer noch beim alten Provider an. Als Resultat ergibt sich ein erneutes Anwachsen der Routingtabellen (s. Abb. 9). 200.25.0.0/16 13.15.28.0/23 ISP 2 Internet 13.15.28.0/23 Kunde 3 13.15.0.0/16 ISP 1 13.15.24.0/22 13.15.16.0/21 Kunde 2 Kunde 1 Abbildung 9: Providerwechsel bei CIDR 3.2.4 NAT (Network Address Translation ) Mit [RFC1918] wurden die Adressen mit folgenden Präfixen zur privaten Benutzung freigestellt: • 10/8 • 176.16/12 • 192.168/16 Innerhalb dieser Blocks können private Netze, die nicht in direkter Verbindung zum Internet stehen, aufgebaut werden, ohne daß eine Registrierung beantragt werden muss. Diese Adressblöcke werden 12 daher im Internet auch nicht geroutet. Eine Möglichkeit, diese Netze an das Internet anzubinden, ist NAT [RFC3022]. Grundsätzlich handelt es sich dabei um eine Abbildung des privaten auf den öffentlichen Adressraum. Somit kann NAT auch das in 3.2.3 angesprochene Problem beim Providerwechsel mindern. Voraussetzung für die Nutzung von NAT ist, daß alle Router des betreffenden Netzes, die mit dem Internet verbunden sind, diese Abbildung in eindeutiger Weise vornehemen. Traditonal NAT bietet dazu zwei Möglichkeiten: Basic NAT nimmt die Abbildung eins-zu-eins vor. Der Router übersetzt dabei die private Adresse in eine zugeteilte öffentliche, indem er die Adresse im IP-Header ändert; bei ausgehenden Paketen die Source, bei eingehenden die Destination Address (Abb. 10). Internet S=198.153.58.90 D=198.76.28.4 S=198.153.58.90 D=198.76.28.4 NAT−Router NAT−Router S=10.33.124.3 D=198.76.28.4 S=198.153.58.90 D=176.16.24.89 10.33.124.3 176.16.24.89 Abbildung 10: Basic NAT Der verfügbare Adressraum begrenzt dabei die Anzahl der Hosts im LAN, die mit dem WAN kommunizieren dürfen. Diese Implementation bietet sich somit für grössere Firmen, etc. an. NAPT Network Adress Port Translation ist die vor allem bei kleinen Netzen, die nur eine öffentliche IP-Adresse zugewiesen bekommen haben, verbreitete NAT-Version. Dabei macht man sich zu Nutze, daß der grösste Teil der Kommunikation über TCP/UDP läuft. Unter dieser Annahme wird die private Adresse des Hosts samt TCP-Port8 der laufenden Anwendung auf die öffentliche Adresse und einen ungenutzten Port abgebildet (Abb. 11). S=(198.76.28.4, 23) D=(198.153.58.90, 1024) S=(198.76.28.4, 23) D=(10.33.124.3, 3017) 10.33.124.3 NAPT−Router Internet S=(198.153.58.90, 1024) D=(198.76.28.4, 23) S=(10.33.124.3, 3017) D=(198.76.28.4, 23) Abbildung 11: NATP, die IP-Adresse des Routers ist 198.153.58.90 Der Router nutzt also die TCP-Ports, um die Kommunikation der einzelnen Hosts zu unterscheiden, die nach außen nur über eine IP-Adresse läuft. Vor allem muss der Router seine eigene TCP/UDP-Kommunikation von der der Hosts trennen. Auch wenn NAT eine breite Anwendung vor allem in privaten Heimnetzen gefunden hat, so ist dieses Konzept nicht unumstritten. Die Vorteile von NAT sind unter anderem: 8 Die 16-bittigen Portnummern werden von der IANA nachgehalten [IANAtcp] 13 • Der Verbrauch von IP-Adressen wird verringert. • Bei einem Wechsel der zugewiesenen IP-Adresse(n), z.B. bei Einwahlverbindungen, müssen die Adressen des LAN nicht geändert werden. • Öffentliche IP-Adressen können wiederverwendet werden für Kunden mit nicht ständigen Zugängen. Die Grösse der Nachfrage nach Adressen bestimmt sich aus der Anzahl der aktiven Knoten und nicht mehr aus der Gesamtzahl aller Knoten. • NAT-verwaltete Netze müssen nicht bei den Registrierungsbehörden beantragt werden. • Durch den Einsatz von NAT können Administratoren auf kompliziertere Routingtechniken wie VLSM in ihren LANs verzichten. Allerdings ergeben sich auch Nachteile, wie zum Beispiel: • Da NAT-Router selbst TCP-Header verändern, findet die Kommunikation nicht mehr zwischen den Endsystemen statt. • Die ursprügliche Eindeutigkeit der IP-Adressen ist nicht mehr gegeben. Problematisch kann das bei VPN9 werden, da dann Adresskonflikte auftreten können. • Die Kommunikation ist nicht mehr verbindungslos. Der NAT-Router muß nachhalten, welche Adresse wie abgebildet wurde, im Falle eines wie auch immer verursachten Verlustes dieser Informationen werden alle TCP-Verbindungen unterbrochen. • Die Modularität des Schichtenmodells wird verletzt, da Annahmen über eine höhere Schicht gemacht werden. NAT-Router würden unbrauchbar, falls sich ein momentan hypothetisches Protokoll TCP-2 mit einer 32-bittigen Portnummer durchsetzen würde. • Anwendungen, die weder TCP noch UDP nutzen, können NAT nicht verwenden.10 • Die zügige Konversion zu IPv6 wird verhindert. Eine tiefer- und weitergehende Diskussion der durch NAT implizierten Folgen findet sich in [RFC2993]. 3.3 Paketfragmentierung Die verschiedenen Protokolle der Verbindungsschicht übertragen Pakete unterschiedlicher Größe, z.B. dürfen Ethernetpakete die Grenze von 1500 Bytes nicht überschreiten, während viele der WANVerbindungen nicht mehr als 576 Bytes übertragen [KUR03]. Das Maximum wird in der Grösse MTU (Maximum Transfer Unit ) angegeben. IP-Pakete werden zur Übertragung noch in einen Rahmen des Verbindungsschichtprotokolls eingebettet, so daß die MTU die Grösse des IP-Pakets eher einschränkt als das Headerfeld Total Length. 9 10 Virtual Private Network Aktuell ist das ein theoretischer Einwand, da alle gängigen Anwendungen TCP/UDP benutzen. 14 Das ist eigentlich kein Problem, da der Host dann die Pakete so gross machen kann, daß sie die MTU des Protokolls des eigenen Interfaces nicht überschreiten. Allerdings können diese Protokolle auf dem Weg zum Ziel durchaus wechseln und die MTU sich verringern. Aus diesem Grund wurde bei der Entwicklung von IPv4 vorgesehen, daß Datenpakete fragmentiert werden können und so ihre Größe an die MTU der nächsten Verbindung angepasst werden kann. Um den Aufwand so gering wie möglich zu halten, ist für Router nur eine Aufteilung in kleinere Fragmente vorgesehen, das Zusammensetzen übernimmt das Empfängersystem. Dieses muß auch durch IPv4 erledigt werden, da zum Beispiel TCP vollständige Pakete erwartet. Wie in 3.1 erwähnt, sind mehrere Headerfelder für die Fragmentverwaltung verantwortlich. Da es sich bei IPv4 um ein unsicheres Protokoll handelt, sind diese auch notwendig, um sicherzustellen, daß das IP-Paket korrekt zusammengesetzt oder gegebenenfalls verworfen wird: Identification ordnet im Falle einer auftretenden Fragmentierung (3.3) die einzelnen Fragmente dem jeweiligen Datenpaket zu. Alle Fragmente des selben Pakets haben hier den gleichen Wert eingetragen. Flags werden für die Handhabung der Fragmentierung gebraucht: Bit 0: nicht genutzt, auf 0 gesetzt. Bit 1, DF (Don’t Fragment ): wird vom Sender gesetzt, wenn das Paket nicht fragmentiert werden darf. Bit 2, MF (More Fragments ): wird vom Router, der das Paket fragmentiert, gesetzt, wenn weitere Fragmente folgen. Beim letzten Fragment 0. Fragment Offset stellt eine Ordnung auf den Fragmenten eines Pakets dar und weist jedem seinen Platz im Paket zu. Ferner kann festgestellt werden, ob das Paket komplett ist. Einheit des Werts ist ein 64-Bit-Wort. Ein Beispiel für die Belegung dieser Felder ist in Tabelle 4 zu finden. Fragment-Nr. 1 2 3 Payload [Byte] 1472 1472 1036 ID 777 777 777 MF 1 1 0 Offset 0 23 46 Tabelle 4: Fregmentierung eines 4000 Byte grossen IPv4-Pakets mit ID=777 und MTU=1500 4 IPv6 Mit CIDR wurde erreicht, daß der IPv4-Adressraum effizient genutzt werden kann, NAT zögert die komplette Belegung aller Adressen hinaus. Angesichts der Probleme, die NAT impliziert und der Aussicht, daß immer mehr Geräte – nicht nur Computer im engeren Sinn, sondern auch Telefone, 15 etc. – einen Anschluss an das Internet haben sollen, wurde die Notwendigkeit erkannt, IPv4 durch ein mächtigeres Protokoll zu ersetzen. In den frühen 1990ern begann die Entwicklung des IPv4Nachfolgers (damals noch unter der Bezeichnung IPng) unter folgenden wichtigsten Vorgaben der IETF (Internet Engineering Task Force ) [TAN03], [RFC1550]: 1. Unterstützung von Milliarden von Hosts, selbst bei ungünstiger Adressraumbelegung, 2. Verkleinerung der Routingtabellen, 3. Simplifizierung des Protokolls, um die Pakete schneller durch die Router bearbeiten zu können, 4. Verbesserung der Sicherheit, 5. Type of Service soll höhere Bedeutung erhalten, vor allem in Bezug auf Echtzeitübertragung, 6. Unterstützung von Multicasting durch die Spezifikation von Bereichen, 7. Roaming von Hosts ohne Änderung der Adresse, 8. Erweiterbarkeit des Protokolls, 9. Koexistenz des alten und neuen Protokolls für eine Übergangszeit. Nach einem längerem Auswahlverfahren wurde schließlich SIPP11 als IPv6 eingeführt; definiert ist es in [RFC2460] bis [RFC2466]. 4.1 Paketstruktur Analog zu IPv4 besteht auch ein IPv6-Paket (Abb. 12) aus Header und Payload. Die wichtigsten Änderungen sind: Erweiterte Adressierungsmöglichkeiten: Durch Vervierfachung der Adresslänge wurde der Adressraum auf das 296 -fache vergrössert und umfasst nun 2128 ≈ 3.4 · 1038 Adressen. Würde man alle Adressen auf die gesamte Erdoberfläche verteilen, erhielte man eine Adressdichte von 7 · 1023 m−2 . Selbst bei ungünstigsten Szenarien der Adressverteilung ergeben sich noch Dichten von über 1000 m−2 [RFC3194]. Ferner wurden zu den bereits bekannten Unicast- und Multicast- noch zusätzlich AnycastAdressen eingeführt. Mit ihnen ist es möglich, Pakete an den nahesten12 Host aus einer Gruppe zu schicken. Rationalisierter Header: Der Header hat nun die feste Länge von 40 Byte mit weniger Feldern, so daß eine effizientere Bearbeitung ermöglicht wird. Die neue Optionendarstellung ist flexibler gestaltet. Flows und Prioritäten: Es ist möglich, sogenannte Flows zu kennzeichnen und zu handhaben; dieses soll z.B. der Audio- und Videoübertragung und anderen Echtzeitanwendungen zugute kommen. Allerdings ist die Bedeutung des Begriffes Flow noch nicht definiert. 16 32 bit Version 8 8 Traffic Class Payload Length Flow Label Next Header 8 Hop Limit Source Address Header 8 Destination Address Payload Abbildung 12: Struktur eines IPv6-Datenpakets Die Felder im einzelnen [RFC2460]: Version (4 bit): Versionsnummer, hier 6. Traffic Class (8 bit) entspricht dem IPv4-Feld Type of Service, bislang experimentelle Nutzung. Flow Label (20 bit) soll Flows kennzeichnen, bislang Gegenstand von Experimenten. Payload Length (16 bit): Länge der Nutzdaten in Bytes. Der Header ist, da er ohnehin feste Länge hat, ausgenommen. Next Header (8 bit) entspricht dem IPv4-Feld Protocol, die Werte sind in [IANAprot] einzusehen. Zusätzlich werden hier Extension Header zur Angabe von Optionen gekennzeichnet, die in 4.1.1 besprochen werden. Hop Limit (8 bit) entspricht dem IPv4-Feld Time to Live, wird schon per Definition per hop dekrementiert. Source Address (128 bit): Senderadresse. Destination Address (128 bit): Empfängeradresse (nicht unbedingt die des endgültigen Empfängers, siehe auch 4.1.1). Wie man sieht, ist ein Teil der Felder des IPv4-Headers, teilweise unter anderem Namen, erhalten geblieben. Dafür sind alle die Fragmentierung betreffenden Felder entfallen, da dieses nun in den Exension Headern gehandhabt wird, was auch für die Optionen gilt. Die Prüfsumme ist für überflüssig befunden worden, da einerseits die Netze zuverlässiger sind, zum anderen sowohl Transport- als auch Verbindungsschichtprotokolle eine eigene mitführen. 11 12 Simple Internet Protocol Plus bez. des Routingprotokolls 17 4.1.1 Extension Header Die Extension Header (Tab. 5) übernehmen Aufgaben, die früher von IPv4-Headerfeldern übernommen wurden, zum Teil mit deutlich erweiterten Möglichkeiten. Sie können in beliebiger Anzahl vor den eigentlichen Nutzdaten auftreten und müssen in der Reihenfolge, in der sie auftreten, abgearbeitet werden. Das jeweilige Next-Header-Feld aller Header, bis auf das des letzten, bezeichnet die Art des folgenden Headers, das des letzten kennzeichnet das Transportschichtprotokoll der ihm folgenden Nutzdaten. Extension Header Hop-by-Hop Options Destination Options Routing Fragment Authentication Encapsulating Security Payload Beschreibung diverse Informationen für Router zusätzliche Informationen für ein Ziel Liste von zu besuchenden Routern Fragmentverwaltung Verfikation der Senderidentität Informationen über verschlüsselte Inhalte Tabelle 5: Arten von Extension Headern Das gestattet eine flexible Gestaltung des Pfades und ermöglicht es, auch zwischendurch auftretenden Routern Informationen zukommen zu lassen. Hop-by-Hop Options enthält Informationen und Anweisungen für alle Router, die auf dem Pfad liegen. Destination Options werden vom im Feld Destination Address und allen folgenden Knoten verarbeitet. Routing enthält eine Liste von Knoten, die mindestens durchlaufen werden müssen. Hierüber bieten sich verschiedene Möglichkeiten, u.a. auch das Roaming bei Beibehaltung einer festen IPAdresse [HIN95]. Fragment verwaltet die Fragmentierung von Paketen ähnlich wie es schon in IPv4 gemacht wurde. Allerdings werden die Pakete nicht mehr von den Routern aufgeteilt, sondern vom Sender selbst. Ist ein Paket, beziehungsweise ein Fragment, zu groß, um weitergeleitet zu werden, so verwirft es der entsprechende Router und sendet dem Sender ein Kontrollprotokollpaket. Dieser zerteilt es dann und sendet erneut. Authentication und Encapsulating Security Payload stellen Sicherheitstechniken gemäß [RFC2401] zur Verfügung. 4.2 Adressen Noch nötiger als bei IPv4 ist bei IPv6 eine nichtbinäre Darstellung der 128-bittigen Adressen. Um beide zu unterscheiden, wurde nicht die Dotted-Decimal Notation gewählt. Statt dessen stehen drei Schreibweisen zur Verfügung: 18 preferred : X:X:X:X:X:X:X:X, jedes X repräsentiert eine vierstellige Hexadezimalzahl, getrennt werden diese durch einen Doppelpunkt (Tab. 6). binär preferred : : : : : 0000 : 7654 : 3210 : FEDC : BA98 : 7654 : : 3210 : : 003C 0000000000000000 0111011001010100 0011001000010000 1111111011011100 1011101010011000 0111011001010100 0011001000010000 0000000000111100 Tabelle 6: Beispiel für preferred Schreibweise compressed : Aus der preferred-Schreibweise dürfen in folgenden Fällen Nullen weggelassen werden: 1. führende Nullen in einer vierstelligen Zahl 2. genau ein Mal dürfen beliebig viele hintereinander stehende Viererblöcke durch einen zusätzlichen Doppelpunkt ersetzt werden mixed : X:X:X:X:X:X:D.D.D.D, wird in gemischten IPv4/IPv6-Umgebungen benutzt, die letzten 4 Bytes der Adresse werden in der Dotted-Decimal Notation dargestellt Da es drei Arten von Adressen (Unicast, Multicast und Anycast) gibt, und die Unicast-Adressen noch weiter aufgeteilt sind, ist auch der IPv6-Adressraum nicht beliebig belegbar [RFC2373]. Allerdings entsprechen die Adressierungsregeln keinesfalls denen des klassenbehafteten Verfahrens bei IPv4 (3.2.1). Ähnlich wie bei CIDR (3.2.3) wird in IPv6 der Netzwerkpräfix mittels einer Maske nachgehalten, die Schreibweise ist äquivalent. Die Konfiguration eines Interfaces wird bei IPv6 entweder über DHCP vorgenommen, oder der Knoten konfiguriert sich selbst automatisch, indem er sich an die eventuell vorhandenen Nachbarn anpasst [RFC2461], [RFC2462]. 4.2.1 Route Aggregation Ein Achtel des IPv6-Adressraums ist für die sogenannten Aggregatable Global Unicast Addresses reserviert. Für diese Adressen ist, neben der providerbasierten, eine neue Art der Route Aggregation vorgesehen, die unter anderem Aggregation bei Roaming ermöglichen soll. Die Autoren von [RFC2734] nehmen an, daß sich dadurch diese Adressen als Standard im Internet durchsetzen werden. Die Adressstruktur (Abb. 13) spiegelt die hierarchische Organisationsstruktur wieder: 3 13 8 TLA ID RES FP 24 NLA ID Public Topology 16 SLA ID 64 Interface ID Site Topology Interface Identifier Abbildung 13: Adressstruktur 19 FP, Format Prefix : bestimmt das Format der Adresse (hier 001) TLA ID, Top-Level Aggregation Identifier : die oberste Ebene der Routinghierarchie. Sie werden von der IANA verwaltet und an große ISPs vergeben. Ihre Routingtabellen umfassen lediglich andere TLAs. RES, Reserved : reserviert, um entweder mehr TLAs oder NLAs aufnehmen zu können. NLA ID, Next-Level Aggregation Identifier : Von den TLAs verwalteter Adressraum, der in beliebig vielen Ebenen verteilt werden kann SLA ID, Site-Level Aggregation Identifier : entspricht VLSM (3.2.2) bei IPv4. Diesen Adressbereich verwalten die Kunden selbst. Interface ID : identifiziert das Interface am Knoten selbst Durch diese Hierarchie soll ein Kompromiss zwischen Flexibilität und dem Bedarf an möglichst kleinen Routingtabellen erreicht werden. 4.3 Konversion von IPv4 zu IPv6 Da ein Wechsel der Protokolle von einem Tag auf den anderen nicht praktikabel ist, muß er gleitend erfolgen, indem Stück für Stück Netzknoten von IPv4 auf IPv6 umgestellt werden. Zwei Wege, dies durchzuführen, werden in [RFC2893] diskutiert: Dual IP Layer : Es werden sogenannte IPv4/IPv6-Knoten installiert, die sowohl IPv6 als auch IPv4 beherrschen. Kommunizieren sie mit einem reinen IPv4-Knoten, wird IPv4 als Protokoll gewählt, sonst IPv6. Allerdings kann es dadurch dazu kommen, daß zwei IPv6-Knoten über IPv4 kommunizieren: auf einem Pfad, auf dem ein IPv4 Knoten sitzt, geht zusätzliche Information aus den IPv6-Headern verloren. Tunneling : Der Header wird hierbei nicht wie bei Dual IP Layer gewechselt, sondern im Falle eines Auftretens eines IPv4-Knotens wird das komplette IPv6-Paket samt Header in ein IPv4-Paket verpackt und beim nächsten IPv6-Knoten wieder ausgepackt. So wird sicher gestellt, daß auch alle IPv6-Headerinformationen ausgewertet werden können. Angesichts der Tragweite des Wechsels verwundert es nicht, daß er nur schleppend vorankommt. Vor allem Techniken wie CIDR und NAT (3.2.4) nehmen den Migrationsdruck von den ISPs, dabei ist der vergrösserte Adressraum keinesfalls der einzige Vorteil den man, wie oben dargelegt, durch einen Wechsel gewinnen würde. 5 Kontrollprotokolle Zusätzlich zu den Transferprotokollen IPv4 und IPv6 werden in der Internetschicht, wie in Abbildung 3 zu sehen ist, Kontrollprotokolle verwendet. Unter anderem sind das ICMP, ARP, RARP, BOOTP und DHCP; die beiden ersten werden im Folgenden näher betrachtet. 20 5.1 ICMP (Internet Control Message Protocol ) Alle Operationen in der Internetschicht werden durch die Router überwacht, Unregelmässigkeit werden dem Sender per ICMP gemeldet. Dieses Protokoll dient ferner Testzwecken. Es ist somit ein Zusatz zum an sich unzuverlässigen IP, um die Ursache einer auftretenden Unregelmäßigkeit feststellen zu können. ICMP ist dabei kein Teil des jeweiligen Transferprotokolls, sondern liegt über ihm. Wie TCP wird es mittels IP-Paketen übertragen. Beiden Versionen des Kontrollprotokolls ist das Format der Meldungen gemein (Abb. 14). 32 bit 8 8 Type Code 8 8 Checksum Message Body Abbildung 14: ICMP: Meldungsformat Type: Typ der Meldung; der Wert bestimmt das Format des Message Body. Code: weitere Unterteilung des Meldungstyps; der Wert ist abhängig von diesem. Checksum: Prüfsumme; wird wie bei IPv4 berechnet. Body liefert detaillierte Information zum Typ der Meldung. 5.1.1 ICMPv4 ICMPv4 ist das zu IPv4 gehörende Kontrollprotokoll und wurde zeitgleich mit ihm definiert [RFC792]. Die wichtigsten Meldungstypen sind in Tabelle 7 aufgeführt [IANAicmpv4]. Wert 0 3 5 8 11 12 13 14 Name Echo Reply Destination Unreachable Redirect Echo Time Exceed Parameter Problem Timestamp Timestamp Reply Beschreibung Lebenszeichen Paket konnte nicht abgeliefert werden Falsche Route Lebenszeichen anfordern TTL=0 Ungültiges Headerfeld wie Echo, aber mit Zeitangabe wie Echo Reply, aber mit Zeitangabe Tabelle 7: Einige ICMPv4-Meldungstypen 21 Echo und Echo Reply werden benutzt, um festzustellen, ob ein Zielknoten erreichbar und aktiv ist. Destination Unreachable wird gemeldet, wenn ein Router oder Subnetz den Zielknoten nicht lokalisieren können oder die Größe eines Pakets mit gesetztem DF-Bit die MTU überschreitet. Redirect meldet, daß das Paket falsch geroutet wurde. Time Exceed: das Paket hat seine Lebensdauer überschritten. Ein Grund dafür kann sein, daß das Paket eine Schleife durchläuft. Parameter Problem bedeutet, daß eines der Headerfelder auf einen unerlaubten Wert gesetzt wurde. Timestamp und Timestamp Reply entsprechen den Echo-Nachrichten. Da sie zusätzlich mit einer Zeitangabe versehen sind, kann man sie zur Leistungsmessung benutzen. 5.1.2 ICMPv6 Auch für IPv6 wurde ein Kontrollprotokoll entwickelt, ICMPv6 [RFC2463]. Die Nummerierung der Typen wurde in zwei Gruppen aufgeteilt: • Fehlermeldungen im Bereich 0 bis 127 • Informationsmeldungen im Bereich 128 bis 255 Einige von ihnen sind in Tabelle 8 aufgeführt, die komplette Liste wird von der IANA verwaltet [IANAicmpv6]. Wert 1 2 3 4 128 129 Name Destination Unreachable Packet Too Big Time Exceeded Parameter Problem Echo Request Echo Reply Beschreibung Paket konnte nicht abgeliefert werden Paketgrösse überschreitet MTU Hop Limit ist Null Ungültiges Feld im Haupt- oder Extension Header Lebenszeichen anfordern Lebenszeichen Tabelle 8: Einige ICMPv6-Meldungenstypen Wie man sieht, ist die Fehlermeldung Packet Too Big hinzugekommen, die beim Sender des Pakets den Fragmentierungsprozess in Gang setzt. Ferner sind weitere Informationsmeldungen hinzugekommen, unter anderem für Multicasting13 , etc.. 13 unter IPv4 eigenes Protokoll IMGP 22 5.2 ARP (Address Resolution Protocol ) Die Internetschicht stellt ein logisches Netz dar, während darunter nur Hardwareadressen bekannt sind. So lange IP diese nicht kennt, kann es auch keine Daten übermitteln. Eine Möglichkeit, dieses Problem zu lösen, wäre eine Tabelle, in der die Abbildung von IP- auf LAN-Adressen14 festgehalten ist. Dieses würde aber für LANs mit vielen Hosts in einem hohen Administrationsaufwand münden. Im WAN dagegen ist es mittels der Routingtabellen tatsächlich so realisiert. Eine einfachere Möglichkeit ist, beim Versand eines Pakets die LAN-Nummer des Empfängers direkt aus dem Netz zu ermitteln. Das wird durch ARP [RFC826] erledigt. Es reicht somit aus, jedem Interface eine IP-Adresse und Subnetmaske zuzuordnen, den Rest erledigt ARP. Soll ein Paket versandt werden, wird ein Broadcast mit einem ARP-Paket ins LAN abgesetzt. Das ARP-Paket enthält unter anderem die IP-Adresse des gesuchten Zielknotens. Beim Empfang überprüfen alle Knoten das ARP-Paket und nur der Knoten, dessen IP-Adresse mit der angegebenen übereinstimmt, sendet ein Antwortpaket an den fragenden Knoten. Dieser kann nun die IP-Adresse des Empfängers der entsprechenden LAN-Adresse zuordnen. Es können noch diverse Optimierungen vorgenommen werden: • Der Sender speichert die erfragte Abbildung für einige Zeit, um die Zahl der Broadcasts niedrig zu halten. • Das fragende System sendet seine eigene IP-LAN-Abbildung im anfragenden ARP-Paket, so daß ein Broadcast durch den Empfänger nicht notwendig ist. Ferner können alle Knoten diese Abbildung in den Zwischenspeicher aufnehmen. • Ein System, welches mit dem LAN neu verbunden ist, broadcastet seine eigene Abbildung ins Netz. Dieses passiert durch eine Anfrage mit der eigenen IP-Adresse, wodurch erreicht wird, daß 1. Adresskonflikte aufgezeigt werden können, falls ein anderes System antwortet. 2. jedes System im LAN diese Abbildung zwischenspeichern kann. Die Abbildungen im Zwischenspeicher müssen nach einigen Minuten verfallen, um auf eventuell auftretende Änderungen im LAN reagieren zu können. Wird eine IP-Adresse im ARP-Paket angegeben, die ausserhalb des LAN, d.h. hinter einem Router, liegt, gibt es zwei Möglichkeiten: 1. Der Sender weiß, daß es sich um eine Adresse in einem anderen Netz handelt. Dann ermittelt er über ARP direkt die LAN-Adresse des Routers und bildet die IP-Adresse des Empfängers auf diese ab. 2. Dem Sender ist unbekannt, ob der Empfänger im eigenen Netz ist. Dann empfängt auch der Router, der IP-Pakete an diese IP-Adresse weiterleiten soll, auch das ARP-Paket und antwortet mit seiner eigenen LAN-Adresse. 14 die Betonung liegt auf LAN; in der Verbindungsschicht kommunizieren nur direkt verbundene Interfaces 23 In beiden Fällen erhält der Router das Paket. Er ermittelt seinerseits die LAN-Addresse des Knotens, der nach der Routingtabelle der nächste auf dem Pfad zum Empfänger ist. Dieses geschieht im Falle von LANs, die nicht über ein WAN verbunden sind, wiederum mittels ARP, falls sich die jeweilige Abbildung nicht im Zwischenspeicher befindet. Die Kommunikationswege in einem einfachen Beispiel sind in Abbildung 15 eingezeichnet. Host 1 Router 1 Router 2 Host 2 Netzwerkschicht ARP Verbindungsschicht Abbildung 15: Kommunikation beim Versand eines IP-Pakets in verschiedenen Schichten 6 Zusammenfassung IPv4 hat nun für über 20 Jahre ein stabiles Fundament für den Datentransfer in heterogenen Netzen gebildet. Es ermöglichte durch seine Flexibilität und Robustheit das rapide Wachstum des Internets bis zum heutigen Stand. Auf dem Weg dahin ist es gelungen, einige Unzulänglichkeiten des ursprünglichen Designs zu beseitigen. So führten die Adressklassen zu einer ineffizienten Belegung des Adressraums. Dieses wurde mit CIDR gelöst, wofür keine fundamentalen Änderungen des Protokolls nötig waren. Trotzdem erweist sich die aus heutiger Sicht knapp bemessene Adresslänge als offensichtliches Hindernis für das weitere Wachstum, wie die schnelle Verbreitung der Krücke“ NAT beweist. Doch ” auch das Wachstum der Routingtabellen, das die Effizienz der Router vermindert, geringe Eignung für Echtzeitanwendungen oder kaum genutzte Headerfelder zeigen auf, daß ein Wechsel des Fundaments nötig ist. Dieser Wechsel soll gleitend geschehen. Der Nachfolger IPv6 ist schon gestartet, auch wenn es im täglichen Leben noch nicht besonders auffällt. Viele seiner Vorteile, wie der – aus heutiger Sicht – gigantische Adressraum, sind offensichtlich. Einige andere, wie die erweiterten Möglichkeiten bei der Route Aggregation, werden sich bewähren müssen, wenn IPv6 das Internet nachhaltig durchdrungen hat. Auch die erhöhte Flexibilität durch die Aneinanderkettung von Headern wird dann seine Wirkung zeigen. Daß mit der Definition von IPv6 die Arbeit trotzdem noch nicht beendet ist, beweisen die undefinierten Belegungen von Headerfeldern bez. der Flows, die ja das Transferprotokoll fit machen sollen für Echtzeitanwendungen. Vielleicht wird man in 20 Jahren ein ähnliches Resumee über IPv6 ziehen wie heute über IPv4 und IPv6 mit seinem sich langsam durchsetzenden Nachfolger vergleichen können. 24 Literatur [ARIN96] ftp://ftp.arin.net/netinfo/ip network allocations [HIN95] Hinden, R.; IP Next Generation Overview ; http://playground.sun.com/pub/ipng/html/INET-IPng-Paper.html; 1995 [IANAicmpv4] http://www.iana.org/assignments/icmp-parameters [IANAicmpv6] http://www.iana.org/assignments/icmpv6-parameters [IANAip] http://www.iana.org/assignments/ip-parameters [IANAprot] http://www.iana.org/assignments/protocol-numbers [IANAtcp] http://www.iana.org/assignments/port-numbers [KUR03] Kurose, James F. & Ross, Keith W.; Computer Networking, 2nd Edition ; Boston, u.a., 2003; Addison-Wesley [RFC768] Postel, Jon; User Datagram Protocol, RFC 768 ; USC/ISI; 1980 [RFC791] Postel, Jon (ed.); Internet Protocol, RFC 791 ; USC/ISI; 1981 [RFC792] Postel, J.; Internet Control Message Protocol, RFC 792 ; USC/ISI; 1981 [RFC793] Postel, Jon; Transmission Control Protocol, RFC 793 ; USC/ISI; 1981 [RFC826] Plummer; D.; Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware, RFC 826 ; 1982 [RFC950] Mogul, Jeffrey & Postel, Jon; Internet Standard Subnetting Procedure, RFC 950 ; Stanford University, USC/ISI; 1985 [RFC1009] Braden, R. & Postel, Jon; Requirements for Internet Gateways, RFC 1009 ; USC/ISI; 1987 [RFC1058] Hendrick, C.; Routing Information Protocol, RFC 1058 ; Rutgers University; 1988 [RFC1517] Hinden, Robert (ed.); Applicability Statement for the Implementation of Classless InterDomain Routing (CIDR), RFC 1517 ; Sun; 1993 [RFC1518] Rekhter, Y. & Li, T. (ed.); An Architecture for IP Address Allocation with CIDR, RFC 1518 ; IBM, cisco; 1993 [RFC1519] Fuller, V., Li, T., Yu, J. & Varadhan, K.; Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy, RFC 1519 ; BARRNet, cisco, MERIT, OARnet; 1993 25 [RFC1520] Rekhter, Y. & Topolcic, C.; Exchanging Routing Information Across Provider Boundaries in the CIDR Environment, RFC 1520 ; IBM, CNRI; 1993 [RFC1550] Bradner, S. & Mankin, A.; IP: Next Generation (IPng) White Paper Solicitation, RFC 1550 ; Harvard University, NRL; 1993 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G. J. & Lear, E.; Address Allocation for Private Internets, RFC 1918 ; Cisco, Chrysler, RIPE NCC, Silicon Graphics; 1996 [RFC2131] Droms, Ralph; Dynamic Host Configuration Protocol, RFC2131 ; Bucknell University; 1997 [RFC2373] Hinden, R. & Deering, S.; IP Version 6 Addressing Architecture, RFC 2373 ; Nokia, Cisco; 1998 [RFC2401] Kent, S. & Atkinson, R.; Security Architecture for the Internet Protocol, RFC 2401 ; BBN, @Home Network ; [RFC2460] Deering, S. & Hinden, R.; Internet Protocol, Version 6 (IPv6) Specification, RFC 2460 ; Cisco, Nokia; 1998 [RFC2461] Narten, T., Nordmark, E. & Simpson, W.; Neighbor Discovery for IP Version 6 (IPv6), RFC 2461 ; IBM, Sun, Daydreamer; 1998 [RFC2462] Thompson, S. & Narten, T.; IPv6 Stateless Address Autoconfiguration, RFC 2462 ; Bellcore, IBM; 1998 [RFC2463] Conta, A.& Deering, S.; Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, RFC 2463 ; Lucent, Cisco; 1998 [RFC2464] Crawford, M.; Transmission of IPv6 Packets over Ethernet Networks, RFC 2464 ; Fermilab; 1998 [RFC2465] Haskin, D. & Onishi, S.; Management Information Base for IP Version 6: Textual Conventions and General Group, RFC 2465 ; Bay Networks; 1998 [RFC2466] Haskin, D. & Onishi, S.; Management Information Base for IP Version 6: ICMPv6 Group, RFC 2466 ; Bay Networks; 1998 [RFC2734] Hinden, R., O’Dell, M. & Deering, S.; An IPv6 Aggregatable Global Unicast Address Format, RFC 2374 ; Nokia, UUNET, Cisco; 1998 [RFC2893] Gilligan, R. & Nordmark, E., Transition Mechanisms for IPv6 Hosts and Routers, RFC 2893 ; FreeGate, Sun; 2000 [RFC2993] Hain, T.; Architectural Implications of NAT, RFC 2993 ; Microsoft; 2000 [RFC3022] Srisuresh, P. & Egevang, K.; Traditional IP Network Address Translator (Traditional NAT), RFC 3022 ; Jasmine Networks, Intel; 2001 26 [RFC3194] Durand, A. & Huitema, C.; The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio, RFC 3194 ; Sun, Microsoft; 2001 [SEM96] Semeria, Chuck; Understanding IP Addressing ; http://www.3com.com/other/pdfs/infra/corpinfo/en US/501302.pdf [TAN03] Tanenbaum, Andrew S.; Computer networks, 4th Edition ; Upper Saddle River, NJ, 2003; Prentice Hall 27