Version vom 10. Juli 2023, 10:36 Uhr

topic - Kurzbeschreibung

Beschreibung

Installation

Syntax

Optionen

Parameter

Umgebungsvariablen

Exit-Status

Anwendung

Fehlerbehebung

Konfiguration

Dateien

Anhang

Siehe auch

Sicherheit

Dokumentation

RFC

Man-Pages

Info-Pages

Links

Projekt

Weblinks

TMP

Beschreibung

Durch das schnelle Wachstum des Internets er gibt sich das Problem, dass der Adressraum des IPv4-Protokolls annähernd erschöpft ist
Wie Sie bereits wissen, besteht eine IPv4-Adresse nur aus 32 Bit, wodurch sich zumindest rein rechnerisch eine Anzahl von 4.294.967.296 Adressen ergibt
Ein großer Teil dieser Adressen steht außerdem nicht zur Verfügung
Allein durch die Tatsache, dass die komplette D-Klasse und die E-Klasse nicht zur Verfügung stehen, ergibt sich schon ein enormer Verlust
Außerdem müssen private Adressräume abgezogen werden, und der großzügige Umgang mit ganzen A-Klassen in den frühen Computertagen ist auch nicht zu vernachlässigen

IPv6-Adressen warten mit einer Länge von 128 Bit auf. Die Anzahl der möglichen Adressen, die sich daraus ergibt, macht genau:

340.282.366.920.938.463.463.374.607.431.768.211.456

Das sind also mehr als 340 Sextillionen. Man kann bei IPv6 wohl ohne weiteres großzügig bei der Verteilung der Adressen vorgehen. Weil IPv6 ohne Subnetzmaske auskommt, werden auch schon gleich zu Anfang eine ganze Menge Adressen verbraucht
Die Unterscheidung der Netze geschieht innerhalb der ersten 64 Bit
Demzufolge sind also noch 64 Bit für Host-Adressen verfügbar (allerdings pro Netzwerk)
Die Anzahl der möglichen Netze und Adressen pro Netzwerk ist somit identisch und liegt bei genau:

18.446.744.073.709.551.616

Das sind mehr als 18 Trillionen und es könnte somit momentan jeder Mensch etwa 2,4 Milliarden eigene Netzwerke betreiben, ohne in einen Engpass bezüglich der IP-Adressen zu kommen
Diese Zahlen sollten Ihnen nur eine kleine Vorstellung von den Dimensionen eines 128-Bit-Adressraums geben

Adressnotation

Bei der Notation von IPv6-Adressen sind folgende Punkte zu beachten:
- Eine IPv6-Adresse wird hexadezimal notiert.
- Sie besteht aus acht Segmenten zu je 16 Bit.
- Die einzelnen Segmente sind durch Doppelpunkte voneinander getrennt.
- Führende Nullen innerhalb eines Segments können weggelassen werden.
Segmente, die nur aus Nullen bestehen, können unter Umständen leer gelassen werden. Daraus ergeben sich zwei aufeinander folgende Doppelpunkte
Wenn mehrere aufeinander folgende Segmente aus Nullen bestehen, können diese aufdieselbe Art notiert werden
Innerhalb einer einzelnen IPv6-Adresse kann nur einmal ein doppelter Doppelpunkt verwendet werden, weil sonst im mittleren Bereich nicht mehr eindeutig festgestellt werden kann, wo der Netzwerkanteil der Adresse endet bzw. der Host-Anteil beginnt.

Beispiel:

fe80::20c:6eff:febe:22fc

Dies ergibt »aufgefüllt«:

fe80:0000:0000:0000:020c:6eff:febe:22fc

Hierbei handelt es sich übrigens um eine link-lokale Adresse
Diese Adressen werden nur für die Kommunikation innerhalb eines Netzwerksegments verwendet und sind nicht routingfähig
Die Host-Adresse kann ein IPv6-Host aus seiner MAC-Adresse selbst errechnen. Ein DHCP-Server ist deshalb zumindest in einfachen Netzwerken nicht erforderlich.

IPv6-Adressbereiche

IPv6 Präfixe

Bezeichnung	Präfix	Verwendung
Link Local Unicast	`fe80::/10`	Rechner im eigenen Subnetz
Site Local Unicast	fec0 - feff	Standortlokale Adressen
Unique Local Unicast	fc00 - fdff	Private Adressen
Multicast	ff00	Für mehrere Clients
Global Unicast	2000 - 3fff	Weltweite eindeutige Adressen
	`2001`	An Provider vergeben, die weiterverteilen.
	`2002`	Tunnelmechanismus 6to4
NAT64	`64:ff9b::/96`	Übersetzungsmechanismus NAT64

Link-lokale Unicast-Adressen

Adressbereich fe80::/10 sind, wie weiter oben schon erwähnt, nur zur Kommunikation innerhalb desselben Netzwerksegments gedacht. Routing ist mit diesen Adressen nicht möglich.

Unique-lokale Unicast-Adressen

Adressbereich fc00::/7 entsprechen den privaten Adressen des IPv4-Protokolls.
Sie lösen die inzwischen veralteten sitelokalen Unicast-Adressen ab und werden im Internet nicht geroutet.

Globale Unicast-Adressen

Hier sind mehrere Adressbereiche in Gebrauch.
Die endgültigen Bereiche scheinen noch nicht ganz festzustehen, sind für die LPI-Prüfung aber auch nicht von Belang
Der globale Bereich ist jedenfalls für die Kommunikation im Internet zuständig
Da diese Adressen bei den meisten Internet Service Providern noch nicht nativ zu bekommen sind, empfehle ich zum Experimentieren die Verwendung eines Tunnelbrokers

TMP

Was ist IPv6?

IPv6 ist ein neues Schicht 3 Vermittlungsprotokoll und es wird IPv4 (auch als IP bekannt) ablösen. IPv4 wurde vor langer Zeit entworfen (RFC 760 / Internet Protocol vom Januar 1980). Seitdem wurden viele Adressen vergeben und Erweiterungen angeregt. Die aktuelle RFC ist RFC 2460 / Internet Protocol Version 6 Specification. Hauptänderungen in IPv6 sind das neue Design des Headers sowie die Erweiterung der Adresslänge von 32 bits auf 128 bits. Die Schicht 3 ist für den Transport der Pakete von Endpunkt-zu-Endpunkt mittels adressbasierten Paket-Routings zuständig, und wie bei IPv4 müssen bei IPv6 die Adressen (Quell- und Zieladresse) inkludiert sein.

Für weitere Informationen zur IPv6 Geschichte siehe die älteren RFCs z.B. SWITCH IPv6 Pilot / References.

Geschichte von IPv6 & Linux

Die Jahre 1992, 1993 und 1994 der allgemeinen IPv6 Geschichte können Sie in folgendem Dokument nachlesen: IPv6 or IPng (IP next generation).

Zu erledigen: Bessere Chronologie, mehr Inhalt

Anfang

Der erste IPv6 Netzwerk Code wurde dem Linux Kernel 2.1.8 im November 1996 durch Pedro Roque hinzugefügt. Er basierte auf dem BSD API:

Diese Zeilen entstammen dem patch-2.1.8 (die E-Mail-Adresse wurde hier beim Copy & Paste absichtlich gelöscht).

2.2.2. Übergangszeit

Aufgrund fehlender Arbeitskraft konnte die IPv6-Kernel-Implementierung nicht mit den Drafts oder neu freigegebenen RFCs Schritt halten. Im Oktober 2000 wurde in Japan das USAGI Projekt gestartet. Das Ziel war, die fehlende bzw. bereits veraltete IPv6 Funktionalität in Linux zu implementieren. Dabei richtete man sich nach der aktuellen FreeBSD Implementierung von IPv6, die durch das KAME project umgesetzt wurde. Von Zeit zu Zeit wurden im Vergleich zu den aktuellen Standard Linux-Kernel-Quellen ein Auszug erstellt.

Bis zum Start der Entwicklungs-Kernel Serie 2.5.x, der USAGI Patch war so groß, das er von den Linux-Netzwerkcode-Maintainers nicht komplett für die Einbindung in die Produktions-Kernel Serie 2.4.x eingebunden werden konnte.

Während der Entwicklung in der Serie 2.5.x hat USAGI versucht, so viel wie möglich ihrer Erweiterungen darin zu integrieren.

Heute

Viele der von USAGI und anderen lang entwickelten IPv6-bezogenen Patches sind bereits in der Vanilla Kernel Serie 2.6.x integriert.

Zukunft

USAGI und andere arbeiten weiterhin an der Implementierung von neuen Features wie Mobility und anderen. Von Zeit zu Zeit werden neue Erweiterungs-Patches veröffentlicht, wie auch die Integration in die Vanilla Kernel Serie 2.6.x vorangetrieben.

Wie sehen IPv6 Adressen aus?

Wie gesagt, IPv6 Adressen sind 128 bit lang. Diese bit-Anzahl kann sehr hohe dezimale Zahlen mit bis zu 39 Ziffern ergeben:

Solche Zahlen sind nicht wirklich Adressen, die auswendig gelernt werden können. Die IPv6 Adressdarstellung ist bitweise orientiert (wie bei IPv4, aber das wird nicht oft bedacht). Eine bessere Schreibweise ist deshalb die hexadezimale Darstellung. Dabei werden 4 bits (auch ”nibble” genannt) durch die Zeichen 0-9 und a-f (10-15) dargestellt, wodurch die Länge auf 32 Zeichen reduziert wird.

Diese Darstellung ist ebenfalls nicht sehr angenehm (mögliche Verwechslung oder Verlust einzelner hexadezimaler Ziffern), so dass die IPv6 Designer das hexadezimales Format mit einem Doppelpunkt als Trennzeichen nach jedem 16 bit Block erweiterten. Ferner wird das führende ”0x” (ein in Programmiersprachen verwendetes Identifizierungsmerkmal für hexadezimale Werte) entfernt:

Eine gültige Adresse (s.u. Adress-Typen) ist z.B.:

Der Vereinfachung halber können führende Nullen jedes 16 bit-Blocks weggelassen werden:

Eine Sequenz von 16 bit-Blöcken, die nur Nullen enthaltet, kann durch ein “::“ ersetzt werden. Diese Komprimierung kann aber nicht öfters als einmal durchgeführt werden

Die höchstmögliche Reduktion sieht man bei der IPv6 Localhost Adresse:

Es gibt auch eine so genannte kompakte Darstellung (base 85 codiert) RFC 1924 / A Compact Representation of IPv6 Addresses (publiziert am 1. April 1996). Diese Notation wurde allerdings nie in der Praxis gesehen und ist wahrscheinlich ein Aprilscherz. Ein Beispiel:

Info: ipv6calc ist ein IPv6 Adressen-Format-Umrechner und Konvertierungsprogramm und ist hier zu finden: ipv6calc homepage (Mirror)

FAQ (Grundlagen)

Warum wird der Nachfolger von IPv4 nun IPv6 und nicht IPv5 genannt?

In jedem IP-Header werden die ersten 4 Bits für die Protokollversion reserviert. So sind theoretisch die Protokollnummern 0 bis 15 möglich:

4: Wird schon für IPv4 verwendet
5: Ist für das Stream Protocol (STP, RFC 1819 / Internet Stream Protocol Version 2) reserviert (das aber nie den Weg in die Öffentlichkeit fand)

So war die nächste freie Zahl 6. IPv6 war geboren!

IPv6 Adressen: Warum ist die Anzahl der Bits so groß?

Bei der Entwicklung von IPv4 dachte man, dass 32 Bits für die Welt ausreichend wären. Blickt man zurück, so waren bis heute 32 bits ausreichend. Vielleicht ist dies auch noch für ein paar Jahre so. Jedoch werden 32 bits nicht ausreichen, um in der Zukunft jedes Netzwerkgerät mit einer globalen Adresse ausstatten zu können. Denken Sie an Mobiltelefone, Autos (mit elektronischen Geräten an einem CAN Bus), Toaster, Kühlschränken, Lichtschalter usw.

Die IPv6 Designer haben 128 Bit gewählt, 4-mal mehr als im heutigen IPv4.

Aber die benutzbare Größe ist kleiner als es erscheinen mag, da in dem gegenwärtig definierten Adress-Schema 64 Bits für die Schnittstellen-Identifizierung verwendet werden. Die zweiten 64 Bit werden für das Routing verwendet. Die derzeitigen Aggregation-Levels (= Größe der zugeteilten IP-Blöcke) vorausgesetzt (/48, /32,...), ist eine Verknappung der Adressen weiterhin denkbar. Aber mit Sicherheit nicht in naher Zukunft.

Weitere Informationen finden Sie unter RFC 1715 / The H Ratio for Address Assignment Efficiency und RFC 3194 / The Host-Density Ratio for Address Assignment Efficiency.

IPv6 Adressen: Warum ist die Bit-Anzahl bei einem neuen Design so klein?

Es gibt (wahrscheinlich) eine Gruppe (bekannt ist nur Jim Fleming...) von Personen am Internet, die über IPv8 und IPv16 nachdenken. Für diese Designs gibt es aber keine hohe Akzeptanz und auch keine Kernel-Implementierungen. 128 bits sind die beste Wahl bezogen auf Header-Overhead und dem Datentransport. Denken Sie an die minimalste Maximum Transfer Unit (MTU) in IPv4 (575 octets) und in IPv6 (1280 octets), die Header-Länge in IPv4 (20 octets Minimum, kann bis zu 60 octets mit IPv4 Optionen ansteigen) und in IPv6 sind es 40 octets (fixer Wert). Dies ist 3.4 % der minimalen MTU in IPv4 und 3.1 % der minimalen MTU in IPv6. Dies bedeutet, dass der Overhead beim Header fast identisch ist. Mehr bits für die Adressierung würden größere Header und deshalb mehr Overhead erfordern. Bedenken Sie auch die maximale MTU von 1500 octets (in speziellen Fällen bei Jumbo-Paketen bis zu 9k octets) bei normalen Verbindungen (z.B. Ethernet). Letztlich wäre es kein korrektes Design, wenn 10 % oder 20 % der transportierten Daten in einem Schicht 3-Paket für Adressen und nicht für die ”Nutzlast” benötigt würden.

@@ Zeile 116: / Zeile 116: @@
 * Der globale Bereich ist jedenfalls für die Kommunikation im Internet zuständig
 * Da diese Adressen bei den meisten Internet Service Providern noch nicht nativ zu bekommen sind, empfehle ich zum Experimentieren die Verwendung eines Tunnelbrokers
+= TMP =
+=== Was ist IPv6? ===
+IPv6 ist ein neues Schicht 3 Vermittlungsprotokoll und es wird IPv4 (auch als IP bekannt) ablösen. IPv4 wurde vor langer Zeit entworfen (<nowiki>RFC 760</nowiki> / Internet Protocol vom Januar 1980). Seitdem wurden viele Adressen vergeben und Erweiterungen angeregt. Die aktuelle RFC ist <nowiki>RFC 2460</nowiki> / Internet Protocol Version 6 Specification. Hauptänderungen in IPv6 sind das neue Design des Headers sowie die Erweiterung der Adresslänge von 32 bits auf 128 bits. Die Schicht 3 ist für den Transport der Pakete von Endpunkt-zu-Endpunkt mittels adressbasierten Paket-Routings zuständig, und wie bei IPv4 müssen bei IPv6 die Adressen (Quell- und Zieladresse) inkludiert sein.
+Für weitere Informationen zur IPv6 Geschichte siehe die älteren RFCs z.B. SWITCH IPv6 Pilot / References.
+=== Geschichte von IPv6 & Linux ===
+Die Jahre 1992, 1993 und 1994 der allgemeinen IPv6 Geschichte können Sie in folgendem Dokument nachlesen: IPv6 or IPng (IP next generation).
+Zu erledigen: Bessere Chronologie, mehr Inhalt
+==== Anfang ====
+Der erste IPv6 Netzwerk Code wurde dem Linux Kernel 2.1.8 im November 1996 durch Pedro Roque hinzugefügt. Er basierte auf dem BSD API:
+{| class="wikitable"
+|
+|}
+Diese Zeilen entstammen dem patch-2.1.8 (die E-Mail-Adresse wurde hier beim Copy & Paste absichtlich gelöscht).
+==== 2.2.2. Übergangszeit ====
+Aufgrund fehlender Arbeitskraft konnte die IPv6-Kernel-Implementierung nicht mit den Drafts oder neu freigegebenen RFCs Schritt halten. Im Oktober 2000 wurde in Japan das USAGI Projekt gestartet. Das Ziel war, die fehlende bzw. bereits veraltete IPv6 Funktionalität in Linux zu implementieren. Dabei richtete man sich nach der aktuellen FreeBSD Implementierung von IPv6, die durch das KAME project umgesetzt wurde. Von Zeit zu Zeit wurden im Vergleich zu den aktuellen Standard Linux-Kernel-Quellen ein Auszug erstellt.
+Bis zum Start der Entwicklungs-Kernel Serie 2.5.x, der USAGI Patch war so groß, das er von den Linux-Netzwerkcode-Maintainers nicht komplett für die Einbindung in die Produktions-Kernel Serie 2.4.x eingebunden werden konnte.
+Während der Entwicklung in der Serie 2.5.x hat USAGI versucht, so viel wie möglich ihrer Erweiterungen darin zu integrieren.
+==== Heute ====
+Viele der von USAGI und anderen lang entwickelten IPv6-bezogenen Patches sind bereits in der Vanilla Kernel Serie 2.6.x integriert.
+==== Zukunft ====
+USAGI und andere arbeiten weiterhin an der Implementierung von neuen Features wie Mobility und anderen. Von Zeit zu Zeit werden neue Erweiterungs-Patches veröffentlicht, wie auch die Integration in die Vanilla Kernel Serie 2.6.x vorangetrieben.
+=== Wie sehen IPv6 Adressen aus? ===
+Wie gesagt, IPv6 Adressen sind 128 bit lang. Diese bit-Anzahl kann sehr hohe dezimale Zahlen mit bis zu 39 Ziffern ergeben:
+{| class="wikitable"
+|
+|}
+Solche Zahlen sind nicht wirklich Adressen, die auswendig gelernt werden können. Die IPv6 Adressdarstellung ist bitweise orientiert (wie bei IPv4, aber das wird nicht oft bedacht). Eine bessere Schreibweise ist deshalb die hexadezimale Darstellung. Dabei werden 4 bits (auch ”nibble” genannt) durch die Zeichen 0-9 und a-f (10-15) dargestellt, wodurch die Länge auf 32 Zeichen reduziert wird.
+{| class="wikitable"
+|
+|}
+Diese Darstellung ist ebenfalls nicht sehr angenehm (mögliche Verwechslung oder Verlust einzelner hexadezimaler Ziffern), so dass die IPv6 Designer das hexadezimales Format mit einem Doppelpunkt als Trennzeichen nach jedem 16 bit Block erweiterten. Ferner wird das führende ”0x” (ein in Programmiersprachen verwendetes Identifizierungsmerkmal für hexadezimale Werte) entfernt:
+{| class="wikitable"
+|
+|}
+Eine gültige Adresse (s.u. Adress-Typen) ist z.B.:
+{| class="wikitable"
+|
+|}
+Der Vereinfachung halber können führende Nullen jedes 16 bit-Blocks weggelassen werden:
+{| class="wikitable"
+|
+|}
+Eine Sequenz von 16 bit-Blöcken, die nur Nullen enthaltet, kann durch ein “::“ ersetzt werden. Diese Komprimierung kann aber nicht öfters als einmal durchgeführt werden
+{| class="wikitable"
+|
+|}
+Die höchstmögliche Reduktion sieht man bei der IPv6 Localhost Adresse:
+{| class="wikitable"
+|
+|}
+Es gibt auch eine so genannte ''kompakte'' Darstellung (base 85 codiert) <nowiki>RFC 1924</nowiki> / A Compact Representation of IPv6 Addresses (publiziert am 1. April 1996). Diese Notation wurde allerdings nie in der Praxis gesehen und ist wahrscheinlich ein Aprilscherz. Ein Beispiel:
+{| class="wikitable"
+|
+|}
+<blockquote>Info: ''ipv6calc'' ist ein IPv6 Adressen-Format-Umrechner und Konvertierungsprogramm und ist hier zu finden: ipv6calc homepage (Mirror)</blockquote>
+=== FAQ (Grundlagen) ===
+==== Warum wird der Nachfolger von IPv4 nun IPv6 und nicht IPv5 genannt? ====
+In jedem IP-Header werden die ersten 4 Bits für die Protokollversion reserviert. So sind theoretisch die Protokollnummern 0 bis 15 möglich:
+* 4: Wird schon für IPv4 verwendet
+* 5: Ist für das Stream Protocol (STP, <nowiki>RFC 1819</nowiki> / Internet Stream Protocol Version 2) reserviert (das aber nie den Weg in die Öffentlichkeit fand)
+So war die nächste freie Zahl 6. IPv6 war geboren!
+==== IPv6 Adressen: Warum ist die Anzahl der Bits so groß? ====
+Bei der Entwicklung von IPv4 dachte man, dass 32 Bits für die Welt ausreichend wären. Blickt man zurück, so waren bis heute 32 bits ausreichend. Vielleicht ist dies auch noch für ein paar Jahre so. Jedoch werden 32 bits nicht ausreichen, um in der Zukunft jedes Netzwerkgerät mit einer globalen Adresse ausstatten zu können. Denken Sie an Mobiltelefone, Autos (mit elektronischen Geräten an einem CAN Bus), Toaster, Kühlschränken, Lichtschalter usw.
+Die IPv6 Designer haben 128 Bit gewählt, 4-mal mehr als im heutigen IPv4.
+Aber die benutzbare Größe ist kleiner als es erscheinen mag, da in dem gegenwärtig definierten Adress-Schema 64 Bits für die Schnittstellen-Identifizierung verwendet werden. Die zweiten 64 Bit werden für das Routing verwendet. Die derzeitigen Aggregation-Levels (= Größe der zugeteilten IP-Blöcke) vorausgesetzt (/48, /32,...), ist eine Verknappung der Adressen weiterhin denkbar. Aber mit Sicherheit nicht in naher Zukunft.
+Weitere Informationen finden Sie unter <nowiki>RFC 1715</nowiki> / The H Ratio for Address Assignment Efficiency und <nowiki>RFC 3194</nowiki> / The Host-Density Ratio for Address Assignment Efficiency.
+==== IPv6 Adressen: Warum ist die Bit-Anzahl bei einem neuen Design so klein? ====
+Es gibt (wahrscheinlich) eine Gruppe (bekannt ist nur Jim Fleming...) von Personen am Internet, die über IPv8 und IPv16 nachdenken. Für diese Designs gibt es aber keine hohe Akzeptanz und auch keine Kernel-Implementierungen. 128 bits sind die beste Wahl bezogen auf Header-Overhead und dem Datentransport. Denken Sie an die minimalste Maximum Transfer Unit (MTU) in IPv4 (575 octets) und in IPv6 (1280 octets), die Header-Länge in IPv4 (20 octets Minimum, kann bis zu 60 octets mit IPv4 Optionen ansteigen) und in IPv6 sind es 40 octets (fixer Wert). Dies ist 3.4 % der minimalen MTU in IPv4 und 3.1 % der minimalen MTU in IPv6. Dies bedeutet, dass der Overhead beim Header fast identisch ist. Mehr bits für die Adressierung würden größere Header und deshalb mehr Overhead erfordern. Bedenken Sie auch die maximale MTU von 1500 octets (in speziellen Fällen bei Jumbo-Paketen bis zu 9k octets) bei normalen Verbindungen (z.B. Ethernet). Letztlich wäre es kein korrektes Design, wenn 10 % oder 20 % der transportierten Daten in einem Schicht 3-Paket für Adressen und nicht für die ”Nutzlast” benötigt würden.
 [[Kategorie:IPv6]]
 </noinclude>