{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicdyctiy6n4esmew3ufvmnzy7qdj4yr7xae665jhnvuhyfllw5q7i",
    "uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmbobmjaedr2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreibb2fedfgnlpu2454nqmw3yhf5kcjewa4ew7d6bk77sqcyqegxngy"
    },
    "mimeType": "image/png",
    "size": 919417
  },
  "description": "`rt6_redirect: source isn't a valid nexthop for redirect target` im Kernel-Log — kein Bug, sondern ein abgelehntes ICMPv6-Redirect. Typischerweise durch globale statt Link-Local-Next-Hops. Diagnose, Fix und wann Abschalten die pragmatische Loesung ist.",
  "path": "/2013/10/24/rt6-redirect-source-isn-t-a-valid-nexthop-for-redirect-target/",
  "publishedAt": "2026-05-20T10:14:13.000Z",
  "site": "https://www.kernel-error.de",
  "tags": [
    "Hardening",
    "IPv6",
    "Linux",
    "Networking",
    "router",
    "Sysadmin",
    "Neighbor Discovery",
    "RFC 3971",
    "IPv6 ULA und Adresspriorisierung",
    "IPv6 Grundlagen",
    "RFC 4861 §8",
    "RFC 6980",
    "Einfach melden."
  ],
  "textContent": "Man stolpert irgendwann über diese Meldung im Kernel-Log:\n\n\n    rt6_redirect: source isn't a valid nexthop for redirect target\n\nGerne im Zusammenhang mit IPv6, gerne dann, wenn man glaubt, eigentlich alles richtig gemacht zu haben. Routing stimmt. Neighbors sehen gut aus. Und trotzdem meckert der Kernel.\n\nDie Kurzfassung: **Der Linux-Kernel hat ein ICMPv6 Redirect bekommen und lehnt es ab, weil der vorgeschlagene Next Hop aus seiner Sicht kein gültiger First Hop ist.**\n\n### Worum geht es überhaupt?\n\nICMPv6 Redirects (Typ 137) sind Teil von Neighbor Discovery. Ein Router sagt damit zu einem Host sinngemäß:\n\n_„Für dieses Ziel gibt es einen besseren ersten Hop als mich.“_\n\nWichtig: _erster Hop_. Nicht irgendein Router irgendwo, sondern ein direkt erreichbarer Nachbar auf dem Link.\n\nEin Redirect enthält deshalb zwei zentrale Informationen:\n\n  * das **Target** (Zieladresse, für die das Redirect gilt)\n  * den **Better Next Hop**\n\n\n\nUnd jetzt kommt der Teil, den viele Implementierungen (und Admins) gerne unterschätzen:\n**Der Host muss diesem Vorschlag nicht glauben.**\n\n### Was Linux hier tatsächlich prüft\n\nLinux ist bei Redirects ziemlich streng. Zu Recht. Redirects sind ein beliebtes Einfallstor für Unsinn und Angriffe.\n\nBevor der Kernel ein Redirect akzeptiert, prüft er u. a.:\n\n  * stammt das Redirect von einem Router, den ich _bereits_ als Router kenne?\n  * liegt der vorgeschlagene Next Hop auf demselben Link?\n  * ist dieser Next Hop als Neighbor bekannt bzw. grundsätzlich auflösbar?\n  * passt das Ganze zur bestehenden Routing-Entscheidung?\n\n\n\nUnd genau hier schlägt diese Logmeldung zu.\n\nDer Kernel schaut auf den **Better Next Hop** im Redirect und stellt fest:\n\n_„Diese Adresse kann für dieses Ziel kein gültiger Next Hop sein.“_\n\nDann wird das Redirect verworfen. Keine neue Route. Kein Update. Nur diese Meldung.\n\n### Der Klassiker: Global statt Link-Local\n\nIn der Praxis sieht man das oft in Setups, in denen Router ihre Default-Route oder interne Routen **nicht sauber über Link-Local-Adressen aufbauen**.\n\nBeispiel (vereinfacht):\n\n\n    default via 2001:db8:1::1 dev eth0\n\nSieht harmlos aus. Funktioniert auch meistens. Aber:\nIPv6 erwartet, dass **Router auf einem Link über ihre Link-Local-Adresse angesprochen werden**.\n\nKorrekt wäre also eher:\n\n\n    default via fe80::1 dev eth0\n\nWas passiert nun?\n\nDer Router verschickt ein Redirect und trägt als „Better Next Hop“ seine **globale Adresse** ein (z. B. `2001:db8:1::1`).\nDer Host bekommt das Redirect, prüft es – und sagt:\n\n_„Moment. Dieser Next Hop ist kein gültiger direkt erreichbarer Neighbor für dieses Ziel.“_\n\nUnd genau dann landet diese Meldung im Log.\n\nWichtig:\nDas Problem ist **nicht primär** , dass die Adresse global ist.\nDas Problem ist, dass der Kernel den vorgeschlagenen Next Hop **nicht als legitimen First Hop auf diesem Link akzeptiert**.\n\nLink-Local ist der Normalfall. Alles andere muss extrem gut begründet sein – und ist es fast nie.\n\n### Ein Blick auf die Nachbartabelle hilft\n\nWenn man wissen will, warum der Kernel das Redirect ablehnt, lohnt sich ein Blick in die Neighbor-Daten:\n\n\n    ip -6 neigh show\n\nOder gezielter:\n\n\n    ip -6 route get 2001:db8:dead:beef::1\n\nWenn der vorgeschlagene Next Hop dort nicht als sinnvoller Neighbor auftaucht, ist die Sache im Prinzip entschieden.\nKein Neighbor → kein gültiger Next Hop → Redirect wird verworfen.\n\n### Das Redirect live mitschneiden\n\nWenn man genau wissen will, ob der Router wirklich ein Redirect schickt und was er als Next Hop vorschlägt, hilft `tcpdump`. ICMPv6 Typ 137 ist das Redirect:\n\n\n    tcpdump -n -i eth0 'icmp6 and ip6[40] == 137'\n\nIm Paket sieht man den Router als Absender, das **Target** (Ziel, für das der Hinweis gilt) und den **Better Next Hop**. Passt der Next Hop nicht zu einem gültigen Neighbor auf dem Link, ist klar warum der Kernel ablehnt.\n\nEbenfalls nützlich: ob der Host Redirects überhaupt annehmen will.\n\n\n    sysctl net.ipv6.conf.all.accept_redirects\n    sysctl net.ipv6.conf.eth0.accept_redirects\n\nDefault ist `1` auf einem Host, `0` auf einem Router. Zusätzlich greift `secure_redirects` (Default `1`): nur Redirects von bereits bekannten Gateways werden überhaupt akzeptiert.\n\n### Default-Route mit Link-Local als Next Hop\n\nWer die Route selbst setzt (statische Konfiguration ohne RA), sollte Link-Local nehmen. Link-Local ist pro Interface nicht eindeutig, der Eintrag braucht also immer ein `dev`:\n\n\n    ip -6 route add default via fe80::1 dev eth0\n\nPersistenz hängt vom System ab. `systemd-networkd` in `/etc/systemd/network/*.network` unter `[Route] Gateway=fe80::1`, `netplan` in `/etc/netplan/*.yaml`, die klassische `/etc/network/interfaces` kennt `post-up ip -6 route ...`. Wichtig: das Interface muss im Eintrag stehen.\n\nMit Link-Local als Next Hop verschwindet die `rt6_redirect`-Meldung in der Regel. Der Kernel hat einen gültigen First Hop als Neighbor, und ein Redirect desselben Routers passt dann sauber ins Modell.\n\n### Oder: Redirects abschalten\n\nAuf Servern in kontrollierten Hosting-Umgebungen (Hetzner, Netcup, Cloud-VPCs) ist das Routing sauber vorgegeben, und der Provider-Router hat keinen besseren Next Hop anzubieten. Dann sind ICMPv6-Redirects nur Rauschen im Log:\n\n\n    sysctl -w net.ipv6.conf.all.accept_redirects=0\n    sysctl -w net.ipv6.conf.default.accept_redirects=0\n\nPersistent in `/etc/sysctl.d/99-ipv6.conf`. Nachteil: kennt der Router tatsächlich einen legitimen besseren Weg, bleibt der Host trotzdem bei seiner existierenden Route. Im Rechenzentrum mit einer einzigen Default-Route ist das genau richtig, in einem verzweigten Firmennetz mit mehreren Uplinks eher nicht.\n\n### Warum das kein Bug ist\n\nDie Meldung klingt erstmal nach kaputtem Routing. Ist es aber meistens nicht.\n\nIm Gegenteil:\nDer Kernel verhält sich exakt so, wie es das Protokoll vorsieht. Redirects sind **Hinweise** , keine Befehle. Und Linux nimmt diese Hinweise nur an, wenn sie sauber in das bestehende Neighbor- und Routing-Modell passen.\n\nDas schützt unter anderem vor:\n\n  * falschen Router-Konfigurationen\n  * kaputten RA-Setups\n  * Bridge-/VM-Konstrukten mit „kreativem“ IPv6\n  * trivialen Redirect-Spoofing-Angriffen\n\n\n\n### Update 2026: was heute anders ist\n\nIn modernen Setups begegnet einem die Meldung seltener. Nicht weil das Protokoll sich geändert hätte, sondern weil die Umgebung drumherum sauberer geworden ist:\n\n  * **Enterprise-Switches** mit _RA Guard_ und _ND Inspection_ filtern unerwünschte RAs und Redirects bereits auf Layer 2 heraus. Cisco, Juniper und andere haben das seit Jahren im Portfolio.\n  * **Cloud-Umgebungen** (AWS VPC, Hetzner Cloud, Azure) liefern ein sauber vorgegebenes Default-Gateway aus, in der Regel ein Link-Local-Hop. Redirects tauchen praktisch nie auf.\n  * **Home-Router** (FritzBox, Unifi, OpenWrt) machen es per Default richtig.\n  * **SEND/CGA** (RFC 3971) hätte kryptografisch signierte Neighbor Discovery gebracht und Redirect-Spoofing strukturell verhindert. Die Adoption ist praktisch bei null geblieben. Tot.\n\n\n\nÜbrig bleibt die Meldung heute fast nur in selbstgebauten VM- und Container-Setups, in denen Host- und Gast-Routing nicht sauber zusammenpassen, oder wenn in statischer Konfiguration aus Gewohnheit eine globale Adresse als Next Hop gesetzt wird.\n\n### Fazit\n\nDie Meldung\n\n\n    rt6_redirect: source isn't a valid nexthop for redirect target\n\nbedeutet nicht „IPv6 kaputt“.\nSie bedeutet: _Ein Router hat ein Redirect geschickt, das aus Sicht des Hosts keinen gültigen Next Hop beschreibt._\n\nIn der Praxis ist das fast immer ein Hinweis auf:\n\n  * Default- oder interne Routen ohne Link-Local-Next-Hop (siehe auch IPv6 ULA und Adresspriorisierung)\n  * Router, die globale Adressen in Redirects verwenden\n  * Setups, in denen Neighbor Discovery und Routing nicht sauber zusammenpassen\n\n\n\nOder anders gesagt:\nDer Kernel ist hier nicht pingelig. Er ist vorsichtig. Und das ist gut so.\n\nSiehe auch: IPv6 Grundlagen. Zum Nachlesen: RFC 4861 §8 (Redirect-Handling bei Hosts) und RFC 6980 (fragmentiertes Neighbor Discovery ist verboten — ein harter Security-Fix für ND-Spoofing).\n\nFragen? Einfach melden.",
  "title": "IPv6 ICMP Redirect erklärt: „rt6_redirect: source isn’t a valid nexthop“"
}