Man stolpert irgendwann über diese Meldung im Kernel-Log:
rt6_redirect: source isn't a valid nexthop for redirect target
Gerne 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.
Die 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.
Worum geht es überhaupt?
ICMPv6 Redirects (Typ 137) sind Teil von Neighbor Discovery. Ein Router sagt damit zu einem Host sinngemäß:
„Für dieses Ziel gibt es einen besseren ersten Hop als mich.“
Wichtig: erster Hop. Nicht irgendein Router irgendwo, sondern ein direkt erreichbarer Nachbar auf dem Link.
Ein Redirect enthält deshalb zwei zentrale Informationen:
- das Target (Zieladresse, für die das Redirect gilt)
- den Better Next Hop
Und jetzt kommt der Teil, den viele Implementierungen (und Admins) gerne unterschätzen:
Der Host muss diesem Vorschlag nicht glauben.
Was Linux hier tatsächlich prüft
Linux ist bei Redirects ziemlich streng. Zu Recht. Redirects sind ein beliebtes Einfallstor für Unsinn und Angriffe.
Bevor der Kernel ein Redirect akzeptiert, prüft er u. a.:
- stammt das Redirect von einem Router, den ich bereits als Router kenne?
- liegt der vorgeschlagene Next Hop auf demselben Link?
- ist dieser Next Hop als Neighbor bekannt bzw. grundsätzlich auflösbar?
- passt das Ganze zur bestehenden Routing-Entscheidung?
Und genau hier schlägt diese Logmeldung zu.
Der Kernel schaut auf den Better Next Hop im Redirect und stellt fest:
„Diese Adresse kann für dieses Ziel kein gültiger Next Hop sein.“
Dann wird das Redirect verworfen. Keine neue Route. Kein Update. Nur diese Meldung.
Der Klassiker: Global statt Link-Local
In der Praxis sieht man das oft in Setups, in denen Router ihre Default-Route oder interne Routen nicht sauber über Link-Local-Adressen aufbauen.
Beispiel (vereinfacht):
default via 2001:db8:1::1 dev eth0
Sieht harmlos aus. Funktioniert auch meistens. Aber:
IPv6 erwartet, dass Router auf einem Link über ihre Link-Local-Adresse angesprochen werden.
Korrekt wäre also eher:
default via fe80::1 dev eth0
Was passiert nun?
Der Router verschickt ein Redirect und trägt als „Better Next Hop“ seine globale Adresse ein (z. B. 2001:db8:1::1).
Der Host bekommt das Redirect, prüft es – und sagt:
„Moment. Dieser Next Hop ist kein gültiger direkt erreichbarer Neighbor für dieses Ziel.“
Und genau dann landet diese Meldung im Log.
Wichtig:
Das Problem ist nicht primär, dass die Adresse global ist.
Das Problem ist, dass der Kernel den vorgeschlagenen Next Hop nicht als legitimen First Hop auf diesem Link akzeptiert.
Link-Local ist der Normalfall. Alles andere muss extrem gut begründet sein – und ist es fast nie.
Ein Blick auf die Nachbartabelle hilft
Wenn man wissen will, warum der Kernel das Redirect ablehnt, lohnt sich ein Blick in die Neighbor-Daten:
ip -6 neigh show
Oder gezielter:
ip -6 route get 2001:db8:dead:beef::1
Wenn der vorgeschlagene Next Hop dort nicht als sinnvoller Neighbor auftaucht, ist die Sache im Prinzip entschieden.
Kein Neighbor → kein gültiger Next Hop → Redirect wird verworfen.
Warum das kein Bug ist
Die Meldung klingt erstmal nach kaputtem Routing. Ist es aber meistens nicht.
Im Gegenteil:
Der 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.
Das schützt unter anderem vor:
- falschen Router-Konfigurationen
- kaputten RA-Setups
- Bridge-/VM-Konstrukten mit „kreativem“ IPv6
- trivialen Redirect-Spoofing-Angriffen
Fazit
Die Meldung
rt6_redirect: source isn't a valid nexthop for redirect target
bedeutet nicht „IPv6 kaputt“.
Sie bedeutet: Ein Router hat ein Redirect geschickt, das aus Sicht des Hosts keinen gültigen Next Hop beschreibt.
In der Praxis ist das fast immer ein Hinweis auf:
- Default- oder interne Routen ohne Link-Local-Next-Hop
- Router, die globale Adressen in Redirects verwenden
- Setups, in denen Neighbor Discovery und Routing nicht sauber zusammenpassen
Oder anders gesagt:
Der Kernel ist hier nicht pingelig. Er ist vorsichtig. Und das ist gut so.
Im Folgenden nun als kleines Beispiel das Zonenfile vom Bind für kernel-error.com mit den gesetzten Records.
