|
|
| (8 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| === Beschreibung ===
| | [[Kategorie:IPv6]] |
| ; Zur Zeit ist Link internal noch 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.
| |
| | |
| === Präfix ===
| |
| ; Präfix für den Link
| |
| ==== Automatische Konfiguration ====
| |
| ; 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
| |
| ** Notieren 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.
| |
| | |
| ; Installation
| |
| root@fuzzball :~# apt 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.
| |
| | |
| ==== Minimale Konfiguration von Radvd ====
| |
| /etc/radvd.conf
| |
| interface eth1 {
| |
| AdvSendAdvert on ;
| |
| MinRtrAdvInterval 15;
| |
| prefix 2 a 1 :198:2 :8 a23 ::/64 { };
| |
| };
| |
| | |
| 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 ====
| |
| ; Router Advertisements 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 ====
| |
| ; 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 Minute.
| |
| | |
| : 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 ;
| |
| };
| |
| | |
| | |
| 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
| |
| # 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
| |
| | |
| 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.
| |