ICMP Redirect

Diese Seite entstand als Folge eines Netzwerk Assessment bei einem Kunden, der gerade seine komplette Netzwerkinfrastruktur umbaut. Das ist gar nicht mal so selten, dass z.B. nach vielen Jahren einmal alle Switches und Core-Router durch neue Modelle oder ganz andere Hersteller getauscht werden. Sehr viele Firmen haben noch relativ "flache"  Netzwerkstrukturen mit einem Subnetz für alle Clients und Server und stellen dabei auch ihr IP-Routing neu auf. Diese Seite beschäftigt sich mit dem Sonderfall "ICMP-Redirect".

Worum geht es?

Es gibt einige Mittelständler, die schon viele Jahre ein recht klassisches Netzwerk betreiben, in dem viele PCs in einem großen Class-C oder Class-B-Netzwerk sind. Alle Server und Drucker und Clients sind im gleichen Subnetz und mit etwas Glück gibt es ein eigenes Subnetz für WLAN, Gäste und vielleicht Produktionssysteme.

Das so ein Setup nicht skaliert und auch nicht mehr der heutigen Sicherheitsanforderung nach Segmentierung von Netzwerken entspricht, ist vermutlich allen klar und wenn Sie eh neue Switche aufbauen wollen, dann ist das doch die Möglichkeit eine langsame Migration umzusetzen. Das könnten dann so aussehen, dass Sie die neuen Netzwerkkomponenten "daneben" stellen und erst einmal neue VLANs einrichten. Der neue Core Switch ist dabei auch ein Router zwischen den Netzwerken, der per ACLs die Verbindungen beschränken kann. Zwar sind die Regeln auf so einem Core Router/Switch nicht ganz so einfach zu steuern wie bei einer "richtigen" Firewall. Aber eine zentrale Firewall, die zwischen allen VLANs mit "Wirespeed" routet, ist schon sehr kostentreibend.

Die bestehenden Clients können Sie dann nach und nach durch Umpatchen von den alten Switches auf die neuen Switch umstellen oder sie haben alle Etagenswitche schon getauscht und wechseln den Port dann vom "Default VLAN" zum gewünschten Ziel. Das kann statisch oder auch per 802.1x-Authentifizierung erfolgen. Aber das alte Netzwerk steht ganz sicher noch in ganz vielen Systemen "im Bauch" in Form von statischen Einträgen in HOSTS-Dateien, Konfigurationsdateien etc.

IP-Routing mit Split Horizont

Es gibt also eine Zeit, in der Clients im alten Netzwerk mit den Clients im neuen Netzwerk kommunizieren müssen aber weiterhin noch die alte Firewall als Default Gateway nutzen. Das Bild sieht dann vereinfacht wie folgt aus:

 

Der PC (3) kann über die Firewall (1), die sein Default Gateway ist, natürlich wie bisher mit dem Internet kommunizieren. Da der PC (3) aktuell aber sonst keine Leitwege kennt, kann er ein Paket an die neuen VLANs aber nur senden, wenn er eine Hilfe bekommt. Hierzu gibt es mehrere Optionen:

  • Firewall (1) routet Paket
    Der Client sendet das Paket, dessen Ziel nicht im eigenen Subnetz liegt, über sein Default Gateway an die Firewall. Die kennt aber den Weg zu den anderen Netzwerken und routet das Paket zu Router (2) weiter, welcher das Paket dann an das Ziel sendet. Das Ziel antwortet über seinen Router (2), welcher dann aber das Paket direkt an den Client (3) sendet. Sie sehen aber schon die Nachteile, das die Firewall (1) auch Pakete routen muss, die in die neuen Subnetze müssen, was Last, Netzwerklast auf deren internem Bein und eine Abhängigkeit bei Ausfällen und Updates mit sich bringt. Es geht aber ist nicht schön. Es soll aber auch Firewalls auf Endgeräten wie PC (3) geben, die eine Rückantwort von einem anderen Router nicht zuordnen können. Das ist aber eher selten und würde ich als Fehlverhalten einschätzen.
  • Firewall (1) sendet redirect
    Um aber Firewall (1) zu entlasten, kann sie das Paket zwar weiterhin routen aber sendet an den Absender ein "ICMP Redirect", d.h. der PC(3) bekommt einen Hinweis, dass es eine bessere Route zum Ziel gibt und der PC (3) solle dies doch das nächste Mal berücksichtigen. Spoiler: Windows ignoriert solche Redirect-Informationen. Sie können sich das sparen. Das hat weniger etwas mit "nicht können" sondern eher mit "nicht erlauben" zu tun, denn ICMP ist nicht gesichert und auch ein Angreifer im gleichen LAN könnte so einen Client vielleicht dazu verleiten, Pakete über den Angreifer zu senden.
  • Client lernt OSPF/RIP/IPv6
    Anstatt auf ICMP-Redirect zu vertrauen, könnte ein System auch über etablierte Routingprotokolle (RIP, OSPF, BGP) natürlich die Leitwege lernen. Allerdings ist das wohl zuviel verlangt, zumal bei OSPF/BGP die Peers explizit konfiguriert werden müssen. So kann ein anderer Router im Verbund seine Konfiguration erhalten aber kein Endgerät.
  • Client bekommt statische Route 
    Aber jeder IP-Stack pflegt sehr wohl eine Routingtabelle. Auch wenn ein Client die ICMP-redirect nicht verarbeitet, kann ich ihm doch über die Leitwege den Weg zum richtigen Router nennen. Das geht statisch aber auch per DHCP (Option 121).

Von all den Optionen verbleiben also nur die erste Option, bei der ein Router das Paket für den Client Weiterleitet, auch wenn es nicht der effizienteste Weg ist oder die korrekte Konfiguration des Clients mit entsprechenden Leitwegen

So funktioniert ICMP-Redirect

Um die Funktion und damit auch die Auswirkungen und Nachteile eines ICMP-Redirect zu verstehen, betrachten wir eine Verbindung des PC3 zu einem PC4 in einem Netzwerk, welches nicht über das Default Gateway angebunden ist.

 

In dem Bild ist die Firewall1 natürlich auch ein TCP/IP-Router. 

  1. Der PC3 sendet eine Paket an den PC4 in einem anderen Subnetz
    Aufgrund der lokale Routingtabelle geht das Paket zur Firewall1.
  2. Die Firewall1 leitet Paket zu Router 2 weiter und sendet ein ICMP-Redirect
    Laut RFC muss der Router 1 das Paket weiterleiten, wenn keine Policies dagegen sprechen. Er kann aber den Absender informieren, dass es einen besseren Weg für zukünftige Pakete gibt. Ein Router muss dies aber icht tun und der PC3 muss ein eingehendes Paket nicht verarbeiten. Bei Windows verhindert schon die Firewall den Empfang.
  3. Der Router 2 routet das Paket zum Client 4
    Auch das ist das "normalste" von der Welt. Da kein NAT erfolgt, erhält der Client 4 das Paket von der IP-Adresse 10.49.1.3 des PC3.
  4. Der Client 4 sendet eine Antwort an PC3 über seine Leitwege.
    Der Client 4 erreicht den Router 2 in seinem Subnetz über die dort gültige MAC-Adresse des Router.
  5. Router 2 sendet das Paket direkt zu Client3
    Beide befinden sich ja im gleichen Subnetz und daher muss der Router 2 nicht über die Firewall1 gehen.

Sollte der Client den optimierten Weg zum Host "PC4 (10.49.2.4)" über den Router 2 anhand des empfangenen ICMP-Redirect gelernt haben, dann geht das nächste Paket zum PC4 direkt vom PC3 zu Router2.

Besser mit ICMP-Redirect?

Leider senden nicht alle Router einen ICMP-Redirect, sondern leiten teilweise die falsch zugestellten Pakete einfach an den richtigen "next Hop" weiter und zudem gibt es viele Clients, z.B. auch Windows 7 und höher, die ein eingehende "ICMP-Redirect"-Paket einfach ignorieren. Dabei löst der ICMP-Redirect einen großen Nachteil:

Überlastung des falschen Gateways durch mehr Routingarbeit und Mehrfachübertragungen auf dem Interface und etwas höherer Latenzzeit.

Wenn Sie sich das Interface bei Firewall1 anschauen, dann sehen sie, dass auf das eine eingehende Paket zwei ausgehende Pakete kommen, obwohl die Firewall1 eigentlich überhaupt nichts mit der Verbindung zu tun haben sollte. Stellen Sie sich vor, sie haben einen nagelneuen Router/Switch mit viel Gigabit und alle Pakete aus dem alten Netzwerk müssen weiter durch die alte Firewall mit einem 1 GBit-Link laufen? In der Vergangenheit war das ausreichend, da nur Paket zum Internet durch diesen Link mussten. Mit dem Umzug von mehr und mehr Servern in die neuen VLANs wird der neue Router gefordert aber bekommt die Pakete nur über den Umweg des alten Routers.

Weiterhin kommt noch der Faktor "Ausfallsicherheit" hinzu. Wenn Sie die Firewall1 z.B. durch ein Update einmal offline nehmen, dann betrifft dies akut auch die internen Verbindungen von PC3 und PC4 über Router 2. Zumindest wenn der PC3 nichts dazugelernt hat.

Dennoch ist "ICMP Redirect" keine Lösung sondern nur ein Notbehelf, denn bei einer korrekten Konfiguration ihres IP-Routings sollte es keinen Bedarf hierfür geben.

RFC 792 Internet Control Message Protocol

Schaue wir uns zuerst de "Redirect" einmal an, wie er in der RFC definiert ist:

The gateway sends a redirect message to a host in this situation:
- A gateway, G1, receives an Internet datagram from a host on a network to which the gateway is attached.
- The gateway, G1, checks its routing table and obtains the address of the next gateway, G2, on the route to the datagram Internet destination network, X
- If G2 and the host identified by the Internet source address of the datagram are on the same network, a redirect message is sent to the host. The redirect message advises the host to send its traffic for network X directly to gateway G2 as this is a shorter path to the destination.
- The gateway forwards the original datagram data to its Internet destination.
Quelle: RFC 792 Internet Control Message Protocol - https://datatracker.ietf.org/doc/html/rfc792

Das Beispiel beschreibt sehr gut, wie ein Client und zwei Gateways im gleichen Subnetz arbeiten können, wenn der Client das falsche Gateway anspricht. Das entbindet das angesprochene Gateway aber nicht davon, das Paket dennoch weiter zu leiten. G1 darf sich nicht auf den Redirect verlassen, dass der Client schon den neuen Weg wählt.

Redirect mit Wireshark

Um zuerst einmal das Verhalten eines ICMP-Redirect zu sehen, brauche ich mindestens einen Router der auch einen Redirect sendet. In meinem Heimnetzwerk habe ich so eine Konfiguration, denn hinter meiner Fritz!Box steht ein TP-Link-Switch (TP-Link T2600G-28TS (TL-SG3424)) , der zugleich ein IPv4-Router für weitere Subnetze ist. Die Fritz!Box kennt neben dem Internet ja nur das interne LAN und ein Gäste-Netzwerk aber sonst keine VLANs. Daher habe ich der Box mitgeteilt, dass Sie Pakete an die anderen Subnetze (IoT, Gäste, etc.) bitte an den Router im Switch senden soll: 

 

Umgekehrt hat der Switch natürlich die Fritz!Box als Default Gateway. Das Netzwerk ist dann wie folgt aufgebaut:

 

Dann habe ich von meinem Client (192.168.178.50) einen Ping auf ein IoT-Gerät (192.168.180.5) gesendet. Die Daten aus WireShark zeigen, dass die Fritz!Box sowohl einen ICMP-Redirect sendet als auch das Paket dennoch weiterleitet. Die Pakete sind

  • Zeile 1: Mein ICMP-Ping an die 192.168.180.5
    Beachten Sie die id?0x0005 und die Werte bei "Seq=31169/49529"
  • Zeile 2: Der ICMP Redirect der Fritz!Box
    Das im Detail abgebildete Paket kommt von der Fritz!Box (grüne Umrandung) und enthält ein IMCP Typ 5-Paket.
    Die Payload enthält die Information (blau), welche bei der Fritz!Box angekommene Paket betroffen ist.
    Aber weiter unten wird auch noch der Identifier und die Sequence Nummer (rot) mitgeliefert.
    Damit sollte der IP-Stack meines Clients die ausgehende Verbindung zuordnen können und die nächsten Pakete über den besseren Leitweg senden können. Allerdings sehe ich kein zweites ausgehendes PING. Der Client erwartet also, dass die Fritz!Box das Paket weitersendet,
  • Zeile 3: Hier sehe ich dann eine Rückmeldung des TP-Link-Routers (192.168.178.2) an meinen Client (192.168.178.50)
    Die Gegenstelle ist wohl nicht erreichbar. Der TP-Link wird einen ARP-Request auf die Zieladresse des Ping (192.168.180.5) gemacht haben und keine Antwort bekommen. Daher bekomme ich diese Rückmeldung ca. 3 Sekunden später

 

Das ICMP Redirect Paket liefert also sehr umfangreiche Informationen, wenn ein Client nicht den optimalen Weg nutzt.

ICMP-Redirect Verarbeitung

Natürlich wollte ich wissen, ob mein Client mit dem Wissen umgehen kann. Ich habe daher einen Dauer-Ping aufgesetzt und mit Wireshark auf die ICMP Messages gefiltert:

Der Trace offenbart, dass mein Windows Client weiterhin die PING-Pakete an die MAC-Adresse der Fritz!Box sendet, die diese Pakete auch brav weiterleitet, worauf der TP-Link auch antwortet. Aber ich sehe nach dem ersten ICMP-Redirect keinen Redirect-Informationen der Fritz!Box. Anscheinend sendet die Fritz!Box nur genau einen Redirect pro Sessions. Es reicht auch nicht den PING abzubrechen und neu zu starten. Nur wenn ich eine komplett andere Adresse "anpinge", dann kommt ein neuer Redirect für dieses neue Ziel.

Ich wollte natürlich auch wissen, wie lange die Fritz!Box den einmal gesendeten Redirect sich merkt. Ich habe den Dauerping einfach weiterlaufen lassen und auf erneute ICMP-Redirect gewartet. 

Die Abstände der ersten Redirects sind ca. 70Sek, 117Sek, 300Sek, 109Sek, 198Sek, 300Sek, 174Sek, 126Sek. Eine gewisse Abweichung ist sicher in der Wartezeit meines auf die ausbleibende PING-Antwort zu sehen, aber ein Muster kann ich nicht erkennen.

Das ist das Verhalten meiner Fritz!Box 7590 im Okt 2024. Letztlich implementiert jeder Router-Hersteller wohl selbst, und wenn wenn ja, wie oft er eine ICMP-Redirect-Message sendet. Es soll Router geben, die auf jedes falsch adressierte Paket eine ICMP-Redirect-Meldung senden und damit den Absender und das Netzwerk eigentlich über Gebühr belasten

Wenn Sie ähnliche Tests durchgeführt haben, dann würde mich ein Feedback zu den ICMP-Redirect-Verhalte ihrer Router freuen.

Lancom: ICMP-Redirects senden: Jedes empfangene Paket, für das eine lokale Route existiert, wird mit einem ICMP-Redirect beantwortet, wenn sich die Quelle des Pakets im lokalen Netz befindet.
Quelle: https://www2.lancom.de/kb.nsf/1275/D6F2F925C35F5DC5C1257CB5002CD8D7?OpenDocument und https://www.lancom-forum.de/fragen-zur-lancom-systems-routern-und-gateways-f41/icmp-redirects-t15803.html

Als Gegencheck habe ich noch einen Leitweg zu meinem TP-Link-Router gesetzt und mitgeschnitten. Der Router sendet gar keine Redirect, sondern leitet die Pakete einfach weiter. Das sehe ich im Wireshark gut über die MAC-Adresse. Die Zieladresse des PING ist eine TP-Link-Adresse aber die Antwort kommt dann von der Fritz!Box

 

Der Client hat hier gar keine Möglichkeit seine unpassende Konfiguration zu erkennen.

Windows und ICMP Redirect

Auf der anderen Seite muss ich natürlich feststellen, dass mein Client die ICMP Redirect-Meldungen einfach ignoriert. Also habe ich etwas recherchiert und es scheint so zu sein, dass Windows bis Version XP die ICMP Redirect-Meldungen angenommen UND verarbeitet hat aber seit Windows 7 dies nicht mehr der Fall ist. Als Ursache wird die Windows Firewall hingestellt, die diese Pakete einfach nicht mehr ankommen lässt. Also habe ich zuerst einfach mal die Firewall deaktiviert und geschaut, ob sich etwas verändert:

 

Tatsächlich hat sich nun Windows umgestellt.

  • Paket 1: Der PING an das Default Gateway (AVM) 
  • Paket 2: Der ICMP-Redirect eingehend
  • Paket 3: Auf das von AVM weitergeleitete Paket liefert der TP-Link ein ICMP-Unreachable
  • Paket 4: Mein Client sendet nun aber das nächste ICMP-Echo-Request direkt an den TP-Link
  • Paket5: Darauf antwortet der TP-Link natürlich wieder.

Also habe ich die Firewall wieder eingeschaltet und eine explizite eingehende Regel addiert:

 

Auch diese Regel hat dafür gesorgt, dass mein Windows 11 Client den ICMP Redirect empfangen und verarbeitet hat.

Bei der Suche im Internet habe ich mehrere Hinweise auf einen Schlüssel in der Registrierung gefunden, den ich aber nicht gesetzt habe. Ich weiß nicht, was er genau bewirkt.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 
EnableICMPRedirect: DWORD = 1

Nur zu Windows PE habe ich einen Eintrag gefunden, der ICMP Redirect steuern:

im Grunde kann der Windows TCP-Stack sehr wohl mit einem ICMP-Redirect umgehen. Ich frage mich nur, warum Microsoft in der Windows Firewall keine entsprechende Regel per Default aktiviert hat

Drei Dinge sind aber noch nicht geklärt 

  • Anzeige der Routen im Cache
    Auch wenn mein Windows 11 mittlerweile die ICMP-Redirect-Meldungen verarbeitet und sich danach richtet, habe ich bislang keinen Weg gefunden, dies auch abzufragen. Weder "route print" noch "Get-NetRoute" liefern diese gelernten Routen eines ICMP-Redirect
  • Dauer im Cache unbekannt
    Damit kann ich auch nicht ermitteln, wie lange die dynamisch gelernten Routen in der Routing-Tabelle bleiben. Irgendwann muss der Client dieses "Update" ja vergessen.
  • Windows Routing als ICMP-Redirect Sender
    Sie können den Windows TCP-Stack auch dazu verwenden, IP-Pakete zwischen Subnetzen zu routen. Das geht nicht nur mit der "Routing und RAS"-Rolle, sondern auch ein Windows Client kann einfache Routingaufgaben übernehmen. Ich habe nicht weiter geprüft, ob Windows auch selbst als ICMP-Redirect-Sender agieren kann, wenn er ein Paket bekommt, welches besser zu einem anderen Router im gleichen Subnetz gehen sollte. Ich habe aber einen Performance Counter gefunden, der solche gesendete Pakete zählen soll.

Ich stehe auf dem Standpunkt, dass sie eigentlich keinen ICMP-Redirect in einem Netzwerk brauchen, wenn ihre Router ihre Leitwege alle gut kennen und Sie den Clients das passende Default Gateway geben. Die wenigsten Clients dürften in einem Subnetz mit mehreren Routern sein, die für unterschiedliche Ziele zuständig sind.

Perfmon und SNMP

Wenn ein System bestimmte Pakete sendet und empfängt, dann gibt es sicher auch Zähler, die solche Vorkommen erfassen. Bei Windows gibt es z.B. einen Windows Performance Counter für ICMP-Redirect

 

Interessanterweise findet sich selbst auf einem Windows 11 Client auch ein Counter für versendet "ICMP-Redirect"-Pakete. Auf meinem Client waren aber beide Counter immer auf "0"

Beim -Net-Framework gibt es ebenfalls entsprechende Counter, die vermutlich aber auf die Performance Counter zurückgreifen.

Wenn sie dann auf Router schauen, finden Sie sehr schnell entsprechende SNMP-OIDs

1.3.6.1.2.1.5.7	  icmpInRedirects
1.3.6.1.2.1.5.20  icmpOutRedirect

ICMP Redirect Risiken

Im Abschnitt zu ICMP Redirect und Windows habe ich geschrieben, dass die Windows Firewall vermutlich ab Windows 7 den Empfang der ICMP-Redirect-Pakete unterbindet und der Windows TCP-Stack daher diese gar nicht erst bekommt. Da stellt sich die Frage, warum das der Default ist und welche Risiken damit verbunden sein könnten. ICMP enthält keine richtige Authentifizierung aber genug Informationen, damit ein Zielsystem erkennen kann, welche Verbindung gemeint ist. Folgende Überlegungen habe ich angestellt:

  • Spoofing
    Wenn es einem Angreifer im gleichen Subnetz gelänge, auf eine Verbindung einen ICMP-Redirect zu senden und der Client darauf reagieren würde, dann könnte ein Angreifer den Client anweisen, alle Pakete z.B. an den "Route des Angreifers" zu senden, der die Pakete dann mitliest ehe er sie weiterleitet. Das ist ähnlich wir ARP-Spoofing im gleichen Netzwerk. Für das Rückpaket müsste der Angreifer dann aber auch den echten Router überlisten, was aber nach meiner Einschätzung nicht geht, da Router und Client im gleichen Subnetz sind.
  • Störung
    Ebenso könnte ein Angreifer mit einem ICMP-Redirect eine Verbindung auf einen nicht erreichbaren Router, quasi ein "Black hole" senden, und so eine Verbindung des Client verhindern oder eine bestehende Verbindung stören. Sowohl beim Spoofing als auch beim Stören muss das ICMP-Redirect-Paket aber viele Informationen über das original gesendete Paket erhalten, was ein Angreifer eigentlich nicht hat.
  • DoS
    Als Angreifer könnte ich aber mit der IP-Adresse eines Ziels ein Paket an einen falschen Router senden, der dann ein ICMP-Redirect an den vorgeblichen Absender zurücksendet. Theoretisch kann ich so mit einem kleinem PING ein vielleicht etwas größeren ICMP-Redirect-Paket generieren, was das Opfer natürlich verwirft.

Das Schadpotential von ICMP-Redirect erscheint mir doch eher gering oder vernachlässigbar. Es muss eigentlich nur im gleichen Subnetz funktionieren, denn ein Redirect über mehrere Hops habe ich noch nicht gesehen und macht auch keinen Sinn. Der Angreifer muss im gleichen Subnetz sein und einen Router finden, der ICMP-Redirects in Mengen sendet. Meine Fritz!Box sendet nur wenige ICMP-Redirects, mein TP-Link per Default gar keine.

DHCP Option 121

Wenn Sie aber ein Client-Subnetz mit zwei oder mehr  Router haben, die auch noch für unterschiedliche Subnetze zuständig sind und sie ICMP-Redirect vermeiden wollen, dann sollten sie die Option 121 in ihrem DHCP-Server kennen. Sie können mittels DHCP-Server nicht nur das "Default Gateway" an den Client übermitteln, sondern zusätzlich auch weitere statische Routen.

 

Diese "Classless static routes" werden idealerweise auf dem Scope und nicht Serverweit konfiguriert, da Sie nur auf Router im gleichen Subnetz verweisen können.

Denken Sie aber daran, dass nicht allzu viele Administratoren und Netzwerke diese Option täglich nutzen und bei der Analyse eines Client mit "route print" nicht sofort an DHCP 121 denken. Zudem gibt es auch mögliche Angriffe, weil ein Angreifer auch einfach eine DHCP-Antwort mit der Option an Client senden und damit Routen umdrehen kann.

Die meisten Switche habe einen DHCP-Schutz, d.h. Sie können die Ports definieren, welche DHCP-Antworten ins Netzwerk einspeisen können und damit fremde Pakete aussperren.

IPv6 und Router Announcement (RA)

Bei IPv6 ist alles anders. Genau genommen benötigen sie bei IPv6 keinen DHCP-Server, weil der Client einfach auf das erste Paket wartet, um den Netzwerk-Teil der Adresse zu erhalten und den Host-Anteil kann sich der Anwender mit 32bit aus seiner MAC-Adresse oder per Zufall selbst bestimmen. Um dies zu unterstützen, senden alle Router eines IPv6-Netzwerks regelmäßig ein "Router Announcement (RA)". Zudem sendet ein IPv6-Client ein "ICMPv6 Type 133 Router Solicitation (RS)"-Nachricht, um einen Router zu finden. Hier eine Beispielmeldung meiner Fritz!Box:

 

Die Fritz!Box sendet die RA-Pakete immer mal wieder. Das Intervall muss auf jeden Fall kleiner als die "Router lifetime" (hier 1800 Sekunden = 30 Minuten) sein. Erlaubt wären 4-1800 Sekunden Aber wenn ein Client beim Beginn einer Verbindungen fragt, sollte jeder Router auch reagieren. Diese "ICMPv6 Type 133 Router Solicitation (RS)"-Nachricht habe ich hier nicht anzeigen lassen. Über das ICMPv6 Typ 134-Paket sendet der Router die Information, dass es ein Router ist und zwei Leitwege anbietet. Zudem nennt das Paket das Netzwerk-Prefix (2a00:6020:4e92:e200::/64), die verfügbaren DNS-Server und ihre eigene MAC-Adresse. Der Client muss diese Meldungen der eventuell vorhandenen Routern nur noch einsammeln und damit seine Routingtabelle aktualisieren. Ein ICMP-Redirect gibt es bei IPv6 aber immer noch (Typ 137).

Einschätzung

Ich vermute, dass die meisten Leser noch nie etwas von ICMP-Redirect gehört und auch selten mit komplexen Routing-Szenarien zu tun haben. Wenn Sie in einem Subnetz nur einen Router oder zwei redundante Router haben, die als Default Gateway agieren, dann kommt ein ICMP-Redirect eigentlich nicht vor. Dass ein Windows Client die Meldungen eh nicht verarbeitet und es offensichtlich keine Probleme damit gibt, ist ein weiteres Zeichen. Ein ICMP-Redirect ist eher ein Zeichen, dass ein System keine gültigen Routen durch eine passende Konfiguration bekommen hat. Bei Routern sind das RIP, OSPF, BGP und bei Clients die lokale Konfiguration per DHCP.

Es kann aber dennoch nicht falsch sein, z.B. bei den Router die entsprechenden Counter zu prüfen, die versendete oder empfangene "ICMP Redirect"-Pakete zählen.

Weitere Links