Zum Hauptinhalt springen

8. Redirect-Funktion (Redirect Function)

Die Redirect-Nachricht wird von Routern verwendet, um Hosts über einen besseren First-Hop zu einem Ziel zu informieren. Router senden Redirect-Nachrichten nur für Pakete, die vom Router weitergeleitet werden. Hosts MÜSSEN (MUST) alle empfangenen Redirect-Nachrichten stillschweigend verwerfen, die nicht alle in Abschnitt 8.1 spezifizierten Gültigkeitsprüfungen erfüllen.

8.1. Validierung von Redirect-Nachrichten (Validation of Redirect Messages)​

Ein Host MUSS (MUST) alle empfangenen Redirect-Nachrichten stillschweigend verwerfen, die nicht alle folgenden Gültigkeitsprüfungen erfüllen:

  • Die IP-Quelladresse des Redirects ist dieselbe wie der aktuelle First-Hop-Router für die angegebene ICMP-Zieladresse.

  • Das IP Hop Limit-Feld hat einen Wert von 255, d. h., das Paket konnte unmöglich von einem Router weitergeleitet worden sein.

  • Die ICMP-Prüfsumme ist gültig.

  • Der ICMP-Code ist 0.

  • Die ICMP-Länge (abgeleitet von der IP-Länge) beträgt 40 oder mehr Oktette.

  • Die IP-Quelladresse des Redirects ist eine Link-Local-Adresse. Router müssen ihre Link-Local-Adresse als Quelle für Redirect-Nachrichten verwenden, damit Hosts Router eindeutig identifizieren können.

  • Das ICMP Destination Address-Feld in der Redirect-Nachricht enthält keine Multicast-Adresse.

  • Die ICMP Target Address ist entweder eine Link-Local-Adresse (bei Umleitung zu einem Router) oder identisch mit der ICMP Destination Address (bei Umleitung zum On-Link-Ziel).

  • Alle enthaltenen Optionen haben eine Länge, die größer als Null ist.

Der Inhalt des Reserved-Feldes und aller nicht erkannten Optionen MUSS (MUST) ignoriert werden. Zukünftige, rückwärtskompatible Änderungen am Protokoll können den Inhalt des Reserved-Feldes spezifizieren oder neue Optionen hinzufügen; rückwärtsinkompatible Änderungen können unterschiedliche Code-Werte verwenden.

Der Inhalt aller definierten Optionen, die nicht für die Verwendung mit Redirect-Nachrichten spezifiziert sind, MUSS (MUST) ignoriert werden und das Paket normal verarbeitet werden. Die einzigen definierten Optionen, die erscheinen können, sind die Optionen Target Link-Layer Address und Redirected Header.

8.2. Router-Spezifikation (Router Specification)​

Ein Router SOLLTE (SHOULD) eine Redirect-Nachricht unter Ratenbegrenzung senden, wann immer er ein Paket weiterleitet, das nicht explizit an ihn selbst adressiert ist, bei dem:

  • das Source Address-Feld des Pakets einen Nachbarn identifiziert, und

  • der Router bestimmt, dass ein besserer First-Hop-Knoten auf demselben Link wie der sendende Knoten für die Destination Address des Pakets vorhanden ist, und

  • die Destination Address des Pakets keine Multicast-Adresse ist.

Die übertragene Redirect-Nachricht enthält:

  • Im Target Address-Feld: die Adresse, an die nachfolgende Pakete für das Ziel gesendet werden sollen. Wenn das Ziel ein Router ist, MUSS (MUST) die Link-Local-Adresse dieses Routers verwendet werden. Wenn das Ziel ein Host ist, MUSS (MUST) das Target Address-Feld auf denselben Wert wie die Destination Address des aufrufenden IP-Pakets gesetzt werden.

  • Im Destination Address-Feld: die Zieladresse des aufrufenden IP-Pakets.

  • In den Optionen:

    • Target Link-Layer Address-Option: die Link-Layer-Adresse des Ziels. Sie SOLLTE (SHOULD) enthalten sein (falls bekannt). Beachten Sie, dass auf NBMA-Links Hosts möglicherweise keine Link-Layer-Adressen haben, in welchem Fall die Option nicht enthalten sein kann.

    • Redirected Header: so viel vom weitergeleiteten Paket wie möglich, ohne dass das Redirect-Paket die minimale MTU überschreitet, die zur Unterstützung von IPv6 erforderlich ist, wie in [IPv6] spezifiziert.

Ein Router MUSS (MUST) die Rate begrenzen, mit der Redirect-Nachrichten gesendet werden, um die Bandbreite und Verarbeitungskosten zu begrenzen, die durch die Redirect-Nachrichten entstehen, wenn die Quelle nicht korrekt auf die Redirects reagiert. Weitere Details zur Ratenbegrenzung von ICMP-Fehlermeldungen finden Sie in [ICMPv6].

8.3. Host-Spezifikation (Host Specification)​

Ein Host, der einen Redirect empfängt, untersucht das Paket und führt die folgenden Gültigkeitsprüfungen durch. Wenn eine dieser Prüfungen fehlschlägt, MUSS (MUST) der Host die Redirect-Nachricht stillschweigend verwerfen.

Nachdem der Host überprüft hat, dass die Redirect-Nachricht gültig ist, verarbeitet er die Nachricht wie folgt:

  • Wenn die Target Address nicht identisch mit der Destination Address ist, ersetzt der Host den aktuellen Eintrag für die Destination Address in seinem Destination Cache durch einen Eintrag, der auf die Target Address zeigt. Der Eintrag sollte den Zustand des alten Eintrags in Bezug auf Path MTU-Informationen und Neighbor Unreachability Detection-Zustand erben. Wenn der Host einen neuen Destination Cache-Eintrag erstellt, wird der Eintrag wie in Abschnitt 5.2 beschrieben initialisiert.

  • Wenn die Target Address identisch mit der Destination Address ist, führt der empfangende Host die folgenden Operationen an seinem Prefix List-Eintrag für das Ziel durch:

    • Wenn kein Eintrag existiert, fügt der Host das Ziel seiner Prefix List als On-Link-Ziel hinzu.
    • Wenn bereits ein Eintrag für das Ziel in der Prefix List existiert, aktualisiert der Host den Eintrag, um anzuzeigen, dass das Ziel on-link ist.

In beiden Fällen aktualisiert der Host den Destination Cache-Eintrag für das Ziel, um auf die Target Address zu zeigen. Wenn der Destination Cache-Eintrag nicht existiert, erstellt der Host einen neuen Eintrag. Der Eintrag SOLLTE (SHOULD) aktualisiert werden, auch wenn der Host bereits einen zwischengespeicherten Eintrag hat, der einen anderen First-Hop-Nachbarn spezifiziert, da Router in einer besseren Position sind, den geeigneten First-Hop-Nachbarn zu bestimmen.

Wenn der Redirect eine Target Link-Layer Address-Option enthält, erstellt oder aktualisiert der Host den Neighbor Cache-Eintrag für das Ziel. In beiden Fällen wird die Link-Layer-Adresse in der Option verwendet. Der Neighbor Cache-Eintrag für das Ziel wird auf den STALE-Zustand gesetzt. Wenn ein Neighbor Cache-Eintrag für das Ziel erstellt wird, MUSS (MUST) sein Erreichbarkeitszustand auf STALE gesetzt werden, wie in Abschnitt 7.3.3 spezifiziert. Wenn bereits ein Cache-Eintrag existierte und mit einer anderen Link-Layer-Adresse aktualisiert wird, MUSS (MUST) sein Erreichbarkeitszustand ebenfalls auf STALE gesetzt werden.

Der Host MUSS (MUST) die Target Address zum Destination Cache hinzufügen. Die Next-Hop-Adresse des Eintrags wird auf die Target Address des Redirects gesetzt. Wenn bereits ein Destination Cache-Eintrag für das Ziel existierte, wird er aktualisiert, um die Target Address als Next-Hop zu verwenden. Beachten Sie, dass der Host nicht überprüft, ob das Ziel erreichbar ist; die Gültigkeit der Redirect-Nachricht liegt in der Verantwortung des Routers.

Eine Redirect-Nachricht SOLLTE (SHOULD) von einem Router als Antwort auf ein vom Router weitergeleitetes Paket gesendet werden, bei dem das Source Address-Feld einen Nachbarn identifiziert und der Router einen besseren First-Hop-Knoten für das Ziel bestimmt. Die Rate, mit der ein Router Redirects senden kann, muss begrenzt werden, um Broadcast-Stürme oder Denial-of-Service-Angriffe auf Hosts zu verhindern.

8.4. Beispiel (Example)​

Betrachten Sie den Fall, in dem ein Host ein Paket über einen Standard-Router R1 an ein Ziel sendet, aber ein anderer Router R2 auf demselben Link ein besserer First-Hop zum Ziel wäre. Beim Weiterleiten des Pakets sendet R1 einen Redirect an den Host und informiert ihn, dass R2 eine bessere Wahl ist. Der Redirect enthält die Link-Local-Adresse von R2.

      +------+
      | Host |
      +------+
         |
         | (1) Paket zu Dest
         |
         v
      +----+              +----+
      | R1 |  --------->  | R2 |
      +----+   Redirect   +----+
         |                  |
         |                  |
         +------------------+
                Link
  1. Host sendet Paket an Ziel über R1 (seinen Standard-Router)
  2. R1 leitet Paket weiter und sendet Redirect an Host, der anzeigt, dass R2 besser ist
  3. Host aktualisiert seinen Destination Cache, um R2 für dieses Ziel zu verwenden
  4. Nachfolgende Pakete zum Ziel werden direkt an R2 gesendet

8.5. Redirect-Loop-Prävention (Redirect Loop Prevention)​

Der Redirect-Mechanismus ist anfällig für Redirect-Loops, wenn mehrere Router auf einem Link sich über den besten First-Hop für ein Ziel nicht einig sind. Solche Loops sind jedoch typischerweise kurzlebig aus folgenden Gründen:

  • Router senden nur Redirects für Pakete, die sie weiterleiten. Wenn ein Router ein Paket empfängt, für das er der beste First-Hop ist, sendet er keinen Redirect.

  • Hosts, die mehrere Redirects erhalten, die auf verschiedene Router für dasselbe Ziel zeigen, verwenden den zuletzt empfangenen Redirect. Im Laufe der Zeit sollte das System zu einem stabilen Zustand konvergieren.

  • Der Neighbor Unreachability Detection-Algorithmus wird schließlich erkennen, wenn ein Router nicht erreichbar ist, was dazu führt, dass der Host auf einen anderen Router zurückfällt.

Trotz dieser Abhilfemaßnahmen sollten Implementierungen sich der Möglichkeit von Redirect-Loops bewusst sein und können zusätzliche Schutzmaßnahmen implementieren, wie z. B. die Begrenzung der Rate, mit der Destination Cache-Einträge als Antwort auf Redirects aktualisiert werden.

Letztes Update am