Zum Hauptinhalt springen

2. Differences from OSPF for IPv4 (Unterschiede zu OSPF für IPv4)

Die meisten Algorithmen von OSPF für IPv4 [OSPFV2] wurden in OSPF für IPv6 beibehalten. Allerdings waren einige Änderungen notwendig, entweder aufgrund von Änderungen in der Protokollsemantik zwischen IPv4 und IPv6 oder einfach zur Handhabung der vergrößerten Adressgröße von IPv6.

Die folgenden Unterabschnitte beschreiben die Unterschiede zwischen diesem Dokument und [OSPFV2].

IPv6 verwendet den Begriff „Link" zur Bezeichnung „einer Kommunikationseinrichtung oder eines Mediums, über das Knoten auf der Verbindungsschicht kommunizieren können" ([IPV6]). „Schnittstellen (Interfaces)" verbinden sich mit Links. Mehrere IPv6-Subnetze können einem einzelnen Link zugewiesen werden, und zwei Knoten können direkt über einen einzelnen Link kommunizieren, selbst wenn sie kein gemeinsames IPv6-Subnetz (IPv6-Präfix (IPv6 Prefix)) teilen.

Aus diesem Grund läuft OSPF für IPv6 pro Link statt des IPv4-Verhaltens pro IP-Subnetz. Die Begriffe „Netzwerk (Network)" und „Subnetz (Subnet)", die in der IPv4-OSPF-Spezifikation ([OSPFV2]) verwendet werden, sollten im Allgemeinen durch Link ersetzt werden. Ebenso verbindet sich eine OSPF-Schnittstelle jetzt mit einem Link statt mit einem IP-Subnetz.

Diese Änderung beeinflusst den Empfang von OSPF-Protokollpaketen, den Inhalt von Hello-Paketen und den Inhalt von Network-LSAs.

2.2. Removal of Addressing Semantics (Entfernung der Adressierungssemantik)​

In OSPF für IPv6 wurde die Adressierungssemantik aus den OSPF-Protokollpaketen und den Haupttypen von LSAs entfernt, wodurch ein netzwerkprotokollunabhängiger Kern übrig bleibt. Insbesondere:

  • IPv6-Adressen sind nicht in OSPF-Paketen vorhanden, außer in LSA-Nutzdaten, die von Link State Update Packets übertragen werden. Siehe Abschnitt 2.7 für Details.

  • Router-LSAs und Network-LSAs enthalten keine Netzwerkadressen mehr, sondern drücken lediglich Topologieinformationen aus. Siehe Abschnitt 2.8 für Details.

  • OSPF Router IDs, Area IDs und LSA Link State IDs bleiben bei der IPv4-Größe von 32 Bit. Sie können nicht mehr als (IPv6-)Adressen zugewiesen werden.

  • Benachbarte Router werden jetzt immer durch die Router ID identifiziert. Zuvor wurden sie durch eine IPv4-Adresse auf Broadcast-, NBMA- (Non-Broadcast Multi-Access) und Point-to-Multipoint-Links identifiziert.

2.3. Addition of Flooding Scope (Hinzufügung des Flooding-Bereichs)​

Der Flooding-Bereich (Flooding Scope) für LSAs wurde verallgemeinert und ist jetzt explizit im LS-Typ-Feld des LSA codiert. Es gibt jetzt drei separate Flooding-Bereiche für LSAs:

  • Link-Local-Bereich (Link-local Scope). Das LSA wird nur auf dem lokalen Link geflutet und nicht weiter. Wird für das neue Link-LSA verwendet. Siehe Abschnitt 4.4.3.8 für Details.

  • Area-Bereich (Area Scope). Das LSA wird nur in einer einzelnen OSPF-Area geflutet. Wird für Router-LSAs, Network-LSAs, Inter-Area-Prefix-LSAs, Inter-Area-Router-LSAs und Intra-Area-Prefix-LSAs verwendet.

  • AS-Bereich (AS Scope). Das LSA wird im gesamten Routing-Domain geflutet. Wird für AS-External-LSAs verwendet. Ein Router, der AS-Bereich-LSAs origiert, wird als AS Boundary Router (ASBR) betrachtet und setzt sein E-Bit in Router-LSAs für reguläre Areas.

OSPF unterstützt jetzt die Möglichkeit, mehrere OSPF-Protokollinstanzen auf einem einzelnen Link auszuführen. Dies kann beispielsweise auf einem NAP-Segment (Network Access Point) erforderlich sein, das von mehreren Anbietern gemeinsam genutzt wird. Anbieter unterstützen möglicherweise separate OSPF-Routing-Domains, die getrennt bleiben möchten, obwohl sie ein oder mehrere physische Netzwerksegmente (d.h. Links) gemeinsam haben. In OSPF für IPv4 wurde dies auf ungeordnete Weise unter Verwendung der Authentifizierungsfelder im OSPF-für-IPv4-Header unterstützt.

Eine weitere Verwendung für die Ausführung mehrerer OSPF-Instanzen besteht darin, wenn Sie aus irgendeinem Grund möchten, dass ein einzelner Link zu zwei oder mehr OSPF-Areas gehört.

Die Unterstützung mehrerer Protokollinstanzen auf einem Link wird über eine „Instance ID" erreicht, die im OSPF-Paketheader und in OSPF-Schnittstellendatenstrukturen enthalten ist. Die Instance ID beeinflusst ausschließlich den Empfang von OSPF-Paketen und gilt für normale OSPF-Schnittstellen und virtuelle Links (Virtual Links).

IPv6-Link-Local-Adressen (Link-Local Addresses) sind für die Verwendung auf einem einzelnen Link bestimmt, für Zwecke wie Neighbor Discovery, Auto-Configuration usw. IPv6-Router leiten keine IPv6-Datagramme mit Link-Local-Quelladressen weiter [IP6ADDR]. Link-Local-Unicast-Adressen werden aus dem IPv6-Adressbereich FE80/10 zugewiesen.

OSPF für IPv6 geht davon aus, dass jedem Router Link-Local-Unicast-Adressen auf jedem der angeschlossenen physischen Links des Routers zugewiesen wurden [IP6ADDR]. Auf allen OSPF-Schnittstellen außer virtuellen Links werden OSPF-Pakete unter Verwendung der zugehörigen Link-Local-Unicast-Adresse der Schnittstelle als Quelladresse gesendet. Ein Router lernt die Link-Local-Adressen aller anderen an seine Links angeschlossenen Router und verwendet diese Adressen als Next-Hop-Informationen während der Paketweiterleitun.

Auf virtuellen Links muss (MUST) eine IPv6-Adresse mit globalem Geltungsbereich (Global Scope) als Quelladresse für OSPF-Protokollpakete verwendet werden.

Link-Local-Adressen erscheinen in OSPF-Link-LSAs (siehe Abschnitt 4.4.3.8). Link-Local-Adressen sind jedoch in anderen OSPF-LSA-Typen nicht zulässig. Insbesondere dürfen (MUST NOT) Link-Local-Adressen nicht in Inter-Area-Prefix-LSAs (Abschnitt 4.4.3.4), AS-External-LSAs (Abschnitt 4.4.3.6), NSSA-LSAs (Abschnitt 4.4.3.7) oder Intra-Area-Prefix-LSAs (Abschnitt 4.4.3.9) angekündigt werden.

2.6. Authentication Changes (Authentifizierungsänderungen)​

In OSPF für IPv6 wurde die Authentifizierung aus dem OSPF-Protokoll entfernt. Die Felder „AuType" und „Authentication" wurden aus dem OSPF-Paketheader entfernt, und alle authentifizierungsbezogenen Felder wurden aus den OSPF-Area- und Schnittstellendatenstrukturen entfernt.

Bei der Ausführung über IPv6 verlässt sich OSPF auf den IP Authentication Header (siehe [IPAUTH]) und das IP Encapsulating Security Payload (siehe [IPESP]), wie in [OSPFV3-AUTH] beschrieben, um die Integrität und Authentifizierung/Vertraulichkeit von Routing-Austauschen zu gewährleisten.

Der Schutz von OSPF-Paketaustauschen gegen versehentliche Datenkorruption wird durch die Standard-IPv6-Upper-Layer-Prüfsumme (IPv6 Upper-Layer Checksum, wie in Abschnitt 8.1 von [IPV6] beschrieben) bereitgestellt, die das gesamte OSPF-Paket und den vorangestellten IPv6-Pseudo-Header (IPv6 Pseudo-Header, siehe Anhang A.3.1) abdeckt.

2.7. Packet Format Changes (Paketformatänderungen)​

OSPF für IPv6 läuft direkt über IPv6. Abgesehen davon wurde die gesamte Adressierungssemantik aus den OSPF-Paketheadern entfernt, wodurch es im Wesentlichen „netzwerkprotokollunabhängig (Network-Protocol-Independent)" wird. Alle Adressierungsinformationen sind jetzt nur noch in den verschiedenen LSA-Typen enthalten.

Im Detail bestehen die Änderungen im OSPF-Paketformat aus Folgendem:

  • Die OSPF-Versionsnummer wurde von 2 auf 3 erhöht.

  • Das Options-Feld in Hello-Paketen und Database Description Packets wurde auf 24 Bit erweitert.

  • Die Felder Authentication und AuType wurden aus dem OSPF-Paketheader entfernt (siehe Abschnitt 2.6).

  • Das Hello-Paket enthält jetzt überhaupt keine Adressinformationen mehr. Stattdessen enthält es jetzt eine Interface ID, die der originierende Router zugewiesen hat, um seine Schnittstelle zum Link eindeutig zu identifizieren (unter seinen eigenen Schnittstellen). Diese Interface ID wird als Link State ID des Network-LSA verwendet, wenn der Router der Designated Router auf dem Link wird.

  • Zwei Options-Bits, das „R-Bit" und das „V6-Bit", wurden dem Options-Feld hinzugefügt, um Router-LSAs während der SPF-Berechnung zu verarbeiten (siehe Anhang A.2). Wenn das „R-Bit" gelöscht ist, kann ein OSPF-Sprecher an der OSPF-Topologieverteilung teilnehmen, ohne für die Weiterleitung von Transit-Traffic verwendet zu werden; dies kann in Multi-Homed Hosts verwendet werden, die am Routing-Protokoll teilnehmen möchten. Das V6-Bit spezialisiert das R-Bit; wenn das V6-Bit gelöscht ist, kann ein OSPF-Sprecher an der OSPF-Topologieverteilung teilnehmen, ohne für die Weiterleitung von IPv6-Datagrammen verwendet zu werden. Wenn das R-Bit gesetzt und das V6-Bit gelöscht ist, werden IPv6-Datagramme nicht weitergeleitet, aber Datagramme einer anderen Protokollfamilie können weitergeleitet werden.

  • Der OSPF-Paketheader enthält jetzt eine „Instance ID", die es ermöglicht, mehrere OSPF-Protokollinstanzen auf einem einzelnen Link auszuführen (siehe Abschnitt 2.4).

2.8. LSA Format Changes (LSA-Formatänderungen)​

Die gesamte Adressierungssemantik wurde aus dem LSA-Header, den Router-LSAs und den Network-LSAs entfernt. Diese beiden LSAs beschreiben jetzt die Topologie der Routing-Domain auf netzwerkprotokollunabhängige Weise. Neue LSAs wurden hinzugefügt, um IPv6-Adressinformationen und Daten zu verteilen, die für die Next-Hop-Auflösung erforderlich sind. Die Namen einiger LSAs von IPv4 wurden geändert, um untereinander konsistenter zu sein.

Im Detail bestehen die Änderungen im LSA-Format aus Folgendem:

  • Das Options-Feld wurde aus dem LSA-Header entfernt, auf 24 Bit erweitert und in den Hauptteil von Router-LSAs, Network-LSAs, Inter-Area-Router-LSAs und Link-LSAs verschoben. Siehe Anhang A.2 für Details.

  • Das LSA-Type-Feld wurde (in den früheren Options-Raum) auf 16 Bit erweitert, wobei die oberen drei Bits den Flooding-Bereich und die Behandlung unbekannter LSA-Typen codieren (siehe Abschnitt 2.9).

  • Adressen in LSAs werden jetzt als [Präfix (Prefix), Präfixlänge (Prefix Length)] statt als [Adresse (Address), Maske (Mask)] ausgedrückt (siehe Anhang A.4.1). Die Standardroute wird als Präfix mit Länge 0 ausgedrückt.

  • Router-LSAs und Network-LSAs haben jetzt keine Adressinformationen und sind netzwerkprotokollunabhängig.

  • Router-Schnittstelleninformationen können (MAY) über mehrere Router-LSAs verteilt werden. Empfänger müssen (MUST) alle von einem bestimmten Router originierten Router-LSAs verketten, wenn sie die SPF-Berechnung ausführen.

  • Ein neues LSA namens Link-LSA wurde eingeführt. Link-LSAs haben Link-Local-Flooding-Bereich; sie werden niemals über den Link hinaus geflutet, mit dem sie verbunden sind. Link-LSAs haben drei Zwecke: 1) Sie stellen die Link-Local-Adresse des Routers allen anderen an den Link angeschlossenen Routern zur Verfügung, 2) sie informieren andere an den Link angeschlossene Router über eine Liste von IPv6-Präfixen, die mit dem Link verbunden werden sollen, und 3) sie ermöglichen es dem Router, eine Sammlung von Options-Bits anzukündigen, die mit dem Network-LSA verbunden werden sollen, das für den Link originiert wird. Siehe Abschnitt 4.4.3.8 für Details.

  • In IPv4 trägt das Router-LSA die IPv4-Schnittstellenadressen eines Routers, das IPv4-Äquivalent von Link-Local-Adressen. Diese werden nur bei der Berechnung von Next-Hops während der OSPF-Routing-Berechnung verwendet (siehe Abschnitt 16.1.1 von [OSPFV2]), daher müssen sie nicht über den lokalen Link hinaus geflutet werden. Daher ist die Verwendung von Link-LSAs zur Verteilung dieser Adressen effizienter. Beachten Sie, dass Link-Local-Adressen nicht in allen Fällen durch den Empfang von Hellos gelernt werden können. Auf NBMA-Links tauschen Next-Hop-Router nicht unbedingt Hellos aus. Vielmehr erfahren diese Router von der Existenz des jeweils anderen über den Designated Router (DR).

  • Das Options-Feld im Network-LSA wird auf das logische ODER (Logical OR) der Options gesetzt, die jeder Router auf dem Link in seinem Link-LSA ankündigt.

  • Typ-3-Summary-LSAs wurden in „Inter-Area-Prefix-LSAs" umbenannt. Typ-4-Summary-LSAs wurden in „Inter-Area-Router-LSAs" umbenannt.

  • Die Link State ID in Inter-Area-Prefix-LSAs, Inter-Area-Router-LSAs, NSSA-LSAs und AS-External-LSAs hat ihre Adressierungssemantik verloren und dient nun ausschließlich der Identifizierung einzelner Teile der Link-State-Datenbank. Alle Adressen oder Router-IDs, die früher durch die Link State ID ausgedrückt wurden, werden jetzt in den LSA-Hauptteilen transportiert.

  • Network-LSAs und Link-LSAs sind die einzigen LSAs, deren Link State ID eine zusätzliche Bedeutung trägt. Für diese LSAs ist die Link State ID immer die Interface ID des originierenden Routers auf dem beschriebenen Link. Aus diesem Grund sind Network-LSAs und Link-LSAs jetzt die einzigen LSAs, deren Größe nicht begrenzt werden kann: ein Network-LSA muss (MUST) alle mit dem Link verbundenen Router auflisten, und ein Link-LSA muss (MUST) alle Adressen eines Routers auf dem Link auflisten.

  • Ein neues LSA namens Intra-Area-Prefix-LSA wurde eingeführt. Dieses LSA trägt alle IPv6-Präfixinformationen, die in IPv4 in Router-LSAs und Network-LSAs enthalten sind. Siehe Abschnitt 4.4.3.9 für Details.

  • Die Aufnahme einer Forwarding Address oder eines External Route Tag in AS-External-LSAs ist jetzt optional. Darüber hinaus können AS-External-LSAs jetzt auf ein anderes LSA verweisen, um zusätzliche Routenattribute einzuschließen, die außerhalb des Geltungsbereichs des OSPF-Protokolls liegen. Beispielsweise könnte dieser Verweis verwendet werden, um BGP-Pfadattribute an externe Routen anzuhängen.

2.9. Handling Unknown LSA Types (Behandlung unbekannter LSA-Typen)​

Die Behandlung unbekannter LSA-Typen wurde flexibler gestaltet, sodass basierend auf dem LS-Typ unbekannte LSA-Typen entweder als mit Link-Local-Flooding-Bereich behandelt werden oder gespeichert und geflutet werden, als ob sie verstanden würden. Dieses Verhalten ist explizit im LSA Handling Bit des LS-Typ-Felds des Link-State-Headers codiert (siehe das U-Bit in Anhang A.4.2.1).

Das IPv4-OSPF-Verhalten, unbekannte Typen einfach zu verwerfen, wird aufgrund des Wunsches, Router-Fähigkeiten auf einem einzelnen Link zu mischen, nicht unterstützt. Das Verwerfen unbekannter Typen verursacht Probleme, wenn der Designated Router weniger Optionen unterstützt als die anderen Router auf dem Link.

2.10. Stub/NSSA Area Support (Stub/NSSA-Area-Unterstützung)​

In OSPF für IPv4 wurden Stub- und NSSA-Areas entwickelt, um die Link-State-Datenbank- und Routing-Tabellengrößen für die internen Router der Areas zu minimieren. Dies ermöglicht es Routern mit minimalen Ressourcen, auch an sehr großen OSPF-Routing-Domains teilzunehmen.

In OSPF für IPv6 wird das Konzept von Stub- und NSSA-Areas beibehalten. In IPv6 tragen Stub-Areas von den obligatorischen LSA-Typen nur Router-LSAs, Network-LSAs, Inter-Area-Prefix-LSAs, Link-LSAs und Intra-Area-Prefix-LSAs. NSSA-Areas sind auf diese Typen und natürlich NSSA-LSAs beschränkt. Dies ist das IPv6-Äquivalent der LSA-Typen, die in IPv4-Stub-Areas getragen werden: Router-LSAs, Network-LSAs, Typ-3-Summary-LSAs und für NSSA-Areas: Stub-Area-Typen und NSSA-LSAs.

2.11. Identifying Neighbors by Router ID (Identifizierung von Nachbarn durch Router-ID)​

In OSPF für IPv6 werden benachbarte Router auf einem bestimmten Link immer durch ihre OSPF-Router-ID identifiziert. Dies steht im Gegensatz zum IPv4-Verhalten, bei dem Nachbarn auf Point-to-Point-Netzwerken und virtuellen Links durch ihre Router-IDs identifiziert werden, während Nachbarn auf Broadcast-, NBMA- und Point-to-Multipoint-Links durch ihre IPv4-Schnittstellenadressen identifiziert werden.

Diese Änderung beeinflusst den Empfang von OSPF-Paketen (siehe Abschnitt 8.2 von [OSPFV2]), die Suche nach Nachbarn (Abschnitt 10 von [OSPFV2]) und den Empfang von Hello-Paketen (Abschnitt 10.5 von [OSPFV2]).

Die Router-ID 0.0.0.0 ist reserviert und sollte nicht (SHOULD NOT) verwendet werden.

Letztes Update am