Zum Inhalt springen

Skript/Netzwerk/IPv6

Aus Foxwiki

Skript/Netzwerk/IPv6

Einführung

IPv6 - Internetprotokoll Version 6

Beschreibung

DoD-Schicht Protokolle
Anwendung HTTP IMAP SMTP DNS …
Transport TCP/UDP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token Bus Token Ring FDDI …

1998


Header

IPv6/Header Aufbau des Protokollkopfes von IPv6

Beschreibung

Feste Länge (Anders als IPv4/Header)
  • 40 Byte (320 Bit)
  • inkl. 32 Byte für Absender- und Empfängeradresse (256 Bit)

IPv6 (Felder)

Byte/Bin 00-03 04-07 08-11 12-15 16-19 20-23 24-27 28-31
01 Version Traffic Class Flow Label H
e
a
d
e
r
02 Payload Length Next Header Hop Limit
03 - 06 Quell-IP-Adresse
07 - 10 Ziel-IP-Adresse
11+ Payload

IPv4 Header Felder

IPv4/Header#Header-Format

Option Beschreibung
Version always 4
TOS (type of service) precedence (3 bits) and "minimize delay", "maximize throughput", "maximize reliability", "minimize cost" bits
Identifier identifier, different for each packet
TTL time to live field; initialized to 64; decremented at each router; drop if TTL = 0
Protocol next header proto (TCP 6, UDP 17)
Header checksum add together 16-bit words using one’s complement: software optimized

Entfallene Felder

Option Beschreibung
HL IPv6Header eine feste Länge hat
Protocol Feld Next-Header angibt welches Protokoll auf der Transportschicht verwendet wird.
Felder zur
Fragmentierung		 IPv6 Fragmentierung wird anders handhabt, IPv6-Router fragmentieren keine Pakete, sondern schicken der Quelle eine Nachricht kleinere Pakete zu schicken.
Checksum die Berechnung der Prüfsumme bei jedem Hop sich negativ auf die Performance auswirkt, auf den Schichten über und unter der Vermittlungsschicht werden bereits Prüfsummen berechnet
Padding

Header-Format

Header-Felder

Feld Länge (bit) Inhalt
Version 4 IP-Versionsnummer (6)
Traffic Class 8 Für Quality of Service (QoS) verwendeter Wert. Eine Art Prioritätsvergabe.
Flow Label 20 Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.
Payload Length 16 Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte
Next Header 8 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 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 Adresse des Senders
Destination Address 128 Adresse des Empfängers


Vereinfachung des Headers

Enthält nur grundlegende Forwarding-Information
  • Zusätzliche Informationen in variablen zusätzlichen Erweiterungs-Headern, welche durch das "Next Header" Feld identifiziert werden
  • Trotz vierfacher IPv6-Adresslänge (16 Byte) nur doppelte Headerlänge

Header-Format

Feste Länge
  • Bei IPv6 eine feste Länge von 40 Byte (320 Bit)
  • Im Gegensatz zu IPv4
Extension Headers
  • Optionale, seltener benutzte Informationen werden in Erweiterungs-Kopfdaten (engl.: Extension Headers) eingebettet
  • zwischen IPv6-Kopfdatenbereich und der eigentlichen Nutzlast (Payload)

Kopfdaten

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

Trace File

IPv4 und IPv6 Header im Vergleich




Adressierung

Skript/Netzwerk/IPv6

Beschreibung

Beschreibung
Adressen
Interface
Adressraum
Privacy


Skript/Netzwerk/IPv6 - Unterteilung des IPv6-Adressraums

Beschreibung

IPv6-Adressraum

Eigenschaft IPv4 IPv6
Adressraum 32 Bit 128 Bit
Maximale Adressen 4.294.967.296 340.282.366.920.938.463.463.374.607.431.768.211.456

Zuteilung

IANA
Zuweisungslogik

Die Internet Assigned Numbers Authority (IANA) weist nur einen kleinen Teil des gesamten IPv6-Raums zu

  • Die IANA stellt globale Unicast-Adressen bereit, die mit den führenden Bits ganz links 001 beginnen
  • Ein kleiner Teil der Adressen, die mit 000 und 111 beginnen, wird für spezielle Typen zugewiesen
  • Alle anderen möglichen Adressen sind für die zukünftige Verwendung reserviert und werden derzeit nicht zugewiesen
Beispiele für globale Unicast-Adressen
2001:4::aac4:13a2
2001:0db6:87a3::2114:8f2e:0f70:1a11
2c0f:c20a:12::1

Derzeit beginnen in der Internet-IPv6-Routing-Tabelle alle Präfixe mit der hexadezimalen Ziffer 2 oder 3, da die IANA nur Adressen vergibt, die mit den ersten 3 Bits 001 beginnen


Subnetzmasken

Teilen IP-Adressen in einen Netz- und einen Host-Teil

Lehren aus IPvb4

Es wäre von Vorteil

  • Interfaces mit meherenen IP-Adresse
    • je nach Bedarf und Zweck (aliases, multicast und weitere)

Um in Zukunft flexibler bleiben zu können, geht man bei IPv6 weiter und erlaubt pro Interface mehr als eine zugewiesene IP-Adresse

  • Derzeit sind durch die RFCs kein Limit gesetzt, wohl aber in der Implementierung des IPv6 Stacks (um DoS Attacken vorzubeugen)

Neben der großen Bit-Anzahl für Adressen definiert IPv6 basierend auf einigen vorangestellten Bits verschiedene Adress-Typen

  • Diese werden hoffentlich in der Zukunft niemals aufgehoben (zum Unterschied zu IPv4 heute und die Entwicklung der class A, B und C Netze)

Zur Unterstützung einer automatischen Konfiguration wird die Bitanzahl in einen Netzwerk-Teil (vordere 64 Bits) und einen Hostteil (hintere 64 Bit)

Adress-Typ Beschreibung
Adressen ohne speziellen Präfix
Netzteil der Adresse (Präfix)
Adress-Typen (Host-Teil)
Präfixlängen für das Routing

Präfixe

Netzteil der Adresse

Es wurden einige Adress-Typen definiert

  • Zugleich blieb für zukünftige Anforderungen ausreichend Raum für weitere Definitionen
  • In RFC/4291 / IP Version 6 Addressing Architecture wird das aktuelle Adress-Schema definiert
Präfixe (Adress-Arten)
Adress-Typ Beschreibung
Link-lokaler Adress-Typ
Site-lokaler Adress-Typ
Unique Local IPv6 Unicast Adressen
Globaler Adress-Typ ("Aggregatable global unicast")
Multicast-Addressen
Anycast-Adressen
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

Ohne Präfix

Adressen ohne speziellen Präfix
Adress-Typ Beschreibung
Localhost Adresse
Unspezifische Adresse
IPv6 Adressen mit eingebetteter IPv4 Adresse

Localhost Adresse

Pakete mit dieser Quell- bzw. Ziel-Adresse sollten niemals den sendenden Host verlassen 

::1

Unspezifische Adresse

Dies ist eine spezielle Adresse vergleichbar mit "any" oder "0.0.0.0" bei IPv4

Diese Adresse wird meistens in Routing-Tabellen und beim "socket binding" (zu jeder IPv6 Adresse) angewandt bzw. gesehen

Beachten
Die unspezifizierte Adresse kann nicht als Ziel-Adresse verwendet werden

Adress-Typen (Host-Teil)

In Hinblick auf Auto-Konfigurations- und Mobilitätsfragen wurde entschieden, die niedrigeren 64 bits als Host-Bestandteil zu nutzen

  • Jedes einzelne Subnetz kann deshalb eine große Anzahl an Adressen enthalten

Der Host-Teil kann aus unterschiedlichen Blickwinkeln betrachtet werden:

Adress-Typ Beschreibung
Automatisch erstellte Adressen
Manuell festgelegte Adressen

Automatisch erstellte Adressen

Automatisch erstellte Adressen
  • stateless
Auto-Konfiguration

Bei der Auto-Konfiguration wird der Hostteil der Adresse durch die Konvertierung der MAC-Adresse eines Interfaces (falls vorhanden) zu einer einmaligen IPv6 Adresse (mittels EUI-64 Methode) generiert

  • Falls keine MAC-Adresse verfügbar ist (beispielsweise bei virtuellen Interfaces), wird anstelle dessen etwas anderes herangezogen (wie beispielsweise die IPv4 Adresse oder die MAC-Adresse eines physikalischen Interfaces)

Als Beispiel hat hier ein NIC folgende MAC-Adresse (48 bit)

  • Diese wird gemäß demIEEE-Tutorial EUI-64 Design für EUI-48 Identifiers zum 64 bit Interface Identifier erweitert:
  • Mit einem gegebenen Präfix wird daraus die schon oben gezeigte IPv6-Adresse:
Datenschutzproblem

Datenschutzproblem mit automatisch erstellten Adressen sowie eine Lösung

  • Der "automatisch generierte" Hostteil ist weltweit einmalig
  • mit Ausnahme, wenn der Hersteller einer NIC die gleiche MAC-Adresse bei mehr als einer NIC einsetzt
  • Die Client-Verfolgung am Host wird dadurch möglich, solange kein Proxy verwendet wird
Dies ist ein bekanntes Problem und eine Lösung wurde dafür definiert
  • Datenschutz-Erweiterung
  • definiert in RFC/3041
  • Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (es gibt bereits ein neueres Draft: draft-ietf-ipv6-privacy-addrs-v2-*)
  • Es wird sporadisch mittels eines statischen und eines Zufallswertes ein neues Suffix erstellt
Hinweis
Dies ist nur für ausgehende Client-Verbindungen sinnvoll und bei bekannten Servern nicht wirklich sinnvoll

Manuell festgelegte Adressen

Bei Servern ist es wahrscheinlich leichter, sich einfachere Adressen zu merken

  • Dies kann beispielsweise mit der Zuweisung einer zusätzlichen IPv6 Adresse an ein Interface geschehen

Für das manuelle Suffix, wie "::1" im obigen Beispiel, muss das siebte höchstwertige Bit auf 0 gesetzt sein (das universale/local Bit des automatisch generierten Identifiers)

  • Es sind auch noch andere (ansonsten nichtausgewählte) Bit-Kombinationen für Anycast-Adressen reserviert

Präfixlängen für das Routing

IPv6-Adressentypen

Eine IPv6-Adresse ist eine 128-Bit-Kennung der Netzwerkschicht für eine Netzwerkschnittstelle eines IPv6-fähigen Knotens

"IPv6 Address Types

Haupttypen

Typ Beschreibung
Unicast Eine Netzwerkschicht-Kennung für eine einzelne Schnittstelle eines IPv6-fähigen Knotens
  • Pakete, die an eine Unicast-Adresse gesendet werden, werden an die mit dieser IPv6-Adresse konfigurierte Schnittstelle zugestellt
  • Es handelt sich also um eine Eins-zu-eins-Kommunikation
Multicast Eine Netzwerkschicht-Kennung für eine Reihe von Schnittstellen, die zu verschiedenen IPv6-fähigen Knoten gehören
  • Pakete, die an eine Multicast-Adresse gesendet werden, werden an alle durch diese Adresse identifizierten Schnittstellen zugestellt
  • Es handelt sich also um eine One-to-many-Kommunikation
Anycast Eine Netzwerkschicht-Kennung für eine Reihe von Schnittstellen, die zu verschiedenen IPv6-fähigen Knoten gehören
  • Pakete, die an eine Anycast-Adresse gesendet werden, werden an die "nächstgelegene" Schnittstelle zugestellt, die durch diese Adresse identifiziert wird. "Am nächsten" bedeutet in der Regel diejenige mit der besten Routing-Metrik gemäß dem IPv6-Routing-Protokoll
  • Es handelt sich also um eine "one-to-closest"-Kommunikation
  • Broadcast - In IPv6 gibt es keine Broadcast-Adressen
  • Die Broadcast-Funktionalität wird über Multicast-Adressen implementiert. 


Unicast

Aggregierbare globale Unicast-Adresse

Aggregierbare globale Unicast-Adressen sind Teil des globalen Routing-Präfixes

  • Die Struktur dieser Adressen ermöglicht die Aggregation von Routing-Einträgen, um eine kleinere globale IPv6-Routing-Tabelle zu erhalten
  • Zurzeit beginnen alle globalen Unicast-Adressen mit dem Binärwert 001 (2000::/3)
  • Ihre Struktur besteht aus einem globalen 48-Bit-Routing-Präfix und einer 16-Bit-Subnetz-ID, die auch als Site-Level-Aggregator (SLA) bezeichnet wird
"Aggregatable Global IPv6 Address Format"

Schauen wir uns das folgende Beispiel für die Zuweisung globaler Unicast-Adressen an

  • Die IANA vergibt derzeit Adressen mit dem Präfix 2000::/3 an die regionalen Anbieter
  • Ein Teil dieses Adressraums ist zum Beispiel ARIN zugewiesen
  • ARIN weist dann Teilbereiche dieses Adressraums 2001:18::/23 an ISPs und Großkunden zu

Beachten Sie, dass das Präfix 2001:18B1:1::/48, das dem Kunden 1 zugewiesen wurde, Teil des größeren Präfixes 2001:18B1::/32 ist, das dem ISP gehört, der wiederum Teil des größeren Präfixes 2001:18::/23 von ARIN ist, usw

  • Aus diesem Grund werden diese globalen IPv6-Unicast-Adressen als aggregierbar bezeichnet

Link-Lokal

Struktur einer link-local-Adresse

IPv6 link-local ist eine spezielle Art von Unicast-Adresse

  • Wird auf jeder Schnittstelle automatisch konfiguriert
Kombination
  • link-local Präfix FE80::/10
    • die ersten 10 Bit entsprechen 1111 1110 10
  • MAC-Adresse der Schnittstelle
Ähnlich wie 169.254.0.0/16 in IPv4
IPv6 Link-local address autoconfigured on Windows

Bei mehrere IPv6-fähige Knoten an einen Switch, konfigurieren sie ihre Schnittstellen automatisch mit link-local-Adressen, erkennen einander und können miteinander kommunizieren

  • Der Geltungsbereich der link-local-Adresse ist nur die jeweilige Verbindung
  • Router leiten Pakete, die eine link-local-Quell- oder Zieladresse haben, nicht an andere Verbindungen weiter
Sind nur innerhalb abgeschlossener Netzwerksegmente (link) gültig
  • Netzwerksegment ist ein lokales Netz, gebildet mit Switches oder Hubs, bis zum ersten Router
  • Link-Local-Adressen sind mit APIPA-Adressen im Netz 169.254.0.0/16 vergleichbar
Formatpräfix lautet fe80::/10
10 Bit 54 Bit 64 Bit
1111111010 0 Interface ID
Verwendung
  • Adressierung von Nodes in abgeschlossenen Netzwerksegmenten
  • Autokonfiguration
  • Neighbour-Discovery
Vorteile
  • In einem Netzwerksegment muss keinen DHCP-Server zur Adressvergabe konfigurieren werden
Zone ID
  • Soll ein Gerät mittels einer dieser Adressen kommunizieren, so muss die Zone ID mit angegeben werden
  • eine Link-Lokale-Adresse kann auf einem Gerät mehrfach vorhanden sein
Beispiele
fe80::7645:6de2:ff:1%1
fe80::7645:6de2:ff:1%eth0
Link-lokaler Adress-Typ
  • 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

Es handelt sich um spezielle Adressen, die ausschließlich auf einem Link eines Interfaces gültig sind

  • Wird diese Adresse als Zieladresse verwendet, so kann das Paket niemals einen Router passieren
  • Die Adresse wird bei der Link-Kommunikation eingesetzt, beispielsweise:
  • Ist noch jemand anderer auf diesem Link?
  • Ist jemand mit einer speziellen Adresse hier (beispielsweise Suche nach einem Router)?

Die Adresse beginnt mit (wobei "x" für ein hexadezimales Zeichen steht, im Normalfall "0")

Eine Adresse mit diesem Präfix gibt es an jedem IPv6 fähigen Interface nach einer stateless automatischen Konfiguration (dies ist der Regelfall)

Loopback

Sowohl bei IPv4 als auch bei IPv6 bezeichnet eine Loopback-Adresse eine logische Schnittstelle, die keine physische Repräsentation hat und immer betriebsbereit ist

  • An eine Loopback-Adresse gesendete Pakete werden über dieselbe Schnittstelle zurückgeschickt (looped)
  • In der Computerwelt werden Loopback-Adressen normalerweise zum Testen des TCP/IP-Netzwerkstacks verwendet

In IPv4 ist der gesamte Adressbereich 127.0.0.0/8 für Loopback-Adressen reserviert, aber alle führenden Betriebssysteme verwenden standardmäßig die berühmte Adresse 127.0.0.1, genannt "localhost"

  • Der restliche 127.0.0.0/8-Adressraum wird in der Regel nicht verwendet

In IPv6 ist die IPv6-Adresse 0:0:0:0:0:0:0:1/128 für die Loopback-Kennung reserviert

  • Sie kann auf ::1/128 gekürzt werden

Nicht spezifiziert

  • wird von Betriebssystemen in Ermangelung einer gültigen IP-Adresse und Prozessen wie DHCP verwendet
  • Router leiten keine Pakete weiter, deren Quell- oder Zieladresse auf eine nicht spezifizierte Adresse eingestellt ist
Spezieller Adresstyp

Alle binären Bit auf 0 gesetzt

IP-Version Adresse
4 0.0.0.0/32
6 0:0:0:0:0:0:0:0:0/128
::/128

Unique Local

Struktur einer Unique-Local-Adresse

Eine eindeutige lokale Adresse

  • Spezieller Typ einer global eindeutigen IPv6-Adresse
Merkmale

Weltweit eindeutiges Präfix

  • ähnlich wie globale Unicast-Adressen

Keinen Konflikt mit anderen globalen IPv6-Präfixen

  • Kann einfach an Standortgrenzen gefiltert werden

Internet-Router filtern alle ein- oder ausgehenden lokalen IPv6-Unicast-Routen heraus

Standorte verbinden ohne Adresskonflikte
  • Es handelt sich um einen von Internetdienstanbietern unabhängigen Adressraum
  • Daher überschneiden sich diese Adressen nicht mit einem anderen vom ISP zugewiesenen Bereich
  • Die Anwendung behandelt diese Adressen wie reguläre globale IPv6-Adressen

Eingebettetes IPv4-in-IPv6

Struktur einer eingebetteten IPv4-in-IPv6-Adresse

Eingebettetes IPv4-in-IPv6 ist eine Unicast-Adresse, die nur Nullen in den ersten 96 Bits der Adresse und eine IPv4-Adresse in den äußersten 32 Bits hat

  • Wenn also die IPv4-Adresse A.B.C.D (in Hexadezimalziffern) mit dieser Logik in IPv6 eingebettet wird, wird sie zu 0:0:0:0:0:0:0:A:B:C:D oder einfach ::A:B:C:D
  • Diese Arten von IPv6-Adressen werden in automatischen Tunneln verwendet, die sowohl IPv4- als auch IPv6-Protokollstapel unterstützen


IPv6 Adressen mit eingebetteter IPv4 Adresse

Es gibt zwei Adressen-Typen, die IPv4 Adressen enthalten können

IPv4 Adressen in IPv6 Format

IPv4-only IPv6-kompatible Adressen kommen manchmal bei IPv6 kompatiblen Daemon zur Anwendung, die allerdings ausschließlich an IPv4 Adressen gebunden sind

Diese Adressen sind mit einer speziellen Präfixlänge von 96 definiert (a.b.c.d. ist die IPv4 Adresse):

oder in komprimiertem Format:

Die IPv4 Adresse 1.2.3.4

  • beispielsweise sieht wie folgt aus:
IPv4 kompatible IPv6 Adressen

Dieser Adress-Typ wurde für das automatische Tunneln (RFC 2893 / Transition Mechanisms for IPv6 Hosts and Routers) verwendet, welches aber durch das 6to4 tunneling ersetzt wurde

Unicast-Adressen

Kommunikation eines Netzknotens mit genau einem anderen Netzknoten
Unicast-Adressen sind providerbasierte Adressen und gelten Weltweit
  • Sie sind durch die ersten 3 Bit 010 gekennzeichnet
  • Anschließend folgen 5 Bit Registry-ID, die das Organ bezeichnen, das diese Adresse an den Provider vergeben hat, auf die wiederum eine Provider-ID folgt
  • Anschließend folgt die Subscriber-Id, die die Einrichtung bezeichnet, die von dem Provider die Adresse bezieht
Subscriber kann sein Netz wiederum in verschiedene Unternetze gliedern
  • die durch eine entsprechende ID gekennzeichnet sind
  • Die letzten 48 Bit bilden schließlich die Interface-ID
  • Da dies genau der Größe einer MAC-Adresse enstpricht, können sich damit Stationen im LAN automatisch konfigurieren, indem sie einfach ihre MAC-Adresse als Interface-ID verwenden
Weitere Adressbereiche
  • die den heutigen lokalen Adressbereichen entsprechen, und die nicht von einem Router geroutet werden
  • Es sind dies verbindungsspezifische und standortspezifische lokale Adressen

Site Local Unicast (veraltet)

fec0::/10
  • fec0… bis feff…
Standortlokale Adressen (site local addresses)
  • Nachfolger der privaten IP-Adressen (beispielsweise 192.168.x.x)
  • Durften nur innerhalb der gleichen Organisation geroutet werden
  • Die Wahl des verwendeten Adressraums innerhalb von fec0::/10 war beliebig
Überschneidungen der Adressräume
  • Es konnte zu Überschneidungen der Adressräume an unterschiedlichen Standorten kommen
    • Bei der Zusammenlegung von ehemals getrennten Organisationen
    • wenn eine VPN-Verbindung zwischen eigentlich getrennten mit Site Local Addresses nummerierten Netzwerken hergestellt wurde
Deprecated (RFC 3879)
  • Aus diesem und weiteren Gründen sind Site Local Addresses nach RFC 3879 veraltet
    • werden aus zukünftigen Standards verschwinden
  • Neue Implementierungen müssen diesen Adressbereich als Global-Unicast-Adressen behandeln
Nachfolger sind die Unique Local Unicast-Addressen

Site-Local

Site-lokaler Adress-Typ

Diese Adressen sind vergleichbar zu den RFC 1918 / Address Allocation for Private Internets im heutigen IPv4

  • Eine Neuerung und Vorteil hierbei ist, vergleichbar zum 10.0.0.0/8 im IPv4, die Nutzbarkeit von 16 bits bzw. ein Maximum von 65536 Subnetzen

Ein weiterer Vorteil: Da man bei IPv6 mehr als eine Adresse an ein Interface binden kann, ist auch die Zuweisung einer site-local Adresse zusätzlich zu einer globalen Adresse möglich

Die Adresse beginnt mit:

("x" ist ein hexadezimales Zeichen, normalerweise "0")

Dieser Adresstyp ist nun abgekündigt RFC 3879 / Deprecating Site Local Addresses und sollte nicht mehr verwendet werden

  • Für Tests im Labor sind solche Adressen meineserachtens aber immer noch eine gute Wahl

Unique Local Unicast

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

Weil die schon früh definierten site-local Adressen nicht eindeutig sind, kann dies zu großen Problemen führen, wenn beispielsweise einst unabhängige Netzwerke später zusammengeschlossen werden (Überlappung von Subnetzen)

  • Aufgrund dessen und anderer Gründe wurde ein neuer Adresstyp definiert, genant RFC 4193 / Unique Local IPv6 Unicast Addresses

Die Adresse beginnt mit:

Ein Teil des Präfix (40 Bits) werden pseudozufällig generiert

  • Es ist sehr unwahrscheinlich, daß zwei generierte Präfixe identisch sind

Ein Beispiel für einen Präfix (generiert mit Hilfe des web-basierten Werkzeugs: Goebel Consult / createLULA):

Globale Unicast-Adressen

  • Aggregatable global unicast
  • 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

Heute gibt es ist per Definition eine globale Adress-Art (Das erste Design, ''Provider based'' genannt, wurde bereits vor einigen Jahren wieder aufgegeben RFC 1884 / IP Version 6 Addressing Architecture [obsolete]

  • Einige Überbleibsel hiervon sind in älteren Linux Kernelquellen noch zu finden

Die Adresse beginnt mit (x sind hexadezimale Zeichen)

Hinweis: Der Zusatz "aggregatable" im Namen wird in aktuellen Drafts abgelegt

  • Es sind weitere Subarten definiert:

6bone Test-Adressen

Diese globalen Adressen waren die Ersten definierten und auch benutzen Adressen

  • Sie alle beginnen mit:

Beispiel:

Eine spezielle 6bone Test-Adresse, die niemals weltweit einmalig ist, beginnt mit

und wird zumeist in alten Beispielen benutzt, um zu vermeiden, dass Anwender diese mit Copy & Paste in Ihre Konfigurationen übernehmen können

  • Auf diese Weise können Duplikate weltweit einmaliger Adressen aus Versehen bzw. Unachtsamkeit vermieden werden
  • Es würde für den Original-Host ernste Probleme bedeuten (beispielsweise Antwortpakete für niemals gesendete Anfragen bekommen...)
  • Aufgrund dessen, daß IPv6 nun produktiv ist, wird dieser Präfix nicht mehr länger delegiert und nach dem 6.6.2006 vom Routing ausgenommen (mehr unter RFC 3701 / 6bone Phaseout )

6to4 Adressen

Diese Adressen werden für einen speziellen Tunnelmechanismus verwendet [RFC 3056 / Connection of IPv6 Domains via IPv4 Clouds und RFC 2893 / Transition Mechanisms for IPv6 Hosts and Routers]

  • Sie kodieren eine gegebene IPv4 Adresse, ein eventuelles Subnetz und beginnen mit

beispielsweise wird 192.168.1.1/5 repräsentiert durch:

Ein kleines Shell-Kommando kann aus einer IPv4 eine 6to4 Adresse erstellen:

Siehe auch tunneling using 6to4 und information about 6to4 relay routers

Durch einen Provider zugewiesene Adressen für ein hierarchisches Routing

Diese Adressen werden an Internet Service Provider (ISP) delegiert und beginnen mit:

Präfixe für große ISPs (mit eigenem Backbone) werden durch local registries vergeben

  • Zurzeit wird ein Präfix mit der Länge 32 zugeteilt

Grosse ISPs delegieren ihrerseits an kleinere ISPs ein Präfix mit der Länge 48

Für Beispiele und Dokumentationen reservierte Adressen

Momentan sind zwei Adressbereiche für Beispiele und Dokumentationen RFC 3849 / IPv6 Address Prefix Reserved for Documentation reserviert:

Diese Adressbereiche sollten nicht geroutet werden und am Übergangsrouter zum Internet (basierend auf Absendeadressen) gefiltert werden

Unique Local Unicast (ULA)

fc00::/7 (fc00… bis fdff…)
Für private Adressen gibt es die Unique Local Addresses (ULA)
  • beschrieben in RFC 4193
Präfix fd
  • Derzeit ist nur das Präfix fd für lokal generierte ULA vorgesehen
Präfix fc
  • ist für global zugewiesene, eindeutige ULA reserviert
Site-ID
  • Auf das Präfix folgen 40 Bit, als eindeutige Site-ID
Eindeutigkeit
  • Diese Site-ID ist bei den ULA mit dem Präfix fd zufällig zu generieren und somit sehr wahrscheinlich eindeutig
  • Bei global vergebenen ULA jedoch auf jeden Fall eindeutig
    • RFC 4193 gibt jedoch keine konkrete Implementierung der Zuweisung von global eindeutigen Site-IDs an
Subnet-ID
  • Nach der Site-ID folgt eine 16-Bit-Subnet-ID, welche ein Netz innerhalb der Site angibt
Beispiel
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
  • 2323 eine willkürlich gewählte Subnet-ID
  • ::1 die Host-ID
Vorteil der Verwendung von wahrscheinlich eindeutigen Site-IDs
  • Beim Einrichten eines Tunnels zwischen getrennt voneinander konfigurierten Netzwerken sind Adresskollisionen sehr unwahrscheinlich
  • Pakete, die an eine nicht erreichbare Site gesendet werden, laufen mit großer Wahrscheinlichkeit ins Leere, statt an einen lokalen Host gesendet zu werden, der zufällig die gleiche Adresse hat
ULA-Central
  • 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" bisher nicht gegründet
  • Sowohl der RFC 4193 als auch der proposed standard sind identisch in Bezug auf das Adressformat und den Generierungs-Algorithmus

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
  • In RFC 4291 vom Februar 2006 als veraltet (engl. deprecated) gekennzeichnet
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
  • Routbare und weltweit einzigartige Adressen
Bildung einer Globalen Unicast Adresse
Unterteilung des Adressraumes in öffentlichen (TLA, NLA, SLA) und lokalen Bereich (64 Bit + 64 Bit)
  • Routing im öffentl. Bereich effizient durch hierarchische Netz-topologische Orientierung
  • Routing im lokalen Bereich effizient durch festen "public-" Teil der Adresse (64 Bit)

Nur Top-Level Aggregation ID muss zentral verwaltet werden

Adressvergabe erfolgt blockweise hierarchisch von oben nach unten
Option Beschreibung
TLA Top Level Aggregation (beispielsweise Super-Provider,Exchange)
NLA Next Level Aggregation (beispielsweise ISP)
SLA Site Level Aggregation (beispielsweise Firma)
Global Unicast Adressen
Option Beschreibung
2001 2003, 240, 260, 261, 262, 280, 2a0, 2b0 werden an Provider vergeben und 2c0
  • die diese an ihre Kunden weiterverteilen
  • werden von Regional Internet Registries (RIRs) vergeben
2001::/32 sind ihnen noch vollständig zugeteilt
  • beginnend mit 2001:0:
  • anders als 2001::/16
  • Tunnelmechanismus Teredo 3ffe::/16
2001:db8::/32 Testnetzwerk 6Bone
  • Dokumentationszwecke
  • wurden gemäß RFC 3701 an die IANA
  • keine tatsächlichen Netzteilnehmer zurückgegeben
2002 64:ff9b::/96 Adressen des Tunnelmechanismus 6to4
  • Übersetzungsmechanismus NAT64 gemäß RFC 6146

Multicast

Netzwerk-Multicast ist eine Technik, bei der ein Knoten Pakete an mehrere Ziele gleichzeitig sendet (one-to-many)

  • Bei den Zielen handelt es sich eigentlich um eine Reihe von Schnittstellen, die durch eine einzige Multicast-Adresse, die sogenannte Multicast-Gruppe, identifiziert werden

In IPv6 werden Multicast-Adressen von allen anderen Typen durch den Wert der äußersten linken 8 Bits der Adressen unterschieden: ein Wert von 11111111 (Hexadezimalziffern FF) bedeutet, dass es sich um eine Multicast-Adresse handelt

  • Daher sind alle Multicast-Adressen Teil des Präfixes ff00::/8, was dem IPv4-Multicast-Adressraum 224.0.0.0/4 entspricht
Regeln für Multicast
  • Pakete, die an eine Multicast-Gruppe gesendet werden, haben immer eine Unicast-Quelladresse
  • Eine Multicast-Adresse kann nicht die Quelladresse eines Pakets sein
In IPv6 gibt es keine Broadcast-Adressen
  • Stattdessen werden in IPv6 für diese Funktion spezielle Multicast-Gruppen verwendet - eine Multicast-Adresse für alle IPv6-Geräte und eine Multicast-Adresse für angefragte Knoten

Bekannte Multicast-Adressen

Bei IPv4 gibt es mehrere bekannte Multicast-Adressen im Bereich 224.0.0.0/24

  • Bekannt bedeutet, dass diese Adressen vordefiniert
  • für eine besondere Verwendung reserviert sind

In IPv6 beginnen alle bekannten Multicast-Adressen mit dem Präfix ff00::/12

  • Das bedeutet, dass die ersten 3 Hexadezimalziffern einer Adresse immer ff0 sind
Beispiele
Adresse Funktion
FF02::1 Alle Knoten Adresse
FF02::2 Alle Router Adresse
FF02::4 DVMRP-Router
FF02::5 Alle OSPFv3-Router
FF02::6 OSPFv3 Bezeichnete Router
FF02::a Alle EIGRP (IPv6)-Router
FF02::D Alle PIM-Router
FF02::12 VRRP
FF02::16 Alle MLDv2-fähigen Router

Solicited-node Multicast Address

Eine Solicited-Node-Multicast-Adresse ist eine spezielle Art von IPv6-Multicast

  • Sie wird als effizienterer Ansatz für die IPv4-Broadcast-Zustellung verwendet
  • Eine Solicited-Node-Multicast-Adresse wird automatisch über einen IPv6-Unicast einer Schnittstelle generiert
Solicited-Node-Multicast-Adresse

Wenn eine Schnittstelle mit einer IPv6-Unicast-Adresse konfiguriert wird, wird automatisch eine Solicited-Node-Multicast-Adresse auf der Grundlage der Unicast-Adresse für diese Schnittstelle generiert, und der Knoten tritt der Multicast-Gruppe bei

  • Daher hat jede Unicast-Adresse eine entsprechende Solicited-Node-Multicast-Adresse
  • Diese automatisch generierte Multicast-Gruppe wird dann für die Adressauflösung, die Nachbarschaftserkennung und die Erkennung von Adressduplikaten verwendet

Eine Solicited-Node-Multicast-Adresse aus dem festen Präfix FF02::1:FF00:0/104 und den letzten 24 Bits der entsprechenden IPv6-Adresse

Wie wir bereits gelernt haben, gibt es in IPv6 keinen Broadcast

  • Es gibt auch kein ARP
  • Wenn ein Knoten die MAC-Adresse einer bekannten IPv6-Adresse auflösen muss, muss das Gerät dennoch eine Anfrage senden
  • In diesem Anforderungspaket ist die IPv6-Zieladresse die Multicast-Adresse des angefragten Knotens, die der IPv6-Unicast-Zieladresse entspricht (als Referenz: bei IPv4-ARP ist die Zieladresse 0.0.0.0), und die MAC-Zieladresse ist die Multicast-MAC-Adresse, die der Multicast-Adresse entspricht
  • Nur der Zielknoten "hört" auf diese Multicast-Adresse des angefragten Knotens
  • Daher wird die Anfrage nur vom Zielknoten verarbeitet und nicht von allen an der Verbindung angeschlossenen Knoten, wie es bei Broadcasted ARP in IPv4 der Fall ist
Router#sh ipv6 interface gi0/0/0
GigabitEthernet0/0/0 is up, line protocol is up
 IPv6 is enabled, link-local address is FE80::ABCD:1234
 No Virtual link-local address(es):
 Global unicast address(es):
 2001::1234:ABCD, subnet is 2001::/64
 Joined group address(es):
 FF02::1
 FF02::1:FF34:ABCD
 FF02::1:FFCD:1234
 MTU is 1500 bytes
 ICMP error messages limited to one every 100 milliseconds
 ICMP redirects are enabled
 ICMP unreachables are sent
 ND DAD is enabled, number of DAD attempts: 1
 ND reachable time is 30000 milliseconds

Multicast-Addressen

Multicast-Adressen werden für entsprechende Dienste verwendet

Sie beginnen immer mit (xx ist hierbei der Wert der Reichweite)

Die Adressen werden in Reichweiten und Typen unterteilt:

Multicast-Bereiche

Die Multicast Reichweite ist ein Parameter, mit dem die maximale Distanz angegeben werden kann, die ein Multicast Paket sich von der versendenden Einheit entfernen kann Zurzeit sind folgende Regionen (reichweiten) definiert:

Bereich Beschreibung
ffx1 Node-lokal, Pakete verlassen niemals den Knoten
ffx2 Link-lokal, Pakete werden niemals von Routers weitergeleitet, der angegebene Link wird nie verlassen
ffx5 Site-lokal, Pakete verlassen niemals den Standort (Site)
ffx8 organisationsweit, Pakete verlassen niemals eine Organisation (nicht einfach zu implementieren, dies muss durch das Routing Protokoll abgedeckt werden)
ffxe Globale Reichweite
... Sonstige sind reserviert
Multicast-Typen

Es sind bereits viele Typen definiert bzw. reserviert (siehe RFC 4291 / IP Version 6 Addressing Architecture für weitere Details), einige Beispiele:

  • All Nodes Adresse: ID = 1h, alle Hosts am lokalen Node (ff01:0:0:0:0:0:0:1) oder am angeschlossenen Link (ff02:0:0:0:0:0:0:1) werden adressiert
  • All Routers Adresse: ID = 2h, alle Router am lokalen Node (ff01:0:0:0:0:0:0:2), am angeschlossenen Link (ff02:0:0:0:0:0:0:2) oder am lokalen Standort werden adressiert
Erforderliche node link-local Multicast Adresse

Diese spezielle Multicast Adresse wird als Zieladresse bei der Erkundung des Nahbereichs verwendet, da es ARP bei IPv6 im Gegensatz zu IPv4 nicht mehr gibt

Ein Beispiel für diese Adresse könnte sein:

Das benutzte Präfix zeigt, dass es sich um eine link-lokale Multicast Adresse handelt

  • Dass Suffix wird aus der Zieladresse erstellt
  • In diesem Beispiel soll ein Paket zur Adresse "fe80::1234" gesendet werden, aber die Netzwerk-Schicht hat keine Kenntnis der aktuellen Schicht 2 MAC Adresse
  • Die oberen 104 bits werde mit "ff02:0:0:0:01:ff00::/104" ersetzt und die unteres 24 bits bleiben unverändert
  • Diese Adresse wird nun "am Link" verwendet, um den entsprechenden Node zu finden, der wiederum seine Schicht 2 MAC Adresse als Antwort zurücksendet

Multicast-Adressen

Multicast-Adressen sprechen eine Gruppe von Rechnern an
  • Das ist zum Beispiel für Video on Demand oder Fernunterricht nützlich und spart Bandbreite, da es bereits auf der IP-Schicht ausgewertet wird und mehrfache Übertragung von Paketen verhindert
  • Auch mehrere NTP-Server können einer Multicast-Gruppe angehören
Multicast-Adressen beginnen alle mit der Bitfolge 1111 1111
  • Darauf folgen dei Felder Flag und Scope
  • Bisher ist allerdings nur das Flag T definiert, mit den Werten 1 für dauerhaft und 0 für temporär
Einer-zu-vielen-Kommunikation wird durch Multicast-Adressen abgebildet

Typ: 0000

  • fest definiert (ANA), 0001
  • Adresse wurde "frei" vergeben
Scope
Gültigkeitsbereich 0001 nur lokales Endgerät
Wert Scope
0010 Link lokal
0101 Site lokal
1000 Organisations-lokal
1110 Global
Regel
  1. FF02::1:FF00:0/104 zzgl. letzte 24 Bit der Unicast Adresse
  2. Link-Lokale MC Adresse des Endsystems (für Neighbor Discovery)
Beispiele für Multicast-Adressen
FFO1::1 alle lokalen Interfaces FF02::1 alle Link-lokalen Interfaces
FF05::2 alle Site-Ilokalen Router FF0x::202 Sun RPC

Präfix ff00::/8 (ff…)

stehen für Multicast-Adressen

Nach dem Multicast-Präfix folgen
  • 4 Bit für Flags
  • 4 Bit für den Gültigkeitsbereich (Scope)
Flags sind zurzeit in folgenden Kombinationen gültig
Wert Bezeichnung Beschreibung
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
Weitere Bereiche sind nicht zugewiesen
  • Können von Administratoren benutzt werden, um weitere Multicast-Regionen zu definieren
Wert Scope Beschreibung
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 darf überallhin geroutet werden
0, 3, f reservierte Bereiche
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

Anycast-Adressen

Anycast Adressen

Verschiedene Endgeräte sind unter einer (Anycast-) Adresse erreichbar
  • Auslieferung des Paketes normalerweise an das Interface des Endgerätes, welches (Netztopologie) Routing-mäßig das nächstliegende ist
  • Unterscheidet sich nicht von normaler Unicast-Adresse 4 Anycast Funktionalität ist durch die Router und durch Konfiguration des Endgerätes zu realisieren
  • Derzeit nur für Router oder Server zulässig (Änderung jedoch absehbar)
Anwendungsbeispiele
  • Dienste unter global gleicher Adresse effizient verfügbar (Routing zum PoP)
  • Load Balancing
  • erhöhte Stabilität durch mehrere Router gleicher Adresse
  • Mobile IPv6 Home Agents Anycast (Anycast Id. 126 oder 7E)
Mit Anycast-Adressen erreicht man genau einen aus einer Gruppe von Rechnern
  • die die selbe Anycast-Adresse haben
    • Zum Beispiel einen aus einer Gruppe von Nameservern, oder von Routern bei einem Provider

Anycast Adressen sind spezielle Adressen und werden verwendet, um besondere Bereiche wie den nächstgelegenen DNS-Server, den nächstliegenden DHCP Server und vergleichbare dynamische Gruppen abzudecken

  • Die Adressen werden dem Pool des Unicast Adressraums (global-aggregierbar oder Site-lokal zurzeit) entnommen
  • Der Anycast-Mechanismus (client view) wird von dynamischen Routing-Protokollen gehandhabt

Hinweis: Anycast Adressen können nicht als Quelladresse verwendet werden, sondern ausschließlich als Zieladressen

Subnet-Router Anycast-Adresse

Die Subnet-Router Anycast Adresse ist ein einfaches Beispiel für eine Anycast Adresse

  • Angenommen, der Knoten hat folgende global zugewiesene IPv6 Adresse:

Die Subnet-Router Anycast Adresse wird durch komplette Streichung des Suffixes (die letzten gültigen 64 bits) erstellt:

Anycast

Eine Anycast-Adresse ist eine Kennung der Netzebene, die in der Regel mehr als einer Schnittstelle (einem Satz von Schnittstellen) zugewiesen wird, die zu verschiedenen IPv6-fähigen Knoten gehören

  • Pakete, die an eine Anycast-Adresse gesendet werden, werden an die "nächstgelegene" Schnittstelle zugestellt, die durch diese Adresse identifiziert wird
  • "Am nächsten" bedeutet in der Regel diejenige mit der besten Routing-Metrik gemäß dem IPv6-Routing-Protokoll

Anycast-Adressen werden aus dem Unicast-Adressraum zugewiesen, daher sind sie nicht von globalen Unicast-Adressen zu unterscheiden

  • Wenn dieselbe Unicast-Adresse für mehr als eine Schnittstelle konfiguriert wird, handelt es sich um eine Anycast-Adresse
  • Geräte, denen eine Anycast-Adresse zugewiesen wurde, müssen explizit so konfiguriert werden, dass sie erkennen, dass die Adresse für die Anycast-Kommunikation verwendet wird, wie im folgenden Konfigurationsbeispiel gezeigt
Device(config-if)#ipv6 address 2001:4db8:a541::/128 anycast

Zusammenfassung

Fassen wir alle Arten von IPv6-Adressen zusammen, die wir in dieser Lektion behandelt haben:

Adresse Beschreibung
Global Unicast Derzeit vergibt die IANA globale Unicast-Adressen, die mit dem Binärwert 001 (2000::/3) beginnen
  • Ihre Struktur besteht aus einem 48-Bit-globalen Routing-Präfix und einer 16-Bit-Subnetz-ID, die auch als Site-Level Aggregator (SLA) bezeichnet wird
  • Die Struktur dieser Adressen ermöglicht die Aggregation von Routing-Einträgen, um eine kleinere globale IPv6-Routing-Tabelle zu erhalten
Unique-local Sie haben ein global eindeutiges Präfix, ähnlich wie globale Unicast-Adressen
  • Ihre Struktur ist bekannt (siehe Abbildung 4), was eine einfache Filterung an Standortgrenzen ermöglicht
  • Es handelt sich um einen vom Internetdienstanbieter unabhängigen Adressraum
Loopback Die bekannte Loopback-Adresse in IPv6 lautet ::1/128
  • Ähnliches Konzept wie 127.0.0.0/8 in IPv4
  • Wird in der Regel zum Testen des TCP/IP-Protokollstacks in Betriebssystemen verwendet
Nicht spezifiziert Die nicht spezifizierte Adresse in IPv6 lautet ::/128
  • Ähnliches Konzept wie 0.0.0.0 in IPv4
Eingebettetes IPv4 in IPv6 Die IPv4-Adresse A.B.C.D (in Hexadezimalziffern) wird in IPv6 als 0:0:0:0:0:0:A:B:C:D oder einfach als ::A:B:C:D eingebettet
  • IPv6-Adressen werden in automatischen Tunneln verwendet, die sowohl IPv4 als auch IPv6 unterstützen
Link-local Präfix FE80::/10
  • Wird automatisch jeder IPv6-fähigen Schnittstelle zugewiesen
  • Analog zu 169.254.0.0/16 in IPv4
  • Nicht routbar
  • Sie sind nur im Bereich einer Schnittstelle gültig
  • Wird für die Nachbarerkennung und die zustandslose Autokonfiguration verwendet
Bekannte Multicast-Adressen Alle bekannten Multicast-Adressen beginnen mit dem Präfix ff00::/12
  • Sie haben eine ähnliche Funktion wie 224.0.0.0/24 in IPv4
Solicited-Node-Multicast Jede IPv6-Unicast-Adresse hat eine entsprechende Solicited-Node-Multicast-Adresse
  • Die Struktur besteht aus dem festen Präfix FF02::1:FF00:0/104 und den letzten 24 Bits der entsprechenden IPv6-Adresse
  • Diese speziellen Multicast-Gruppen werden für die Adressauflösung, Nachbarerkennung und Duplikaterkennung verwendet


ICMPv6

IPv6/ICMP - ICMPv6 (Internet Control Message Protocol für IPv6)

Beschreibung

IPv6-Adressauflösung und Netzwerkreichweiten-Ermittlung

ICMPv6 (Internet Control Message Protocol Version 6)
Familie Internetprotokolle
Einsatzgebiet Fehlermeldungen, Diagnose, Autoconfiguration, Routing
Internet-Protokolle im TCP/IP-Protokollstapel
Internet ICMPv6
IPv6
Netzzugang Ethernet Token
Bus 		IEEE
802.11a/b/g/n 		FDDI …
Grundfunktionen
  • Grundlegende Funktionen
  • Rolle des Internet Control Message Protocol Version 6 (ICMPv6) in IPv6-Netzwerken
Fehlererkennung und -meldung
  • Diagnostische Aufgaben
  • Echo-Request und Echo-Reply für Ping-Operationen
ICMPv6-Nachrichten

Funktionsweise

  • Neighbor Discovery (ND)
  • Router Solicitation
  • Router Advertisement
  • Neighbor Solicitation
  • Neighbor Advertisement

Das Internet Control Message Protocol for the Internet Protocol Version 6 (ICMPv6) ist die mit IPv6 zusammen verwendete Version des Internet Control Message Protocol

ICMPv6 zwingend notwendig

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)

ICMPv6 dient als Hilfsprotokoll für IPv6, ist in derselben OSI-Schicht 3 wie dieses angesiedelt und nutzt das IPv6-Protokoll zum Versand von ICMP-Nachrichten

  • Als Protokoll-Nummer wird dabei 58 ins Next-Header-Feld des IPv6-Headers eingefügt

Header

ICMPv6 Header
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 zur Verifizierung der Gültigkeit des ICMPv6-Pakets benutzt

Der restliche Inhalt der ICMP-Nachricht wird durch den jeweiligen Typ bestimmt

  • Bei Fehlernachrichten wird nach den möglichen zusätzlichen Feldern immer noch so viel wie möglich vom fehlerverursachenden Paket angehängt
Prüfsumme
Prüfsummen-Schema
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

Verarbeitung

Regeln für die Verarbeitung von ICMPv6-Nachrichten
  • Unbekannte ICMPv6-Fehlernachrichten müssen an die darüberliegende Netzwerkschicht weitergereicht werden
  • Unbekannte ICMPv6-Informationsnachrichten müssen ohne Benachrichtigung des Absenders 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

Anhang

Siehe auch

RFC

RFC Titel
3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
4604
4861 Neighbor Discovery for IP Version 6 (IPv6)
7112 Implications of Oversized IPv6 Header Chains
8200 Internet Protocol, Version 6 (IPv6) Specification, löst 2460 ab

Links

Weblinks

  1. https://de.wikipedia.org/wiki/ICMPv6
  2. IANA ICMP Parameters - Vollständige Liste der ICMPv6-Typen und -Codes

</noinclude>

IPv6/ICMPv6 Fuktionen

Upper Layer Protokolle

IPv6/Upper Layer Protokolle

Beschreibung

Änderungen in höheren Protokollschichten (Dual Stack)

Untersuchung der Anpassungen in höheren Protokollschichten

  • die durch die Einführung von IPv6 notwendig wurden
  • insbesondere im Kontext der Dual-Stack-Implementierung
  • bei der Geräte gleichzeitig IPv4 und IPv6 unterstützen

Dieser Abschnitt beleuchtet

  • Anwendungen und Netzwerkprotokolle modifiziert wurden, um mit beiden IP-Versionen zu arbeiten
  • Herausforderungen, die sich aus der Notwendigkeit der gleichzeitigen Unterstützung ergeben

Es wird besprochen

  • wie Software und Netzwerkausrüstungen angepasst werden müssen
  • um nahtlos zwischen IPv4 und IPv6 wechseln zu können
  • und welche speziellen Anpassungen für Protokolle wie HTTP, SMTP und FTP erforderlich sind, um eine vollständige Funktionalität über beide Protokollversionen zu gewährleisten

DNS

Bedeutung von DNS

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

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 beispielsweise 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


Sicherheit

IPv6/Sicherheit - Sicherheit von IPv6-Knoten

Beschreibung

Empfehlungen
Beschreibung
1 Patches einspielen
2 Dienste deaktivieren
3 Firewall aktivieren
4 Dienste nur an benötigte IPv4/IPv6 Adressen binden

tcp_wrapper

Zugangsbeschränkungen
  • Viele Dienste setzen die tcp_wrapper Bibliothek für die Zugangskontrolle ein
  • Eine Beschreibung finden Sie unter use of tcp_wrapper

Sicherheitsüberwachung

  • Aktuell gibt es keine komfortablen Sicherheitstools mit denen man ein System über ein Netzwerk nach IPv6 relevanten Sicherheitslücken hin überprüfen kann
  • Weder Nessus noch irgendein kommerzieller Security Scanner ist zur Zeit dazu in der Lage, IPv6-Adressen scannen zu können

Rechtsfragen

ACHTUNG
Bitte stellen Sie immer sicher, dass Sie ausschließlich ihr eigenes Netzwerk scannen oder einen Scan nur nach Erhalt einer schriftlichen Erlaubnis durchführen.
  • Andernfalls haben sie mit rechtlichen Konsequenzen zu rechnen! ÜBERPRÜFEN Sie die Ziel-IPv6-Adresse ZWEIMAL, bevor Sie einen Scan starten

Sicherheitsüberwachung


QoS

IPv6/QoS - IPv6 - Quality of Service

Beschreibung

IPv6 unterstützt QoS durch die Anwendung von Flow Labels und Traffic Classes.

Vernünftig funktionierendes QoS ist nur an der ausgehenden Schnittstelle eines Routers oder Host möglich, wo der Flaschenhals anfängt. Alles andere bereitet nur Probleme und funktioniert wahrscheinlich nicht so, wie erwartet.



Router

topic - Beschreibung

Beschreibung

Migration

IPv6/Migration - Umstieg von IPv4 auf IPv6

Beschreibung

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 Mechanismen
Übergangstechnologie Beschreibung
Parallelbetrieb
Tunnel
Übersetzen

Parallelbetrieb und Tunnelmechanismen setzten voraus, dass die Betriebssysteme der angebundenen Rechner beide Protokolle beherrschen.

  • Es gibt bereits heute Bereiche des Internet, die ausschließlich mittels IPv6 erreichbar sind
  • Andere Teile, die über beide Protokolle angebunden sind und große Teile, die sich ausschließlich auf IPv4 verlassen.

Parallelbetrieb

Verfahren Beschreibung
Dual Stack Netzknoten mit IPv4 und IPv6
Dual Stack Lite Dual-Stack mit globaler IPv6 und Carrier-NAT IPv4

Tunnel

Verfahren Beschreibung
4in6 IPv4 in IPv6
6in4 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 (veraltet)
AYIYA Anything In Anything
6rd IPv6 rapid deployment
ISATAP Intra-Site Automatic Tunnel Addressing Protocol (veraltet)
Teredo Kapselung von IPv6-Datenpaketen in IPv4-UDP-Datenpaketen

Übersetzung

Verfahren Beschreibung
NAT64 IPv4-Adressen in IPv6-Adressen
464XLAT IPv4- in IPv6- in IPv4-Adressen


Firewall

Skript/Netzwerk/IPv6 - Beschreibung

Beschreibung

Regeln Client

* mangle
 : PREROUTING ACCEPT [ : ]
 : INPUT ACCEPT [ : ]
 : FORWARD ACCEPT [ : ]
 : OUTPUT ACCEPT [ : ]
 : POSTROUTING ACCEPT [ : ]
 COMMIT
 #
 * filter
 : INPUT DROP [ : ]
 : FORWARD DROP [ : ]
 : OUTPUT ACCEPT [ : ]
 : ndp-slaac - [ : ]
 : trashlog - [ : ]
 -A INPUT -i lo -j ACCEPT
 -A INPUT -m conntrack -- ctstate INVALID -j trashlog
 -A INPUT -m conntrack -- ctstate RELATED , ESTABLISHED -j ACCEPT
 -A INPUT -p ipv6-icmp -j ndp-slaac
 -A INPUT -s fe80::/1 -d fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 128 -m conntrack -- ctstate NEW -j ACCEPT
 -A INPUT -s fe80::/1 -p tcp -m tcp -- dport 22 -m conntrack -- ctstate NEW -j ACCEPT
 -A OUTPUT -o lo -j ACCEPT
 -A ndp-slaac -p ipv6-icmp -m icmp6 --icmpv6-type 133 -m hl --hl-eq 255 -j ACCEPT
 -A ndp-slaac -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT
 -A ndp-slaac -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
 -A ndp-slaac -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
 -A ndp-slaac -p ipv6-icmp -m icmp6 --icmpv6-type 137 -m hl --hl-eq 255 -j ACCEPT
 -A ndp-slaac -p ipv6-icmp -m icmp6 --icmpv6-type  13 -m hl --hl-eq   1 -j ACCEPT
 -A ndp-slaac -p ipv6-icmp -m icmp6 --icmpv6-type 131 -m hl --hl-eq   1 -j ACCEPT
 -A ndp-slaac -p ipv6-icmp -m icmp6 --icmpv6-type 132 -m hl --hl-eq   1 -j ACCEPT
 -A ndp-slaac -p ipv6-icmp -m icmp6 --icmpv6-type 143 -m hl --hl-eq   1 -j ACCEPT
 -A trashlog -j LOG -- log - prefix " TRASHLOG : " --log - level 5
 -A trashlog -j DROP
 COMMIT

Regeln Router

* mangle
: PREROUTING ACCEPT [ : ]
: INPUT ACCEPT [ : ]
: FORWARD ACCEPT [ : ]
: OUTPUT ACCEPT [ : ]
: POSTROUTING ACCEPT [ : ]
COMMIT
#
* filter
: INPUT DROP [ : ]
: FORWARD DROP [ : ]
: OUTPUT ACCEPT [ : ]
: bad - eh - [ : ]
: icmpv6-filter - [ : ]
: ndp-minimal - [ : ]
: trashlog - [ : ]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack -- ctstate RELATED , ESTABLISHED -j ACCEPT
-A INPUT -m conntrack -- ctstate INVALID -j trashlog
-A INPUT -p ipv6-icmp -j ndp-minimal
-A INPUT -i eth1 -p ipv6-icmp -m icmp6 --icmpv6-type 133 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -i eth1 -p udp -m udp -- dport 53 -m conntrack -- ctstate NEW -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp -- dport 53 -m conntrack -- ctstate NEW -j ACCEPT
-A FORWARD -m conntrack -- ctstate RELATED , ESTABLISHED -j ACCEPT
-A FORWARD -p ipv6-icmp -j icmpv6-filter
-A FORWARD -i eth1 -o sixxs -m conntrack -- ctstate NEW -j ACCEPT
-A FORWARD -i eth1 -o nat64 -m conntrack -- ctstate NEW -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A bad - eh -m rt --rt - type --rt - segsleft -j DROP
-A icmpv6-filter -s fe80::/1 -j DROP
-A icmpv6-filter -d fe80::/1 -j DROP
-A icmpv6-filter -s 2a01:198:200:8a23::/64 -p ipv6-icmp -m icmp6 --icmpv6-type 128 -m conntrack -- ctstate NEW -j ACCEPT
-A icmpv6-filter -d 2a01:198:200:8a23:200:ff:fe60:d1e/128 -p ipv6-icmp -m icmp6 --icmpv6-type 128 -m conntrack -- ctstate NEW -j ACCEPT
-A icmpv6-filter -d ff00::/8 -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j DROP
-A icmpv6-filter -s 2a01:198:200:8a23::/64 -p ipv6-icmp -m icmp6 --icmpv6-type 2   -j ACCEPT
-A icmpv6-filter -s 2a01:198:200:8a23::/64 -p ipv6-icmp -m icmp6 --icmpv6-type 3/1 -j ACCEPT
-A icmpv6-filter -s 2a01:198:200:8a23::/64 -p ipv6-icmp -m icmp6 --icmpv6-type 4/0 -j ACCEPT
-A icmpv6-filter -s 2a01:198:200:8a23::/64 -p ipv6-icmp -m icmp6 --icmpv6-type 4/1 -j ACCEPT
-A icmpv6-filter -s 2a01:198:200:8a23::/64 -p ipv6-icmp -m icmp6 --icmpv6-type 4/2 -j ACCEPT
-A icmpv6-filter -s 2a01:198:200:8a23::/64 -p ipv6-icmp -m icmp6 --icmpv6-type 1   -j ACCEPT
-A icmpv6-filter -s 2a01:198:200:8a23::/64 -p ipv6-icmp -m icmp6 --icmpv6-type 3/0 -j ACCEPT
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 133 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 134 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 137 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type  13 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 143 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 147 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 139 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type  14 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 144 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 145 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 146 -j DROP
-A icmpv6-filter -p ipv6-icmp -m icmp6 --icmpv6-type 147 -j DROP
-A icmpv6-filter -j DROP
-A ndp-minimal -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A ndp-minimal -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A ndp-minimal -p ipv6-icmp -m icmp6 --icmpv6-type 137 -m hl --hl-eq 255 -j ACCEPT
-A ndp-minimal -p ipv6-icmp -m icmp6 --icmpv6-type  13 -m hl --hl-eq   1 -j ACCEPT
-A ndp-minimal -p ipv6-icmp -m icmp6 --icmpv6-type 131 -m hl --hl-eq   1 -j ACCEPT
-A ndp-minimal -p ipv6-icmp -m icmp6 --icmpv6-type 132 -m hl --hl-eq   1 -j ACCEPT
-A ndp-minimal -p ipv6-icmp -m icmp6 --icmpv6-type 143 -m hl --hl-eq   1 -j ACCEPT
-A trashlog -j LOG -- log - prefix " TRASHLOG : " --log - level 5
-A trashlog -j DROP
COMMIT

Tunnel

topic - Beschreibung

Beschreibung

Ein Tunnelbroker ist im Bereich der Computernetzwerke ein Dienst, der Tunnel bereitstellt, die zum Beispiel dazu genutzt werden können, Verkehr gesichert (Virtual Private Network) oder verkapselt zu transportieren, um beispielsweise IPv6 über ein IPv4-Netzwerk zu transportieren

Obwohl es mehrere Arten von Tunnelbrokern gibt, werden damit meist Broker bezeichnet, die Tunnel bereitstellen, die es ermöglichen, IPv6-Pakete über alte IPv4-Infrastruktur zu routen (RFC 3053), allerdings kann es auch IPv4-Tunnelbroker geben, die IPv4-Pakete über IPv6-Infrastruktur leiten

  • Um IPv6 über IPv4 zu leiten, werden verschiedene Methoden wie 6in4, 6over4, 6to4 oder 6rd verwendet
  • Heutzutage wird häufig Dual-Stack verwendet, bei dem sowohl IPv4 und IPv6 unabhängig voneinander verwendet werden

Automatische Konfiguration

Normalerweise werden IPv6-Tunnel über das Tunnel Setup Protocol oder Tunnel-Information-Control-Protokoll konfiguriert und erstellt

  • Oft wird ein Tunnel jedoch manuell konfiguriert

Probleme mit Network Address Translation und Routern

Protokoll-41-Tunnel, wobei IPv6 direkt in IPv4 verpackt wird, funktionieren hinter NATs eventuell nicht mehr zuverlässig
Protokoll 41 in Wireshark
  • Mit vielen modernen Routern gibt es allerdings keine Probleme
  • Umgehen kann man auftretende Probleme, indem man den Endpunkt entweder in eine Demilitarisierte Zone legt oder gleich auf das NAT-Gerät; moderne Router für den Heimeinsatz, die IPv6-fähig sind, unterstützen dies inzwischen
  • Ebenfalls möglich ist der Gebrauch von AYIYA oder TSP (Tunnel Setup Protocol), die IPv6-Pakete in UDP-Pakete verpacken
  • Diese können die meisten Firewalls problemlos passieren (vorausgesetzt, es gibt keine verbietende Regel)
Ein Problem, das immer noch auftreten kann, ist, dass eine NAT-Regel aus der Tabelle entfernt wird, obwohl die Verbindung noch besteht
  • Falls dann von außen Pakete für den Tunnel ankommen, kann der Router diese nicht mehr weiterleiten und verwirft sie
  • Das unterbricht die Tunnelverbindung, bis der Nutzer wieder ein Paket durch den Tunnel sendet
Ältere (Heim-)Router routen teilweise generell keine Protokoll-41-Pakete

Dynamische Endpunkte

Falls der Client-Endpunkt des Tunnels eine dynamische IP-Adresse besitzt (wie bei Privatkunden-Breitbandanschlüssen), dann muss der Kunde den Tunnelbroker immer bei einer Änderung über die neue IP-Adresse informieren

  • Das geschieht entweder manuell über die Website des Tunnelbrokers oder über ein automatisches Protokoll wie TSP oder Heartbeat

Andere Tunnelbroker erlauben eine komfortable webbasierte Lösung, bei der eine vorgegebene URL aufgerufen wird, in der Nutzername, Passwort und der Hostname oder die ID des Tunnels enthalten sind. Über die IP des Aufrufers (der Server für diese Lösung ist über IPv4 angebunden) kann der Endpunkt aktualisiert werden

tunnelbroker.net

Hurricane Electric bietet einen kostenlosen tunnel broker Dienst an, der unter Arch relativ einfach zu benutzen ist, wenn Sie einem IPv4-Host IPv6-Konnektivität hinzufügen möchten

Registrierung für einen Tunnel

Gehen Sie auf die Tunnelbroker-Site und füllen Sie die Registrierung aus

Einrichten des Hurricane Electric-Tunnels

Erstellen Sie die folgende systemd-Unit und ersetzen Sie den fettgedruckten Text durch die IP-Adressen, die Sie von HE erhalten haben
Hinweis
Wenn Sie sich hinter einem NAT befinden (typische Heimrouter-Einrichtung), verwenden Sie Ihre lokale IPv4-Adresse für client_IPv4_address, beispielsweise 192.168.0.2
/etc/systemd/system/he-ipv6.service
[Einheit]
Beschreibung=he.net IPv6-Tunnel
Nach=network.target

[Service]
Typ=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/ip tunnel add he-ipv6 mode sit remote server_IPv4_address local client_IPv4_address ttl 255
ExecStart=/usr/bin/ip link set he-ipv6 up mtu 1480
ExecStart=/usr/bin/ip addr add client_IPv6_address dev he-ipv6
ExecStart=/usr/bin/ip -6 route add ::/0 dev he-ipv6
ExecStop=/usr/bin/ip -6 route del ::/0 dev he-ipv6
ExecStop=/usr/bin/ip link set he-ipv6 down
ExecStop=/usr/bin/ip tunnel del he-ipv6

[Install]
WantedBy=multi-user.target
Dann start/enable he-ipv6.service

systemd-networkd

Wenn systemd-networkd Ihre Netzwerkverbindungen verwaltet, ist es wahrscheinlich eine bessere Idee, ihn auch den Tunnelbroker verwalten zu lassen (anstatt eine .service-Datei zu verwenden)
/etc/systemd/network/he-tunnel.netdev
[Match]

[NetDev]
Name=he-ipv6
Kind=sit
MTUBytes=1480

[Tunnel]
Lokal=<lokale IPv4>
Entfernt=<Tunnel-Endpunkt>
TTL=255
/etc/systemd/network/he-tunnel.network
[Match]
Name=he-ipv6

[Netzwerk]
Adresse=<lokale IPv6>
Gateway=<IPv6-Gateway>
DNS=2001:4860:4860::8888
DNS=2001:4860:4860::8844

Und fügen Sie diese Zeile in den Abschnitt "[Network]</nowiki>" Ihrer Standard-Internetverbindungsdatei "'.network" ein 

Tunnel=he-ipv6

Verwendung des Tunneling mit dynamischer IPv4 IP

Aktualisierung über Cronjob

Der einfachste Weg, das Tunneln mit einer dynamischen IPv4-IP zu nutzen, besteht darin, einen Cronjob einzurichten, der Ihre aktuelle Adresse regelmäßig aktualisiert
  • Die Beispiel-URL und einen Update Key finden Sie auf der Registerkarte Advanced der Seite Tunnel Details
Um zu überprüfen, ob die Aktualisierung funktioniert, führen Sie den folgenden Befehl aus (ersetzen Sie USERNAME, UPDATEKEY und TUNNELID durch die Angaben zu Ihrem Konto und Ihrem Tunnel)
wget -O - https://USERNAME:UPDATEKEY@ipv4.tunnelbroker.net/nic/update?hostname=TUNNELID
Wenn es funktioniert, erstellen Sie einen Cronjob, indem Sie crontab -e öffnen und eine neue Zeile hinzufügen
*/10 * * * * wget -q -O /dev/null https://USERNAME:UPDATEKEY@ipv4.tunnelbroker.net/nic/update?hostname=TUNNELID

Aktualisieren über ddclient

Alternativ kann dies auch durch die Installation von ddclient und die Konfiguration von /etc/ddclient.conf konfiguriert werden
protocol=dyndns2
use=web
web=checkip.dns.he.net
server=ipv4.tunnelbroker.net
ssl=ja
anmeldung=BENUTZERNAME
passwort=UPDATEKEY
TUNNELID

Und schließlich start/enable ddclient.service

Setting up a tunnelbroker.net IPv6 tunnel on Debian

Things you need to find out first

The IP address you plan to use the tunnel from (e.g. your current IP, or the IP of the server you want to set this up on) - $yourip

Getting a tunnelbroker account

  • Hit the registration page and sign up
  • Wait for the confirmation email, then login
  • From the (left-hand-side) "User Functions" menu click "Create Regular Tunnel"
  • Enter the IP you want to use the tunnel from
  • Pick a host near the machine with that IP - the closer it is, the shorter the path your IPv6 packets will have to take to hit the IPv6 Internet

Configure your machine to use the tunnel

Pick a name for the tunnel - it is just used as the interface name on Linux. Let’s say sit1. Now click on the your new tunnel, and you’ll be on the "Tunnel details" page

Open up /etc/network/interfaces: 

auto sit1
iface sit1 inet6 v4tunnel
    address $address
    netmask 64
    local $yourip
    endpoint $endpoint
    up ip route add 2000::0/3 via $theirip dev sit1

Where:

$address is the value of "Client IPv6 address"

$yourip is the local IP address

$endpoint is the value of "Server IPv4 address"

$theirip is the value of "Server IPv6 address", with the /64 removed

Test

Ping

Make sure iputils-ping is installed (sudo aptitude install iputils-ping, if it isn’t), then try ping6 www.kame.net in a terminal:: 

PING www.kame.net(orange.kame.net) 56 data bytes
64 bytes from orange.kame.net: icmp_seq=1 ttl=54 time=126 ms

Web

If you are setting this up on your desktop, visit Kame using your browser. If this is on a server, use ssh -D1027 yourserver (via ipv4, of course) on your local machine to create a SOCKS proxy, tell your browser to use localhost:1027 as a SOCKS proxy, then visit Kame in your browser. If the tortoise is dancing, you’re done

  1. https://ertius.org/docs/ipv6-tunnel-on-debian/

IPv6 Tunnel unter Debian mit Tunnelbroker.net

Da es ja bald (TM) nur noch IPv6 Adressen gibt, wollte ich damit schon mal frühzeitig etwas herumspielen

Die Frage war nur wie, den natives IPv6 bekommt man nicht von jedem Provider, und als privater DSL Nutzer schon mal garnicht

  • Aber eine Lösung gibt es dennoch, sie heißt IPv6 Tunnel
  • Dabei wird der komplett IPv6 Traffic in IPv4 Pakete verpackt und zu einem Tunnelserver geschickt, der das ganze Entpackt und ins IPv6 Internet weiterleitet
  • Insgesamt eine schöne Sache, und es gibt kostenlose Dienste die einen solchen Service anbieten
  • Einer ist tunnelbroker.net, hier kann man sich Registrieren und bekommt dann Ipv6 Adressen und die Daten zu einem Tunnel Server

Einrichtung Debian

/etc/network/interfaces  folgenden Eintrag hinzugefügt: 

#IPv6 TUNNEL
auto 6in4
iface 6in4 inet6 v4tunnel
   address 2001:470:1f0a:cf7::2 #Zugewiesene Addresse des eigenen Endpunkts
  netmask 64
  endpoint 216.66.80.30 #IPv4 Adresse des Tunnelservers auf der anderen Seite
  gateway 2001:470:1f0a:cf7::1 # IPv6 Adresse des Tunnelservers der anderen Seite
  up ip route add ::/0 dev 6in4

Dann speichern und man kann danach mit 

ifup 6in4 #Tunnel anfahren
ifdown 6in4 #Tunnel herrunterfahren


Subnetting

IPv6/Subnetting - IPv6-Adressen mit Subnetzmasken in Netz- und Host-Teil unterteilen

Beschreibung

Wie bei IPv4 können IPv6-Adressen mittels Subnetzmasken (subnet masks) in einen Netz- und einen Host-Teil unterteilt werden

Präfixlängen für das Routing

Um eine maximale Reduktion an Routing-Tabellen zu erzielen, war in der frühen Design-Phase noch ein vollkommen hierarchischer Routing-Ansatz vorgesehen

  • Die Überlegungen hinter diesem Ansatz waren die gegenwärtigen IPv4 Routing-Einträge in den Haupt-Routern (mit über 400.000 Einträgen im Jahr 2013) sowie die Reduktion des Speicherbedarfs für die Routing-Tabellen bei Hardware-Routern (ASIC "Application Specified Integrated Circuit", speziell konstuierter Chip) sowie ein daraus resultierender Geschwindigkeitszuwachs (weniger Einträge ergeben hoffentlich schnellere Abfragen)

Heutiger Standpunkt ist, dass das Routing für Netzwerke mit nur einem Service Provider hauptsächlich mit einem hierarchischen Design realisiert wird

  • Eine solche Vorgehensweise ist nicht möglich, wenn mehr als eine ISP-Verbindung besteht
  • Diese Problematik wird unter dem Thema multi-homing diskutiert (Infos zu multi-homing: drafts-ietf-multi6-*,IPv6 Multihoming Solutions)

Präfixlängen (netmasks)

Vergleichbar zu IPv4, handelt es sich hierbei um den routbaren Netzwerkpfad für das stattfindende Routing

  • Da die Standard-Notierung der Netzmaske von 128 bit nicht sehr fein aussieht, verwenden die Designer das aus IPv4 bekannte Classless Inter Domain Routing Schema (CIDR, RFC 1519 / Classless Inter-Domain Routing)
  • Mit Hilfe des CIDR wird die Bitanzahl der IP Adresse festgelegt, welche für das Routing verwendet werden
  • Diese Methode wird auch als "Slash"-Notation genannt
Beispiel

Diese Notation wird erweitert zu

  • Netzwerk
  • Netzmaske

Zutreffende Routen

Im Normalfall (ohne QoS) ergibt eine Suche in der Routing-Tabelle eine Route mit der signifikantesten Adress-Bit-Anzahl, d. h. jene Route mit der größten Präfix-Länge wird zuerst herangezogen

Wenn beispielsweise eine Routing-Tabelle folgende Einträge zeigt (Liste ist nicht komplett)

Die gezeigten Zieladressen der IPv6 Pakete werden über die entsprechenden Geräte geroutet


TMP

Pv6/Windows/IPv6 Subnetz

Beschreibung

IPv6 Subnetz

Was ist das Richtige für mich?

Es gibt einen Standard-IPv6-Bereich, der vergleichbar mit dem private Class A / B / C Netzen von IPv4 ist, eine sog. Site local address. Übrigens, die Link local address (fe80::/64) ist mit der 169.254.0.0/16 bei IPv4 vergleichbar.

  • Wenn man also noch keine offizielle, von der IETF oder dem ISP zugewiesene IPv6 hat, sollte auch nicht auf die Idee kommen irgendeine zu verwenden.
  • Das macht früher oder später nur Probleme und man muss erneut umstellen.
Site local Adresse

Folgende Site local Adresse ist frei verfügbar 

Site local: fec0::
Subnetz prefix length: 64

Gleiches Netz, andere Schreibweise 

Address prefix: fec0::/64

Man könnte auch ein anderes Subnetz innerhalb von fec0 verwenden, allerdings bevorzuge ich kurze Schreibweisen.

Beispiel für ein Subnetz wäre 

fec0:0:0:1::
Übersicht über alle Adressen

Testumgebung

Server A
  • Windows 2008 R2
  • AD, DNS
  • IPv6: fec0::3
Server B
  • Windows 2008 R2
  • DHCP
  • IPv6: fec0::2
Client
    • Windows 7
    • IPv6: DHCP (beispielsweise fec0::aaaa)

In dieser Umgebung gibt es keinen IPv6 fähigen Router und damit auch kein Gerät was per Router Discovery gefunden wird

Statische IPv6 vergeben

Nachdem IPv6 mittlerweile standardmäßig aktiv ist, muss man in den Protokolleigenschaften lediglich eine statische IP-Adresse eintragen, hier am Server B:

"image"

Server A erhält die IP fec0::3.     

Über ping -6 fec0::3 kann man die IPv6 Konnektivität von A nach B überprüfen (wenn ich den Parameter -6 nicht angebe, versucht Windows es zuerst über IPv6. Mit dem Parameter erzwingt man das Ganze):

"image"

Konfiguration DHCP-Server

Während der Installation der DHCP-Server Rolle, wird man gefragt, ob man den DHCP im Stateless oder Stateful Modus betreiben möchte, für diesen Verwendungszweck ist Stateful die richtige Wahl.

DHCP-Bereich 

fec0:: /64

Ausnahmen

  • fec0::ffff bis fec0::ffff:ffff:ffff:ffff (ich möchte dass meine Clients möglichst kurze Adressen bekommen, und 65.000 IP's reichen mir)
  • fec0::1 bis fec0::20 (meine statischen IPv6 Adressen sind im Bereich 1-20, deshalb soll dieser nicht per DHCP vergeben werden)

Server Options

  • 00023 DNS Recursive Name Server IPv6 Addresss: fec0::3

Wenn ich jetzt am Client meine IPv6 Adresse per ipconfig /renew6 erneuere, bekomme ich beispielsweise fec0::aaaa

Starte ich einen ping vom Client zum Server (ping -6 fec0::3) kann es passieren, dass ich nur PING: transmit failed. General failure. Bekomme. Als nächstes sollte man den ping über link local Adresse (fe80::/64) versuchen, das sollte klappen. In diesem Fall hilft der nächste Schritt.

Zusätzliche Konfiguration am DHCP-Server

An dieser Stelle scheitert man ganz gerne. IPv6 ist auf das sog. Router Advertisement angewiesen, damit ein Routing im Netzwerk möglich ist. Nun steht uns aber kein IPv6 fähiger Router zur Verfügung, d.h. der DHCP-Server soll diese Aufgabe übernehmen. Dazu sind ein paar Kniffe über netsh notwendig. Ohne das Router Advertisement bekommt der Client auch keine Route ins eigene Netz zugewiesen. Über den folgenden Befehl kann man sich die Routen anzeigen lassen: 

netsh int ipv6 show route

Hier fehlt fec0:: - unser neues Netz.

Damit es als Route hinzugefügt wird, muss man am DHCP-Server folgendes konfigurieren: # Auf der Netzwerkkarte Advertise=enabled setzen

  1. Für die entsprechende Route, also fec0::, die Eigenschaft publish=enabled setzen
Schritt 1
  • Man muss die ID der betroffenen Netzwerkkarte herausfinden: netsh int ipv6 show int
  • Anschließend muss Advertise=enabled gesetzt werden: netsh int ipv6 set int <ID> advertise=enabled   // optional noch: rou=en (das sollte schon enabled sein)
Schritt 2
  • Anschließend die Route hinzufügen: netsh int ipv6 add route fec0::/64 publish=enabled
  • Falls es die schon gibt, kann man die Eigenschaft publish wie folgt ändern: netsh int ipv6 set route fec0::/64 publish=enabled
  • Update, mit einem Service Pack hat sich scheinbar der Syntax geändert, beispielsweise: netsh int ipv6 set route fec0::/64 "LAN" publish=yes

"image"

Anschließend sollte ein ping vom Client zu Server A & B möglich sein. Alle weiteren IPv6 fähigen Clients können dann ohne zusätzliche Konfiguration über IPv6 kommunizieren.

Troubleshooting

Troubleshooting Tools

Wertvolle Helfer auf der Kommandozeile, die speziell auf IPv6 losgehen 

ping -6 <hostname>
tracert -6 <hostname>
ipconfig /release6
ipconfig /renew6
netsh int ipv6 show int
netsh int ipv6 show int <ID>
netsh int ipv6 show route


Abgerufen von „https://wiki.foxtom.de/index.php?title=Skript/Netzwerk/IPv6&oldid=126090“