|
|
| (8 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 3: |
Zeile 3: |
| == Beschreibung == | | == Beschreibung == |
| == Automatische Konfiguration == | | == Automatische Konfiguration == |
| ; Link internal soll ein Global-Unicast-Präfix erhalten | | ; Link internal soll Global-Unicast-Präfix erhalten |
| * um am IPv6-Netzwerk teilnehmen zu können | | * Teilnahme am IPv6-Netzwerk |
| * Manuelle Konfiguration vermeiden | | * Manuelle Konfiguration vermeiden |
|
| |
|
| Zeile 13: |
Zeile 13: |
|
| |
|
| == Resolving Nameserver == | | == Resolving Nameserver == |
| ; Ein Resolving Nameserver wäre, technisch gesehen, für das Herstellen der Konnektivität nicht erforderlich
| | Ein Resolving Nameserver wäre, technisch gesehen, für das Herstellen der Konnektivität nicht erforderlich |
| * In der Praxis erweisen sich Hosts ohne funktionierende Namensauflösung aber als mühsam bedienbar | | * 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 | | * Für die tägliche Arbeit mit dem Internet sind sie schlicht nicht geeignet |
|
| |
|
| == Aufgabenteilung == | | == Aufgabenteilung == |
| ; Welche Teile der automatischen Konfiguration der Router erledigt, und wo die Hosts selbst tätig werden müssen, werden wir gleich erfahren
| | 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 | | * 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 | | * Einer erfolgreichen Konfiguration geht immer ein Zusammenspiel von Router und Host voraus |
| Zeile 33: |
Zeile 33: |
|
| |
|
| == Router Advertisement == | | == Router Advertisement == |
| ; Unter IPv6 gehört es zum guten Ton, dass sich ein Router am Link bekannt macht
| | [[Router Advertisement]] |
| * 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 ==
| |
| [[Router Advertisement Daemon]] | |
| | |
| == 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 ff02::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
| |
| | |
| == 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 Flags:
| |
| | |
| {| class="wikitable sortable options"
| |
| |-
| |
| ! Flag !! Beschreibung
| |
| |-
| |
| | 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:
| |
| | |
| {| class="wikitable sortable options"
| |
| |-
| |
| ! Flag !! Beschreibung
| |
| |-
| |
| | 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
| |
| |-
| |
| | 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 ''2a01:198:200:8a23::'' verteilt, so wie wir es Radvd aufgetragen haben
| |
| |}
| |
| | |
| == Angepasstes Router Advertisement ==
| |
| ; Minimalkonfiguration von Radvd 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
| |
| [[File:abb5.8.png|mini|400px|Angepasstes Router Advertisement]]
| |
| 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 2a01:198:200:8a23::/64 {
| |
| AdvOnLink on ;
| |
| AdvAutonomous on ;
| |
| AdvRouterAddr off ;
| |
| AdvValidLifetime 36 ;
| |
| AdvPreferredLifetime 18
| |
| };
| |
| AdvSourceLLAddress on ;
| |
| };
| |
| | |
| 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
| |
|
| |
|
| <noinclude> | | <noinclude> |