Zusammenfassung

  • RFC 3542 trennte dauerhafte IPv6-Socket-Optionen von Ancillary Data für eine einzelne Nachricht. Zusatzdaten ersetzen nur die gleichnamige Option; alle anderen Vorgaben bleiben aktiv.
  • Die Reichweite hat klare Grenzen: Ein Datenobjekt der Länge null kann eine Option für ein Datagramm deaktivieren, bereits eingereihte Pakete können neu angeforderte Metadaten vermissen lassen, und TCP-Sendeaufrufe entsprechen nicht einzelnen übertragenen Segmenten.

Man stelle sich einen langlebigen UDP-Socket für Diagnoseverkehr vor. Die Anwendung hat eine Ausgangsschnittstelle und mehrere IPv6-Optionen festgelegt, die für jedes Datagramm gelten sollen. Eine besondere Nachricht muss einen anderen Weg nehmen. Wird ihre Zusatzinformation als Ersatz für den gesamten Satz von Vorgaben behandelt, erreicht das Paket vielleicht die gewünschte Route, verliert dabei aber Entscheidungen, die niemand ändern wollte.

RFC 3542, im Mai 2003 als Advanced Sockets Application Program Interface (API) for IPv6 veröffentlicht, machte diese Grenze ausdrücklich. Das Dokument ist Informational und kein Protokollstandard für das Netz. Es beschreibt die Schnittstelle zwischen Anwendung und Kernel: Welche IPv6-Verarbeitung ein Programm anfordern kann, nicht was das Netz anschließend tatsächlich transportiert. Ein akzeptierter Aufruf beweist weder den gesendeten Paketinhalt noch den späteren Anwendungserfolg.

Der Vergleich mit RFC 2292, den RFC 3542 ersetzte, erklärt die Änderung. Das ältere Modell fasste dauerhafte Optionen als Gruppe auf. Ancillary Data für eine Nachricht konnte diese Gruppe ersetzen. RFC 3542 trennte mehr Optionen und machte die einzelnen Kontrollen separat adressierbar. Wenn der Zustand einzelne Felder besitzt, sollte auch das Überschreiben einzeln begrenzt sein: Nur die Option desselben Typs wird ersetzt.

Das ist mehr als Programmiersyntax. Die Regel bestimmt, wie weit eine Ausnahme wirken darf. Hält der Socket Entscheidungen für Schnittstelle, Verkehrsklasse und Erweiterungsheader fest, darf ein Routing-Datum für eine Nachricht nicht die übrigen Optionen löschen. Der Kernel verbindet die dauerhaften Vorgaben mit der eng gefassten Ausnahme, wenn er das Datagramm erstellt. Diese Konstruktion ist jedoch noch keine Beobachtung des tatsächlich gesendeten Pakets.

Die API erlaubt auch eine genau benannte Abwesenheit. Eine Anwendung kann IPV6_HOPOPTS dauerhaft setzen und für eine Nachricht Ancillary Data desselben Typs mit Länge null übergeben. So entfällt der Hop-by-Hop-Optionsheader für dieses Datagramm. Null bedeutet nicht „alle Vorgaben vergessen“. Es deaktiviert eine bezeichnete Option einmalig. Das nächste Datagramm übernimmt wieder den dauerhaften Wert, sofern die Anwendung ihn nicht anderweitig ändert.

Beim Empfang entsteht ein anderes, zeitliches Problem. Die Anwendung aktiviert IPV6_RECVxxx-Optionen; recvmsg() kann verfügbare Paketinformationen als Ancillary-Objekte liefern. Fehlt ein erwartetes Objekt, kann die betreffende Information im Paket gefehlt haben. RFC 3542 weist aber auch darauf hin, dass Datagramme, die schon vor dem Aktivieren der Empfangsoption in der Warteschlange lagen, die neuen Metadaten möglicherweise nicht enthalten. Die Lücke kann also vom Paket stammen oder davon, dass die Beobachtung zu spät begann.

TCP markiert das Ende der Datagramm-Analogie. RFC 3542 definiert nicht dieselbe Ancillary-Steuerung pro Sendeaufruf, weil ein Aufruf der Anwendung keinem einzelnen TCP-Segment entspricht. Eine erneute Übertragung kann alte oder neue dauerhafte Optionen verwenden; die Spezifikation verspricht keine Nachrichtengrenze, die TCP nicht abbildet. Auch bestimmte optionale Empfangsinformationen für TCP bleiben undefiniert und sollen laut RFC nicht für Zugriffskontrolle herangezogen werden.

Historische Beispiele brauchen eine zeitliche Einordnung. RFC 3542 zeigt einen Routing Header vom Typ 0 aus der RFC-2460-Zeit. RFC 8200 ist heute die IPv6-Basisspezifikation. Das frühere Beispiel belegt, welche API-Funktionen damals beschrieben wurden; es ist keine aktuelle Routingempfehlung.

Die Geschichte von RFC 3542 handelt somit von einer engeren Ausnahme: Aus dem gruppenweiten Ersatz in RFC 2292 wurde ein Ersatz nur für die gleichnamige Option. Für einen belastbaren Nachweis müssen der Socket-Zustand vor dem Aufruf, die Ancillary Data der Nachricht, das beobachtete Paket und das spätere Ergebnis getrennt erfasst werden. Ein erfolgreicher sendmsg()-Aufruf belegt, dass die Schnittstelle eine Absicht annahm, nicht dass das Paket den erwarteten Weg nahm.

Quellen