Zum Hauptinhalt springen

3. Betrachtungen zu IPv6 (IPv6 Considerations)

Um Verwirrung zu vermeiden, basierten die bisherigen Erörterungen ausschließlich auf IPv4. Das entsprechende Protokoll für IPv6 ist die Multicast Listener Discovery [MLD]. Da MLD auf IGMP basiert, werden die vollständige Beschreibung und die Empfehlungen hier nicht wiederholt; stattdessen werden nur die Fälle benannt, in denen MLD von IGMP abweicht.

Die für IGMP in Abschnitt 2 beschriebenen Steuerungs- und Datenweiterleitungsregeln können mit wenigen Überlegungen auf MLD angewendet werden; das heißt, die Grundfunktionalität des Abfangens von MLD-Nachrichten und des Aufbaus von Mitgliedschafts- und Multicast-Router-Listen ist dieselbe wie bei IGMP.

Die IPv6-Datenweiterleitung ist in einer Hinsicht einfacher als bei IPv4: MLD ist für Adressen im Bereich Scope 2 (link-lokal) und größer verpflichtend. Die einzige Ausnahme ist die Link-Local-Adresse aller Hosts FF02::1, die niemals MLD-Nachrichten sendet; Pakete, die an die Link-Local-Adresse aller Hosts gerichtet sind, SOLLTEN (SHOULD) auf allen Ports weitergeleitet werden.

Gruppen mit Adressen in FF00::/15 (was das reservierte FF00::/16 und das node-lokale FF01::/16 einschließt) senden keine MLD-Nachrichten; diese Adressen sollten daher niemals in Paketen auf dem Link erscheinen.

Die folgenden Unterschiede zwischen IPv4 und IPv6 sind für Snooping relevant:

  1. Das Protokoll zur Pflege von IPv6-Multicast-Gruppen heißt Multicast Listener Discovery Version 2 [MLDv2]. MLDv2 verwendet ICMPv6-Nachrichtentypen anstelle von IGMP-Nachrichtentypen.

  2. [IPV6-ETHER] und [IPV6-FDDI] beschreiben, wie die 32 Bit der 128-Bit-Ziel-IP-Adresse (DIP) zur Bildung der 48-Bit-Ziel-MAC-Adresse (DMAC) verwendet werden; [IPV6-TOKEN] beschreibt die Abbildung für Token-Ring-DMAC-Adressen anhand der drei niederwertigen Bits; und [IPV6-1394] verwendet eine 6-Bit-Kanalnummer.

  3. Die Erkennung von Multicast-Routern erfolgt durch das in [MRDISC] definierte MRDISC-Protokoll.

Entsprechend dem IPv4-Verhalten in Bezug auf die Null-IP-Quelladresse DÜRFEN (MUST NOT) MLD-Mitgliedschaftsberichte von einem MLD-Snooping-Switch nicht deshalb zurückgewiesen werden, weil die IP-Quelladresse nicht spezifiziert (::) ist. Wenn ein Nicht-Querier-Switch zudem General Queries spoofed (wie oben in Abschnitt 2.1 für Spanning-Tree-Topologieänderungen behandelt), SOLLTE (SHOULD) er beim Senden dieser Anfragen die nicht spezifizierte IP-Quelladresse (::) verwenden. Werden solche Proxy-Anfragen empfangen, DÜRFEN (MUST NOT) sie nicht in den Querier-Wahlprozess einbezogen werden.

Der IPv6-Header enthält kein Prüfsummenfeld. Ein Switch SOLLTE (SHOULD) jedoch, soweit möglich, andere Paketintegritätsprobleme erkennen, etwa die Konsistenz zwischen Adressversion und Payload-Länge. Werden solche Fehler erkannt, DÜRFEN (MUST NOT) die Informationen des Pakets nicht in die MLD-Weiterleitungstabelle übernommen werden, und der Weiterleitungscode SOLLTE (SHOULD) das Paket verwerfen und die zuvor erörterten sinnvollen Folgemaßnahmen ergreifen.

Da MLDv2 ICMPv6 verwendet und ICMPv6 neben MLD mehrere andere Verwendungen hat, reicht es nicht mehr aus, sich allein auf das next-header-Feld im IP-Header als ICMPv6 zu verlassen, um festzustellen, ob ein Paket mit MLD-Snooping zusammenhängt. Eine Software-Implementierung, die alle ICMPv6-Pakete als Kandidaten für MLD-Snooping behandelt, kann leicht Empfangswarteschlangen füllen und die CPU blockieren, wodurch der Zweck der Snooping-Funktion verfehlt wird, und verliert Nicht-MLD-Pakete, die für andere Hosts bestimmt sind.

Es gibt zwei mögliche Vorgehensweisen:

  1. Vom Snooping-Switch zu verlangen, den Paketinhalt genauer zu untersuchen. Dieser Ansatz ist vorzuziehen, wenn eine Konfigurationsoption bereitgestellt wird, mit der der Administrator festlegen kann, welche ICMPv6-Pakettypen eine CPU-Umleitung auslösen sollen; das Hartcodieren von Pakettypen bietet wenig Flexibilität für die künftige Einführung neuer Typen.

  2. Die ICMPv6-Erkennung mit der Multicast-DMAC-Adresse zu kombinieren. Dieser Ansatz birgt das Risiko, neue Protokolle, die ICMPv6 mit einer Multicast-DMAC-Adresse verwenden, fälschlich als MLD einzustufen.

Der erste Ansatz wird empfohlen. Kann eine solche Konfigurationsoption nicht bereitgestellt werden, SOLLTEN (SHOULD) Implementierer ernsthaft erwägen, sie hinzuzufügen, da Neighbor-Discovery-Nachrichten in die Kategorie fallen, die falsch eingestuft würde, und sie für die Betriebsintegrität von IPv6-Netzwerken entscheidend sind.

Die in [RFC3307] beschriebene Anfangsvergabe von IPv6-Multicast-Adressen deckt nur die unteren 32 Bit der Gruppen-ID ab. Die Abbildung von IP-Multicast-Adressen auf Multicast-DMAC-Adressen weist daher eine große Überschneidung auf. Die Struktur einer IPv6-Multicast-Adresse ist:

   |   8    |  4 |  4 |             112 bits                  |
   +--------+----+----+---------------------------------------+
   |11111111|flgs|scop|             group ID                  |
   +--------+----+----+---------------------------------------+

Somit bilden bei Ethernet und FDDI 2 ** (112 - 32), also mehr als 1,2e24 eindeutige DIP-Adressen, auf dieselbe DMAC-Adresse ab, verglichen mit 2**5 bei IPv4. Gemäß [RFC3307] deckt die Anfangsvergabe von IPv6-Multicast-Adressen jedoch nur die unteren 32 Bit der Gruppen-ID ab; dies beschränkt das Mehrdeutigkeitsproblem vorläufig auf Gruppen-IDs mit unterschiedlichen Flag- und Scope-Werten, doch die Vergabepolitik könnte sich künftig ändern. Angesichts dieser potenziellen Überschneidung wird eine Weiterleitung auf Basis von IPv6-Adressen statt auf Basis von MAC-Adressen empfohlen.