Warum funktionierte IPv6 in meinem Heimnetzwerk nicht?

• Im Heimnetzwerk war ping google.com erfolgreich, aber ping6 google.com schlug fehl. Die Ursache war, dass in den Adguard Home DNS-Einstellungen IPv6-DNS-Abfragen deaktiviert waren.
• ACT broadband unterstützte IPv6 früher nicht, wurde aber offenbar schrittweise für Nutzer in Chennai ausgerollt. Als IPv6 im Router aktiviert wurde, funktionierte es normal.
• Bei jüngsten Netzwerktests trat das IPv6-Problem erneut auf, doch im Admin-Portal des Routers war die IPv6-Verbindung des ISP selbst sichtbar, und auf macOS sowie einem Raspberry Pi ließ sich das Problem ebenfalls reproduzieren.
• Bei dig AAAA google.com wurde kein DNS-Ergebnis zurückgegeben, wodurch sich der Fehlerbereich vom ISP-Anschluss oder den Client-Einstellungen auf den DNS-Server eingrenzen ließ, der AAAA-Record-Abfragen verarbeitet.
• Das Problem entstand durch eine Einstellung, nachdem DNS im vergangenen Jahr auf Adguard Home umgestellt worden war. Nach dem Deaktivieren des Schalters zum Blockieren von IPv6-DNS-Abfragen waren sowohl ping -4 als auch ping -6 mit 0 % Paketverlust erfolgreich.

---

Ursache und Lösung

• Im Heimnetzwerk war ping google.com erfolgreich, aber ping6 google.com schlug fehl. Die letztendliche Ursache war, dass in den Adguard Home DNS-Einstellungen sämtliche IPv6-DNS-Abfragen deaktiviert waren.
• ACT broadband unterstützte IPv6 eine Zeit lang nicht, doch vor einigen Jahren wurde bestätigt, dass es schrittweise für Nutzer in Chennai ausgerollt wurde. Nach der Aktivierung von IPv6 im Router funktionierte damals alles problemlos.
• Kürzlich wurde beim Testen der Netzwerkverbindung nach Änderungen am Schreibtisch-Setup das IPv6-Problem erneut sichtbar, während im Admin-Portal des Routers die IPv6-Verbindung des ISP selbst bestätigt wurde.
• Auch in den macOS-Netzwerkeinstellungen war IPv6 erlaubt, und auf einem per LAN mit dem Router verbundenen Raspberry Pi trat dasselbe Problem auf, sodass es kaum an einem einzelnen Gerät liegen konnte.
• Um direkt mit einer IPv6-Adresse zu testen, wurde dig AAAA google.com ausgeführt, aber es wurde kein DNS-Ergebnis zurückgegeben. Da Google IPv6 unterstützt, fiel der Verdacht auf den DNS-Server.
• Nachdem dem Autor wieder einfiel, dass DNS im vergangenen Jahr auf Adguard Home umgestellt worden war, wurden die DNS-Server-Einstellungen überprüft und ein kleiner Schalter entdeckt, der IPv6-DNS-Abfragen blockierte.
• Nach dem Deaktivieren dieser Einstellung und dem Speichern funktionierten sowohl IPv4 als auch IPv6 wieder korrekt.

Prüfprozess und Ergebnis

• Symptome prüfen

  • IPv4-Namensauflösung und -Verbindung funktionierten normal.
  • IPv6-Namensauflösung oder -Verbindung schlugen fehl.
  • Die verwendeten Basistests waren die folgenden:

    ping google.com
    ping6 google.com
    

• ISP- und Geräteeinstellungen prüfen

  • Zuerst lag der Verdacht nahe, dass der ISP IPv6 erneut deaktiviert hatte, doch im Admin-Portal des Routers wurde die IPv6-Verbindung bestätigt.
  • Auch in den macOS-Netzwerkeinstellungen war IPv6 erlaubt.
  • Dasselbe Problem trat auch auf dem Raspberry Pi auf, weshalb ein Problem in der Konfiguration eines einzelnen Clients unwahrscheinlich war.
  • Da ein eigener DNS-Server verwendet wurde, wurden auch die IPv6-DNS-Serveradresse des Routers und die IP-Adresse der Ethernet-Schnittstelle des Raspberry Pi abgeglichen.

• Hinweise, die auf ein DNS-Problem hindeuteten

  • Um ein Problem bei der Weitergabe von IPv6-DNS über DHCP auszuschließen, sollte die IPv6-Adresse direkt überprüft werden. Doch dig AAAA google.com lieferte kein Ergebnis.
  • An diesem Punkt ließ sich das Problem nicht mehr auf die ISP-Verbindung oder die IPv6-Freigabe auf dem Client zurückführen, sondern auf den DNS-Server, der AAAA-Record-Abfragen verarbeitet.

• Verifizierung nach der Korrektur

  • Nachdem in den Adguard-Home-Einstellungen der Schalter zum Deaktivieren von IPv6-DNS-Abfragen ausgeschaltet worden war, waren sowohl ping -4 als auch ping -6 erfolgreich.
  • Beim IPv4-Test wurden 5 Pakete an 172.217.24.110 gesendet, 5 empfangen, bei 0 % Paketverlust.
  • Beim IPv6-Test wurden 5 Pakete an 2404:6800:4007:817::200e gesendet, 5 empfangen, bei 0 % Paketverlust.
  • Die Aktivierung von IPv6 bringt Vorteile wie geringere Latenz, bessere P2P-Verbindungen ohne NAT traversal und Mechanismen wie SLAAC.

[GN⁺]

Lobste.rs-Kommentare

• Das ist furchtbar, und AdGuard Home sollte sich schämen

  • Diese Einstellung scheint standardmäßig nicht aktiviert zu sein.
    Ich nutze auch AdGuard Home, und hier ist sie deaktiviert; außerdem habe ich die Einstellungen/den Router erst vor weniger als zwei Wochen ersetzt, daher bin ich ziemlich sicher, dass ich daran nichts geändert habe.

• Ich verstehe nicht, warum es diese Funktion überhaupt gibt

  • Weil die DNS-Werbeblocker-Community insgesamt, insbesondere AdGuard und Pi-hole, historisch ziemlich feindselig gegenüber IPv6 und Dual-Stack-Netzwerken war.
    Wenn bei solchen Diensten Support-Anfragen eingehen, lautet die erste Empfehlung immer noch oft „IPv6 deaktivieren“, egal ob über offizielle Support-Kanäle oder in Projekt-Communitys wie Foren, Discord oder Subreddits.

• IPv6 ist schlecht entworfen und bei der Konfiguration leicht falsch zu machen, deshalb lautet der naheliegendste Rat, es abzuschalten

• Ich habe gerade das umgekehrte Problem debuggt: In meinem Heimnetzwerk funktionierte IPv4 nicht.
  Es war ein IPv6-only-Dienst, der für IPv4-Konnektivität DS-Lite nutzte; bei DS-Lite tunnelt der Heimrouter IPv4-Pakete an den AFTR, also das NAT des ISP.
  Die Domain des AFTR wird per DHCPv6 bereitgestellt und hatte bei mir die Form something.aftr.kabelbw.de, aber aktuell wird diese Domain nicht aufgelöst, weil denic Probleme mit seiner DNSSEC-Konfiguration hat.
  Zum Glück hat nirgendwo jemand IPv6 deaktiviert, daher funktioniert bis auf GitHub alles problemlos.