Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:radvd [03.07.2024 21:26. ] – [Lösung] django
+++ linux:radvd [10.07.2024 18:40. ] (aktuell) – [RA — Router Advertisement (ICMPv6 type 134)] django
@@ Zeile 1: / Zeile 1: @@
+~~NOCACHE~~
 ====== Router Advertisements mit radvd unter Arch Linux einrichten und nutzen ======
 {{:linux:radv-daemon-icon.png?nolink&191 |Bild: Icon Router Advertisement Damon}}
@@ Zeile 60: / Zeile 61: @@
 === RA — Router Advertisement (ICMPv6 type 134) ===
-**Router Advertisment Nachrichten** werden vom Server entweder regelmässig an alle Clients im Netz oder ebnen speziell auf An Anfrage durch einen Client versandt. Es handelt sich also im ersten Fall um eine ICMPv6-Nachricht, die an die All-Nodes-Multicast-Adresse (ff02::1) oder eben als Unicast-Nachricht an einen bestimmten Host gesendet wird.
+**Router Advertisment Nachrichten** werden vom Server entweder regelmässig an alle Clients im Netz oder ebnen speziell auf An Anfrage durch einen Client versandt. Es handelt sich also im ersten Fall um eine ICMPv6-Nachricht, die an die All-Nodes-Multicast-Adresse (ff02::1) oder eben als Unicast-Nachricht an einen bestimmten Host gesendet wird.e
   * Ein Router verwenden diese RA-Nachrichten, um seine Anwesenheit, Netzwerkparameter und weitere Konfigurationsoptionen für Hosts bekannt zu geben.
   * Hosts verwerten diese RA-Nachrichten, um daraus z.B. den Default-Router, den bzw. die Netzwerk-Präfixe, die Link-MTU oder ob z.B. ein DHCPv6-Server im Netz verfügbar ist, sowie weitere relevante Netzwerkinformationen abzuleiten. \\ Ist ein DHCPv6-Server verfügbar ist, wird dies durch zwei Flags in der Router-Ankündigung angezeigt. Diese Flags sind das Konfigurationsflag für die verwaltete Adresse und das andere Konfigurationsflag. Das M-Bit und das O-Bit werden verwendet, um diese Flaggen zu setzen. Das M-Bit zeigt an, dass DHCPv6-Dienste für Adress- und Konfigurationseinstellungen verfügbar sind. Das O-Bit zeigt an, ob andere Konfigurationsparameter als die IP-Adresse über den DHCPv6-Dienst verfügbar sind. RAs bestehen also aus bestimmten Flags und Optionen (Präfix, MTU, DNS, SLLA - Src Link-Layer Address). Die wichtigsten Optionen sind hierbei:
@@ Zeile 66: / Zeile 67: @@
     * **Home-Agent H-Flag**: Dieses Flag wird verwendet, um anzuzeigen, dass es sich bei dem beworbenen Präfix um ein Heimnetzwerk-Präfix handelt, insbesondere für Mobile IPv6, dass sie also somit als Home Agent für Mobile IPv6 fungieren und Dienste für mobile Knoten bereitstellen können.
     * **On-link L-Flag**: Ist dieses Flag gesetzt, wird definiert dass ein bestimmtes Präfix als "on-link" betrachtet wird, d.h. dass Hosts Adressen innerhalb dieses Präfixes verwenden können, um direkt mit anderen Hosts auf demselben Link zu kommunizieren. Ist das L-Flag nicht gesetzt, müssen Hosts einen Router verwenden um Hosts in diesem Präfix erreichen zu können.
-    * **Managed M-Flag** : Eine '1' bedeutet, dass die Adresse durch stateful DHCPv6 bereitgestellt wird.
+    * **Managed M-Flag** : Eine '1' bedeutet, dass die Adresse durch Stateful DHCPv6 bereitgestellt wird.
     * **Other O-Flag** : Eine '1' bedeutet, dass die Adresse von Stateless DHCPv6 bereitgestellt wird, was für die Bereitstellung von Optionen nützlich ist, wenn der Client SLAAC-StatelessAddress Autoconfiguration durchführt.
     * **Router-Präferenz (Prf)**: Der Wert in diesem Feld steht für die Präferenzstufe des Routers, der die RA-Nachricht sendet. So wird z.B. darüber ermittelt ob das Gateway als Standardgateway fungieren soll. Das Prf-Feld kann drei Werte annehmen: Hoch (0x00), Mittel (0x40) oder Niedrig (0x80). Router mit einem höheren Präferenzwert werden gegenüber Routern mit niedrigeren Werten bevorzugt.
@@ Zeile 142: / Zeile 143: @@
 Damit unsere Clients Verbindungen zu dem geöffneten **dhcpv6-client**-Port **546/udp** und **dhcpv6-server**-Port **547/udp** unseres radvd-Daemons aufbauen können, müssen wir für diese noch Änderungen am Paketfilter **firewalld** vornehmen.
-Mit Hilfe des Programms **firewall-cmd** legen wir nun eine **permanente** Regel in der Zone **intra** an. Als Source-IP geben geben wir jeweils die Netze unserer Clients an. Genug der Vorrede, mit nachfolgendem Befehl wird der Port **123** geöffnet.
+Mit Hilfe des Programms **firewall-cmd** legen wir nun eine **permanente** Regel in der Zone **intra** an. Genug der Vorrede, mit nachfolgendem Befehl werden die Ports für den Service **dhcpv6** geöffnet.
    # firewall-cmd --permanent --zone=intra --add-service=dhcpv6
@@ Zeile 173: / Zeile 174: @@
 <WRAP center round info 80%>
 Starten werden wir den **radvd**-Daemon erst einmal noch nicht, da wir diesen ja noch konfigurieren müssen. Nachfolgend werden wir noch detailliert zu einzelnen Anwendungsfällen eingehen:
-  - **[[#slaac_-_ipv6_stateless_address_auto-configuration|SLAAC - IPv6 Stateless Address Auto-configuration]]**
+  - **[[#slaac_-_ipv6_stateless_address_auto-configuration|Konfigurationsbeispiel: SLAAC - IPv6 Stateless Address Auto-configuration]]**
-  - **DHCPv6 - stateless und stateful**
+  - **[[#router_advertisement_icmpv6-nachrichten_fuer_stateful_dhcpv6|Konfigurationsbeispiel: DHCPv6 - stateless und stateful]]**
+  - **[[#musterkonfiguration_gua_via_slaac_und_ula_via_dhcpv6|Musterkonfiguration für GUA via SLAAC und statischen festen ULA mit Hilfe von DHCPv6]]**
 </WRAP>
-==== SLAAC - IPv6 Stateless Address Auto-configuration ====
+==== Konfigurationsbeispiel für SLAAC ====
-=== Was ist SLAAC und wie funktioniert es ===
+=== Was ist SLAAC (IPv6 Stateless Address Autoconfiguration) und wie funktioniert es ===
 Bevor wir uns nun mit der Konfiguration unseres **radvd** beschäftigen, machen wir erst einmal klar, was SLAAC ist und wie es funktioniert. Jeder IPv6-Host in unserem Netz benötigt eine weltweit eindeutige Adresse, damit dieser auch ausserhalb dessen lokalen Segments kommunizieren zu können.
@@ Zeile 225: / Zeile 226: @@
 Bei unserem Konfigurationsbeispiel hier gehen wir für den Router Advertisement Daemon **radvd** für die Adressvergabe über **SLAAC** von folgenden Eckwerten aus:
-  * **Netzwerkinterface** : \\ Der **radvd** soll nure auf dem Netzwerkinterface **''eth1''** operieren, also dort lauscht er auf Router Solicitation ICMPv6-Nachrichten neuer Klients und beantwortet selbige mit Router Advertisements ICMPv6-Nachrichten bzw. sendet auf dieser Netzwerkschnittstelle regelmäßig seine Router Advertisements ICMPv6-Nachrichten an alle Clients im lokalen betreffenden Netz.
+  * **Netzwerkinterface** : \\ Der **radvd** soll nure auf dem Netzwerkinterface **''eth1''** operieren, also dort lauscht er auf Router Solicitation ICMPv6-Nachrichten neuer Clients und beantwortet selbige mit Router Advertisements ICMPv6-Nachrichten bzw. sendet auf dieser Netzwerkschnittstelle regelmäßig seine Router Advertisements ICMPv6-Nachrichten an alle Clients im lokalen betreffenden Netz.
   * **M-Flag**: \\ AdvManagedFlag = **''off''** (Adresskonfiguration über SLAAC)
   * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen.
-  * **A-Flag**: \\AdvAutonomous = **''on''** (Adresskonfiguration über SLAAC)
+  * **A-Flag**: \\ AdvAutonomous = **''on''** (Adresskonfiguration über SLAAC)
   * **Global-Scope Address Prefix** : \\ **''2001:a:bcd:1234''**
     * **Route** : \\ **''2001:a:bcd:1234::/64''** und eine Gültigkeit von einer 1/2 Stunde, also **''1800''** Sekunden.
@@ Zeile 697: / Zeile 698: @@
 </WRAP>
-Warum ist das nun so? Ganz einfach, weil am Client-Renchner noch keine Privacy Extension ausgewählt wurde. Werfen wir einen Blick in die betreffende Konfigurationsdatei **''/etc/sysctl.d/10-ipv6-privacy.conf''**.
+Warum ist das nun so? Ganz einfach, weil am Client-Rechner noch keine Privacy Extension ausgewählt wurde. Werfen wir einen Blick in die betreffende Konfigurationsdatei **''/etc/sysctl.d/10-ipv6-privacy.conf''**.
    # vim /etc/sysctl.d/10-ipv6-privacy.conf
 <file bash /etc/sysctl.d/10-ipv6-privacy.conf># Django : manual on 2024-06-27
@@ Zeile 762: / Zeile 763: @@
 </WRAP>
-==== Router Advertisement ICMPv6-Nachrichten für Stateful DHCPv6 ====
+==== Konfigurationsbeispiel DHCPv6 ====
-Ein **Stateful DHCPv6-Server** liefert neben IPv6-Adressen ach weitere Informationen, wie z.B. wie eine DNS-Serverliste und einen Domänennamen, an einen Host aus. Hosts. Dieser Stateful DHCPv6-Server behält auch den Status jeder Zuweisung im Auge, sprich er verfolgt die Verfügbarkeit des Adresspools und löst doppelte Adresskonflikte auf. Darüber hinaus protokolliert er jede Zuweisung und behält die Ablaufzeiten im Auge. Im Gegensatz zu IPv4 stellt ein Stateful DHCPv6-Server den Hosts keine Standard-Gateway-Adressen zur Verfügung, das kann bei IPv6 nur Router, die Router Advertisement-Nachrichten sendet wie z.B. unser **radvd**!
+=== Router Advertisement ICMPv6-Nachrichten für Stateful DHCPv6 ===
+Ein **Stateful DHCPv6-Server** liefert neben IPv6-Adressen auch weitere Informationen, wie z.B. wie eine DNS-Serverliste und einen Domänennamen, an einen Host aus. Hosts. Dieser Stateful DHCPv6-Server behält auch den Status jeder Zuweisung im Auge, sprich er verfolgt die Verfügbarkeit des Adresspools und löst doppelte Adresskonflikte auf. Darüber hinaus protokolliert er jede Zuweisung und behält die Ablaufzeiten im Auge. Im Gegensatz zu IPv4 stellt ein Stateful DHCPv6-Server den Hosts keine Standard-Gateway-Adressen zur Verfügung, das kann bei IPv6 nur Router, die Router Advertisement-Nachrichten sendet wie z.B. unser **radvd**!
 === Stateful DHCPv6 Konfiguration beim radvd ===
@@ Zeile 772: / Zeile 774: @@
   * **M-Flag**: \\ AdvManagedFlag = **''on''** (Adresskonfiguration via Stateful DHCPv6)
   * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen.
-  * **A-Flag**: \\AdvAutonomous = **''off''** (Adresskonfiguration via Statful DHCPv6)
+  * **A-Flag**: \\ AdvAutonomous = **''off''** (Adresskonfiguration via Statful DHCPv6)
   * **Route** für den **Global-Scope Address Prefix** **''2001:a:bcd:1234''**: \\ **''2001:a:bcd:1234::/64''** und eine Gültigkeit von einer 1/2 Stunde, also **''1800''** Sekunden.
   * **Route** für den **Unique Local IPv6 prefix** : **''fdb6:cb48:9d77:0::/64''**\\ **''fdb6:cb48:9d77:0::/64''** ebenfalls eine Gültigkeit von **''1800''** Sekunden.
@@ Zeile 1158: / Zeile 1160: @@
 Verbindet sich nun ein Client mit dem Netzwerk, handelt dieser **__nicht__** eigenständig seine IPv6-Adressen aus, sondern richtet eine entsprechende Anfrage an den DHCPv6-Server!
-===== Orchestrierung - Installation und Konfiguration des radvd mit Hilfe von Ansible  =====
+==== Musterkonfiguration GUA via SLAAC und ULA via DHCPv6 ====
-==== Aufgabenstellung ====
+=== Grundüberlegungen ===
-Natürlich wird man im Jahr 2024 nicht mehr ernsthaft, manuell Server aufsetzen und betreiben wollen. Vielmehr wird man auf ein Orchestrierungswerkzeug wie z.B. **[[linux:ansible:start|Ansible]]** zurückgreifen. Setzen wir einen neue virtuellen Server unter Arch Linux neu auf, oder wollen wir bei einem bestehenden Host die Konfiguration aktualisieren, verwenden wir wie zuvor schon angeschnitten [[https://www.ansible.com/|Ansible]] als Orchestrierungswerkzeug. So ist sichergestellt dass zum einen all unsere Hosts entsprechend gleich aufgebaut, konfiguriert und betrieben werden.
+In den beiden vorgenannten Konfigurationsbeispielen **[[#konfigurationsbeispiel_fuer_slaac|Konfigurationsbeispiel für SLAAC]]** und **[[#konfigurationsbeispiel_dhcpv6|Konfigurationsbeispiel DHCPv6]]** haben wir gesehen, dass wir mit den **''M''**- und **''A''**-Flag steuern können, wie ein Client, wenn er sich mit unserem Netzwerk verbindet, zu einer oder mehreren IP-v6-Adressen kommen kann. Auch da Thema **[[#slaac_und_privacy_extension_-_konfiguration_der_arch_linux_clients|SLAAC und Privacy Extension]]** bei de Konfiguration der (Arch Linux) Clients haben wir uns im Detail vorgenommen.
-Wir werden uns nun nachfolgend die Server-Installation und -konfiguration genauer betrachten.
+Wenn wir uns mit dem Thema IPv6 im Intranet befassen, wird sich in aller Regel folgende Frage stellen: Welche Typen von Adressen werden benötigt und welche sollen letztendlich auch wirklich genutzt werden. Nun Gut, die **L**ink **L**ocla **A**ddress generiert ein Host selbst wie wir bereits wissen, denn ohne diese könnte er z.B. kein SLAAC initiieren.
-==== Lösung ====
+<WRAP center round important 80%>
+Betrachten wir also nun die **U**nified **L**ocal **A**ddress, können wir erkennen, dass mit Hilfe dieser Adressen z.B. ein Laptop den Drucker im Netz direkt erreichen kann, denn wollen wir unserem Drucker eine öffentliche IP-Adresse verpassen? Nein, sicherlich nicht! Ausserdem soll es ja unter anderem **ISP**((**I**nternet **S**ervice **P**rovider)) geben, die ihren Kunden mit Hinweis von //Privatsphäre// **__keine__** statischen **''/56''** oder **''/64''** zuweisen sondern lediglich dynamische Prefixe, die sich bei jeder Neueinwahl oder auch 1x Pro Tag ändern. Würde man mit Hilfe von Prefix-Delegation nun diesen vom ISP zugewiesenen dynamischen Prefix im Intranet weiterverwenden wollen, würde sich in unserem Beispiel auch jedes mal die **GUA** des Drucker ändern - welch gruselige Vorstellung und administrativ kaum handelbar! :-? Gar nicht toll, gar nicht schön ... Moment, da war doch noch so ein Thema, statische feste IPv6 **GUA**: Wie wir beim Abschnitt **[[#slaac_und_privacy_extension_-_konfiguration_der_arch_linux_clients|SLAAC und privacy extension]]** bereits bemerkt haben, können einzelnen Nutzer mit ihren Geräten anhand der letzten 48 Bits der IPv6-Adresse weltweit trackbar werden. Nun Gut unter SLAAC gibt es die Option **//privacy extension//**, in den RFCs zu **DHCPv6** sucht man aber leider vergebens nach einer derartigen Option - O.K. zumindest im Jahre 2024 noch! Als sind statische eineindeutige **GUA** im Intranet eigentlich auch nichts was man sehen und haben möchte!
+</WRAP>
+<WRAP center round info 80%>
-<WRAP center round tip 80%>
+Je länger man sich nun mit der ganzen Thematik um nicht Misere zu sagen beschäftigt kommt man zu folgender Musterkonfigurationslösung:
-Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen der Inventory-Hülle, des Playbooks und der zugehörigen Rolle überspringen und diese Aufgaben mit folgendem Befehl sozusagen auf einem Rutsch erledigen:
+  - **ULA**:
+    - Wir wollen statische eineindeutige wiederkehrende feste **ULA**s die wir per **DHCPv6** auf Basis der **DUID** oder anderen dem Host zuordenbare Eigenschafte fest vergeben.
+    - Gästen oder entsprechenden Geräte lassen wir aus einem dynamischen Pool **ULA** zuweisen.
+  - **GUA**:
+    - Die öffentlichen **IPv6** Adressen (**GUA**)) vergeben wir dynamisch via SLAAC.
+    - Laptops oder Notebooks auf denen ein aktuelles fortschrittliches Linux, wie z.B. **[[https://archlinux.org/|Arch Linux]]** läuft, konfigurieren wir so, dass diese sich regelmässig mit den Optionen der privacy extension, neu Adressen via SLAAC holen.
+    - Bei mobilen Geräten aus dem Hause Apple mit ihrem **[[https://de.wikipedia.org/wiki/IOS_(Betriebssystem)|IOS Betriebssystem]]** oder Google mit ihrem **[[https://de.wikipedia.org/wiki/Android_(Betriebssystem)|Android Betriebssystem]]** sind wir auf Gedeih und Verderben diesen Firmen ausgeliefert und müssen vertrauen, dass diese doch irgendwann andere MAC-Adressen in kurzen Zeitabständen selbst generieren. Spoiler: Besser nicht danach suchen, die Ergebnisse im Jahre 2024 sind mehr als **<%%-%%redacted%%-%%>** und vorab von dem was man eigentlich erhoffen und erwarten würde!
+Wir wollen uns also nun ansehen, wie wir solch ein Muster-Szenario abbilden können
+</WRAP>
-<code> $ mkdir -p ~/devel/ansible ; wget https://gitlab.nausch.org/django/example_radvd/-/archive/main/example_radvd-main.tar.gz -O - | tar -xz --strip-components=1 -C ~/devel/ansible</code>
+<WRAP center round alert 80%>
+Der geneigte Leser wir sich nun fragen, ja wie macht man denn nun das beim **radvd**? Denn schliesslich wissen wir ja dass wir bei Nutzung von **SLAAC** die bekannten Flags wir folgt setzen müssen:
+  * **M-Flag**: \\ AdvManagedFlag = **''off''** (Adresskonfiguration über SLAAC)
+  * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen.
+  * **A-Flag**: \\ AdvAutonomous = **''on''** (Adresskonfiguration über SLAAC)
+Hingegen bei **DHCPv6** hingegen müssen wir die Flags wie folgt setzen.
+  * **M-Flag**: \\ AdvManagedFlag = **''on''** (Adresskonfiguration via Stateful DHCPv6)
+  * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen.
+  * **A-Flag**: \\ AdvAutonomous = **''off''** (Adresskonfiguration via Stateful DHCPv6)
-Nach Anpassung der Daten im Inventory kann man anschliessend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**.
+O.K. das **''O''**-Flag macht uns keine Sorgen, das setzen wir ja immer auf **''on''**. Das **A-Flag** wird über die Konfigurationsoption **''AdvAutonomous''** entweder auf **''on''** bei **SLAAC** gesetzt und auf **''off''** **bei DHCPv6**. Da diese Option im jeweiligen Prefix-Abschnitt in der Konfigurationsdatei **''radvd.conf''** definiert wird, ist das auch keine allzu grosse Herausforderung. O.K. was bleibt übrig? Richtig, das **''M''**-Flag, welches bei **SLAAC** mit der Konfigurationsoption **''AdvManagedFlag''** auf **''off''** gesetzt werden muss und bei **DHCPv6** eben auf **''on''**. Tja aber leider ist die Konfigurationsoption **''AdvManagedFlag''** **__global__** in der Konfigurationsdatei **''radvd.conf''**, sie kann also nur **__1x__** definiert werden und leider nicht **__2-mal__** wie wir es eigentlich bräuchten!
 </WRAP>
-=== Vorbereitung - (Server-)Daten im Inventory ===
+=== radvd Konfiguration ===
-Bei unserem Konfigurationsbeispiel hier gehen wir von folgenden Host-Parametern aus:
+Wie wir aber dennoch eine funktionierende Konfiguration des **radvd** hierzu hinbekommen werden wir uns nun ansehen. **SPOILER**: Ja die Konfiguration läuft wirklich uns wurde in fast Tagelangen nein Nächtelangen **[[https://de.wikipedia.org/wiki/Versuch_und_Irrtum|triel-and-error]]** Runden mehrfach validiert1 In unserem Konfigurationsbeispiel gehen wir von folgenden Rahmenbedingungen aus:
-  * **''zone: intra''**
-  * **''hostname: vml010110''**
-Die Konfigurationsdatei unseres **inventory** in unsere, Ansible-Verzeichnis beinhaltet demnach unter anderem:
+  * **Netzwerkinterface** : \\ Der **radvd** soll auf dem Netzwerkinterface **''eth1''** operieren, also dort lauscht er auf Router Solicitation ICMPv6-Nachrichten neuer Clients und beantwortet selbige mit Router Advertisements ICMPv6-Nachrichten bzw. sendet auf dieser Netzwerkschnittstelle regelmässig seine Router Advertisements ICMPv6-Nachrichten an alle Clients im lokalen betreffenden Netz.
-   $ vim inventories/production/hosts
+  * **GUA**
-++++ inventories/production/hosts |
+    * **SLAAC** : \\ Clients sollen sich über den Mechanismus **SLAAC** selbst öffentliche IPv6-Adressen generieren und das ohne Zuhilfenahme eines DHCPv6-Servers bei der Adressvergabe!
-<file bash inventories/production/hosts># Inventory Datei für die System-Umgebung im SOHO
+    * **Global-Scope Address Prefix** : \\ **''2001:a:bcd:1234''**
-#
+    * **Route** : \\ **''2001:a:bcd:1234::/64''**
-# Hinweise:
+    * **AdvRouteLifetime** : \\ Gültigkeit der Routen Lifetime  von einer 1/2 Stunde, also **''1800''** Sekunden.
-#           - Kommentare beginnen mit einem '#'-Zeichen
+    * **M-Flag**: \\ AdvManagedFlag = **''off''** (Adresskonfiguration über SLAAC)
-#           - leere Zeilen werden ignoriert
+    * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen.
-#           - Host- und Gruppendefinitionen werden mit [] abgegrenzt
+    * **A-Flag**: \\ AdvAutonomous = **''on''** (Adresskonfiguration über SLAAC)
-#           - Hosts können über ihren Hostnamen, FQN oder ihrer IP-Adresse definiert
+  * **ULA**
-#           - übergeordnete Gruppen werden durch [:children] abgegrenzt
+    * **DHCPv6** : \\ Der **radvd** lauscht auf dem Netzwerkinterface **''eth1''** des **radvd**-/**kea-dhcp6**-Host auf Router Solicitation ICMPv6-Nachrichten neuer Clients und beantwortet selbige mit Router Advertisements ICMPv6-Nachrichten bzw. sendet auf dieser Netzwerkschnittstelle regelmäßig seine Router Advertisements ICMPv6-Nachrichten an alle Clients im lokalen betreffenden Netz.
-#
+    * **Unique Local IPv6 prefix** : \\ Hier verwenden wir den zuvor erzeugten Unique Local IPv6 prefix von **''fdb6:cb48:9d77:0::/64''**.
-# Host-Definitionen
+    * **Route** : \\ **''fdb6:cb48:9d77:0::/64''**
+    * **AdvRouteLifetime** : \\ Gültigkeit der Routen Lifetime  von einer 1/2 Stunde, also **''1800''** Sekunden.
+    * **M-Flag**: \\ O.K. das **M-Flag** müssten wir ja eigentlich auf **''1''** AdvManagedFlag = **''on''** (Adresskonfiguration via Stateful DHCPv6) setzen. :!: Wir haben aber bereits bemerkt dass wir diese globale Option in der radvd.conf nur einmal setzen können - wir ignorieren also geflissentlich diese Option bei der **ULA** und **DHCPv6** :!:
+    * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen.
+    * **A-Flag**: \\ AdvAutonomous = **''off''** (Adresskonfiguration via Stateful DHCPv6)
-# Hosts ohne Gruppenzuordnung
+Daraus ergibt sich nun folgende Konfigurationsdatei für unseren radvd:
-localhost
+   # vim /etc/radvd.conf
+<file bash /etc/radvd.conf># Configuration example for the router advertisement daemon radvd
-[edmz]
+# for GUA and SLAAC as well as ULA with DHCPv6
-vml000210
-[idmz]
-vml000110
-[intra]
-vml010110
-# Host-Gruppen-Definitionen
-# (zu welcher Gruppe gehören Untergruppen bzw. Hosts)
-[linux:children]
-intra
-edmz
-idmz
-</file>
-++++
-Bei den Host-Variablen definieren wir über die Variable **''radvd_ipv6_mode''**, wie in unserer Umgebung die IPv6-Adressen letztlich generiert bzw. verteilt werden sollen. Wollen wir **[[#slaac_-_ipv6_stateless_address_auto-configuration|SLAAC - IPv6 Stateless Address Auto-Configuration]]** in unserem Netzwerk-(segment) nutzen, so setzen die die Variable **''radvd_ipv6_mode: "slaac"''**. Wollen wir hingegen **[[#router_advertisement_icmpv6-nachrichten_fuer_stateful_dhcpv6|IPv6 Stateful DHCPv6]]** nutzen, so setzen wir die Variable **''radvd_ipv6_mode: "dhcp6"''**.
-Bei der Definition unseres KVM-Hosts hatten wir unter anderem definiert:
-  * **''guest_nic_2       : %%"%%eth1%%"%%''**
-  * **''guest_ip6_net_2   : %%"%%2003:a:bcd:1234::%%"%%''**
-  * **''guest_mask6_2     : %%"%%/64%%"%%''**
-  * **''guest_ip6_ls_fx_2 : %%"%%fdb6:cb48:9d77:0::%%"%%''**
-  * **''guest_zone_2      : %%"%%intra%%"%%''**
-++++ inventories/production/host_vars/vml010110/kvm_vhost |
-<file bash inventories/production/host_vars/vml010110/kvm_vhost>guest_nic_2:        "eth1"
-guest_ip6_net_2:    "2001:a:bcd:1234::"
-guest_mask6_2:      "/64"
-guest_ip6_ls_fx_2:  "fdb6:cb48:9d77:0::"
-guest_zone_2:       "intra"
-</file>
-++++
-Die für den **radvd** relavanten Konfigurationsparameter legen wir in der Inventrory-Datei **''inventories/production/host_vars/vml010110/radvd''** ab.
-   $ vim inventories/production/host_vars/vml010110/radvd
-++++ inventories/production/host_vars/vml010110/radvd |
-<file bash inventories/production/host_vars/vml010110/radvd>radvd_ipv6_mode:      "dhcp6"
-radvd_nic:            '{{ guest_nic_2 }}'
-radvd_gua_prefix:     '{{ guest_ip6_net_2 }}'
-radvd_gua_netmask:    '{{ guest_mask6_2 }}'
-radvd_gua_preference: "medium"
-radvd_gua_valid_time: "5400"
-radvd_gua_route_time: "1800"
-radvd_gua_prefd_time: "2700"
-radvd_ula_prefix:     '{{ guest_ip6_ls_fx_2 }}'
-radvd_ula_netmask:    '{{ radvd_gua_netmask }}'
-radvd_ula_preference: '{{ radvd_gua_preference }}'
-radvd_ula_valid_time: '{{ radvd_gua_valid_time }}'
-radvd_ula_route_time: '{{ radvd_gua_route_time }}'
-radvd_ula_prefd_time: '{{ radvd_gua_prefd_time }}'
-</file>
-++++
-=== Playbook ===
-Unser Playbook zum Installieren und Konfigurieren unseres Router Advertisements Daemon **radvd**, ist unscheinbar und unspektakulär.
-   $ vim playbooks/arch_radvd.yml
-<file bash playbooks/arch_radvd.yml>
----
-# Ansible Playbook zum Konfigurieren des Router Advertisement Daemon unter Arch-Linux.
-# Aufruf via $ ansible-playbook playbooks/arch_radvd.yml :
-#  $ ansible-playbook playbooks/arch_radvd.yml
-# für einen Host aus der Hostgruppe DMZ.
-- name: "Playbook-Name: arch_chrony_server.yml" # Name des Playbooks
-  hosts: vml010110                              # Hostname/-gruppe für die das Playbook gelten soll
-  roles:
-    - role: radvd                               # radvd installieren und konfigurieren
-      tags: radvd                               # Tag-Kennzeichnung der definierten Rolle
-...
-</file>
-=== Rolle ===
-Für die Konfiguration unseres **radvd** verwenden wir eine eigene Rolle **''radvd''**, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. hierzu kopieren wir uns zunächst die Mustervorlage **''common''**.
-   $ cp -avr roles/common/ roles/radvd
-<code>'roles/common/' -> 'roles/radvd'
-'roles/common/defaults' -> 'roles/radvd/defaults'
-'roles/common/defaults/.gitkeep' -> 'roles/radvd/defaults/.gitkeep'
-'roles/common/files' -> 'roles/radvd/files'
-'roles/common/files/.gitkeep' -> 'roles/radvd/files/.gitkeep'
-'roles/common/handlers' -> 'roles/radvd/handlers'
-'roles/common/handlers/.gitkeep' -> 'roles/radvd/handlers/.gitkeep'
-'roles/common/library' -> 'roles/radvd/library'
-'roles/common/library/.gitkeep' -> 'roles/radvd/library/.gitkeep'
-'roles/common/lookup_plugins' -> 'roles/radvd/lookup_plugins'
-'roles/common/lookup_plugins/.gitkeep' -> 'roles/radvd/lookup_plugins/.gitkeep'
-'roles/common/meta' -> 'roles/radvd/meta'
-'roles/common/meta/.gitkeep' -> 'roles/radvd/meta/.gitkeep'
-'roles/common/module_utils' -> 'roles/radvd/module_utils'
-'roles/common/module_utils/.gitkeep' -> 'roles/radvd/module_utils/.gitkeep'
-'roles/common/tasks' -> 'roles/radvd/tasks'
-'roles/common/tasks/main.yml' -> 'roles/radvd/tasks/main.yml'
-'roles/common/templates' -> 'roles/radvd/templates'
-'roles/common/templates/.gitkeep' -> 'roles/radvd/templates/.gitkeep'
-'roles/common/vars' -> 'roles/radvd/vars'
-'roles/common/vars/.gitkeep' -> 'roles/radvd/vars/.gitkeep'
-</code>
-Bei Bedarf können wir uns die Struktur die somit angelegt wurde mit nachfolgendem Befehl anzeigen lassen.
-   $ tree roles/radvd/
-++++ Ausgabe von tree roles/radvd/ |
-<code>roles/radvd/
-├── defaults
-├── files
-├── handlers
-├── library
-├── lookup_plugins
-├── meta
-├── module_utils
-├── tasks
-│   ├── firewalld.yml
-│   ├── install.yml
-│   └── main.yml
-├── templates
-│   └── radvd_config.j2
-└── vars
-</code>
-++++
-Wie wir sehen ist die Rolle durchaus überschaubar, im Task **''main.yaml''** verweisen wir lediglich auf die beiden eigentlichen Tasks **''install.yml''** und **''firewalld.yml''**
-   $ vim roles/radvd/tasks/main.yml
-<file bash roles/radvd/tasks/main.yml>
----
-- name: "Installation und Konfiguration des Router Advertisement Daemon radvd."
-  ansible.builtin.include_tasks:
-    file: install.yml
-    apply:
-      tags: install
-- name: "Konfiguration des firewalld für den Router Advertisement Daemon radvd."
-  ansible.builtin.include_tasks:
-    file: firewalld.yml
-    apply:
-      tags: firewalld
-...
-</file>
-Die eigentliche Installation und Konfiguration erfolgt dann im Task **''install.yml''**.
-   $ vim roles/radvd/tasks/install.yml
-<file bash roles/radvd/tasks/install.yml>---
-- name: "Installation des Router Advertisement Daemon radvd."
-  community.general.pacman:
-    name: radvd
-    state: present
-- name: "Checken ob es bereits eine Backupdatei der radvd.conf gibt."
-  ansible.builtin.stat:
-    path: /etc/radvd.conf.orig
-  register: check_radvd_config
-- name: "Backupdatei der radvd.conf Konfigurationsdatei erstellen."
-  ansible.builtin.copy:
-    remote_src: true
-    src: /etc/radvd.conf
-    dest: /etc/radvd.conf.orig
-    owner: root
-    group: root
-    mode: '0644'
-  when: not check_radvd_config.stat.exists
-- name: "Generieren und kopieren der radvd Konfigurationsdatei /etc/radvd.conf"
-  ansible.builtin.template:
-    src: templates/radvd_config.j2
-    dest: /etc/radvd.conf
-    owner: root
-    group: root
-    mode: '0644'
-...
-</file>
-Die Anpassung an unserer Firewall-Konfiguration  erfolgt im Task **''firewalld''**.
-   $ vim roles/radvd/tasks/firewalld.yml
-<file bash roles/radvd/tasks/firewalld.yml>---
-- name: "Sicherstellen, dass der Firewall-Daemon reboot(-fest) starten."
-  ansible.builtin.systemd:
-    state: reloaded
-    enabled: true
-    name: firewalld
-- name: "Service basierte Rules je Zone definieren"
-  ansible.posix.firewalld:
-    zone: '{{ guest_zone_2 }}'
-    service: dhcpv6
-    immediate: true
-    permanent: true
-    state: enabled
-- name: "Zum Schluss den aktuellen permanenten Regelsatz final neu laden."
-  ansible.builtin.service:
-    name: firewalld
-    state: reloaded
-...
-</file>
-Das Template **''radvd_config.j2''** für die Generierung der Konfigurationsdatei **''/etc/radvd.conf''** hat folgenden Aufbau.
-   $ vim roles/radvd/templates/radvd_config.j2
-<file bash roles/radvd/templates/radvd_config.j2># BEGIN ANSIBLE MANAGED - DO NOT EDIT BLOCK
-# Ansible managed configuration file, do not modify manually!
 #
-# Configuration file router advertisement daemon radvd
-{% if radvd_ipv6_mode == "dhcp6" %}
-#  - M-flag: AdvManagedFlag = on (address configuration via '{{ radvd_ipv6_mode }}')
-{% else %}
-#  - M-flag: AdvManagedFlag = off (address configuration via '{{ radvd_ipv6_mode }}')
-{% endif %}
 #  - O-flag: AdvOtherConfigFlag = on (obtaining a DNS server list
 #            and a domain name from a Stateless DHCPv6 server, but
 #            not addressing information.
-{% if radvd_ipv6_mode == "dhcp6" %}
+#  - M-flag: AdvManagedFlag = off (address configuration via SLAAC for GUA)
-#  - A-flag: AdvAutonomous = off (address configuration via '{{ radvd_ipv6_mode }}')
+#  - A-flag: AdvAutonomous = on (address configuration via SLAAC for GUA)
-{% else %}
+#  - A-flag: AdvAutonomous = off (address configuration via DHCPv6 for static ULA)
-#  - A-flag: AdvAutonomous = on (address configuration via '{{ radvd_ipv6_mode }}')
-{% endif %}
-interface {{ radvd_nic }}
+interface eth1
 {
   # A  flag  indicating  whether or not the router sends periodic
   # router advertisements and responds to router solicitations.
   # This option no longer has to be specified first, but it needs
@@ Zeile 1440: / Zeile 1240: @@
   # Must be no less than 4 seconds and no greater than 1800 seconds.
   # Minimum when using Mobile IPv6 extensions: 0.07.
   # For values less than 0.2 seconds, 0.02 seconds is added to
   # account for scheduling granularities as specified in RFC3775.
   MaxRtrAdvInterval 600;
@@ Zeile 1446: / Zeile 1246: @@
   # The minimum time allowed between sending unsolicited multicast
   # router advertisements from the interface, in seconds.
   # Must be no less than 3 seconds and no greater than
   # 0.75 * MaxRtrAdvInterval.
   # Minimum when using Mobile IPv6 extensions: 0.03.
   MinRtrAdvInterval 200;
   # The preference associated with the default router, as either
   # "low", "medium", or "high".
-  AdvDefaultPreference {{ radvd_gua_preference }};
+  AdvDefaultPreference medium;
   # Mobile IPv6 support, when set, indicates that sending router is
   # able to serve as Mobile IPv6 Home Agent.
   # When set, minimum limits specified by Mobile IPv6 are used for
   # MinRtrAdvInterval and MaxRtrAdvInterval.
   AdvHomeAgentFlag off;
   # When set, hosts use the administered (stateful) protocol for
   # address  autoconfiguration in  addition to any addresses
   # autoconfigured using stateless address autoconfiguration.
   # The use of this flag is described in RFC 4862.
   # M-flag - if it is set to 1, this informs hosts that they can
   # obtain a global address as well as DNS and a domain name from
   # a Stateful DHCPv6 server. Typically this means that auto-
   # addressing using SLAAC is not allowed on this segment and both
   # the A-flag and the O-flag are set to 0.
-{% if radvd_ipv6_mode == "dhcp6" %}
+  AdvManagedFlag on;
-  AdvManagedFlag = on;
-{% else %}
-  AdvManagedFlag = off;
-{% endif %}
   # When set, hosts use the administered (stateful) protocol for
   # autoconfiguration of other (non-address) information.
   # The use of this flag is described in RFC 4862
   # O-flag - if it is set to on, this informs hosts that they can
   # obtain a DNS server list and a domain name from a Stateless
   # DHCPv6 server, but not addressing information. Typically it
   # works in conjunction with SLAAC for auto-addressing and both
   # the A-flag and the O-flag are set to on.
@@ Zeile 1487: / Zeile 1283: @@
   AdvOtherConfigFlag on;
   # The time, in milliseconds, that a node assumes a neighbor is
   # reachable after having received a reachability confirmation.
   # Used by the Neighbor Unreachability Detection algorithm (see
@@ Zeile 1497: / Zeile 1293: @@
   # The time,in milliseconds, between retransmitted Neighbor Soli-
   # citation messages. Used by address resolution and the Neighbor
   # Unreachability Detection algorithm (see Sections 7.2 and 7.3
   # of RFC 4861).  A value of zero means unspecified (by this router).
   AdvRetransTimer 0;
@@ Zeile 1513: / Zeile 1309: @@
   # router's usefulness as a default router; it does not apply to in-
   # formation contained in other message fields or options. Options that
   # need time limits for their information include their own lifetime
   # fields.
   # Must be either zero or between MaxRtrAdvInterval and 9000 seconds.
   # Default: 3 * MaxRtrAdvInterval (Minimum 1 second).
-  AdvDefaultLifetime {{ radvd_gua_route_time }};
+  AdvDefaultLifetime 1800;
   # When set, the link-layer address of the outgoing interface is
   # included in the RA.
   AdvSourceLLAddress on;
-  # global-scope address prefix
+  # global-scope adress prefix
-  prefix {{ radvd_gua_prefix  }}{{  radvd_gua_netmask }}
+  prefix 2003:a:e0d:7607::/64
   {
     # When set, indicates that this prefix can be used for on-link
     # determination. When not set the advertisement makes no statement
     # about on-link or off-link properties of the prefix. For instance,
     # the prefix might be used for address configuration with some of
     # the addresses belonging to the prefix being on-link and others
     # being off-link.
     AdvOnLink on;
     # When set, indicates that this prefix can be used for autonomous
     # address configuration as specified in RFC 4862.
     # A-flag - if it is set to on, this informs hosts that they can
     # auto-generate GUA address using SLAAC. If it is set to off means
     # that auto-configuration is not allowed for this segment.
-{% if radvd_ipv6_mode == "dhcp6" %}
-    AdvAutonomous off;
-{% else %}
     AdvAutonomous on;
-{% endif %}
     # When set, indicates that the address of interface is sent instead
     # of network prefix, as is required by Mobile IPv6. When set,
     # minimum limits specified by Mobile IPv6 are used for
     # MinRtrAdvInterval and MaxRtrAdvInterval.
     AdvRouterAddr off;
     # The length of time in seconds (relative to the time the packet is
     # sent) that the prefix is valid for the purpose of on-link de-
     # termination. The symbolic value infinity represents infinity
     # (i.e. a value of all one bits (0xffffffff)). The valid lifetime
     # is also used by RFC 4862.
@@ Zeile 1562: / Zeile 1354: @@
     # Note: RFC4861's suggested default value is significantly longer:
     # 30 days.
-    AdvValidLifetime {{ radvd_gua_valid_time  }};
+    AdvValidLifetime 5400;
     # The length of time in seconds (relative to the time the packet
@@ Zeile 1572: / Zeile 1364: @@
     # Note: RFC4861's suggested default value is significantly longer:
     # 7 days.
-    AdvPreferredLifetime {{ radvd_gua_prefd_time}};
+    AdvPreferredLifetime 2700;
     };
-  # route for global-scope address prefix
+ route 2003:a:e0d:7607::/64
-  route {{ radvd_gua_prefix  }}{{  radvd_gua_netmask }}
   {
     # The preference associated with the default router, as either
     # "low", "medium", or "high".
-    AdvRoutePreference {{ radvd_gua_preference }};
+    AdvRoutePreference medium;
     # The lifetime associated with the route in units of seconds. The
@@ Zeile 1587: / Zeile 1378: @@
     #
     # Default: 3 * MaxRtrAdvInterval
-    AdvRouteLifetime {{ radvd_gua_route_time }};
+    AdvRouteLifetime 1800;
   };
-  # unique local prefix
+  prefix fdb6:cb48:9d77:0::/64
-  prefix {{ radvd_ula_prefix }}{{ radvd_ula_netmask }}
   {
     # When set, indicates that this prefix can be used for on-link
     # determination. When not set the advertisement makes no statement
     # about on-link or off-link properties of the prefix. For instance,
     # the prefix might be used for address configuration with some of
     # the addresses belonging to the prefix being on-link and others
     # being off-link.
     AdvOnLink on;
     # When set, indicates that this prefix can be used for autonomous
     # address configuration as specified in RFC 4862.
     # A-flag - if it is set to on, this informs hosts that they can
     # auto-generate GUA address using SLAAC. If it is set to off means
     # that auto-configuration is not allowed for this segment.
-{% if radvd_ipv6_mode == "dhcp6" %}
     AdvAutonomous off;
-{% else %}
-    AdvAutonomous on;
-{% endif %}
     # When set, indicates that the address of interface is sent instead
     # of network prefix, as is required by Mobile IPv6. When set,
     # minimum limits specified by Mobile IPv6 are used for
     # MinRtrAdvInterval and MaxRtrAdvInterval.
     AdvRouterAddr off;
     # The length of time in seconds (relative to the time the packet is
     # sent) that the prefix is valid for the purpose of on-link de-
     # termination. The symbolic value infinity represents infinity
     # (i.e. a value of all one bits (0xffffffff)). The valid lifetime
     # is also used by RFC 4862.
@@ Zeile 1629: / Zeile 1415: @@
     # Note: RFC4861's suggested default value is significantly longer:
     # 30 days.
-    AdvValidLifetime {{ radvd_ula_valid_time  }};
+    AdvValidLifetime 5400;
     # The length of time in seconds (relative to the time the packet
@@ Zeile 1639: / Zeile 1425: @@
     # Note: RFC4861's suggested default value is significantly longer:
     # 7 days.
-    AdvPreferredLifetime {{ radvd_ula_prefd_time}};
+    AdvPreferredLifetime 2700;
     };
-  #route for unique local prefix
+ route fdb6:cb48:9d77:0::/64
-  route {{ radvd_ula_prefix }}{{ radvd_ula_netmask }}
   {
     # The preference associated with the default router, as either
     # "low", "medium", or "high".
-    AdvRoutePreference {{ radvd_ula_preference }};
+    AdvRoutePreference medium;
     # The lifetime associated with the route in units of seconds. The
     # symbolic value infinity represents infinity (i.e. a value of
     # all one bits (0xffffffff)).
     #
     # Default: 3 * MaxRtrAdvInterval
-    AdvRouteLifetime {{ radvd_gua_route_time }};
+    AdvRouteLifetime 1800;
   };
+};
+</file>
+Wollen wir die Kondfigurationsdate ohne die Kommentare sehen, grep'en wir einfach entspprechend danach.
+   # grep -Ev '(^.*#|^$)' /etc/radvd.conf
+++++ Beispielkonfigurationsdatei ohne Kommentare |
+<code>interface eth1
+{
+  AdvSendAdvert on;
+  MaxRtrAdvInterval 600;
+  MinRtrAdvInterval 200;
+  AdvDefaultPreference medium;
+  AdvHomeAgentFlag off;
+  AdvManagedFlag on;
+  AdvOtherConfigFlag on;
+  AdvReachableTime 0;
+  AdvRetransTimer 0;
+  AdvCurHopLimit 64;
+  AdvDefaultLifetime 1800;
+  AdvSourceLLAddress on;
+  prefix 2003:a:e0d:7607::/64
+  {
+    AdvOnLink on;
+    AdvAutonomous on;
+    AdvRouterAddr off;
+    AdvValidLifetime 5400;
+    AdvPreferredLifetime 2700;
+    };
+ route 2003:a:e0d:7607::/64
+  {
+    AdvRoutePreference medium;
+    AdvRouteLifetime 1800;
+  };
+  prefix fdb6:cb48:9d77:0::/64
+  {
+    AdvOnLink on;
+    AdvAutonomous off;
+    AdvRouterAddr off;
+    AdvValidLifetime 5400;
+    AdvPreferredLifetime 2700;
+    };
+ route fdb6:cb48:9d77:0::/64
+  {
+    AdvRoutePreference medium;
+    AdvRouteLifetime 1800;
+  };
 };
+</code>
+++++
+Bevor wir nun unseren **radvd** starten, führen wir noch einen Konfigurationstest durch.
+Wir prüfen also nun die Konfigurationsdatei unseres **radvd** auf syntaktische Fehler.
+   # radvd -cC /etc/radvd.conf
+  [Jul 09 17:59:05] radvd (1264): config file, /etc/radvd.conf, syntax ok
+Nun starten wir unseren **radvd** Daemon.
+   # systemctl start radvd.service
+Im journald wir der Start entsprechend dokumentiert.
+   # journalctl -fu radvd
+<code>Jul 09 18:00:37 vml000110 systemd[1]: Started IPv6 Router Advertisement Daemon.
+Jul 09 18:00:37 vml000110 radvd[1296]: [Jul 09 18:00:37] radvd (1296): version 2.19 started</code>
+Bei Bedarf können wir natürlich auch den Status unseres Daemons jederzeit abfragen.
+   # systemctl status radvd.service
+<html><pre class="code">
+<font style="color: rgb(29, 180, 29)"><b>●</b></font> radvd.service - IPv6 Router Advertisement Daemon
+     Loaded: loaded (/usr/lib/systemd/system/radvd.service; </font><font style="color: rgb(29, 180, 29)"><b>disabled</b></font>; preset: <font style="color: rgb(201, 214, 95)"><b>disabled</b></font>)
+   Active:<font style="color: rgb(29, 180, 29)"><b>active (running)</b></font> since Tue 2024-07-09 18:00:37 CEST; 1min 19s ago
+ Invocation: bc40f348d21e45bf83b5976494e7fe39
+   Main PID: 1296 (radvd)
+      Tasks: 2 (limit: 9510)
+     Memory: 368K (peak: 1.5M)
+        CPU: 13ms
+     CGroup: /system.slice/radvd.service
+             ├─1296 /usr/bin/radvd --nodaemon
+             └─1297 /usr/bin/radvd --nodaemon
+Jul 09 18:00:37 vml000110 systemd[1]: Started IPv6 Router Advertisement Daemon.
+Jul 09 18:00:37 vml000110 radvd[1296]: [Jul 09 18:00:37] radvd (1296): version 2.19 started</font></pre>
+</html>
+Nun prüfen wir, ob unser **radvd** auch die richtigen Router Advertisement ICMPv6 Nachrichten ins Netz schickt. Hier bieten sich zwei mögliche Varianten an:
+  - Mit dem Programm **''radvdump''** aus dem Paket **radvd**. Hierzu starten wir dias besagte Binary auf einem unserer Clients im lokalen Netzwerk-Segment dieses Binary. <code> # radvdump</code><code>#
+# radvd configuration generated by radvdump 2.18
+# based on Router Advertisement from fe80::10:ff:fe10:110
+# received by interface enp0s25
 #
-# END ANSIBLE MANAGED - DO NOT EDIT BLOCK
+interface enp0s25
+{
+  AdvSendAdvert on;
+  # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
+  AdvManagedFlag on;
+  AdvOtherConfigFlag on;
+  AdvReachableTime 0;
+  AdvRetransTimer 0;
+  AdvCurHopLimit 64;
+  AdvDefaultLifetime 1800;
+  AdvHomeAgentFlag off;
+  AdvDefaultPreference medium;
+  AdvSourceLLAddress on;
+  prefix 2001:a:bcd:1234::/64
+  {
+    AdvValidLifetime 5400;
+    AdvPreferredLifetime 2700;
+    AdvOnLink on;
+    AdvAutonomous on;
+    AdvRouterAddr off;
+  }; # End of prefix definition
+  prefix fdb6:cb48:9d77::/64
+  {
+    AdvValidLifetime 5400;
+    AdvPreferredLifetime 2700;
+    AdvOnLink on;
+    AdvAutonomous off;
+    AdvRouterAddr off;
+  }; # End of prefix definition
+  route 2001:a:bcd:1234::/64
+  {
+    AdvRoutePreference medium;
+    AdvRouteLifetime 1800;
+  }; # End of route definition
+  route fdb6:cb48:9d77::/64
+  {
+    AdvRoutePreference medium;
+    AdvRouteLifetime 1800;
+  }; # End of route definition
+}; # End of interface definition</code> In regelmäßigen Abständen tauchen also diese RA-Meldungen auf.
+  - Mit Hilfe von **''tcpdump''** können wir auch die RA-Meldungen mitschneiden und darstellen, in nachfolgenden Beispiel ist der Name des Netzwerkinterfaces **''enp0s15''**.<code> # tcpdump -vi enp0s25 "icmp6[icmp6type] == icmp6-routeradvert"</code><code>tcpdump: listening on enp0s25, link-type EN10MB (Ethernet), snapshot length 262144 bytes
+:08:04.399616 IP6 (flowlabel 0x37bf6, hlim 255, next-header ICMPv6 (58) payload length: 136) _gateway > nitropad: [icmp6 sum ok] ICMP6, router adver
+  hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
+    prefix info option (3), length 32 (4): 2003:a:e0d:7607::/64, Flags [onlink, auto], valid time 5400s, pref. time 2700s
+    prefix info option (3), length 32 (4): fdb6:cb48:9d77::/64, Flags [onlink], valid time 5400s, pref. time 2700s
+    route info option (24), length 24 (3):  2003:a:e0d:7607::/64, pref=medium, lifetime=1800s
+    route info option (24), length 24 (3):  fdb6:cb48:9d77::/64, pref=medium, lifetime=1800s
+    source link-address option (1), length 8 (1): 52:54:00:41:11:02
+^C
+packet captured
+packet received by filter
+packets dropped by kernel
+</code>
+=== kea-dhcp6 Konfiguration ===
+Wir brauchen jetzt natürlich für die statischen **ULA** noch eine passende Konfigurationsdatei. Wir greifen nun kurz dem Kapitel **[[linux:kea|DHCPv4/v6-Server mit DHCP ISC Kea unter Arch Linux einrichten und nutzen]]** vor und werfen einen kurzen Blick auf die unkommentierte Konfigurationsdatei **''/etc/kea/kea-dhcp6.conf''** des **kea-dhcp6**-Daemon. Im besagten [[linux:kea|Kapitel]] werden wir uns noch mit dem **[[|DHCP ISC Kea]]** ähnlich detailliert auseinander setzen wir hier in diesem Kapitel **[[#dokuwiki__top|Router Advertisements mit radvd unter Arch Linux einrichten und nutzen]]**!
+   # vim /etc/kea/kea-dhcp6.conf
+++++ Beispielkonfigurationsdatei ohne Kommentare |
+<code>{
+  "Dhcp6": {
+    "valid-lifetime": 4000,
+    "renew-timer": 1000,
+    "rebind-timer": 2000,
+    "preferred-lifetime": 3000,
+    "control-socket": {
+      "socket-type": "unix",
+      "socket-name": "/var/lib/kea/kea6-ctrl-socket"
+    },
+    "interfaces-config": {
+      "interfaces": [
+        "eth1"
+      ]
+    },
+    "lease-database": {
+      "type": "memfile",
+      "persist": true,
+      "name": "/var/lib/kea/kea-leases6.csv",
+      "lfc-interval": 1800,
+      "max-row-errors": 100
+    },
+    "expired-leases-processing": {
+      "reclaim-timer-wait-time": 10,
+      "flush-reclaimed-timer-wait-time": 25,
+      "hold-reclaimed-time": 3600,
+      "max-reclaim-leases": 100,
+      "max-reclaim-time": 250,
+      "unwarned-reclaim-cycles": 5
+    },
+    "option-data": [
+      {
+        "name": "dns-servers",
+        "data": "fdb6:cb48:9d77:10:0:10:110"
+      },
+      {
+        "name": "domain-search",
+        "data": "intra.nausch.org"
+      }
+    ],
+    "subnet6": [
+      {
+        "interface": "eth1",
+        "id": 857665,
+        "subnet": "fdb6:cb48:9d77::/64",
+        "pools": [
+          {
+            "pool": "fdb6:cb48:9d77:10:0:10:300/120"
+          }
+        ],
+        "option-data": [
+          {
+            "name": "dns-servers",
+            "data": "fdb6:cb48:9d77:10:0:10:110"
+          }
+        ],
+        "reservations": [
+          {
+            "duid": "00:04:28:b0:df:3d:fd:11:6b:62:82:5c:14:95:dc:27:97:98",
+            "ip-addresses": [ "fdb6:cb48:9d77:10:0:10:73" ]
+          },
+          {
+            "duid": "00:04:80:6f:6d:f5:a6:44:99:a4:3f:9f:09:7c:69:8d:e8:d2",
+            "ip-addresses": [ "fdb6:cb48:9d77:10:0:10:74" ]
+          }
+        ]
+      }
+    ],
+    "loggers": [
+      {
+        "name": "kea-dhcp6",
+        "output_options": [
+          {
+            "output": "/var/log/kea-dhcp6.log",
+            "maxsize": 1048576,
+            "maxver": 8
+          }
+        ],
+        "severity": "DEBUG",
+        "debuglevel": 99
+      }
+    ]
+  }
+}
+</code>
+++++
+=== IP-Adresse am Client ===
+Fragen wir die IP-Adresse des Netzwerkinterfaces ab sehen wir:
+  django@nitropad:~$ ip addr show enp0s25
+<code>2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
+    link/ether 3c:97:0e:18:e4:dd brd ff:ff:ff:ff:ff:ff
+    inet 10.0.10.73/24 brd 10.0.10.255 scope global dynamic noprefixroute enp0s25
+       valid_lft 3594sec preferred_lft 3594sec
+    inet6 fdb6:cb48:9d77:10:0:10:73/128 scope global dynamic noprefixroute
+       valid_lft 3995sec preferred_lft 2995sec
+    inet6 2001:a:bcd:1234:c79d:9c68:ff37:3f53/64 scope global temporary dynamic
+       valid_lft 5395sec preferred_lft 2695sec
+    inet6 2001:a:bcd:1234:2688:fdb0:775:c02c/64 scope global dynamic mngtmpaddr noprefixroute
+       valid_lft 5395sec preferred_lft 2695sec
+    inet6 fe80::e9a6:bb03:1544:b000/64 scope link noprefixroute
+       valid_lft forever preferred_lft forever</code>
+<WRAP center round tip 80%>
+Wir haben neben der **IPv4** Adresse **''10.0.10.73''** und der vom Client-System generierten **LLA** **''fe80::e9a6:bb03:1544:b000/64''** mit ***''scope link noprefixroute''** noch drei weitere IPv6-Adressen erhalten. Das wäre zum einen die statische feste **ULA** **''fdb6:cb48:9d77:10:0:10:73/128''** mit **''scope global dynamic noprefixrout''** noch eine stabile dynamische IPv6 Adresse **''2001:a:bcd:1234:2688:fdb0:775:c02c/64''** mit **''scope global dynamic mngtmpaddr''** und eine temporäre "privacy" IPv6 Adresse **''2001:a:bcd:1234:c79d:9c68:ff37:3f53/64''** mit **''scope global temporary dynamic''**. Erstere ist für eingehende Verbindungen und letztere ist für ausgehende Verbindungen und wird alle gemäß der RA-Option **''AdvPreferredLifetime 2700''** alle 45 Minuten neu ausgewürfelt.
+</WRAP>
+===== Orchestrierung - Installation und Konfiguration des radvd mit Hilfe von Ansible  =====
+==== Aufgabenstellung ====
+Natürlich wird man im Jahr 2024 nicht mehr ernsthaft, manuell Server aufsetzen und betreiben wollen. Vielmehr wird man auf ein Orchestrierungswerkzeug wie z.B. **[[linux:ansible:start|Ansible]]** zurückgreifen. Setzen wir einen neue virtuellen Server unter Arch Linux neu auf, oder wollen wir bei einem bestehenden Host die Konfiguration aktualisieren, verwenden wir wie zuvor schon angeschnitten [[https://www.ansible.com/|Ansible]] als Orchestrierungswerkzeug. So ist sichergestellt dass zum einen all unsere Hosts entsprechend gleich aufgebaut, konfiguriert und betrieben werden.
+Wir werden uns nun nachfolgend die Server-Installation und -konfiguration genauer betrachten.
+==== Lösung ====
+<WRAP center round tip 80%>
+Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen der Inventory-Hülle, des Playbooks und der zugehörigen Rolle überspringen und diese Aufgaben mit folgendem Befehl sozusagen auf einem Rutsch erledigen:
+<code> $ mkdir -p ~/devel/ansible ; wget https://gitlab.nausch.org/django/example_radvd/-/archive/main/example_radvd-main.tar.gz -O - | tar -xz --strip-components=1 -C ~/devel/ansible</code>
+Nach Anpassung der Daten im Inventory kann man anschliessend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**.
+</WRAP>
+=== Vorbereitung - (Server-)Daten im Inventory ===
+Bei unserem Konfigurationsbeispiel hier gehen wir von folgenden Host-Parametern aus:
+  * **''zone: intra''**
+  * **''hostname: vml010110''**
+Die Konfigurationsdatei unseres **inventory** in unsere, Ansible-Verzeichnis beinhaltet demnach unter anderem:
+   $ vim inventories/production/hosts
+++++ inventories/production/hosts |
+<file bash inventories/production/hosts># Inventory Datei für die System-Umgebung im SOHO
+#
+# Hinweise:
+#           - Kommentare beginnen mit einem '#'-Zeichen
+#           - leere Zeilen werden ignoriert
+#           - Host- und Gruppendefinitionen werden mit [] abgegrenzt
+#           - Hosts können über ihren Hostnamen, FQN oder ihrer IP-Adresse definiert
+#           - übergeordnete Gruppen werden durch [:children] abgegrenzt
+#
+# Host-Definitionen
+# Hosts ohne Gruppenzuordnung
+localhost
+[edmz]
+vml000210
+[idmz]
+vml000110
+[intra]
+vml010110
+# Host-Gruppen-Definitionen
+# (zu welcher Gruppe gehören Untergruppen bzw. Hosts)
+[linux:children]
+intra
+edmz
+idmz
 </file>
+++++
+Bei den Host-Variablen definieren wir über die Variable **''radvd_ipv6_mode''**, wie in unserer Umgebung die IPv6-Adressen letztlich generiert bzw. verteilt werden sollen. Wollen wir **[[#slaac_-_ipv6_stateless_address_auto-configuration|SLAAC - IPv6 Stateless Address Auto-Configuration]]** in unserem Netzwerk-(segment) nutzen, so setzen die die Variable **''radvd_ipv6_mode: "slaac"''**. Wollen wir hingegen **[[#router_advertisement_icmpv6-nachrichten_fuer_stateful_dhcpv6|IPv6 Stateful DHCPv6]]** nutzen, so setzen wir die Variable **''radvd_ipv6_mode: "dhcp6"''**.
+Bei der Definition unseres KVM-Hosts hatten wir unter anderem definiert:
+  * **''guest_nic_2       : %%"%%eth1%%"%%''**
+  * **''guest_ip6_net_2   : %%"%%2003:a:bcd:1234::%%"%%''**
+  * **''guest_mask6_2     : %%"%%/64%%"%%''**
+  * **''guest_ip6_ls_fx_2 : %%"%%fdb6:cb48:9d77:0::%%"%%''**
+  * **''guest_zone_2      : %%"%%intra%%"%%''**
+++++ inventories/production/host_vars/vml010110/kvm_vhost |
+<file bash inventories/production/host_vars/vml010110/kvm_vhost>guest_nic_2:        "eth1"
+guest_ip6_net_2:    "2001:a:bcd:1234::"
+guest_mask6_2:      "/64"
+guest_ip6_ls_fx_2:  "fdb6:cb48:9d77:0::"
+guest_zone_2:       "intra"
+</file>
+++++
+Die für den **radvd** relevanten Konfigurationsparameter legen wir in der Inventrory-Datei **''inventories/production/host_vars/vml010110/radvd''** ab.
+   $ vim inventories/production/host_vars/vml010110/radvd
+++++ inventories/production/host_vars/vml010110/radvd |
+{{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/inventories/production/host_vars/vml010110/radvd  }}
+++++
+=== Playbook ===
+Unser Playbook zum Installieren und Konfigurieren unseres Router Advertisement Daemon **radvd**, ist unscheinbar und unspektakulär.
+   $ vim playbooks/arch_radvd.yml
+{{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/playbooks/arch_radvd.yml }}
+=== Rolle ===
+Für die Konfiguration unseres **radvd** verwenden wir eine eigene Rolle **''radvd''**, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. hierzu kopieren wir uns zunächst die Mustervorlage **''common''**.
+   $ cp -avr roles/common/ roles/radvd
+<code>'roles/common/' -> 'roles/radvd'
+'roles/common/defaults' -> 'roles/radvd/defaults'
+'roles/common/defaults/.gitkeep' -> 'roles/radvd/defaults/.gitkeep'
+'roles/common/files' -> 'roles/radvd/files'
+'roles/common/files/.gitkeep' -> 'roles/radvd/files/.gitkeep'
+'roles/common/handlers' -> 'roles/radvd/handlers'
+'roles/common/handlers/.gitkeep' -> 'roles/radvd/handlers/.gitkeep'
+'roles/common/library' -> 'roles/radvd/library'
+'roles/common/library/.gitkeep' -> 'roles/radvd/library/.gitkeep'
+'roles/common/lookup_plugins' -> 'roles/radvd/lookup_plugins'
+'roles/common/lookup_plugins/.gitkeep' -> 'roles/radvd/lookup_plugins/.gitkeep'
+'roles/common/meta' -> 'roles/radvd/meta'
+'roles/common/meta/.gitkeep' -> 'roles/radvd/meta/.gitkeep'
+'roles/common/module_utils' -> 'roles/radvd/module_utils'
+'roles/common/module_utils/.gitkeep' -> 'roles/radvd/module_utils/.gitkeep'
+'roles/common/tasks' -> 'roles/radvd/tasks'
+'roles/common/tasks/main.yml' -> 'roles/radvd/tasks/main.yml'
+'roles/common/templates' -> 'roles/radvd/templates'
+'roles/common/templates/.gitkeep' -> 'roles/radvd/templates/.gitkeep'
+'roles/common/vars' -> 'roles/radvd/vars'
+'roles/common/vars/.gitkeep' -> 'roles/radvd/vars/.gitkeep'
+</code>
+Bei Bedarf können wir uns die Struktur die somit angelegt wurde mit nachfolgendem Befehl anzeigen lassen.
+   $ tree roles/radvd/
+++++ Ausgabe von tree roles/radvd/ |
+<code>roles/radvd/
+├── defaults
+├── files
+├── handlers
+├── library
+├── lookup_plugins
+├── meta
+├── module_utils
+├── tasks
+│   ├── firewalld.yml
+│   ├── install.yml
+│   ├── main.yml
+│   └── variablencheck.yml
+├── templates
+│   ├── radvd_both_config.j2
+│   └── radvd_single_config.j2
+└── vars
+</code>
+++++
+Wie wir sehen ist die Rolle durchaus überschaubar, im Task **''main.yaml''** verweisen wir lediglich auf die eigentlichen Tasks **''variablencheck''**, **''install.yml''** und **''firewalld.yml''**
+   $ vim roles/radvd/tasks/main.yml
+{{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/tasks/main.yml }}
+Bei der Konfiguration unseres **radvd** haben wir in unserem Konfigurationsbeispiel, ob nur eine **GUA** oder eine **ULA** oder eben beide Adresstypen genutzt werden sollen. Zusätzlich haben wir noch die Wahl ob eine IPv6 mit Hilfe von **[[https://www.rfc-editor.org/rfc/rfc4862|SLAAC]]** oder **[[https://www.rfc-editor.org/rfc/rfc8415|Statful DHCPv6]]** bezogen werden soll.
+<WRAP center round tip 80%>
+Für die Überlegungen welche Adressen und wie diese bezogen werden, hilf unter anderem der **[[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Internetsicherheit/isi_lana_leitfaden_IPv6_pdf.pdf?__blob=publicationFile|Leitfaden für eine sichere IPv6-Netzwerkarchitektur]]** vom **[[https://www.bsi.bund.de|Bundesamt für Sicherheit in der Informationstechnik]]**.
+</WRAP>
+Die Konfiguration welcher Adresstyp und ob **SLAAC** und|oder **DHCPv6** zum Einsatz kommen wird, wird im Inventory mit den beiden Variablen **''radvd_gua_mode''** und **''radvd_ula_mode''** gesetzt:
+GUA-/LUA-Mode bei IPv6-Adressen:
+  * **''noone''** = weder SLAAC noch DHCPv6, keine Adresse
+  * **''slaac''** = Adresse via SLAAC generieren
+  * **''dhcp6''** = Adresse via DHCPv6 beziehen
+Um sicher zu stellen, dass die beiden Variablen **''radvd_gua_mode''** und **''radvd_ula_mode''** mit validen Daten gefüttert werden, überprüfen wir in einem Task die Gültigkeit der Daten.
+   $ vim roles/radvd/tasks/variablencheck.yml
+{{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/tasks/variablencheck.yml }}
+Die eigentliche Installation und Konfiguration erfolgt dann im Task **''install.yml''**.
+   $ vim roles/radvd/tasks/install.yml
+{{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/tasks/install.yml }}
+Die Anpassung an unserer Firewall-Konfiguration  erfolgt im Task **''firewalld''**.
+   $ vim roles/radvd/tasks/firewalld.yml
+{{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/tasks/firewalld.yml }}
+Die beiden Templates **''radvd_single_config.j2''** und **''radvd_both_config.j2''** werden verwendet entsprechend der Auswahl ob nun Nur **GUA** oder **ULA** verwendet werden sollen oder beide.
+Das Template **''radvd_single_config.j2''** für die Generierung der Konfigurationsdatei **''/etc/radvd.conf''**, wenn nur eine der beiden Adressarten gewählt wurde, hat folgenden Aufbau.
+   $ vim roles/radvd/templates/radvd_single_config.j2
+{{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/templates/radvd_single_config.j2 }}
+Sollen sowohl **GUA** wie **ULA** zum Einsatz kommen wird das zweite Template **''radvd_both_config.j2''** herangezogen.
+   $ vim roles/radvd/templates/radvd_both_config.j2
+{{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/templates/radvd_both_config.j2 }}
@@ Zeile 1695: / Zeile 1931: @@
 </html>
+/*
+[15:40:36] Gathering Facts
+↳  vml010110 | SUCCESS | 3.43s
+[15:40:40] radvd : Prüfen ob die Variablen für GUA und ULA valide Werte haben.
+↳  vml010110 | SUCCESS | 12ms
+[15:40:40]     ↳ variablencheck: Prüfen ob die Variable radvd_gua_mode gesetzt wurde.
+↳  vml010110 | SUCCESS | 34ms
+[15:40:40]     ↳ variablencheck: Prüfen ob die Variable radvd_ula_mode gesetzt wurde.
+↳  vml010110 | SUCCESS | 34ms
+[15:40:40]     ↳ variablencheck: Prüfen ob die beiden Variable raddv_gua_mode und radvd_ula_mode = noone sind.
+vml010110 | SKIPPED | 19ms
+[15:40:40] radvd : Installation und Konfiguration des Router Advertisement Daemon radvd.
+↳  vml010110 | SUCCESS | 13ms
+[15:40:40]     ↳ install: Installation des Router Advertisement Daemon radvd.
+↳  vml010110 | SUCCESS | 4.12s
+[15:40:44]     ↳ install: Checken ob es bereits eine Backupdatei der radvd.conf gibt.
+↳  vml010110 | SUCCESS | 765ms
+[15:40:45]     ↳ install: Backupdatei der radvd.conf Konfigurationsdatei erstellen.
+vml010110 | SKIPPED | 18ms
+[15:40:45]     ↳ install: GUA _oder_ ULA: Generieren und kopieren der radvd Konfigurationsdatei /etc/radvd.conf
+vml010110 | SKIPPED | 17ms
+[15:40:45]     ↳ install: GUA _und_ ULA: Generieren und kopieren der radvd Konfigurationsdatei /etc/radvd.conf
+↳  vml010110 | CHANGED | 1.30s
+[15:40:46]     ↳ install: Restart des radvd zur Aktivierung der Konfiguration.
+↳  vml010110 | CHANGED | 1.08s
+[15:40:47] radvd : Konfiguration des firewalld für den Router Advertisement Daemon radvd.
+↳  vml010110 | SUCCESS | 16ms
+[15:40:47]     ↳ firewalld: Sicherstellen, dass der Firewall-Daemon reboot(-fest) starten.
+↳  vml010110 | CHANGED | 1.12s
+[15:40:48]     ↳ firewalld: Service basierte Rules je Zone definieren
+↳  vml010110 | SUCCESS | 874ms
+[15:40:49]     ↳ firewalld: Zum Schluss den aktuellen permanenten Regelsatz final neu laden.
+↳  vml010110 | CHANGED | 852ms
+[15:40:50] system
+-- Play recap --
+vml010110                  : ok=13   changed=4    unreachable=0    failed=0    skipped=3    rescued=0    ignored=0
+✔ ~/devel/ansible [main|✚ 1]
+*/
+FIXME
 === Ergebniskontrolle ===
 Nun prüfen wir, ob unser **radvd** auch die richtigen Router Advertisement ICMPv6 Nachrichten ins Netz schickt. Hier bieten sich zwei mögliche Varianten an:
@@ Zeile 1752: / Zeile 2028: @@
 }; # End of interface definition</code> In regelmäßigen Abständen tauchen also diese RA-Meldungen auf.
   - Mit Hilfe von **''tcpdump''** können wir auch die RA-Meldungen mitschneiden und darstellen, in nachfolgenden Beispiel ist der Name des Netzwerkinterfaces **''enp0s25''**.<code> # tcpdump -vi enp0s25 "icmp6[icmp6type] == icmp6-routeradvert"</code><code>cpdump: listening on enp0s25, link-type EN10MB (Ethernet), snapshot length 262144 bytes
-:58:47.643378 IP6 (flowlabel 0xc155a, hlim 255, next-header ICMPv6 (58) payload length: 136) _gateway > nitropad: [icmp6 sum ok] ICMP6, router advertisement, length 136
+:23:42.141271 IP6 (flowlabel 0xc155a, hlim 255, next-header ICMPv6 (58) payload length: 136) _gateway > nitropad: [icmp6 sum ok] ICMP6, router advertisement, length 136
 	hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
 	  prefix info option (3), length 32 (4): 2001:a:bcd:1234::/64, Flags [onlink], valid time 5400s, pref. time 2700s