IPv6/Link/Präfix

Aus Foxwiki

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

/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.
Abgerufen von „https://wiki.foxtom.de/index.php?title=IPv6/Link/Präfix&oldid=76739“