Zum Hauptinhalt springen

9. Erweiterbarkeit - Optionsverarbeitung (Extensibility - Option Processing)

Das Neighbor Discovery-Protokoll wurde so konzipiert, dass es durch Hinzufügen neuer Optionen erweiterbar ist. Dieser Abschnitt beschreibt, wie Knoten Optionen in empfangenen Neighbor Discovery-Nachrichten verarbeiten, um sicherzustellen, dass zukünftige Erweiterungen mit aktuellen Implementierungen koexistieren können.

9.1. Allgemeine Prinzipien (General Principles)​

Um Rückwärtskompatibilität und Vorwärtserweiterbarkeit zu gewährleisten:

  • Nicht erkannte Optionen (Unrecognized Options): Alle Knoten MÜSSEN (MUST) alle Optionen, die sie in empfangenen Neighbor Discovery-Paketen nicht erkennen, stillschweigend ignorieren und die Verarbeitung des Pakets fortsetzen. Dies ermöglicht es, in Zukunft neue Optionen zu definieren, ohne bestehende Implementierungen zu beeinträchtigen.

  • Mehrfache Optionen (Multiple Options): Optionen können mehrfach in derselben Nachricht erscheinen. Knoten MÜSSEN (MUST) darauf vorbereitet sein, diesen Fall angemessen zu behandeln.

  • Optionsreihenfolge (Option Order): Die Reihenfolge, in der Optionen in einer Nachricht erscheinen, ist im Allgemeinen nicht signifikant, es sei denn, dies wird für bestimmte Optionstypen explizit angegeben.

  • Auffüllung (Padding): Optionen sollten bei Bedarf aufgefüllt werden, um sicherzustellen, dass sie an ihren natürlichen 64-Bit-Grenzen enden.

9.2. Verarbeitungsregeln (Processing Rules)​

Bei der Verarbeitung einer Neighbor Discovery-Nachricht, die Optionen enthält:

  1. Alle Optionen parsen (Parse All Options): Der Knoten MUSS (MUST) alle Optionen in der Nachricht parsen, auch wenn einige nicht erkannt werden.

  2. Unbekannte Optionen ignorieren (Ignore Unknown Options): Wenn eine Option nicht erkannt wird (basierend auf ihrem Type-Feld), MUSS (MUST) der Knoten sie ignorieren und mit der Verarbeitung nachfolgender Optionen und der Nachricht selbst fortfahren.

  3. Bekannte Optionen validieren (Validate Known Options): Für erkannte Optionen MUSS (MUST) der Knoten die Option gemäß den für diesen Optionstyp spezifizierten Regeln validieren. Wenn eine Option die Validierung nicht besteht (z. B. falsche Länge, ungültige Feldwerte), hängt das Verhalten vom spezifischen Optionstyp und Nachrichtentyp ab.

  4. Verarbeitung fortsetzen (Continue Processing): Selbst wenn eine oder mehrere Optionen ungültig oder nicht erkannt sind, SOLLTE (SHOULD) der Knoten die Verarbeitung der Nachricht und aller verbleibenden gültigen Optionen fortsetzen, es sei denn, die Spezifikation für einen bestimmten Nachrichten- oder Optionstyp erfordert etwas anderes.

9.3. Anforderungen an das Optionsformat (Option Format Requirements)​

Alle neuen für Neighbor Discovery definierten Optionen MÜSSEN (MUST) dem in Abschnitt 4.6 spezifizierten allgemeinen Optionsformat mit einem Type- und Length-Feld folgen. Das Length-Feld wird in Einheiten von 8 Oktetten angegeben.

Bei der Definition neuer Optionen SOLLTEN (SHOULD) Protokolldesigner:

  • Sicherstellen, dass die Option von Knoten, die sie nicht implementieren, sicher ignoriert werden kann, ohne betriebliche Probleme zu verursachen.
  • Die Auswirkungen auf die Nachrichtengröße und Link-MTU berücksichtigen.
  • Klare Validierungsregeln für die Option spezifizieren.

9.4. Zukünftige Erweiterungen (Future Extensions)​

Zukünftige rückwärtskompatible Änderungen am Neighbor Discovery-Protokoll können:

  • Neue Optionstypen definieren
  • Die Verwendung derzeit reservierter Felder in Nachrichtenformaten spezifizieren
  • Neue Flag-Bits in bestehenden Nachrichten definieren (mit dem Verständnis, dass nicht erkannte Flags ignoriert werden)

Rückwärts-inkompatible Änderungen würden die Definition neuer Nachrichtentypen (mit unterschiedlichen ICMP Type- oder Code-Werten) oder die Definition einer neuen Protokollversion erfordern.

9.5. Implementierungsüberlegungen (Implementation Considerations)​

Implementierungen SOLLTEN (SHOULD):

  • So konzipiert sein, dass sie neue Optionstypen problemlos aufnehmen können, ohne größere Codeänderungen zu erfordern.
  • Protokollieren oder Diagnoseinformationen über nicht erkannte Optionen bereitstellen, um Debugging und zukünftige Protokollbereitstellung zu unterstützen.
  • Sicherheitsimplikationen beim Verarbeiten von Optionen berücksichtigen, insbesondere solche, die Routing-Entscheidungen oder Cache-Einträge beeinflussen könnten.

9.6. Sicherheit und Erweiterbarkeit (Security and Extensibility)​

Der Erweiterbarkeitsmechanismus bietet an sich keine Sicherheit. Neue Optionen können neue Sicherheitslücken einführen, wenn sie nicht sorgfältig konzipiert werden. Protokolldesigner, die neue Optionen definieren, SOLLTEN (SHOULD):

  • Berücksichtigen, wie die Option mit Secure Neighbor Discovery (SEND) [RFC3971] interagiert.
  • Potenzielle Angriffe analysieren, die die neue Option ausnutzen könnten.
  • Sicherheitsüberlegungen dokumentieren, die spezifisch für die neue Option sind.

Implementierungen SOLLTEN (SHOULD) Mechanismen bereitstellen, um die Unterstützung für bestimmte Optionstypen basierend auf lokalen Sicherheitsrichtlinien selektiv zu aktivieren oder zu deaktivieren.

Letztes Update am