IPv6 ULA Adresse - keine Anfragen von fd00 Clients

Hallo,
zum Zeitpunkt der Installation von Pi Hole auf meinem Raspberry hatte mein Netzwerk noch keine ULA IPv6 Adressen, sondern ausschließlich die link-local fe00: und die öffentlichen IPv6 Adressen, da ich einen Dual Stack Internetanschluss habe und das Prefix vom Router (Unifi USG) durchgereicht wird.
Da ich - auch hier im Forum - immer wieder gelesen habe, dass es bei Pi Hole am besten ist ULA Adressen zu benutzen, habe ich das entsprechend "nachgerüstet", und ein paar Fragen dazu. Hier aber erstmal kurz die Schritte meiner Umstellung auf ULA:

  1. Im USG Gateway per config.gateway.json ein fd59 Prefix erstellt. Dieses habe ich vorab hier https://cd34.com/rfc4193/ mittels MAC Adresse der LAN Schnittstelle des Gateways errechnen lassen. Nun bekommen alle Geräte (außer das USG selbst) auch eine vollständige fd59:... Adresse.
  2. In der setupvars.conf von Pi Hole bei IPV6 die fd59:... Adresse eingetragen, die auf dem Pi Hole unter terminal mit dem Befehl ip -6 addr show angezeigt wird. Dort werden 3 IPv6 angezeigt, ich habe die mit fd59:... genommen. Diese bleibt anscheinend, auch bei Neustart des Raspberry oder Routers; dies ist ja auch gewünscht.
  3. Ebenfalls diese fd59:... Adresse in den LAN Einstellungen des Gateways als DHCPv6/RDNSS Name Server so eingetragen, dass diese bei allen Clients als IPv6 DNS automatisch auftaucht. Das klappt auch bei den Clients.
  4. Als Gateway wird in den Apple Geräten unter IPv6 immer die fe00 Link-Local des Routers automatisch angezeigt.

Also eigentlich scheint alles zu klappen, laut Dashboard werden sowohl IPv4 als auch IPv6 Requests bearbeitet. Internetzugriff klappt auch auf den Clients.

Aber, und hier kommen die Fragen:

  1. Ist die Vorgehensweise wie oben beschrieben so korrekt, oder habe ich etwas nicht berücksichtigt?
  2. Auf keinem meiner iPhones / Macs wird nun noch eine fe00 Link-Local Adresse angezeigt, sondern nur mehrere öffentliche IPv6 2a02:... und die ULA mit dem Prefix fd59. Was ist denn mit der Link-Local Adresse? Gibt es die jetzt nicht mehr? Ich dachte die sei immer da?
  3. In den Pi Hole Statistiken bspw. Top-Clients erscheinen nun die Hostnamen der Clients, das gefällt mir. Es ist jedoch so, dass beim Hover-over eines Hostnamens nur die lokale IPv4 angezeigt wird. Bedeutet das, dass dieser Client nur per IPv4 DNS Anfragen stellt?
    image

Was ist denn mit den IPv6 Requests, die ja von den fd59 ULA Adressen kommen müssten? Immerhin ist lt. Statistik die Aufteilung:
Typ A (IPv4) ca 40%
Typ AAAA (IPv6) ca 40%
Rest HTTP etc. 20%

  1. Ist es korrekt, dass als Gateway in den devices die Link-Local fe00 Adresse auftaucht?

So, ich hoffe ihr könnt mir bei den offenen Fragen helfen. Danke schon mal!

Das sollte alles soweit passen. Zur Bestätigung kannst du eine DNS Anfrage explizit an die ULA Adresse deines Pi-hole stellen und schauen, ob du eine Antwort bekommst: dig google.com @fd59:...

Da kann ich nicht helfen, ich habe keine Apple Geräte hier. Die Link-Lokalen Adressen sollte es aber auf jeden Fall noch geben.

Ja, verschiedene IP Adressen werden als unterschiedliche Clients angezeigt. Würden deine Geräte auch über IPv6 kommunizieren, würden die Hostnamen mehrfach in der Liste stehen und beim Hovern würde die jeweilige IP Adresse angezeigt werden. In der Netzwerkübersicht (Tools > Network) werden die Geräte jedoch über ihre MAC Adresse zu einem einzigen Eintrag zusammengefasst. Schaue dort nach, ob auch IPv6 Addressen den Geräten zugeordnet werden.

Das ist unabhängig von der IP Adresse, über die kommuniziert wird. AAAA Daten sind lediglich ein Typ von DNS Daten, die eine IPv6 Addresse enthalten. Diese Daten können aber problemlos über IPv4 abgerufen werden. Genauso werden HTTPS DNS Daten nicht wirklich über das HTTPS Protokoll abgerufen (sofern du nicht DoH implementierst), es ist einfach ein anderer Datentyp.

Ja. Da das Gateway per Definition Teil des gleichen Links wie das Gerät ist, ist die Link-Lokale Addresse hier in Ordnung.

1 Like

Hallo, super Danke für die ausführliche Antwort. Das hilft mir schon mal. Bei einer Sache bin ich noch etwas verunsichert:

Es war vorher so, dass viele Hostnamen doppelt angezeigt wurden: einmal mit der IPv4, und dann nochmal mit der Link-Local fe00:... Adresse. Beide waren in den Top Listen fast immer dabei. Bedeutet also, dass vorher die Kommunikation in Sachen DNS über IPv4 und IPv6 ablief?

Seit meiner Umstellung auf ULA gibt es aber anscheinend fast nur noch IPv4 Traffic. Die ULA Adressen tauchen in der Statistik so gut wie gar nicht mehr auf.

In der Netzwerkübersicht werden die Devices unter dem korrekten Hostnamen zusammengefasst. Einige Devices haben entweder nur IPv4; andere haben IPv4, Öffentliche IPv6, LL IPv6, ULA IPv6, teils auch ohne ULA IPv6, bunt gemischt. Wahrscheinlich "lernt" die Netzwerkübersicht und ordnet den Hostnamen erst nach einer erfolgten Anfrage anhand der MAC die korrekten IPs zu?

Ich wundere mich halt, dass vorher so reger IPv6 Verkehr vorhanden war, und seit ich die ULA verwenden fast nur noch IPv4. Ist das normal oder muss ich da tiefer graben?

Das ist richtig, Pi-hole kennt nur die IP Addressen, die zuvor auch eine DNS Anfrage gestellt haben. Diese IP Addressen werden dann über die ARP-Tabelle einer MAC Addresse, und damit einem Gerät, zugeordnet.

Das hab ich zumindest bei den zwei iPhones in meinem Netzwerk auch beobachtet. Du musst dabei aber bedenken, dass viele Geräte standardmäßig temporäre IPv6 Adressen verwenden (RTF4941-Privacy Extensions). Die iPhones hier produzieren so viele temporäre Adressen, dass diese gar nicht mehr in das Hover-Fenster passen, und dass, obwohl ich nur die letzten 8 Tage an Daten aufhebe. Mein Windows-Rechner dagegen generiert eine einzige temporäre Adresse am Tag (oder bei einem Neustart). Der gesamte IPv6 Verkehr, und damit die gesamten Statistiken, werden somit auf all diese temporären Adressen verteilt und tauchen dementsprechend selten in den Top-Listen auf. Die Geräte haben nur eine einzige IPv4 Adresse (oder Link-Lokale IPv6 Adresse), die Statistik für diese ist also entsprechend höher als die für den ganzen Haufen individueller IPv6 Adressen.

Was außerdem hier zu beachten ist, ist dass die Geräte verschiedene IP Adressen durchaus priorisieren. Es wird immer versucht, die Quell-IP-Adresse mit der Ziel-IP-Adresse abzugleichen. Das heißt, wenn die Ziel-IP-Adresse eine ULA ist, wird möglichst auch eine entsprechende ULA als Quell-IP-Adresse verwendet. Sollte das Ziel allerdings mehrere IP Adressen zur Auswahl haben, muss sich für eine entschieden werden. Hierbei werden bestimmte Adressen priorisiert. Unter Windows kann man diese Regeln mit netsh int ipv6 show prefixpolicies einsehen:

>netsh int ipv6 show prefixpolicies
Der aktive Status wird abgefragt...

Vorgänger   Label  Präfix
----------  -----  --------------------------------
        50      0  ::1/128
        40      1  ::/0
        35      4  ::ffff:0:0/96
        30      2  2002::/16
         5      5  2001::/32
         3     13  fc00::/7
         1     12  3ffe::/16
         1      3  ::/96
         1     11  fec0::/10

Die erste Spalte gibt die Priorität an, mit der die entsprechende Adresse verwendet wird (Ich hab keine Ahnung, warum Windows da Vorgänger schreibt). In meinem Fall haben die IPv4 Adressen (::/96 Präfix) die niedrigste Priorität (1), während die ULA (fc00::/7 Präfix) etwas darüber stehen (3). Windows ist natürlich ein bisschen bekloppt und nutzt für DNS Anfragen immmer IPv4 und IPv6, so dass alle Anfragen doppelt und dreifach gestellt werden, aber das ist hier erst einmal irrelevant.

Wichtig ist, dass diese Tablle auf anderen Geräten anders aussehen kann. Es ist möglich, dass die Apple Geräte durchaus die IPv4 Adresse über die ULA stellen und du dadurch generell weniger IPv6 Verkehr siehst.

TL,DR:
Deine Geräte könnten zum einen IPv4 über die ULA an Priorität stellen, zum anderen werden die Statistiken auf viele temporäre IPv6 Adressen verteilt.

3 Likes

Ja es ist wohl von beidem etwas dabei...

Es ist in der Tat so, dass die Apple devices ordentlich IPs generieren und sich die Übersicht der Netzwerkgeräte binnen weniger Tage mit IPv6 bei den Apples füllt. Wie auch immer, es funktioniert ja alles soweit.

Danke für die vielen Informationen.

Nur ergänzend zu Daxtorims vorbildlichen Erläuterungen:

Streng genommen verwendet Pi-hole hier auch ip neighbour statt arp (aber das ist nur eine technische Spitzfindigkeit) :wink:

Vermutlich ein einfacher Übersetzungsfehler:
Der englische Begriff ist precedence - Präzendenz oder Vorrangigkeit.
(Windows 7 und 8 verwenden übrigens durchaus unterschiedliche Tabellen.)

Für die Ermittlung einer Kombination aus Quell- und Zieladresspräfix für eine Kommunikation zwischen zwei Gegenstellen (die jeweils über mehrere Adressen mit unterschiedlichen Präfixen verfügen können) wirkt dabei precedence auf die Auswahl der Zieladresse und label auf die Auswahl der Quelladresse.
Details dazu finden sich in RFC6724.

Prefix Policies sollten nach diesem RFC prinzipiell auch konfigurierbar sein.
Für Smartphones und Tablets ist mir hierzu allerdings keine Möglichkeit bekannt.
Falls jemand diese kennt, würde ich mich über einen entsprechenden Hinweis freuen.

1 Like

@Bucking_Horn Dir auch vielen Dank für die zusätzlichen Infos!

Ich glaube noch nicht einmal im MacOS kann man an den Prefix Policies schrauben, zumindest nicht in den normalen Einstellungen.
Das geht auf keinem Apple Gerät, sind hier alle in Gebrauch.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.