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.
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 128-Bit-Adressierung der beteiligten Netzwerkelemente (Rechner oder Router) her.
IPv6 stellt als Protokoll der Vermittlungsschicht (Schicht 3 des OSI-Modells) im Rahmen der Internetprotokolle eine über Teilnetze hinweg gültige 128-Bit-Adressierung der beteiligten Netzwerkelemente (Rechner oder Router) her.
Ferner regelt es unter Verwendung dieser Adressen den Vorgang der Paketweiterleitung zwischen Teilnetzen (Routing).
Ferner regelt es unter Verwendung dieser Adressen den Vorgang der Paketweiterleitung zwischen Teilnetzen (Routing).
Zeile 1.404:
Zeile 1.404:
|-
|-
| | Familie:
| | Familie:
| | Internetprotokollfamilie
| | Internetprotokolle
|-
|-
| | Einsatzgebiet:
| | Einsatzgebiet:
Zeile 1.942:
Zeile 1.942:
|-
|-
| | '''Familie:'''
| | '''Familie:'''
| | Internetprotokollfamilie
| | Internetprotokolle
|-
|-
| | '''Einsatzgebiet:'''
| | '''Einsatzgebiet:'''
Zeile 3.160:
Zeile 3.160:
* M6Bone https://de.wikipedia.org/wiki/M6Bone
* M6Bone https://de.wikipedia.org/wiki/M6Bone
* Peer Name Resolution Protocol https://de.wikipedia.org/wiki/Peer_Name_Resolution_Protocol
* Peer Name Resolution Protocol https://de.wikipedia.org/wiki/Peer_Name_Resolution_Protocol
* Hurricane Electric, ein für seinen Tunnelbroker und sein v6-Backbone bekannter ISP https://de.wikipedia.org/wiki/Hurricane_Electric
* Hurricane Electric, ein für seinen Tunnelbroker und sein v6-Backbone bekannter ISP https://de.wikipedia.org/wiki/Hurricane_Electric
Version vom 29. Dezember 2023, 11:00 Uhr
Internet Protokoll Version 6
Anwendung
HTTP
IMAP
SMTP
DNS
…
Transport
TCP
UDP
Internet
IPv6
Netzzugang
Ethernet
TokenBus
TokenRing
FDDI
…
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 Internetprotokolle eine über Teilnetze hinweg gültige 128-Bit-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.
Befürworter bemängeln die zögerliche Einführung von IPv6 angesichts der ausgelaufenen IPv4-Adressvergabe in Asien, Ozeanien und Europa.
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.
IPv6 is short for "Internet Protocol version 6"
IPv6 is the "next generation" protocol designed by the IETF to replace the current version of Internet_Protocol, IP Version 4 or IPv4.
IPv6 was initially designed with a compelling reason in mind: the need for more IP addresses. This need arose from fast Internet growth: billions of new devices (cell phones, PDAs, appliances, cars, etc.), and billions of new users (China, India, Latin America). This, combined with new 'always-on' access technologies such as xDSL, cable, ethernet-to-the-home, were increasing the appetite for new devices and new users.
There may be alternative technical solutions, such as NAT (Network Address Translation), but they won't work so easily to allow this growth.
Consequently, the design of IPv6 was an opportunistic way to improve the Internet, with new benefits such as: * Expanded addressing capabilities.
Server-less autoconfiguration ("plug-n-play") and reconfiguration.
More efficient and robust mobility mechanisms.
End-to-end security, with built-in, strong IP-layer encryption and authentication.
Streamlined header format and flow identification.
Enhanced support for multicast and QoS.
Extensibility: Improved support for options / extensions.
History
The History of IPv6 started in 1994-1995 with documents such as: RFC1719 "A Direction for IPng", RFC1726 "Technical Criteria for Choosing IP The Next Generation (IPng)" and RFC1752 RFC1752 "The Recommendation for the IP Next Generation Protocol".
Then the main document was published in December 1995: RFC1883 "Internet Protocol, Version 6 (IPv6) Specification".
Which was obsoleted in December 1998 by: RFC2460"Internet Protocol, Version 6 (IPv6) Specification".
Gründe für ein neues Internet-Protokoll
Datei:.pngAbbildung 1: Verfügbare IPv4-Adressblöcke zwischen 1995 und heuteIPv4
IPv4 bietet einen Adressraum von etwas über vier Milliarden IP-Adressen (232 = 2564 = 4.294.967.296), von denen 3.707.764.736 verwendet werden können, um Computer und andere Geräte direkt anzusprechen.
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.
Gemäß einer Vereinbarung aus dem Jahr 2009 wurde am 3. Februar 2011 schließlich der verbleibende Adressraum gleichmäßig auf die regionalen Adressvergabestellen verteilt.
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; am 14. September 2012 folgte dann RIPE NCC mit der letzten freien Zuteilung in der Region Europa/Naher Osten.
Seitdem haben APNIC- und RIPE NCC-Mitglieder jeweils nur noch Anspruch auf eine einzelne Zuteilung von IPv4-Adressraum der minimalen Zuteilungsgröße.
Historische Entwicklung (Routing)
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 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.
Neue Eigenschaften von IPv6
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
Dadurch wird die Verschlüsselung und die Überprüfung der Authentizität von IP-Paketen ermöglicht.
Unterstützung von Netztechniken
Quality of Service
Multicast
Ende-zu-Ende-Prinzip
Die hauptsächliche Motivation zur Vergrößerung des Adressraums besteht in der Wahrung des Ende-zu-Ende-Prinzips, das ein zentrales Designprinzip des Internets ist:
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.
NAT
Heute übliche Verfahren wie Network Address Translation (NAT), welche derzeit die IPv4-Adressknappheit umgehen, verletzen das Ende-zu-Ende-Prinzip.
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.
Paradigmenwechsel für Heimanwender
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 den 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.
Wahl der Adresslänge
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.
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.
Anzahl der Autonomen Systeme mit publizierten IPv6-Routen und Anzahl der publizierten Präfixe zwischen 2003 und heute
IPv6 setzt sich im praktischen Einsatz nur langsam durch.
Die Adressvergabe für IPv6 ist im Juli 1999 vom experimentellen in den Regelbetrieb übergegangen und immer mehr ISPs betreiben neben IPv4 auch IPv6 in ihrem Netz.
Über den Internetknoten AMS-IX werden zu Spitzenzeiten 20 GBit/s IPv6-Traffic transportiert, das sind etwas unter 1 % des dort anfallenden Gesamtverkehrs von etwa 2,5 TBit/s.
Auf Webseiten im Dual-Stack Betrieb werden weltweit 4 % der Zugriffe über IPv6 gemessen, für Zugriffe aus Deutschland liegt der IPv6-Anteil bei 11 %.
Die globale IPv6-Routingtabelle umfasste im Juli 2014 etwa 20000 Präfixe, und ungefähr 17 % aller im Internet verfügbaren Autonomen Systeme beteiligen sich am globalen IPv6-Routing.
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.
Das IPv6 Forum wurde im Juli 1999, der Deutsche IPv6 Rat im Dezember 2007 gegründet.
Das IPv6 Forum Projekt IPv6-Ready 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.
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) – vor Jahren noch nur über etwa so viele IP-Adressen verfügte wie ein Campus der University of California (Dezember 2004).
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.
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) 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. Der Test verlief weitestgehend problemlos.
Am Internetknotenpunkt DE-CIX war ein deutlich erhöhtes IPv6-Verkehrsaufkommen zu messen, das auch nach dem 8. Juni anhält.
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.
Seit dem 25. September 2012 leistet die Deutsche Telekom IPv6 auch an DSL-Endkundenanschlüssen.
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.
In der aktuellen Leistungsbeschreibung für die Nutzung von LTE an einer fest vereinbarten Adresse („Call & Surf Comfort via Funk“ als Alternative zu DSL) stellt die Deutsche Telekom aber z. B. klar, dass „[ü]ber diesen Internetzugang […] nur IPv4-Adressen erreichbar“ sind.
Adressaufbau von IPv6
IPv6-Adressen sind 128 Bit lang (IPv4: 32 Bit)
Die ersten 64 Bit
bilden den sogenannten Präfix
Die letzten 64 Bit
bilden bis auf Sonderfälle einen für die Netzwerkschnittstelle (englisch network 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.
Privacy-Extensions
Da die Erzeugung des Interface-Identifiers aus der global eindeutigen MAC-Adresse die Nachverfolgung von Benutzern ermöglicht, wurden die Privacy-Extensions (PEX, 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.
Adressnotation
Die 128 Bit einer IPv6-Adresse sehen zum Beispiel wie folgt aus:
IPv6-Netzwerke werden in der CIDR-Notation aufgeschrieben
Dazu werden die erste Adresse (bzw. die Netzadresse) und die Länge des Präfixes in Bit 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.
Interface Identifiers (EUI-64 )
Aufbau und automatische Erzeugung
Bei dem 64 Bit langen IPv6-Interface Identifier handelt es sich um die Link Layer Adresse (OSI-Modell Schicht 2), d.h. der MAC-Adresse, der Schnittstelle.
Dazu wird das 64 Bit lange, genormte IEEE EUI-64 Adressformat in einer leicht abgeänderten Form verwendet. Durch Invertierung des u-Bits wird die Konfiguration von Hand erleichtert.
Bei den folgenden Darstellung der Adresse handelt es sich um die kanonische Sichtweise in der ISO/OSI-Modell Schicht 2.
Datei:Bild13.pngAbbildung: Aufbau eines 64 Bit Interface Identifier
u
„1“ = universal : weltweit eindeutige Adresse„0“ = local : lokal eindeutige Adresse
g
„1“ = group : Gruppen-/Multicast-Adresse„0“ = individual : Einzel-Adresse
c
durch IEEE festgelegte Bits die den Interface-Hersteller kennzeichnen
Bei der Abbildung der 48 Bit langen IEEE 802.3 auf die 64 Bit langen IPv6-Interface ID Adresse, führt der Weg über die Abbildung auf eine IEEE EUI-64 Adresse [RFC2464].
Dazu werden die ersten drei Oktette der IEEE 802.3 MAC-Adresse (OUI = Organizational Unique Identfier) in die IEEE EUI-64 Adresse übernommen. In das vierte und das fünfte Oktett wird die Zahlen FF16 und FE16 eingefügt. Die letzten 3 Oktette der IEEE 802.3 MAC-Adresse werden zu den letzten drei Oktetten der IEEE EUI-64 Adresse. Zusätzlich wird auch das u-Bit invertiert.
Typischerweise bekommt ein Internetprovider (ISP) die ersten 32 Bit (oder weniger) als Netz von einer Regional Internet Registry (RIR) zugewiesen.
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.
Ä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.
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.
Netzsegmente
Einem einzelnen Netzsegment wird in der Regel ein 64 Bit langer Präfix zugewiesen, das dann zusammen mit einem 64 Bit langen Interface-Identifier die Adresse bildet.
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
2001:0db8:85a3:0800::/56.
Der Adressraum teilt sich in mehrere große Blöcke
die weiter unterteilt sein können
Alle Adressen unterhalb der hierarchischen Adressebene eines Blockes weisen einen identischen Präfix auf.
Dadurch wird das Routing entschieden vereinfacht, da die Router einen großen Teil der Entscheidungen schon anhand dieses Präfix treffen können
IPv4-Adressen werden mit dem Präfix 0 in den IP6-Raum eingeblendet
Durch die neue Struktur stehen nicht nur eine Menge neuer Adressen, sondern auch einige neue Adressierungsarten zur Verfügung
Pakete werden je nach Adressierung
an genau eine Station gesendet (Unicast),
an eine Gruppe von Stationen ( Multicast)
an die schnellste aus einer Gruppe von Stationen (Anycast)
Es gibt verschiedene IPv6-Adressbereiche mit Sonderaufgaben und unterschiedlichen Eigenschaften. Diese werden meist schon durch die ersten Bit der Adresse signalisiert. Sofern nicht weiter angegeben, werden die Bereiche in RFC 4291 bzw. RFC 5156 definiert.
Scopes
interface
Verlässt nie den Host
link-local
Verlässt nie das lokale Subnetz
global
Geht um die ganze Welt
Unicast-Adressen
charakterisieren Kommunikation eines Netzknotens mit genau einem anderen Netzknoten
* 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.
Jedoch können auch Serverprogramme durch Angabe dieser Adresse bewirken, dass sie auf allen Adressen des Hosts lauschen.
loopback-Adresse
::1/128 (127 0-Bit, 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 sind nur innerhalb abgeschlossener Netzwerksegmente (link) gültig.
Ein Netzwerksegment ist ein lokales Netz, gebildet mit Switches oder Hubs, bis zum ersten Router.
Der Formatpräfix lautet „fe80::/10“:
10 Bit
54 Bit
64 Bit
1111111010
0
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, 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 bzw. fe80::7645:6de2:ff:1%eth0
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 ehemals 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.
Unique Local Unicast
fc00::/7 (fc00… bis fdff…)
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.
Das Präfix fc ist für global zugewiesene, eindeutige ULA reserviert. Auf das Präfix folgen dann 40 Bit, die als eindeutige Site-ID fungieren.
Diese Site-ID ist bei den ULA mit dem Präfix fd zufällig zu generieren 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, 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 Bit für Flags und 4 Bit für den Gültigkeitsbereich (Scope).
Für die Flags sind zurzeit folgende Kombinationen gültig:* 0: Permanent definierte wohlbekannte Multicast-Adressen (von der IANA zugewiesen)
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)
Gültigkeitsbereiche
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.
Beispiele für wohlbekannte Multicast-Adressen
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.
Global Unicast
Alle anderen Adressen gelten als Global-Unicast-Adressen.
Von diesen sind jedoch bisher nur die folgenden Bereiche zugewiesen:
::/96 (96 0-Bit)
* stand für IPv4-Kompatibilitätsadressen, welche in den letzten 32 Bit 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-Bit, gefolgt von 16 1-Bit)
* steht für IPv4 mapped (abgebildete) IPv6 Adressen. Die letzten 32 Bit 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 (2000… bis 3fff…; 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.
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.
Mittels Stateless Address Autoconfiguration (SLAAC, zustandslose Adressenautokonfiguration, spezifiziert in RFC 4862) 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
link-lokale Adresse
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.
Router Solicitation
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.
Router Advertisements
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 einen solchen Präfix hängt der Host den auch für die link-lokale Adresse verwendeten Interface-Identifier an.
Duplicate Address Detection
Um die doppelte Vergabe einer Adresse zu verhindern, ist der Mechanismus Duplicate Address Detection (DAD – Erkennung doppelt vergebener Adressen) vorgesehen.
Ein Gerät darf bei der Autokonfiguration nur unvergebene Adressen auswählen. Der DAD-Vorgang läuft ebenfalls ohne Benutzereingriff via NDP ab.
Gültigkeitsangaben
Valid Lifetime und Preferred Lifetime
Router können bei der Vergabe von Adresspräfixen begrenzte Gültigkeitszeiten mitgeben: Valid Lifetime und Preferred Lifetime. * Innerhalb der Valid Lifetime darf der angegebene Präfix zur Kommunikation verwendet werden
innerhalb der Preferred Lifetime soll dieser Präfix einem anderen, dessen Valid Lifetime schon abgelaufen ist, vorgezogen werden.
Router Advertisements
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.
Autokonfiguration und DHCPv6
Stateful Address Configuration
Die IPv6-Autokonfiguration unterscheidet sich konzeptionell von DHCP beziehungsweise DHCPv6. * Bei der Adressvergabe durch DHCPv6 wird von „Stateful Address Configuration“ gesprochen
sinngemäß: Adressvergabe, über die Buch geführt wird, etwa durch einen DHCP-Server
definiert in RFC 3315
Autokonfiguration ist eine „Stateless Address (Auto)Configuration“
Geräte weisen sich selbst eine Adresse zu
über diese Vergabe wird nicht Buch geführt
Grenzen der Autokonfiguration
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.
Stateless DHCPv6
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.
Problem: Providerwechsel
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.
Umnummerierung und IPv6
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 einfacher 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.
Ausfallsicherheit
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.
Mobile IPv6
Mobile IP wurde als Erweiterung des IPv6-Standards unter dem Namen „Mobile IPv6“ (RFC 6275) in IPv6 integriert.
Überall unter der gleichen IP-Adresse erreichbar
Die Kommunikation erfolgt dabei virtuell immer unabhängig von der aktuellen Position der Knotenpunkte.
Somit erlaubt Mobile IP Endgeräten, überall unter der gleichen IP-Adresse erreichbar zu sein, beispielsweise im heimischen Netzwerk und auf einer Konferenz.
Home Agent
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.
Binding Updates
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.
IPv4
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
Feste Länge
Bei IPv6 eine feste Länge von 40 Byte (320 Bit)* Im Gegensatz zu IPv4 hat der IP-Kopfdatenbereich (Header)
Extension Headers
Optionale, seltener benutzte Informationen werden in so genannten Erweiterungs-Kopfdaten (engl.: Extension Headers) eingebettet * zwischen dem IPv6-Kopfdatenbereich und der eigentlichen Nutzlast (engl. Payload)
Kopfdatenbereich eines IPv6-Paketes laut RFC 2460:
Feld
Länge
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
Extension Headers
Die meisten IPv6-Pakete sollten ohne Extension Headers auskommen. Extension Headers können bis auf den Destination Options Header nur einmal in jedem Paket vorkommen. Befindet sich 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. Wie im Next Header Feld verwiesen sind einige Extension Headers und ein Platzhalter definiert:
Name
Typ
Größe
Beschreibung
RFCs
Hop-By-Hop Options
0
variabel
Optionen* von allen IPv6-Geräten zu beachten
wird z.B. für Jumbograms benutzt
RFC 2460
RFC 2675
Routing
43
variabel
Hier kann der Weg des Paketes durch das Netzwerk beeinflusst werden* wird u.a. für Mobile IPv6 verwendet
RFC 2460
RFC 6275
RFC 5095
Fragment
44
64 Bit
Parameter zur Fragmentierung
RFC 2460
Authentication Header (AH)
51
variabel
Daten zur Vertraulichkeit (IPsec)
RFC 4302
Encapsulating Security Payload (ESP)
50
variabel
Daten zur Verschlüsselung (IPsec)
RFC 4303
Destination Options
60
variabel
Optionen* nur vom Zielrechner zu beachten
RFC 2460
Mobility
135
variabel
Daten für Mobile IPv6
RFC 6275
No Next Header
59
leer
Platzhalter* zeigt Ende eines Header-Stapels an
RFC 2460
Next-Header
Alle Extension Headers enthalten ein Next-Header-Feld, in dem * der nächste Extension Header oder
das Upper Layer Protocol genannt wird
Größen immer Vielfache von 64 Bit* Speicherzugriffe im Router beschleunigen
die meisten Felder der Kopfdatenbereiche sind auf 64-Bit-Grenzen ausgerichtet
Keine Prüfsummen
Es werden keine Prüfsummen über die IP-Kopfdaten berechnet* im Gegensatz zu IPv4
Fehlerkorrektur auf Schichten 2 und 4
Maximum Transmission Unit
Die Maximum Transmission Unit (MTU) beschreibt die maximale Paketgröße eines Protokolls der Vermittlungsschicht (Schicht 3) des OSI-Modells, gemessen in Oktetten, welche ohne Fragmentierung in den Rahmen (engl. "Frames") eines Netzes der Sicherungsschicht (Schicht 2) übertragen werden kann.
Diese Paketgröße passt also in die Nutzlast (Payload) des Protokolls der Sicherungsschicht. Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der Sicherungsschicht (engl. 'link MTU') bezeichnet.
Die maximale Größe eines Rahmens der Sicherungsschicht lässt sich so berechnen:
Maximale Rahmengröße =
Größte MTU aller benutzten Protokolle der Vermittlungsschicht + Größe der Sicherungsschichtheader
Die MTU wird durch Einstellungen im Rahmen der Möglichkeiten der verwendeten Hardware und Technik bestimmt.
Sie kann auf derselben Schnittstelle unterschiedliche Werte für unterschiedliche Protokolle der Vermittlungsschicht (z. B. IPv4 oder IPv6) annehmen.
Alle an einem Schicht-2-Netz beteiligten Schnittstellen, welche Protokolle höherer Schichten verarbeiten, müssen auf denselben Wert für die jeweiligen Schicht-3-Protokolle eingestellt werden.
Im OSI-Modell spricht man auf der Vermittlungsschicht von einem Paket (engl. 'packet'), während man auf der Sicherungsschicht von einem Rahmen (engl. 'frame') spricht.
Die Terminologie, welche das OSI-Modell für die Einheiten auf den verschiedenen OSI-Modellschichten verwendet, hat zu einiger Verwirrung um den Begriff der MTU geführt (siehe abweichende Verwendung bei wichtigen Herstellern).
Unter der „packet size“ (Paketgröße) wird fälschlicherweise teils die „frame size“ (Rahmengröße) verstanden, jedoch stellt die obige Definition (siehe RFC 1122 und RFC 791) dies eindeutig klar.
Ein Spezialfall liegt vor, wenn ein Schicht-2-Protokoll über ein anderes Schicht-2-Protokoll getunnelt wird, denn dann nennt man auch die Nutzlast selbst "Rahmen" (engl. 'frame').
Typische MTU-Größen
Medium
MTU in Bytes
Hyperchannel
65535
Token Ring(4)(802.5)
4464
Token Ring(16)
17914
FDDI
4352
Ethernet
1500
Gigabit Ethernetmit Jumboframes
9000
PPPoE (z. B. DSL)
≤ 1492
SLIP/PPP (low delay)
296
X.25
576
FibreChannel
theoretisch unbegrenzt
ISDN
576
DQDB
HIPPI
ATM
4500, s. u.
ARCNET
802.11
2312 (WiFi)
Die Path MTU (PMTU) beschreibt die maximale Paketgröße, die entlang der gesamten Wegstrecke übertragen werden kann, ohne einer Fragmentierung zu unterliegen.
Sie ist damit gleich der kleinsten MTU aller Schicht-2-Teilstücke im Pfad. Die PMTU kann automatisch durch PMTU Discovery (PMTUD) ermittelt werden.
Beispiel Brief
Das Konzept der MTU auf die Post adaptiert ist verständlicher.
Eine MTU 50 g heißt, dass man max. 50 g Inhalt (entspricht der Packet Size) in den Brief einpacken kann.
Der Brief insgesamt kann selbst aber schwerer als 50 g sein, da im Normalfall noch ein Briefumschlag z.B. 4 g und eine Briefmarke 0,3 g hinzukommt.
Bezahlt und verschickt wird der ganze Brief von 54,3 g Masse entsprechend der Frame Size.
Beispiel Ethernet
Ein Ethernetrahmen besteht aus zwei Teilen: dem „Header“, in dem Quell- und Zieladressen und andere wichtige Parameter für den Versand kodiert sind, und der Nutzlast, deren Größe durch die MTU bestimmt ist.
In diesem Versuch ist die Größe der MTU mit 1500 Byte vorgegeben.
Mit Hilfe des ping-Programmes wird ein „Frame“ erzeugt, der dann im Netzwerk über das Ethernet-Protokoll versendet wird.
Die Verwendung des Begriffes Nutzlast ist hier mehrdeutig, da im OSI-Modell die verschiedenen Protokolle ineinander eingepackt (gekapselt) werden.
Mit einem Sniffer wie z. B. Wireshark wird als Ethernet Header nur die Größe von 14 Byte angezeigt. Hierzu kommt noch die 4 Byte große Frame Check Sequence am Ende des Frames.
Falls VLANs verwendet werden, besteht der Header der Sicherungsschicht aus 18 Byte und der gesamte Ethernetrahmen kann eine Größe von bis zu 1522 Byte annehmen.
Würde IPv6 verwendet, änderte sich obige Berechnung dahingehend, dass der IPv6-Header der Vermittlungsschicht 40 statt 20 Byte beträgt und damit statt 1472 Byte ICMP-Nutzlast nur 1452 Byte möglich wären.
Oft ist es hilfreich dem ping-Programm vorzugeben das „don’t fragment (DF) bit“ für die Testpakete im IPv4-Header zu setzen,
für Linux z. B.
ping -M do -s 1472 10.0.0.1
für Windows
ping -l 1472 -f 10.0.0.1
denn dann erhält man eine Nachricht, falls die MTU überschritten wird. Leicht sichtbar machen lässt sich die Path MTU mit dem Programm tracepath für IPv4 bzw. tracepath6 für IPv6.
Einfluss auf andere Protokolle
Die MTU ist ein hardwareabhängiger Wert, der sämtliche Parameter oberhalb der Sicherungsschicht des OSI-Modells beeinflusst.
Am Beispiel Ethernet ist dies einfach erklärt: In diesem Netzwerk werden sämtliche Pakete der Schicht 3, beispielsweise IP-Pakete, in „Ethernet-Frames“ übertragen.
Die Nutzdaten dieses Ethernet-Frames (d. h. die IP-Pakete) dürfen den MTU-Wert nicht übersteigen. Die Länge der TCP-Nutzdaten (Maximum Segment Size) wird daher aus der MTU direkt berechnet.
Andere Beispiele und Probleme
Jumbo Frames für Gigabit Ethernet können deutlich mehr als 1518 Oktette beinhalten und damit ist es möglich, größere Pakete unfragmentiert zu übertragen.
Positiv wiegt, dass der Protokoll-Overhead bei der Verwendung von Jumbo Frames reduziert werden kann und Router weniger Pakete behandeln müssen.
Allerdings ist die Terminologie bzgl. MTU derart uneinheitlich unter den Herstellern, dass es in der Praxis schwierig ist, von den Standardeinstellungen abzuweichen.
Des Weiteren sind Jumbo Frames nicht im IEEE-802.3-Standard spezifiziert, trotzdem unterstützen die meisten Hersteller von Gigabit Ethernet Switches und Routern MTUs bis 9000 Oktette.
So hat sich als Quasistandard eine Path MTU um ca. 1500 Byte im Internet eingebürgert, die durch das weit verbreitete Fast Ethernet sowieso meist nicht überschritten werden kann.
Mit dem Aufkommen von Internetzugängen, die auf Tunnelprotokollen basieren, zum Beispiel beim Verbindungsaufbau über das PPPoE-Protokoll hat die MTU an Bedeutung gewonnen.
Obwohl die PMTUD in diesem Fall dafür sorgen soll, dass die Kommunikation trotz der durch den Tunnel abgesenkten MTU möglich ist, gibt es immer wieder fehlkonfigurierte Firewalls, die durch Verwerfen von ICMP-Steuerpaketen die PMTUD stören.
Auch große Websites sind oft von diesem Konfigurationsfehler betroffen, sodass die Nutzer von getunnelten Zugängen die MTU ihrer Geräte verkleinern müssen, um auch mit diesen Sites kommunizieren zu können.
Über die optimale MTU gibt es viele Diskussionen.
Kurz zusammengefasst:* einfache Optimierung: so groß wie möglich, ohne dass Probleme auftreten
komplexe Optimierung: so viel kleiner als o. g. Maximum, dass der Verschnitt der Transportzellen der unter der DSL-Schicht liegenden ATM-Transportschicht möglichst klein wird.
oder einfach probieren
Die MTU bei ATM (4500) ist nicht zu verwechseln mit der Zellengröße (53 Bytes, 48 davon Nutzlast).
Bei der Übertragung über einen ATM-Link werden IP-Pakete in Stücke zu je 48 Bytes zerlegt und für die Übertragung auf mehrere ATM-Zellen verteilt. Der Router am anderen Ende des ATM-Links sammelt diese Zellen und setzt das ursprüngliche IP-Paket wieder zusammen.
Im Gegensatz dazu wird bei der IP-Fragmentierung das Paket nicht vom Router reassembliert, sondern erst von dem Host, für den das Paket bestimmt war.
Probleme, die durch einen falschen MTU-Wert auftreten können, sind Webseiten, die gar nicht oder nur teilweise angezeigt werden.
Abweichende Verwendung des Begriffs
Die Routerhersteller Cisco und Juniper verwenden den Begriff MTU in ihrer Konfigurationssyntax als maximale Rahmen- bzw. Paketgröße der zu konfigurierenden Netzwerkschicht. Folgende Einstellungen entsprechen einander.
Bei beiden Herstellern bedeutet das erste Auftauchen des Begriffs die maximale Ethernet Rahmengröße und nicht die maximale Größe der Nutzlast und diese muss folglich einige Byte größer gewählt werden als die dann folgenden Einstellungen für die verschiedenen Schicht-3 Protokolle.
Cisco:
interface GigabitEthernet2/3
mtu 9192
ip address 192.168.0.1 255.255.255.252
ip mtu 9000
ipv6 address 2001:DB8::1/64
ipv6 mtu 8000
ipv6 router isis
clns mtu 1497
!
Juniper:
interfaces {
ge-0/0/0 {
mtu 9192;
unit 0 {
family inet {
mtu 9000;
address 192.168.0.2/30;
}
family inet6 {
mtu 8000;
address 2001:DB8::2/64;
}
family iso {
mtu 1497;
}
}
}
}
Paketgrößen
Jumbograms
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, außerdem muss bei jedem Paket, welches einen Jumbogram beinhaltet, im IPv6-Header die Payload-Length auf 0 gesetzt werden.
Erweiterte ICMP-Funktionalität
Unverzichtbar
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.
ARP und NDP
Insbesondere wird das Address Resolution Protocol (ARP) durch das Neighbor Discovery Protocol (NDP) ersetzt, welches auf ICMPv6 basiert. * macht hierbei intensiv Gebrauch von Link-Local-Unicast-Adressen und Multicast
das von jedem Host beherrscht werden muss
Default-Routen
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 UDP-Pakete benutzt.
Fragmentierung
Fragmentierung überlanger IPv6-Pakete erfolgt nicht mehr durch die Router
Absender wird mit Hilfe von ICMPv6-Nachrichten aufgefordert, kleinere Pakete zu schicken
auch unter Zuhilfenahme des Fragment Extension Headers
Path MTU Discovery
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.
ICMPv6
ICMPv6 (Internet Control Message Protocol Version 6)
Familie:
Internetprotokolle
Einsatzgebiet:
Obligatorischer Zusatz zu IPv6, Fehlermeldungen, Diagnose, Autoconfiguration, Routing
Internet-Protokolle im TCP/IP-Protokollstapel
Internet
ICMPv6
IPv6
Netzzugang
Ethernet
TokenBus
IEEE802.11a/b/g/n
FDDI
…
Standards:
RFC 4443 (2006)
Das Internet Control Message Protocol for the Internet Protocol Version 6 (ICMPv6) ist die mit IPv6 zusammen verwendete Version des Internet Control Message Protocol.
Es dient, wie schon bei IPv4, in Netzwerken zum Austausch von Fehler- und Informationsmeldungen. Zusätzlich findet es aber noch im Neighbor Discovery Protocol, dem Ersatz des Address Resolution Protocol, Verwendung.
Im Gegensatz zum ICMP bei IPv4 ist ICMPv6 zwingend für den Betrieb von IPv6 nötig. Ein generelles Blockieren von ICMPv6 auf der Firewall führt dazu, dass IPv6 nicht funktioniert (vgl. RFC 4890).
Auch wenn ICMPv6 auf derselben Netzwerkschicht ist wie IPv6, werden die ICMPv6-Nachrichten vor dem Versenden in IPv6-Pakete eingepackt und so verschickt.
Als Protokoll-Nummer wird 58 ins Next-Header-Feld des IPv6-Headers eingefügt.
ICMPv6-Header
ICMPv6 Header
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
…
ICMPv6-Nachricht …
Das Feld Type gibt die Klasse der ICMP-Nachricht an, welche mit dem Feld Code genauer spezifiziert werden kann. Die Prüfsumme wird zum Prüfen der Gültigkeit des ICMPv6-Pakets benutzt.
Der restliche Inhalt der ICMP-Nachricht wird durch den jeweiligen Typ bestimmt.
Dei Fehlernachrichten wird nach den möglichen zusätzlichen Feldern immer noch so viel wie möglich vom fehlerverursachenden Paket angehängt.
ICMPv6-Typen
Die Nachrichten-Typen werden in zwei Gruppen unterteilt. * Die ersten 128 Typen (0–127) mit dem höchstwertigen Bit (engl. most significant bit) auf 0, sind Fehlernachrichten.
Die zweiten 128 Typen (128–255), mit dem höchstwertigem Bit auf 1, sind Informationsnachrichten.
Fehlernachrichten
Type
Beschreibung
RFC
1
Destination Unreachable
RFC 4443
2
Packet Too Big
RFC 4443
3
Time Exceeded
RFC 4443
4
Parameter Problem
RFC 4443
100
Private experimentation
101
Private experimentation
Informationsnachrichten
Type
Beschreibung
RFC
128
Echo Request
RFC 4443
129
Echo Reply
RFC 4443
130
Multicast Listener Query
RFC 2710 und RFC 3810
131
Version 1 Multicast Listener Report
RFC 2710
132
Multicast Listener Done
RFC 2710
133
Router Solicitation
RFC 4861
134
Router Advertisement
RFC 4861
135
Neighbor Solicitation
RFC 4861
136
Neighbor Advertisement
RFC 4861
137
Redirect
RFC 4861
138
Router Renumbering
139
ICMP Node Information Query
RFC 4620
140
ICMP Node Information Response
RFC 4620
141
Inverse Neighbor Discovery Solicitation Message
RFC 3122
142
Inverse Neighbor Discovery Advertisement Message
RFC 3122
143
Version 2 Multicast Listener Report
RFC 3810
144
Home Agent Address Discovery Request Message
RFC 3775
145
Home Agent Address Discovery Reply Message
RFC 3775
146
Mobile Prefix Solicitation
RFC 3775
147
Mobile Prefix Advertisement
RFC 3775
148
Certification Path Solicitation Message
RFC 3971
149
Certification Path Advertisement Message
RFC 3971
150
ICMP messages utilized by experimental mobility protocols such as Seamoby
RFC 4065
151
Multicast Router Advertisement
RFC 4286
152
Multicast Router Solicitation
RFC 4286
153
Multicast Router Termination
RFC 4286
200
Private experimentation
201
Private experimentation
255
Reserved for expansion of ICMPv6 informational messages
Prüfsumme
Prüfsummen-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
IPv6-Absender-Adresse
32
64
96
128
IPv6-Ziel-Adresse
160
192
224
256
IPv6-Nutzlast-Größe
288
Checksumme 0
Next Header 58
Die Prüfsumme (engl. checksum) eines ICMPv6-Pakets ist ein 16-Bit-Einerkomplement der Summe des Einerkomplements der gesamten ICMPv6-Nachricht.
Zusätzlich zur Nachricht wird noch ein IPv6-Pseudoheader vorne angehängt.
Zur Berechnung der Prüfsumme wird das Prüfsummenfeld auf 0 gesetzt. Der zur Berechnung der Prüfsumme verwendete Pseudoheader sieht wie im Schema nebenan aus.
Dies ist eine der Neuerungen von ICMPv6 gegenüber ICMP, wo die Prüfsumme nur über den ICMP-Header berechnet wurde.
ICMPv6-Verarbeitung
Für die Verarbeitung von ICMPv6-Nachrichten gelten folgende Regeln:* Unbekannte ICMPv6-Fehlernachrichten müssen an die darüberliegende Netzwerkschicht weitergereicht werden.
Unbekannte ICMPv6-Informationsnachrichten müssen kommentarlos verworfen werden.
Jeder Fehlernachricht wird am Ende so viel wie möglich des fehlerverursachenden Pakets angehängt.
Die Protokollnummer zum Weiterreichen von unbekannten Fehlernachrichten wird aus dem angehängten Originalpaket entnommen.
Auf folgende Pakete werden keine Fehlernachrichten versandt:
Fehlernachrichten
Pakete an Multicast-, Link-Level-Multicast- oder Link-Level-Broadcast-Adressen mit folgenden Ausnahmen:
Packet-Too-Big-Nachrichten
Parameter-Problem-Nachrichten mit Code 2 – unbekannte IPv6-Option
Das Netz darf nicht mit ICMPv6-Fehlernachrichten geflutet werden.
ICMP-Standard-Typen
Destination Unreachable – Type 1
Destination-Unreachable-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
32
Unbenutzt
…
Fehlerhaftes Paket
Destination-Unreachable-Nachrichten sollten vom Router erzeugt werden, wenn ein Paket nicht ausgeliefert werden konnte. * Wenn das Paket wegen Überlastung fallen gelassen wurde, muss keine Destination Unreachable versandt werden.
Wenn das Paket wegen fehlender Routen nicht ausgeliefert wurde, wird der Code 0 gesetzt.
Ist das Ausliefern administrativ verboten (Firewall), wird der Code 1 gesetzt.
Wenn der Router die IPv6-Adresse nicht auflösen kann, oder ein Problem mit dem Link hat, wird der Code 3 gesetzt.
Wenn ein Zielhost für ein UDP-Paket keinen Listener hat, sollte er ein Destination Unreachable mit Code 4 versenden.
Wenn ein Destination Unreachable empfangen wird, muss es der darüberliegenden Schicht weitergereicht werden.
Packet Too Big – Type 2
Packet-Too-Big-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
32
MTU
…
Fehlerhaftes Paket
Eine Packet-Too-Big-Nachricht muss vom Router erzeugt werden, wenn ein Paket nicht weitergeleitet werden kann, weil es größer ist als die maximale MTU des Links, über den es versendet werden soll.
Packet-Too-Big-Nachrichten werden vom Path MTU Discovery dazu gebraucht, um die pfadabhängige MTU zu ermitteln.
Der Code sollte vom Sender auf 0 gesetzt und vom Empfänger ignoriert werden.
Wenn ein Packet Too Big empfangen wird, muss es dem darüberliegenden Layer weitergereicht werden.
Time Exceeded – Type 3
Time-Exceeded-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
32
Unbenutzt
…
Fehlerhaftes Paket
Wenn ein Router ein Paket mit einem Hop-Limit von 0 erhält, oder sie auf 0 verkleinert, muss er das Paket verwerfen und ein Time Exceeded mit Code 0 versenden.
Das zeigt entweder eine Endlosschleife im Routing an oder ein zu kleines anfängliches Hop-Limit.
Wenn von einer fragmentierten Nachricht nicht alle Fragmente innerhalb einer gewissen Zeit ankommen, wird das Paket verworfen und es muss ein Time Exceeded mit Code 1 versendet werden.
Parameter Problem – Type 4
Parameter-Problem-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
32
Pointer
…
Fehlerhaftes Paket
Wenn ein Host beim Verarbeiten eines IPv6-Pakets ein Problem in einem Feld feststellt und nicht mit der Verarbeitung weiterfahren kann, muss er das Paket verwerfen und eine Parameter-Problem-Nachricht verschicken.
Mit dem Code wird dabei die Art des Problems genauer beschrieben.
0
Fehlerhaftes Header-Feld gefunden
1
Unbekannter Next-Header-Typ gefunden
2
Unbekannte IPv6-Option
Der Pointer zeigt dabei auf die Stelle im Paket, an der das Problem aufgetreten ist.
Echo Request – Type 128
Echo-Request-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
32
Identifikation
Sequenznummer
…
Daten
Mit einem Echo Request wird um eine Antwort gebeten. Ein Echo Request ist nichts anderes als ein simpler Ping.
Das Datenfeld kann mit Daten vergrößert werden, um größere Pakete zu produzieren. So kann man zum Beispiel die MTU ermitteln.
Jedes System muss auf Echo Requests reagieren und mit Echo Replies antworten. Auch sollte jedes System eine Anwendung zum Versenden und Empfangen von Echo Request/Replies besitzen.
Empfangene Echo Request können an Anwendungen weitergeleitet werden, die auf ICMP-Nachrichten horchen.
Echo Reply – Type 129
Echo-Reply-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
32
Identifikation
Sequenznummer
…
Daten
Auf eine Echo-Request-Nachricht muss mit einem Echo Reply geantwortet werden. Das Paket ist bis auf das Typenfeld dasselbe. Echo-Reply-Nachrichten sollen nur an Unicast-Adressen verschickt werden.
Anhand der Identifikation und der Sequenznummer wird der Empfänger die Antworten zu seinen Anfragen zuordnen können.
Empfangene Echo-Reply-Nachrichten müssen an die Anwendung weitergereicht werden, die den zugehörigen Echo Request versendet hat.
An die restlichen auf ICMP horchende Anwendungen kann es weitergereicht werden.
Multicast Listener Discovery – Type 130
MLD ist die Implementation von IGMP (IPv4) in IPv6. Es wird also genutzt um Multicast Abonnements zu verwalten. Dabei entspricht MLDv1 IGMPv2 und MLDv2 IGMPv3.
Bei den jeweils neueren Versionen lässt sich bestimmen, welche Quell-Adressen für Multicast-Steams akzeptabel sind. Linux unterstützt es seit 2003 (2.5.68), Windows seit 2006 (Vista), FreeBSD seit 2009 (8.0)
Das Address Resolution Protocol (ARP) ist ein Netzwerkprotokoll, das zu einer Netzwerkadresse der Internetschicht die physikalische Adresse (Hardwareadresse) der Netzzugangsschicht ermittelt und diese Zuordnung gegebenenfalls in den so genannten ARP-Tabellen der beteiligten Rechner hinterlegt.
Es wird fast ausschließlich im Zusammenhang mit IPv4-Adressierung auf Ethernet-Netzen, also zur Ermittlung von MAC-Adressen zu gegebenen IP-Adressen verwendet, obwohl es nicht darauf beschränkt ist. Für IPv6 wird diese Funktionalität nicht von ARP, sondern durch das Neighbor Discovery Protocol (NDP) bereitgestellt.
Verwendungen
MAC-Adressen (Hardwareadressen) werden vom Hersteller einer Ethernet-Netzwerkkarte oder eines Ethernet-fähigen Gerätes vergeben. Die Adresse jeder Schnittstelle ist dabei theoretisch weltweit eindeutig.
Bei einigen Netzen, wie zum Beispiel Novell und DECnet, werden die Netzwerkadressen eindeutig auf die Ethernetadressen abgebildet, etwa, indem die MAC-Adresse um weitere Informationen ergänzt wird. Ein Sender kann dann die MAC-Adresse des Empfängers einfach aus der Netzwerkadresse ermitteln.
IP-Adressen werden von der IANA (Internet Assigned Numbers Authority) zugeteilt. Da IPv4-Adressen nur aus 32 Bits bestehen, sind sie nicht in der Lage, MAC-Adressen zu speichern.
Aus diesem Grund besteht keine feste Beziehung zwischen MAC-Adressen und IP-Adressen. Bevor ein Rechner in einem Ethernet an einen Rechner im selben Subnetz ein IP-Paket sendet, muss er die Information in einen Ethernetframe verpacken.
Dazu muss er die MAC-Adresse des Zielrechners kennen und im entsprechenden Feld des Ethernetframes einfügen. Ist ihm diese nicht bekannt, kann er das IP-Paket nicht zustellen. Stattdessen ermittelt er dann mit Hilfe des ARP zunächst die MAC-Adresse des Zielrechners.
Funktionsweise am Beispiel Ethernet
Es wird eine ARP-Anforderung (ARP Request) mit der MAC-Adresse und der IP-Adresse des anfragenden Computers als Senderadresse und der IP-Adresse des gesuchten Computers als Empfänger-IP-Adresse an alle Computer des lokalen Netzwerkes gesendet.
Als Empfänger-MAC-Adresse wird dazu die Broadcast-Adresse ff-ff-ff-ff-ff-ff16 verwendet. Empfängt ein Computer ein solches Paket, sieht er nach, ob dieses Paket seine IP-Adresse als Empfänger-IP-Adresse enthält.
Wenn dies der Fall ist, antwortet er mit dem Zurücksenden seiner MAC-Adresse und IP-Adresse (ARP-Antwort oder ARP-Reply) an die MAC-Quelladresse des Anforderers. Dieser trägt nach Empfang der Antwort die empfangene Kombination von IP- und MAC-Adresse in seine ARP-Tabelle, den sogenannten ARP-Cache, ein. Für ARP-Request und ARP-Reply wird das gleiche Paket-Format verwendet.
Zusätzlich können die Empfänger des ARP-Requests ebenfalls die Kombination von IP-Adresse und MAC-Adresse des anfragenden Computers in ihre ARP-Tabelle eintragen bzw. einen bestehenden Eintrag aktualisieren.
Insbesondere der Rechner mit der im ARP-Request angefragten IP-Adresse sollte diese Eintragung vornehmen, da anzunehmen ist, dass der ARP-Request als Vorbereitung für weitere Kommunikation auf höherer Protokollebene dienen soll, wofür er dann für eventuelle Antworten ebenfalls die MAC-Adresse des Anfragenden benötigt.
Der ARP-Cache enthält eine vierspaltige Tabelle, die im Allgemeinen aus <Protokolltyp, Protokolladresse des Senders, Hardware-Adresse des Senders, Eintragszeitpunkt> besteht.
Das Zeitintervall, nachdem ein Eintrag aus dem ARP-Cache gelöscht wird, ist implementierungsabhängig. So verwerfen aktuelle Linux-Distributionen Einträge nach ca. 5 Minuten. Sobald ein Eintrag in der Tabelle genutzt wird, wird dessen Ablaufzeit verlängert.
Unter Unix und Windows kann der ARP-Cache mit arp beziehungsweise arp -a angezeigt und mit dem entsprechenden Programm auch manipuliert werden.
Mit dem Zusatzprogramm arping können manuell Anforderungen versendet werden.
Das ARP ist für die Auflösung der MAC-Adressen im lokalen Netzwerk zuständig. Sollen Daten über Netzwerkgrenzen hinweg gesendet werden, wird das Internet Protokoll (IP) verwendet.
IP-Implementierungen sind in der Lage, zu erkennen, dass ein Paket nicht für das lokale Subnetz bestimmt ist und senden es an einen lokalen Router, der sich um die Weiterleitung des Pakets kümmert.
Dieser Router hat wiederum eine lokale MAC-Adresse, die über ARP ermittelt werden kann.
Das Flussdiagramm stellt den Zusammenhang von IP-Routing mit ARP dar.
Paketformat
Das ARP-Paket schließt sich an den Ethernet-MAC-Header an. Das Typfeld im Ethernetframe wird auf 0x0806 (2054) gesetzt. Diese Nummer ist für das ARP-Protokoll reserviert.
Dadurch lassen sich ARP-Pakete von Paketen anderer Protokolle wie beispielsweise IP unterscheiden.
Da das Paket sehr kurz ist, müssen in der Regel im Ethernetframe zwischen ARP-Paket und CRC zusätzliche Bytes eingefügt werden (Padding), um die minimale Framelänge von 64 Bytes zu erreichen.
Obwohl ARP ursprünglich für IPv4 und MAC-Adressen entwickelt wurde, sind im Paket Adresstypen und Protokollgrößenfelder vorgesehen. Dadurch ist ARP auch für andere Protokolle geeignet.
Für IPv6 könnten die Protokolladressgröße statt auf 4 auf 16 Bytes gesetzt und die Adressfelder auf 128 Bits (=16 Byte) verlängert werden, jedoch wird ARP für IPv6 durch das Neighbor Discovery Protocol (NDP) ersetzt, welches auf ICMPv6 basiert.
Bit 0–7
Bit 8–15
Bit 16–23
Bit 24–31
Hardwareadresstyp (1)
Protokolladresstyp (0x0800)
Hardwareadressgröße (6)
Protokolladressgröße (4)
Operation
Quell-MAC-Adresse
Quell-MAC-Adresse
Quell-IP-Adresse
Quell-IP-Adresse
Ziel-MAC-Adresse
Ziel-MAC-Adresse
Ziel-IP-Adresse
ARP-Nachrichtenformat am Beispiel Ethernet-MAC-Adressen und IPv4-Adressen
Hardwareadresstyp (2 Byte) enthält den Typ der MAC-Adresse im Paket (für Ethernet: 1).
Protokolladresstyp (2 Byte) enthält den Protokolltyp, der für die MAC-Adresse angefordert wird (für IPv4-Adressen: 0x0800 (2048)).
Hardwareadressgröße (1 Byte) enthält die Größe der MAC-Adresse (für Ethernet: 6).
Protokolladressgröße (1 Byte) enthält die Größe des Protokolls (für IPv4: 4).
Operation (2 Byte) enthält den Wert, der angibt, welche Operation ausgeführt werden soll (1 für ARP-Anforderung, 2 für ARP-Antwort).
Quell-MAC-Adresse (6 Byte) enthält in einer ARP-Anforderung die MAC-Adresse des Senders. In einer ARP-Antwort enthält es die MAC-Adresse des antwortenden Hosts oder Next-Hop-Routers.
Quell-IP-Adresse (4 Bytes bei IPv4) enthält bei einer ARP-Anforderung die IP-Adresse des anfragenden Hosts. In einer ARP-Antwort enthält es die IP-Adresse des antwortenden Hosts oder Next-Hop-Routers.
Ziel-MAC-Adresse (6 Byte) ist in einer ARP-Anforderung ein Broadcast (FF:FF:FF:FF:FF:FF). In einer ARP-Antwort enthält es die MAC-Adresse des anfragenden Hosts.
Ziel-IP-Adresse (4 Bytes bei IPv4) ist bei einer ARP-Anforderung die IP-Adresse des gesuchten Hosts. In einer ARP-Antwort enthält es die IP-Adresse des anfragenden Hosts.
Spezielle ARP-Nachrichten
Proxy ARP
Proxy ARP erlaubt einem Router, ARP-Anforderungen für Hosts zu beantworten.
Die Hosts befinden sich dabei in durch einen Router getrennten Netzen - verwenden untypischerweise jedoch den gleichen IP-Adressenbereich. Bei der Kommunikation ist für die Hosts der Router transparent, das heißt, er braucht nicht speziell angesprochen zu werden, sondern die Hosts können wie gewöhnlich Pakete über verschiedene Netze hinweg versenden.
Sendet Computer A eine ARP-Anforderung an Computer B, reagiert der dazwischen liegende Router anstelle des Computers B mit einer ARP-Antwort und der Hardwareadresse der Schnittstelle (MAC des Ports am Router), auf der die Anfrage empfangen wurde. Der anfragende Computer A sendet dann seine Daten an den Router, der sie dann an Computer B weiterleitet.
Proxy ARP kann man am ARP-Cache von Computer A erkennen. Falls für mehrere IP-Adressen dieselbe MAC-Adresse eingetragen ist, arbeitet der Router mit dieser MAC-Adresse als Proxy. Die Einträge können auch ein Hinweis auf einen Angriff durch ARP-Spoofing sein.
Gratuitous ARP
Gratuitous ARP (engl. „unaufgefordertes ARP“) bezeichnet eine spezielle Verwendung von ARP. Dabei sendet ein Host ein ARP-Anforderungs-Broadcast, bei dem er seine eigene IP-Adresse als Quell- und Ziel-IP-Adresse einträgt. Damit teilt er seine ggf. neue MAC-Adresse unaufgefordert mit. Das kann mehreren Zwecken dienen:# Normalerweise darf keine Antwort kommen, denn eine IP-Adresse muss in einem Netz eindeutig sein. Bekommt er trotzdem eine Antwort, ist das für den Administrator ein Hinweis darauf, dass ein Host nicht richtig konfiguriert ist.
Jeder Host aktualisiert seinen ARP-Cache. Das ist beispielsweise dann nützlich, wenn die Netzwerkkarte eines Rechners ausgetauscht wurde und die anderen Hosts über die neue MAC-Adresse informiert werden sollen. Gratuitous ARP geschieht deshalb normalerweise beim Booten eines Computers.
Wenn zwei Server aus Gründen der Ausfallsicherheit als Server und Ersatzserver aufgebaut sind und sich eine IP-Adresse teilen und der aktive Verkehr vom einen auf den anderen geschwenkt werden soll, ist die IP-Adresse jetzt über eine andere MAC-Adresse zu erreichen. Diese neue MAC-/IP-Adress-Zuordnung muss bekannt gemacht werden. Sonst bekommt niemand den Wechsel mit.
In einem Mobile-IP-Szenario sendet der Home Agent einen Gratuitous ARP, wenn sich der Mobile Host aus dem Heimatnetz entfernt, um die Pakete stellvertretend für diesen zu empfangen. Analog sendet der Mobile Host einen Gratuitous ARP, sobald er sich wieder im Netz befindet.
RARP – Reverse-ARP
Das Reverse-ARP (RARP) funktioniert umgekehrt zu ARP. Es kann also MAC-Adressen zu IP-Adressen auflösen.
Dies ist für die Ermittlung der eigenen IP-Adresse bei Geräten nützlich, bei denen keine dauerhafte Speicherung oder Zuweisung einer Adresse vorgesehen ist.
Beide Protokolle besitzen das gleiche Paketformat. Die Anwendungsbereiche von RARP und ARP unterscheiden sich jedoch stark voneinander.
Probleme
ARP ist für den Benutzer unsichtbar, sodass das Vorhandensein dieses Protokolls meist nur bemerkt wird, wenn seltene Fehler auftreten.
Die Dauer der Gültigkeit eines ARP-Eintrags (normalerweise wenige Minuten) kann ein Problem darstellen, wenn falsche Einträge vorhanden sind. Solange ein fehlerhafter Eintrag existiert, kann mit dem betreffenden Host nicht kommuniziert werden. Die Fehlfunktion wird häufig nicht dem ARP-Protokoll zugeschrieben, sondern dem Netz oder einem Fehler in der Netzwerkimplementierung. Darüber hinaus ermöglicht nicht jedes Betriebssystem das Erzeugen eines korrigierten Eintrags oder einer Anforderung.
Gravierender ist das Eintragen von Daten in den ARP-Cache aus Paketen, für die keine Anforderung erzeugt wurde (blinder Glaube). Ein überlasteter Host, der eine alte IP-Adresse führt, antwortet mit großer Wahrscheinlichkeit als letzter auf eine ARP-Anforderung mit einer Antwort, die die falsche Adresse enthält. Dieses letzte Paket überschreibt die ARP-Tabelle aller Geräte im Netz, ein fehlerhafter Eintrag bleibt übrig.
ARP-Spoofing
Mit ARP-Spoofing ist es möglich, absichtlich eine falsche Hardwareadresse in einem Netz zu verteilen. Dadurch kann der Datenverkehr für einen Rechner auf einen anderen umgelenkt und eventuell von diesem sogar verändert werden (Man-In-The-Middle-Angriff). Das stellt ein Sicherheitsproblem dar.
ARP-Spoofing ist aufgrund der Architektur von ARP sehr einfach zu realisieren. Es müssen einfach ARP-Pakete mit den falschen MAC-/IP-Kombinationen versendet werden. Daraufhin wird keiner der Empfängerrechner irgendwelche Überprüfungen anstellen, sondern die Daten einfach in seinen Cache eintragen.
Moderne Implementierungen ändern die ARP-Tabelle nur für ARP-Antworten, für die vorher vom betreffenden Host eine Anforderung generiert wurde.
Neighbor Discovery Protocol
Neighbor Discovery Protocol (NDP) ist der Ersatz des Address Resolution Protocol (ARP) von IPv4 für IPv6. Es wird unter anderem dazu benutzt, IPv6-Adressen in Link-Layer-Adressen aufzulösen.
Verwendung
NDP wird von den am IPv6-Netzwerk beteiligten Knoten benutzt, um die Link-Layer-Adresse von anderen am selben Netzwerk hängenden Knoten ausfindig zu machen und zum Aktualisieren der gecachten Adressen.
Für alle nicht am selben Netzwerk hängenden Knoten wird NDP benutzt, um einen/den Router zu finden, der die Pakete weiterleiten kann.
Funktionsweise
Für NDP muss der Knoten für jedes Interface folgende Informationen verwalten:
Im Neighbor Cache werden Adressen verwaltet, an die etwas gesendet wurde und die sich im selben Netzwerk befinden. Zu jedem Eintrag einer IPv6-Adresse steht ihre Link-Layer-Adresse.
Auch weitere Informationen werden hier verwaltet, wie zum Beispiel Pointer auf Pakete, die auf die Adressauflösung warten, Informationen für die Erreichbarkeitsprüfung oder ob es ein Router ist.
Im Destination Cache werden Adressen verwaltet, an die etwas gesendet wurde. Für jeden Eintrag wird, per Link auf den Neighbor Cache, gespeichert, welches der nächste Hop ist, den ein Paket nehmen soll.
In der Prefix List werden die Präfixe verwaltet, die auf demselben Netz gültig sind. Jeder Eintrag, außer der zur link-lokalen Adresse, hat ein Ablaufdatum. Somit bleiben nur Netze in der Liste, die von einem Router verkündet werden.
In der Default Router List werden alle Router verwaltet, die für das Interface bekannt sind. Die Einträge verweisen auf Einträge im Neighbor Cache.
Zusätzlich haben sie ein Ablaufdatum, sodass alte Router verschwinden und nur die erhalten bleiben, die ihre Anwesenheit verkünden.
Die Informationen zum Erstellen dieser Listen werden per ICMPv6 (Internet Control Message Protocol V6) ausgetauscht. NDP definiert zu diesem Zweck fünf ICMPv6-Typen.
Router- und Präfix-Ermittlung
Router versenden in gewissen Zeitabständen Router-Advertisement-Nachrichten per Multicast. Die Informationen in diesen Nachrichten werden verwendet, um die Default Router List und die Prefix List zu erstellen.
Nach Ablauf der angegebenen Lebenszeit werden die Einträge wieder aus den Listen gelöscht. Dadurch bleiben nur Router eingetragen, die aktiv sind und ihre Anwesenheit periodisch kundtun.
Um nicht auf das nächste geplante Router Advertisement warten zu müssen, kann ein Knoten per Router-Solicitation-Nachricht an die Router-Multicast-Adresse ein Router Advertisement erzwingen.
Dies ist besonders beim Aktivieren eines neuen Interfaces von Vorteil, um mit der Konfiguration nicht warten zu müssen.
Parameterermittlung
Mit diesem Mechanismus ermitteln Knoten relevante Parameter für den Link (z. B. die für den Link verwendete MTU), an dem sie angeschlossen sind, oder Internet Parameter (wie zum Beispiel den Wert für den Hop Limit), die für ausgehende Pakete verwendet werden müssen.
Adress-Autokonfiguration
Mit diesem Verfahren konfigurieren Netzknoten IPv6-Adressen für ihre Interfaces ohne einen DHCP-Dienst zu nutzen.
Bestimmung des nächsten Hops
Wenn ein Paket versendet werden soll, wird im Destination Cache nachgeschaut, ob für dieses Ziel schon ein Eintrag vorhanden ist. Wenn kein Eintrag existiert, wird anhand der Prefix List und der Default Router List der nächste Hop für das Paket ermittelt.
Diese Information wird dann im Destination Cache gespeichert, um dies nicht jedes Mal ermitteln zu müssen.
Wenn der neue Eintrag auf einen nichtvorhandenen Eintrag im Neighbor Cache zeigt, wird dieser ebenfalls erzeugt, als unfertig markiert und die Adressauflösung (engl. Address resolution) angestoßen. Das Paket wird in die Queue gestellt und im Neighbor Cache ein Pointer darauf gesetzt.
Adressauflösung
Um die Link-Layer-Adresse eines Knotens zu ermitteln, wird eine Neighbor-Solicitation-Nachricht per IPv6-Multicast an die sog. Solicited Nodes-Adresse des Ziels versendet. Anzumerken ist, dass auf Link-Layer-Ebene ebenfalls Multicast genutzt wird – jeder IPv6-Knoten muss also auf Link-Layer-Ebene nicht nur auf seine originäre feste Adresse (z. B. Ethernet) hören, sondern auch auf eine, auf seiner IPv6-Adresse beruhende, spezifische Multicast-Adresse.
Im Neighbor-Solicitation-Paket ist dann die vollständige gesuchte IPv6-Adresse in den Nutzdaten enthalten, und nur der Knoten mit der gleichen Adresse antwortet darauf.
Er verschickt eine Neighbor-Advertisement-Nachricht. Die darin enthaltenen Informationen werden im Neighbor Cache gespeichert. Wenn ein Eintrag noch unfertig war, kann er nun als erreichbar markiert werden und die Pakete, auf die er verweist, können ausgelöst werden.
Beispiel: Ein IPv6-Host in einem Ethernet-Netzwerk mit einer link-lokalen IPv6-Adresse fe80::021d:e0ff:fe2a:4242 hört auf der Link-Layer-Ebene nicht nur auf die Adresse 00:1d:e0:2a:42:42, sondern auch auf die Ethernet-Multicast-Adresse 33:33:ff:2a:42:42. 33:33 ist dabei der Teil, der ein IPv6 Multicast-Paket kennzeichnet, ff:2a:42:42 identifiziert die eigentliche Gruppe.
Das Multicast-Ziel für ein Neighbor-Solicitation-Paket auf IPv6-Ebene ist dann ff02::1:ff2a:4242.
Erkennung der Nichterreichbarkeit des Nachbarn
Um den Neighbor Cache aktuell zu halten, wird versucht herauszufinden, ob die Einträge darin noch aktuell sind. Es gibt dabei verschiedene Wege festzustellen, ob ein Knoten nicht aktiv ist.
Solange man TCP-Daten oder TCP-Empfangsbestätigungen erhält, weiß man, dass der Knoten noch erreichbar ist.
Wenn ein Eintrag seine Lebenszeit überschreitet, ohne durch Verkehr bestätigt zu werden, wird er als veraltet markiert. Sobald ein Paket versendet werden will, wird der Eintrag als verzögert markiert und für kurze Zeit versucht, ihn durch Verkehr zu bestätigen.
Wenn dies nicht passiert, wird erneut eine Neighbor-Solicitation-Nachricht gesendet, um den Knoten aktiv zu testen. Wenn er nicht antwortet, wird er aus dem Neighbor Cache gelöscht.
Erkennung doppelter Adressen
Mit diesem Verfahren ermitteln Netzknoten, ob die Adresse, die sie sich bei der Autokonfiguration gegeben haben, eindeutig ist.
Umleitung
Redirect-Nachrichten werden vom Router verschickt, um andere Knoten über einen besseren ersten Hop für eine Zieladresse zu informieren. Beim Empfangen einer solchen Nachricht wird der Destination Cache aktualisiert. Wenn kein passender Eintrag im Destination Cache gefunden wird, wird ein neuer erstellt.
ICMPv6-Typen
Router Solicitation – Type 133
Router-Solicitation-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
32
Reserviert
…
Optionen
Per Router Solicitation an die Router-Multicast-Adresse werden alle Router im selben Netz aufgefordert, sich zu melden.
Der Code dieser Nachricht ist immer 0. Das Feld „Reserviert“ muss vom Sender mit Nullen initialisiert werden und der Empfänger muss es ignorieren.
Die einzig mögliche Option ist die Link-Layer-Adresse des Senders. Um bei Protokollerweiterungen keine Probleme zu bekommen, müssen alle unbekannten Optionen ignoriert werden.
Router Advertisement – Type 134
Router-Advertisement-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
32
Hop-Limit
M
O
Reserviert
Router-Lifetime
64
Erreichbarkeits-Timeout
96
Auflösungs-Timeout
…
Optionen
Per Router Advertisement verkünden Router ihre Anwesenheit im Netz. Entweder auf Anfrage per Router Solicitation oder periodisch, um nicht vergessen zu werden.
Das Hop-Limit ist ein 8-Bit-Wert, der die vom Router vorgeschlagene Standard-Hop-Limits enthält. Ein gesetztes M-Bit sagt dem Knoten, dass er neben Autokonfiguration für die IP-Adresse auch Stateful-Autokonfiguration verwenden soll. Ein gesetztes O-Bit sagt dem Knoten, dass er neben Autokonfiguration für alle Nicht-IP-Adress-Informationen auch Stateful-Autokonfiguration verwenden soll.
Die Router-Lifetime ist ein 16-Bit-Integer, der angibt, wie viele Sekunden ein Router in der Default Router List bleiben soll. Das Maximum sind 18,2 Stunden. Ein Wert von 0 besagt, dass der Router kein Default Router ist und nicht in die Default Router List eingetragen werden soll.
Das Erreichbarkeits-Timeout ist ein 32-Bit-Integer, der angibt, wie viele Millisekunden ein Eintrag im Neighbor Cache nach dem Empfangen von Daten noch als erreichbar gelten soll. Das Auflösungs-Timeout ist ein 32-Bit-Integer, der angibt, nach wie vielen Millisekunden erneut ein Neighbor Solicitation gesendet werden soll.
Gültige Optionen sind die Link-Layer-Adresse des Senders, die MTU des Routers und alle gültigen Präfixe. Um problemfreie Protokollerweiterungen zu ermöglichen, müssen alle unbekannten Optionen ignoriert werden.
Neighbor Solicitation – Type 135
Neighbor-Solicitation-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
32
Reserviert
64
Zieladresse
96
128
160
…
Optionen
Per Neighbor Solicitation (soviel wie Nachbar Anfrage) an die Link-Layer-Multicast-Adresse einer IPv6-Adresse, die aus der Multicast-Adresse der betreffenden IPv6-Adresse mittels Adress-Mapping der letzten 3 Byte xx:yy:zz der Solicited-Node Multicast Adresse auf die letzten 3 Byte der Link-Layer Adresse 33:33:FF:xx:yy:zz berechnet wird, werden IPv6-Adressen zu Link-Layer-Adressen aufgelöst. Ebenfalls wird so die Erreichbarkeit eines Knotens geprüft.
Der Typ wird auf 135 gesetzt und der Code auf 0. Das reservierte Feld muss vom Sender mit Nullen initialisiert und vom Empfänger ignoriert werden. Die Zieladresse ist die IPv6-Adresse, die in eine Link-Layer-Adresse aufgelöst werden soll. Es darf keine Multicast-Adresse angegeben werden.
Die einzig mögliche Option ist die Link-Layer-Adresse des Senders. Um bei Protokollerweiterungen keine Probleme zu bekommen, müssen alle unbekannten Optionen ignoriert werden.
Neighbor Advertisement – Type 136
Neighbor-Advertisement-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
32
R
S
O
Reserviert
Reserviert
64
Zieladresse
96
128
160
…
Optionen
Mit einer Neighbor-Advertisement-Nachricht wird auf Neighbor-Solicitation-Nachrichten geantwortet.
Der Typ wird auf 136 gesetzt und der Code auf 0. Das R-Bit wird gesetzt, wenn der Knoten ein Router ist. Das S-Bit wird gesetzt, wenn das Neighbor Advertisement aufgrund einer Unicast-Neighbor-Solicitation-Nachricht gesendet wird.
Ein gesetztes O-Bit bedeutet, dass der Eintrag im Neighbor Cache aktualisiert werden muss. Das reservierte Feld muss vom Sender mit Nullen initialisiert werden und vom Empfänger ignoriert werden. Als Zieladresse wird die Link-Layer-Adresse angegeben, nach der gefragt wurde.
Die einzig mögliche Option ist die Link-Layer-Adresse des Senders. Um bei Protokollerweiterungen keine Probleme zu bekommen, müssen alle unbekannten Optionen ignoriert werden.
Redirect – Type 137
Redirect-Schema
+
Bits 0–7
Bits 8–15
Bits 16–23
Bits 24–31
0
Type
Code
Prüfsumme
32
Reserviert
64
Hop-Adresse
96
128
160
192
Zieladresse
224
256
288
…
Optionen
Per Redirect-Nachricht teilen Router mit, wenn es einen besseren ersten Hop für ein gewisses Ziel gibt.
Der Typ wird auf 137 gesetzt und der Code auf 0. Das reservierte Feld muss vom Sender mit Nullen initialisiert werden und vom Empfänger ignoriert werden. Die Hop-Adresse ist der zu bevorzugende Router für die Adresse. Die Zieladresse ist die Adresse für die es einen besseren First-Hop gibt.
Die einzigen möglichen Optionen sind die Link-Layer-Adresse des Senders und der Header des auslösenden Paketes. Um bei Protokollerweiterungen keine Probleme zu bekommen, müssen alle unbekannten Optionen ignoriert werden.
Implementierung in Betriebssystemen
Alle IPv6-fähigen Betriebssysteme, die in Ethernet-basierten Netzwerken betrieben werden, sind in der Lage, mittels NDP Adressen aufzulösen.
Unter den meisten Linux-Distributionen erhält man mit dem iproute2-Werkzeug Einsicht in den Neighbor Cache:
# ip -6 neigh
2001:470:1f0b:2f2:5cad:a77f:aaff:849 dev wlan0 lladdr 00:11:25:32:10:ab REACHABLE
fe80::2a10:7bff:fe65:58a dev wlan0 lladdr 28:10:7b:65:ab:cd router REACHABLE
2001:470:1f0b:2f2::cafe dev wlan0 lladdr 00:11:25:32:10:ab REACHABLE
Auf vielen BSD-basierten Systemen wie FreeBSD und OpenBSD hilft hierbei das Werkzeug ndp, wobei die Optionen '-an' bedeuten, dass alle Hosts numerisch angezeigt werden sollen; hier bei FreeBSD 9 (die Kommentare rechts wurden selbstverständlich nachträglich eingefügt):
# ndp -an
Neighbor Linklayer Address Netif Expire S Flags
2001:475:abcd:2f2:3189:67c1:b550:9400 c6:ab:27:56:b5:30 em0 14s R R # <-- Ein anderer Rechner im Netzwerk, mit Privacy Extensions
2001:475:abcd:2f2:211:25ff:fe32:10ab 00:11:25:32:10:ab em0 permanent R
fe80::211:25ff:fe32:10ab%em0 00:11:25:32:10:ab em0 permanent R
2001:475:abcd:2f2::cafe 00:11:25:32:10:ab em0 permanent R # <-- Alias-Adresse
fe80::2a10:7bff:fe65:58a%em0 28:10:7b:65:ab:cd em0 23h59m25s S R # <-- Das ist der Router
2001:475:abcd:2f2:5cad:a77f:aaff:849 00:11:25:32:10:ab em0 permanent R
fe80::c6ab:27ff:fe56:b530%em0 c6:ab:27:56:b5:30 em0 24s R R # <-- Derselbe Rechner wie in der ersten Zeile mit seiner link-local address
Hierbei ist insbesondere die Spalte Expire zu beachten. Sie legt fest, wann ein Namenseintrag als veraltet einzustufen ist. Die Adressen des Rechners selbst sind dabei permanent, der Router liegt hier bei fast 24 Stunden und die Nachbargeräte im Netzwerk liegen zumeist bei unter einer Minute, bis der Eintrag wieder aufgefrischt wird.
Unter Windows lautet der Befehl:
# netsh interface ipv6 show neighbors level=verbose
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.
AAAA
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.
Root-Nameserver
Elf 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.
IPv6 Test/Debug-Programme
Nachdem Sie ihr System auf IPv6 vorbereitet haben, wollen Sie nun IPv6 für die Netzwerkkommunikation einsetzen. Zuerst sollten Sie lernen, IPv6 Pakete mit einem Sniffer Programm zu untersuchen. Dies ist zu empfehlen, denn in Hinblick auf Fehlersuche und Troubleshooting kann das Durchführen einer schnellen Diagnose von Nutzen sein.
IPv6 ping
Das Programm ist normalerweise im Paket iputils beinhaltet. Durch senden von ICMPv6 echo-request Paketen und warten auf ICMPv6 echo-reply Paketen können einfache Transport-Tests durchgeführt werden.
Einige Implementierungen unterstützen auch %<device> Definition zusätzlich zu -I <device>, z.B.
# ping6 <link-local-ipv6address>%<device>
Beispiel
# ping6 -c 1 ::1
PING ::1(::1) from ::1 : 56 data bytes
64 bytes from ::1: icmp_seq=0 hops=64 time=292 usec
--- ::1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.292/0.292/0.292/0.000 ms
Hinweis: ping6 benötigt direkten Zugriff auf den Socket und hierfür Root-Rechte. Wenn Nicht-Root-Benutzer ping6 nicht benutzen können, kann dies zwei Ursachen haben:# ping6 ist nicht im Pfad des Benutzers eingetragen; ping6 ist allgemein in /usr/sbin zu finden -> Lösung: Den Pfad ergänzen (nicht empfohlen)
ping6 lässt sich im Allgemeines wegen fehlender Root-Rechte nicht korrekt ausführen -> Lösung: chmod u+s /usr/sbin/ping6
Das Interface für einen IPv6 ping bestimmen
Wenn link-lokale Adressen für ein IPv6 ping verwendet werden, dann hat der Kernel keine Kenntnis darüber, durch welches (physikalische oder virtuelle) Gerät das Paket gesendet werden muss - jedes Gerät hat eine link-lokale Adresse. Ein Versuch resultiert in folgender Fehlermeldung:
In diesem Fall müssen Sie das Interface zusätzlich spezifizieren:
# ping6 -I eth0 -c 1 fe80::2e0:18ff:fe90:9205
PING fe80::212:23ff:fe12:3456(fe80::212:23ff:fe12:3456) from
¬ fe80::212:34ff:fe12:3478 eth0: 56 data bytes
64 bytes from fe80::212:23ff:fe12:3456: icmp_seq=0 hops=64 time=445 usec
--- fe80::2e0:18ff:fe90:9205 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss round-trip
¬ min/avg/max/mdev = 0.445/0.445/0.445/0.000 ms
Beispiel für %<device> Notation:
# ping6 -c 1 fe80::2e0:18ff:fe90:9205%eth0
Ping6 zu Multicast-Adressen
Ein interessanter Mechanismus zum Aufspüren eines IPv6 aktiven Hosts am Link ist mit ping6 an eine link-lokale all-node Multicast Adresse zu pingen.
# ping6 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80:::2ab:cdff:feef:0123 eth0: 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.104 ms
64 bytes from fe80::212:34ff:fe12:3450: icmp_seq=1 ttl=64 time=0.549 ms (DUP!)
Beispiel für %<device> Notation:
# ping6 ff02::1%eth0
Bei IPv6 kann dieses Verhalten zurzeit, im Gegensatz zu IPv4, wo Antworten auf ein Ping auf die Broadcast Adresse unterdrückt werden können, nicht unterbunden werden. Ausnahme hierbei ist der Einsatz der lokalen IPv6 Firewall-Funktionalität.
IPv6 traceroute6
Dieses Programm ist normal im Paket iputils enthalten. Es ist ein Programm vergleichbar dem IPv4 traceroute. Unten sehen Sie ein Beispiel:
# traceroute6 www.6bone.net
traceroute to 6bone.net (3ffe:b00:c18:1::10) from 2001:0db8:0000:f101::2, 30
¬ hops max, 16 byte packets
1 localipv6gateway (2001:0db8:0000:f101::1) 1.354 ms 1.566 ms 0.407 ms
2 swi6T1-T0.ipv6.switch.ch (3ffe:2000:0:400::1) 90.431 ms 91.956 ms 92.377 ms
3 3ffe:2000:0:1::132 (3ffe:2000:0:1::132) 118.945 ms 107.982 ms 114.557 ms
4 3ffe:c00:8023:2b::2 (3ffe:c00:8023:2b::2) 968.468 ms 993.392 ms 973.441 ms
5 3ffe:2e00:e:c::3 (3ffe:2e00:e:c::3) 507.784 ms 505.549 ms 508.928 ms
6 www.6bone.net (3ffe:b00:c18:1::10) 1265.85 ms * 1304.74 ms
Anmerkung: Im Unterschied zu modernen IPv4 traceroute Versionen, welche den Einsatz von ICMPv4-echo-request Paketen wie auch UDP Paketen (default) ermöglichen, können mit IPv6-traceroute nur UDP Pakete versendet werden. Wie Sie vielleicht bereits wissen, werden von Firewalls bzw. von ACLs auf Routern ICMP echo-request Pakete mehr akzeptiert als UDP Pakete.
Falls ein Interface spezifiziert werden muß, kann dies durch -i <device> oder in der Form <address>%<device> erfolgen.
IPv6 tracepath6
Dieses Programm ist normalerweise im Paket iputils enthalten. Das Programm ist dem traceroute6 ähnlich, es gibt den Weg zu einem angegebenen Ziel wieder und misst hierbei den MTU-Wert. Unten sehen Sie ein Beispiel:
In Linux ist tcpdump ein Haupttool zum aufzeichnen von Paketen. Weiter unten sehen Sie einige Beispiele. Normalerweise ist die Ipv6-Unterstützung in der aktuellen Version 3.6 gegeben.
Bei tcpdump werden zur Geräuschminimierung bei der Paket-Filterung Ausdrücke eingesetzt:* icmp6: ICMPv6 Datenverkehr wird gefiltert
ip6: IPv6 Datenverkehr (inkl.ICMPv6) wird gefiltert
proto ipv6: getunnelter IPv6-in-IPv4 Datenverkehr wird gefiltert
not port ssh: zum unterdrücken der Anzeige von SSH Paketen während der Ausführung von tcpdump bei einer remote SSH-Sitzung
Ebenfalls sind einige Kommandozeilen-Optionen sehr hilfreich, um detailliertere Informationen über die Pakete erlangen und protokollieren zu können. Für ICMPv6 Pakete sind hauptsächlich interessant:* “-s 512”: Bei der Aufzeichnung der Pakete wird die zu Aufzeichnungslänge auf 512 bytes vergrößert
“-vv”: wirklich sehr ausführliche Ausgabe
“-n”: Adressen werden nicht in Namen aufgelöst. Dies ist hilfreich, wenn die Reverse-DNS-Auflösung nicht sauber arbeiten sollte
IPv6 ping zur Adresse 2001:0db8:100:f101::1 über einen lokalen Link
IPv6 ping zur Adresse 2001:0db8:100::1 über einen IPv6-in-IPv4 Tunnel geroutet
1.2.3.4. und 5.6.7.8. sind Tunnel-Endpunkte (alle Adressen sind Beispiele)
# tcpdump -t -n -i ppp0 -s 512 -vv ip6 or proto ipv6
tcpdump: listening on ppp0
1.2.3.4 > 5.6.7.8: 2002:ffff:f5f8::1 > 2001:0db8:100::1: icmp6: echo request
¬ (len 64, hlim 64) (DF) (ttl 64, id 0, len 124)
5.6.7.8 > 1.2.3.4: 2001:0db8:100::1 > 2002:ffff:f5f8::1: icmp6: echo reply (len
¬ 64, hlim 61) (ttl 23, id 29887, len 124)
1.2.3.4 > 5.6.7.8: 2002:ffff:f5f8::1 > 2001:0db8:100::1: icmp6: echo request
¬ (len 64, hlim 64) (DF) (ttl 64, id 0, len 124)
5.6.7.8 > 1.2.3.4: 2001:0db8:100::1 > 2002:ffff:f5f8::1: icmp6: echo reply (len
¬ 64, hlim 61) (ttl 23, id 29919, len 124)
Wireshark
Protocol dependencies
Ethernet: Typically, IPv6 uses Ethernet as its transport protocol.
IPv6 can be transported over a wide variety of other protocols as well.
Example traffic
XXX - Add example traffic here (as plain text or Wireshark screenshot).
Wireshark
The IPv6 dissector is (fully functional, partially functional, not existing, ... whatever the current state is). Also add info of additional Wireshark features where appropriate, like special statistics of this protocol.
Preference Settings
(XXX add links to preference settings affecting how IPv6 is dissected).
Example capture file
XXX - Add a simple example capture file to the SampleCaptures page and link from here. Keep it short, it's also a good idea to gzip it to make it even smaller, as Wireshark can open gzipped files automatically.
Display Filter
A complete list of IPv6 display filter fields can be found in the display filter reference * Show only the IPv6 based traffic: ipv6
Filter for specific IPv6 address(es): ipv6.addr eq fe80::f61f:c2ff:fe58:7dcb or ipv6.addr eq ff02::1
Capture Filter
Capture IPv6 based traffic only: ip6 Capture only the IPv6 based traffic to or from host fe80::1: host fe80::1 Capture IPv6-over-IPv4 tunneled traffic only: ip proto 41 Capture native IPv6 traffic only: ip6 and not ip proto 41
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.
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 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.
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, 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.
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.
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; so kann etwa die bei einigen Implementierungen bestehende Funktion von NAT, neu eingehende Verbindungen nicht an Rechner des Heimnetzes weiterzuleiten, durch einen zustandsbehafteten 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.
Betriebssysteme
Viele Betriebssysteme unterstützen inzwischen IPv6.
Entscheidend für eine tunnelfreie Anbindung ist 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. 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.
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, iPod Touch, Apple TV)
Apple-Geräte mit iOS ab Version 4 unterstützen IPv6 im Dual-Stack-Modus. Privacy Extensions werden jedoch erst ab Version 4.3 unterstützt.
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 produktiv einsatzbare IPv6-Unterstützung auf ähnlichem Niveau wie die BSD-Derivate.
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 4941) fehlen.
Die meisten Linux-Distributionen haben im Auslieferungszustand mit Kerneln ab Version 3.x die Privacy Extensions eingeschaltet, diese können jedoch manuell deaktiviert werden.
Eine 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.
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.
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. Bekommt Windows XP hingegen einen 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 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 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.
Windows Mobile
Windows Mobile 6.5 unterstützt IPv6.
Windows Phone
Windows Phone 7 und 7.5 unterstützen IPv6 nicht. Erst ab Version 8 ist ein IPv6-Stack integriert.
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.
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.
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 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.
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 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.
Datenschutz
Datenschützer bemängeln an IPv6, dass hier jedes mit dem Internet verbundene Gerät eine fixe IP-Adresse bekommen könnte, wodurch alle besuchten Seiten noch Jahre später eruiert und der Besucher identifiziert werden könnte.
Um dieses Problem zu umgehen, wollen Datenschützer Internet Service Provider per Gesetz dazu verpflichten, auch unter IPv6 dynamische Adressen anzubieten.
Übergangsmechanismen
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.
Mangelnde Unterstützung
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.
Datei:Form6.pngEs 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.
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
Dual-Stack Lite
Wie Dual-Stack, jedoch mit globaler IPv6 und Carrier-NAT IPv4
6rd
IPv6 rapid deployment
ISATAP
Intra-Site Automatic Tunnel Addressing Protocol
Teredo
Kapselung von IPv6-Datenpaketen in IPv4-UDP-Datenpaketen
NAT64
Übersetzung von IPv4-Adressen in IPv6-Adressen
464XLAT
Übersetzung von IPv4- in IPv6- in IPv4-Adressen
SIIT
Stateless IP/ICMP Translation
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.
Aufgrund der knappen IPv4-Adressen hat die IETF den Mechanismus „Dual-Stack Lite“ (RFC 6333) entwickelt.
Hierbei werden dem Kunden nur via IPv6 global routbare IP-Adressen bereitgestellt. (Im regulären Dual-Stack-Betrieb werden sowohl IPv6 als auch IPv4 zur Verfügung gestellt.)
Im LAN des Kunden werden private IPv4-Adressen benutzt (analog zum Vorgehen bei NAT). Statt einer NAT-Übersetzung werden die IPv4-Pakete dann durch das Customer Premises Equipment (CPE) in IPv6-Pakete gekapselt.
Das CPE benutzt seine globale IPv6-Verbindung, um die Pakete in das Carrier-grade NAT des Internet Service Providers zu transportieren, welches über globale IPv4-Adressen verfügt.
Hier wird das IPv6-Paket entpackt und das originale IPv4-Paket wiederhergestellt. Danach wird das IPv4-Paket mit NAT auf eine öffentliche IP-Adresse umgesetzt und ins öffentliche IPv4-Internet geroutet.
Das Carrier-grade NAT identifiziert Sitzungen eindeutig mittels Aufzeichnungen über die öffentliche IPv6-Adresse des CPE, die private IPv4-Adresse und TCP- oder UDP-Portnummern.
Diese DS-Lite-Umsetzung führt allerdings beim Endkunden zu Problemen: * Zum einen sind bei portbasierten Protokollen (z.B. TCP, UDP) keine IPv4-basierenden Portfreigaben mehr möglich, da die Pakete an die öffentliche IP-Adresse bereits beim Provider ausgefiltert werden.
Dienste, die an einem DS-Lite-Anschluss angeboten werden, können also von Geräten, die keine IPv6-Verbindungen aufbauen können, nicht erreicht werden.
Auch werden vom CGN-Gateway nur bestimmte Protokolle verstanden und weitergeleitet, was die Nutzung anderer IP-basierter Protokolle erschwert oder völlig unmöglich macht.
Protokoll 41: IPv6-Pakete werden direkt in IPv4-Pakete gepackt, die dann zu einem speziellen Tunnelserver geschickt werden
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 herausgelöst und zum Ziel via IPv6-Routing übertragen. Der Rückweg funktioniert analog. Jedes Tunnelverfahren ist abhängig von der 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. 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.
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) 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.
Das Verfahren NAT64 bietet eine recht befriedigende Lösung, solange die Hauptanforderung darin besteht, von IPv6-Hosts initiierte Verbindungen an IPv4-Hosts weiterzuleiten.
Literatur
Spezifikationen
RFC 2460, Internet Protocol, Version 6 (IPv6) Specification
RFC 4861, Neighbor Discovery for IP version 6 (IPv6)
Netsh-Befehle für Schnittstellen-IPv6https://msdn.microsoft.com/de-de/library/cc740203
IPv6
Betrifft: Windows Server 2008
Syntax von IPv6-Adressen
IPv4-Adressen werden in Dezimalschreibweise mit Punkten angegeben. Diese 32-Bit-Adressen sind in 8-Bit-Blöcke unterteilt. Jeder dieser 8-Bit-Blöcke wird in die entsprechende Dezimalzahl konvertiert und durch Punkte von den anderen Blöcken getrennt. Bei IPv6 handelt es sich um 128-Bit-Adressen, die in 16-Bit-Blöcke unterteilt sind. Jeder 16-Bit-Block wird in eine 4-stellige Hexadezimalzahl konvertiert und durch Doppelpunkte von den anderen Blöcken getrennt. Die resultierende Schreibweise wird als Doppelpunkt-Hexadezimal-Notation bezeichnet.
Nachfolgend sehen Sie eine IPv6-Adresse im Binärformat:
Jeder 16-Bit-Block wird in eine Hexadezimalzahl konvertiert und durch Doppelpunkte von den anderen Blöcken getrennt. Das Ergebnis sieht wie folgt aus:
21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A
Die IPv6-Notation kann durch Entfernen der führenden Nullen in jedem 16-Bit-Block weiter vereinfacht werden. Jeder Block muss jedoch mindestens eine Stelle aufweisen. Nach Entfernung der führenden Nullen sieht die Adresse wie folgt aus:
21DA:D3:0:2F3B:2AA:FF:FE28:9C5A
Komprimierung von Nullen
Manche Adresstypen enthalten lange Reihen von Nullen. Zur weiteren Vereinfachung der Schreibweise von IPv6-Adressen kann eine zusammenhängende Reihe von 16-Bit-Blöcken, die auf 0 festgelegt sind, im Doppelpunkt-Hexadezimal-Format zu einem doppelten Doppelpunkt (::) komprimiert werden.
Die verbindungslokale Adresse FE80:0:0:0:2AA:FF:FE9A:4CA2 kann beispielsweise zu FE80::2AA:FF:FE9A:4CA2 komprimiert werden. Die Multicastadresse FF02:0:0:0:0:0:0:2 kann zu FF02::2 komprimiert werden.
Die Komprimierung von Nullen kann auch verwendet werden, um nur einen einzelnen 16-Bit-Block in Doppelpunkt-Hexadezimal-Notation zu komprimieren. Sie können die Komprimierung von Nullen jedoch nicht verwenden, um einen Teil eines 16-Bit-Blocks mit zu komprimieren. Es ist beispielsweise nicht möglich FF02:30:0:0:0:0:0:5 als FF02:3::5 auszudrücken.
Wenn Sie feststellen möchten, wie viele 0-Bits durch den doppelten Doppelpunkt dargestellt werden, können Sie die Anzahl der Blöcke in der komprimierten Adresse zählen, diese Zahl von 8 subtrahieren und dann das Ergebnis mit 16 multiplizieren. Die Adresse FF02::2 beispielsweise enthält zwei Blöcke (den Block "FF02" und den Block "2"). Die Anzahl der 0-Bits, die durch den doppelten Doppelpunkt dargestellt werden, ist 96 (96 = (8 – 2)×16).
Die Komprimierung von Nullen kann in einer Adresse nur einmal verwendet werden. Andernfalls könnten Sie hinterher nicht mehr feststellen, wie viele 0-Bits durch den doppelten Doppelpunkt dargestellt werden.
IPv6-Präfixe
Das Präfix ist jener Teil der Adresse, der angibt, welche Bits feste Werte aufweisen oder die Subnetzkennung darstellen. Präfixe für IPv6-Subnetzkennungen und -Routen werden auf dieselbe Weise angegeben wie bei der CIDR-Notation (Classless Inter-Domain Routing) für IPv4, und zwar in der Adressen/Präfixlängennotation. Beispielsweise stellt 21DA:D3::/48 ein Routenpräfix und 21DA:D3:0:2F3B::/64 ein Subnetzpräfix dar.
IPv4-Implementierungen geben das Netzwerkpräfix häufig in Dezimalschreibweise mit Punkten an, als so genannte Subnetzmaske. IPv6 unterstützt keine Subnetzmasken. IPv6 unterstützt nur die Präfixlängennotation.
Typen von IPv6-Adressen
IPv6 unterstützt drei Adresstypen:* Unicast Eine Unicastadresse identifiziert eine einzelne Schnittstelle innerhalb des Bereichs des Unicastadresstyps. Über eine geeignete Unicastroutingtopologie werden Pakete, die an Unicastadressen gerichtet sind, an eine einzelne Schnittstelle übermittelt. Zur Unterstützung von Lastenausgleichssystemen ermöglicht RFC 3513, dass mehrere Schnittstellen dieselbe Adresse verwenden, so lange sie für die IPv6-Implementierung auf dem Host als einzelne Schnittstellen erkennbar sind.
Multicast Eine Multicastadresse identifiziert mehrere Schnittstellen. Über eine geeignete Multicastroutingtopologie werden Pakete, die an eine Multicastadresse gerichtet sind, an alle Schnittstellen übermittelt, die durch die Adresse identifiziert werden. Eine Multicastadresse wird für die 1:n-Kommunikation verwendet, bei der Pakete von einer Schnittstelle an mehrere andere Schnittstellen übermittelt werden.
Anycast Eine Anycastadresse identifiziert mehrere Schnittstellen. Über eine geeignete Routingtopologie werden Pakete, die an eine Anycastadresse gerichtet sind, an eine einzelne Schnittstelle übermittelt. Hierbei handelt es sich um die nächstgelegene Schnittstelle, die durch die Adresse identifiziert wird. Die nächstgelegene Schnittstelle ist jene Schnittstelle, die den kürzesten Routingabstand von der Quelle aufweist. Eine Anycastadresse wird für die Übermittlung eines Pakets von einer Schnittstelle an eine von mehreren Schnittstellen verwendet.
IPv6-Adressen identifizieren stets Schnittstellen, aber keine Knoten. Ein Knoten wird durch eine Unicastadresse identifiziert, die einer seiner Schnittstellen zugewiesen ist.
In RFC 3513 wird keine Broadcastadresse definiert. Alle Typen der IPv4-Broadcastadressierung werden in IPv6 mithilfe von Multicastadressen vorgenommen. Beispielsweise werden Subnetzadressen und eingeschränkte Broadcastadressen aus IPv4 durch die verbindungslokale Multicastadresse für alle Knoten FF02::1 ersetzt.
IPv6-Unicastadressen
IPv6-Unicastadressen werden in fünf Typen unterteilt:* Globale Unicastadressen
Verbindungslokale Adressen
Standortlokale Adressen
Spezielle Adressen
Kompatibilitätsadressen
Globale Unicastadressen
Globale Unicastadressen entsprechen öffentlichen IPv4-Adressen. Sie sind im IPv6-Internet global routbar und erreichbar.
Im Gegensatz zum aktuellen IPv4-basierten Internet, das eine Mischung aus flachem und hierarchischem Routing darstellt, wurde das IPv6-basierte Internet von Grund auf für die Unterstützung einer effizienten, hierarchischen Adressierung und eines entsprechenden Routings entwickelt. Der Bereich einer globalen Unicastadresse (die Region des IPv6-Netzwerks, in dem die Adresse eindeutig ist) umfasst das gesamte IPv6-Internet.
Die folgende Abbildung zeigt die Struktur einer globalen Unicastadresse gemäß Definition in RFC 3587.
Globale Unicastadressen umfassen vier Felder.* Die drei höherwertigen Bits werden auf 001 festgelegt. Das Adresspräfix für aktuell zugewiesene globale Adressen ist 2000::/3.
Das globale Routingpräfix gibt das globale Routingpräfix für den Standort eines bestimmten Unternehmens an. Die Kombination der drei festgelegten Bits mit dem 45-Bit globalen Routingpräfix ergibt ein 48-Bit-Standortpräfix, das einem einzelnen Standort eines Unternehmens zugewiesen wird. Nachdem dieses Präfix zugewiesen wurde, leiten die Router im IPv6-Internet den IPv6-Datenverkehr, der dem 48-Bit-Präfix entspricht, an die Router des Unternehmensstandorts weiter.
Die Subnetzkennung wird innerhalb des Unternehmensstandorts verwendet, um Subnetze zu identifizieren. Dieses Feld ist 16 Bits lang. Website des Unternehmens kann diese 16 Bits innerhalb des Standorts verwenden, um 65.536 Subnetzen oder mehreren Ebenen Adressierung Hierarchie und eine effiziente Routinginfrastruktur erstellen.
Die Schnittstellen-ID gibt die Schnittstelle in einem bestimmten Subnetz des Standorts an. Dieses Feld ist 64 Bits lang.
Die folgende Abbildung zeigt, wie die Felder innerhalb der globalen Unicastadresse eine dreistufige Struktur bilden.
Die dreistufige Struktur der globalen Unicastadresse
Die öffentliche Topologie umfasst größere und kleinere ISPs, die Zugriff auf das IPv6-Internet bereitstellen. Die Standorttopologie umfasst die Subnetze innerhalb des Standorts eines Unternehmens. Die Schnittstellenkennung identifiziert eine bestimmte Schnittstelle in einem Subnetz innerhalb eines Unternehmensstandorts. Weitere Informationen zu globalen Unicastadressen finden Sie unter RFC 3587 in der IETF RFC-Datenbank (möglicherweise in englischer Sprache).
Unicastadressen für die lokale Nutzung
Die Unicastadressen für die lokale Nutzung werden in zwei Typen unterteilt:* Verbindungslokale Adressen werden zwischen Nachbarn auf Verbindungen und für die Nachbarsuche verwendet.
Standortlokale Adressen werden zwischen Knoten am selben Standort verwendet.
Verbindungslokale Adressen
Knoten verwenden verbindungslokale Adressen für die Kommunikation mit benachbarten Knoten auf derselben Verbindung. In einem IPv6-Netzwerk mit nur einer Verbindung verwenden Hosts beispielsweise verbindungslokale Adressen, um mit anderen Hosts auf der Verbindung zu kommunizieren. Verbindungslokale Adressen entsprechen APIPA-IPv4-Adressen (Automatic Private IP Addressing, automatische Zuweisung von privaten IP-Adressen), die auf Computern unter Windows automatisch konfiguriert werden. APIPA-Adressen verwenden das Präfix 169.254.0.0/16. Der Bereich einer verbindungslokalen Adresse ist die lokale Verbindung.
Eine verbindungslokale Adresse wird für Nachbarsuchen benötigt und immer automatisch konfiguriert, selbst wenn alle anderen Unicastadressen nicht vorhanden sind.
Die folgende Abbildung zeigt die Struktur der verbindungslokalen Adresse.
Verbindungslokale Adressen beginnen stets mit FE80. Bei 64-Bit-Schnittstellenkennungen lautet das Präfix für verbindungslokale Adressen stets FE80::/64. Ein IPv6-Router leitet verbindungslokalen Datenverkehr niemals jenseits der Verbindung weiter.
Standortlokale Adressen
Standortlokale Adressen entsprechen dem privaten IPv4-Adressbereich (10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16). Beispielsweise können private Intranets, die über keine direkte, geroutete Verbindung zum IPv6-Internet verfügen, standortlokale Adressen verwenden, ohne Konflikte mit globalen Adressen zu verursachen. Standortlokale Adressen können nicht von anderen Standorten aus erreicht werden, und die Router dürfen keinen standortlokalen Datenverkehr an eine Stelle außerhalb des Standorts weiterleiten. Standortlokale Adressen können zusätzlich zu globalen Adressen verwendet werden. Der Bereich einer standortlokalen Adresse ist der Standort.
Im Gegensatz zu verbindungslokalen Adressen werden standortlokale Adressen nicht automatisch konfiguriert und müssen entweder über eine statusfreie oder über eine statusbehaftete Adresskonfiguration zugewiesen werden.
Die folgende Abbildung zeigt die Struktur der standortlokalen Adresse.
Die ersten 10 Bits werden stets für standortlokale Adressen festgelegt, beginnend bei FEC0::/10. Auf die 10 festen Bits folgt eine 54-Bit-Subnetzkennung (Feld Subnetz-ID). Mit diesen 54-Bits können Sie innerhalb des Standorts eine hierarchische und zusammenfassbare Routinginfrastruktur erstellen. Auf das Feld Subnetz-ID folgt ein 64-Bit-Schnittstellenkennungsfeld, das eine bestimmte Schnittstelle in einem Subnetz identifiziert.
In RFC 3879 wird die Verwendung von standortlokalen Adressen für künftige IPv6-Implementierungen ausdrücklich abgelehnt. Bestehende Implementierungen von IPv6 können weiterhin standortlokale Adressen verwenden, bis ein Ersatzstandard definiert wurde. Mittlerweile wurde eine neue Version des IPv6-Adressierungsarchitekturstandards als Internetentwurf veröffentlicht (draft-ietf-ipv6-addr-arch-v4-0x.txt). Darin wird die Ablehnung standortlokaler Adressen festgelegt. Dieser neue Internetentwurf des Standards für die IPv6-Adressierung soll RFC 3513 ersetzen.
Spezielle IPv6-Adressen
Es gibt die folgenden speziellen IPv6-Adressen:* Unspezifizierte Adresse Die unspezifizierte Adresse (0:0:0:0:0:0:0:0 oder ::) weist darauf hin, dass keine Adresse vorhanden ist. Sie entspricht der unspezifizierten Adresse von IPv4, 0.0.0.0. Die unspezifizierte Adresse wird in der Regel als Quelladresse für Pakete verwendet, um die Eindeutigkeit einer Adresse mit Vorbehalt zu überprüfen. Die unspezifizierte Adresse wird nie einer Schnittstelle zugewiesen oder als Zieladresse verwendet.
Loopbackadresse Die Loopbackadresse (0:0:0:0:0:0:0:1 oder ::1) wird zur Identifizierung einer Loopbackschnittstelle verwendet, die es ermöglicht, dass ein Knoten Pakete an sich selbst sendet. Sie entspricht der Loopbackadresse von IPv4, 127.0.0.1. Pakete, die an die Loopbackadresse gerichtet sind, dürfen nicht über eine Verbindung gesendet oder von einem Router weitergeleitet werden.
Kompatibilitätsadressen
Die folgenden Adressen wurden definiert, um die Migration von IPv4 zu IPv6 und den parallelen Einsatz von beiden Typen von Hosts zu erleichtern:* IPv4-kompatible Adresse Die IPv4-kompatible Adresse, 0:0:0:0:0:0:w.x.y.z oder ::w.x.y.z (hierbei ist w.x.y.z eine öffentliche IPv4-Adresse in Dezimalschreibweise mit Punkten), wird von IPv6/IPv4-Knoten verwendet, die über IPv6 miteinander kommunizieren. IPv6/IPv4-Knoten unterstützen IPv4- und IPv6-Protokolle. Wenn eine IPv4-kompatible Adresse als IPv6-Ziel verwendet wird, wird der IPv6-Datenverkehr automatisch mit einem IPv4-Header gekapselt und über die IPv4-Infrastruktur an das Ziel gesendet.
IPv4-zugeordnete Adresse Die IPv4-zugeordnete Adresse, 0:0:0:0:0:FFFF:w.x.y.z oder ::FFFF:w.x.y.z, wird zur Darstellung eines reinen IPv4-Knotens als IPv6-Knoten verwendet. Sie wird nur für die interne Darstellung verwendet. Die IPv4-zugeordnete Adresse wird nie als Quell- oder Zieladresse für ein IPv6-Paket verwendet.
IPv6-zu-IPv4-Adresse Die IPv6-zu-IPv4-Adresse wird zur Kommunikation zwischen zwei Knoten verwendet, auf denen IPv4 und IPv6 über eine IPv4-Routinginfrastruktur eingesetzt werden. Die IPv6-zu-IPv4-Adresse wird durch Kombination des Präfix 2002::/16 mit den 32 Bits einer öffentlichen IPv4-Adresse des Knotens gebildet, wodurch ein 48-Bit Präfix entsteht. IPv6-zu-IPv4 ist eine Tunneltechnologie, die in RFC 3056 beschrieben wird.
ISATAP-Adressen Im Internetentwurf "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)" werden ISATAP-Adressen definiert, die zwischen zwei Knoten verwendet werden, auf denen IPv4 und IPv6 über eine IPv4-Routinginfrastruktur eingesetzt werden. ISATAP-Adressen verwenden die lokal verwaltete Schnittstellen-ID ::0:5EFE:w.x.y.z. Hierbei ist w.x.y.z eine IPv4-Unicastadresse, die sowohl öffentliche als auch private Adressen umfasst.Die ISATAP-Schnittstellen-ID kann mit jedem 64-Bit-Präfix kombiniert werden, das für IPv6-Unicastadressen zulässig ist. Hierzu gehören das verbindungslokale Adresspräfix (FE80::/64), standortlokale Präfixe sowie globale Präfixe.
Teredo-Adresse Teredo-Adressen verwenden das Präfix 3FFE:831F::/32. Jenseits der ersten 32 Bits werden Teredo-Adressen zur Codierung der IPv4-Adresse eines Teredo-Servers, für Kennzeichner und für die codierte Version der externen Adresse und des Ports eines Teredo-Clients verwendet. Ein Beispiel für eine Teredo-Adresse ist 3FFE:831F:CE49:7601:8000:EFFF:62C3:FFFE. Teredo Adressen werden verwendet, um einen Host darzustellen bei Verwendung des automatischen Tunneling-Mechanismus im Internetentwurf definierten “ Teredo: Tunneling IPv6 über UDP über NAT-Geräte. ”
IPv6-Multicastadressen
Bei IPv6 verhält sich der Multicastdatenverkehr auf dieselbe Weise wie bei IPv4. IPv6-Knoten mit beliebigem Standort können den Multicastdatenverkehr auf beliebigen IPv6-Multicastadressen überwachen. IPv6-Knoten können mehrere Multicastadressen gleichzeitig überwachen. Außerdem können die Knoten jederzeit einer Multicastgruppe beitreten oder diese verlassen.
Die ersten 8 Bits von IPv6-Multicastadressen sind auf 1111 1111 festgelegt. Eine IPv6-Adresse kann leicht als Multicastadresse klassifiziert werden, da diese stets mit "FF" beginnt. Multicastadressen können in einem Routingheader nicht als Quelladressen oder Zwischenziele verwendet werden.
Jenseits der ersten 8 Bits enthalten Multicastadressen zusätzliche Strukturen zur Identifizierung der Kennzeichner, des Bereichs und der Multicastgruppe. Die folgende Abbildung zeigt die Struktur der IPv6-Multicastadresse.
Die Multicastadresse enthält die folgenden Felder:* Kennzeichner Gibt Kennzeichner an, die für die Multicastadresse festgelegt sind. Die Größe dieses Felds ist 4 Bits. Gemäß RFC 3513 lautet der einzige definierte Kennzeichner Transient (T) (Vorübergehend). Der Kennzeichner T verwendet das niederwertige Bit des Felds Kennzeichner. Bei Festlegung auf 0 gibt der Kennzeichner T an, dass die Multicastadresse eine bekannte Multicastadresse ist, die von der Internet Assigned Numbers Authority (IANA) dauerhaft zugewiesen wurde. Bei Festlegung auf 1 gibt der Kennzeichner T an, dass die Multicastadresse eine vorübergehende Multicastadresse ist, die von der IANA nicht dauerhaft zugewiesen wurde.
Bereich Gibt den Bereich des IPv6-Netzwerks an, für den der Multicastdatenverkehr gedacht ist. Die Größe dieses Felds ist 4 Bits. Zusätzlich zu den Informationen, die durch die Multicastroutingprotokolle bereitgestellt werden, verwenden Router den Multicastbereich, um zu ermitteln, ob sie Multicastdatenverkehr weiterleiten können. Die am meisten verwendeten Werte für das Feld Bereich sind 1 (schnittstellenlokaler Bereich), 2 (verbindungslokaler Bereich) und 5 (standortlokaler Bereich).Datenverkehr mit der Multicastadresse FF02::2 weist beispielsweise einen verbindungslokalen Bereich auf. Ein IPv6-Router leitet diesen Datenverkehr nie jenseits der lokalen Verbindung weiter.
Gruppen-ID Identifiziert die Multicastgruppe und ist innerhalb des Bereichs eindeutig. Die Größe dieses Felds ist 112 Bits. Dauerhaft zugewiesene Gruppen-Ds sind bereichsunabhängig. Vorübergehende Gruppen-IDs sind nur für einen bestimmten Bereich relevant. Multicastadressen von FF01:: über FF0F:: sind reservierte, bekannte Adressen.
Die folgenden Adressen wurden definiert, um alle Knoten für den schnittstellenlokalen und den verbindungslokalen Bereich zu identifizieren:* FF01::1 (Multicastadresse für alle Knoten im schnittstellenlokalen Bereich)
FF02::1 (Multicastadresse für alle Knoten im verbindungslokalen Bereich)
Die folgenden Adressen wurden definiert, um alle Router für den schnittstellenlokalen, den verbindungslokalen und den standortlokalen Bereich zu identifizieren:* FF01::2 (Multicastadresse für alle Router im schnittstellenlokalen Bereich)
FF02::2 (Multicastadresse für alle Router im verbindungslokalen Bereich)
FF05::2 (Multicastadresse für alle Router im standortlokalen Bereich)
Mit 112 Bits für die GRUPPENKENNUNG ist es möglich, 2112 Gruppe IDs. Aufgrund der Art und Weise, wie IPv6-Multicastadressen den Ethernet-Multicast-MAC-Adressen (Media Access Control) zugeordnet werden, empfiehlt RFC 3513 jedoch eine Zuweisung der Gruppen-ID aus den niederwertigen 32 Bits der IPv6-Multicastadresse sowie die Festlegung der restlichen ursprünglichen Gruppen-ID-Bits auf 0. Durch Verwendung der niederwertigen 32 Bits wird jede Gruppen-ID einer eindeutigen Ethernet-Multicast-MAC-Adresse zugeordnet. Die folgende Abbildung zeigt die empfohlene IPv6-Multicastadresse.
Die empfohlene IPv6-Multicastadresse mit einer 32-Bit-Gruppen-ID
Die Anforderungsknotenadresse (Solicited-Node Address) ermöglicht eine effiziente Abfrage der Netzwerkknoten während der Adressauflösung. Bei IPv4 wird der ARP-Anforderungsrahmen an den MAC-Level-Broadcast gesendet. Dieser stört alle Knoten im Netzwerksegment, einschließlich der Knoten, auf denen IPv4 nicht eingesetzt wird. IPv6 verwendet die Nachbaraufforderungsnachricht, um die Adressauflösung durchzuführen. Statt jedoch als Ziel für die Nachbaraufforderungsnachricht die Multicastadresse für alle Knoten im verbindungslokalen Bereich zu verwenden, was alle IPv6-Knoten auf der lokalen Verbindung stören würde, wird die Anforderungsknoten-Multicastadresse verwendet. Die folgende Abbildung zeigt, wie die Anforderungsknoten-Multicastadresse aus dem Präfix FF02::1:FF00:0/104 und den letzten 24 Bits der aufzulösenden IPv6-Adresse gebildet wird.
Zuordnung von IPv6-Unicastadressen zu IPv6-Anforderungsknotenadresse
Für den Knoten mit der verbindungslokalen IPv6-Adresse FE80::2AA:FF:FE28:9C5A lautet die entsprechende Anforderungsknotenadresse FF02::1:FF28:9C5A. Dieser Knoten überwacht den Multicastdatenverkehr an der Anforderungsknotenadresse FF02::1:FF28:9C5A. Für Schnittstellen, die zu einer physischen Netzwerkkarte gehören, ist die entsprechende Multicastadresse zudem bei der Netzwerkkarte registriert. Zur Auflösung der Adresse FE80::2AA:FF:FE28:9C5A in die zugehörige Sicherungsschichtadresse sendet ein benachbarter Knoten eine Nachbaraufforderungsnachricht an die Anforderungsknotenadresse FF02::1:FF28:9C5A.
Die Verwendung der Anforderungsknoten-Multicastadresse bewirkt, dass zur Adressauflösung, die einen häufigen Vorgang auf einer Verbindung darstellt, kein Mechanismus eingesetzt werden muss, der alle Netzwerkknoten stört. Durch Verwendung der Anforderungsknotenadresse werden bei der Adressauflösung nur wenige Knoten gestört. Aufgrund der Beziehung zwischen der Ethernet-MAC-Adresse, der IPv6-Schnittstellen-ID und der Anforderungsknotenadresse fungiert die Anforderungsknotenadresse in der Praxis als Pseudo-Unicastadresse für eine sehr effiziente Adressauflösung .
IPv6-Anycastadressen
Eine Anycastadresse wird mehreren Schnittstellen zugewiesen. Die Routinginfrastruktur leitet Pakete, die an eine Anycastadresse gerichtet sind, an die nächstgelegene Schnittstelle weiter, der die Anycastadresse zugewiesen ist. Zur Übermittlung der Pakete muss die Routinginfrastruktur die Schnittstellen, denen die Anycastadresse zugewiesen ist, sowie die Entfernung, ausgedrückt in Routingmetriken, ermitteln. Zurzeit werden Anycastadressen nur als Zieladressen verwendet und ausschließlich Routern zugewiesen. Anycastadressen werden aus dem Unicastadressbereich zugewiesen, und der Bereich einer Anycastadresse entspricht dem Bereich des Unicastadresstyps, aus dem diese zugewiesen wurde.
Die Subnetzrouter-Anycastadresse ist vordefiniert und erforderlich. Sie wird aus dem Subnetzpräfix für eine bestimmte Schnittstelle erstellt. Zur Bildung der Subnetzrouter-Anycastadresse werden die Bits im Subnetzpräfix auf die entsprechenden Wert festgelegt, und die restlichen Bits werden auf 0 festgelegt. Allen Routerschnittstellen, die mit einem Subnetz verbunden sind, wird die Subnetzrouter-Anycastadresse für dieses Subnetz zugewiesen. Die Subnetzrouter-Anycastadresse wird für die Kommunikation mit einem von mehreren Routern verwendet, die mit einem Remotesubnetz verbunden sind.
IPv6-Adressen für einen Host
Ein IPv4-Host mit einer einzelnen Netzwerkkarte verfügt in der Regel über eine IPv4-Adresse, die dieser Netzwerkkarte zugewiesen ist. Im Gegensatz dazu verfügt ein IPv6-Host meist über mehrere IPv6-Adressen, selbst wenn er nur eine Schnittstelle aufweist. Einem IPv6-Host werden die folgenden Unicastadressen zugewiesen:* Eine verbindungslokale Adresse für jede Schnittstelle
Unicastadressen für jede Schnittstelle (eine standortlokale Adresse und eine oder mehrere globale Unicastadressen)
Die Loopbackadresse (::1) für die Loopbackschnittstelle
Typische IPv6-Hosts sind mehrfach logisch vernetzt, da sie über mindestens zwei Adressen verfügen, auf denen Sie Pakete empfangen können – eine verbindungslokale Adresse für verbindungslokalen Datenverkehr und eine routbare standortlokale oder globale Adresse.
Darüber hinaus überwacht jeder Host den Datenverkehr für die folgenden Multicastadressen:* Die Multicastadresse für alle Knoten im schnittstellenlokalen Bereich (FF01::1)
Die Multicastadresse für alle Knoten im verbindungslokalen Bereich (FF02::1)
Die Anforderungsknotenadresse für jede Unicastadresse auf jeder Schnittstelle
Die Multicastadressen der Gruppen, denen der Host beigetreten ist, auf jeder Schnittstelle
IPv6-Adressen für einen Router
Einem IPv6-Router werden die folgenden Unicastadressen zugewiesen:* Eine verbindungslokale Adresse für jede Schnittstelle
Unicastadressen für jede Schnittstelle (eine standortlokale Adresse und eine oder mehrere globale Unicastadressen)
Eine Subnetzrouter-Anycastadresse
Zusätzliche Anycastadressen (optional)
Die Loopbackadresse (::1) für die Loopbackschnittstelle
Darüber hinaus überwacht jeder Router den Datenverkehr für die folgenden Multicastadressen:* Die Multicastadresse für alle Knoten im schnittstellenlokalen Bereich (FF01::1)
Die Multicastadresse für alle Router im schnittstellenlokalen Bereich (FF01::2)
Die Multicastadresse für alle Knoten im verbindungslokalen Bereich (FF02::1)
Die Multicastadresse für alle Router im verbindungslokalen Bereich (FF02::2)
Die Multicastadresse für alle Router im standortlokalen Bereich (FF05::2)
Die Anforderungsknotenadresse für jede Unicastadresse auf jeder Schnittstelle
Die Multicastadressen der Gruppen, denen der Host beigetreten ist, auf jeder Schnittstelle
