Zum Hauptinhalt springen

13. IANA-Überlegungen (IANA Considerations)

Dieser Abschnitt beschreibt die IANA (Internet Assigned Numbers Authority)-Registrierungen und Überlegungen im Zusammenhang mit Neighbor Discovery für IPv6.

13.1. ICMPv6-Typ- und Code-Registrierungen

Neighbor Discovery verwendet mehrere ICMPv6-Nachrichtentypen, die bei IANA registriert wurden. Die folgenden ICMPv6-Typen sind in dieser Spezifikation definiert:

ICMPv6 TypNameReferenz
133Router SolicitationRFC 4861, Section 4.1
134Router AdvertisementRFC 4861, Section 4.2
135Neighbor SolicitationRFC 4861, Section 4.3
136Neighbor AdvertisementRFC 4861, Section 4.4
137Redirect MessageRFC 4861, Section 4.5

Alle diese Nachrichtentypen verwenden Code 0, und es sind derzeit keine anderen Code-Werte für diese Typen definiert.

13.2. Neighbor Discovery Optionstyp-Register

IANA führt ein Register für Neighbor Discovery-Optionstypen. Die folgenden Optionstypen sind in dieser Spezifikation definiert:

OptionstypNameReferenz
1Source Link-Layer AddressRFC 4861, Section 4.6.1
2Target Link-Layer AddressRFC 4861, Section 4.6.1
3Prefix InformationRFC 4861, Section 4.6.2
4Redirected HeaderRFC 4861, Section 4.6.3
5MTURFC 4861, Section 4.6.4

13.2.1. Registrierungsverfahren

Neue Neighbor Discovery-Optionstypen werden nach folgendem Verfahren zugewiesen:

  • Werte 0-255: IETF Review oder IESG Approval erforderlich (wie in RFC 8126 definiert)
  • Neue Optionen MÜSSEN (MUST) in einer RFC oder anderen dauerhaften, öffentlich verfügbaren Referenz dokumentiert werden
  • Die Registrierung MUSS (MUST) enthalten:
    • Optionstyp-Wert
    • Optionsname
    • Kurze Beschreibung der Option
    • Referenz auf das definierende Dokument

13.2.2. Optionstyp-Format

Optionstyp-Werte sind 8-Bit-Identifikatoren. Die höherwertigen zwei Bits des Optionstyp-Feldes werden verwendet, um die Aktion zu spezifizieren, die ausgeführt werden soll, wenn der Optionstyp nicht erkannt wird:

  • 00: Diese Option überspringen und die Verarbeitung der Nachricht fortsetzen
  • 01: Die Nachricht verwerfen
  • 10: Die Nachricht verwerfen und eine ICMP Parameter Problem-Nachricht senden
  • 11: Die Nachricht verwerfen und eine ICMP Parameter Problem-Nachricht nur senden, wenn die Zieladresse keine Multicast-Adresse ist

Diese Kodierung ermöglicht eine flexible Behandlung unbekannter Optionen und ermöglicht eine reibungslose Bereitstellung neuer Optionstypen.

13.3. IPv6 Neighbor Discovery-Protokollkonstanten

Obwohl nicht direkt von IANA verwaltet, definiert diese Spezifikation mehrere Protokollkonstanten (dokumentiert in Abschnitt 10), die Implementierer verwenden MÜSSEN (MUST). Diese Konstanten umfassen Timing-Werte, Wiederholungsgrenzen und andere für die Interoperabilität wesentliche Parameter.

13.4. Router Advertisement-Flags

IANA führt ein Register für Router Advertisement-Flags. Die folgenden Flags sind in dieser Spezifikation definiert:

BitFlag-NameReferenz
0M (Managed Address Configuration)RFC 4861, Section 4.2
1O (Other Configuration)RFC 4861, Section 4.2
2-7ReserviertRFC 4861

Zusätzliche Flags können in zukünftigen Spezifikationen nach IETF Review-Verfahren definiert werden.

13.5. Prefix Information Option-Flags

IANA führt ein Register für Prefix Information Option-Flags. Die folgenden Flags sind in dieser Spezifikation definiert:

BitFlag-NameReferenz
0L (On-Link)RFC 4861, Section 4.6.2
1A (Autonomous Address Configuration)RFC 4861, Section 4.6.2
2R (Router Address)RFC 6275
3-7ReserviertRFC 4861

Hinweis: Das R-Flag wurde durch RFC 6275 (Mobile IPv6) hinzugefügt und ist hier der Vollständigkeit halber enthalten.

13.6. Neighbor Advertisement-Flags

IANA führt ein Register für Neighbor Advertisement-Flags. Die folgenden Flags sind in dieser Spezifikation definiert:

BitFlag-NameReferenz
0R (Router)RFC 4861, Section 4.4
1S (Solicited)RFC 4861, Section 4.4
2O (Override)RFC 4861, Section 4.4
3-31ReserviertRFC 4861

13.7. Aktualisierungen früherer Registrierungen

Dieses Dokument (RFC 4861) macht RFC 2461 obsolet. Alle IANA-Registrierungen, die RFC 2461 referenzierten, wurden aktualisiert, um stattdessen RFC 4861 zu referenzieren.

13.8. Überlegungen für zukünftige Erweiterungen

Bei der Definition neuer Neighbor Discovery-Nachrichten, -Optionen oder -Flags:

  1. Rückwärtskompatibilität: Stellen Sie sicher, dass neue Funktionen mit bestehenden Implementierungen koexistieren können. Unbekannte Optionen MÜSSEN (MUST) wie in Abschnitt 9 spezifiziert stillschweigend ignoriert werden.

  2. Sicherheitsauswirkungen: Berücksichtigen Sie, wie neue Funktionen mit Sicherheitsmechanismen wie SEcure Neighbor Discovery (SEND) [RFC3971] interagieren.

  3. Dokumentationsanforderungen: Dokumentieren Sie die neue Funktion vollständig in einer RFC oder anderen dauerhaften, öffentlich verfügbaren Referenz.

  4. IANA-Registrierung: Befolgen Sie ordnungsgemäße IANA-Registrierungsverfahren wie in RFC 8126 spezifiziert.

  5. Implementierungserfahrung: Sammeln Sie wenn möglich Implementierungs- und Bereitstellungserfahrung vor der Standardisierung.

13.9. Verweise auf IANA-Register

Aktuelle IANA-Register im Zusammenhang mit Neighbor Discovery finden Sie unter:

Implementierer und Protokolldesigner sollten diese Register für die aktuellsten Informationen über registrierte Werte konsultieren.