Version vom 14. Juli 2023, 21:28 Uhr

Beschreibung

Adressaufbau von IPv6

IPv6-Adressen sind 128 Bit lang

Präfix: Ersten 64 Bit
Suffix: Letzten 64 Bit
- Interface-Identifier

Netzwerkschnittstellen können unter mehreren IP-Adressen erreichbar sein

link-lokalen Adresse
global eindeutigen Adressen

Interface-Identifier

Ein Interface-Identifier kann damit Teil mehrerer IPv6-Adressen sein
welche mit verschiedenen Präfixen auf dieselbe Netzwerkkarte gebunden sind
Insbesondere gilt dies auch für Präfixe möglicherweise verschiedener Provider
- dies vereinfacht Multihoming-Verfahren

Adressnotation

Binäre Darstellung einer IPv6-Adresse

0010   0000   0000   0001   0000   1101   1011        1000
0000   0000   0000   0000   0000   0000   0000        0000
0000   0000   0000   0000   0000   0000   0000        0000
0000   0000   0000   0000   0000   0000   0000        0001

Hexadezimalzahl Darstellung einer IPv6-Adresse

2001:0DB8:0000:0000:0000:0000:0000:0001

RFC 4291

Notation von IPv6-Adressen

Hexadezimale Notation
Acht Blöcke je 4 Nibble

Mit Doppelpunkten getrennt

2001:0db8:85a3:08d3:1319:8a2e:0370:7344

Führende Nullen dürfen ausgelassen werden

2001:0db8:0000:08d3:0000:8a2e:0070:7344

ist gleichbedeutend mit

2001:db8:0:8d3:0:8a2e:70:7344

Aufeinander folgende 0-Blöcke werden durch: : ersetzt

2001:0db8:0:0:0:0:1428:57ab

ist gleichbedeutend mit

2001:db8::1428:57ab

RFC 4291

Adressnotation

Einbettung eines IPv4-Adressraums in den IPv6-Adressraum
Die letzten vier Byte können dezimal notiert werden

::ffff:127.0.0.1

ist eine alternative Schreibweise für

::ffff:7f00:1

RFC 5952

Darstellung für und zwischen Menschen

Schreibweisen nach RFC 4291

2001:db8:0:0:1:0:0:1
2001:0db8:0000:0000:1:00:0:1
2001:db8::1:0:0:1
2001:db8::0:1:0:0:1
2001:0db8::0:1:0:0:1
2001:db8:0:0:1::1
2001:db8:0000:0:1::1
2001:DB8:0:0:1::1
2001:DB8:0:0:1::1

RFC 5952
Darstellung für und zwischen Menschen

RFC 5952

Verbindliche Regeln zur Notation

Verbindliche Regeln zur Notation und Darstellung fest

für und zwischen Menschen

1. Führende Nullen müssen weggelassen werden

      2001:0db8:00::001 → 2001:db8::001
      2001:0db8:00::001 → 2001:db8::1

2. Zwei Doppelpunkte müssen die größtmögliche Anzahl von Null-Blöcken kürzen

      2001:db8:0:0:0:0:0:1 → 2001:db8::0:1
      2001:db8:0:0:0:0:0:1 → 2001:db8::1

3. Zwei Doppelpunkte dürfen nicht zur Kürzung eines alleinstehenden Null-Blocks benutzt werden

      2001:db8:0:1:1:1:1:1 → 2001:db8::1:1:1:1:1
      2001:db8:0:1:1:1:1:1 → 2001:db8:0:1:1:1:1:1

4. Bei gleichwertigen Möglichkeiten zur Kürzung ist die erste von links zu wählen

      2001:db8:0:0:1:0:0:1 → 2001:db8:0:0:1::1
      2001:db8:0:0:1:0:0:1 → 2001:db8::1:0:0:1

5. Alphabetische Zeichen werden klein geschrieben

      2001:DB8::1
      2001:db8::1

6. Bei der Angabe von Port-Nummern wird die Adresse in eckige Klammern geschrieben

      2001:db8::1:80
      [2001:db8::1]:80

RFC 5952

Verbindliche Regeln zur Notation

URL-Notation
In einer URL wird die IPv6-Adresse in eckige Klammern eingeschlossen

 http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]/

verhindert die Interpretation von Portnummern als Teil der IPv6-Adresse

 http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:8080/

RFC 5952

Verbindliche Regeln zur Notation

Netznotation
IPv6-Netzwerke werden in der CIDR-Notation aufgeschrieben

Dazu werden die erste Adresse (bzw. die Netzadresse) und die Länge des Präfixes in Bit

getrennt durch einen Schrägstrich notiert.

Zum Beispiel steht

2001:0db8:1234::/48

für das Netzwerk mit den Adressen

2001:0db8:1234:0000:0000:0000:0000:0000
bis
2001:0db8:1234:ffff:ffff:ffff:ffff:ffff

Die Größe eines IPv6-Netzwerkes

(oder Subnetzwerkes) im Sinne der Anzahl der vergebbaren Adressen in diesem Netz muss

eine Zweierpotenz sein.

Ein einzelner Host

Da ein einzelner Host auch als Netzwerk mit einem 128 Bit langen Präfix betrachtet werden

kann, werden Host-Adressen manchmal mit einem angehängten „/128“ geschrieben.

Adress-Repräsentation

IPv6-Adressnotation

Zusammenfassung

Interface Identifiers

Aufbau und automatische Erzeugung

Bei dem 64 Bit langen IPv6-Interface Identifier handelt es sich um die Link Layer Adresse

(OSI-Modell Schicht 2), d.h. der MAC-Adresse, der Schnittstelle.

Dazu wird das 64 Bit lange, genormte IEEE EUI-64 Adressformat in einer leicht abgeänderten

Form verwendet.

Durch Invertierung des u-Bits wird die Konfiguration von Hand erleichtert.
Bei den folgenden Darstellung der Adresse handelt es sich um die kanonische Sichtweise in der

ISO/OSI-Modell Schicht 2.

u Kennzeichnung:

„1“ = universal : weltweit eindeutige Adresse
„0“ = local : lokal eindeutige Adresse

g Kennzeichnung:

„1“ = group : Gruppen-/Multicast-Adresse
„0“ = individual : Einzel-Adresse

c durch IEEE festgelegte Bits die den Interface-Hersteller

kennzeichnen

x durch Interface-Hersteller vergebene Adressbit

Abbildungsvorschriften

IEEE EUI-64 Adresse (64 Bit) => IPv6-Interface ID Adresse (64 Bit)
IEEE 802.3 MAC-Adresse (48 Bit) => IPv6-Interface ID Adresse (64 Bit)

IEEE EUI-64 Adresse (64 Bit) => IPv6-Interface ID Adresse (64 Bit)

Alle 64 Bit der IEEE EUI-64 Adresse werden übernommen

Es wird lediglich das u-Bit invertiert.
Beispiel
- IEEE EUI-64 Adresse (64 Bit) => IPv6-Interface ID Adresse (64 Bit)

IEEE EUI-64 Adresse (64 Bit)                         7834:1234:ABCD:5678
IPv6-Interface ID Adresse (64 Bit)                        7A34:1234:ABCD:5678

IEEE 802.3 MAC-Adresse (48 Bit) => IPv6-Interface ID Adresse (64 Bit)

Bei der Abbildung der 48 Bit langen IEEE 802.3 auf die 64 Bit langen IPv6-Interface ID Adresse,

führt der Weg über die Abbildung auf eine IEEE EUI-64 Adresse [RFC2464].

Dazu werden die ersten drei Oktette der IEEE 802.3 MAC-Adresse (OUI = Organizational

Unique Identfier) in die IEEE EUI-64 Adresse übernommen.

In das vierte und das fünfte Oktett wird die Zahlen FF16 und FE16 eingefügt.
Die letzten 3 Oktette der IEEE 802.3 MAC-Adresse werden zu den letzten drei Oktetten der

IEEE EUI-64 Adresse. Zusätzlich wird auch das u-Bit invertiert.

Beispiel
- IEEE 802.3 MAC-Adresse (64 Bit) => IPv6-Interface ID Adresse (64 Bit)

IEEE 802.3 MAC-Adresse (48Bit)                            3007:8912:3456
IPv6-Interface ID Adresse (64 Bit)                     3207:89FF:FE12:345

EUI-64

EUI-64 (64-Bit Extended Unique Identifier)

bezeichnet ein vom IEEE standardisiertes MAC-Adressformat zur Identifikation von

Netzwerkgeräten.

Eine EUI-64 Adresse ist 64 Bit lang und setzt sich aus zwei Teilen zusammen

Die ersten 24, 28 oder 36 Bit identifizieren den Hardwarehersteller (siehe OUI)
Die restlichen Bits dienen der Geräteidentifikation

Eine Variante davon ist das sogenannte modifizierte EUI-64 Adressformat

welches bei IPv6 zum Einsatz kommt.
Dieses unterscheidet sich darin, dass der Wert des siebten Bits (von links) einer EUI-64

Adresse, auch Universal/Local Bit genannt, invertiert wird.

EUI-64

Umrechnung
Eine 48 Bit lange MAC-Adresse lässt sich ohne Probleme in das modifizierte EUI-64
Adressformat umrechnen

Die MAC-Adresse wird in zwei 24 Bit lange Teile geteilt

wobei der erste Teil die ersten 24 Bit und der zweite Teil die letzten 24 Bit der modifizierten EUI-

64 Adresse bilden

Die restlichen 16 Bits werden nach folgendem Bitmuster belegt

1111 1111 1111 1110 (Hexadezimal: FFFE)

Nach Schritt zwei befindet sich die Adresse im EUI-64-Format

Wenn man nun den Wert des siebten Bits invertiert, erhält man die modifizierte EUI-

64-Adresse

EUI-64

Organisationally Unique   Network Interface Controller
Identifier (OUI)            (NIC) Specific
3 bytes                      3 bytes

00 0C 29 0C 47 D5

00 0C 29                                        0C 47 D5
8 bit
b8 b7 b6 b5 b4 b3    1 b1

02 0C 29                                        0C 47 D5

Aufteilung des Adressraums

Adresszuweisung

Internetprovider und Regional Internet Registry
Internetprovider (ISP) bekommen die ersten 32 Bit (oder weniger) als Netz von einer
Regional Internet Registry (RIR) zugewiesen

Dieser Bereich wird vom Provider weiter in Subnetze aufgeteilt

Die Länge der Zuteilung an Endkunden wird dabei dem ISP überlassen

Vorgeschrieben ist die minimale Zuteilung eines /64-Netzes
Ältere Dokumente (z.B. RFC 3177) schlagen eine Zuteilung von /48-Netzen an Endkunden vor
In Ausnahmefällen ist die Zuteilung größerer Netze als /48 oder mehrerer /48-Netze an einen

Endkunden möglich

Informationen über die Vergabe von IPv6-Netzen können über die Whois-Dienste der jeweiligen

RIRs abgefragt werden

Präfixe

Präfixe geben den Netzwerkteil der Adresse an

Sie werden in CIDR - Notation angegeben

Alle übrigen Bit können verwendet werden zur

Unterteilung in Subnetze
Adressierung von Nodes

Das Präfix /128 bezeichnet einen einzelnen Node

Typische Präfix-Längen

Netzsegmente

Einzelnen Netzsegmenten werden in der Regel ein 64 Bit langer Präfix zugewiesen

das zusammen mit dem 64 Bit langen Interface-Identifier die Adresse bildet

Der Interface-Identifier

kann aus der MAC-Adresse der Netzwerkkarte erstellt oder
anders eindeutig zugewiesen werden
das genaue Verfahren ist in RFC 4291, Anhang A beschrieben

Netzsegmente

Hat ein Netzwerkgerät die IPv6-Adresse

2001:0db8:85a3:08d3:1319:8a2e:0370:7347/64

so lautet das Präfix

2001:0db8:85a3:08d3::/64

und der Interface-Identifier

1319:8a2e:0370:7347

Der Provider bekam von der RIR wahrscheinlich das Netz

2001:0db8::/32

zugewiesen und der Endkunde vom Provider möglicherweise das Netz

2001:0db8:85a3::/48

oder aber nur

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

IPv6-Adressraum

Der Adressraum von IPv6 teilt sich in mehrere große Blöcke auf

die weiter unterteilt sein können

Alle Adressen unterhalb der hierarchischen Adressebene eines Blockes weisen

einen identischen Präfix auf

Dadurch wird das Routing entschieden vereinfacht
Router können einen großen Teil der Entscheidungen schon anhand des Präfix treffen

IPv4-Adressen

Können mit dem Präfix 0 in den IP6-Raum eingeblendet werden

Durch die neue Struktur stehen viele neuer Adressen und neue Adressierungsarten

zur Verfügung

Pakete werden je nach Adressierung

an genau eine Station gesendet (Unicast),
an eine Gruppe von Stationen (Multicast)
an die schnellste aus einer Gruppe von Stationen (Anycast)

Adressierungsarten

Zu unterstützende Adressen

Zugeordnete Adressbereiche

Address Scopes (Gültigkeitsbereiche)

Es gibt verschiedene IPv6-Adressbereiche mit Sonderaufgaben

und unterschiedlichen Eigenschaften

Diese werden meist schon durch die ersten Bit der Adresse signalisiert

Sofern nicht weiter angegeben, werden die Bereiche in RFC 4291 bzw. RFC 5156 definiert

Scopes

interface/host                        Verlässt nie den Host
link-local                            Verlässt nie das lokale Subnetz
global                                Geht um die ganze Welt

Address Scopes sind nicht mit Multicast Scopes zu verwechseln

Besondere Adressen

Nicht spezifizierte Adresse

/128

128 0-Bit
darf keinem Host zugewiesen werden
zeigt das Fehlen einer Adresse an

Verwendung

Absenderadresse eines initialisierenden Hosts, solange er noch keine Adresse hat
Serverprogramme werden durch Angabe dieser Adresse angewiesen, auf allen Adressen des

Hosts lauschen

Loopback-Adresse

1/128

127 0-Bit, ein 1-Bit
ist die Adresse des eigenen Rechners
loopback-Adresse, die in der Regel mit localhost verknüpft ist

Unicast-Adressen

Charakterisieren Kommunikation eines Netzknotens mit genau einem anderen
Netzknoten

Link-Local-Adressen

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

Beispiel

fe80::7645:6de2:ff:1%1 bzw. fe80::7645:6de2:ff:1%eth0

Site Local Unicast (veraltet)

fec0::/10 (fec0… bis feff…)

Auch: Standortlokale Adressen (site local addresses)
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 Unique Local Addresses

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

Unique Local Unicast (ULA)

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“ noch nicht gegründet
Sowohl der RFC 4193 als auch der proposed standard sind identisch in Bezug auf das

Adressformat und den Generierungs-Algorithmus

Multicast-Adressen

Multicast-Adressen sprechen eine ganze 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.

Multicast-Adressen

Einer-zu-vielen-Kommunikation wird durch Multicast-Adressen abgebildet

Multicast-Adressen

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

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)

Multicast-Adressen

Gültigkeitsbereiche

Die restlichen Bereiche sind nicht zugewiesen

und dürfen von Administratoren benutzt werden, um weitere Multicast-Regionen zu definieren.

1            interfacelokal, diese Pakete verlassen die Schnicite_ref-multicast_28-1cite_ref-multicast_28-1
ttstelle nie. (Loopback)
2            link-lokal, werden von Routern grundsätzlich nie weitergeleitet und können deshalb das
Teilnetz nicht verlassen.
4            adminlokal, der kleinste Bereich, dessen Abgrenzung in den Routern speziell administriert
werden muss.
5            sitelokal, dürfen zwar geroutet werden, jedoch nicht von Border-Routern.
8            organisationslokal, die Pakete dürfen auch von Border-Routern weitergeleitet werden, bleiben
jedoch „im Unternehmen“ (hierzu müssen seitens des Routing-Protokolls entsprechende
Vorkehrungen getroffen werden).
e            globaler Multicast, der überallhin geroutet werden darf.
0, 3, f      reservierte Bereiche

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

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

Unterteilung des IPv6-Adressraums

Präfix        Verwendung
0000 0000     Reserviert und IPv4
0000 0001     Nicht zugewiesen
0000 0010     OSI-NSAP-Adressen
0000 010      Netware IPX-Adressen
0000 011      Nicht zugewiesen
0000 1        Nicht zugewiesen
1             Nicht zugewiesen
1             Nicht zugewiesen
10            Adressen für Service Provider
11            Nicht zugewiesen
100           Adressen für geographische Bereiche
101           Nicht zugewiesen
110           Nicht zugewiesen
1110          Nicht zugewiesen
1111 10       Nicht zugewiesen
1111 110      Nicht zugewiesen
1111 1110     Nicht zugewiesen
1111 1110 0   Nicht zugewiesen
1111 1110 10  verbindungsspezifische lokale Adressen
1111 1110 11  Standortspezifische lokale Adressen
1111 1111     Multicast

Unicast Adressen

Unicast-Adressen

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

Der 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

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

Global Unicast Adressen

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

IPv6-Adressraum

Zusammenfassung

IPv6

Privacy Extensions nach RFC 4941
Privacy-Extensions

Erzeugung des Interface-Identifiers

Die Erzeugung des Interface-Identifiers aus der global eindeutigen MAC-Adresse ermöglicht die

Nachverfolgung von Benutzern

Privacy-Extensions (PEX, RFC 4941)

hebt die permanente Kopplung der Benutzeridentität an die IPv6-Adressen auf

Zufällig generiert und regelmäßig gewechselt

Indem der Interface-Identifier zufällig generiert wird und regelmäßig wechselt, soll ein Teil der

Anonymität von IPv4 wiederhergestellt werden

Täglich wechselndes Präfix wünschenswert

Im Privatbereich lässt das Präfix allein recht sicher auf einen Nutzer schließen
Daher ist aus Datenschutzgründen ein vom Provider dynamisch zugewiesenes Präfix

wünschenswert

- in Verbindung mit den Privacy Extensions
- z. B. täglich wechselnd

Whois-Datenbank

Statische Adresszuteilung erfordern meist ein Eintrag in der öffentlichen Whois-Datenbank
In Deutschland hat der Deutsche IPv6-Rat Datenschutzleitlinien formuliert, die auch eine

dynamische Zuweisung von IPv6-Präfixen vorsehen

Privacy Extensions nach RFC 4941

Stateless Address Autoconfiguration (SLAAC)

nutzt auf einigen Betriebssystemen per Vorgabe die Hardware-Adresse der

Netzwerkschnittstelle

Solche Adressen sind im Internet leicht wiederzuerkennen

Abhilfe schaffen die Privacy Extensions

die zusätzliche, über Zufallszahlen generierte und wechselnde IPv6-Adressen erzeugen

Stateless Address Autoconfiguration

schiebt in der Mitte der nur 48 Bit langen MAC-Adresse zusätzlich die Bytes ff:fe ein
erzeugt daraus den Local Identifier, also die hinteren 64 Bit einer IPv6-Adresse
Die ersten 64 Bit gehören dem Netzwerk-Präfix, das der IPv6-Router im Netzwerk bekannt gibt

und das der Rechner in die globale IPv6-Adresse übernimmt.

Privacy Extensions nach RFC 4941

Linuxe und Mac-OS
* leiten ohne Eingriff ihre globale IPv6-
Adresse aus der Hardware ab
* damit offenbaren sie Informationen über
den Benutzer

Windows (seit Vista)

erzeugt immer eine temporäre IPv6-

Adresse

die dem Nutzer mehr Privatheit verschafft

Privacy Extensions nach RFC 4941

Den IPv6-Entwicklern fiel schnell auf

dass dieses Verfahren die Privatsphäre von Rechner und Nutzer gefährdet
Solche statischen IPv6-Adressen wirken wie eine eindeutige Hardware-ID, die der Rechner bei

jedem Kontakt zu einem IPv6-tauglichen Server überträgt.

Brisant ist das bei Geräten wie Tablets oder Smartphones, denn sie werden in der Regel nur von

einer Person genutzt.

Die für jeden Serverbetreiber und Netzbeobachter zugängliche MAC-Adresse erlaubt es damit,

diese Person wiederzuerkennen.

Privacy Extensions for Stateless Address Autoconfiguration in IPv6

Daher definierten sie nachträglich das Verfahren "Privacy Extensions for Stateless Address

Autoconfiguration in IPv6" (RFC 4941)

mit dem sich zusätzlich zu diesen statischen Adressen temporäre erzeugen lassen
die der Rechner für seine Anfragen ins IPv6-Internet einsetzt

Der Host Identifier dieser Adressen wird über Zufallszahlen ermittelt

Allerdings setzen längst nicht alle aktuellen Betriebssysteme diese Erweiterung ab Werk ein

Derzeit hat einzig Windows die Privacy Extensions eingeschaltet

Andere wie Mac OS und Linux beherrschen das Verfahren
man muss es aber per Hand aktivieren

Privacy Extensions nach RFC 4941

Übersicht

Betriebssystem Privacy ab Werk de-/aktivierbar Anmerkung

Extensions    aktiv

Windows XP + + +/+
Windows Vista + + +/+
Windows 7 + + +/+
Windows Server 2003 + - +/+
Windows Server 2008 + - +/+
R2
OpenSuse Linux + - +/+
Ubuntu Linux + ab 12.04 +/+
Debian Linux + - +/+
Fedora Linux + - +/+
Mac OS X + ab 10.7 +/+

iOS 4.1 + - -/- Privacy Extensions via

Jailbreak

iOS 4.2 + - -/- Privacy Extensions via

Jailbreak

iOS 4.3 + + -/-

Android ab 2.1 + - -/- Privacy Extensions über

Rooting

Privacy Extensions nach RFC 4941

Windows

Ohne dass der Nutzer eingreifen muss

richten die Desktop-Versionen von Windows per Stateless Autoconfiguration bereits temporäre

IPv6-Adressen ein.

Wie im RFC vorgesehen wechselt Windows diese Adressen in Intervallen
die sich wie auch andere IPv6-Parameter über das Kommando netsh einstellen lassen

Wechselnde Adressen auf Servern wenig sinnvoll

Daher hat Microsoft die Privacy Extensions auf Windows-Server-Versionen nicht eingeschaltet
Anders als andere erzeugen Windows-Rechner ihre statische IPv6-Adresse auch nicht aus der

Hardware-Adresse der jeweiligen Schnittstelle.

Stattdessen würfelt Windows die Adresse einmal, meist bei der Installation, aus

Abschalten

Dieses Verhalten lässt sich als Administrator ändern
Mit folgendem Befehl nutzt Windows für seine statische, globale IPv6-Adresse nun die MAC der

Netzwerkschnittstelle
netsh interface ipv6 set global randomizeidentifiers=disabled

Nachschauen

Die aktuelle Einstellung zeigt das folgende Kommando in der Ausgabezeile an

netsh interface ipv6 show global

Privacy Extensions nach RFC 4941

Windows

Aktuelle IPv6-Adressen aller Netzwerkkarten

netsh interface ipv6 show addresses

Vorgaben für die Privacy Extensions ausgeben

netsh interface ipv6 show privacy
Der aktive Status wird abgefragt...
Parameter für temporäre Adressen
------------------------------------------------
Temporäre Adresse verwenden         : enabled
Versuch, doppelte Adr. zu entdecken : 5
Maximale Gültigkeitsdauer           : 7d
Maximale bevorzugte Gültigkeitsdauer: 1d
Regenerationszeit                   : 5s
Maximale Verzögerungszeit           : 10m
Verzögerungszeit                    : 0s

Privacy Extensions nach RFC 4941

Windows

Windows erzeugt seine feste IPv6-Adresse nicht über die MAC, die Privacy Extensions hat
Microsoft ab Werk aktiviert.

Privacy Extensions nach RFC 4941

Windows

Die Ausgabe bestätigt, dass die Privacy Extensions (Temporäre Adresse verwenden)

aktiv sind.

Maximale bevorzugte Gültigkeitsdauer

legt fest, nach welcher Zeit (hier in Tagen) der Rechner eine neue temporäre Adresse erzeugt

und für ausgehende Pakete auch einsetzt.

Maximale Gültigkeitsdauer

Eingehende Verbindungen akzeptiert der Rechner deutlich länger auf einer temporären Adresse,

was etwa für Peer-to-Peer-Anwendungen nützlich sein kann.

Temporären IPv6-Adressen vollständig abschalten

netsh interface ipv6 set privacy state=disabled

Gültigkeitsdauer setzen

netsh interface ipv6 set privacy maxpreferredlifetime=12h

Schlüssel maxpreferredlifetime und maxvalidlifetime
Zeitangaben in Tagen (d), Stunden (h), Minuten (m) und Sekunden (s)

Privacy Extensions nach RFC 4941

Linux

Alle großen Linux-Distributionen aktivieren IPv6, die Privacy Extensions jedoch

nicht

Das bemerkt man schnell an den aus der Hardware-Adresse abgeleiteten Adressen, die im

hinteren Teil die Bytes ff und fe enthalten.

Die Privacy Extensions lassen sich über das Sysctl-System dauerhaft einschalten

Am einfachsten gelingt das, wenn man für jede Netzwerkschnittstelle im Computer eine Zeile in

die Datei /etc/sysctl.conf nachträgt.
net.ipv6.conf.IF.use_tempaddr = 2
Den Platzhalter IF müssen Sie dabei durch die Schnittstellenbezeichnung ersetzen, also etwa
eth0 für die erste Ethernet-Karte oder wlan0 für das WLAN-Interface.

Testweise können Sysctl-Werte auch über die Shell eingeben werden

sysctl net.ipv6.conf.wlan0.use_tempaddr=2

Damit Linux die Netzwerkschnittstelle mit einer temporären IPv6-Adresse versorgt, müssen Sie

die Schnittstelle einmal aus- und wieder einschalten (etwa über den Network Manager).

Anschließend zeigt ifconfig an der Schnittstelle eine weitere IPv6-Adresse, deren hinterer Teil

nicht mehr aus der Hardware-Adresse abgeleitet wurde.

Dass es sich tatsächlich um eine temporäre Adresse handelt, zeigt der Befehl ip -6 addr show

über den Bezeichner "temporary" in seinen Ausgaben an.

Bei Ubuntu muss zusätzlich der Wert net.ipv6.conf.default.use_tempaddr=2 in der Datei

/etc/sysctl.conf setzen.

Privacy Extensions nach RFC 4941

Linux: Vorgaben ändern

Vorgaben zum Wechseln der temporären IPv6-Adresse lassen sich via sysctl

anpassen

Die Sysctl-Schlüssel

net.ipv6.conf.IF.temp_valid_lft
net.ipv6.conf.IF.temp_prefered_lft

setzen die maximale Zeit in Sekunden, in der Linux die Adresse für eingehende und

ausgehende Anfragen nutzt.

Der letzte Schlüssel hat typischerweise den Wert 86400 (24 Stunden), eingehende Pakete

akzeptiert Linux sieben Tage an dieser Adresse.

Den Platzhalter IF müssen Sie dabei wie oben durch den Schnittstellennamen ersetzen.

Privacy Extensions nach RFC 4941

Android

Googles Smartphone-Betriebssystem setzt auf Linux auf

das zufällige und wechselnde IPv6-Adressen erzeugen kann
Andererseits hat Google die dafür nötigen Vorgaben nicht gesetzt, sodass bislang jede Android-

Version ohne die Privatsphäre schützenden IPv6-Adressen auskommen muss.

Auch lassen sie sich nicht einfach einschalten, denn die Mobilfunk-Provider und Handy-Hersteller

vernageln den dafür nötigen Root-Zugang.

Zwei Befehle genügen und ein gerootetes Android surft über die wechselnden und nicht aus der

Hardware abgeleitetden IPv6-Adressen.

Wie auch auf iPhones bleibt nur der Weg über das nachträgliche

Freischalten des Root-Zugangs oder über die Installation von
Custom-ROMs:

Mit dem für solche Verwaltungsaufgaben nötigen Root-Benutzer

lassen sich dann wieder die Sysctl-Werte setzen, die die
Privacy Extensions für IPv6 aktivieren.

Steht auf dem Telefon das Kommando sysctl bereit, reichen die Befehle

su
sysctl -w net.ipv6.conf.default.use_tempaddr=2
sysctl -w net.ipv6.conf.all.use_tempaddr=2

Nach einem Neustart vergisst Android diese Einstellungen jedoch wieder.
Man kann die beiden Befehle allerdings in eine Datei namens /data/local/userinit.sh schreiben.
Existiert diese Datei, führt Cyanogenmod die darin aufgelisteten Befehle beim Systemstart aus.

Privacy Extensions nach RFC 4941

Mac OS X

Auch Apples Betriebssystem Mac OS X über die Privacy Extensions ermittelte IPv6-
Adressen erzeugen und einsetzen

Allerdings hat Apple dafür keinen Schalter vorgesehen.
Das Programm IPv6 Anonymizer von c't
- zeigt den Status der Privacy Extensions,
- schaltet sie an oder aus und
- sorgt dafür, dass die Funktion auch

beim Neustart zur Verfügung steht.

Kommandozeile

Die Privacy Extensions lassen sich im Terminal (im Dienstprogramme-Ordner) mit einem Befehl

aktivieren

sudo sysctl -w net.inet6.ip6.use_tempaddr=1

Damit das klappt, müssen Sie mit einem Benutzer angemeldet sein, der den Mac verwalten darf.
Leider verschwindet die Einstellung nach einem Neustart.

Privacy Extensions nach RFC 4941

iPhone und iPad (IOS)

Noch schlechter als auf dem Apple-Desktop sah es bis vor kurzem unter den Mobil-
Betriebssystemen für iPhones und iPads aus

Bis zur Version 4.3 waren auch dort die Privacy Extensions abgeschaltet. Erst das Update aktiviert die

Erweiterung.

Im Unterschied zu Mac OS X steht aber auf den Mobilbetriebssystemen für iPhone und iPad kein vom

Hersteller vorgesehener Weg offen, die Privacy Extensions zu aktivieren oder abzuschalten.

Will man auf Geräten mit der IOS-Version kleiner als 4.3 die Privacy Extensions einschalten, hat man

nur dann eine Chance, wenn man einen Administrator-Zugang zum Betriebssystem hat (Jailbreak): In
diesem Fall reicht der Aufruf von

sudo sysctl -w net.inet6.ip6.use_tempaddr=1

respektive der Eintrag in die Datei /etc/sysctl.conf:

net.inet6.ip6.use_tempaddr=1

Starten Sie dazu im Terminal einen Editor mit root-Rechten und fügen Sie die Zeile am Ende der Datei

an.

sudo pico /etc/sysctl.conf

Nach einem Neustart der WLAN-Schnittstelle respektive einem Neustart des Geräts sollte die

Webseite http://ct.de/ip die zweite, über die Privacy Extensions erzeugte IPv6-Adresse anzeigen.

RFC 4291

Adressnotation

Reduktion durch Regel 3 darf nur einmal durchgeführt werden

Es darf höchstens eine zusammenhängende Gruppe aus Null-Blöcken in der Adresse ersetzt

werden.

2001:0db8:0:0:8d3:0:0:0

darf gekürzt werden zu

2001:db8:0:0:8d3::
oder
2001:db8::8d3:0:0:0

Wegen Mehrdeutigkeit Unzulässig

2001:db8::8d3::

2001:db8:0:0:0:8d3:0:0

interpretiert werden könnte.

Es empfiehlt sich den Block mit den meisten Null-Blöcken zu kürzen.

TMP

Adressnotation

IPv6-Adresse werden hexadezimal notiert

Acht Segmente zu je 16 Bit
Die 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

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