Kategorie:IPv6/Link

Der Link

Im Moment ist der Link internal noch relativ unbelebt.

• Die Nodes haben gelegentlich über Link-local Addresses miteinander kommuniziert, dabei die gegenseitige Erreichbarkeit nachgewiesen und ihre Neighbor Caches gepflegt.
• Was den Hosts fehlt, ist der Zugang zur großen weiten IPv6-Welt.
• Da könnte fuzzball weiterhelfen, er hat dank des Tunnels bereits Zugang zu ihr.
• Im Folgenden werden wir daher den Router fuzzball bestimmungsgemäß einsetzen, die Hosts mit gültigen, weltweit eindeutigen Adressen versorgen sowie ihre Konnektivität überprüfen.

Ein Präfix für den Link

Automatische Konfiguration

Der Link internal soll ein Global-Unicast-Präfix erhalten um am IPv6-Internet teilnehmen zu können.

• Eine manuelle Konfiguration der Hosts am Link möchten wir möglichst 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

Der 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

Ein 64 Bits langes Präfix haben wir von SixXS als kostenlose Beigabe zum Tunnel erhalten.

• 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 SixXS

aktiviert ist.

• Im Home-Bereich der SixXS-Website befindet sich eine Tabelle mit Präfixen, die dort Subnets genannt werden (siehe auch Abbildung 3.11 auf Seite 53).
• 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 im Workshop lautet es 2a 1:198:2 :8a23::/64. Wir notieren uns das eigene Präfix für die spätere Verwendung.

Router Advertisement

Unter IPv6 gehört es zum guten Ton, dass sich ein Router am Link bekannt macht.

• Dabei liefert er auch Informationen zu den verwendeten Präfixen mit, insbesondere zu den Präfixen für die er selbst zuständig ist.
• Eine solche Information wird Router Advertisement genannt.
• Router Advertisements sind Teil von NDP und werden, wie von NDP gewohnt, über

ICMPv6 transportiert.

• Wir werden fuzzball dazu bewegen, solche Router Advertisements am Link internal auszusenden.

Router Advertisement Daemon

Dazu werden wir den Router Advertisement Daemon, kurz Radvd, verwenden.

• Die Installation gelingt, wie gewohnt, über den Paketmanager:

Minimale Konfiguration von Radvd

/etc/radvd.conf

interface eth1 {
AdvSendAdvert on ;
MinRtrAdvInterval 15;
prefix 2 a 1 :198:2 :8 a23 ::/64 { };
};

root@fuzzball :~# apt - get install radvd
The following NEW packages will be installed :
radvd
upgraded , 1 newly installed , to remove and upgraded.
Starting radvd:
* /etc/radvd.conf does not exist or is empty.
* See /usr/share/doc/radvd/README.Debian
* radvd will *not* be started.

Radvd wird mit einer ausführlichen Dokumentation ausgeliefert.

• Die Dokumentation lässt sich mit den Kommandos man radvd und man radvd.conf anzeigen.

Erstkonfiguration von Radvd

Aufgrund fehlender Konfigurationsdatei verweigert Radvd noch die Aufnahme der Arbeit.

• Die Konfiguration reichen wir sogleich nach.
• Dazu bearbeiten wir die Datei /etc/radvd.conf gemäß Abbildung.

Für jedes Interface auf dem Radvd Router Advertisements versenden soll, enthält die Konfigurationsdatei einen interface-Block.

• Das eigentliche Senden erlaubt oder verbietet der Parameter AdvSendAdvert.
• Mit MinRtrAdvInterval legen wir die Zeit in Sekunden fest, die zwischen zwei periodisch versandten Router Advertisements vergehen soll. 15 Sekunden ist ein guter Wert für einen Link dieser Größe.
• Anstelle von 2a 1:198:2 :8a23::/64 setzen Sie bitte das Präfix ein, dass Sie sich vorhin von der SixXS-Seite notiert haben.

Interface konfigurieren

Bevor wir Radvd neu starten, erhält das Interface eth1 noch eine Adresse aus dem Präfix das verteilt werden soll:

root@fuzzball :~# ip addr add 2a01:198:200:8a23::1/64 dev eth1

Permanente Konfiguration von eth1

/etc/network/interfaces

# Loopback Interface
auto lo
iface lo inet loopback

# Interface an VirtualBox auf dem Wirtsystem
allow-hotplug eth0
iface eth0 inet dhcp

# Interface am Link " internal "
auto eth1
iface eth1 inet6 static
address 2 a 1 :198:2 :8 a23 ::1
netmask 64

Der wichtigste Effekt des letzten Schritts ist eine Veränderung in der Routingtabelle von fuzzball:

user@fuzzball :~ $ ip -6 route show
2a01:198:200:a23::/64 dev sixxs proto kernel metric 256 mtu 128 advmss 122 hoplimit 4294967295
2a01:198:200:8a23::/64 dev eth1 proto kernel metric 256 mtu 15 advmss 144 hoplimit 4294967295
default via 2a01:198:200:a23::1 dev sixxs metric 1 24 mtu 128 advmss 122 hoplimit 4294967295

Ohne den Eintrag für eth1 liefe fuzzball Gefahr, ein Präfix auf Interface eth1 zu verteilen, zu dem er selbst keine Route kennt.

• Für einen Router eine sehr ungünstige Situation, denn diese Pakete würde er dann schlicht verwerfen.

Damit das Interface auch nach dem nächsten Neustart wieder so konfiguriert wird, aktualisieren wir die Datei /etc/network/interfaces auf fuzzball gemäß Abbildung.

Die Konfiguration des Interfaces wird ab jetzt statisch erfolgen.

• Die Direktiven up und down haben nun ausgedient und werden durch address und netmask ersetzt.

Forwarding aktivieren

Ein Router ist ein Node der Pakete weiterleitet.

• Als Fachbegriff dafür hat sich das englische forwarding durchgesetzt.
• Das Forwarding müssen wir fuzzball explizit erlauben, denn aus Sicherheitsgründen ist es standardmäßig deaktiviert.
• Dazu editieren wir die Datei /etc/sysctl.conf wie in Abbildung gezeigt.

/etc/sysctl.conf (Auszug)

# Uncomment the next line to enable packet forwarding for IPv6
# Enabling this option disables Stateless Address Autoconfiguration
# based on Router Advertisements for this host
net.ipv6.conf.all.forwarding=1

IPv6-Forwarding permanent aktivieren

Abbildung 5.4

IPv6-Header eines Router Advertisements

Die Änderungen werden erst nach dem nächsten Neustart aktiv.

• Alternativ können wir die Prozedur abkürzen und die Änderungen sofort wirksam werden lassen:

root@fuzzball:~# sysctl -p net.ipv6.conf.all.forwarding = 1

Jetzt kann fuzzball anfangen Router Advertisements zu versenden.

• Wir starten den zuständigen Daemon:

root@fuzzball :~# service radvd start
Starting radvd : radvd .

Nun sollte Radvd periodische Router Advertisements aussenden.

Router Advertisement mitschneiden

Natürlich werden wir auch den Beweis antreten und ein solches Router Advertisement auf dem Link entdecken.

• Wir starten Wireshark auf lynx und lassen ihn auf eth0 lauschen.
• Spätestens nach 15 Sekunden sollte das erste Router Advertisement aufgefangen werden.
• Das werden wir uns nun genauer anschauen.
• Es sollte den Abbildungen 5.4 und 5.5 recht nahe kommen.

Abbildung 5.5

Router Advertisement nach Minimalkonfiguration

IPv6-Header des Router Advertisements

Betrachten wir zunächst den IPv6-Header des Paketes (Abbildung 5.4).

• Das Feld Next Header verweist auf ICMPv6, dem Transportprotokoll von NDP.
• Folgerichtig ist das Hop Limit auf

255 gesetzt.

• Die Quelladresse ist die Link-local Address von eth1, was von RFC 2461 [NNS98] so vorgeschrieben wird.
• Die Zieladresse für periodisch versandte Router Advertisements ist die All Nodes Multicast Address ff 2::1.
• Ihr Multicast Scope ist, das haben wir bereits gelernt, an der vierten hexadezimalen Stelle verzeichnet.
• Hier handelt es sich um den Scope Link, da wir an vierter Stelle eine 2 finden.
• Von den Flags, an dritter hexadezimaler Stelle zu finden, ist keines gesetzt.
• Denn nur wenn kein Flag gesetzt ist, kann an die dritte hexadezimale Stelle 0 lauten.
• Somit ist auch das TransientFlag nicht gesetzt.
• Daher können wir uns sicher sein, dass es sich bei dieser Multicast Address um eine Well-known Multicast Address handelt.
• Tatsächlich finden wir sie in Tabelle 4.5 auf Seite 103 wieder.
• Das Wissen um den Aufbau von

Multicast Addresses hat uns bereits ein erstes Mal weitergeholfen.

Router Advertisement im Detail

In der ICMPv6-Nachricht (Abbildung 5.5) sehen wir an erste Stelle die Typnummer 134 für Router Advertisements.

• Nach Code und Checksum folgt ein Feld namens Cur Hop Limit, es hat in unserem Beispiel den Wert 64.
• Das Cur Hop Limit gibt an, welches Hop Limit ein Host, der seinen Stack gemäß den Angaben dieses Router Advertisements konfiguriert, nutzen soll.
• Hat das Feld den Wert 0, dann gibt es keine Vorgabe durch den Router, der Host entscheidet dann selbst welches Hop Limit er für IPv6-Pakete verwendet.

Router Advertisement Flags

Es folgen Flags, von denen hier keines gesetzt ist.

• Möglich wären folgende Flags:

Managed

Das Managed Flag zeigt einem interessierten Host an, dass er auf anderen Wegen Adressen erhalten kann.

• Andere Wege meint zum Beispiel DHCPv6 und wird auch als stateful configuration bezeichnet.
• Nicht zu verwechseln mit der im Deutschen ähnlichen klingenden statischen Konfiguration.

Other Managed

Mit diesem Flag informiert der Router darüber, dass weitere Konfigurationsdaten über einen anderen Weg bezogen werden können.

• Auch hier ist in der Regel DHCPv6

gemeint, welches beispielsweise Nameserver-Adressen zur Verfügung stellen könnte.

Home Agent

Ein gesetztes Flag zeigt an, dass dieser Router als Home Agent für Mobile IPv6 genutzt werden kann.

Router Preference

Eigentlich handelt es sich bei der Router Preference nicht um ein Flag im klassischen Sinne.

• Es werden zwei Bits im Flag-Feld genutzt um die Priorität des Routers zu codieren.
• Es gibt die Werte low, medium und high.
• Sollten mehrere Default-Router am Link präsent sein, wird die Priorität auf den Hosts unter Berücksichtigung dieses Flags festgelegt.

Proxy

Dieses Flag wurde im experimentellen RFC 4389 [TTP06] vorgeschlagen.

• Es deutet auf das Vorhandensein eines NDP-Proxys hin.
• Für uns ist das Flag nicht relevant und wir behandeln es im Folgenden nicht weiter.

Die Flags können, geschickt kombiniert, sehr unterschiedliche Situationen abdecken.

• So wäre es zum Beispiel möglich, den Hosts zwar die eigenständige Adresskonfiguration zu erlauben, ihnen alle zusätzlichen Informationen jedoch per DHCPv6 zuzustellen.

Router Lifetime

Im Router Advertisement folgt als nächstes die Router Lifetime in Sekunden.

• Sie gibt an, wie lange dieser Router als DefaultRouter verwendet werden darf.
• Der Wert 0 bedeutet, dass der

Router nicht als Default-Router verwendet werden darf.

• In unserem Fall bedeutet das, dass der Router nach 1800 Sekunden (einer halben Stunde) ungültig werden würde.
• Mit jedem neuen Router Advertisement kann dieser Wert überschrieben werden.
• Da wir alle 15 Sekunden ein Router Advertisement aussenden, sollten wir vorerst nicht Gefahr laufen, den DefaultRouter zu verlieren.

Reachable Time und Retrans Timer

Die Felder Reachable Time und Retrans Timer dienen den Stacks der Hosts als Anhaltspunkte für ihre eigene Konfiguration.

• Die Reachable Time legt fest, wie viele Millisekunden ein Nachbar auf dem Link als erreichbar gilt, nachdem eine Bestätigung der Erreichbarkeit eingetroffen ist.

Hinweis

Als Bestätigung der Erreichbarkeit können alle Pakete dienen, die darauf schließen lassen, das der Nachbar erreichbar ist.

• Zum Beispiel können das eintreffende Pakete einer bestehenden TCP-Verbindung sein.
• Es muss sich nicht zwingend um NDP handeln.

Der Retrans Timer legt die Wartezeit zwischen zwei Neighbor Solicitations in Millisekunden fest.

• Die Werte dieser Felder haben also direkten Einfluss auf die Neighbor Caches der Hosts.
• Wenn die Felder den Wert enthalten, macht der Router keine Vorgaben und die Hosts können ihre eigene Konfiguration verwenden.

Präfix-Informationen

Unser Router Advertisement liefert zwei ICMPv6-Optionen mit. Die Option Source Link-layer Address kennen wir schon aus anderen NDP-Paketen.

• Die Prefix Information Option aus Abbildung 5.6 hingegen ist uns neu.

Wie jede ICMPv6-Option hat sie eine Typnummer und eine Längenangabe.

• Daran schließt sich das Feld Prefix Length an, es gibt an wie viele Bits des Präfixes von Router vorgegeben werden.
• In diesem Fall sind es 64 Bits, so dass den Hosts weitere 64 Bits für ihre Interface Identifier zur Verfügung stehen.

Abbildung 5.6

Prefix Information Option

Präfix-Flags

Jedes Präfix hat ein eigenes Feld für Flags.

• Die Bedeutung der Flags ist wie folgt:

On-Link

Ist das Flag gesetzt, zeigt der Router damit an, dass dieses Präfix sich auf dem Link befindet.

• Pakete an Adressen innerhalb des Präfixes können direkt gesendet werden, und brauchen nicht über den Router gehen.
• Wenn das Flag nicht gesetzt wurde, bedeutet das lediglich, dass der Router keine Aussage treffen konnte.

Autonomous Address-Configuration

Das Flag wird gesetzt wenn das Präfix den Hosts für die Stateless Address Autoconfiguration zur Verfügung steht.

Router Address

Wenn das Flag gesetzt ist, befindet sich im Präfix-Feld anstelle eines Präfixes die Adresse des Interfaces welches für Mobile IPv6 zuständig ist.

• Dieses Flag nutzen wir im Workshop nicht.

Valid Lifetime und Preferred Lifetime

In den Feldern Valid Lifetime und Preferred Lifetime wird festgelegt, wie lange das Präfix gültig (valid) ist und bevorzugt (preferred) werden soll.

• Generierte Adressen aus dem Präfix erben diese Eigenschaften.
• Für neue Verbindungen werden stets bevorzugte Adressen genutzt.
• Adressen bestehender Verbindungen können während der Valid Lifetime noch genutzt werden, dürfen aber nicht für neue Verbindungen hergenommen werden.
• Die Angaben erfolgen jeweils in Sekunden.
• Der höchstmögliche Wert steht abweichend für unbegrenzte Gültigkeit.

Das Präfix

Das letzte, und wohl wichtigste, Feld ist das Präfix selbst.

• Der Teil hinter der mit Prefix Length definierten Grenze wird üblicherweise mit Nullen aufgefüllt und von den Hosts ignoriert.
• Unser Router hat hier das Präfix 2a 1:198:2 :8a23:: verteilt, so wie wir es Radvd aufgetragen haben.

Angepasstes Router Advertisement

Jetzt, wo wir uns mit Router Advertisements besser auskennen, werden wir unsere Minimalkonfiguration von Radvd etwas leistungssteigern.

• Die Router Advertisements sollen weiterhin in Abständen von mindestens 15 Sekunden ausgesendet werden, es sollen aber nie mehr als 60 Sekunden zwischen ihnen liegen.
• Das Hop Limit und die Flags erhalten Standardwerte, diese sollen zur Übung dennoch in der Konfigurationsdatei vermerkt werden.
• Der Router soll mit mittlerer Priorität als DefaultRouter angepriesen werden.

Da der Tunnel in der Standardkonfiguration eine MTU von 1280 aufweist, propagieren wir diese MTU auf dem Link.

• Die Link MTU wird später als weitere ICMPv6-Option im Router Advertisement auftauchen.

Das Präfix soll mit gesetzten Flags für On-Link und Autonomous Address Autoconfiguration verteilt werden.

• Generierte Adressen sollen eine Stunde lang gültig sein und für eine halbe Stunde bevorzugt werden.

Natürlich darf auch die Source Link-layer Address nicht fehlen.

Radvd konfigurieren

Versuchen Sie mithilfe des Kommandos man radvd.conf das eben beschriebene Router Advertisement zu konfigurieren.

• Die Lösung:

Angepasste Konfiguration von Radvd

/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

};

AdvSourceLLAddress on ;
};

Abbildung 5.8

Angepasstes Router Advertisement

Zum Anwenden der geänderten Konfiguration starten wir Radvd neu:

root@fuzzball :~# service radvd restart
Stopping radvd : radvd.
Starting radvd : radvd.

Das neue Router Advertisement fangen wir ebenfalls mit Wireshark auf lynx auf.

• Es ist zur Kontrolle in Abbildung 5.8 zu sehen.

Stateless Address Autoconfiguration

Zweck

Die Stateless Address Autoconfiguration, kurz SLAAC, dient der automatischen Konfiguration von Adressen und Routen der Hosts am Link. 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.

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)

Prinzipieller Ablauf

Abbildung 5.9 Prinzip von SLAAC

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

Wir werden versuchen eine komplette Autoconfiguration von lynx mit Wireshark aufzufangen. Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration. Dazu öffnen wir ein root-Terminal auf lynx und fahren das Interface eth0 herunter:

root@lynx :~# 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@lynx :~# 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@lynx :~ $ 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 lynx verschickt. Der IPv6-Header ist in Abbildung 5.10 zu sehen.

Abbildung 5.10 SLAAC Paket 1

IPv6-Header

Als Quelladresse hat lynx 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 lynx.

Gruppenbeitritt

Zu diesem Zeitpunkt hat lynx also 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 lynx 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 lynx 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 lynx gewählte Adresse sehr wahrscheinlich

Abbildung 5.12

SLAAC Paket 2: Neighbor Solicitation

auf dem Link noch nicht vergeben. 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 lynx 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 lynx 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 Router

Abbildung 5.13

SLAAC Paket 3: Router Solicitation

Advertisement zukommen. Die Anforderung der Router Advertisements geschieht mit Hilfe einer Router Solicitation, die in Abbildung 5.13 zu sehen ist.

Die Nachricht wird von der Link-local Address des Hosts gesendet, hier von der Adresse fe8 ::2 :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 fuzzball, 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 lynx eine Global Unicast Address. Dazu verwendet er das von fuzzball 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 lynx 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

Abbildung 5.15 SLAAC Paket 5

Multicast Listener Report

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.

Duplicate Address Detection (Global Unicast)

Der letzte Schritt ist die Durchführung der Duplicate Address Detection für die Global Unicast Address. Dazu sendet lynx 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 lynx steht nun nichts mehr im Wege. Dazu verschicken wir Echo Requests von lynx an den Tunnelendpunkt von SixXS:

user@lynx :~ $ 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@lynx :~ $ 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 fuzzball. Schon in der zweiten Zeile ist das Ziel erreicht.

SLAAC unter Windows 8

Nun werden wir die eben erworbenen Fähigkeiten zur Analyse einer Autoconfiguration auf felis anwenden. 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 8

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

Leider kommt es unter Windows 8 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 fuzzball 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 fuzzball 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

Namensauflösung

Was den Nodes am Link jetzt noch fehlt, ist ein Nameserver für die Namensauflösung. Ein kleiner Test deckt den Missstand auf:

user@lynx :~ $ ping6 -c 3 ping . ipv6 - workshop . de unknown host

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

Zielkonfiguration DNS

Der 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. Die Zielkonfiguration ist in Abbildung 5.18 zu sehen. Der Router selbst, aber auch die Hosts können dann DNSAnfragen 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.

Installation von Unbound

Ein schlanker und einfach zu konfigurierender Nameserver ist Unbound. Seine Stärke ist das Auflösen von Namen und das Cachen der Ergebnisse. Das Ausliefern von Zonendaten hingegen ist nur sehr begrenzt möglich. Wenn Sie auch auf diesem Gebiet experimentieren möchten, sollten Sie zu Bind9 als Nameserver greifen. Im Workshop werden wir mit Unbound arbeiten, ein Austausch ist aber jederzeit möglich.

Installiert wird Unbound über die Paketverwaltung:

root@fuzzball :~# apt - get install unbound
Reading package lists ... Done
After this operation , 2 ,261 kB of additional disk space will be used.
Do you want to continue [Y/n ]? y
Setting up unbound (1.4.16 -1) ...
* Starting recursive DNS server unbound [ OK ]

Konfiguration von Unbound

Der Nameserver soll sowohl für die Hosts am Link, als auch für fuzzball selbst, zuständig sein. Er muss daher auf der Loopback Address und auf einer der Adressen von Interface eth1 lauschen. Auf den ersten Blick mag sich da die Linklocal Address anbieten, schließlich befindet sich keiner der potentiellen Benutzer außerhalb des lokalen Scopes. Leider akzeptieren nicht alle Betriebssysteme einen Resolving Nameserver mit einer Link-local Address. Manche stören sich auch an der Schreibweise mit Interface hinter der Adresse: fe8 ::1%eth . Es bleibt uns also nichts anderes übrig, als eine Global Unicast Address zu verwenden. Der Dienst soll auf dem Standard-Port 53 angeboten werden. Eine Zugriffskontrolle erlaubt dem Präfix des Links internal den Zugriff auf den DNS-Server. Versuchen Sie sich ruhig selbst an der Konfiguration! Mit dem Kommando man unbound.conf erhalten Sie alle benötigten Informationen zur Konfigurationsdatei.

Unter Beachtung der eben genannten Anforderungen ergibt sich eine Konfiguration wie in Abbildung 5.19 gezeigt. Sobald die Konfigurationsdatei geschrieben wurde, starten wir den Nameserver neu:

root@fuzzball :~# service unbound restart
* Restarting recursive DNS server unbound [ OK ]

Nameserver testen

Mit dem Kommando host können wir uns von der Funktion des Nameservers überzeugen. Das erste Argument ist der aufzulösende Hostname, das zweite und optionale Argument benennt

Abbildung 5.19 Konfiguration von Unbound

/etc/unbound/unbound.conf

server :
 verbosity : 1

 interface : ::1
 interface : 2a01:198:200:8a23::1

 port : 53

 access - control : ::1/128 allow
 access - control : 2a01:198:200:8a23::/64 allow

den zu befragenden Nameserver. Wir werden natürlich unseren eigenen Nameserver befragen, weshalb wir ihn auf der Loopback Address ansprechen:

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

Nameserver festlegen

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

root@fuzzball :~# resolvconf -u
root@fuzzball :~# 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 lynx:

user@lynx :~ $ 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 uns, dass der Nameserver funktioniert und von den Hosts erreicht und verwendet werden kann.

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@fuzzball :~# service radvd restart
Stopping radvd : radvd.
Starting radvd : radvd.

Router Advertisement

Selbstverständlich schauen wir uns das neue Router Advertisement in Wireshark an. Auf fuzzball fangen wir eines auf Interface eth1 auf. Mit dem notwendigen Vorgehen sind wir inzwischen bestens vertraut. In Abbildung 5.21 ist das Router Advertisement zu sehen.

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

Abbildung 5.20

Konfiguration von Radvd mit RDNSS Address

Abbildung 5.21

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 ;
};

Minute. Wie so häufig, müssen wir auch hier wieder eine 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

Die hostseitige Unterstützung für die RDNSS Option ist leider 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 noch 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 lynx 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 lynx übernehmen.

Wir starten ihn wieder:

root@lynx :~# / 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@lynx :~# update - rc . d network - manager enable update - rc .d: using dependency based boot sequencing

Abbildung 5.22 NetworkManager

Einstellungen und Profile

Abbildung 5.23 Profil Auto eth0 auf lynx

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@lynx :~ $ 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@lynx :~ $ cat / etc / resolv . conf

1. 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 lynx:

user@lynx :~ $ ping6 -c 3 ping . ipv6 - workshop . de
PING ping . ipv6 - workshop . de ( ping . ipv6 - workshop . de ) 56 '
data bytes
64 bytes from ping . ipv6 - workshop . de : icmp_seq =1 ttl =58 '
time =44.8 ms
3 packets transmitted , 3 received , % packet loss , time '
2 2 ms

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.