Zum Hauptinhalt springen

4.2. Protocol Packet Processing (Protokollpaketverarbeitung)

OSPF für IPv6 läuft direkt über der IPv6-Netzwerkschicht. Als solches ist es in einem oder mehreren IPv6-Headern gekapselt, wobei das Next-Header-Feld des unmittelbar kapselnden IPv6-Headers auf den Wert 89 gesetzt ist.

Wie bei OSPF für IPv4 werden OSPF-Routingprotokollpakete für IPv6 nur entlang von Adjacencies gesendet (mit Ausnahme von Hello-Paketen, die zur Erkennung der Adjacencies verwendet werden). OSPF-Pakettypen und -funktionen sind in IPv4 und IPv6 gleich, codiert durch das Type-Feld des Standard-OSPF-Paketheaders.

4.2.1. Sending Protocol Packets (Senden von Protokollpaketen)​

Wenn ein IPv6-Router ein OSPF-Routingprotokollpaket sendet, füllt er die Felder des Standard-OSPF-Paketheaders für IPv6 (siehe Anhang A.3.1) wie folgt aus:

Version #

Auf 3 gesetzt, die Versionsnummer des Protokolls, wie in dieser Spezifikation dokumentiert.

Type

Der Typ des OSPF-Pakets, wie z. B. Link State Update oder Hello-Paket.

Packet length (Paketlänge)

Die Länge des gesamten OSPF-Pakets in Bytes, einschließlich des Standard-OSPF-Paketheaders.

Router ID

Die Identität des Routers selbst (wer das Paket originiert).

Area ID

Der OSPF-Bereich für die Schnittstelle, auf der das Paket gesendet wird.

Instance ID

Die OSPF-Instanz-ID, die mit der Schnittstelle verbunden ist, über die das Paket gesendet wird.

Checksum (Prüfsumme)

Die Standard-IPv6-Upper-Layer-Prüfsumme (wie in Abschnitt 8.1 von [IPV6] beschrieben), die das gesamte OSPF-Paket und den vorangestellten IPv6-Pseudo-Header abdeckt (siehe Anhang A.3.1).

Die Auswahl der IPv6-Quell- und Zieladressen von OSPF-Routingprotokollpaketen wird identisch zur IPv4-Logik in Abschnitt 8.1 von [OSPFV2] durchgeführt. Die IPv6-Zieladresse wird aus den Adressen AllSPFRouters, AllDRouters und der Neighbor-IP-Adresse ausgewählt, die mit dem anderen Ende der Adjacency verbunden ist (was in IPv6 für alle Links außer virtuellen Links eine IPv6-Link-Local-Adresse ist).

Das Senden von Link State Request-Paketen und Link State Acknowledgment-Paketen bleibt gegenüber den IPv4-Verfahren, die in den Abschnitten 10.9 bzw. 13.5 von [OSPFV2] dokumentiert sind, unverändert. Das Senden von Hello-Paketen ist in Abschnitt 4.2.1.1 dokumentiert, und das Senden von Database Description-Paketen in Abschnitt 4.2.1.2. Das Senden von Link State Update-Paketen ist in Abschnitt 4.5.2 dokumentiert.

4.2.1.1. Sending Hello Packets (Senden von Hello-Paketen)​

IPv6 ändert die Art und Weise, wie OSPF-Hello-Pakete gesendet werden, auf folgende Weise (vergleiche mit Abschnitt 9.5 von [OSPFV2]):

  • Bevor das Hello-Paket auf einer Schnittstelle gesendet wird, muss die Interface-ID der Schnittstelle in das Hello-Paket kopiert werden.

  • Das Hello-Paket enthält keine IP-Netzmaske mehr, da OSPF für IPv6 pro Link statt pro Subnetz läuft.

  • Die Wahl des Designated Routers und des Backup Designated Routers wird jetzt in Hellos durch ihre Router-IDs statt durch ihre IP-Schnittstellenadressen angezeigt. Das Ankündigen des Designated Routers (oder Backup Designated Routers) als 0.0.0.0 zeigt an, dass der Designated Router (oder Backup Designated Router) noch nicht gewählt wurde.

  • Das Options-Feld in Hello-Paketen hat sich bewegt und ist dabei größer geworden. Mehr Options-Bits sind jetzt möglich. Diejenigen, die in Hello-Paketen korrekt gesetzt werden müssen, sind wie folgt. Das E-Bit wird genau dann gesetzt, wenn die Schnittstelle an einen regulären Bereich angeschlossen ist, d. h. nicht an einen Stub- oder NSSA-Bereich. Ebenso wird das N-Bit genau dann gesetzt, wenn die Schnittstelle an einen NSSA-Bereich angeschlossen ist (siehe [NSSA]). Schließlich wird das DC-Bit genau dann gesetzt, wenn der Router das Senden zukünftiger Hellos über die Schnittstelle unterdrücken möchte (siehe [DEMAND]). Nicht erkannte Bits im Options-Feld des Hello-Pakets sollten gelöscht werden.

Das Senden von Hello-Paketen auf NBMA-Netzwerken läuft für IPv6 genauso ab wie für IPv4, wie in Abschnitt 9.5.1 von [OSPFV2] dokumentiert.

4.2.1.2. Sending Database Description Packets (Senden von Database Description-Paketen)​

Das Senden von Database Description-Paketen unterscheidet sich von Abschnitt 10.8 von [OSPFV2] auf folgende Weise:

  • Das Options-Feld in Database Description-Paketen hat sich bewegt und ist dabei größer geworden. Mehr Options-Bits sind jetzt möglich. Diejenigen, die in Database Description-Paketen korrekt gesetzt werden müssen, sind wie folgt. Das DC-Bit wird genau dann gesetzt, wenn der Router das Senden von Hellos über die Schnittstelle unterdrücken möchte (siehe [DEMAND]). Nicht erkannte Bits im Options-Feld des Database Description-Pakets sollten gelöscht werden.

4.2.2. Receiving Protocol Packets (Empfangen von Protokollpaketen)​

Immer wenn ein Router ein OSPF-Protokollpaket empfängt, wird es mit der Schnittstelle markiert, auf der es empfangen wurde. Für Router, die virtuelle Links konfiguriert haben, ist möglicherweise nicht sofort offensichtlich, mit welcher Schnittstelle das Paket verknüpft werden soll. Betrachten Sie beispielsweise den Router RT11, der in Abbildung 6 von [OSPFV2] dargestellt ist. Wenn RT11 ein OSPF-Protokollpaket auf seiner Schnittstelle zum Netzwerk N8 empfängt, möchte er das Paket möglicherweise mit der Schnittstelle zu Area 2 oder mit dem virtuellen Link zu Router RT10 (der Teil des Backbones ist) verknüpfen. Im Folgenden nehmen wir an, dass das Paket zunächst mit dem nicht-virtuellen Link verknüpft ist.

Damit das Paket zur Verarbeitung an OSPF weitergeleitet werden kann, müssen die folgenden Tests an den kapselnden IPv6-Headern durchgeführt werden:

  • Die IP-Zieladresse des Pakets muss eine der IPv6-Unicast-Adressen sein, die mit der empfangenden Schnittstelle verbunden sind (dies umfasst Link-Local-Adressen), eine der IPv6-Multicast-Adressen AllSPFRouters oder AllDRouters oder eine IPv6-Global-Adresse (für virtuelle Links).

  • Das Next-Header-Feld des unmittelbar kapselnden IPv6-Headers muss das OSPF-Protokoll (89) angeben.

  • Alle kapselnden IP-Authentifizierungsheader (siehe [IPAUTH]) und IP-Einkapselungs-Sicherheitsnutzlasten (siehe [IPESP]) müssen verarbeitet und/oder verifiziert werden, um die Integrität und Authentifizierung/Vertraulichkeit von OSPF-Routing-Austauschen zu gewährleisten. Dies wird in [OSPFV3-AUTH] beschrieben.

Nach der Verarbeitung der kapselnden IPv6-Header wird der OSPF-Paketheader verarbeitet. Die im Header angegebenen Felder müssen mit denen übereinstimmen, die für die empfangende OSPFv3-Schnittstelle konfiguriert sind. Wenn sie nicht übereinstimmen, sollte das Paket verworfen werden:

  • Das Versionsnummernfeld muss Protokollversion 3 angeben.

  • Die IPv6-Upper-Layer-Prüfsumme (wie in Abschnitt 8.1 von [IPV6] beschrieben), die das gesamte OSPF-Paket und den vorangestellten IPv6-Pseudo-Header abdeckt, muss verifiziert werden (siehe Anhang A.3.1).

  • Die Area-ID und Instanz-ID, die im OSPF-Header gefunden werden, müssen verifiziert werden. Wenn beide der folgenden Fälle fehlschlagen, sollte das Paket verworfen werden. Die im Header angegebene Area-ID und Instanz-ID müssen entweder:

    1. Mit einer der Area-ID(s) und Interface-Instanz-ID(s) für den empfangenden Link übereinstimmen. Anders als bei IPv4 ist die IPv6-Quelladresse nicht darauf beschränkt, im selben IPv6-Subnetz wie der empfangende Link zu liegen. IPv6-OSPF läuft pro Link statt pro IP-Subnetz.

    2. Mit dem Backbone-Bereich und anderen Kriterien für einen konfigurierten virtuellen Link übereinstimmen. Der empfangende Router muss ein ABR (Area Border Router) sein, und die im Paket angegebene Router-ID (der Quell-Router) muss das andere Ende eines konfigurierten virtuellen Links sein. Zusätzlich muss der empfangende Link eine OSPFv3-Schnittstelle haben, die an den konfigurierten Transit-Bereich des virtuellen Links angeschlossen ist, und die Instanz-ID muss mit der Instanz-ID des virtuellen Links übereinstimmen. Wenn alle diese Prüfungen erfolgreich sind, wird das Paket akzeptiert und mit dem virtuellen Link (und dem Backbone-Bereich) verknüpft.

  • Lokal originierte Pakete sollten nicht von OSPF verarbeitet werden, außer zur Unterstützung mehrerer Schnittstellen, die an denselben Link angeschlossen sind, wie in Abschnitt 4.9 beschrieben. Lokal originierte Pakete haben eine Quelladresse, die einer der lokalen Adressen des Routers entspricht.

  • Pakete, deren IPv6-Ziel AllDRouters ist, sollten nur akzeptiert werden, wenn der Zustand der empfangenden OSPFv3-Schnittstelle DR oder Backup ist (siehe Abschnitt 9.1 [OSPFV2]).

Nach der Header-Verarbeitung wird das Paket gemäß seinem OSPF-Pakettyp weiterverarbeitet. OSPF-Pakettypen und -funktionen sind für IPv4 und IPv6 gleich.

Wenn der Pakettyp Hello ist, sollte er dann durch die Hello-Paketverarbeitung, wie in Abschnitt 4.2.2.1 beschrieben, weiterverarbeitet werden. Alle anderen Pakettypen werden nur auf Adjacencies gesendet/empfangen. Dies bedeutet, dass das Paket von einem der aktiven Nachbarn des Routers gesendet worden sein muss. Der Nachbar wird durch die Router-ID identifiziert, die im OSPF-Header des empfangenen Pakets erscheint. Pakete, die zu keinem aktiven Nachbarn passen, werden verworfen.

Die Empfangsverarbeitung von Database Description-Paketen, Link State Request-Paketen und Link State Acknowledgment-Paketen ist fast identisch mit den IPv4-Verfahren, die in den Abschnitten 10.6, 10.7 bzw. 13.7 von [OSPFV2] dokumentiert sind, mit den unten aufgeführten Ausnahmen.

  • LSAs mit unbekannten LS-Typen in Database Description-Paketen, die einen akzeptablen Flooding-Bereich haben, werden genauso verarbeitet wie LSAs mit bekannten LS-Typen. In OSPFv2 [OSPFV2] würden diese dazu führen, dass die Adjacency mit einem SequenceMismatch-Ereignis heruntergefahren wird.

Der Empfang von Hello-Paketen ist in Abschnitt 4.2.2.1 dokumentiert, und der Empfang von Link State Update-Paketen ist in Abschnitt 4.5.1 dokumentiert.

4.2.2.1. Receiving Hello Packets (Empfangen von Hello-Paketen)​

Die Empfangsverarbeitung von Hello-Paketen unterscheidet sich von Abschnitt 10.5 von [OSPFV2] auf folgende Weise:

  • Auf allen Link-Typen (z. B. Broadcast, NBMA, Point-to-Point usw.) werden Nachbarn ausschließlich anhand ihrer OSPF-Router-ID identifiziert. Für alle Link-Typen außer virtuellen Links wird die Neighbor-IP-Adresse auf die IPv6-Quelladresse im IPv6-Header des empfangenen OSPF-Hello-Pakets gesetzt.

  • Es gibt kein Network Mask-Feld mehr im Hello-Paket.

  • Die Wahl des Nachbarn für Designated Router und Backup Designated Router wird jetzt als OSPF-Router-ID statt als IP-Schnittstellenadresse codiert.

Letztes Update am