Bla

IPv6 / IPv4 Stoff für Abschlußprüfung

Die PDF-Datei wurde mit Hilfe des Open-Source-Werkzeugs „mwlib“ erstellt. Für weitere Informationen siehe http://code.pediapress.com/ PDF generated at: Mon, 28 Jan 2013 11:18:02 UTC

Inhalt Artikel IP-Adresse

1

IPv6

9

IPv4

32

Quellennachweise Quelle(n) und Bearbeiter des/der Artikel(s)

40

Quelle(n), Lizenz(en) und Autor(en) des Bildes

41

Artikellizenzen Lizenz

42

IP-Adresse

1

IP-Adresse Eine IP-Adresse ist eine Adresse in Computernetzen, die – wie das Internet – auf dem Internetprotokoll (IP) basiert.

Sie wird Geräten zugewiesen, welche an das Netz angebunden sind und macht die Geräte so adressierbar und damit erreichbar. Die IP-Adresse kann einen einzelnen Empfänger oder eine Gruppe von Empfängern bezeichnen (Multicast, Broadcast). Umgekehrt können einem Computer mehrere IP-Adressen zugeordnet sein.

Die IP-Adresse wird verwendet, um Daten von ihrem Absender zum vorgesehenen Empfänger transportieren zu können. Ähnlich der Postanschrift auf einem Briefumschlag werden Datenpakete mit einer IP-Adresse versehen, die den Empfänger eindeutig identifiziert. Aufgrund dieser Adresse können die „Poststellen“, die Router, entscheiden, in welche Richtung das Paket weiter transportiert werden soll. Im Gegensatz zu Postadressen sind IP-Adressen nicht an einen bestimmten Ort gebunden.

Die bekannteste Notation der heute geläufigen IPv4-Adressen besteht aus vier Zahlen, die Werte von 0 bis 255 annehmen können und mit einem Punkt getrennt werden, beispielsweise 192.0.2.42. Technisch gesehen ist die Adresse eine 32-stellige (IPv4) oder 128-stellige (IPv6) Binärzahl.

Grundlagen Um eine Kommunikation zwischen zwei technischen Geräten aufzubauen, muss jedes der Geräte in der Lage sein, dem anderen Gerät Daten zu senden. Damit diese Daten bei der richtigen Gegenstelle ankommen, muss diese eindeutig benannt (adressiert) werden. Dies geschieht in IP-Netzen mit einer IP-Adresse. So wird zum Beispiel ein Webserver von einem Webbrowser direkt über seine IP-Adresse angesprochen. Der Browser fragt dazu für einen Domainnamen, zum Beispiel „www.example.com“, die IP-Adresse bei einem Nameserver an und spricht den Webserver dann direkt unter seiner IP-Adresse „198.51.100.42“ an.

IP-Adresse in IP-Datenpaketen Jedes IP-Datenpaket beginnt mit einem Informationsbereich für die Beförderung durch die IP-Schicht, dem IP-Header. Dieser Header enthält auch zwei Felder, in welche die IP-Adressen sowohl des Senders als auch des Empfängers eingetragen werden, bevor das Datenpaket verschickt wird. Die Vermittlung geschieht auf der Schicht 3 im OSI-Modell, der Vermittlungsschicht.

Aufbau IPv4 → Hauptartikel: IPv4 Die seit der Einführung der Version 4 des Internet Protocols überwiegend verwendeten IPv4-Adressen bestehen aus 32 Bits, also 4 Oktetts (Bytes). Damit sind 232, also 4.294.967.296 Adressen darstellbar. In der dotted decimal notation werden die 4 Oktetts als vier durch Punkte voneinander getrennte ganze Zahlen in Dezimaldarstellung im Bereich von 0 bis 255 geschrieben, Beispiel 203.0.113.195.

IP-Adresse

2

IPv6 – neue Version mit größerem Adressraum → Hauptartikel: IPv6 Durch den rasch steigenden Bedarf an IP-Adressen ist absehbar, dass der nutzbare Adressraum von IPv4 früher oder später erschöpft sein wird. Vor allem aus diesem Grund wurde IPv6 entwickelt. Es verwendet 128 Bit zur Speicherung von Adressen, damit sind 2128 = 25616 (= 340.282.366.920.938.463.463.374.607.431.768.211.456 ≈ 3,4 · 1038) Adressen darstellbar. Diese Anzahl reicht aus, um für jeden Quadratmillimeter der Erdoberfläche mindestens 665.570.793.348.866.944 (= 6,65 · 1017)[1] IP-Adressen bereitzustellen.

Da die Dezimaldarstellung ddd.ddd.ddd.ddd.ddd.ddd.ddd.ddd.ddd.ddd.ddd.ddd.ddd.ddd.ddd.ddd unübersichtlich und schlecht handhabbar wäre, stellt man IPv6-Adressen hexadezimal dar. Um diese Darstellung weiter zu vereinfachen, werden jeweils zwei Oktetts der Adresse zusammengefasst und in Gruppen durch Doppelpunkt getrennt dargestellt.

XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX. Beispiel 2001:0db8:85a3:0000:0000:8a2e:0370:7344 Zur weiteren Verkürzung können Nullen am Beginn eines Blocks weggelassen werden und maximal eine Folge von Blöcken, die nur aus Nullen bestehen, durch :: ersetzt werden.

Beispiel 2001:db8:85a3::8a2e:370:7344

Netzwerkteil und Geräteteil Jede IPv4-Adresse wird durch eine Netzmaske, jede IPv6-Adresse durch die Angabe der Präfixlänge, in einen Netzwerk- und einen Geräteteil („Hostteil“) getrennt. Die Netzmaske, also die Präfixlänge, gibt an, an welchem Bit die Adresse geteilt werden muss. Die von der Netzmaske maskierten oder von der Präfixlänge genannten Bits (Netzwerkteil) sind bei allen Hosts (Rechnern) eines Subnetzwerks identisch. Die Information, ob ein Gerät im gleichen Subnetz liegt (d. h. gleicher Netzwerkteil in der IP-Adresse), wird von einem Host benötigt, um Routing-Entscheidungen treffen zu können (siehe folgenden Abschnitt).

Beispiel (klassenlose) IPv4-Adresse 203.0.113.195/27 Dezimal

Binär

Berechnung

IP-Adresse

203.000.113.195

11001011 00000000 01110001 11000011

Netzmaske

255.255.255.224

11111111 11111111 11111111 11100000

Netzwerkadr.

203.000.113.192

11001011 00000000 01110001 11000000

IP-Adresse

203.000.113.195

11001011 00000000 01110001 11000011

Netzmaske

255.255.255.224

11111111 11111111 11111111 11100000 00000000 00000000 00000000 00011111

Geräteteil

3

00000000 00000000 00000000 00000011

ip-adresse AND netzmaske = netzwerkteil ip-adresse

AND (NOT netzmaske) = geräteteil

Bei einer Netzmaske mit 27 gesetzten Bits ergibt sich eine Netzadresse von 203.0.113.192. Es verbleiben 5 Bits und damit 25 = 32 Adressen für den Geräteteil. Hiervon werden noch je eine Adresse für das Netz selbst und für den Broadcast benötigt, so dass 30 Adressen für Geräte zur Verfügung stehen.

IP-Adresse

3

Routing Will ein Gerät ein IP-Paket versenden, werden die Netzwerkteile der Quell-IP-Adresse und Ziel-IP-Adresse verglichen. Stimmen sie überein, befindet sich der Ziel-Host im selben Netz und das Paket wird direkt an den Empfänger gesendet. Im Falle von Ethernet-Netzen dient das ARP (Address Resolution Protocol) zum Auffinden der Hardwareadresse. Das ARP arbeitet auf der zweiten Schicht des OSI-Modells und stellt die Verbindung zur ersten Schicht her.

Stimmen die Netzwerkteile dagegen nicht überein, so wird über eine Routingtabelle die IP-Adresse eines Routers (next hop) gesucht und das Paket an diesen Router gesendet. Dieser hat über eine oder mehrere Schnittstellen Kontakt zu anderen Netzen und routet das Paket mit demselben Verfahren weiter – er konsultiert dazu seinerseits seine eigene Routingtabelle und sendet das Paket gegebenenfalls an den nächsten Router oder an das Ziel. Bis zum Endgerät kann das Paket viele Netze und Router durchlaufen. Das Durchlaufen eines Routers wird auch Hop (Sprung) genannt, das Routingverfahren Next Hop Routing.

Routing eines HTTP Pakets über drei Netze

Ein Router hat dabei für jede seiner Schnittstellen eine eigene IP-Adresse und Netzmaske, die zum jeweiligen Netz gehört. Jedes IP-Paket wird einzeln geroutet. Die Quell- und Zieladresse im IP-Header werden vom Sender gesetzt und bleiben während des gesamten Weges unverändert.

Besondere IP-Adressen Besondere IPv4-Adressen nach RFC 3330: CIDR-Adressblock

Adressbereich

Beschreibung

RFC

0.0.0.0/8

0.0.0.0 bis 0.255.255.255

aktuelles Netz (nur als Quelladresse gültig)

RFC 3232 (ersetzt RFC 1700)

10.0.0.0/8

10.0.0.0 bis 10.255.255.255

Netzwerk für den privaten Gebrauch

RFC 1918

100.64.0.0/10

100.64.0.0 bis 100.127.255.255

Mehrfach benutzter Adressbereich für Provider-NAT RFC 6598

127.0.0.0/8(1)

127.0.0.0 bis 127.255.255.255

Localnet

RFC 3330

169.254.0.0/16

169.254.0.0 bis 169.254.255.255 Zeroconf

RFC 3927

172.16.0.0/12

172.16.0.0 bis 172.31.255.255

Netzwerk für den privaten Gebrauch

RFC 1918

192.0.0.0/24

192.0.0.0 bis 192.0.0.255

reserviert, aber zur Vergabe vorgesehen

192.0.2.0/24

192.0.2.0 bis 192.0.2.255

Dokumentation und Beispielcode (TEST-NET-1)

RFC 5737 (ersetzt RFC 3330)

192.88.99.0/24

192.88.99.0 bis 192.88.99.255

6to4-Anycast-Weiterleitungspräfix

RFC 3068

192.168.0.0/16

192.168.0.0 bis 192.168.255.255 Netzwerk für den privaten Gebrauch

RFC 1918

198.18.0.0/15

198.18.0.0 bis 198.19.255.255

RFC 2544

198.51.100.0/24

198.51.100.0 bis 198.51.100.255 Dokumentation und Beispielcode (TEST-NET-2)

RFC 5737

203.0.113.0/24

203.0.113.0 bis 203.0.113.255

Dokumentation und Beispielcode (TEST-NET-3)

RFC 5737

224.0.0.0/4

224.0.0.0 bis 239.255.255.255

Multicasts (früheres Klasse-D-Netz)

RFC 3171

240.0.0.0/4

240.0.0.0 bis 255.255.255.255

reserviert (früheres Klasse-E-Netz)

RFC 3232 (ersetzt RFC 1700)

255.255.255.2552)

255.255.255.255

Broadcast

Netz-Benchmark-Tests

IP-Adresse

4

Nach dieser Liste erfüllen 622.199.809 von rund 4,3 Milliarden IPv4-Adressen bzw. 14,5 % aller möglichen IPv4-Adressen einen besonderen Zweck.

1. Das Netz 127.0.0.0/8 bezieht sich auf den lokalen Computer (loopback address). Aus diesem Netzbereich ist oftmals die Adresse 127.0.0.1 mit dem Hostnamen localhost ansprechbar. Adressen aus diesem Bereich dienen zur Kommunikation eines Client- mit einem Server-Prozess auf demselben Computer. Mit Kommandozeilenbefehlen wie ssh localhost oder ftp 127.0.0.1 können die Server auf einem lokalen Rechner angesprochen werden, etwa um ihr Funktionieren zu testen.

2. Die spezielle Adresse 255.255.255.255 kann neben der höchsten Geräteadresse im Netz ebenfalls als Broadcastadresse verwendet werden. Dadurch ist das Versenden von Broadcasts ohne Kenntnis weiterer Netzwerkparameter möglich. Dies ist für Protokolle wie BOOTP und DHCP wichtig.

Damit gibt es drei IP-Adresstypen: • Unicast: Senden an einen bestimmten Empfänger im Internet (normale Adressierung).

• Broadcast: Senden an alle Geräte im selben Netz (Subnetz). Dieses wird bei IPv6 durch Multicast ersetzt.

• Multicast: Senden an einige Geräte im selben Netz (oder Geräte im Multicastbackbone-Netz).

Nicht mehr reservierte IP-Adressen Mit dem RFC 5735 wurden ca. 50 Millionen IP-Adressen freigegeben. Die Reservierung der folgenden Adressbereiche wurde aufgehoben und zur Verteilung freigegeben.

CIDR-Adressblock

Adressbereich

Anzahl

Beschreibung

RFC

14.0.0.0/8

14.0.0.0 bis 14.255.255.255

16.777.216 Öffentliches Datennetz

RFC 3232 (ersetzt RFC 1700)

24.0.0.0/8

24.0.0.0 bis 24.255.255.255

16.777.216 Cable Television Networks

39.0.0.0/8

39.0.0.0 bis 39.255.255.255

16.777.216 im Januar 2011 an das APNIC vergeben

128.0.0.0/16

128.0.0.0 bis 128.0.255.255

65.536 im November 2010 an das RIPE NCC vergeben [2]

191.255.0.0/16

191.255.0.0 bis 191.255.255.255

65.536 reserviert, aber zur Vergabe vorgesehen

RFC 1918

223.255.255.0/24

223.255.255.0 bis 223.255.255.255

256 reserviert, aber zur Vergabe vorgesehen

RFC 3330

RFC 1797

DNS – Übersetzung von Rechnernamen in IP-Adressen Über das weltweit verfügbare Domain Name System (DNS) können Namen in IP-Adressen (und umgekehrt) aufgelöst werden. Der Name www.example.com ergibt zum Beispiel die IPv4-Adresse 208.77.188.166, der Name www.ipv6.uni-muenster.de die IPv6-Adresse 2001:638:500:101:2e0:81ff:fe24:37c6.

Vergabe von IP-Adressen und Netzbereichen IANA – Internet Assigned Numbers Authority Die Vergabe von IP-Netzen im Internet wird von der IANA geregelt. In den Anfangsjahren des Internets wurden IPv4-Adressen bzw. -Netze in großen Blöcken direkt von der IANA an Organisationen, Firmen oder Universitäten vergeben. Beispielsweise wurde der Bereich 13.0.0.0/8 und damit 16.777.216 Adressen der Xerox Corporation zugeteilt. Merck & Co. erhielt von der IANA ebenfalls einen Bereich von 16.777.216 Adressen (54.0.0.0/8), ebenso wie IBM (9.0.0.0/8). Die einzige deutsche Firma welche einen /8 Bereich zugeteilt bekommen hat ist die debis AG (53.0.0.0/8). Heute vergibt die IANA Blöcke an regionale Vergabestellen.

IP-Adresse

5

RIR – Regional Internet Registry Seit Februar 2005 gibt es fünf regionale Vergabestellen, die Regional Internet Registries (RIR) genannt werden: • AfriNIC (African Network Information Centre) – zuständig für Afrika • APNIC (Asia Pacific Network Information Centre) – zuständig für die Region Asien-Pazifik

Zuständigkeitsbereiche der fünf RIR

• ARIN (American Registry for Internet Numbers) – Nordamerika • LACNIC (Latin-American and Caribbean Network Informaton Centre) – Lateinamerika und Karibik • RIPE NCC (Réseaux IP Européens Network Coordination Centre) – Europa, Naher Osten, Zentralasien.

Für Deutschland, Liechtenstein, Österreich und die Schweiz ist also das RIPE NCC zuständig.

Die Regional Internet Registries vergeben die ihnen von der IANA zugeteilten Netze an lokale Vergabestellen.

LIR – Local Internet Registry Die Local Internet Registries (LIR) genannten lokalen Vergabestellen geben die ihnen von den RIRs zugeteilten Adressen weiter an ihre Kunden. Die Aufgabe der LIR erfüllen in der Regel Internet Service Provider. Kunden der LIR können entweder Endkunden oder weitere (Sub-)Provider sein.

Die Adressen können dem Kunden entweder permanent zugewiesen werden (static IP address, feste IP-Adresse) oder beim Aufbau der Internetverbindung dynamisch zugeteilt werden (dynamic IP address, dynamische IP-Adresse). Fest zugewiesene Adressen werden vor Allem bei Standleitungen verwendet oder wenn Server auf der IP-Adresse betrieben werden sollen.

Welchem Endkunden oder welcher Local Internet Registry eine IP-Adresse bzw. ein Netz zugewiesen wurde, lässt sich über die Whois-Datenbanken der RIRs ermitteln.

Private Netze In privaten, lokalen Netzen (LAN) können selbst IP-Adressen vergeben werden. Dafür sollten für IPv4-Adressen aus den in RFC 1918 genannten privaten Netzen verwendet werden (zum Beispiel 192.168.1.1, 192.168.1.2, …). Diese Adressen werden von der IANA nicht weiter vergeben und im Internet nicht geroutet. Um trotzdem eine Internet-Verbindung zu ermöglichen, werden in einem Router mittels Network Address Translation die LAN-internen Adressen in öffentliche, im Internet gültige IPv4-Adressen übersetzt. Bei Paketen, die an die öffentliche Adresse gerichtet ankommen, wird die öffentliche Adresse wiederum in die privaten Adressen zurückübersetzt. Zusätzlich ermöglicht NAT, dass alle Computer des lokalen Netzes nach außen unter derselben (also nur einer) im Internet gültigen IPv4-Adresse erscheinen, was „Adressen spart“. Die Zuordnung einer Kommunikation zwischen einem lokalen Computer mit privater Adresse und dem Server im Internet geschieht dann über die Portnummer.

IP-Adresse

6

Netzklassen Ursprünglich wurden IPv4-Adressen in Netzklassen von A bis C mit verschiedenen Netzmasken eingeteilt. Klassen D und E waren für spezielle Aufgaben vorgesehen. Aufgrund der immer größer werdenden Routing-Tabellen wurde 1993 das klassenlose Routing CIDR (Classless Interdomain Routing) eingeführt. Damit spielt es keine Rolle mehr, welcher Netzklasse eine IPv4-Adresse angehört.

Gerätekonfiguration Manuelle Konfiguration Für Administratoren gibt es Programme, um die IP-Adresse anzuzeigen und zu konfigurieren. Unixoide Betriebssysteme verwenden hierfür das Kommando ifconfig, für Linux steht ip zur Verfügung, DOS oder Windows verwenden, je nach Version, ipconfig oder winipcfg.

Beispiele Der Netzschnittstelle eth0 wird die IPv4-Adresse 192.168.0.254 in einem /27-Subnetz zugewiesen.

• Unix (FreeBSD, Mac OS X): ifconfig eth0 192.168.0.254/27 • Linux: ip addr add 192.168.0.254/27 brd + dev eth0 • Linux (alt): ifconfig eth0 192.168.0.254 netmask 255.255.255.224 broadcast 192.168.0.255 Die Angabe der Teile „broadcast 192.168.0.255“ bzw. „brd +“ sind optional. („brd +“ steht hier für die automatische Berechnung der Broadcast-Adresse, es kann auch eine spezifische Adresse angegeben werden. ifconfig berechnet die Broadcast-Adresse in neueren Versionen automatisch).

Automatische Konfiguration Über Protokolle wie BOOTP oder DHCP können IP-Adressen beim Hochfahren des Rechners durch einen entsprechenden Server zugewiesen werden. Auf dem Server wird dazu vom Administrator ein Bereich von IP-Adressen definiert, aus dem sich weitere Rechner beim Hochfahren eine Adresse entnehmen können. Diese Adresse wird an den Rechner geleast. Rechner, die feste Adressen benötigen, können im Ethernet-Netz über ihre MAC-Adresse identifiziert werden und eine dauerhafte Adresse erhalten.

Vorteil hierbei ist die zentrale Verwaltung der Adressen. Ist nach der Installation des Betriebssystems die automatische Konfiguration vorgesehen, müssen keine weiteren Einstellungen für den Netzzugriff mehr vorgenommen werden. Mobilgeräte wie Laptops können sich Adressen teilen, wenn nicht alle Geräte gleichzeitig ans Netz angeschlossen werden. Daneben können sie ohne Änderung der Konfiguration bei Bedarf in verschiedene Netze (zum Beispiel Firma, Kundennetz, Heimnetz) integriert werden.

Für IPv6 gibt es zusätzlich noch die Möglichkeit der Autokonfiguration, die ohne Server auskommt.

Dynamische Adressierung Wenn einem Host bei jeder neuen Verbindung mit einem Netz eine neue IP-Adresse zugewiesen wird, spricht man von dynamischer oder wechselnder Adressierung. Im LAN-Bereich ist die dynamische Adressierung per DHCP verbreitet, im Internetzugangsbereich wird dynamische Adressierung vor allem von Internet-Service-Providern (ISP) eingesetzt, die Internet-Zugänge über Wählleitungen anbieten. Sie nutzen die dynamische Adressierung via PPP oder PPPoE. Vorteil der dynamischen Adressierung ist, dass im Durchschnitt deutlich weniger als eine IP-Adresse pro Kunde benötigt wird, da nie alle Kunden gleichzeitig online sind. Ein Verhältnis zwischen 1:10 und 1:20 ist üblich. Das RIPE NCC verlangt von seinen LIRs einen Nachweis über die Verwendung der ihnen zugewiesenen IP-Adressen.

Eine feste Zuordnung von Adressen wird nur in begründeten Fällen akzeptiert, zum Beispiel für den Betrieb von Servern oder für Abrechnungszwecke.

IP-Adresse

7

Bei DSL-Anbindung des Kunden verwenden die Provider meist ebenfalls dynamisch vergebene IPs.

Statische Adressierung Statische Adressierung wird prinzipiell überall dort verwendet, wo eine dynamische Adressierung technisch nicht möglich oder nicht sinnvoll ist. So erhalten in LANs zum Beispiel Gateways, Server oder Netzwerk-Drucker in der Regel feste IP-Adressen. Im Internet-Zugangsbereich wird statische Adressierung vor allem für Router an Standleitungen verwendet. Auch für Machine-to-Machine-Kommunikation wird insbesondere im Mobilfunkbereich (GPRS) zunehmend statische Adressierung verwendet. Statische Adressen werden meist manuell konfiguriert, können aber auch über automatische Adressierung (siehe oben) zugewiesen werden.

Mehrere Adressen auf einer Netzwerkkarte Meist wird jeder Netzwerk-Schnittstelle (zum Beispiel Netzwerkkarte) eines Hosts genau eine IPv4-Adresse zugewiesen. In einigen Fällen (siehe unten) ist es allerdings notwendig, einer Schnittstelle mehrere IPv4-Adressen zuzuweisen. Dies wird auch als IP-Aliasing bezeichnet. Mehrere IPv4-Adressen auf einer Netzwerkkarte werden unter anderem verwendet, um mehrere gleiche Services dort parallel zu betreiben, um einen Host aus verschiedenen Subnetzen erreichbar zu machen oder um einen Service logisch vom Host zu trennen, sodass er – mit seiner IPv4-Adresse und transparent für die Clients – auf eine andere Hardware verschoben werden kann.

Beispiel (FreeBSD) Die Netzwerkschnittstelle fxp0 bekommt die IPv4-Adresse 192.168.2.254 mit einem /26-Subnetz als Alias ifconfig fxp0 alias 192.168.2.254 netmask 255.255.255.192 Beispiel (Linux) Unter Linux wird einfach der gleiche Befehl wie unter Manuelle Konfiguration verwendet, um weitere Adressen hinzuzufügen ip addr add 192.168.2.254/26 dev eth0 Bei IPv6 ist die Bindung mehrerer Adressen an eine Netzwerk-Schnittstelle die Regel, um beispielsweise eine link-lokale neben einer globalen Adresse und dynamisch vergebene Präfixe neben festen zu betreiben oder um IPv6-Adressen mehrerer Internetprovider auf demselben Host zur Verfügung zu haben. Außerdem gelten die oben genannten Gründe wie für IPv4.

Unterschiedliche Netze auf einem physischen Netz Auf einem physischen Netz (zum Beispiel Ethernet-Netz) können unterschiedliche Netze (mit unterschiedlichem Netzwerk-Adressteil) aufgesetzt und gleichzeitig verwendet werden. Dies wird unter anderem eingesetzt, wenn später das Netz aufgeteilt werden soll oder wenn früher getrennte Netze zusammengefasst werden.

Speicherung von IP-Adressen Eine abschließende rechtliche Bewertung der Speicherung von IP-Adressen in Deutschland ist bislang nicht zustande gekommen.

Das deutsche Bundesverfassungsgericht urteilte am 2. März 2010, dass die Speicherung von IPs in Deutschland in ihrer bisherigen Umsetzung verfassungswidrig sei, da das Gesetz zur anlasslosen Speicherung umfangreicher Daten sämtlicher Nutzer elektronischer Kommunikationsdienste keine konkreten Maßnahmen zur Datensicherheit vorsehe und hat zudem die Hürden für den Abruf dieser Daten als zu niedrig bewertet. Das Urteil verpflichtete deutsche Telekommunikationsanbieter zur sofortigen Löschung der bis dahin gesammelten Daten. Es stellte jedoch fest, dass die Vorratsdatenspeicherung unter schärferen Sicherheits- und Transparenzvorkehrungen sowie begrenzten Abrufmöglichkeiten für die Sicherheitsbehörden grundsätzlich zulässig sei.

IP-Adresse Einem Auskunftsgesuch der Staatsanwaltschaft ist dann nachzukommen, wenn dieses im Rahmen eines Ermittlungsverfahrens über eine schwere Straftat im Sinne von § 100a Abs. 2 StPO erfolgt.[3] Die Speicherung von IP-Adressen zu anderen Zwecken (beispielsweise beim Besuch einer Internetseite, etwa in einer Logdatei) ist jedoch rechtlich völlig ungeklärt.

Das Amtsgericht Mitte (Berlin) erklärte im März 2007 IP-Adressen zu personenbezogenen Daten im Sinne von § 3 BDSG[4],[5] somit wäre ihre Speicherung nicht zulässig. Das Amtsgericht München entschied Ende September 2008, dass IP-Adressen nicht als personenbezogene Daten zu werten sind, somit wäre ihre Speicherung grundsätzlich zulässig.[6] Das Gericht knüpfte dies jedoch an einige Vorgaben. So hängt die Zulässigkeit der Speicherung von den Möglichkeiten desjenigen ab, der die Daten speichert. Hat er prinzipiell die Möglichkeit, eine Person anhand ihrer IP-Adresse zu identifizieren (etwa anhand eines personalisierten Benutzerkontos), so ist die automatische Speicherung nicht zulässig. In diesem Fall ist dies nur erlaubt, wenn der Benutzer seine ausdrückliche Zustimmung erteilt hat.

Es ist festzuhalten, dass beide Urteile bzgl. IPv4-Adressen ergingen, aufgrund des größeren Adressbereiches von IPv6-Adressen sind letztere unter Umständen rechtlich anders einzuordnen.[7]

Literatur • Marc Störing: Gefährliches Adressgedächtnis – Rechtsunsicherheit bei Speicherung und Weitergabe von IP-Daten. In: c’t 25/08, S. 190/191

Weblinks • • • • • •

IANA – Internet Assigned Numbers Authority [8] (mit Informationen zu IP-Adressen, englisch) IANA – Ipv4-address-space [9] (Zuordnungen der IP-Bereiche) RFC 3330 Special-Use IP Addresses (englisch) RIPE – Réseaux IP Européens [10] (Gibt unter anderem den registrierten Eigentümer einer IP aus, englisch) Webinterface zur Berechnung von Netzmasken, Netzgrenzen usw. [11] (englisch) tmp.to [12] (Gibt die eigene IP sowie Informationen über Betriebssystem, Browser und Standort aus, englisch)

Einzelnachweise [1] Joseph Davies: Understanding IPv6. Microsoft Press 2002, ISBN 0-7356-1245-5, Berechnung ist 2^128 Adressen pro 510 Millionen Quadratkilometer (http:/ / www. microsoft. com/ mspress/ books/ sampchap/ 4883. asp) [2] ARIN WhoIs 128.0.0.0/16 (http:/ / whois. arin. net/ rest/ net/ NET-128-0-0-0-1) [3] Eilantrag in Sachen „Vorratsdatenspeicherung“ teilweise erfolgreich (http:/ / www. bverfg. de/ pressemitteilungen/ bvg08-037. html) [4] §3 BDSG (http:/ / www. gesetze-im-internet. de/ bdsg_1990/ __3. html) [5] AG Berlin Mitte, Urteil vom 27. März 2007, Az. 5 C 314/06 [6] AG München, Urteil vom 30. September 2008, Az. 133 C 5677/08 [7] Institut für IT-Recht (http:/ / www. iitr. de/ datenschutz-aktuelle-diskussion-ip-adresse-personenbezogene-daten-bdsg. html)Datenschutz im Internet: Aktuelle Diskussion zur Frage, ob IP-Adressen personenbezogene Daten im Sinne des BDSG sind [8] http:/ / www. iana. org/ [9] http:/ / www. iana. org/ assignments/ ipv4-address-space [10] http:/ / www. ripe. net/ [11] http:/ / jodies. de/ ipcalc?host=& mask1=& mask2= [12] http:/ / tmp. to/

8

IPv6

9

IPv6 IPv6 im TCP/IP‑Protokollstapel: Anwendung Transport

HTTP

IMAP SMTP DNS …

TCP

Internet

UDP IPv6

Netzzugang Ethernet Token Token FDDI …

Bus Ring

Das Internet Protocol Version 6 (IPv6), früher auch Internet Protocol next Generation (IPnG) genannt, ist ein von der Internet Engineering Task Force (IETF) seit 1998 standardisiertes Verfahren zur Übertragung von Daten in paketvermittelnden Rechnernetzen, insbesondere dem Internet. In diesen Netzen werden die Daten in Paketen versendet, in welchen nach einem Schichtenmodell Steuerinformationen verschiedener Netzwerkprotokolle ineinander verschachtelt um die eigentlichen Nutzdaten herum übertragen werden. IPv6 stellt als Protokoll der Vermittlungsschicht (Schicht 3 des OSI-Modells) im Rahmen der Internetprotokollfamilie eine über Teilnetze hinweg gültige Adressierung der beteiligten Netzwerkelemente (Rechner oder Router) her. Ferner regelt es unter Verwendung dieser Adressen den Vorgang der Paketweiterleitung zwischen Teilnetzen (Routing). Die Teilnetze können so mit verschiedenen Protokollen unterer Schichten betrieben werden, die deren unterschiedlichen physikalischen und administrativen Gegebenheiten Rechnung tragen.

Im Internet soll IPv6 in den nächsten Jahren die gegenwärtig noch überwiegend genutzte Version 4 des Internet Protocols ablösen, da es eine deutlich größere Zahl möglicher Adressen bietet, die bei IPv4 zu erschöpfen drohen.

Kritiker befürchten ein Zurückdrängen der Anonymität im Internet durch die nun mögliche zeitlich stabilere und weiter reichende öffentliche Adressierung.[1] Befürworter bemängeln die zögerliche Einführung von IPv6 angesichts der ausgelaufenen IPv4-Adressvergabe in Asien, Ozeanien und Europa.[2]

Gründe für ein neues Internet-Protokoll IPv4 bietet einen Adressraum von etwas über vier Milliarden IP-Adressen (232 = 2564 = 4.294.967.296), mit denen Computer und andere Geräte angesprochen werden können. In den Anfangstagen des Internets, als es nur wenige Rechner gab, die eine IP-Adresse brauchten, galt dies als weit mehr als ausreichend. Aufgrund des unvorhergesehenen Wachstums des Internets herrscht heute aber Adressenknappheit. Im Januar 2011 teilte die IANA der asiatischen Regional Internet Registry APNIC die letzten zwei frei zu vergebenden Netze zu.[3] Gemäß einer Vereinbarung aus dem Jahr 2009[4] wurde am 3. Februar 2011 schließlich der verbleibende Adressraum gleichmäßig Anzahl verfügbarer IPv4-Adressblöcke zwischen 1995 und 2011 auf die regionalen Adressvergabestellen verteilt.[5][6] Darüber hinaus steht den regionalen Adressvergabestellen kein weiterer IPv4-Adressraum mehr zur Verfügung. Am 15. April 2011 teilte APNIC die letzten frei zu vergebenden Adressen für die Region Südostasien zu;[7] am 14. September 2012 folgte dann RIPE NCC mit der letzten freien Zuteilung in der Region Europa/Naher Osten.[8] Seitdem haben APNIC- und RIPE NCC-Mitglieder jeweils nur noch Anspruch auf eine einzelne Zuteilung von IPv4-Adressraum der minimalen Zuteilungsgröße.[9][10] Die historische Entwicklung des Internets wirft ein weiteres Problem auf: Durch die mit der Zeit mehrmals geänderte Vergabepraxis von Adressen des IPv4-Adressraums ist dieser inzwischen stark fragmentiert, d. h., häufig gehören

IPv6

10 mehrere nicht zusammenhängende Adressbereiche zur gleichen organisatorischen Instanz. Dies führt in Verbindung mit der heutigen Routingstrategie (Classless Inter-Domain Routing) zu langen Routingtabellen, auf welche Speicher und Prozessoren der Router im Kernbereich des Internets ausgelegt werden müssen. Zudem erfordert IPv4 von Routern, Prüfsummen jedes weitergeleiteten Pakets neu zu berechnen, was eine weitere Prozessorbelastung darstellt.

Aus diesen Gründen begann die IETF bereits 1995 die Arbeiten an IPv6. Im Dezember 1998 wurde IPv6 mit der Publikation von RFC 2460 auf dem Standards Track offiziell zum Nachfolger von IPv4 gekürt.

Die wesentlichen neuen Eigenschaften von IPv6 umfassen: • Vergrößerung des Adressraums von IPv4 mit 232 (≈ 4,3 Milliarden = 4,3·109) Adressen auf 2128(≈ 340 Sextillionen = 3,4·1038) Adressen bei IPv6, d. h. Vergrößerung um den Faktor 296 (≈7,9·1028).

• Vereinfachung und Verbesserung des Protokollrahmens (Kopfdaten); dies entlastet Router von Rechenaufwand.

• zustandslose automatische Konfiguration von IPv6-Adressen; zustandsbehaftete Verfahren wie DHCP werden beim Einsatz von IPv6 damit in vielen Anwendungsfällen überflüssig • Mobile IP sowie Vereinfachung von Umnummerierung und Multihoming • Implementierung von IPsec innerhalb des IPv6-Standards.[11] Dadurch wird die Verschlüsselung und die Überprüfung der Authentizität von IP-Paketen ermöglicht.[12] • Unterstützung von Netztechniken wie Quality of Service und Multicast Die hauptsächliche Motivation zur Vergrößerung des Adressraums besteht in der Wahrung des Ende-zu-Ende-Prinzips[13], das ein zentrales Designprinzip des Internets ist:[14] Nur die Endknoten des Netzes sollen aktive Protokolloperationen ausführen, das Netz zwischen den Endknoten ist nur für die Weiterleitung der Datenpakete zuständig. (Das Internet unterscheidet sich hier wesentlich von anderen digitalen Datenübertragungsnetzwerken wie z. B. GSM.) Dazu ist es notwendig, dass jeder Netzknoten global eindeutig adressierbar ist.[13] Heute übliche Verfahren wie Network Address Translation (NAT), welche derzeit die IPv4-Adressknappheit umgehen, verletzen das Ende-zu-Ende-Prinzip.[15] Sie ermöglichen den so angebundenen Rechnern nur ausgehende Verbindungen aufzubauen. Aus dem Internet können diese hingegen nicht ohne weiteres kontaktiert werden. Auch verlassen sich IPsec oder Protokolle auf höheren Schichten wie z. B. FTP und SIP teilweise auf das Ende-zu-Ende-Prinzip und sind mit NAT nur eingeschränkt oder mittels Zusatzlösungen funktionsfähig.[16] Besonders für Heimanwender bedeutet IPv6 damit einen Paradigmenwechsel: Anstatt vom Provider nur eine einzige IP-Adresse zugewiesen zu bekommen und über NAT mehrere Geräte ans Internet anzubinden, bekommt der Anwender global eindeutigen IP-Adressraum für ein ganzes Teilnetz zur Verfügung gestellt, so dass jedes seiner Geräte eine IP-Adresse aus diesem erhalten kann. Damit wird es für Endbenutzer einfacher, durch das Anbieten von Diensten aktiv am Netz teilzunehmen. Zudem entfallen die Probleme, die bei NAT durch die Adressumschreibung entstehen.

Bei der Wahl der Adresslänge und damit der Größe des zur Verfügung stehenden Adressraums waren mehrere Faktoren zu berücksichtigen. Zum einen müssen pro Datenpaket auch Quell- und Ziel-IP-Adresse übertragen werden. Längere IP-Adressen führen damit zu erhöhtem Protokoll-Overhead, d. h. das Verhältnis zwischen tatsächlichen Nutzdaten und der zur Vermittlung notwendigen Protokolldaten sinkt.[17] Auf der anderen Seite sollte dem zukünftigen Wachstum des Internets Rechnung getragen werden. Zudem sollte es zur Verhinderung der Fragmentierung des Adressraums möglich sein, einer Organisation nur ein einziges Mal Adressraum zuweisen zu müssen. Um den Prozess der Autokonfiguration sowie Umnummerierung und Multihoming zu vereinfachen, war es außerdem wünschenswert, einen festen Teil der Adresse zur netzunabhängigen eindeutigen Identifikation eines Netzknotens zu reservieren. Die letzten 64 Bit der Adresse bestehen daher in der Regel aus der EUI-64 der Netzwerkschnittstelle des Knotens.

IPv6

11

Adressaufbau von IPv6 IPv6-Adressen sind 128 Bit lang (IPv4: 32 Bit). Die letzten 64 Bit bilden bis auf Sonderfälle einen für die Netzwerkschnittstelle (engl. Interface) eindeutigen Interface Identifier. Eine Netzwerkschnittstelle kann unter mehreren IP-Adressen erreichbar sein; in der Regel ist sie dies mittels ihrer link-lokalen Adresse und einer global eindeutigen Adresse. Derselbe Interface Identifier kann damit Teil mehrerer IPv6-Adressen sein, welche mit verschiedenen Präfixen auf dieselbe Netzwerkkarte gebunden sind. Insbesondere gilt dies auch für Präfixe möglicherweise verschiedener Provider; dies vereinfacht Multihoming-Verfahren.

Da die Erzeugung des Interface Identifiers aus der global eindeutigen MAC-Adresse die Nachverfolgung von Benutzern ermöglicht, wurden die Privacy Extensions (RFC 4941) entwickelt, um diese permanente Kopplung der Benutzeridentität an die IPv6-Adressen aufzuheben. Indem der Interface Identifier zufällig generiert wird und regelmäßig wechselt, soll ein Teil der Anonymität von IPv4 wiederhergestellt werden.

Da im Privatbereich in der IPv6-Adresse aber sowohl der Interface Identifier als auch das Präfix allein recht sicher auf einen Nutzer schließen lassen können, ist aus Datenschutzgründen in Verbindung mit den Privacy Extensions ein vom Provider dynamisch zugewiesenes, z. B. täglich wechselndes, Präfix wünschenswert. (Mit einer statischen Adresszuteilung geht in der Regel insbesondere ein Eintrag in der öffentlichen Whois-Datenbank einher.) Dabei ist es wie oben beschrieben grundsätzlich möglich, auf derselben Netzwerkkarte sowohl IPv6-Adressen aus dynamischen als auch aus fest zugewiesenen Präfixen parallel zu verwenden. In Deutschland hat der Deutsche IPv6-Rat Datenschutzleitlinien formuliert, die auch eine dynamische Zuweisung von IPv6-Präfixen vorsehen.[18]

Adressnotation Die textuelle Notation von IPv6-Adressen ist in Abschnitt 2.2 von RFC 4291 beschrieben: 1. IPv6-Adressen werden gewöhnlicherweise hexadezimal (IPv4: dezimal) notiert, wobei die Zahl in acht Blöcke zu jeweils 16 Bit (4 Hexadezimalstellen) unterteilt wird. Diese Blöcke werden durch Doppelpunkte (IPv4: Punkte) getrennt notiert: 2001:0db8:85a3:08d3:1319:8a2e:0370:7344.

2. Führende Nullen innerhalb eines Blockes dürfen ausgelassen werden: 2001:0db8:0000:08d3:0000:8a2e:0070:7344 ist gleichbedeutend mit 2001:db8:0:8d3:0:8a2e:70:7344.

3. Ein oder mehrere aufeinander folgende Blöcke, deren Wert 0 (bzw. 0000) beträgt, dürfen ausgelassen werden.

Dies wird durch zwei aufeinander folgende Doppelpunkte angezeigt: 2001:0db8:0:0:0:0:1428:57ab ist gleichbedeutend mit 2001:db8::1428:57ab.

4. Die Reduktion durch Regel 3 darf nur einmal durchgeführt werden, das heißt, es darf höchstens eine zusammenhängende Gruppe aus Null-Blöcken in der Adresse ersetzt werden. Die Adresse 2001:0db8:0:0:8d3:0:0:0 darf demnach entweder zu 2001:db8:0:0:8d3:: oder 2001:db8::8d3:0:0:0 gekürzt werden; 2001:db8::8d3:: ist unzulässig, da dies mehrdeutig ist und fälschlicherweise z. B. auch als 2001:db8:0:0:0:8d3:0:0 interpretiert werden könnte.

5. Ebenfalls darf für die letzten vier Bytes (also 32 Bits) der Adresse die herkömmliche dezimale Notation verwendet werden. So ist ::ffff:127.0.0.1 eine alternative Schreibweise für ::ffff:7f00:1. Diese Schreibweise wird vor allem bei Einbettung des IPv4-Adressraums in den IPv6-Adressraum verwendet.

IPv6

12

URL-Notation von IPv6-Adressen In einer URL wird die IPv6-Adresse in eckige Klammern eingeschlossen,[19] z. B.: http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]/ Diese Notation verhindert die fälschliche Interpretation von Portnummern als Teil der IPv6-Adresse: http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:8080/

Netznotation IPv6-Netzwerke werden in der CIDR-Notation aufgeschrieben. Dazu werden die erste Adresse (bzw. die Netzadresse) und die Länge des Präfixes in Bits getrennt durch einen Schrägstrich notiert. Zum Beispiel steht 2001:0db8:1234::/48 für das Netzwerk mit den Adressen 2001:0db8:1234:0000:0000:0000:0000:0000 bis 2001:0db8:1234:ffff:ffff:ffff:ffff:ffff. Die Größe eines IPv6-Netzwerkes (oder Subnetzwerkes) im Sinne der Anzahl der vergebbaren Adressen in diesem Netz muss also eine Zweierpotenz sein. Da ein einzelner Host auch als Netzwerk mit einem 128 Bit langen Präfix betrachtet werden kann, werden Host-Adressen manchmal mit einem angehängten „/128“ geschrieben.

Aufteilung des IPv6-Adressraums Adresszuweisung Typischerweise bekommt ein Internetprovider (ISP) die ersten 32 Bit (oder weniger) als Netz von einer Regional Internet Registry (RIR) zugewiesen.[20] Dieser Bereich wird vom Provider weiter in Subnetze aufgeteilt. Die Länge der Zuteilung an Endkunden wird dabei dem ISP überlassen; vorgeschrieben ist die minimale Zuteilung eines /64-Netzes.[21] Ältere Dokumente (z. B. RFC 3177) schlagen eine Zuteilung von /48-Netzen an Endkunden vor; in Ausnahmefällen ist die Zuteilung größerer Netze als /48 oder mehrerer /48-Netze an einen Endkunden möglich.[22] Informationen über die Vergabe von IPv6-Netzen können über die Whois-Dienste der jeweiligen RIRs abgefragt werden. Es gibt in deren RPSL-Datenbanken dazu inet6num- und route6-Objekte und in vielen anderen Objekttypen Attribute zur Multi-Protocol-Erweiterung (mp) mit Angabe der Address-Family (afi) zum Spezifizieren des neuen Protokolls.

Einem einzelnen Netzsegment wird in der Regel ein 64 Bit langes Präfix zugewiesen, das dann zusammen mit einem 64 Bit langen Interface Identifier die Adresse bildet.[23] Der Interface Identifier kann entweder aus der MAC-Adresse der Netzwerkkarte erstellt oder anders eindeutig zugewiesen werden; das genaue Verfahren ist in RFC 4291, Anhang A beschrieben.

Hat z. B. ein Netzwerkgerät die IPv6-Adresse 2001:0db8:85a3:08d3:1319:8a2e:0370:7347/64, so lautet das Präfix 2001:0db8:85a3:08d3::/64 und der Interface Identifier 1319:8a2e:0370:7347.

Der Provider bekam von der RIR wahrscheinlich das Netz 2001:0db8::/32 zugewiesen und der Endkunde vom Provider möglicherweise das Netz 2001:0db8:85a3::/48, oder aber nur

IPv6

13 2001:0db8:85a3:0800::/56.

Adressbereiche Es gibt verschiedene IPv6-Adressbereiche mit Sonderaufgaben und unterschiedlichen Eigenschaften. Diese werden meist schon durch die ersten Bits der Adresse signalisiert. Sofern nicht weiter angegeben, werden die Bereiche in RFC 4291 bzw. RFC 5156 definiert. Unicast-Adressen charakterisieren Kommunikation eines Netzknotens mit genau einem anderen Netzknoten; Einer-zu-vielen-Kommunikation wird durch Multicast-Adressen abgebildet.

Besondere Adressen • ::/128 (128 0-Bits) ist die nicht spezifizierte Adresse. Sie darf keinem Host zugewiesen werden, sondern zeigt das Fehlen einer Adresse an. Sie wird beispielsweise von einem initialisierenden Host als Absenderadresse in IPv6-Paketen verwendet, solange er seine eigene Adresse noch nicht mitgeteilt bekommen hat.[24] Jedoch können auch Serverprogramme durch Angabe dieser Adresse bewirken, dass sie auf allen Adressen des Hosts lauschen.

• ::1/128 (127 0-Bits, ein 1-Bit) ist die Adresse des eigenen Standortes (loopback-Adresse, die in der Regel mit localhost verknüpft ist).

Link-Local-Adressen Link-Local-Adressen[25] werden innerhalb abgeschlossener Netzwerksegmente eingesetzt. Man identifiziert sie am Subnetz-Präfix (den ersten 64 Bits) mit dem Wert „fe80:0000:0000:0000“ oder „fe80::/64“: 10 Bits

54 Bits

1111111010 0

64 Bits Interface ID

Link-Local-Adressen nutzt man zur Adressierung von Nodes in abgeschlossenen Netzwerksegmenten, sowie zur Autokonfiguration oder Neighbour-Discovery. Dadurch muss man in einem Netzwerksegment keinen DHCP-Server zur automatischen Adressvergabe konfigurieren. Link-Local-Adressen sind mit APIPA-Adressen im Netz 169.254.0.0/16 vergleichbar.

Soll ein Gerät mittels einer dieser Adressen kommunizieren, so muss die Zone ID mit angegeben werden (unter Windows ist das in der Regel die zugehörige Netzwerkschnittstelle), da eine Link-Lokale-Adresse auf einem Gerät mehrfach vorhanden sein kann. Bei einer einzigen Netzwerkschnittstelle würde eine Adresse etwa so aussehen: fe80::7645:6de2:ff:1%1.

Site Local Unicast (veraltet) fec0::/10 (fec0… bis feff…), auch standortlokale Adressen (site local addresses), waren die Nachfolger der privaten IP-Adressen (beispielsweise 192.168.x.x). Sie durften nur innerhalb der gleichen Organisation geroutet werden. Die Wahl des verwendeten Adressraums innerhalb von fec0::/10 war für eine Organisation beliebig.

Bei der Zusammenlegung von ehemalig getrennten Organisationen oder wenn eine VPN-Verbindung zwischen eigentlich getrennten mit Site Local Addresses nummerierten Netzwerken hergestellt wurde, konnte es daher zu Überschneidungen der Adressräume an den unterschiedlichen Standorten kommen. Aus diesem und weiteren Gründen sind Site Local Addresses daher nach RFC 3879 inzwischen veraltet (engl. deprecated) und werden aus zukünftigen Standards verschwinden. Neue Implementierungen müssen diesen Adressbereich als Global-Unicast-Adressen behandeln. Nachfolger der standortlokalen Adressen sind die Unique Local Addresses, die im nächsten Abschnitt beschrieben werden.

IPv6

14 Unique Local Unicast fc00::/7 (fc… und fd…). Für private Adressen gibt es die Unique Local Addresses (ULA), beschrieben in RFC 4193. Derzeit ist nur das Präfix fd für lokal generierte ULA vorgesehen, mit dem Präfix fc werden in Zukunft wahrscheinlich global zugewiesene eindeutige ULA gekennzeichnet. Auf dieses Präfix folgen dann 40 Bits, die als eindeutige Site-ID fungieren. Diese Site-ID ist bei den ULA mit dem Präfix fd zufällig zu generieren[26] und somit nur sehr wahrscheinlich eindeutig, bei den global vergebenen ULA jedoch auf jeden Fall eindeutig (RFC 4193 gibt jedoch keine konkrete Implementierung der Zuweisung von global eindeutigen Site-IDs an). Nach der Site-ID folgt eine 16-Bit-Subnet-ID, welche ein Netz innerhalb der Site angibt.

Eine Beispiel-ULA wäre fd9e:21a7:a92c:2323::1. Hierbei ist fd das Präfix für lokal generierte ULAs, 9e:21a7:a92c ein einmalig zufällig erzeugter 40-Bit-Wert und 2323 eine willkürlich gewählte Subnet-ID. Die Verwendung von wahrscheinlich eindeutigen Site-IDs hat den Vorteil, dass zum Beispiel beim Einrichten eines Tunnels zwischen getrennt voneinander konfigurierten Netzwerken Adresskollisionen sehr unwahrscheinlich sind.

Weiterhin wird erreicht, dass Pakete, welche an eine nicht erreichbare Site gesendet werden, mit großer Wahrscheinlichkeit ins Leere laufen, anstatt an einen lokalen Host gesendet zu werden, der zufällig die gleiche Adresse hat.

Es existiert ein proposed standard [27], welcher Richtlinien für Registrare (IANA, RIR) beschreibt, konkret deren Betrieb sowie die Adressvergabe-Regeln. Allerdings ist eine derartige „ULA-Central“ noch nicht gegründet.

Sowohl der RFC 4193 als auch der proposed standard sind identisch in Bezug auf das Adressformat und den oben genannten Generierungs-Algorithmus.

Multicast ff00::/8 (ff…) stehen für Multicast-Adressen.

Nach dem Multicast-Präfix folgen 4 Bits für Flags und 4 Bits für den Gültigkeitsbereich (Scope). Für die Flags sind zurzeit folgende Kombinationen gültig:[28] • • • •

0: Permanent definierte wohlbekannte Multicast-Adressen (von der IANA zugewiesen)[29] 1: (T-Bit gesetzt) Transient (vorübergehend) oder dynamisch zugewiesene Multicast-Adressen 3: (P-Bit gesetzt, erzwingt das T-Bit) Unicast-Prefix-based Multicast-Adressen (RFC 3306) 7: (R-Bit gesetzt, erzwingt P- und T-Bit) Multicast-Adressen, welche die Adresse des Rendezvous Point enthalten (RFC 3956)

Die folgenden Gültigkeitsbereiche sind definiert:[28] • 1: interfacelokal, diese Pakete verlassen die Schnittstelle nie. (Loopback) • 2: link-lokal, werden von Routern grundsätzlich nie weitergeleitet und können deshalb das Teilnetz nicht verlassen.

• 4: adminlokal, der kleinste Bereich, dessen Abgrenzung in den Routern speziell administriert werden muss.

• 5: sitelokal, dürfen zwar geroutet werden, jedoch nicht von Border-Routern.

• 8: organisationslokal, die Pakete dürfen auch von Border-Routern weitergeleitet werden, bleiben jedoch „im Unternehmen“ (hierzu müssen seitens des Routing-Protokolls entsprechende Vorkehrungen getroffen werden).

• e: globaler Multicast, der überallhin geroutet werden darf.

• 0, 3, f: reservierte Bereiche • die restlichen Bereiche sind nicht zugewiesen und dürfen von Administratoren benutzt werden, um weitere Multicast-Regionen zu definieren.[30] Beispiele für wohlbekannte Multicast-Adressen[31]: • ff01::1, ff02::1: All Nodes Adressen. Entspricht dem Broadcast.

• ff01::2, ff02::2, ff05::2: All Routers Adressen, adressiert alle Router in einem Bereich.

IPv6

15 Global Unicast Alle anderen Adressen gelten als Global-Unicast-Adressen. Von diesen sind jedoch bisher nur die folgenden Bereiche zugewiesen: • ::/96 (96 0-Bits) stand für IPv4-Kompatibilitätsadressen, welche in den letzten 32 Bits die IPv4-Adresse enthielten (dies galt nur für globale IPv4 Unicast-Adressen). Diese waren für den Übergang definiert, jedoch im RFC 4291 vom Februar 2006 für veraltet (engl. deprecated) erklärt.

• 0:0:0:0:0:ffff::/96 (80 0-Bits, gefolgt von 16 1-Bits) steht für IPv4 mapped (abgebildete) IPv6 Adressen. Die letzten 32 Bits enthalten die IPv4-Adresse. Ein geeigneter Router kann diese Pakete zwischen IPv4 und IPv6 konvertieren und so die neue mit der alten Welt verbinden.

• 2000::/3 (was dem binären Präfix 001 entspricht) stehen für die von der IANA vergebenen globalen Unicast-Adressen, also routbare und weltweit einzigartige Adressen.

• 2001-Adressen werden an Provider vergeben, die diese an ihre Kunden weiterverteilen.

• Adressen aus 2001::/32 (also beginnend mit 2001:0:) werden für den Tunnelmechanismus Teredo benutzt.

• Adressen aus 2001:db8::/32 dienen Dokumentationszwecken, wie beispielsweise in diesem Artikel, und bezeichnen keine tatsächlichen Netzteilnehmer.

• 2002-Präfixe deuten auf Adressen des Tunnelmechanismus 6to4 hin.

• Auch mit 2003, 240, 260, 261, 262, 280, 2a0, 2b0 und 2c0 beginnende Adressen werden von Regional Internet Registries (RIRs) vergeben; diese Adressbereiche sind ihnen z. T. aber noch nicht zu dem Anteil zugeteilt, wie dies bei 2001::/16 der Fall ist.[32] • 3ffe::/16-Adressen wurden für das Testnetzwerk 6Bone benutzt; dieser Adressbereich wurde gemäß RFC 3701 wieder an die IANA zurückgegeben.

• 64:ff9b::/96 kann für den Übersetzungsmechanismus NAT64 gemäß RFC 6146 verwendet werden.

Funktionalität Autokonfiguration Mittels der so genannten Stateless Address Autoconfiguration (SLAAC, zustandslose Adressenautokonfiguration) kann ein Host vollautomatisch eine funktionsfähige Internetverbindung aufbauen. Dazu kommuniziert er mit den für sein Netzwerksegment zuständigen Routern, um die notwendige Konfiguration zu ermitteln.

Ablauf Zur initialen Kommunikation mit dem Router weist sich der Host eine link-lokale Adresse zu, die im Falle einer Ethernet-Schnittstelle etwa aus deren Hardware-Adresse berechnet werden kann. Damit kann ein Gerät sich mittels des Neighbor Discovery Protocols (NDP, siehe auch ICMPv6-Funktionalität) auf die Suche nach den Routern in seinem Netzwerksegment machen. Dies geschieht durch eine Anfrage an die Multicast-Adresse ff02::2, über die alle Router eines Segments erreichbar sind (Router Solicitation).

Ein Router versendet auf eine solche Anfrage hin Information zu verfügbaren Präfixen, also Information über die Adressbereiche, aus denen ein Gerät sich selbst Unicast-Adressen zuweisen darf. Die Pakete, die diese Informationen tragen, werden Router Advertisements genannt. Sie besitzen ICMPv6-Typ 134 (0x86) und besitzen Informationen über die Lifetime, die MTU und das Präfix des Netzwerks. An ein solches Präfix hängt der Host den auch für die link-lokale Adresse verwendeten Interface Identifier an.

Die doppelte Vergabe einer Adresse wird durch die Duplicate Address Detection (DAD – Erkennung doppelt vergebener Adressen) verhindert. Die DAD muss von jedem Gerät nach der Wahl einer Adresse durchgeführt werden. Ein Gerät darf bei der Autokonfiguration nur unvergebene Adressen auswählen. Der DAD-Vorgang läuft

IPv6

16 ebenfalls ohne Benutzereingriff via NDP ab.

Gültigkeitsangaben Router können bei der Vergabe von Adresspräfixen begrenzte Gültigkeitszeiten mitgeben: Valid Lifetime und Preferred Lifetime.[33] Innerhalb der Valid Lifetime darf das angegebene Präfix zur Kommunikation verwendet werden; innerhalb der Preferred Lifetime soll dieses Präfix einem anderen, dessen Preferred Lifetime schon abgelaufen ist, vorgezogen werden.[34] Router verschicken regelmäßig Router Advertisements an alle Hosts in einem Netzsegment, für das sie zuständig sind, mittels derer die Präfix-Gültigkeitszeiten aufgefrischt werden; durch Änderung der Advertisements können Hosts umnummeriert werden. Sind die Router Advertisements nicht über IPsec authentifiziert, ist die Herabsetzung der Gültigkeitszeit eines einem Host bereits bekannten Präfixes auf unter zwei Stunden jedoch nicht möglich.[35] Verhältnis von Autokonfiguration zu DHCPv6 Die IPv6-Autokonfiguration unterscheidet sich konzeptionell von DHCP beziehungsweise DHCPv6. Während bei der Adressvergabe durch DHCPv6 (definiert in RFC 3315) von „Stateful Address Configuration“ gesprochen wird (sinngemäß: Adressvergabe, über die Buch geführt wird, etwa durch einen DHCP-Server), ist die Autokonfiguration eine „Stateless Address (Auto)Configuration“, da Geräte sich selbst eine Adresse zuweisen und über diese Vergabe nicht Buch geführt wird.

Mittels der Autokonfiguration können an Clients keine Informationen zu Host-, Domainnamen, DNS, NTP-Server etc. mitgeteilt werden, sofern diese nicht spezifische Erweiterungen von NDP unterstützen. Als Alternative hat sich der zusätzliche Einsatz eines DHCPv6-Servers etabliert; dieser liefert die gewünschten Zusatzinformationen, kümmert sich dabei aber nicht um die Adressvergabe. Man spricht in diesem Fall von Stateless DHCPv6 (vgl. RFC 3736). Dem Client kann mittels des Managed-Flags in der Antwort auf eine NDP-Router-Solicitation angezeigt werden, dass er eine DHCPv6-Anfrage stellen und somit die Zusatzinformationen beziehen soll.

Umnummerierung und Multihoming Unter IPv4 ist die Umnummerierung (Änderung des IP-Adressbereichs) für Netze ab einer gewissen Größe problematisch, auch wenn Mechanismen wie DHCP dabei helfen. Speziell der Übergang von einem Provider zum nächsten ohne ein „hartes“ Umschalten zu einem festen Zeitpunkt ist schwierig, da dies nur dann möglich ist, wenn das Netz für einen gewissen Zeitraum multihomed ist, also ein Netz gleichzeitig von mehr als einem Provider mit Internet-Anbindung und IP-Adressbereichen versorgt wird. Die Umgehung des Umnummerierens unter IPv4 mittels Border Gateway Protocol (BGP) führt zur Fragmentierung des Adressraums. Es geraten also viele, vergleichsweise kleine Netze bis in die Routingtabellen im Kernbereich des Internets, und die Router dort müssen darauf ausgelegt werden.

Der Vorgang der Umnummerierung wurde beim Design von IPv6 hingegen berücksichtigt, er wird in RFC 4076 behandelt. Mechanismen wie die IPv6-Autokonfiguration helfen dabei. Der parallele Betrieb mehrerer IP-Adressbereiche gestaltet sich unter IPv6 ebenfalls unproblematischer als unter IPv4, wie im Abschnitt Adressaufbau oben beschrieben. In RFC 3484 wird festgelegt, wie die Auswahl der Quell- und Zieladressen bei der Kommunikation geschehen soll und wie sie beeinflusst werden kann, wenn nun jeweils mehrere zur Verfügung stehen. Darüber hinaus darf diese Auswahl auch auf Anwendungsebene oder durch noch zu schaffende, z. B. die Verbindungsqualität einbeziehende Mechanismen getroffen werden. Das Ziel ist unter anderem, dem Betreiber eines Netzwerkes den unkomplizierten Wechsel zwischen Providern oder gar den dauerhaften Parallelbetrieb mehrerer Provider zu ermöglichen, um damit den Wettbewerb zu fördern, die Ausfallsicherheit zu erhöhen oder den Datenverkehr auf Leitungen mehrerer Anbieter zu verteilen.

IPv6

17

Mobile IPv6 Mobile IP wurde als Erweiterung des IPv6-Standards unter dem Namen „Mobile IPv6“ (RFC 6275) in IPv6 integriert. Die Kommunikation erfolgt dabei virtuell immer unabhängig von der aktuellen Position der Knotenpunkte.[36] Somit erlaubt Mobile IP Endgeräten, überall unter der gleichen IP-Adresse erreichbar zu sein, beispielsweise im heimischen Netzwerk und auf einer Konferenz. Normalerweise müssten dazu aufwändig Routing-Tabellen geändert werden. Mobile IPv6 benutzt stattdessen einen Schatten-Rechner („Home Agent“), der das Mobilgerät in seinem Heimnetz vertritt. Eingehende Pakete werden durch diesen Schattenrechner an die momentane Adresse („Care-of-Address“) des Mobilgeräts getunnelt. Der Home Agent bekommt die aktuelle Care-of-Address des Mobilgerätes durch „Binding Updates“ mitgeteilt, die das Gerät an den Home Agent sendet, sobald es eine neue Adresse im besuchten Fremdnetz erhalten hat. Mobile IP ist auch für IPv4 spezifiziert; im Gegensatz zu dieser Spezifikation benötigt Mobile IPv6 jedoch keinen Foreign Agent, der im Fremdnetz die Anwesenheit von Mobilgeräten registriert.

Header-Format Im Gegensatz zu IPv4 hat der IP-Kopfdatenbereich (Header) bei IPv6 eine feste Länge von 40 Bytes (320 Bits). Optionale, seltener benutzte Informationen werden in so genannten Erweiterungs-Kopfdaten (engl.: Extension Headers) zwischen dem IPv6-Kopfdatenbereich und der eigentlichen Nutzlast (engl. Payload) eingebettet. Der Kopfdatenbereich eines IPv6-Paketes setzt sich laut RFC 2460 aus den folgenden Feldern zusammen:

Feld

Länge

Der Kopfdatenbereich eines IPv6-Paketes

Inhalt

Version

4 Bit IP-Versionsnummer (6)

Traffic Class

8 Bit Für Quality of Service (QoS) verwendeter Wert. Eine Art Prioritätsvergabe.

Flow Label

20 Bit Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.

Payload Length

16 Bit Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte

Next Header

8 Bit Identifiziert den Typ des nächsten Kopfdatenbereiches, dieser kann entweder einen Erweiterungs-Kopfdatenbereich (siehe nächste Tabelle) oder ein Protokoll höherer Schicht (engl.: Upper Layer Protocol) bezeichnen, wie z. B. TCP (Typ 6) oder UDP (Typ 17).

Hop Limit

8 Bit Maximale Anzahl an Zwischenschritten über Router, die ein Paket zurücklegen darf; wird beim Durchlaufen eines Routers („Hops“) um eins verringert. Pakete mit null als Hop Limit werden verworfen. Es entspricht dem Feld Time to Live (TTL) bei IPv4.

Source Address

128 Bit Adresse des Senders

Destination Address 128 Bit Adresse des Empfängers

Wie im Next Header Feld verwiesen sind einige Extension Headers und ein Platzhalter definiert:

IPv6

18

Name

Typ Größe

Beschreibung

RFCs

Hop-By-Hop Options

0

variabel Enthält Optionen, die von allen IPv6-Geräten, die das Paket durchläuft, beachtet werden müssen. Wird z. B. für Jumbograms benutzt.

RFC 2460, RFC 2675

Routing

43

variabel Durch diesen Header kann der Weg des Paketes durch das Netzwerk beeinflusst werden, er wird unter anderem für Mobile IPv6 verwendet.

RFC 2460, RFC 6275, RFC 5095

Fragment

44

64 Bit

RFC 2460

Authentication Header (AH)

51

variabel Enthält Daten, welche die Vertraulichkeit des Paketes sicherstellen können (siehe IPsec).

RFC 4302

Encapsulating Security Payload (ESP)

50

variabel Enthält Daten zur Verschlüsselung des Paketes (siehe IPsec).

RFC 4303

Destination Options

60

variabel Enthält Optionen, die nur vom Zielrechner des Paketes beachtet werden müssen. RFC 2460

Mobility

135 variabel Enthält Daten für Mobile IPv6.

RFC 6275

No Next Header

59

RFC 2460

leer

In diesem Header können die Parameter einer Fragmentierung festgelegt werden.

Dieser Typ ist nur ein Platzhalter, um das Ende eines Header-Stapels anzuzeigen.

Die meisten IPv6-Pakete sollten ohne Extension Headers auskommen, diese können bis auf den Destination Options Header nur einmal in jedem Paket vorkommen. Befindet sich nämlich ein Routing Extension Header im Paket, so darf davor ein weiterer Destination Options Header stehen. Die Reihenfolge bei einer Verkettung ist bis auf die genannte Ausnahme die der Tabelle. Alle Extension Headers enthalten ein Next-Header-Feld, in dem der nächste Extension Header oder das Upper Layer Protocol genannt wird.

Die Größen dieser Header sind immer Vielfache von 64 Bit, auch sind die meisten Felder der Kopfdatenbereiche auf 64-Bit-Grenzen ausgerichtet, um Speicherzugriffe im Router zu beschleunigen. Des Weiteren werden (im Gegensatz zu IPv4) keine Prüfsummen mehr über die IP-Kopfdaten berechnet, es wird nur noch die Fehlerkorrektur in den Schichten 2 und 4 genutzt.

Paketgrößen Die Maximum Transmission Unit (MTU) darf in einem IPv6-Netzwerk 1280 Byte nicht unterschreiten. Somit unterschreitet auch die Path MTU (PMTU) diesen Wert nicht und es können Pakete bis zu dieser Größe garantiert ohne Fragmentierung übertragen werden. Minimale IPv6-Implementierungen verlassen sich auf diesen Fall.

Ein IPv6-fähiger Rechner muss in der Lage sein, aus Fragmenten wieder zusammengesetzte Pakete mit einer Größe von mindestens 1500 Byte zu empfangen. Für IPv4 beträgt dieser Wert nur 576 Byte. Im anderen Extrem darf ein IPv6-Paket auch fragmentiert laut Payload-Length-Feld im IPv6-Header die Größe von 65.575 Byte einschließlich Kopfdaten nicht überschreiten, da dieses Feld 16 Bit lang ist (216 − 1 Bytes zzgl. 40 Bytes Kopfdaten). RFC 2675 stellt aber über eine Option des Hop-by-Hop Extension Headers die Möglichkeit zur Verfügung, Pakete mit Größen bis zu 4.294.967.335 Byte, sogenannte Jumbograms zu erzeugen. Dies erfordert allerdings Anpassungen in Protokollen höherer Schichten, wie z. B. TCP oder UDP, da diese oft auch nur 16 Bit für Größenfelder definieren.

IPv6

19

Erweiterte ICMP-Funktionalität ICMPv6 (Protokolltyp 58) stellt für das Funktionieren von IPv6 unverzichtbare Funktionen zur Verfügung. Das Verbieten aller ICMPv6-Pakete in einem IPv6-Netzwerk durch Filter ist daher im Normalfall nicht durchführbar.

Insbesondere wird das Address Resolution Protocol (ARP) durch das Neighbor Discovery Protocol (NDP) ersetzt, welches auf ICMPv6 basiert. Dieses macht hierbei intensiv Gebrauch von Link-Local-Unicast-Adressen und Multicast, das von jedem Host beherrscht werden muss. Im Rahmen des NDP werden auch die automatische Adressvergabe und die automatische Zuordnung einer oder mehrerer Default-Routen über ICMPv6 abgewickelt, so stellt es die meisten Funktionen zur Verfügung, die oben unter IPv6-Autokonfiguration erklärt wurden. NDP kann auf die Möglichkeit weiterer Konfiguration durch DHCPv6 verweisen, welches allerdings UDP-Pakete benutzt.

Die Fragmentierung überlanger IPv6-Pakete erfolgt nicht mehr durch die Router, der Absender wird stattdessen mit Hilfe von ICMPv6-Nachrichten aufgefordert, kleinere Pakete, auch unter Zuhilfenahme des Fragment Extension Headers, zu schicken (siehe in diesem Zusammenhang Maximum Transmission Unit (MTU)). Idealerweise sollte ein IPv6-Host, bzw. eine Anwendung vor dem Versenden einer großen Anzahl von IPv6-Paketen eine Path MTU Discovery gemäß RFC 1981 durchführen, um Pakete mit maximal möglicher Größe verschicken zu können.

IPv6 und DNS Wegen der Länge der IP-Adressen, die an das menschliche Erinnerungsvermögen höhere Anforderungen stellt als IPv4-Adressen, ist IPv6 in besonderem Maße von einem funktionierenden Domain Name System (DNS) abhängig.

RFC 3596 definiert den Resource Record (RR) Typ AAAA (sprich: Quad-A), der genau wie ein A Resource Record für IPv4 einen Namen in eine IPv6-Adresse auflöst. Der Reverse Lookup, also die Auflösung einer IP-Adresse in einen Namen, funktioniert nach wie vor über den RR-Typ PTR, nur ist für IPv6 die Reverse Domain nicht mehr IN-ADDR.ARPA wie für IPv4, sondern IP6.ARPA und die Delegation von Subdomains darin geschieht nicht mehr an 8-Bit-, sondern an 4-Bit-Grenzen.

Ein IPv6-fähiger Rechner sucht in der Regel mittels DNS zu einem Namen zunächst nach dem RR-Typ AAAA, dann nach dem RR-Typ A. Laut der Default Policy Table in RFC 3484 wird die Kommunikation über IPv6 gegenüber IPv4 bevorzugt, falls festgestellt wird, dass für eine Verbindung beide Protokolle zur Verfügung stehen.

Die Anwendungsreihenfolge der Protokolle ist meistens aber auch im Betriebssystem und auf der Anwendungsebene, also z. B. im Browser, einstellbar.

Acht der dreizehn Root-Nameserver und mindestens zwei Nameserver der meisten Top-Level-Domains sind bereits über IPv6 erreichbar. Das übertragende Protokoll ist unabhängig von den übertragenen Informationen. Insbesondere kann man über IPv4 einen Nameserver nach AAAA-RRs fragen. Anbieter großer Portalseiten denken jedoch darüber nach, nur DNS-Anfragen, die über IPv6 gestellt werden, auch mit AAAA Resource Records zu beantworten, um Probleme mit fehlerhaft programmierter Software zu vermeiden. [37]

Übergangsmechanismen

IPv6

20

IPv6-Übergangsmechanismen 4in6

Tunneling von IPv4 in IPv6

6in4

Tunneling von IPv6 in IPv4

6over4

Transport von IPv6-Datenpaketen zwischen Dual-Stack Knoten über ein IPv4-Netzwerk

6to4

Transport von IPv6-Datenpaketen über ein IPv4-Netzwerk

AYIYA

Anything In Anything

Dual-Stack Netzknoten mit IPv4 und IPv6 im Parallelbetrieb 6rd

IPv6 rapid deployment

ISATAP

Intra-Site Automatic Tunnel Addressing Protocol

NAT64

Übersetzung von IPv4-Adressen in IPv6-Adressen

Teredo

Kapselung von IPv6-Datenpaketen in IPv4-UDP-Datenpaketen

SIIT

Stateless IP/ICMP Translation

IPv4 und IPv6 lassen sich auf derselben Infrastruktur, insbesondere im Internet, parallel betreiben. Für den Übergang werden also in der Regel keine neuen Leitungen, Netzwerkkarten oder Geräte benötigt, sofern dafür geeignete Betriebssysteme zur Verfügung stehen. Es gibt zurzeit kaum Geräte, welche IPv6, aber nicht gleichzeitig auch IPv4 beherrschen. Damit jedoch Geräte, die ausschließlich über IPv4 angebunden sind, auch mit Geräten kommunizieren können, die ausschließlich über IPv6 angebunden sind, benötigen sie Übersetzungsverfahren.

Um einen einfachen Übergang von IPv4- zu IPv6-Kommunikation im Internet zu ermöglichen, wurden verschiedene Mechanismen entwickelt. IPv6 wird dabei in der Regel hinzugeschaltet, ohne IPv4 abzuschalten. Grundlegend werden folgende drei Mechanismen unterschieden: • Parallelbetrieb (Dual-Stack) • Tunnelmechanismen • Übersetzungsverfahren Parallelbetrieb und Tunnelmechanismen setzten voraus, dass die Betriebssysteme der angebundenen Rechner beide Protokolle beherrschen.

Es gibt bereits heute Bereiche des Internet, die ausschließlich mittels IPv6 erreichbar sind, andere Teile, die über beide Protokolle angebunden sind und große Teile, die sich ausschließlich auf IPv4 verlassen. Im Folgenden werden die ersten beiden Bereiche zusammen als IPv6-Internet bezeichnet.

Dual-Stack Bei diesem Verfahren werden allen beteiligten Schnittstellen neben der IPv4-Adresse zusätzlich mindestens eine IPv6-Adresse und den Rechnern die notwendigen Routinginformationen zugewiesen. Die Rechner können dann über beide Protokolle unabhängig kommunizieren. Dieses Verfahren sollte der Regelfall sein, es scheitert derzeit oft daran, dass einige Router (meistens die Zugangsserver des Internetproviders oder die Heimrouter bei den Kunden) auf dem Weg zum IPv6-Internet noch keine IPv6-Weiterleitung eingeschaltet haben oder unterstützen.

IPv6

21

Tunnelmechanismen Um Router, die IPv6 nicht weiterleiten, auf dem Weg zum IPv6-Internet zu überbrücken, gibt es eine Vielzahl von Tunnelmechanismen. Dabei werden IPv6-Pakete in den Nutzdaten anderer Protokolle, meist IPv4, zu einer Tunnelgegenstelle übertragen, die sich im IPv6-Internet befindet. Dort werden die IPv6-Pakete Protokoll 41: IPv6-Pakete werden direkt in herausgelöst und zum Ziel via IPv6-Routing übertragen. Der Rückweg IPv4-Pakete gepackt, die dann zu einem funktioniert analog. Jedes Tunnelverfahren ist abhängig von der speziellen Tunnelserver geschickt werden Qualität des tunnelnden Protokolls: der Weg der Pakete zum Ziel ist wegen des Umwegs über die Tunnelgegenstelle meistens nicht optimal und die mögliche Nutzlast sinkt, da mehr Kopfdaten übertragen werden müssen.

Der klassische Weg ist es, bei einem so genannten Tunnelbroker eine solche Gegenstelle für den privaten Gebrauch gebührenfrei zu beantragen. Diese Gegenstelle bleibt fest, und man bekommt über den Tunnel immer den gleichen IPv6-Adressbereich zugewiesen. 6in4 benutzt zum Beispiel den Protokolltyp 41, um IPv6 direkt in IPv4 zu kapseln.

Für Linux ist die Erstellung eines solchen Tunnels mit den Interface-Konfigurationswerkzeugen möglich[38].

Komplizierter sind die Verfahren 6over4 oder ISATAP. Der Mechanismus 6to4 benötigt keine Absprache mit einer Gegenstelle, denn diese benutzt wohlbekannte, mehrfach im Internet vergebene IPv4-Adressen (Anycast), und die getunnelten Pakete werden zur nächstgelegenen Gegenstelle zugestellt und dort verarbeitet. Dem angebundenen Rechner steht dann ein IPv6-Adressbereich zur Verfügung, der sich aus dessen öffentlicher IPv4-Adresse errechnet. Auch ein solcher Tunnel kann auf aktuellen Linux-Rechnern mit öffentlicher IPv4-Adresse durch wenige Handgriffe eingerichtet werden.[39] Befindet sich ein Rechner in einem privaten IPv4-Adressbereich und findet beim Verbinden mit dem Internet NAT statt, so können Mechanismen wie AYIYA oder Teredo helfen. Diese Protokolle kapseln IPv6-Pakete als Nutzdaten meist in UDP-Paketen. Erlaubt ein Administrator diese Protokolle, kann schnell die Netzwerksicherheit in Gefahr geraten, wenn der Paketfilter die Nutzdaten nicht als IPv6-Pakete interpretieren kann und somit eventuell andere Paketfilterregeln umgangen werden.

Natürlich ist es auch möglich, IPv6 über allgemeinere Tunnelverfahren wie GRE, L2TP oder MPLS zu transportieren, insbesondere, wenn noch Routingprotokolle wie IS-IS parallel übertragen werden müssen.

Übersetzungsverfahren Kann auf einem Gerät IPv6 nicht aktiviert werden oder stehen nicht mehr genügend IPv4-Adressen zur Verfügung, können Verfahren wie Network Address Translation/Protocol Translation (NAT-PT, RFC 2766; inzwischen missbilligt[40]), oder Transport Relay Translation (TRT, RFC 3142) nötig werden, um zwischen beiden Protokollen zu übersetzen. Auch bieten Proxy-Server für einige Protokolle höherer Schichten die Möglichkeit einer Kommunikation zwischen beiden Welten.[41] Das Verfahren NAT64 bietet eine recht befriedigende Lösung, solange die Hauptanforderung darin besteht, von IPv6-Hosts initiierte Verbindungen an IPv4-Hosts weiterzuleiten.

IPv6

22

Technische Umsetzung Die RFC 6434 (IPv6 Node Requirements) gibt einen Überblick über Funktionen, die alle IPv6-Geräte umsetzen sollten, um eine maximale Interoperabilität zu gewährleisten. In diesem Dokument wird auf die jeweiligen Spezifikationen verwiesen.

Betriebssysteme Viele Betriebssysteme unterstützen inzwischen IPv6, ein Überblick folgt. Entscheidend für eine tunnelfreie Anbindung ist aber auch die Unterstützung durch die Firmware, bzw. die Betriebssysteme, auf den (DSL-)Routern bei Endkunden und den Zugangsservern bei den Providern, sie fehlt bei noch fast allen solchen Geräten. Systeme zur Lastverteilung, wie sie z. B. für große Webseiten eingesetzt werden, können in der vorhandenen Form für IPv6 nicht weiter benutzt werden, sofern sie auf NAT basieren.

AIX Seit AIX 4 Version 4.3 ist IPv6 implementiert, seit AIX 5L Version 5.2 ist auch Mobile IPv6 implementiert.

Android Android unterstützt IPv6 seit Version 2.1, jedoch nicht über die 3GPP-Schnittstelle.[42] Seit 2.3.4 werden IPv6 APN unterstützt. Es fehlt allerdings bei den meisten Endgeräten die Unterstützung im UMTS Chipset (bzw. der Firmware). Privacy Extensions werden unterstützt, müssen jedoch manuell eingeschaltet werden.[43] BSD-Varianten IPv6 wird von den BSDs bereits sehr lange und sehr umfassend unterstützt (zum Beispiel bei FreeBSD seit März 2000, bei NetBSD seit Dezember 2000 und bei OpenBSD seit Mitte 2000). Die Unterstützung ist zu großen Teilen dem KAME-Projekt zu verdanken, das seit 1998 einen freien Protokollstapel für IPv6 und IPsec für BSD-Betriebssysteme entwickelt hatte.

Cisco IPv6 wird ab IOS Version 12.2T experimentell, ab den Versionen 12.3 und 12.4 produktiv unterstützt. Auf älteren Geräten und Karten ist das IPv6-Forwarding aufgrund der Hardwareausstattung jedoch nur in Software, also mit Hilfe des Hauptprozessors möglich, was die Leistung gegenüber IPv4 deutlich vermindert.

HP-UX Seit der Version 11iv2 ist IPv6 Bestandteil des Basissystems, frühere 11.x-Versionen können mit TOUR (Transport Optional Upgrade Release) IPv6-fähig gemacht werden. iOS (Apple iPhone, iPad) Apple-Geräte mit iOS ab Version 4 unterstützen IPv6 im Dual-Stack-Modus[44]. Privacy Extensions werden jedoch erst ab Version 4.3 unterstützt[43][45].

Juniper Der Hersteller unterstützt IPv6 auf seinen Routern im Betriebssystem JunOS ab Version 5.1. Das IPv6-Forwarding geschah hier schon früh in Hardware, also ohne die Routing Engine (den Hauptprozessor) zu belasten. Für Firewall-Systeme, sowohl auf der ScreenOS Serie(ScreenOS <6.x), als auch auf der SRX Serie(JunOS <10.x) ist IPv6 unterstützt.

Linux Der Kernel bietet seit Version 2.6 eine IPv6-Unterstützung auf ähnlichem Niveau wie die BSD-Derivate, die produktiv einsetzbar ist. Der Kernel 2.4 bietet eine als experimentell ausgewiesene Unterstützung für IPv6, der jedoch noch wichtige Eigenschaften wie IPSec und Datenschutzerweiterungen (Privacy Extensions, RFC 3041) fehlen. Die meisten Linux-Distributionen haben im Auslieferungszustand auch mit Kerneln ab Version 2.6 die Privacy Extensions nicht eingeschaltet, diese können jedoch manuell aktiviert werden. Eine

IPv6

23 experimentelle IPv6-Implementation ist auch in der Kernel-Version 2.2 enthalten.

Mac OS X Seit Version 10.2 enthält auch Mac OS X Unterstützung für IPv6 auf der Basis von KAME. Erst seit Version 10.3 lässt sich IPv6 auch über die GUI konfigurieren. IPv6 ist standardmäßig aktiviert und unterstützt DNS-AAAA-Records. Die zur Apple-Produktfamilie gehörenden Airport-Extreme-Consumer-Router richten standardmäßig einen 6to4-Tunnel ein und fungieren als IPv6-Router. Die Privacy Extensions sind seit 10.7 (Lion) per Default aktiviert.

OpenVMS Mit HP TCP/IP Services for OpenVMS Version 5.5 unterstützt HP OpenVMS (ab Version 8.2) IPv6.

Solaris Seit der Version 8 ist die Unterstützung von IPv6 auch in dem Betriebssystem der Firma Sun Microsystems in begrenzter Form enthalten (die Implementierung und große Teile der Betriebssystemapplikationen erfordern immer noch, dass IPv4 konfiguriert ist), das für SPARC- und i386-Rechnerarchitekturen zur Verfügung steht.

Die Konfiguration erfolgt analog zu den Linux- und xBSD-Systemen.

Symbian OS Seit der Version 7.0 ist IPv6 fester Bestandteil des Systems. Es sind nur wenige Parameter über die GUI zu konfigurieren.

Windows 9x/ME Ein IPv6-Stack wird nur vom Hersteller Trumpet angeboten.

Windows NT 4.0 Microsoft bietet einen experimentellen Protokollstapel als Hotfix an. Dieser ist sehr alt, aber im Quellcode verfügbar.

Windows 2000 Microsoft bietet einen experimentellen Protokollstapel als Patch an, der sich aber ohne weitere Maßnahmen nur zum gegenseitigen Anpingen von Rechnern eignet. Der Patch ist für Systeme mit Service Pack 1 ausgelegt, mit einer kleinen Anpassung ist er aber auch auf Systemen mit den Service Packs 2 bis 4 anwendbar.[46] Windows XP Auf expliziten Wunsch (ipv6 install) kann man bei Windows XP einen experimentellen IPv6-Protokollstapel installieren. Ab Service Pack 1 hat dieser Protokollstapel „Production Quality“ und wird als Protokoll in den Netzwerkeigenschaften hinzugefügt. Ab Service Pack 2 kann IPv6 ebenfalls unter den Netzwerkeigenschaften hinzugefügt werden, mit dem Namen Internet Protokoll Version 6. Als DNS-Server können IPv6-Adressen mittels netsh eingetragen werden.[47] In Bezug auf den Mobility-Support gilt für Windows XP ab Service Pack 1 das Gleiche wie für Windows Server 2003: correspondent nodes sind verfügbar, mobile nodes und home agent nodes dagegen nicht. Im Rahmen des Mobile-IPv6-Technology-Preview-Programms sind entsprechende Erweiterungen verfügbar. Hat das System eine global routbare IPv4-Adresse, richtet Windows XP automatisch einen 6to4-Tunnel ein.[48] Bekommt Windows XP hingegen ein Präfix von einem IPv6-Router zugewiesen, sind Privacy Extensions standardmäßig aktiviert.

Windows Server 2003 Windows Server 2003 enthält einen „Production-Quality“-Protokollstapel, unterstützt DNS-AAAA-Records und IPv6-Routing. Die IPsec-Komponente ist jedoch noch als „für den Produktiveinsatz ungeeignet“ markiert, weil sie static keying verwendet und Internet Key Exchange (IKE) nicht unterstützt. Außerdem versteht die Bibliothek wininet.dll, auf die sich beispielsweise der Internet Explorer stützt, keine literalen IP-Adressen nach RFC 2732. Weiterhin ist der Mobility-Support unvollständig: Die Funktion eines correspondent node ist

IPv6

24 aktivierbar, mobile node und home agent node werden hingegen nicht angeboten. Jedoch sind auch hier aufgrund des Mobile IPv6 Technology Preview diesbezügliche Erweiterungen bereitgestellt. Windows Server 2003 kann wie Windows XP automatisch 6to4-Tunnel konfigurieren.

Windows Vista IPv6 wird hier von Anfang an unterstützt, da das Betriebssystem mit einer „Dual-IP-Layer-Architektur“ arbeitet und somit sowohl IPv4 als auch IPv6 unterstützt. Ist Internet Connection Sharing aktiviert, so fungiert Windows Vista auch als IPv6-Router und versendet entsprechende Router Advertisements zur Autokonfiguration von Clients. Als nichtroutender IPv6-Knoten sind Privacy Extensions im Auslieferungszustand aktiviert. Mobile IPv6 wird nicht unterstützt. Windows Vista löst Namen nur nach IPv6-Adressen auf, wenn eine physische Netzwerkschnittstelle eine global routbare IPv6-Adresse hat.

Windows Server 2008 IPv6 ist standardmäßig installiert und aktiviert. Viele Komponenten setzen eine Konfiguration beider Protokolle voraus. Wie in Windows Vista fehlt die Unterstützung für Mobile IPv6.

Windows 7 Wie in der Vorgängerversion Vista ist IPv6 auch in Windows 7 Teil der Standardinstallation und die Privacy Extensions sind standardmäßig aktiv, neu ist jedoch die Unterstützung von Mobile IPv6 (welche jedoch unvollständig ist, u. a. wird die Return Routability Procedure[49] nicht implementiert).

Windows 8 Windows 8 unterstützt sowohl IPv4 als auch IPv6. Die Priorität liegt auf IPv6. In Netzwerken, die beide Protokolle anbieten, entscheidet sich Windows 8 standardmäßig für die IPv6-Verbindung.[50] z/OS IBM z/OS unterstützt IPv6 seit September 2002 vollständig, schon 1998 gab es für den Vorgänger OS/390 einen experimentellen Stack.

Routing Während statisches Routing für IPv6 analog zu IPv4 eingerichtet werden kann, ergeben sich für die dynamischen Routingprotokolle einige Änderungen. Zwischen Autonomen Systemen wird das Border Gateway Protocol mit den Multiprotocol Extensions (definiert in RFC 4760) eingesetzt. Als Interior Gateway Protocol stehen OSPF in der Version 3, IS-IS mit Unterstützung von IPv6-TLVs und RIPng als offene Standards zur Verfügung. Die meisten Hersteller unterstützen für IS-IS Multi-Topology Routing, also gleichzeitiges Routing für beide Adressfamilien auch dann, wenn IPv4- und IPv6-Netz sich nicht genau überdecken. OSPFv3 realisiert dieses in einem sehr neuen Standard (RFC 5838) über verschiedene Instanzen für die verschiedenen Protokolle, war ursprünglich aber nur für IPv6 vorgesehen. Ein anderer Weg ist es unterschiedliche Routingprotokolle für die beiden Topologien zu verwenden, also etwa OSPFv2 für IPv4 und IS-IS für IPv6.

An Endsysteme können eine oder mehrere Default-Routen per Autokonfiguration oder DHCPv6 übergeben werden.

Mit DHCPv6-PD (Prefix Delegation) können auch Präfixe zwecks weiteren Routings zum Beispiel an Kundenrouter verteilt werden.

Da weder RSVP noch LDP für IPv6 ausreichend standardisiert sind [51][52], müssen sich MPLS-Netze weiter auf die Signalisierung mittels IPv4 verlassen, können jedoch, abhängig von der Implementierung, IPv6-Verkehr transportieren. Für IPv6 Multicast-Routing ist PIM geeignet.

IPv6

25

Paketfilter und Firewalls Für IPv6 müssen alle Filterregeln in Firewalls und Paketfiltern neu erstellt werden. Je nachdem, ob der filternde Prozess den IPv6-Datenverkehr überhaupt verarbeitet und abhängig von ihrer Default-Policy kann eine Firewall IPv6 ungehindert durchlassen. Auch einige Antivirenprogramme haben Zusätze, welche den Verkehr z. B. auf bestimmten TCP-Ports nach Signaturen durchsuchen. Für Linux kann die Filterung von IPv6 mit dem Programm ip6tables konfiguriert werden.

Deutliche Veränderungen in der Struktur der Filter gegenüber IPv4 können sich ergeben, sofern sie ICMP bzw.

ICMPv6 behandeln, da sich dessen Protokollnummer, Type- und Code-Zuordnungen sowie die Funktionalität verändern[53].

Das Feld Next Header im IPv6-Header eignet sich nicht in gleicher Weise wie das Protocol-Feld im IPv4-Header zum Identifizieren von Protokollen höherer Schicht, denn im Falle der Verwendung von Extension Headers verändert sich dessen Wert, beispielsweise bei Fragmentierung.

Einige Aspekte von NAT wurden in der Vergangenheit oft als Sicherheitsfunktion verstanden; NAT ist in IPv6 jedoch höchstens in Ausnahmefällen vorgesehen. RFC 4864 beschreibt Vorgehensweisen, welche diese Aspekte von NAT mit IPv6-Techniken abbilden[54]; so kann etwa die bei einigen Implementierungen bestehende Funktion von NAT, neu eingehende Verbindungen nicht an Rechner des Heimnetzes weiterzuleiten, durch einen zustandsbasierten Paketfilter im Router ersetzt werden. Dieser kann nach Wunsch neu eingehende Verbindungen generell abweisen oder diese nur für bestimmte Bereiche des Heimnetzes zulassen.

Anwendungssoftware Für Anwendungen wie Webbrowser oder E-Mail-Programme sind Änderungen in der Programmierung notwendig, damit sie über IPv6 kommunizieren können. Dies ist für die wichtigsten Programme, die mit aktuellen Betriebssystemen ausgeliefert werden, bereits geschehen, nicht aber bei weniger häufig benutzten Anwendungen.

In den meisten Fällen sind nur kleinere Änderungen notwendig, da die Anwendungen auf Protokolle höherer Schicht aufsetzen und diese sich kaum ändern. In vielen Betriebssystemen forderten die Programmierschnittstellen jedoch von der Anwendung, Sockets explizit zur IPv4-Kommunikation anzufordern. Neuere Schnittstellen sind in der Regel so gestaltet, dass IPv6-unterstützende Anwendungen automatisch auch IPv4 unterstützen. Verarbeiten die Anwendungen Inhalte mit URLs, wie sie in HTTP oder im Session Initiation Protocol (SIP) vorkommen, so müssen sie die URL-Notation von IPv6-Adressen unterstützen.

Zum Teil sind Änderungen notwendig, um die Leistung der Anwendung nicht zu mindern: So muss z. B. eine eventuell ermittelte, verminderte Path MTU an die Anwendung übergeben werden, um Fragmentierung zu vermeiden oder die Maximum Segment Size (MSS) im TCP-Header muss bei IPv6 gegenüber IPv4 verringert werden. Viele Programmiersprachen stellen spezielle Bibliotheken zur Verfügung, um den Umgang mit dem neuen Protokoll zu vereinfachen.

Administration Die Hauptarbeit der Umsetzung liegt auf der Verwaltungsebene: Administration und Support müssen geschult, Dokumentationen und Konfigurationen, z. B. für Routing, Firewalls, Netzwerküberwachung, das Domain Name System und evtl. DHCP, müssen während der Übergangsphase für beide Protokolle erstellt und gepflegt werden. In vielen Dokumentationen oder Fehlermeldungen muss im Nachhinein zwischen IPv4 und IPv6 unterschieden werden, wo noch vor einigen Jahren nur von IP die Rede war. Die Struktur des IP-Netzes wird zunächst quasi verdoppelt.

Oft haben IP-Adressen eine Bedeutung auf höherer Ebene. So tauchen sie in Logdateien oder Netflow-Daten auf, die teilweise mit Skripten wie beispielsweise Webalizer weiterverarbeitet werden, um Ansichten, Statistiken oder Abrechnungen zu erzeugen. Auch das Layout und die Skripte zur Erzeugung von Seiten wie Wikipedias „Versionsgeschichte“ müssten an die IPv6-Notation angepasst werden, da hier Nutzer zum Teil mit ihrer IP-Adresse

IPv6

26 identifiziert werden. Basiert eine Rechteverwaltung, wie z. B. in vielen Datenbanken, auf dem Zugriff durch festgelegte IP-Adressen, muss dies beim Zuschalten von IPv6 berücksichtigt werden.

Verbreitung und Projekte IPv6 setzt sich im praktischen Einsatz nur langsam durch. Die Adressvergabe für IPv6 ist im Juli 1999 vom experimentellen in den Regelbetrieb übergegangen[55] und immer mehr ISPs betreiben neben IPv4 auch IPv6 in ihrem Netz, dieses aber zumeist nur testweise und entweder ohne entsprechende Produkte oder ohne Verfügbarkeitsgarantien für ihre Kunden. Somit werden vollwertige IPv6-Anbindungen im Dual-Stack-Verfahren fast nur von kleineren Providern angeboten, so dass man im Moment auf Tunnel zurückgreifen muss. Die globale IPv6-Routingtabelle umfasste im Juni 2011 etwa 6000 Präfixe[56] und ungefähr 11 % aller im Internet verfügbaren Autonomen Systeme beteiligen sich am globalen IPv6-Routing.[57] Die meisten der großen Austauschpunkte für Internetverkehr erlauben und fördern neben IPv4 auch den Austausch von IPv6 über ihre Infrastruktur. Beim DE-CIX nutzten im April 2008 etwa 70 bis 80 von insgesamt 240 Providern IPv6.[58] Über den Internetknoten AMS-IX werden zu Spitzenzeiten 4,5 GBit/s IPv6-Traffic transportiert[59] (das sind etwas über 0,36 % des dort anfallenden Gesamtverkehrs (etwa 1,25 TBit/s)[60]); am DE-CIX liegt das Aufkommen bei bis zu 4,5 GBit/s (0,29 % des Gesamtverkehrs von etwa 1,55 TBit/s)[61].

Das IPv6 Forum[62] wurde im Juli 1999, der Deutsche IPv6 Rat im Dezember 2007 gegründet. Das IPv6 Forum Projekt IPv6-Ready[63] vergibt das IPv6-Logo in drei verschiedenen Stufen, die die Implementierung des Protokolls messen. Die Webseite listet dazu auch alle IPv6-fähigen Betriebssysteme auf.

Anzahl der Autonomen Systeme mit publizierten IPv6-Routen und Anzahl der publizierten Präfixe zwischen 2003 und heute

Anzahl der neuen Zuweisungen von IPv6-Adressraum an ISPs seit 2000

Derzeit sind 74 % aller IPv4-Adressen den nordamerikanischen Internet Registries und einigen US-amerikanischen Institutionen und Unternehmen direkt zugewiesen, während beispielsweise ganz China – mit inzwischen über 250 Millionen Internet-Benutzern (Stand: Juni 2008[64]) – vor Jahren noch nur über etwa so viele IP-Adressen verfügte wie ein Campus der University of California (Dezember 2004).[65] In Asien geht der Trend daher inzwischen dahin, bei Neubauten (zum Beispiel dem insbesondere Japan und die USA verbindenden NTT-Backbone) IPv6 auch zu benutzen. Das Bildungsnetzwerk CERNET2 in China ist derzeit das größte Netzwerk, das ausschließlich mit IPv6 betrieben wird. Es verbindet 25 Universitäten in 20 Städten.[66] Von Seiten der Endbenutzer wird IPv6 auch deshalb nicht gefordert, weil außer dem größeren Adressbereich die wesentlichen neuen Eigenschaften von IPv6 inzwischen mehr oder weniger erfolgreich nach IPv4 zurückportiert wurden (beispielsweise IPsec, QoS, Multicast; Umnummerierung und Autokonfiguration sind auch mittels DHCP möglich) – es gibt keine weitverbreitete Anwendung, die nur mit IPv6 funktionieren würde.

IPv6

27

Frühe Projekte In Deutschland federführend bei den Versuchen zu IPv6 war das JOIN-Projekt der Universität Münster. JOIN und der Verein zur Förderung eines Deutschen Forschungsnetzes (DFN) haben mit dem „6WiN“ einen ersten IPv6-Backbone in Deutschland aufgebaut. Das 6WiN ist ein ringförmiger Backbone durch Deutschland mit Querverbindung zwischen Essen und Berlin. Parallel dazu baute die Deutsche Telekom einen eigenen IPv6-Backbone zwischen den Standorten Darmstadt, Münster und Berlin auf und bot ihren Geschäftskunden im Rahmen eines Showcase-Projektes Anschluss daran an. Dieses Netz war in Münster und Berlin mit dem 6WiN verbunden. Ebenfalls in Münster lag der deutsche zentrale Zugang zum experimentellen IPv6-Netzwerk 6Bone, der am 7. Juni 2005 im Rahmen der planmäßigen sukzessiven Beendigung des weltweiten 6Bone-Betriebs abgeschaltet wurde. Zum 1. Januar 2006 wurde der IPv6-Betrieb im Deutschen Forschungsnetz vom JOIN-Projekt an das DFN-NOC übergeben.

Die Universität Wien, die auch den Vienna Internet Exchange (VIX)[67] und mehrere DNS-Server für die Zone „at.“ betreibt, spielte eine entscheidende Rolle bei der IPv6-Migration in Österreich. Beide Einrichtungen sind über IPv6 erreichbar bzw. bieten IPv6-Anbindung an.

Anbindung von Endnutzern Am 8. Juni 2011 fand der sogenannte World IPv6 Day statt, an dem der Dual-Stack-Betrieb auf mehreren großen Webseiten getestet wurde.[68] Der Test verlief weitestgehend problemlos.[69] Am Internetknotenpunkt DE-CIX war ein deutlich erhöhtes IPv6-Verkehrsaufkommen zu messen, das auch nach dem 8. Juni anhält.[70] Im Rahmen eines weiteren Aktionstages am 6. Juni 2012, dem World IPv6 Launch Day, haben mehr als 1400 Unternehmen weltweit ihre Webseiten dauerhaft auf den neuesten Standard umgestellt, so dass sie mit IPv4 und IPv6 erreichbar sind.[71][72] Seit dem 25. September 2012 rollt die Deutsche Telekom IPv6 auch an DSL-Endkundenanschlüssen aus.[73] Zunächst werden erst die sogenannten IP-Anschlüsse IPv6-fähig gemacht, wobei zunächst mit Neukunden begonnen wird, während Bestandskunden kein IPv6 erhalten werden [74].

Probleme Historisch Gerade zu Anfang wurden die IPv6-Standards häufig geändert, was dazu führte, dass bereits fertiggestellte Implementierungen mehrfach angepasst werden mussten.

Adressierung der Netzknoten Der größte Einschnitt bestand in der Einführung der IEEE-Norm EUI-64 für die Interface Identifier als Teil der Adressen. Um die Einzigartigkeit einer Adresse im Netzwerk auf einfache Weise zu garantieren, wurde vorher die MAC-Adresse einer Schnittstelle unverändert in die IPv6-Adresse übernommen, nun wird die MAC-Adresse gemäß EUI-64 in veränderter Form in die IPv6-Adresse geschrieben; dabei wird aufgrund einer Verwechslung in RFC 3513 der Algorithmus, um EUI-64-Namen aus EUI-48-Namen zu berechnen, fälschlicherweise auf MAC-48-Namen angewandt.[75]

Modifiziertes EUI-64

Die beschriebenen Verfahren führen zu einem statischen hostspezifischen Teil der IPv6-Adresse eines autokonfigurierten IPv6-Knotens. Datenschützer waren besorgt, dass auf diese Weise Nutzer über unterschiedliche

IPv6

28 Netzwerke hinweg identifizierbar werden und dies beispielsweise für Marketingmaßnahmen oder staatliche Interventionen ausgenutzt werden könnte. Die IETF definierte deshalb nachträglich die Datenschutzerweiterungen (Privacy Extensions) gemäß RFC 3041, später RFC 4941 (siehe auch Adressaufbau von IPv6). Diese Privacy-Extensions generieren bei der Autokonfiguration via SLAAC einen zufälligen hostspezifischen Teil. Da aber die ersten 64 Bit der IPv6-Adresse eines Netzes (z.B. eines Haushaltes) weiterhin erhalten bleiben, muss ein weiterer Schutz durch regelmäßiges Wechseln des netzspezifischen Teils gewährleistet sein (wie heute bei DSL-Anschlüssen).

Integration ins Domain Name System Lange Zeit war die Anpassung des DNS zur Eingliederung von IPv6 uneinheitlich. 1995 wurde in RFC 1886 zunächst der Record-Typ AAAA für die Auflösung von DNS-Namen in IPv6-Adressen definiert, der funktional äquivalent zum A-Record für IPv4 ist. Im Jahr 2000 wurde AAAA in RFC 2874 durch den Record-Typ A6 abgelöst, der vor allem das Umnummerieren vereinfachen sollte, indem die IP-Adresse stückweise auf das DNS abgebildet wurde, jedoch nie frei von technischen Problemen war. 2003 wurde das Verfahren A6 daher in RFC 3596 wieder nach „experimentell“ zurückgestuft, und AAAA wurde der neue, alte Standard.

Noch mehr Schwierigkeiten bereitete die Rückwärtsauflösung („Reverse“-Auflösung) von IPv6-Adressen, da es aufgrund der Wechsel der Standards PTR-Records in zwei verschiedenen Zonen gab, unterhalb von ip6.arpa und ip6.int. Aufgrund der traditionellen Nutzung der TLD .arpa für die Rückwärtsauflösung bei IPv4 hat sich die erstere Variante gegen ip6.int durchgesetzt, woraufhin die Delegierung von ip6.int im Juni 2006 gelöscht wurde.

Die Auflösung ist vom Protokolltyp der Anfrage völlig unabhängig: Wird eine DNS-Anfrage über IPv4 gestellt, so kann selbstverständlich auch ein AAAA-Record zurückgegeben werden, und über IPv6 erreichbare Nameserver geben auch über IPv4-Adressen (A-Records) Auskunft.

Aktuell Link-lokale Adressen Eine mögliche Designschwäche von IPv6 ist, dass die Adressräume für link-lokale Adressen grundsätzlich nicht getrennt sind. Will man link-lokale Adressen also auf Anwendungsebene zur Kommunikation zwischen Rechnern im gleichen Netzwerksegment verwenden, ergibt sich das Problem, dass es für diese nicht ausreichend ist, die IP-Adresse im Ziel-Feld einzutragen, sondern auch ein Zone Index nach RFC 4007 (in den meisten Fällen ein Interface) angegeben werden muss, da sich der link-lokale Adressraum mehrerer Interfaces überschneidet. Es hängt daher davon ab, ob die IPv6-Unterstützung der verwendeten Anwendung das Konzept der Zonen-Indizes kennt, ob link-lokale Adressen zu diesem Zweck eingesetzt werden können.

Autokonfiguration und DNS Im Zusammenspiel des IPv6-Autokonfigurationsmechanismus mit dem Domain Name System ergeben sich bis heute Probleme. Ursprünglich fehlte die Möglichkeit ganz, im Rahmen der Autokonfiguration Netzknoten auch zu verwendende DNS-Server und weitere DNS-bezogene Informationen wie DNS-Suchpfade mitzuteilen, wie das für IPv4 im Rahmen von DHCP üblich ist. Heute bestehen im Wesentlichen zwei Lösungen für das Problem: • Mittels des Managed-Flags in Router-Advertisements können Netzknoten angewiesen werden, bei einem DHCPv6-Server nach weiterer Konfiguration zu fragen. DHCPv6-Server können über die Multicastadressen ff02::1:2 und ff05::1:3 angesprochen werden. Im Gegensatz zu DHCP muss der DHCPv6-Server keine Protokolle über solche Anfragen führen, die Konfiguration kann also weiterhin zustandslos erfolgen.

• Die NDP-Spezifikation erlaubt die Angabe zusätzlicher Felder in Router Advertisements. Die so genannten RDNSS- (Recursive DNS Server) und DNSSL-Erweiterungen (DNS Search List) spezifizieren eine Möglichkeit, DNS-Server und DNS-Suchpfade im Rahmen der Router Advertisements zu versenden.

IPv6

29 Insbesondere RDNSS und DNSSL sind erst im November 2010 mit Erscheinen von RFC 6106 standardisiert worden.

Die Unterstützung für die obengenannten Lösungen ist unter den verschiedenen Implementierungen uneinheitlich.

Beispielsweise unterstützen Microsoft Windows Vista und 7 nur DHCPv6 und für Linux-Systeme sind zwar alle Verfahren verfügbar, jedoch oft von Distributoren nicht vorinstalliert. Mac OS X unterstützt allerdings seit der Version 10.7 (Lion) sowohl DHCPv6 als auch RDNSS. Multihoming Einige Wissenschaftler wie beispielsweise John Day[76] kritisieren eine unzureichende Berücksichtigung von Multihoming im Design von IPv6. Durch die Identifikation von Schnittstellen anstelle von Hosts durch IP-Adressen treten Effizienzschwierigkeiten beim Routing auf: Die Zuteilung von providerunabhängigem Adressraum (PI Address Space) verlängert Routingtabellen und repliziert damit Probleme von IPv4; im Falle von providerabhängiger mehrfacher Adressierung bedarf es Anpassungen auf höheren Protokollschichten, um den Ausfall einer der Anbindungen kompensieren zu können – etwa kurzfristige Änderungen von DNS-Einträgen.

IPv5 Ein Protokoll mit dem Namen IPv5 gibt es nicht. Allerdings hat die IANA die IP-Versionsnummer 5 für das Internet Stream Protocol Version 2 (ST2, definiert in RFC 1819) reserviert, das gegenüber IPv4 verbesserte Echtzeitfähigkeiten haben sollte, dessen Entwicklung dann aber aus Kosten-Nutzen-Erwägungen zugunsten von IPv6 und RSVP eingestellt wurde.

Literatur Grundlegende Spezifikationen • • • • •

RFC 2460, Internet Protocol, Version 6 (IPv6) Specification RFC 4861, Neighbor Discovery for IP version 6 (IPv6) RFC 4862, IPv6 Stateless Address Autoconfiguration RFC 4291, IP Version 6 Addressing Architecture RFC 5942, IPv6 Subnet Model

Sekundärliteratur • Reiko Kaps: WAN-Auffahrt – Mit dem IPv6-Netz online gehen. in: c’t Heise, Hannover 2008,6. ISSN 0724-8679 [77] .

• Silvia Hagen: IPv6. Grundlagen – Funktionalität – Integration. Sunny Edition, Maur 2009. ISBN 978-3-9522942-2-2.

• Joseph Davies: Understanding IPv6 (englisch). 2. Aufl. Microsoft Press, Redmond 2008. ISBN 978-0-7356-2446-7.

• Anatol Badach: Technik der IP-Netze. TCP/IP incl. IPv6. Funktionsweise, Protokolle und Dienste. Hanser Fachbuch. 2. Aufl. Hanser, München 2007. ISBN 3-446-21935-8.

• Mathias Hein: IPv6, Das Migrationshandbuch. Franzis, Point 2003. ISBN 3-7723-7390-9.

• Herbert Wiese: Das neue Internetprotokoll IPv6. Hanser Fachbuch. Hanser, München 2002. ISBN 3-446-21685-5.

• Hans P. Dittler: IPv6. Das neue Internet-Protokoll. Technik, Anwendung, Migration.. 2. Aufl. Dpunkt, Heidelberg 2002. ISBN 3-89864-149-X. • Christian Huitema: IPv6 – die neue Generation. Addison-Wesley, München 2000. ISBN 3-8273-1420-8.

IPv6

30

Weblinks • • • • • •

Allokation des IPv6-Adressbereiches im Überblick [78] (englisch) CRE197 IPv6 [79] Ausführlicher, deutschsprachiger Podcast über IPv6 Verzeichnis von über IPv6 erreichbaren Websites [80] (englisch) Messungen von Hurricane Electric zur Verbreitung von IPv6 [81] (englisch) Regionenspezifische IPv6-Zugriffs- und Latenzstatistiken für Google-Dienste [82] (benötigt aktiviertes JavaScript) Test your IPv6 [83] (englisch) – IPv6-Verbindungstest-Seite (benötigt aktiviertes JavaScript)

Einzelnachweise [1] Heise.de Datenschützer besorgt über IPv6 (http:/ / www. heise. de/ netze/ meldung/ Datenschuetzer-besorgt-ueber-IPv6-1382812. html) [2] Pressemitteilung der Regional Internet Registries: NRO and OECD Highlight that IPv6 Deployment is Too Slow (http:/ / www. nro. net/ news/ nro-and-oecd-highlight-that-ipv6-deployment-is-too-slow) [3] APNIC: Two /8s allocated to APNIC from IANA (http:/ / www. apnic. net/ publications/ news/ 2011/ delegation) Meldung vom 1. Febr. 2011 [4] ICANN: Global Policy for the Allocation of the Remaining IPv4 Address Space (http:/ / www. icann. org/ en/ general/ allocation-remaining-ipv4-space. htm) [5] Twitter-Verlautbarung der IANA (https:/ / twitter. com/ theiana/ status/ 33170437856825344) zum Ende des IPv4-Adressraums [6] IANA: (http:/ / www. iana. org/ assignments/ ipv4-address-space/ ipv4-address-space. xml) [7] APNIC: APNIC IPv4 Address Pool Reaches Final /8 (http:/ / www. apnic. net/ publications/ news/ 2011/ final-8) [8] RIPE NCC: (http:/ / www. ripe. net/ internet-coordination/ news/ ripe-ncc-begins-to-allocate-ipv4-address-space-from-the-last-8) [9] APNIC: Policies for IPv4 address space management in the Asia Pacific region (http:/ / www. apnic. net/ policy/ add-manage-policy#9. 10), Abschnitt 9.10.1 [10] RIPE NCC: (http:/ / www. ripe. net/ ripe/ docs/ ripe-553#-----use-of-last-8-for-pa-allocations) [11] RFC 6434, Abschnitt 11 [12] IPsec wurde zusätzlich auch für IPv4 spezifiziert, dort ist die Umsetzung aber optional, während sie für IPv6 zunächst in RFC 4294 vorgeschrieben war. Diese Vorschrift wurde aber mit RFC 6434 zurückgenommen.

[13] siehe etwa RFC 2775, Abschnitt 5.1 [14] RFC 3724, Abschnitt 2 [15] RFC 2993, Abschnitt 6 [16] Stefan Wintermeyer: Asterisk 1.4 + 1.6. Addison-Wesley, München; 1. Auflage 2009. Kapitel 8. Online unter (http:/ / das-asterisk-buch. de/ 1. 6/ sip. html#sip-nat-problem) [17] Eine Diskussion des Problems findet sich in einem Internet-Draft von W. Eddy, Comparison of IPv4 and IPv6 Header Overhead (http:/ / tools. ietf. org/ html/ draft-eddy-ipv6-overhead-00).

[18] German IPv6 Council: Leitlinien IPv6 und Datenschutz (http:/ / www. ipv6council. de/ documents/ leitlinien_ipv6_und_datenschutz. html) [19] RFC 3986, Abschnitt 3.2.2 [20] IPv6 Address Allocation and Assignment Policy (http:/ / www. ripe. net/ ripe/ docs/ ripe-512#minimum_allocation) von APNIC, ARIN, RIPE NCC, Abschnitt 4.3 [21] IPv6 Address Allocation and Assignment Policy, Abschnitt 5.4.1 (http:/ / www. ripe. net/ ripe/ docs/ ripe-552#assignment_size) [22] IPv6 Address Allocation and Assignment Policy, Abschnitt 5.4.2 (http:/ / www. ripe. net/ docs/ ripe-512#assignment_multiple) [23] RFC 4291, Abschnitt 2.5.4 [24] RFC 4291, Abschnitt 2.5.2 [25] http:/ / tools. ietf. org/ html/ rfc4291#section-2. 5. 6 [26] Dazu siehe auch das Skript auf (http:/ / www. kame. net/ ~suz/ gen-ula. sh) (Online-Version: (http:/ / www. sixxs. net/ tools/ grh/ ula/ )) [27] http:/ / tools. ietf. org/ html/ draft-ietf-ipv6-ula-central-02 [28] RFC 2373, Abschnitt 2.7 [29] RFC 3307, Abschnitt 4.1 [30] RFC 4291, Abschnitt 2.7 [31] IANA: Internet Protocol Version 6 Multicast Addresses (http:/ / www. iana. org/ assignments/ ipv6-multicast-addresses) [32] IANA: IPv6 Unicast Address Assignments (http:/ / www. iana. org/ assignments/ ipv6-unicast-address-assignments) [33] RFC 2461, Abschnitt 4.6.2 [34] RFC 2462, Abschnitt 4 [35] RFC 4862, Abschnitt 5.5.3 e) [36] Herbert Wiese: Das neue Internetprotokoll IPv6. Hanser Verlag, München 2002. ISBN 3-446-21685-5, S. 197.

[37] "Hack" für IPv6-Erreichbarkeit großer Content-Anbieter (http:/ / www. heise. de/ netze/ meldung/ Weiterer-Hack-fuer-IPv6-Erreichbarkeit-grosser-Content-Anbieter-Update-964947. html) [38] Peter Bieringer: Linux IPv6 Howto, Kapitel 9.3 (http:/ / mirrors. deepspace6. net/ Linux+ IPv6-HOWTO-de/ conf-ipv6-in-ipv4-point-to-point-tunnels. html)

IPv6

31 [39] Peter Bieringer: Linux IPv6 Howto, Abschnitt 9.4 (http:/ / mirrors. deepspace6. net/ Linux+ IPv6-HOWTO-de/ configuring-ipv6to4-tunnels. html) [40] RFC 4966, Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status [41] IPv6-Testbetrieb für heise online – Web-Site per Proxy IPv6-fähig machen (http:/ / www. heise. de/ netze/ IPv6-Testbetrieb-fuer-heise-online-Update--/ artikel/ 134488/ 0) [42] Android Issue 3389: Full IPv6 Android support (https:/ / code. google. com/ p/ android/ issues/ detail?id=3389) [43] heise Netze: IPv6: Privacy Extensions einschalten (http:/ / www. heise. de/ netze/ artikel/ IPv6-Privacy-Extensions-einschalten-1204783. html?artikelseite=4) [44] Iljitsch van Beijnum: iOS 4 IPv6 (http:/ / lists. apple. com/ archives/ ipv6-dev/ 2010/ Jun/ msg00036. html) [45] heise Netze: iOS 4.3: Apple bessert beim Datenschutz nach (http:/ / www. heise. de/ newsticker/ meldung/ iOS-4-3-Apple-bessert-beim-Datenschutz-nach-1206770. html) [46] Schritte zur Anpassung des Windows-2000-Protokollstapels an SP2 bis 4: (http:/ / www. microsoft. com/ Downloads/ details. aspx?FamilyID=27b1e6a6-bbdd-43c9-af57-dae19795a088& displaylang=en) [47] TCP/IP-Grundlagen für Microsoft Windows: Unterstützung für DNS (http:/ / www. microsoft. com/ germany/ technet/ datenbank/ articles/ 600912. mspx) [48] Microsoft TechNet: Routing IPv6 Traffic over IPv4 Infrastructure: TCP/IP (http:/ / technet. microsoft. com/ en-us/ library/ cc756770. aspx) [49] RFC 3775, Abschnitt 5.2.5 [50] Connecting with IPv6 in Windows 8. (http:/ / blogs. msdn. com/ b/ b8/ archive/ 2012/ 06/ 05/ connecting-with-ipv6-in-windows-8. aspx) MSDN Blog, abgerufen am 12. August 2012 (en).

[51] Vishwas Manral: RSVP-TE IPv6 (http:/ / tools. ietf. org/ html/ draft-manral-mpls-rsvpte-ipv6-01) [52] Vishwas Manral: Updates to LDP for IPv6 (http:/ / tools. ietf. org/ html/ draft-manral-mpls-ldp-ipv6-04) [53] RFC 4890 [54] Cisco Systems: IPv6 Local Network Protection with Cisco IOS Routers and Switches (http:/ / replay. web. archive. org/ 20090608180824/ http:/ / www. cisco. com/ en/ US/ prod/ collateral/ iosswrel/ ps6537/ ps6553/ white_paper_c11-474201. html) (Version vom 8. June 2009 im Internet Archive) [55] IANA: Delegation of IPv6 address space (http:/ / www. iana. org/ ipaddress/ ipv6-announcement), Mailinglistenbeitrag vom 14. Juli 1999 [56] Geoff Huston: AS2 IPv6 BGP Table Data (http:/ / bgp. potaroo. net/ v6/ as2. 0/ index. html) [57] Mike Leber: Global IPv6 Deployment Progress Report (http:/ / bgp. he. net/ ipv6-progress-report. cgi) [58] APA, AP: Internet-Protokoll IPv6 kommt endlich in Bewegung (http:/ / derstandard. at/ ?url=/ ?id=3326899), derstandard.at, 6. Mai 2008 [59] AMS-IX sFlow Statistics (http:/ / www. ams-ix. net/ sflow-stats/ ) [60] AMS-IX Traffic Statistics (http:/ / www. ams-ix. net/ statistics/ ) [61] DE-CIX Traffic Statistics (http:/ / www. de-cix. net/ about/ statistics/ ), Stand im Artikel: 27. Juli 2012 [62] Website des IPv6 Forum (http:/ / www. ipv6forum. org/ ) [63] Website IPv6ready (http:/ / www. ipv6ready. org/ ) [64] Heise Online: China hat nun weltweit die meisten Internetnutzer (http:/ / www. heise. de/ newsticker/ meldung/ 113307) (24. Juli 2008) [65] Liu Baijia: China launches new generation Internet (http:/ / www. chinadaily. com. cn/ english/ doc/ 2004-12/ 27/ content_403512. htm) (China Daily, 27. Dezember 2004) [66] Ingrid Marson: China launches largest IPv6 network (http:/ / news. com. com/ China+ launches+ largest+ IPv6+ network/ 2100-1025_3-5506914. html) (CNET News.com, 29. Dezember 2004) [67] Website des Vienna Internet Exchange (http:/ / www. vix. at/ ) [68] Offizielle Website des World IPv6 Day (http:/ / isoc. org/ wp/ worldipv6day/ ) [69] heise Netze: World IPv6 Day: Viel Aufmerksamkeit und kaum Probleme (http:/ / www. heise. de/ netze/ meldung/ World-IPv6-Day-Viel-Aufmerksamkeit-und-kaum-Probleme-1257943. html) [70] heise Netze: World IPv6 Day: Unerwartete Nachwirkungen (http:/ / www. heise. de/ netze/ meldung/ World-IPv6-Day-Unerwartete-Nachwirkungen-1259275. html) [71] World IPv6 Launch Day: Inhalteanbieter schalten IPv6 dazu (http:/ / www. heise. de/ newsticker/ meldung/ World-IPv6-Launch-Day-Inhalteanbieter-schalten-IPv6-dazu-1590409. html) bei heise.de, 5. Juni 2012 (abgerufen am 6. Juni 2012).

[72] IPv6-Standard: Eine unsichtbare Revolution für das Internet (http:/ / www. welt. de/ wirtschaft/ webwelt/ article106417530/ Eine-unsichtbare-Revolution-fuer-das-Internet. html) bei welt.de, 5. Juni 2012 (abgerufen am 6. Juni 2012).

[73] 'Twitter-Meldung der Telekom' (https:/ / twitter. com/ Telekom_hilft/ status/ 251602258318479360) [74] http:/ / www. heise. de/ netze/ meldung/ Telekom-Kein-IPv6-fuer-Vertraege-mit-Analog-und-ISDN-Telefonie-1763557. html [75] Diskussion über EUI-64, EUI-48 und MAC-48 (http:/ / www. atm. tut. fi/ list-archive/ ipng/ msg10039. html) auf der IETF-IPng-Arbeitsgruppen-Mailingliste [76] Deutschlandfunk: "Was wir brauchen, ist etwas ganz anderes als das, was wir bekommen haben" (http:/ / www. dradio. de/ dlf/ sendungen/ computer/ 1463876/ ) [77] http:/ / dispatch. opac. d-nb. de/ DB=1. 1/ CMD?ACT=SRCHA& IKT=8& TRM=0724-8679 [78] http:/ / www. iana. org/ assignments/ ipv6-address-space [79] http:/ / cre. fm/ cre197 [80] http:/ / sixy. ch/

IPv6

32 [81] http:/ / bgp. he. net/ ipv6-progress-report. cgi [82] http:/ / www. google. de/ ipv6/ statistics. html#tab=per-country-ipv6-adoption [83] http:/ / test-ipv6. com/

Normdaten (Sachbegriff): GND: 4462513-3 (http://d-nb.info/gnd/4462513-3)

IPv4 IPv4 im TCP/IP‑Protokollstapel: Anwendung Transport Internet

HTTP

IMAP SMTP DNS …

TCP

UDP IPv4

Netzzugang Ethernet Token Token FDDI …

Bus Ring

IPv4 (Internet Protocol Version 4), früher einfach IP, ist die vierte Version des Internet Protocols (IP). Es war die erste Version des Internet Protocols, welche weltweit verbreitet und eingesetzt wurde, und bildet eine wichtige technische Grundlage des Internets. Es wurde in RFC 791 im Jahr 1981 definiert.

Adressformat → Hauptartikel: IP-Adresse IPv4 benutzt 32-Bit-Adressen, daher sind maximal 4.294.967.296 eindeutige Adressen möglich. IPv4-Adressen werden üblicherweise dezimal in vier Blöcken geschrieben, zum Beispiel 207.142.131.235. Je Block werden 8 Bit zusammengefasst; somit ergibt sich für jeden Block ein Wertebereich von 0 bis 255. Bei der Weiterentwicklung IPv6 werden 128-Bit-Adressen verwendet.

Eine IP-Adresse unterteilt sich in einen Netzwerkteil und einen Host-(Adressen-)teil. Rechner sind im selben IP-Netz, wenn der Netzwerkteil ihrer Adresse gleich ist – das ist eine Voraussetzung, dass diese Rechner direkt miteinander kommunizieren können, also z. B. über einen Hub, einen Switch oder mittels eines Crosslink-Kabels. Im selben Netz darf keine Host-Adresse doppelt vergeben sein.

Für die Kommunikation zwischen unterschiedlichen Netzen wird ein Router benötigt. Den Adressteil vergibt der zuständige Administrator für jedes teilnehmende Gerät unterschiedlich. Die Netzadresse vergibt der Besitzer oder Planer des Netzwerks. Im Internet ist das IANA (Internet Assigned Numbers Authority) für die Vergabe der Netzadressen zuständig.

Die genaue Aufteilung zwischen Netzwerkteil und Adressteil wird durch die Subnetzmaske bestimmt (zum Beispiel 255.255.255.0). In der CIDR-Notation wird dies als 192.168.0.23/24 geschrieben, wobei die „24“ bedeutet, dass die ersten 24 Bits der Subnetzmaske gleich 1 sind. Die Bits der Subnetzmaske, die (in binärer Schreibweise) „1“ sind, legen die Stellen der IP-Adresse fest, die zum Netzanteil gehören.

Beispiel:

IPv4

33

IP-Adresse

192.168.0.

23

→ 11000000.10101000.00000000. 00010111

Subnetzmaske 255.255.255. 0 Netzanteil

→ 11111111.11111111.11111111. 00000000

Hostanteil

Netzanteil

Hostanteil

Netzklassen IP-Netzklassen Bit 31-28 27-24

23-16

15-8

7-0

Class A: Netze 0.0.0.0/8 bis 127.255.255.255 0 … 8-Bit-Netz

24-Bit-Host

Class B: Netze 128.0.0.0/16 bis 191.255.255.255 1 0 … 16-Bit-Netz

16-Bit-Host

Class C: Netze 192.0.0.0/24 bis 223.255.255.255 1 1 0 … 24-Bit-Netz

8-Bit-Host

Class D: Multicast-Gruppen 224.0.0.0/4 bis 239.255.255.255 1110

28-Bit-Multicast-Gruppen-ID

Class E: Reserviert 240.0.0.0/4 bis 255.255.255.255 1111

28 Bit reserviert für zukünftige Anwendungen

Früher gab es fest vorgeschriebene Einteilungen für Netzwerkklassen mit einer festen Länge. Da diese Einteilung sehr unflexibel ist, wird seit 1993 vor allem im WAN hauptsächlich das Classless Inter-Domain Routing-Verfahren durchgeführt, welches bitvariable Netzmasken ermöglicht. Viele netzwerkfähige Betriebssysteme bestimmen die Standardnetzmaske anhand der alten Klassifikation, da im lokalen Netz überwiegend noch mit den Klassen gearbeitet wird.

Die maximale Anzahl der zu vergebenen Host-Adressen in einem Netz ist 2Anzahl Bits der Hostadresse − 2 Zwei Host-Adressen fallen immer weg – die erste Adresse (zum Beispiel 192.168.0.0) bezeichnet das Netz selber, die letzte Adresse (zum Beispiel 192.168.0.255) ist für den Broadcast (alle Teilnehmer werden angesprochen) reserviert.

Besondere Netzwerkadressen Einige Klassen von Netzwerkadressen sind für spezielle Zwecke reserviert. Siehe RFC 5735:

IPv4

34

Adressblock (Prefix)

Verwendung

Referenz

0.0.0.0/8

Aktuelles Netzwerk

RFC 1122

10.0.0.0/8

1x Privates Netzwerk der Klasse A

RFC 1918

100.64.0.0/10

Shared Transition Space

RFC 6598

127.0.0.0/8

Loopback (Lokaler Computer)

RFC 1122

169.254.0.0/16

Privates Netzwerk (link local), APIPA

RFC 3927

172.16.0.0/12

16x Private Netzwerke der Klasse B

RFC 1918

192.0.0.0/24

IETF Protocol Assignments

RFC 5735

192.0.2.0/24

Test-Netzwerke

RFC 5735

192.88.99.0/24

IPv6 zu IPv4 Relay

RFC 3068

192.168.0.0/16

256x Private Netzwerke der Klasse C

RFC 1918

198.18.0.0/15

Netzwerk-Benchmark-Tests

RFC 2544

198.51.100.0/24

Test-Netzwerke

RFC 5735

203.0.113.0/24

Test-Netzwerke

RFC 5735

224.0.0.0/4

Multicasts (ehemals Klasse-D-Netzwerk) RFC 3171

240.0.0.0/4

Reserviert (ehemals Klasse-E-Netzwerk) RFC 1700

255.255.255.255/32

Limited Broadcast

RFC 919, RFC 922

Lokale/Private Netzwerkadressen Adressbereich

Klassenbeschreibung

größter CIDR-Block Anzahl IP-Adressen

10.0.0.0–10.255.255.255

1 Klasse-A-Netz

10.0.0.0/8

224 = 16.777.216

172.16.0.0–172.31.255.255

16 Klasse-B-Netze

172.16.0.0/12

220 = 1.048.576

192.168.0.0/16

216 = 65.536

169.254.0.0–169.254.255.255 link local, 1 Klasse-B-Netz 169.254.0.0/16

216 = 65.536

192.168.0.0–192.168.255.255 256 Klasse-C-Netze

Beispiele Beispiel: (/24 (früher Klasse-C-Netz)) Subnetzmaske = 11111111.11111111.11111111.00000000 (255.255.255.0) Der Besitzer legt den Netzteil auf 192.168.0 fest: Netzteil

= 11000000.10101000.00000000

Das führt zu folgender Adressverteilung: Netzname

= 11000000.10101000.00000000.00000000 (192.168.0.0)

Erste Adr.

= 11000000.10101000.00000000.00000001 (192.168.0.1)

Letzte Adr.

= 11000000.10101000.00000000.11111110 (192.168.0.254)

Broadcast

= 11000000.10101000.00000000.11111111 (192.168.0.255)

Anzahl zu vergebende Adressen: 28 − 2 = 254

IPv4

35 Beispiel: (Classless) Subnetzmaske = 11111111.11111111.11111000.00000000 (255.255.248.0) Der Besitzer legt den Netzteil auf 192.168.120 fest (wobei im dritten Block nur die fünf höchstwertigen Bits zum Netzteil gehören): Netzteil

= 11000000.10101000.01111

Das führt zu folgender Adressverteilung: Netzname

= 11000000.10101000.01111000.00000000 (192.168.120.0)

Erste Adr.

= 11000000.10101000.01111000.00000001 (192.168.120.1)

Letzte Adr.

= 11000000.10101000.01111111.11111110 (192.168.127.254)

Broadcast

= 11000000.10101000.01111111.11111111 (192.168.127.255)

Anzahl zu vergebende Adressen: 211 − 2 = 2046

Paketlänge Ein IP-Paket besteht aus einem Header und den eigentlichen Daten. Der Datenteil enthält in der Regel ein weiteres Protokoll, meist TCP, UDP oder ICMP. Die maximale Länge eines IP-Pakets beträgt 65535 Bytes (216−1), die maximale Datenlänge 65515 Bytes (Paketlänge – minimale Headerlänge von 20 Byte). Normalerweise beschränkt der Sender die Paketlänge auf diejenige des zugrundeliegenden Mediums. Bei Ethernet beträgt die sogenannte MTU (Maximum Transmission Unit) 1500 Bytes, da ein Ethernet-Datenblock maximal 1518 Bytes lang sein darf und 18 Bytes vom Ethernet selbst belegt werden. Für IP (Header und Daten) stehen also nur 1500 Bytes zur Verfügung.

Deshalb ist die Länge von IP-Paketen oft auf 1500 Bytes festgesetzt.

Routing IPv4 unterscheidet nicht zwischen Endgeräten (Hosts) und Vermittlungsgeräten (Router). Jeder Computer und jedes Gerät kann gleichzeitig Endpunkt und Router sein. Ein Router verbindet dabei verschiedene Netzwerke. Die Gesamtheit aller über Router verbundenen Netzwerke bildet das Internet (siehe auch Internetworking).

IPv4 ist für LANs und WANs gleichermaßen geeignet. Ein Paket kann verschiedene Netzwerke vom Sender zum Empfänger durchlaufen, die Netzwerke sind durch Router verbunden. Anhand von Routingtabellen, die jeder Router individuell pflegt, wird der Netzwerkteil einem Zielnetzwerk zugeordnet. Die Einträge in die Routingtabelle können dabei statisch oder über Routingprotokolle dynamisch erfolgen. Die Routingprotokolle dürfen dabei sogar auf IP aufsetzen.

Bei Überlastung eines Netzwerks oder einem anderen Fehler darf ein Router Pakete auch verwerfen. Pakete desselben Senders können bei Ausfall eines Netzwerks auch alternativ „geroutet“ werden. Jedes Paket wird dabei einzeln „geroutet“, was zu einer erhöhten Ausfallsicherheit führt.

Beim Routing über IP können daher • • • •

einzelne Pakete verlorengehen, Pakete doppelt beim Empfänger ankommen, Pakete verschiedene Wege nehmen, Pakete fragmentiert beim Empfänger ankommen.

Wird TCP auf IP aufgesetzt (d. h. die Daten jedes IP-Pakets enthalten ein TCP-Paket, aufgeteilt in TCP-Header und Daten), so wird neben dem Aufheben der Längenbeschränkung auch der Paketverlust durch Wiederholung korrigiert.

Doppelte Pakete werden erkannt und verworfen. Die Kombination TCP mit IP stellt dabei eine zuverlässige bidirektionale Verbindung eines Datenstroms dar.

IPv4

36

ICMP IP ist eng verknüpft mit dem Internet Control Message Protocol (ICMP), das zur Fehlersuche und Steuerung eingesetzt wird. ICMP setzt auf IP auf, das heißt ein ICMP-Paket wird im Datenteil eines IP-Pakets abgelegt. Eine IP-Implementierung enthält stets auch eine ICMP Implementierung. Wichtig ist zum Beispiel die ICMP Source-Quench-Mitteilung, die den Sender über das Verwerfen von Paketen wegen Überlastung eines Routers informiert. Da jedes IP-Paket die Quell-Adresse enthält, können Informationen an den Sender zurückübermittelt werden. Dieser kann nach einem „Source-Quench“ die Paketsendefrequenz verringern und so die Notwendigkeit eines weiteren Verwerfens minimieren oder vermeiden.

ICMP kann zusammen mit dem Don’t-Fragment-Bit des IP-Pakets auch eingesetzt werden, um die maximale Paketgröße MTU eines Übertragungsweges zu ermitteln (sogenannte PMTU Path Maximum Transmission Unit).

Dies ist die MTU desjenigen Netzwerkes mit der kleinsten MTU aller passierten Netzwerke. Dadurch kann auf Fragmentierung verzichtet werden, wenn der Sender nur Pakete mit der maximalen Größe der PMTU erzeugt.

IPv4 auf Ethernet IPv4 kann auf vielen verschiedenen Medien aufsetzen, zum Beispiel auf serielle Schnittstellen (PPP oder SLIP), Satellitenverbindungen usw. Im LAN-Bereich wird heute fast immer Ethernet eingesetzt. Ethernet verwaltet eigene 48-Bit-Adressen. Wenn IP über Ethernet gesendet wird, wird ein 14 (oder bei VLAN 18) Byte großer Ethernet-Header vor dem IP-Header gesendet. Nach den Daten folgt eine 32-Bit-CRC-Prüfsumme. Neben der maximalen Paketlänge von 1522 (bzw. 1518) Bytes kann Ethernet keine kleineren Pakete als 64 Bytes übertragen, so dass zu kurze IP-Pakete (Datenlänge kleiner als 46 Bytes) mit Nullbytes erweitert werden (sogenanntes Padding).

Die Länge im IP-Header gibt dann Auskunft über die tatsächliche Paketgröße.

Im Ethernet hat jede Netzwerkkarte ihre eigene, herstellerbezogene 48-Bit-Adresse, zusätzlich gibt es eine Ethernet-Broadcastadresse. Ein Sender muss die Ethernetadresse der Zielnetzwerkkarte kennen, bevor ein IP-Paket gesendet werden kann. Dazu wird ARP (Address Resolution Protocol) verwendet. Jeder Rechner verwaltet einen ARP-Cache, in dem er ihm bekannte Zuordnungen von Ethernet-Kartenadressen speichert. Unbekannte Adressen erfährt er über ARP mittels einer Anfrage (ARP-Request) über einen Ethernet-Broadcast (Nachricht an alle Empfänger), die der zugehörige Empfänger beantwortet (ARP-Reply).

Header-Format Der IPv4-Header ist normalerweise 20 Bytes lang. Bei Übertragung auf Basis von Ethernet folgt er dem Ethernet-Typfeld, das für IP-Pakete auf 080016 festgelegt ist. Auf anderen Übertragungsmedien und Protokollen kann der Header auch der erste Eintrag sein.

IPv4 bietet verschiedene, größtenteils ungenutzte Optionen, die den Header bis auf 60 Bytes (in 4-Byte-Schritten) verlängern können.

IPv4

37

0–3

4–7

8–11

12–15 16–18 19–23 24–27 28–31

Version IHL Type of Service Identifikation TTL

Gesamtlänge Flags

Protokoll

Fragment Offset

Header-Prüfsumme

Quell-IP-Adresse Ziel-IP-Adresse evtl. Optionen …

Eine spezielle Bedeutung kommt in modernen Implementierungen dem Feld Type of Service zu. Ursprünglich diente dieses Feld bei der Vermittlung eines Datenpaketes als Entscheidungshilfe für die beteiligten Router bei der Wahl der Übertragungsparameter. In modernen Implementierungen wird dieses Feld im Zusammenhang mit der Vermeidung von Überlastungen verwendet.

Fragmentierung Auf dem Weg vom Sender zum Empfänger kann es vorkommen, dass ein Datagramm ein Netz durchlaufen muss, welches nur kleine Datagramme unterstützt. Jedes Datagramm erhält vom Sender eine Kennung (Identification).

Stellt ein Router auf dem Weg zum Ziel fest, dass das Datagramm für das nächste Teilnetz zu groß ist, so kann er es in zwei Fragmente aufteilen. Dazu sind folgende Schritte notwendig: • Aufteilen der Nutzdaten an einer 64-Bit-Grenze (das zweite Fragment enthält dann nicht unbedingt ein Vielfaches von 64 Bit Daten) • Kopieren der Headerdaten des Originaldatagramms in die neuen Header • Setzen des „more-fragments“-Flags beim ersten Fragment • Beim zweiten Fragment erhält das more-fragments Flag den Wert des Originaldatagramms, da das Originaldatagram bereits ein Fragment gewesen sein kann.

• Erneutes Setzen der Länge-Felder in den Headern • Beim zweiten Fragment enthält Fragment-Offset die Summe aus Fragment-Offset des Originaldatagramms und Anzahl (Nutzdaten-)Bytes im ersten Fragment.

Das Fragmentieren in n > 2 Fragmente funktioniert entsprechend.

Um ein Paket wieder zusammenzusetzen, kombiniert der Empfänger alle Fragmente, welche die gleiche Kennung (Identifikation), den gleichen Absender, Empfänger und das gleiche Protokoll haben. Dabei erkennt er das erste Fragment daran, dass Fragment-Offset den Wert 0 hat. Das jeweils nächste Fragment erkennt er ebenfalls am Fragment-Offset und das letzte Fragment daran, dass more-fragments den Wert 0 hat.

Höhere Protokolle IPv4 ist ein geroutetes Protokoll (Schicht 2 im TCP/IP-Referenzmodell – Schicht 3 im ISO/OSI-Modell). Auf IPv4 werden weitere Protokolle aufgesetzt, das heißt in den Datenteil des IP-Pakets werden die Header, Daten und eventuelle Trailer der oberen Protokolle eingefügt (Protokollstapel). Eine Liste der registrierten Protokolle findet sich in unixoiden Betriebssystemen in der Datei „/etc/protocols“.

Neben dem erwähnten ICMP wird TCP verwendet, das TCP/IP zusammen mit IP den Namen gegeben hat. TCP ist ein verbindungsorientiertes Protokoll, das einen byteorientierten, bidirektionalen, zuverlässigen Datenstrom zur Verfügung stellt. Es wird im WAN-Bereich praktisch für alle Arten von Daten- und Informationsübertragungen eingesetzt.

UDP, ein paketorientiertes Protokoll, setzt ebenfalls auf IP auf. Es ist ein einfaches Protokoll, das die Paketeigenschaften von IP im Wesentlichen beibehält (verbindungslos, unzuverlässig, Verdoppelung etc.). TCP und

IPv4

38 UDP fügen IP eine Prüfsumme über die Daten (die Prüfsumme im IP-Header prüft nur die Headerdaten) und als Quell- und Zielport jeweils eine 16-Bit-Zahl hinzu. Diese Ports bilden zusammen mit der jeweiligen Quell- und Zieladresse im IP-Paket sogenannte Endpunkte. Prozesse kommunizieren über diese Endpunkte. TCP baut eine Verbindung nicht zwischen IP-Adressen, sondern zwischen zwei Endpunkten auf.

Die weiteren Protokolle setzen alle entweder auf TCP oder auf UDP auf. Ein wichtiges Protokoll ist das Domain Name System DNS, das eine Umsetzung von Rechnernamen zu IP-Adressen erlaubt. Es überträgt Informationen normalerweise über UDP, der Abgleich zwischen zwei DNS-Servern kann aber auch TCP verwenden.

Die Ports teilen sich auf in: • privilegierte Ports (1 – 1023); diese dürfen nur vom Benutzer Root verwendet werden.

• registrierte Ports (1024 – 49.151); die Registrierung unterliegt der IANA. Eine Liste findet sich auf Unix-Systemen in der Datei „/etc/services“.

• nicht registrierte Ports (49.152–65.535)

Vergangenheit und Zukunft IPv4 hat lange nahezu unverändert überlebt. Ab 1983 wurde die IP-Protokoll-Familie als einzige Protokollfamilie für das Arpanet übernommen, das dann später zum Internet wurde. Damals waren nur einige hundert Rechner an das Netz angeschlossen. 1989 wurde die Grenze von 100.000 Rechnern überschritten, und im selben Jahr der Backbone auf 1,5 MBit/s aufgerüstet. Am Anfang der 1990er-Jahre war erkennbar, dass die IP-Adressen bald knapp würden. Dies führte zuerst zur Entwicklung eines Entwurfes für einen Standard mit der Versionsnummer 7 (TP/IX), der dann aber zugunsten von IPv6 verworfen wurde. TP/IX sollte dabei einen 64-Bit-Adressbereich Zahl der Rechner im Internet (1981 bis 2003) unterstützen. Die Versionsnummer 5 wurde 1995 für das Internet Stream Protocol Version 2 (ST2) benutzt, das nicht als IPv4-Nachfolger geplant war, sondern als gleichzeitig benutzbares, für Streaming optimiertes Protokoll. Mittlerweile ist das Projekt jedoch eingestellt. Einige Eigenschaften, wie Fragmentierung, werden nicht mehr benötigt, da sie für die heutigen schnellen Netze zu aufwendig sind. Path Maximum Transmission Unit Discovery löst dieses Problem.

IPv4 scheint auch in nächster Zukunft noch das allgemein verwendete Protokoll im Internet zu bleiben. Schließlich hat IP auch die konkurrierenden LAN-Protokolle wie DECnet verdrängt. NetWare, AppleTalk und NetBIOS wurden als neue Versionen hervorgebracht, die auf IP aufsetzen.

Am 3. Februar 2011 vergab die IANA die letzten IPv4-Adressen an die Regional Internet Registries[1][2]. Am 15. April 2011 teilte APNIC die letzten frei zu vergebenden Adressen für die Region Südostasien zu.[3] Ab diesem Zeitpunkt haben alle APNIC-Mitglieder nur noch Anspruch auf eine einzelne Zuteilung von IPv4-Adressraum der minimalen Zuteilungsgröße.[4]

IPv4

39

Weblinks • RFC 791 [5] – Internet Protocol • L. Parziale et. al.: TCP/IP Tutorial and Technical Overview [6] in IBM Redbooks [7], Armonk (NY, USA) 2006 (englisch) • Subnetz-Rechner [8] im Kapitel TCP/IP – Grundlagen Computernetze

Literatur • Technik der IP-Netze, Badach, A. und Hoffmann, E.; Hanser. München 2007. ISBN 978-3-446-41089-3 • TCP/IP - Grundlagen und Praxis, Larisch, D., Heise Medien. Hamburg 2011. ISBN 978-3936931693 • IP Addressing & Subnetting, Wegner, J.D. und Rockwell, R.; Syngress. Rockland (MA, USA) 2000. ISBN 3-8266-4077-2

Einzelnachweise [1] WELT ONLINE: Alle Internetadressen weltweit sind aufgebraucht (3. Februar 2011) (http:/ / www. welt. de/ wirtschaft/ webwelt/ article12434989/ Alle-Internetadressen-weltweit-sind-aufgebraucht. html) [2] RIPE NCC: Final IPv4 Allocation (Engl.) (http:/ / ripe. net/ news/ final-v4-allocation. html) [3] APNIC: APNIC IPv4 Address Pool Reaches Final /8 (http:/ / www. apnic. net/ publications/ news/ 2011/ final-8) [4] APNIC: Policies for IPv4 address space management in the Asia Pacific region (http:/ / www. apnic. net/ policy/ add-manage-policy#9. 10), Abschnitt 9.10.1 [5] http:/ / www. ietf. org/ rfc/ rfc0791. txt [6] http:/ / www. redbooks. ibm. com/ redbooks/ pdfs/ gg243376. pdf [7] http:/ / www. redbooks. ibm. com/ abstracts/ gg243376. html [8] http:/ / www. netzmafia. de/ skripten/ netze/ netz8. html#8. 3

Normdaten (Sachbegriff): GND: 4588596-5 (http://d-nb.info/gnd/4588596-5)

Quelle(n) und Bearbeiter des/der Artikel(s)

Quelle(n) und Bearbeiter des/der Artikel(s) IP-Adresse Quelle: http://de.wikipedia.org/w/index.php?oldid=113481860 Bearbeiter: *Pitt*, -papinian-, 08-15, A.Savin, Achim Raschka, Ahellwig, Aka, Akashi, Alkibiades, Alnilam, Amargeddon6, Amtiss, An-d, Andreas 06, Andreas-Meile, Appaloosa, Ardo Beltz, Arilou, Arx, Asdert, Avatar, Axji, BK-Master, Balû, Baumi, Bdk, Benji, Bernard Ladenthin, BioPupil, Birger Fricke, Bitsandbytes, Boonekamp, Boshomi, BuSchu, Bvontob, Bwiedmann, C.Wesner, CBC, CS99, Chiccodoro, ChrisHamburg, Chrislb, ChristianErtl, Christoph Leeb, Christoph Nevie, Clemensfranz, Cleverboy, Codewalker, Complex, Contributor, Conversion script, Cymacs, Cyper, D, Dachris, Daffman, Daniel, DasBee, Der Messer, Der.Traeumer, DerHexer, DerRegenerative, Diba, Dibu68, Diddi, Dishayloo, Dodo von den Bergen, Don Quichote, Dorfmopp, DorisAntony, DrMurx, Drak, Dsone, Dundak, Eddia, Edgeball, Elian, Engie, Englandfan, Euku, Euphoriceyes, Exoport, Felix Stember, Felix Wiemann, Fgb, Fit, Flavia67, Flokru, Florian Adler, Flothi, Fomafix, Frank Schulenburg, Frank.herfert, Franzzup, Frosty79, Fuzz, GDK, Gabrielo, Galoubet, Gamemaster1508, Gilliamjf, Gnu1742, Greuff, GrummelJS, Gunnar.offel, Günther M. Apsel, HaeB, Hans Koberger, He3nry, Head, Hebbet, Heidelberg, Hella, HenHei, Hermannthomas, Hhdw, Hinnerk, HoHun, Howwi, Hoxel, Hubertl, Hubi, Hybridbus, Hydro, Ianusius, Igelball, Inkowik, Itu, JD, Jadadoo, Janz, Jashuah, Jed, Jengelh, Jens Liebenau, Jens Meißner, Jens.ferner, Jivee Blau, Joergens.mi, Johnny Controletti, Jonathan Hornung, Joni2, JonnyBrazil, Jophi, Jorunn, Jos1990, Joschi90, Joz, Jpetersen, Jpp, Juesch, KGF, KaHe, Kahlfin, Kaisersoft, Kam Solusar, Karl-Bernhardin, Karl-Henner, Kcirtap, Kdwnv, Kgfleischmann, Kiker99, Klingelingeling, Klug Csaba Ferenc, Knoerz, Koenraad, Koyote82, KrasseChecker, Krawi, Krd, Krje, Kubrick, KurtMelnik, KönigAlex, Körnerbrötchen, LKD, Laza, Learny, Leipnizkeks, Lennert B, Liesel, Limast, Lofor, Lordcola, MAK, MBq, MainFrame, Man77, MannMaus, Mannerheim, Marius Becker, Martin Aggel, Martin Bahmann, Martin b, Martin-vogel, Matthiasb, Matthäus Wander, Mauerquadrant, Melancholie, Merlissimo, Mgehrmann, Michail, Michikrel, Mijobe, Mino, Mnh, Monarch, Monika St, Morgentau, Mps, MrFixit, MsChaos, NauarchLysander, Nerd, Nfreaker91, Nightflyer, Nocturne, Nolispanmo, Noses, Nothere, OderWat, OecherAlemanne, Ogmios, Olaf1541, Olei, Ot, Otto Normalverbraucher, P3t0r, PM3, Pajz, Paramecium, Pelz, Perhelion, Peter200, PhChAK, Phantasmagorium, Philipendula, Pinklupus, Pischdi, Pit, Pittimann, Plenz, Ps246, PsY.cHo, Purodha, Quadrupel, Querverplänkler, Ra'ike, Ralfsby, Randolph33, Rat, Ratatosk, Raubsaurier, Rauenstein, Rayx, Regi51, Reinhard Kraasch, Rischmueller, Robb, RokerHRO, Ronald M. F., RoswithaC, Rplucke, Rubo77, SPS, STBR, Saldek, Salige, SchallundRauch, Schoos, Scooter, Sebastian, Sechmet, Seewolf, Semper, Sigkill, Sikilai, Simon-Martin, Sinn, Slimjim1984, Sonnenblumen, Spacebirdy, Sparti, Splayn, Spuk968, Stargamer, Staro1, Starwhooper, Stefan Kühn, Stefan506, Sternstefan, Stfn, Storchi, Stunksys, Supaari, Swappy123, Sémhur, TMg, Tbutter, TheK, TheVi, Thire, Thorbjoern, Thornard, Tilman Berger, Tinz, Tobi B., Toblu, Tokikake, Trustable, Tröte, Tschuber, Tsor, Tönjes, Umherirrender, Unscheinbar, Uweschwoebel, Verita, WAH, WWSS1, Watch ip, Wendelin, Wernfried, Wiesecke, WikiNick, Wikifh, Wilhans, Wimpernschlag, WiseWoman, WissensDürster, Wkrautter, Wo st 01, Wolfgang H., Xocolatl, YMS, YourEyesOnly, \ldblquote, gw.phinware.de, 力 北 方, 774 anonyme Bearbeitungen IPv6 Quelle: http://de.wikipedia.org/w/index.php?oldid=113248186 Bearbeiter: 2001:6F8:10B1:0:6CDB:EDCE:69E5:57D0, 2ndstar, AF666, APPER, AWak3N, Achim Raschka, Aconcagua, Admiral kay, Adornix, Adrian Bunk, Ads, Aka, Akw, Albtalkourtaki, An-d, Anthill, Artfuldodger, Arved, Asdert, Atamari, Aufräumer, AydinC, Babel fish, Bachsau, Baumanns, Ben g, Bergfalke2, Bernard Ladenthin, Bierdimpfl, Bikedoc, Bitsandbytes, Björn Bornhöft, Boshomi, BuZZa, C.Wesner, ChristianErtl, ChristianStrauf, Chuppachuppa, Church of emacs, Clemens Gruber, CommonsDelinker, Cream, Crux, Curtis Newton, César, D, DStulle, DaB., Danic, Daniel 1978, Daniel 1992, Danny243, Darkone, DasBee, Dennis, Der Messer, Der.Traeumer, Deschamp, Dfge, Diba, Didym, Dominik, Don Magnifico, Doppelhelix, Dr. Evil, Echoray, Echtner, Elektronentechniker, Elvaube, Emdee, Emergency doc, Emgo, Empro2, Engie, Esperosoph, Euku, F. Saerdna, FBE2005, FalconL, Felanox, Felix Stember, Fg68at, Fgb, Fladi, Florian3, Floschuh, Fomafix, Frankee 67, Froestl, Froggy, Frubi, Fschoenm, Fujnky, GDK, Gartenzwerg2012, Gauss, Gebu, Gimbal, Glglgl, Gms, Grb, Gressenicher, Gronau, Grupp, Guandalug, Gulliveig, HSattler, Hagbard, Hannovernorbi, Happolati, Harald Mühlböck, HardDisk, Harro von Wuff, Hella, Henri97, Henryf, Hephaion, Hevolk, HoPiHaLiDo1992, Hokanomono, Howwi, Hubi, INM, Iblech, Icwiener, Ilja Lorek, Inkowik, Iromeister, Itti, Itu, J-PG, J. Schwerdtfeger, Jailbird, JakobVoss, Janus, Jivee Blau, Jobu0101, Jodoform, Jogo.obb, Jonathan Haas, Jones1103, Jtb, JuTa, Kai-Hendrik, KaiMartin, Kam Solusar, Karl-Henner, Kdwnv, Keksdosenmann, Kgfleischmann, Kiker99, KingLion, Kku, Kl833x9, Klaeren, Kobelix, Krawi, Kubieziel, Kvedulv, LKD, Laza, Learny, Leider, Lemmermen, Lesbar, Lex parsimoniae, Liberatus, Linveggie, Lipstar, Liquidat, LonelyPixel, Luckyduck, LudiKalell, Lukas²³, Lustiger seth, Lysander07, Löschfix, MAKuser, MPirious, MSk, Maggot, Magnus, Maix, Majortom7, Manankanchu, Mark192, Marsupilami, Martin schulte, Martin1978, MartinC, Mathias Schindler, Matthiasb, Matthäus Wander, Matzematik, MauriceKA, Maximilian Schönherr, Mc-404, Melissensaft, Merlissimo, MichiK, Mineo, Mino, Mkleine, Mlorer, Mmaddin, Mnh, Molily, Mps, Muck31, Mudd1, Mvb, N'Maru, NDBro, Naboo N1 Starfighter, Nainoa, Nameless, Napa, Nd, Ne discere cessa!, Nerd, Nightflyer, Nirakka, Nokturn, Nolispanmo, Nothere, OLFERNATOR, Oestivred, Olei, Olliy, Oms, Onlinus, Ot, PM3, PerfektesChaos, Perrak, Peter200, Philistion, Phrood, Pickelhaube, Pisteuos, Pittimann, Pkolmann, Plagiat, Poc, Polarlys, Pool, Pro2, Quarx, Quirin, Randolph33, Redf0x, Reinhard Kraasch, Reinraum, ReneDens, Rischmueller, Roeme, Roemer2201, RokerHRO, Rolf acker, Rufus46, Rößle, Schniggendiller, Schoschie, Scooter, Sebastian Hagedorn, Seewolf, Siegbert 7, Sigkill, Silberchen, Simon.hess, Sinn, Small Axe, SmilingBoy, Spacefish, Speck-Made, Sprachpfleger, Staro1, Steady286, Stefan Knauf, Stefan Kühn, Stefan h, Stefan506, Stefanux, Stern, Stunksys, Syrcro, TAFKACOS, TNolte, Tali, Tbutter, Template namespace initialisation script, Terranic, TheK, ThoRr, Thoemu, Thoken, ThorJH, Thotig, ThurnerRupert, Tim Pritlove, Timelesk, Tkarcher, Tobox, TobyDZ, TomK32, Torsch, Totes huhn, Toxilly, Trustable, Tschäfer, Ucc, Ultralord75, Uncle Pain, Ute Erb, Uuu87, V.R.S., Vachigaggl, Vanger, Verbund, Village Hero, Visionmaster2, Vrumfondel, Vux, W.ewert, Webhamster, WiESi, Wiegels, Wiki-observer, Wikiritter, Wind of change, Wiska Bodo, Wiwa1, Woertz, Wolle212, YMS, ZOiDberg, Zahnradzacken, Zaphod B., ZaphodB, Zarniwoop, Zinnmann, Zone42, 604 anonyme Bearbeitungen IPv4 Quelle: http://de.wikipedia.org/w/index.php?oldid=113347287 Bearbeiter: Achim Raschka, Aka, Alleswissender, Andreas aus Hamburg in Berlin, Asdert, AssetBurned, Asturius, Ben g, Bera, BerndEckenfels, Berntie, BesondereUmstaende, Bitsandbytes, Blane, Boonekamp, Boshomi, C.Wesner, C00n, Chris1412, Christ-ian, ChristianErtl, ChristianSchulz, Chrono, DWay, Daf, Daniel 1992, Der fahrer, Der.Traeumer, DerHexer, Diddi, Drbashir117, Echoray, Eckhart Wörner, Eke, Elvaube, Erusx, Faco, FelixD, Fleasoft, Flominator, Fomafix, Freerk, Fritz Grimpen, Gnu1742, HaeB, Harro von Wuff, Head, Hella, HenHei, HenrikHolke, Howwi, Hubi, Ich, Ilario, Inkowik, JAF, Jengelh, Jivee Blau, Jiver, Jms, Johnny Controletti, JonBs, Joni2, Jpp, Kallistratos, Kam Solusar, Kdwnv, Kgfleischmann, Kiwipferd, KonstiSG, Korinth, LKD, Leider, Libro, LudiKalell, Lukas²³, Macfiron, Maggot, Makid, MarkusHagenlocher, Matthias Bock, Matthäus Wander, Mauerquadrant, Merlissimo, Mikue, Mm-mbs, Mnh, Morphis, Mps, MrManiac, NEUROtiker, Nilspausdd, Nolispanmo, PM3, Panse, Peter200, Pittimann, Pkn, Rdb, Reclus, Ri st, Roland Bless, Rößle, SH3k, Sechmet, Smartcom5, Staro1, Stefan Knauf, Stefan Kühn, Stefan506, SteffenB, Tali, TeachesIT, The-Me, TheK, Thomas.Witzenrath, ThorJH, Timk70, Tobi B., TomK32, Tomte, Uncle Pain, Unscheinbar, Van'Dhunter, W.ewert, Waelder, Wiegels, Wiki-observer, YMS, YPS, Yoursmile, Zollernalb, \ldblquote, 323 anonyme Bearbeitungen

40

Quelle(n), Lizenz(en) und Autor(en) des Bildes

Quelle(n), Lizenz(en) und Autor(en) des Bildes Datei:IP Routing über Netzwerke.png Quelle: http://de.wikipedia.org/w/index.php?title=Datei:IP_Routing_über_Netzwerke.png Lizenz: GNU Free Documentation License Bearbeiter: Melancholie, Parpan05, WikipediaMaster, 2 anonyme Bearbeitungen Datei:Regional Internet Registries world map.svg Quelle: http://de.wikipedia.org/w/index.php?title=Datei:Regional_Internet_Registries_world_map.svg Lizenz: Creative Commons Attribution-Sharealike 3.0 Bearbeiter: Rir.gif: BlankMap-World6,_compact.svg: Canuckguy et al. derivative work: Sémhur (talk) Datei:Ipv4-exhaust.svg Quelle: http://de.wikipedia.org/w/index.php?title=Datei:Ipv4-exhaust.svg Lizenz: Creative Commons Attribution-Share Alike Bearbeiter: Mro Datei:IPv6 header rv1.svg Quelle: http://de.wikipedia.org/w/index.php?title=Datei:IPv6_header_rv1.svg Lizenz: GNU Free Documentation License Bearbeiter: Self-made (png version made

by User:Helix84 and User:HorsePunchKid Datei:6in4_wireshark.png Quelle: http://de.wikipedia.org/w/index.php?title=Datei:6in4_wireshark.png Lizenz: GNU General Public License Bearbeiter: Wireshark Datei:IPv6-as.svg Quelle: http://de.wikipedia.org/w/index.php?title=Datei:IPv6-as.svg Lizenz: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0 Bearbeiter: Mro Datei:Rir-ipv6-allocation-rate.svg Quelle: http://de.wikipedia.org/w/index.php?title=Datei:Rir-ipv6-allocation-rate.svg Lizenz: Creative Commons Attribution-Share Alike Bearbeiter: Mro File:Modified-EUI-64.svg Quelle: http://de.wikipedia.org/w/index.php?title=Datei:Modified-EUI-64.svg Lizenz: unbekannt Bearbeiter: Grupp Datei:Zahl der Internet Hosts.png Quelle: http://de.wikipedia.org/w/index.php?title=Datei:Zahl_der_Internet_Hosts.png Lizenz: GNU Free Documentation License Bearbeiter: Akkakk, FEXX, Hubi

41

Lizenz

42

Lizenz Wichtiger Hinweis zu den Lizenzen Die nachfolgenden Lizenzen bezieht sich auf den Artikeltext. Im Artikel gezeigte Bilder und Grafiken können unter einer anderen Lizenz stehen sowie von Autoren erstellt worden sein, die nicht in der Autorenliste erscheinen. Durch eine noch vorhandene technische Einschränkung werden die Lizenzinformationen für Bilder und Grafiken daher nicht angezeigt. An der Behebung dieser Einschränkung wird gearbeitet.

Das PDF ist daher nur für den privaten Gebrauch bestimmt. Eine Weiterverbreitung kann eine Urheberrechtsverletzung bedeuten.

Creative Commons Attribution-ShareAlike 3.0 Unported - Deed Diese "Commons Deed" ist lediglich eine vereinfachte Zusammenfassung des rechtsverbindlichen Lizenzvertrages (http:/ / de. wikipedia. org/ wiki/ Wikipedia:Lizenzbestimmungen_Commons_Attribution-ShareAlike_3. 0_Unported) in allgemeinverständlicher Sprache.

Sie dürfen: • das Werk bzw. den Inhalt vervielfältigen, verbreiten und öffentlich zugänglich machen • Abwandlungen und Bearbeitungen des Werkes bzw. Inhaltes anfertigen Zu den folgenden Bedingungen: • •

Namensnennung — Sie müssen den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.

Weitergabe unter gleichen Bedingungen — Wenn Sie das lizenzierte Werk bzw. den lizenzierten Inhalt bearbeiten, abwandeln oder in anderer Weise erkennbar als Grundlage für eigenes Schaffen verwenden, dürfen Sie die daraufhin neu entstandenen Werke bzw. Inhalte nur unter Verwendung von Lizenzbedingungen weitergeben, die mit denen dieses Lizenzvertrages identisch, vergleichbar oder kompatibel sind.

Wobei gilt: • •

Verzichtserklärung — Jede der vorgenannten Bedingungen kann aufgehoben werden, sofern Sie die ausdrückliche Einwilligung des Rechteinhabers dazu erhalten.

Sonstige Rechte — Die Lizenz hat keinerlei Einfluss auf die folgenden Rechte: • • •

•

Die gesetzlichen Schranken des Urheberrechts und sonstigen Befugnisse zur privaten Nutzung; Das Urheberpersönlichkeitsrecht des Rechteinhabers; Rechte anderer Personen, entweder am Lizenzgegenstand selber oder bezüglich seiner Verwendung, zum Beispiel Persönlichkeitsrechte abgebildeter Personen.

Hinweis — Im Falle einer Verbreitung müssen Sie anderen alle Lizenzbedingungen mitteilen, die für dieses Werk gelten. Am einfachsten ist es, an entsprechender Stelle einen Link auf http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/ deed. de einzubinden.

Haftungsbeschränkung Die „Commons Deed“ ist kein Lizenzvertrag. Sie ist lediglich ein Referenztext, der den zugrundeliegenden Lizenzvertrag übersichtlich und in allgemeinverständlicher Sprache, aber auch stark vereinfacht wiedergibt. Die Deed selbst entfaltet keine juristische Wirkung und erscheint im eigentlichen Lizenzvertrag nicht.

GNU Free Documentation License Version 1.2, November 2002

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: •

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

• C. State on the Title page the name of the publisher of the Modified Version, as the publisher.

• D. Preserve all the copyright notices of the Document.

• E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

• F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

• G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

• H. Include an unaltered copy of this License.

• I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

• J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

• K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

• L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

• M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.

• N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

• O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

•

5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

Lizenz

43

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http:/ / www. gnu. org/ copyleft/ .

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

ADDENDUM: How to use this License for your documents To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

A copy of the license is included in the section entitled "GNU Free Documentation License".

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this:

with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.