Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:radvd [09.07.2024 14:27. ] – [Musterkonfiguration GUA via SLAAC und ULA via DHCPv6] django
+++ linux:radvd [10.07.2024 18:40. ] (aktuell) – [RA — Router Advertisement (ICMPv6 type 134)] django
@@ Zeile 61: / 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 67: / 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 176: / Zeile 176: @@
   - **[[#slaac_-_ipv6_stateless_address_auto-configuration|Konfigurationsbeispiel: SLAAC - IPv6 Stateless Address Auto-configuration]]**
   - **[[#router_advertisement_icmpv6-nachrichten_fuer_stateful_dhcpv6|Konfigurationsbeispiel: DHCPv6 - stateless und stateful]]**
-  - **[[#musterkonfiguration|Musterkonfiguration für GUA via SLAAC und statischen festen ULA mit Hilfe von DHCPv6]]** FIXME //..coming soon..// FIXME
+  - **[[#musterkonfiguration_gua_via_slaac_und_ula_via_dhcpv6|Musterkonfiguration für GUA via SLAAC und statischen festen ULA mit Hilfe von DHCPv6]]**
 </WRAP>
@@ Zeile 230: / Zeile 229: @@
   * **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 699: / 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 1162: / Zeile 1161: @@
 ==== Musterkonfiguration GUA via SLAAC und ULA via DHCPv6 ====
- In den beiden vorgenannten Konfigurationsbeispielen
+=== Grundüberlegungen ===
+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.
+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.
+<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%>
+Je länger man sich nun mit der ganzen Thematik um nicht Misere zu sagen beschäftigt kommt man zu folgender Musterkonfigurationslösung:
+  - **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>
+<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)
+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>
+=== radvd Konfiguration ===
+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:
+  * **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.
+  * **GUA**
+    * **SLAAC** : \\ Clients sollen sich über den Mechanismus **SLAAC** selbst öffentliche IPv6-Adressen generieren und das ohne Zuhilfenahme eines DHCPv6-Servers bei der Adressvergabe!
+    * **Global-Scope Address Prefix** : \\ **''2001:a:bcd:1234''**
+    * **Route** : \\ **''2001:a:bcd:1234::/64''**
+    * **AdvRouteLifetime** : \\ Gültigkeit der Routen Lifetime  von einer 1/2 Stunde, also **''1800''** Sekunden.
+    * **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)
+  * **ULA**
+    * **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''**.
+    * **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)
+Daraus ergibt sich nun folgende Konfigurationsdatei für unseren radvd:
+   # vim /etc/radvd.conf
+<file bash /etc/radvd.conf># Configuration example for the router advertisement daemon radvd
+# for GUA and SLAAC as well as ULA with DHCPv6
+#
+#  - O-flag: AdvOtherConfigFlag = on (obtaining a DNS server list
+#            and a domain name from a Stateless DHCPv6 server, but
+#            not addressing information.
+#  - M-flag: AdvManagedFlag = off (address configuration via SLAAC for GUA)
+#  - A-flag: AdvAutonomous = on (address configuration via SLAAC for GUA)
+#  - A-flag: AdvAutonomous = off (address configuration via DHCPv6 for static ULA)
+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
+  # to be on to enable advertisement on this interface.
+  AdvSendAdvert on;
+  # The  maximum  time  allowed between sending unsolicited multi-
+  # cast router advertisements from the interface, in seconds.
+  # 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;
+  # 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 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.
+  AdvManagedFlag on;
+  # 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.
+  #
+  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
+  # Section 7.3 of RFC 4861).
+  # A value of zero means unspecified (by this router).
+  # Must be no greater than 3,600,000 milliseconds (1 hour).
+  AdvReachableTime 0;
+  # 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;
+  # The default value that should be placed in the Hop Count field of
+  # the IP header for outgoing (unicast) IP packets. The value should
+  # be set to the current diameter of the Internet.
+  # The value zero means unspecified (by this router).
+  AdvCurHopLimit 64;
+  # The lifetime associated with the default router in units of seconds.
+  # The maximum value corresponds to 18.2 hours. A lifetime of 0 indi-
+  # cates that the router is not a default router and should not appear
+  # on the default router list. The router lifetime applies only to the
+  # 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 1800;
+  # When set, the link-layer address of the outgoing interface is
+  # included in the RA.
+  AdvSourceLLAddress on;
+  # global-scope adress prefix
+  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.
+    AdvAutonomous on;
+    # 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.
+    #
+    # Note that clients will ignore AdvValidLifetime of an existing
+    # prefix if the lifetime is below two hours, as required in RFC
+    # 4862 Section 5.5.3 point e).
+    # Note: RFC4861's suggested default value is significantly longer:
+    # 30 days.
+    AdvValidLifetime 5400;
+    # The length of time in seconds (relative to the time the packet
+    # is sent) that addresses generated from the prefix via stateless
+    # address autoconfiguration remain preferred. The symbolic value
+    # infinity represents infinity (i.e. a value of all one bits
+    # (0xffffffff)).  See RFC 4862.
+    #
+    # Note: RFC4861's suggested default value is significantly longer:
+    # 7 days.
+    AdvPreferredLifetime 2700;
+    };
+ route 2003:a:e0d:7607::/64
+  {
+    # The preference associated with the default router, as either
+    # "low", "medium", or "high".
+    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 1800;
+  };
+  prefix fdb6:cb48:9d77:0::/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.
+    AdvAutonomous off;
+    # 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.
+    #
+    # Note that clients will ignore AdvValidLifetime of an existing
+    # prefix if the lifetime is below two hours, as required in RFC
+    # 4862 Section 5.5.3 point e).
+    # Note: RFC4861's suggested default value is significantly longer:
+    # 30 days.
+    AdvValidLifetime 5400;
+    # The length of time in seconds (relative to the time the packet
+    # is sent) that addresses generated from the prefix via stateless
+    # address autoconfiguration remain preferred. The symbolic value
+    # infinity represents infinity (i.e. a value of all one bits
+    # (0xffffffff)).  See RFC 4862.
+    #
+    # Note: RFC4861's suggested default value is significantly longer:
+    # 7 days.
+    AdvPreferredLifetime 2700;
+    };
+ route fdb6:cb48:9d77:0::/64
+  {
+    # The preference associated with the default router, as either
+    # "low", "medium", or "high".
+    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 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
+#
+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 ====