topic - Beschreibung

Beschreibung

Nodes haben über Link-local Addressen kommuniziert

Erreichbarkeit nachgewiesen
Neighbor Caches gepflegt

Was fehlt, ist der Zugang zum IPv6-Internet

router hat bereits Zugang

Konfiguration router

Hosts mit gültigen, weltweit eindeutigen Adressen versorgen
Konnektivität überprüfen

Nächste Schritte

Präfix	#Präfix
SLAAC	#SLAAC
Namensauflösung	#Namensauflösung

Präfix

Präfix - Präfix für den Link

Beschreibung

Automatische Konfiguration

Link internal soll Global-Unicast-Präfix erhalten

Teilnahme am IPv6-Netzwerk
Manuelle Konfiguration vermeiden

Nach einer automatisierten Konfiguration sollen die Hosts mit

einer oder mehreren IPv6-Adressen
der Adresse des zuständigen Routers und
der Adresse eines Resolving Nameservers ausgestattet sein

Resolving Nameserver

Ein Resolving Nameserver wäre, technisch gesehen, für das Herstellen der Konnektivität nicht erforderlich

In der Praxis erweisen sich Hosts ohne funktionierende Namensauflösung aber als mühsam bedienbar
Für die tägliche Arbeit mit dem Internet sind sie schlicht nicht geeignet

Aufgabenteilung

Welche Teile der automatischen Konfiguration der Router erledigt, und wo die Hosts selbst tätig werden müssen, werden wir gleich erfahren

Soviel vorweg: Die Konfigurationen werden nicht als mundfertige Häppchen serviert, wie es bei IPv4 in Verbindung mit DHCP üblich ist
Einer erfolgreichen Konfiguration geht immer ein Zusammenspiel von Router und Host voraus

Präfix aktivieren

64 Bits langes Präfix des Tunnelbrokers

Das Präfix werden wir für die Adressierung der Nodes auf dem internen Link verwenden
Dazu stellen wir sicher, dass das Präfix bei dem Tunnelbroker aktiviert ist
Im Home-Bereich der Tunnelbrokers-Website befindet sich eine Tabelle mit Präfixen, die dort Subnets genannt werden
In der Spalte State sollte für das zu unserem Tunnel gehörende Präfix Enabled stehen
In der Spalte Subnet Präfix finden wir jenes Präfix, welches über unseren Tunnel geroutet wird
In den Beispielen lautet es 2a01:198:200:8a23::/64
- Notieren für spätere Verwendung!

Router Advertisement

SLAAC

Stateless Address Autoconfiguration (SLAAC) - Automatische Konfiguration von IPv6-Adressen

Beschreibung

Ablauf

Aufgabe	Beschreibung
1	Link-local Address generieren
2	Stateless Address Autoconfiguration
3	Duplicate Address Detection

Den ersten Schritt macht der Host, indem er mittels Router Solicitation nach einem Router Advertisement fragt
- Alternativ könnte er auch ein periodisches Router Advertisement abwarten
- diese Geduld beobachtet man aber eher selten
Der Router verschickt das angeforderte Router Advertisement,welches alle konfigurationsrelevanten Daten enthält
Daraufhin führt der Host die Konfiguration des Interfaces durch und prüft die Eindeutigkeit der selbst erzeugten Adressen

Wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet

Duplicate Address Detection

Duplicate Address Detection besteht aus mehrere Neighbor Solicitations

Wenn ein Node feststellen möchte, ob eine Adresse schon von einem anderen Node genutzt wird, dann versucht er die zugehörige Linklayer Address aufzulösen
Bleibt eine Antwort aus, benutzt offensichtlich kein anderer Node auf dem Link die überprüfte Adresse
Um Fehlschlüsse aufgrund von Paketverlusten zu vermeiden, sollen mehrere Neighbor Solicitations verschickt werden

Ab wann eine Adresse als eindeutig gilt, hängt von den Parametern der jeweiligen Implementierung ab

Jede Adresse hat anfangs den Status tentative (probeweise)
Erst wenn die Duplicate Address Detection vollständig durchlaufen wurde, und keine Anzeichen darauf schließen lassen, dass die Adresse bereits in Benutzung ist, wird die Adresse valid (gültig)

Ablaufverfolgung

Aufzeichnung einer Autoconfiguration mit Wireshark

Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration

Interface herunterfahren

# ip link set down dev enp2s0
2: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
   link/ether 74:27:ea:e1:b2:b4 brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.106/24 brd 192.168.1.255 scope global dynamic noprefixroute enp2s0
      valid_lft 4826sec preferred_lft 4826sec

Wireshark starten

auf PseudoInterface any lauschen

Interface starten

# ip link set up dev enp2s0
enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether 74:27:ea:e1:b2:b4 brd ff:ff:ff:ff:ff:ff
   inet6 2001::a44d:a161:1a33:c64d/64 scope global dynamic noprefixroute
      valid_lft 86399sec preferred_lft 14399sec
   inet6 fe80::99d7:66e5:331d:9449/64 scope link noprefixroute
      valid_lft forever preferred_lft forever

Aktivität beobachten

In Wireshark können wir bereits Aktivität beobachten. Wir warten den Abschluss der Konfiguration ab, sie ist erfolgreich verlaufen wenn wir Adressen mit den Parametern scope global und dynamic sehen:

# ip addr show dev enp1s0
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether 50:3e:aa:1f:63:81 brd ff:ff:ff:ff:ff:ff
   inet 10.30.1.1/24 brd 10.30.1.255 scope global enp1s0
      valid_lft forever preferred_lft forever
   inet6 fe80::523e:aaff:fe1f:6381/64 scope link
      valid_lft forever preferred_lft forever

Autoconfiguration

SLAAC ist Bestandteil der Autoconfiguration, die drei wesentliche Aufgaben hat

Generieren einer Link-local Address
Durchführen der Stateless Address Autoconfiguration
Sicherstellen der Eindeutigkeit der generierten Adressen (Duplicate Address Detection)
Damit reduziert IPv6 als Protokoll die Abhängigkeit von dritten Komponenten zur Organisation des Links
Die Nutzung von Stateless Address Autoconfiguration erfordert keine manuelle Konfiguration der Hosts und nur sehr wenige Konfigurationsschritte auf dem Router
Damit einher geht der Verlust einer strengen Zuordnung von Adressen zu bestimmten Hosts
In Umgebungen wo die Zuordnung von Adressen zu Hosts zentral gesteuert werden soll, ist dieser Ansatz nicht ausreichend
Dort würde man auf DHCPv6 zurückgreifen
Aber auch ein simultaner Betrieb von DHCPv6 und Stateless Address Autoconfiguration wäre denkbar

Ablauf

Den ersten Schritt macht der Host, indem er mittels Router Solicitation nach einem Router Advertisement fragt

Alternativ könnte er auch ein periodisches Router Advertisement abwarten, diese Geduld beobachtet man aber eher selten
Der Router verschickt das angeforderte Router Advertisement, welches alle konfigurationsrelevanten Daten enthält
- Wir gehen hier der Einfachheit halber von nur einem Router aus

Daraufhin führt der Host die Konfiguration des Interfaces durch und prüft die Eindeutigkeit der selbst erzeugten Adressen

Erst wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet

Duplicate Address Detection

Hinter der Duplicate Address Detection verbergen sich mehrere Neighbor Solicitations

Wenn ein Node feststellen möchte, ob eine Adresse schon von einem anderen Node genutzt wird, dann versucht er die zugehörige Linklayer Address aufzulösen
Bleibt eine Antwort aus, benutzt offensichtlich kein anderer Node auf dem Link die überprüfte Adresse
Um Fehlschlüsse aufgrund von Paketverlusten zu vermeiden, sollen mehrere Neighbor Solicitations verschickt werden

Ab wann eine Adresse als eindeutig gilt, hängt von den Parametern der jeweiligen Implementierung ab

Jede Adresse hat anfangs den Status tentative (probeweise)
Erst wenn die Duplicate Address Detection vollständig durchlaufen wurde, und keine Anzeichen darauf schließen lassen, dass die Adresse bereits in Benutzung ist, wird die Adresse valid (gültig)

Autoconfiguration mitschneiden

Mitschnitt einer komplette Autoconfiguration von linux mit Wireshark

Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration

Dazu öffnen wir ein root-Terminal auf linux und fahren das Interface eth0 herunter:

root@linux:~# ip link set down dev eth

Nun starten wir Wireshark und lassen ihn auf dem PseudoInterface any lauschen

Danach fahren wir eth0 wieder hoch:

root@linux:~# ip link set up dev eth

In Wireshark können wir bereits Aktivität beobachten

Wir warten den Abschluss der Konfiguration ab, sie ist erfolgreich verlaufen wenn wir Adressen mit den Parametern scope global und dynamic sehen:

user@linux:~ $ ip addr show dev eth
2: eth : < BROADCAST , MULTICAST ,UP , LOWER_UP > mtu 15 qdisc pfifo_fast state UP qlen 1
link / ether : : :6 : d :1 e brd ff : ff : ff : ff : ff : ff inet6 2 a 1 :198:2 :8 a23 :2 : ff : fe6 : d1e /64 scope global dynamic valid_lft 3578 sec preferred_lft 1778 sec inet6 fe8 ::2 : ff : fe6 : d1e /64 scope link valid_lft forever preferred_lft forever

Wireshark kann jetzt den Mitschnitt beenden

Von den vielen Paketen, die wir mitgeschnitten haben, sind nicht alle von Interesse

Multicast DNS

Insbesondere die Pakete vom Typ Multicast DNS (mDNS) werden wir an dieser Stelle ignorieren

Multicast DNS erlaubt die Auflösung von Namen der Domain .local zu Linklocal Addresses
Leider belastet es dazu den Link ungefragt mit allerlei Paketen
Da wir im Workshop keine lokale Namensauflösung auf Multicast-Basis nutzen, kümmern wir uns nicht weiter um dieses Protokoll
Mehr zu Multicast DNS und seinem Nutzen für kleine Netze findet sich auf der gemeinsamen Website der Beteiligten Interessensgruppen. (http://www.multicastdns.org/)

Multicast Listener Report (Solicited Node)

Das erste interessante Paket im Mitschnitt ist ein Multicast Listener Report und wurde von linux verschickt

Der IPv6-Header ist in Abbildung 5.10 zu sehen

Abbildung 5.10 SLAAC Paket 1: IPv6-Header

Als Quelladresse hat linux die Unspecified Address gewählt

Das heißt, zum Zeitpunkt des Versendens stand keine passende, gültige Adresse zur Verfügung

Die Zieladresse ist die Multicast Address für alle MLDv2-fähigen Router
Zu finden auch in der Tabelle 4.5 in Abschnitt 4.5 Multicast
Uns fällt das für MLDv2 Messages typische Hop Limit von 1 auf
Bemerkenswert ist auch der Einsatz des Hop-by-Hop Options Extension Headers
Neben der Padding Option, welche den Extension Header auf eine einheitliche Länge auffüllt, ist auch eine Router Alert Option vorhanden
Sie informiert Multicastfähige Router darüber, dass sich eine MLDv2 Message im Paket befindet
Interessierte Router werten die Nachricht dann aus und ziehen daraus Schlüsse für ihr Multicast Routing
Die MLDv2 Message kann in Abbildung 5.11 eingesehen werden

Genaugenommen handelt sich um eine MLDv2 Message der Art Changed to Exclude

Wir haben in Abschnitt 4.5 Multicast bereits besprochen wie dieser Typ zu interpretieren ist
Hier wird die Multicast Address ff 2::1:ff6 :d1e für alle potentiellen Multicast-Quellen freigegeben
Die Nachricht entspricht dem Beitritt zur Multicast Group ff 2::1:ff6 :d1e
Es handelt sich dabei um die Solicited Node Multicast Address von Interface eth0 auf linux

Gruppenbeitritt

Zu diesem Zeitpunkt hat linux bereits einen Interface Identifier erzeugt

Der Beitritt zur entsprechenden Multicast Group gewährt ihm Zugang zu den Paketen dieser Gruppe

Abbildung 5.11 SLAAC Paket 1:Multicast Listener Report

So hat er die Chance, frühzeitig zu erfahren, ob sein Interface Identifier schon verwendet wird

Würde ein anderer Node seinen Interface Identifier bereits verwenden, so wäre dieser Node ebenfalls Mitglied der Multicast Group
Eine doppelt vorkommende Adresse würde dadurch schneller auffallen

Gruppen mit mehreren Mitgliedern

Es wäre allerdings auch möglich, dass ein anderer Node eine ähnliche Adresse verwendet

Beispielsweise eine Adresse bei der sich die letzten 24 Bits gleichen
Beide Nodes wären nun in derselben Gruppe, jene mit der gemeinsamen Solicited Node Multicast Address
Beide Nodes würden auch Pakete empfangen, die nicht für sie bestimmt wären, die aufgrund der Ähnlichkeit der Adresse aber an die gemeinsame Gruppe geschickt wurden
Jeder Node muss deshalb prüfen, ob ein Paket, welches an die Gruppe adressiert wurde, auch wirklich für ihn von Belang ist
Auch linux könnte Pakete empfangen, nach der Prüfung des Inhaltes aber feststellen, dass der eigene Interface Identifier davon nicht betroffen ist

Duplicate Address Detection (Link-local)

Möchte linux nun feststellen, ob die von ihm gewählte Adresse nicht nur vielleicht eindeutig ist, dann ist eine Duplicate Address Detection erfolgsversprechender

Wenn sie fehlschlägt, dann ist die von linux gewählte Adresse sehr wahrscheinlich auf dem Link noch nicht vergeben

Abbildung 5.12: SLAAC Paket 2: Neighbor Solicitation

Eine endgültige Gewissheit ist mit der Duplicate Address Detection nicht zu erreichen

Im ungünstigsten Fall gehen genau jene Pakete verloren, die auf eine doppelte Adresse hinweisen würden
Dazu sendet linux eine Neighbor Solicitation für die selbst erzeugte Adresse aus (siehe Abbildung 5.12)

Als Quelladresse wählt er wieder die Unspecified Address, da die Link-local Address noch nicht als eindeutig gilt

Die Neighbor Solicitation geht an die Solicited Node Multicast Address der zu überprüfenden Link-local Address
Im Feld Target Address taucht die gewünschte Adresse fe8 ::2 :ff:fe6 :d1e schließlich auf

Das Ausbleiben eines Neighbor Advertisements wertet der Node als Anzeichen für die Eindeutigkeit seiner Adresse auf dem Link

Sie wird dann dem Interface zugewiesen und gilt fortan als valid

Router Solicitation

Nachdem linux nun eine gültige Link-local Address hat, versucht er auch eine gültige Adresse für den Global Scope zu erhalten

Dazu lässt er sich von jedem Router am Link ein RouterAdvertisement zukommen
Die Anforderung der Router Advertisements geschieht mit Hilfe einer Router Solicitation, die in Abbildung 5.13 zu sehen ist

Abbildung 5.13: SLAAC Paket 3: Router Solicitation

Die Nachricht wird von der Link-local Address des Hosts gesendet

Hier von der Adresse

fe80::200:ff:fe6:d1e

Als Zieladresse wird die All Routers Multicast Address ff 2::2 verwendet, die wir schon in der Tabelle 4.5 in Abschnitt 4.5 Multicast gesehen haben
Angehängt an die Router Solicitation ist, eine ICMPv6-Option mit der Link-layer Address des Absenders

Router Advertisement

Alle Router am Link antworten auf die Router Solicitation mit einem Router Advertisement

Da wir nur einen Router am Link haben, nämlich router, erhalten wir auch nur ein Router Advertisement

Wir werden es hier nicht genauer besprechen, denn das haben wir in Abschnitt 5.1 Ein Präfix für den Link schon getan

Ein auffrischender Blick in das Paket wird aber sicher nicht schaden

Abbildung 5.14: SLAAC Paket 5: IPv6-Header

Nach dem Erhalt des Router Advertisements erzeugt linux eine Global Unicast Address

Dazu verwendet er das von router verteilte Präfix und den bereits vorhandenen Interface Identifier

Multicast Listener Report (Solicited Node, Multicast-DNS)

Auch für diese Adresse muss eine Duplicate Address Detection durchgeführt werden

Die beginnt wieder mit dem Beitritt zu der passenden Multicast Group
Obwohl sich die Solicited Node Multicast Address für die Global Unicast Address nicht von der für die Link-local Address unterscheidet, versendet linux einen neuen Multicast Listener Report
Der wesentliche Unterschied ist die Quelladresse des Paketes, siehe auch Abbildung 5.14

Anstatt der Unspecified Address kommt diesmal die Link-local Address zum Einsatz

Der Rest des Paketes ist in Abbildung 5.15 dargestellt

Unverändert geblieben ist der Beitritt zur Solicited Node Multicast Group, der erneut mithilfe von Changed to Exclude erreicht wurde

Und einen weiteren Gruppenbeitritt können wir im Paket entdecken, der Beitritt zur Gruppe ff 2::fb
Dies ist die Multicast DNS Address für die Verwendung mit IPv6, und für unser Netz nicht weiter wichtig

Abbildung 5.15 SLAAC Paket 5: Multicast Listener Report

Duplicate Address Detection (Global Unicast)

Der letzte Schritt ist die Durchführung der Duplicate Address Detection für die Global Unicast Address

Dazu sendet linux wieder eine Neighbor Solicitation, zu sehen in Abbildung 5.16, aus

Mit dem Ausbleiben einer Antwort ist die Stateless Address Autoconfiguration abgeschlossen

Das Interface eth0 ist nun fertig konfiguriert

Konnektivitätstest

Einem Test der Konnektivität von linux steht nun nichts mehr im Wege

Dazu verschicken wir Echo Requests von linux an den Tunnelendpunkt des Tunnelbrokers:

user@linux:~ $ ping6 -c 3 2 a 1 :198:2 : a23 ::1
PING 2 a 1 :198:2 : a23 ::1 (2 a 1 :198:2 : a23 ::1) 56 data bytes
64 bytes from 2 a 1 :198:2 : a23 ::1: icmp_seq =1 ttl =63 time =8. 2 ms
3 packets transmitted , 3 received , % packet loss , time 2 3 ms

Abbildung 5.16: SLAAC Paket 6: Neighbor Solicitation

Da Echo Replies eintreffen, können wir davon ausgehen dass das Routing funktioniert

Den Beweis können wir auch mit traceroute6 antreten:

user@linux:~ $ traceroute6 -n 2 a 1 :198:2 : a23 ::1
traceroute to 2 a 1 :198:2 : a23 ::1 (2 a 1 :198:2 : a23 ::1) 3 hops max , 8 byte packets
1 2 a 1 :198:2 :8 a23 ::1 2.2 4 ms 162 ms 193 ms
2 2 a 1 :198:2 : a23 ::1 13.255 ms 13.412 ms 19.135 ms

An erster Stelle steht der nächste Hop, in unserem Fall die Adresse des Interfaces eth1 von router

Schon in der zweiten Zeile ist das Ziel erreicht

SLAAC unter Windows

Analyse einer Autoconfiguration unter Windows

Bei dieser Gelegenheit werden wir auch Unterschiede entdecken, die durch Aktivierung von Privacy Extensions auftreten
Dazu öffnen wir als Administrator ein Terminal und stellen sicher das die Privacy Extensions aktiviert sind
Nach dem Betätigen der Tastenkombination Windowstaste+X erscheint ein Menü in dem wir den Punkt Command Prompt (Admin) auswählen:

Abbildung 5.17 SLAAC unter Windows

C:\Users\user> netsh interface ipv6 set global randomizeidentifiers = enabled
Ok

Leider kommt es unter Windows beim Betrieb von Wireshark manchmal zu Problemen

Der benötigte Treiber zum Mitschnitt von Daten heißt Windows Packet Capture (WinPcap), je nach Update-Stand von felis kann er funktionieren oder auch nicht
Als Lösung bietet es sich an, den Verkehr von eth1 auf router mitzuschreiben, auch dort kommen die Pakete vorbei

Sobald Wireshark bereit ist, deaktivieren wir die LAN-Verbindung auf felis und aktivieren sie anschließend wieder

Bei einer Beobachtung von router aus, können wir alternativ auch einen Neustart von felis durchführen
In beiden Fällen ergibt sich ein Mitschnitt, der dem aus Abbildung 5.17 ähnlich sieht

Eigene Untersuchungen

Untersuchen Sie die einzelnen Pakete und finden Sie heraus, zu welchem Zweck jedes einzelne versendet wurde

Sie können sich dabei auf ICMPv6 beschränken und auch die Teile von MLDv2, die sich um Multicast DNS drehen, ignorieren
Erkennen Sie anhand der Informationen in den Paketen, ob diese sich auf einen zufälligen (Privacy Extensions) oder auf einen EUI-64-basierten Interface Identifier beziehen?

Abbildung 5.18: Interner Link mit DNS-Server

Stateless Address Autoconfiguration (SLAAC) - Automatische Konfiguration von IPv6-Adressen

Autoconfiguration

SLAAC ist Bestandteil der Autoconfiguration, die drei wesentliche Aufgaben hat

Generieren einer Link-local Address
Durchführen der Stateless Address Autoconfiguration
Sicherstellen der Eindeutigkeit der generierten Adressen (Duplicate Address Detection)

Ablauf

Den ersten Schritt macht der Host, indem er mittels Router Solicitation nach einem Router Advertisement fragt
1. Alternativ könnte er auch ein periodisches Router Advertisement abwarten
2. diese Geduld beobachtet man aber eher selten
Der Router verschickt das angeforderte Router Advertisement,welches alle konfigurationsrelevanten Daten enthält
Daraufhin führt der Host die Konfiguration des Interfaces durch und prüft die Eindeutigkeit der selbst erzeugten Adressen
Wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet

Duplicate Address Detection

Duplicate Address Detection besteht aus mehrere Neighbor Solicitations

Wenn ein Node feststellen möchte, ob eine Adresse schon von einem anderen Node genutzt wird,dann versucht er die zugehörige Linklayer Address aufzulösen
Bleibt eine Antwort aus, benutzt offensichtlich kein anderer Node auf dem Link die überprüfte Adresse
Um Fehlschlüsse aufgrund von Paketverlusten zu vermeiden, sollen mehrere Neighbor Solicitations verschickt werden

Ab wann eine Adresse als eindeutig gilt, hängt von den Parametern der jeweiligen Implementierung ab

Jede Adresse hat anfangs den Status tentative (probeweise)
Erst wenn die Duplicate Address Detection vollständig durchlaufen wurde, und keine Anzeichen darauf schließen lassen, dass die Adresse bereits in Benutzung ist, wird die Adresse valid (gültig)

Ablaufverfolgung

Ziel

Komplette Aufzeichnung der Autoconfiguration mit Wireshark
Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration

Interface herunterfahren

# ip link set down dev enp2s0

2: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
   link/ether 74:27:ea:e1:b2:b4 brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.106/24 brd 192.168.1.255 scope global dynamic noprefixroute enp2s0
      valid_lft 4826sec preferred_lft 4826sec

Wireshark starten

auf PseudoInterface any lauschen

$ ssh -X root@localhost
root@localhost's password:

# wireshark&

Interface starten

# ip link set up dev enp2s0
enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether 74:27:ea:e1:b2:b4 brd ff:ff:ff:ff:ff:ff
   inet6 2001::a44d:a161:1a33:c64d/64 scope global dynamic noprefixroute
      valid_lft 86399sec preferred_lft 14399sec
   inet6 fe80::99d7:66e5:331d:9449/64 scope link noprefixroute
      valid_lft forever preferred_lft forever

Aktivität beobachten

In Wireshark können wir bereits Aktivität beobachten. Wir warten den Abschluss der Konfiguration ab, sie ist erfolgreich verlaufen wenn wir Adressen mit den Parametern scope global und dynamic sehen:

# ip addr show dev enp1s0
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether 50:3e:aa:1f:63:81 brd ff:ff:ff:ff:ff:ff
   inet 10.30.1.1/24 brd 10.30.1.255 scope global enp1s0
      valid_lft forever preferred_lft forever
   inet6 fe80::523e:aaff:fe1f:6381/64 scope link
      valid_lft forever preferred_lft forever

Automatische Konfiguration

Stateless Auto-Konfiguration (out-of-the-box)

Wird unterstützt und kann bei der zugewiesenen link-lokalen Adressen beobachtet werden, sobald ein IPv6 fähiges Interface aktiv ist

Beispiel:

Stateless Auto-Konfiguration unter Verwendung des Router Advertisement Daemon (radvd)

Mehr Infos hierzu in späteren Versionen. Siehe unten im Abschnitt radvd daemon autoconfiguration

Dynamic Host Configuration Protocol v6 (DHCPv6)

Nach einer langen Zeit der Diskussion wurde RFC 3315 / Dynamic Host Configuration Protocol for IPv6 (DHCPv6) verabschiedet. Momentan (10/2005) existieren 2 Implementierungen:

Dibbler von Tomasz Mrugalski <thomson at klub dot com dot pl>(Tipps zur Konfiguration)
dhcpv6 (Tipps zur Konfiguration)
ISC DHCP (Tipps zur Konfiguration)

Namensauflösung

Was den Nodes am Link jetzt noch fehlt, ist ein Nameserver für die Namensauflösung

Test

user@linux:~ $ ping -6 -c3 ipv6.foxtom.de

Ohne die Möglichkeit Namen aufzulösen, verschafft selbst die beste Konnektivität wenig Vorteile

Konfiguration DNS

router agiert bereits als zentraler Anlaufpunkt für alle Daten die den Link verlassen sollen

Es bietet sich daher an, ihm auch die Aufgabe der Namensauflösung zuzuteilen

Abbildung: Zielkonfiguration

Der Router selbst, aber auch die Hosts können dann DNS-Anfragen an den installierten Resolving DNS Server (RDNSS) weiterleiten

Dieser kümmert sich um die Auflösung des Namens und teilt dem Anfragenden das Ergebnis mit
Der Einsatz eines Caches sorgt dafür, das zukünftige Anfragen teilweise oder komplett aus diesem beantwortet werden können
Die Geschwindigkeit, mit der eintreffende Anfragen beantwortet werden, wird so im Laufe der Zeit optimiert

Unbound

Nameserver festlegen

Wenn der Server wie erwartet antwortet, definieren wir ihn, falls das System es nicht bereits in vorrauseilendem Gehorsam getan hat, auf router als Standard-Nameserver:

root@router:~# resolvconf -u
root@router:~# cat /etc/resolv.conf
nameserver ::1

In der Datei /etc/resolv.conf sind unter Ubuntu GNU/Linux die Adressen der Nameserver des Systems hinterlegt

Das eben ausgeführte Kommando hat die Datei überschrieben und dabei die Loopback Address als neue Nameserver-Adresse festgelegt
Mit dem Kommando cat haben wir uns den Inhalt der Datei anzeigen lassen

Erreichbarkeit testen

Die Erreichbarkeit des Nameservers testen wir sicherheitshalber auch von einem der Hosts aus

Zum Beispiel durch eine einfache Namensauflösung auf linux

user@linux:~ $ host www.ipv6-workshop.de 
2 a 1 :198:2
Using domain server :
Name : 2 a 1 :198:2 :8 a23 ::1
Address : 2 a 1 :198:2 :8 a23 ::1#53
www.ipv6-workshop.de has IPv6 address 2 1:67 c :26 f4 :8 ::6:8:8 a23 ::1

Die korrekte Auflösung zeigt, dass der Nameserver funktioniert und von den Hosts erreicht und verwendet werden kann

RDNSS

Die RDNSS Option

Nameserver-Adressen lassen sich auch als Option im Router Advertisement unterbringen und so bequem auf dem Link verteilen

Die Option heißt RDNSS Option, ist in RFC 6106 [JPBM10] spezifiziert, und reiht sich ein in die lange Liste der ICMPv6-Optionen
Insgesamt bietet sich uns damit der gleiche Komfort wie beim Betrieb eines sehr einfach gehaltenen DHCP-Servers, nur eben ohne einen dedizierten DHCP-Server für derartige Informationen bereitstellen zu müssen

RDNSS Option im Router Advertisement

Mit der Verteilung der Router Advertisements hatten wir Radvd beauftragt

Wir ergänzen die Konfigurationsdatei gemäß Abbildung 5.20 um die RDNSS Option

Damit die Änderungen wirksam werden, ist ein Neustart von Radvd erforderlich:

root@router:~# service radvd restart
Stopping radvd : radvd
Starting radvd : radvd

Router Advertisement

Selbstverständlich schauen wir uns das neue Router Advertisement in Wireshark an

Auf router fangen wir eines auf Interface eth1 auf
Mit dem notwendigen Vorgehen sind wir inzwischen bestens vertraut

Abbildung: Router Advertisement

Neu hinzugekommen ist die ICMPv6-Option vom Typ 25

Sie enthält die Gültigkeitsdauer des Nameservers in Sekunden sowie die Adresse des Nameservers selbst
Die Gültigkeit mag auf den ersten Blick sehr kurz erscheinen, schließlich ändern sich die Adressen von Nameservern üblicherweise nicht jede Minute

Abbildung: Konfiguration von Radvd mit RDNSS Address

Abbildung: Router Advertisement mit RDNSS Address

/etc/radvd.conf

interface eth1 {
 AdvSendAdvert on ;
 MinRtrAdvInterval 15;
 MaxRtrAdvInterval 6 ;
 AdvCurHopLimit 64;
 AdvManagedFlag off ;
 AdvOtherConfigFlag off ;
 AdvMobRtrSupportFlag off ;
 AdvDefaultPreference medium ;
 AdvDefaultLifetime 3 ;
 AdvReachableTime ;
 AdvRetransTimer ;
 AdvLinkMTU 128 ;
 prefix 2 a 1 :198:2 :8 a23 ::/64 {
  AdvOnLink on ;
  AdvAutonomous on ;
  AdvRouterAddr off ;
  AdvValidLifetime 36 ;
  AdvPreferredLifetime 18
 };
 RDNSS 2 a 1 :198:2 :8 a23 ::1 { };
 AdvSourceLLAddress on ;
};

Alte Denkweise abschütteln

Es ist unter IPv6 keine Seltenheit, wenn ein Link mit mehreren Routern ausgestattet ist
Und jeder Router preist unter Umständen seine ganz eigenen Nameserver an
Verlässt ein Router den Link, sollten auch alle Konfigurationsvariablen die er zuvor verteilt hat, zeitnah an Gültigkeit verlieren
Als Höchstwert für die RDNSS-Lifetime wird das doppelte maximale Sendeintervall (MaxRtrAdvInterval) empfohlen
Mit 60 Sekunden sind wir unter diesem empfohlenen Höchstwert geblieben

Betriebssysteme und die RDNSS Option

Unterstützung für die RDNSS Option ist nicht in allen Betriebssystemen vorhanden

Die Betriebssysteme iOS und OS X von Apple geben ein gutes Bild ab, was die Unterstützung der RDNSS Option angeht
Googles Android funktionierte zwar schon sehr früh gut mit IPv6, wertete aber auch Anfang 2013 bisher nicht die RDNSS Option aus

Unter Linux extrahiert das von vielen Distributionen und Desktop- RDNSS Option Umgebungen verwendete Programm NetworkManager die Na- unter Debian meserver-Adressen aus den Router Advertisements

Anschlie- GNU/Linux ßend fügt es die Informationen in die Datei /etc/resolv.conf des jeweiligen Systems ein
Wir hatten den NetworkManager auf linux in Abschnitt 4.1 Debian GNU/Linux 6 vorläufig entmachtet
Jetzt wo das Netz in seinen Grundzügen steht, darf der NetworkManager wieder die Kontrolle über die Interfaces auf linux übernehmen

Wir starten ihn wieder:

root@linux:~#/etc/init.d/network-manager start
Starting network connection manager : NetworkManager

Damit der NetworkManager auch nach einem Neustart noch arbeitet, fügen wir ihn wieder in die Boot-Sequenz ein

root@linux:~# update-rc

d network - manager enable update - rc .d: using dependency based boot sequencing

Abbildung: NetworkManager - Einstellungen und Profile

Abbildung: Profil Auto eth0 auf linux

NetworkManager

Konfiguration durch NetworkManager
Auf dem Desktop befindet sich der NetworkManager in der oberen Leiste

Ein Symbol bestehend aus zwei verbundenen Computern bietet Zugriff auf die Oberfläche des Programms
Mit einem Linksklick werden die verfügbaren Profile angezeigt und mit einem Rechtsklick gelangt man in das Konfigurationsmenü
In letzteres begeben wir uns und wählen dann den Punkt Edit Connections (Abbildung 5.22) aus

Nun öffnet sich eine nach Interfaces sortierte Liste verfügbarer Profile

Im Tab Wired suchen wir ein Profil zum Interface eth0, der Name könnte zum Beispiel Auto eth0 lauten
Mit einem Klick auf Edit gelangen wir zu den Einstellungen des Profils (Abbildung 5.23)

Die Einstellungen für IPv4 stellen wir auf Disabled, die für IPv6 auf Automatic

Weitere Angaben sind nicht nötig für unseren Link, denn dort verteilen wir alle wichtigen Informationen mit den Router Advertisements
Wir schließen die offenen Dialoge und aktivieren das eben bearbeitete Profil mit einem Linksklick auf das NetworkManager-Symbol
Das Symbol zeigt für einen kurzen Augenblick Aktivität an und beruhigt sich wieder, sobald die Konfiguration erfolgreich verlaufen ist

Überprüfen der Konfiguration

Davon werden wir uns überzeugen und lassen uns die Adressen des Interfaces anzeigen:

user@linux :~ $ ip addr show dev eth
2: eth : < BROADCAST , MULTICAST ,UP , LOWER_UP > mtu 15
'
qdisc pfifo_fast state UP qlen 1
link / ether
: : :6 : d :1 e brd ff : ff : ff : ff : ff : ff inet6 2 a 1 :198:2 :8 a23 :2 : ff : fe6 : d1e /64 scope '
global dynamic valid_lft 36 sec preferred_lft 18 sec inet6 fe8 ::2 : ff : fe6 : d1e /64 scope link valid_lft forever preferred_lft forever

Es zeigt sich das gewohnte Bild, die Autoconfiguration hat korrekt gearbeitet

Mit dem Kommando cat lassen wir uns den Inhalt der Datei /etc/resolv.conf anzeigen:

user@linux :~ $ cat /etc/resolv.conf
# Generated by NetworkManager nameserver 2 a 1 :198:2 :8 a23 ::1

Der NetworkManager hat die Nameserver-Adresse richtig aus dem Router Advertisement extrahiert und sie dem System bekannt gemacht

Der obligatorische Test beweist das Funktionieren der Namensauflösung und des Routings auf linux:

user@linux :~ $ ping6 -c 3 ping

RDNSS Option unter Windows 8 Windows 8 unterstützt die RDNSS Option leider nicht von Haus aus

Es gibt ein Programm namens rdnssd-win32 welches die Funktionalität nachrüstet, dieses stammt aber nicht

Abbildung 5.24: Einstellungen von LAN1 aufrufen

Abbildung 5.25: Protokolle von LAN1

von offizieller Seite (http://sourceforge.net/projects/rdnssd-win32/).Die Hoffnungen ruhen auf einer Nachrüstung durch eines der kommenden Service Packs

Es bleibt uns nichts anderes übrig, als die Adresse des Nameservers manuell einzutragen

Dazu öffnen wir das Connection and Sharing Center und wählen dann Change adapter settings (Abbildung 5.24) Ein Rechtsklick auf den Adapter LAN1 und dann auf Properties bringt uns zur Liste der Protokolle

In der Protokollliste, dargestellt in Abbildung 5.25, ist IPv4 deaktiviert und IPv6 aktiviert

Wir wählen IPv6 aus und öffnen mit einem Klick auf Properties den Dialog zur IPv6-Konfiguration

Abbildung 5.26: IPv6Konfiguration von LAN1

Abbildung 5.27: Website des KAME-Projekts

Während die Einstellungen für die Adresse unverändert auf automatically stehen bleiben, erfordern die Nameserver-Einstellungen unser Zutun

Wie in Abbildung 5.26 gezeigt, tragen wir die Nameserver-Adresse ein

Bitte beachten Sie: Ihre Nameserver-Adresse wird anders lauten als jene in den Abbildungen

Die korrekte Adresse können Sie Ihrer Radvd-Konfiguration entnehmen

Nach der Konfiguration schließen wir alle noch offenen Dialoge und schreiten zum Test der Einstellungen Zur Abwechslung besuchen wir diesmal die Website des Überprüfen der KAME-Projekts unter http:// www.kame.net

Mit der Namensauf- Konfiguration lösung und der tanzenden Schildkröte (Abbildung 5.27) ist der Nachweis erbracht, dass auch auf felis alle Einstellungen korrekt vorgenommen wurden

</noinclude>

Anhang

Siehe auch

Links

Weblinks