|
|
| (85 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| === Präfix ===
| | '''Präfix''' - Präfix für den Link |
| ; Präfix für den Link
| | |
| === Automatische Konfiguration === | | == Beschreibung == |
| ; Link internal soll ein Global-Unicast-Präfix erhalten, um am IPv6-Internet teilnehmen zu können. | | == Automatische Konfiguration == |
| * Eine manuelle Konfiguration der Hosts am Link möchten wir möglichst vermeiden. | | ; Link internal soll Global-Unicast-Präfix erhalten |
| | * Teilnahme am IPv6-Netzwerk |
| | * Manuelle Konfiguration vermeiden |
|
| |
|
| ; Nach einer automatisierten Konfiguration sollen die Hosts mit | | ; Nach einer automatisierten Konfiguration sollen die Hosts mit |
| * einer oder mehreren IPv6-Adressen, | | * einer oder mehreren IPv6-Adressen |
| * der Adresse des zuständigen Routers und | | * der Adresse des zuständigen Routers und |
| * der Adresse eines Resolving Nameservers ausgestattet sein. | | * 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 ===
| | == Resolving Nameserver == |
| Versuchen Sie mithilfe des Kommandos man radvd.conf das eben beschriebene Router Advertisement zu konfigurieren.
| | Ein Resolving Nameserver wäre, technisch gesehen, für das Herstellen der Konnektivität nicht erforderlich |
| * Die Lösung: | | * 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 |
|
| |
|
| === Angepasste Konfiguration von Radvd ===
| | == Aufgabenteilung == |
| /etc/radvd.conf
| | Welche Teile der automatischen Konfiguration der Router erledigt, und wo die Hosts selbst tätig werden müssen, werden wir gleich erfahren |
| interface eth1 {
| | * Soviel vorweg: Die Konfigurationen werden nicht als mundfertige Häppchen serviert, wie es bei IPv4 in Verbindung mit DHCP üblich ist |
| AdvSendAdvert on ;
| | * Einer erfolgreichen Konfiguration geht immer ein Zusammenspiel von Router und Host voraus |
| 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 | | == Präfix aktivieren == |
| | ; 64 Bits langes Präfix des Tunnelbrokers |
| | * Das Präfix werden wir für die Adressierung der Nodes auf dem internen Link verwenden |
| | * Dazu stellen wir sicher, dass das Präfix bei dem Tunnelbroker aktiviert ist |
| | * Im Home-Bereich der Tunnelbrokers-Website befindet sich eine Tabelle mit Präfixen, die dort Subnets genannt werden |
| | * In der Spalte State sollte für das zu unserem Tunnel gehörende Präfix Enabled stehen |
| | * In der Spalte Subnet Präfix finden wir jenes Präfix, welches über unseren Tunnel geroutet wird |
| | * In den Beispielen lautet es ''2a01:198:200:8a23::/64'' |
| | ** Notieren für spätere Verwendung! |
|
| |
|
| Zum Anwenden der geänderten Konfiguration starten wir Radvd neu:
| | == Router Advertisement == |
| root@fuzzball :~# service radvd restart
| | [[Router Advertisement]] |
| Stopping radvd : radvd. | |
| Starting radvd : radvd.
| |
|
| |
|
| Das neue Router Advertisement fangen wir ebenfalls mit Wireshark auf lynx auf.
| | <noinclude> |
| * Es ist zur Kontrolle in Abbildung 5.8 zu sehen.
| | == Anhang == |
| | === Siehe auch === |
| | {{Special:PrefixIndex/{{BASEPAGENAME}}}} |
| | ==== Links ==== |
| | ===== Weblinks ===== |
|
| |
|
| [[Kategorie:IPv6/Link]] | | [[Kategorie:IPv6/Link]] |
| | </noinclude> |