Wikipedia

IPv6

Internetprotokoll
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 23. April 2005 um 17:21 Uhr durch 80.81.18.229 (Diskussion) (→Unique Local Addresses: markup). Sie kann sich erheblich von der aktuellen Version unterscheiden.

IPv6, das Internet Protocol Version 6, ist der Nachfolger des gegenwärtig im Internet noch fast ausschließlich verwendeten Internet Protocol v4.

IPv6 im TCP/IP-Protokollstapel
Anwendung FTP SMTP HTTP … DNS …
Transport TCP UDP
Netzwerk IPv6
Netzzugang Ethernet Token
Bus 		Token
Ring 		FDDI …

Warum ein neues Internet-Protokoll?

Das alte IPv4 bietet einen Adressraum von etwas über 4 Milliarden IP-Adressen, mit denen Computer und andere Geräte angesprochen werden können. In den Anfangstagen des Internet, als es nur wenige Rechner gab, die eine IP-Adresse brauchten, galt dies als mehr als ausreichend. Kaum jemand konnte sich vorstellen, dass überhaupt jemals so viele Rechner zu einem einzigen Netzwerk zusammengeschlossen würden, dass es im vorgegebenen Adressraum eng werden könnte.

Viele der theoretisch 4 Milliarden IP-Adressen sind in der Praxis nicht nutzbar, da sie Sonderaufgaben dienen (zum Beispiel Multicast) oder zu großen Teilnetzen (Subnetzen) gehören: Den ersten großen Teilnehmern am Internet wurden riesige Adressbereiche (so genannte Class-A-Netze) mit je 16,8 Millionen Adressen zugeteilt, die diese Organisationen bis heute behalten haben, ohne sie jemals voll ausnutzen zu können. Die Amerikaner (und teilweise die Europäer) teilten die relativ wenigen großen Adressbereiche unter sich auf, während die Internet-Späteinsteiger wie Südamerika, aber vor allem Asien, zunächst außen vor blieben.

Als Resultat herrscht besonders im zukünftigen IT-Wachstumsmarkt Asien heute eine Adressenknappheit, der man mit Notbehelfen wie PAT (Port Address Translation = NAT Overloading), Lockerung der festen Netzklassen-Unterteilung durch CIDR (Classless Inter-Domain Routing) oder dynamischer Vergabe von Adressen begegnen muss.

Auf Grund des Wachstums und der Wichtigkeit des Internet konnte dies kein Dauerzustand bleiben. Auch ist abzusehen, dass in den nächsten Jahren durch neue technische Innovationen (beispielsweise Mobiltelefone mit Internet-Anschluss, bald wohl auch Autos und Elektrogeräte in Privathaushalten) der Bedarf an Adressen auch im Rest der Welt ansteigen wird.

Hauptsächlich wegen der Adressknappheit, aber auch, um einige der Probleme zu lösen, die sich im Zuge der großräumigen Verwendung von IPv4 gezeigt hatten, begann man 1995 mit den Arbeiten an IPv6 (die ersten RFCs entstanden 1983ff.). Die folgende Liste gibt einen Überblick über die wesentlichen neuen Eigenschaften von IPv6. Einige Punkte werden weiter unten näher erklärt:

  • Vergrößerung des Adressraums von 232 bei IPv4 auf 2128 bei IPv6
  • Autokonfiguration (ähnlich DHCP), Mobile IP und automatische Umnummerierung ("Renumbering")
  • Dienste wie IPSec, QoS und Multicast "serienmäßig"
  • Vereinfachung und Verbesserung der Protokollrahmen (Header). Dies ist insbesondere wichtig für Router.

Adressaufbau von IPv6

Eine IPv6-Adresse ist 128 Bit lang (IPv4: 32 Bit). Damit gibt es etwa 3,4 × 1038 IPv6-Adressen. Das bedeutet für jeden Quadratmillimeter (!) Erdoberfläche könnten ca. 665,570793 Billiarden Adressen (6,65570793 × 1017) bereitgestellt werden

IPv6-Adressen werden nicht mehr in dezimaler (zum Beispiel 80.130.234.185), sondern in hexadezimaler Notation mit Doppelpunkten geschrieben: 243f:6a88:85a3:08d3:1319:8a2e:0370:7344. Wenn eine 16-Bit-Gruppe den Wert 0000 hat, können die Ziffern weggelassen werden, so dass zwei Doppelpunkte aufeinander folgen. Wenn dann mehr als zwei Doppelpunkte aufeinander folgen, können diese auf zwei Doppelpunkte reduziert werden, solange es in der resultierenden Adresse nur einmal zwei aufeinander folgende Doppelpunkte gibt. 0588:2353::1428:57ab ist also das selbe wie 0588:2353:0000:0000:0000:0000:1428:57ab, aber 3906::25de::cade wäre nicht erlaubt, da zweimal zwei Doppelpunkte in der Zeichenkette vorkommen – ein Computer wüsste nicht, wo mit wie vielen Nullen aufzufüllen wäre.

Die ersten 64 Bit der IPv6-Adresse dienen üblicherweise der Netzadressierung, die letzten 64 Bit können zur Host-Adressierung verwendet werden – hiermit wird elegant das Konzept der Netzmasken von IPv4 implementiert. Bei Bedarf können auch andere Netzmasken eingesetzt werden.

Die korrekte Form einer IPv6-Adresse in einem URL ist http://[243f:6a88:85a3:08d3:1319:8a2e:0370:7344]/ .

Arten von IPv6-Adressen

Es gibt verschiedene IPv6-Adressen mit Sonderaufgaben und unterschiedlichen Eigenschaften. Diese werden durch die ersten Bits der Adresse (das "Präfix") signalisiert:

  • Das Präfix 00 steht für IPv4 und IPv4-über-IPv6-Kompatibilitätsadressen. Ein geeigneter Router kann diese Pakete zwischen IPv4 und IPv6 konvertieren und so die neue mit der alten Welt verbinden. Zwei weitere Adressen tragen ebenfalls dieses Präfix; ::0 ist die undefinierte Adresse, ähnlich der 0.0.0.0 in IPv4, und ::1 ist die Adresse des eigenen Standortes ("localhost", "Loopback Device").
  • Die Präfixe 2 oder 3 stehen für globale Unicast-Adressen, also eine routbare und weltweit einzigartige Adresse.
    • Eine Abart davon sind die 6Bone-Testadressen 3ffe, die einem Rechner gehören, der Teil des IPv6-Testnetzwerkes 6Bone ist (der 6Bone wird mittelfristig eingestellt werden).
    • 2001-Adressen werden an Provider vergeben, die diese dann wieder an ihre Kunden verteilen
    • 2002-Präfixe deuten auf Adressen des Tunnelmechanismus 6to4 hin.
  • fe80 bis febf sind so genannte linklokale Adressen (link local address), die von Routern nicht weitergeleitet werden dürfen und daher nur im gleichen Teilnetz erreichbar sind. Interessant werden sie bei der Autokonfiguration.
  • Adressen mit Präfixen fec0 bis feff sind die Nachfolger der privaten IP-Adressen (beispielsweise 192.168.x.x). Sie dürfen nur innerhalb der gleichen Organisation geroutet werden. Man nennt sie auch Site-local (standortlokal). Diese Adressen sind inzwischen abgelehnt (engl. deprecated) und werden aus zukünftigen Standards möglicherweise verschwinden.
  • Die Nachfolger der Site-localen Adressen werden wohl die Unique Local Addresses mit dem Präfix ffc, mehr dazu siehe unten.
  • Das Präfix ff steht für Multicast-Adressen. Dem Präfix folgen Angaben über den Gültigkeitsbereich des Pakets. Anstelle des x in der folgenden Aufstellung steht jeweils eine 0, wenn es sich um eine permanente Multicastgruppe handelt, und eine 1, wenn die Gruppe nur temporär besteht:
    • ffx1: knotenlokal, diese Pakete verlassen den Knoten nie.
    • ffx2: linklokal, werden von Routern grundsätzlich nie weitergeleitet und können deshalb das Teilnetz nicht verlassen.
    • ffx5: sitelokal, dürfen zwar geroutet werden, jedoch nicht von Border-Routern.
    • ffx8: organisationslokal, die Pakete dürfen auch von Border-Routern weitergeleitet werden, bleiben jedoch "in der Firma" (hierzu müssen seitens des Routing-Protokolls entsprechende Vorkehrungen getroffen werden).
    • ffxe: globaler Multicast, der überall hin geroutet werden darf.

Autokonfiguration

Ein IPv6-fähiges Interface kann aus seiner Layer 2-MAC-Adresse eine so genannte linklokale Adresse errechnen, mit der es sich auf die Suche nach den Routern in seinem Netzwerksegment machen kann. Der Router kann dem Gerät dann eine "Unicast"-Adresse aus seinem Adressbereich zuweisen, mit der das Gerät aufs Internet zugreifen kann. Der ganze Vorgang läuft ohne Benutzereingriff vollautomatisch ab und ist eine Verbesserung des IPv4-DHCP (er kommt ohne Server aus). Ein IPv6-fähiges Gerät ist so ohne weitere Einstellungen startklar, was besonders für unerfahrene Endnutzer oder stressgeplagte Administratoren ein großer Vorteil ist.

Wegen einer Verwechslung in RFC 2460 wird der Algorithmus, um EUI-64-Namen aus EUI-48-Namen zu berechnen, fälschlicherweise auf MAC-48-Namen angewandt. (Siehe auch: Diskussion darüber) Der EUI-64-Name wird bei der IPv6-Autokonfiguration wiederum modifiziert Teil der IPv6-Adresse.

Umnummerierung

Sobald man bei IPv4 genügend Rechner zu einem Teilnetz zusammengeschlossen hat, bekommt man Probleme, wenn sich an den Adressparametern dieses Netzes etwas ändert (zum Beispiel ein Providerwechsel). Jeder Rechner muss in diesem Fall manuell umkonfiguriert werden – wenn das Netz groß genug ist, eine zeitraubende, stupide und unpraktikable Arbeit. Deshalb hat man bei IPv4 häufig den Adressraum fragmentiert, d.h. ein Teil der IP-Adressen eines Subnetzes wurde anders geroutet als der Rest. Für die Router brachte dies eine vergrößerte Routing-Tabelle, da sie sich die Ausnahmen merken und beachten müssen, und damit Leistungsverlust. Bei IPv6 gibt es wegen des Autokonfigurationsmechanismus diese Probleme nicht. Der neue Adressbereich muss lediglich einmal neu am Router eingestellt werden, und schon haben alle Clients ihre neuen Adressen.

Mobile IPv6

Bei der Erweiterung zum IPv6-Standard namens Mobile IPv6 (RFC 3775) geht es darum, mit der gleichen IP-Adresse überall erreichbar zu sein, beispielsweise im heimischen Netzwerk und auf einer Konferenz. Normalerweise müssten dazu aufwändig Routing-Tabellen geändert werden. Mobile IPv6 benutzt stattdessen einen (das Mobilgerät stellvertretenden) Agenten-Rechner ("Home Agent", HA) in dessen Heimnetz. Eingehende Pakete werden durch diesen HA an die momentane Adresse ("Care-of-Adress", CoA) des Mobilgeräts getunnelt. Der HA bekommt die aktuelle CoA des Mobilgerätes durch "Binding Updates" mit, die das Gerät an den HA sendet, sobald es eine neue Adresse im besuchten Fremdnetz erhalten hat.

Unique Local Addresses

Für private Adressen gibt es die Unique Local Addresses (ULA). Dabei unterscheidet man zwischen lokal vergebenen ULA mit dem Präfix fc00 und von zugewiesen und damit sicher global eindeutigen ULA mit dem Präfix fc01. Auf dieses Präfix folgen dann 40 Bits, die als eindeutige Netz-ID fungieren. Diese Netz-ID ist bei den ULA mit dem Präfix fc00 nur möglichweise eindeutig, bei den global vergebenen ULA jedoch auf jeden Fall eindeutig. Eine Beispiel-ULA wäre also z.B. fc00:dead:cafe::a:b:c:d.

Der Grund für die Netz-ID liegt darin, dass möglicherweise private Adressen an die Öffentlichkeit gelangen. Da bei IPv4 die privaten Adressen immer die gleichen waren, waren so versehentliche Verbindungen zu den eigenen Hosts, und nicht zu den fremden Hosts, wie eigentlich gemeint, unvermeidbar ("mein" 192.168.0.1 ist ein anderer Rechner als 192.168.0.1 eines anderen privaten Netzes). Da mit IPv6 jetzt jedes private Netz eigene IP-Adressen besitzt, laufen solche versehentlich gesendeten Pakete ins Leere.

Effizienzsteigerungen und neues Header-Format

Im Gegensatz zu IPv4 hat der IP-Header bei IPv6 eine feste Länge. Router müssen überlange Pakete nicht mehr selbst fragmentieren, sondern fordern den Absender mit einer ICMP-Nachricht auf, kleinere Pakete zu schicken. Zudem werden keine Prüfsummen mehr über das IP-Paket berechnet, man nutzt nur noch die Fehlerkorrektur in den Schichten 2 und 4. Die meisten Felder im Header sind auf 64-Bit-Grenzen ausgerichtet, so dass der Speicherzugriff im Router nicht unnötig ausgebremst wird. Die Flags liegen jetzt in Zwischenheadern zwischen dem IP-Header und dem Layer-4-Header (TCP/UDP). Dadurch können sich Hochleistungsrouter auf ihre Kernaufgaben konzentrieren und müssen nicht mehr die Fehler anderer Schichten korrigieren. Kritiker werfen ein, dass diese Optimierungen anstatt einer Leistungsverbesserung eher den gegenteiligen Effekt auf die Router hätten, da IPv6-Pakete weniger High-Level-Informationen als IPv4-Pakete enthalten, die für die Router wichtig sein könnten.

IPv6 macht intensiv Gebrauch von Multicast, der von jedem Host beherrscht werden muss. Das ARP-Protokoll wurde beispielsweise durch das neue Verfahren "Neighbor Solicitation" ergänzt: Die MAC-Adresse eines Hosts lässt sich nun auch über eine aus seiner IP gebildeten Multicastgruppe herausfinden. Als Nebeneffekt werden diese Anfragen nicht mehr wie Broadcasts im ganzen LAN verteilt, sondern gehen in Umgebungen mit Netzwerk-Switch idealerweise nur noch über den direkten Weg zum eigentlichen Ziel.

Probleme

Gerade zu Anfang litt IPv6 unter einigen Kinderkrankheiten, die dem neuen Protokoll den Ruf einer "Totgeburt" einbrachten. Die Standards wurden häufig geändert, was einigen Unmut erzeugte, da man die gerade fertig gewordenen Implementierungen schon wieder verwerfen musste. Der größte Einschnitt bestand in der Einführung der IEEE-Norm EUI-64 für die linklokalen Adressen. Vorher übernahm man die MAC-Adresse des Adapters einfach in die IPv6-Adresse, nun wurde die MAC-Adresse gemäß EUI-64 in veränderter Form in die IPv6-Adresse übernommen. Das änderte jedoch nichts an dem Problem, dass aus der gleichen MAC-Adresse auch immer die gleiche IPv6-Adresse resultiert. Dynamische IP-Vergabe wie bei IPv4 sollte es ja bei IPv6 nicht mehr geben. Datenschützer waren besorgt, dass auf diese Weise der Datenverkehr einer IP auf Routern mitgeschnitten werden könnte und beispielsweise für Marketingmaßnahmen oder staatliche Interventionen aller Art verwendet werden könnte. Die IETF definierte deshalb nachträglich die Datenschutzerweiterungen ("Privacy Extensions") gemäß RFC 3041: Die MAC-Adresse wird dabei zunächst mit einer pseudozufälligen Zahl verwürfelt, und aus dem Ergebnis dann die linklokale Adresse des Gerätes ermittelt.

In der Praxis ergab sich mit den linklokalen Adressen das Problem, dass es nicht mehr reicht, die IP-Adresse im Ziel-Feld einzutragen, sondern auch eine Scope-ID angegeben werden muss, da die linklokalen Adressen relativ zum Link sind und für sich genommen noch keinen Endpunkt definieren.

Deshalb sind die linklokalen Adressen nur beschränkt zur Kommunikation tauglich (abhängig davon, ob die IPv6-Unterstützung der verwendeten Anwendung das Konzept der Scope-ID kennt).

IPv6 und DNS

Auf Grund der Länge der IP-Nummern, die man sich nur in den seltensten Fällen merken können wird, ist IPv6 in besonderem Maße von einer funktionierenden Nameserver-Infrastruktur abhängig. Gerade dieser wichtige Bereich ist jedoch bis heute eine Baustelle. Es ergaben sich im wesentlichen folgende Probleme:

  1. IPv6-Autokonfiguration sucht normalerweise nicht nach Nameservern
  2. Privacy Extensions und DNS sind wegen der sich häufig ändernden Adressen schlecht unter einen Hut zu bekommen
  3. Chaos bei den DNS-Record-Typen für IPv6

Bei der Autokonfiguration erhält ein IPv6-Gerät vollautomatisch eine Adresse und ein Gateway, über das es ins Internet kommunizieren kann. Leider fehlt jedoch die Möglichkeit, auch automatisch einen DNS-Server zu suchen, was die Autokonfiguration fast wieder wertlos macht. Dies ist einer der Gründe, warum DHCP v6 entwickelt wurde, das eigentlich durch IPv6 überflüssig gemacht werden sollte. Wer ohne DHCP einen Nameserver finden will, muss auf Bastellösungen zurückgreifen, die meist ganz ähnlich wie die Router-Suche funktionieren. Statt einer Anfrage an die Multicast-Gruppe alle Router wird dabei eine Anfrage an alle Nameserver abgesetzt. Falls es mehrere DNS-Server im lokalen Netz gibt, sucht sich der Client dann den Server seiner Wahl aus den eintreffenden Antworten heraus.

Die Verwendung von Datenschutzerweiterungen ("Privacy Extensions") ist insofern eine Herausforderung an das DNS, als sich IP-Adressen dabei häufig und unvermittelt ändern. Wenn ein Client auf Erreichbarkeit unter einem DNS-Namen angewiesen ist, benötigt er ein zuverlässiges und sicheres Verfahren, um dem DNS-Server eine Adressänderung mitteilen zu können. Auf diesem Gebiet ist bis heute (2005) noch viel Bewegung zu verzeichnen und es hat sich noch kein verwendbarer Standard herauskristallisiert.

Lange Zeit bestand auch auf der grundlegendsten Ebene des DNS, den Records auf den Nameservern, Verwirrung. 1995 wurden in RFC 1886 zunächst der Record-Typ AAAA für die Forward-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. Im Jahr 2003 wurde das Verfahren A6 daher in RFC 3596 wieder nach "experimentell" zurückgestuft, und AAAA wurde der neue, alte Standard. Noch mehr Schwierigkeiten bereitet die Rückwärtsauflösung ("Reverse"-Auflösung) von IPv6-Adressen, da es durch das Hin- und her bei den Standards PTR-Records in zwei verschiedenen Formaten gibt, die noch dazu in drei verschiedenen Zonen liegen.

Die Umsetzung von IPv6 in der Praxis

IPv6 setzt sich im praktischen Einsatz nur langsam durch. Mit der Betriebssystemunterstützung sieht es im Moment folgendermaßen aus:

  • Windows XP: Auf expliziten Wunsch (ipv6 install) kann man bei Windows XP einen experimentellen IPv6-Protokollstapel installieren. Ab ServicePack 1 hat dieser Protokollstapel "Production Quality", und wird als Protokoll in den Netzwerkeigenschaften hinzugefügt. Ab ServicePack 2 kann IPv6 ebenfalls unter den Netzwerkeigenschaften hinzugefügt werden, mit dem Namen Internet Protokoll Version 6.
  • Windows 2000: Microsoft bietet einen experimentellen Protokollstapel als Patch an, der sich aber ohne weitere Maßnahmen nur zum gegenseitigen Anpingen von Rechnern eignet. Das experimentelle Patch läßt sich weiterhin nur auf PCs installieren, auf denen Windows 2000 mit Servicepack 1 läuft. Ist das Servicepack 2 installiert, funktioniert die Installation nicht mehr.
  • Windows Server 2003: Enthält einen Protokollstapel mit "Production Quality" und unterstützt IPv6-DNS (AAAA) Einträge und IPv6-Routing.
  • Windows 9x/ME: Lediglich eine kommerziell verfügbare Unterstützung der Firma Trumpet (Winsock).
  • xBSD: Die derzeit noch beste und vollständigste Unterstützung für IPv6 – vor allem ein Verdienst des japanischen KAME-Projektes.
  • Linux: Eine experimentelle IPv6-Implementation ist seit der Kernel-Version 2.2 enthalten. Der Kernel 2.4 bietet eine ebenfalls als experimentell markierte Unterstützung für IPv6, der jedoch noch wichtige Eigenschaften wie IPSec und Datenschutzerweiterungen (Privacy Extensions, RFC 3041) fehlen. Der neue Kernel 2.6.x bietet eine umfassende IPv6-Unterstützung auf ähnlichem Niveau wie die BSD-Derivate, die sich tatsächlich sicher produktiv einsetzen läßt.
  • Mac OS X: Enthält seit Version 10.2 Unterstützung für IPv6 auf der Basis von KAME. Erst seit Version 10.3 lässt sich IPv6 auch über das GUI konfigurieren.
  • Solaris: Seit der Version 8 ist die Unterstützung des IPv6-Protokolls auch in dem Betriebssystem der Firma SUN enthalten, das für SPARC- und i386-Rechnerarchitekturen zur Verfügung steht. Die Konfiguration erfolgt analog zu den Linux- und xBSD-Systemen über die Kommandozeile.
  • Cisco: Cisco ist der Marktführer bei Internet-Routern. Bei der Umsetzung von IPv6 gehörte Cisco aber eher zu den Schlusslichtern. Es gibt zwar mittlerweile IPv6-fähige IOS-Versionen, diese werden aber nicht von Vorneherein installiert, da sie noch als experimentell eingestuft werden.

Viele Anwendungen (vor allem aus dem Bereich der Freien Software) sind inzwischen ebenfalls IPv6-fähig. (Siehe auch Artikel IPv6/Portierung) Im heimatlichen LAN kann man so schon relativ problemfrei IPv6 benutzen. Jenseits des eigenen Border-Routers sieht es derzeit noch düster aus: Es gibt keine Provider, die native IPv6-Anbindung verkaufen (wohl aber welche, die diese tatsächlich anbieten, ohne dafür zu werben), so dass man im Moment auf bisweilen unbefriedigende Bastel-Lösungen mit Tunneling zurückgreifen muss. Es existiert eine Reihe von Tunnelprotokollen für jeweils unterschiedliche Anwendungsbereiche, darunter die Protokolle 6in4, 6over4, 6to4, Teredo, ISATAP und das NAT-taugliche AYIYA.

Zumindest in Europa und in Nordamerika besteht einfach auch keine Notwendigkeit zur Migration zu IPv6, da noch genügend freie IPv4-Adressen vorhanden sind (in Europa über 50%). In Asien geht der Trend inzwischen dahin, bei Neubauten (zum Beispiel dem NTT-Backbone) IPv6 auch zu benutzen. 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ückgebracht wurden (beispielsweise IPSec, QoS, Multicast. Das Umnummerieren und die Autokonfiguration kann man durch DHCP angenähert erreichen) – es gibt keine weitverbreitete Anwendung, die nur mit IPv6 funktionieren würde.

In Deutschland federführend bei den Versuchen zu IPv6 ist das JOIN-Projekt der Uni Münster. Im Moment ist seitens des JOIN und des DFN ein erstes IPv6-Backbone in Deutschland im Aufbau. Die Planungen für das "6Win" sehen einen ringförmigen Backbone durch Deutschland mit Querverbindung zwischen Essen und Berlin vor. Parallel dazu baut die Deutsche Telekom einen eigenen IPv6-Backbone zwischen den Standorten Darmstadt, Münster und Berlin auf und bietet ihren Geschäftskunden im Rahmen eines Showcase-Projektes Anschluss daran an. Dieses Netz soll in Münster und Berlin mit dem 6Win verbunden werden. Ebenfalls in Münster liegt der deutsche zentrale Zugang zum experimentellen IPv6-Netzwerk 6Bone.

Weiterführende Informationen

Was ist mit IPv5?

Wenn es IPv4 und IPv6 gibt, was ist dann mit IPv5? gehört mit zu den häufigsten Fragen, die sich IPv6-Neueinsteiger stellen. 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 zu Gunsten von IPv6 und RSVP eingestellt wurde.

Siehe auch

Anycast, Multicast, IPv9

Vorlage:WikiReader Internet

Abgerufen von „https://de.wikipedia.org/w/index.php?title=IPv6&oldid=5565110“