Zusammenfassung

  • RFC 9621–9623 lassen eine Anwendung harte Anforderungen und weiche Präferenzen formulieren; die Implementierung verbindet sie mit Systempolitik, gespeichertem Verlauf und den in der aktuellen Umgebung verfügbaren Kandidaten.
  • Ready bestätigt eine hergestellte, zulässige Protokollkombination. Das Ereignis legt weder die Rangfolge noch verworfene Kandidaten, Cache-Einflüsse, verlorene Präferenzen oder das Ergebnis beim Nutzer offen.

RFC 9621 entwirft eine Transport-Services-Architektur, in der Anwendungen nicht jede Adresse, Schnittstelle und jedes Protokoll selbst fest verdrahten. Sie beschreiben den benötigten Dienst und erhalten eine abstrakte Connection. RFC 9622 definiert die sprach- und plattformunabhängige API. RFC 9623 erläutert, wie Pfade, Protokollstapel und Zielvarianten gesammelt, geordnet und gegeneinander gestartet werden.

Die Abstraktion erleichtert die Einführung neuer Transportverfahren und die Nutzung mehrerer Pfade. Sie verlagert aber auch Entscheidungsmacht. Ein stabiler API-Aufruf sagt nicht, dass zwei Plattformen die gleiche Auswahl treffen, wenn Politik, Cache, verfügbare Protokolle oder Netzkontext voneinander abweichen.

Fünf Stufen, zwei verschiedene Vertragsarten

RFC 9622 kennt für die meisten Selection Properties Require, Prefer, No Preference, Avoid und Prohibit. Require lässt nur Kandidaten mit der Eigenschaft zu und erzwingt sonst einen Fehler. Prohibit schließt Kandidaten mit der Eigenschaft aus. Prefer und Avoid verändern die Reihenfolge, erlauben aber ein anderes Ergebnis.

Alle Anforderungen und Verbote müssen erfüllt sein. Präferenzen dürfen je nach System und Situation unterschiedlich ausgehen. Das ist kein Implementierungsfehler, sondern Teil des Anpassungsmodells.

Für Produktzusagen ist der Unterschied entscheidend. „Ungetakteten Zugang bevorzugen“ erlaubt weiterhin einen getakteten Pfad. „Getakteten Zugang verbieten“ schützt die Kosten, kann aber die Verbindung verhindern. Wer die erste Form technisch setzt und die zweite verkauft, verschiebt ein Risiko, ohne es zu kontrollieren.

Auch der Name einer Schnittstelle ist kein Beleg. Wi-Fi bedeutet nicht automatisch ungetaktet, günstig oder privat. Mobilfunk bedeutet nicht automatisch teuer. RFC 9622 warnt ausdrücklich davor, Schnittstellentypen als Stellvertreter für andere Eigenschaften zu verwenden.

Anwendung, System und Implementierung teilen die Auswahl

RFC 9623 nennt drei Quellen: Anwendungspräferenzen, dynamische System Policy und voreingestellte Implementierungspolitik. Eine Verwaltung kann eine Schnittstelle sperren. Das Betriebssystem kann Regeln für einen Prozess anwenden. Die Implementierung setzt Standardwerte für nicht angegebene Eigenschaften.

Jeder verwendete Pfad muss mit den Einschränkungen aller drei Ebenen vereinbar sein. Ein Verbot kann als PolicyProhibited sichtbar werden. RFC 9621 standardisiert jedoch keine Schnittstelle zum Lesen oder Schreiben der System Policy, weil ihre Ausgestaltung plattformabhängig ist.

Damit ist die Absicht portabel, die Begründung der Auswahl aber nicht zwingend. Ein erfolgreiches Ready enthält weder einen Politikstand noch die Kandidatenliste oder Ranggewichte. Zwei korrekt arbeitende Systeme können unterschiedliche Gewinner liefern.

Das verlangt keine zentrale Einheitssteuerung. Es verlangt eine Trennung: Der gemeinsame Vertrag trägt harte Semantik; ein lokaler Auswahlbeleg dokumentiert die konkret ausgeübte Entscheidung.

Schon der Baum enthält eine Priorität

RFC 9623 empfiehlt, zuerst nach Netzpfaden, danach nach Protokolloptionen und zuletzt nach abgeleiteten Endpunkten zu verzweigen. Die Reihenfolge verhindert unbrauchbare Kombinationen, entscheidet aber zugleich, wie Präferenzen aufeinandertreffen.

Im Beispiel bevorzugt eine Anwendung Wi-Fi und SCTP. Wenn der Cache SCTP über Wi-Fi als nicht verfügbar einstuft, enthält der Wi-Fi-Zweig TCP, während LTE SCTP und TCP anbietet. Weil der Pfad zuerst behandelt wird, kann Wi-Fi/TCP vor LTE/SCTP starten.

Keine Präferenz wurde gelöscht. Die Struktur hat ihnen eine Reihenfolge gegeben. Wer nur den Gewinner speichert, kann später nicht erklären, warum eine vermeintlich bessere Kombination nie gestartet wurde. Dafür braucht es gesammelte und entfernte Äste, Filtergründe und Präzedenz.

Auch die Ziele sind kontextabhängig. DNS kann auf zwei Schnittstellen andere Antworten liefern. Ein Proxy ändert Ziel und Port. Ein Protokoll ist vielleicht nur auf einem Pfad verfügbar. Eine Kandidatenliste ohne Zeitpunkt und Netzkontext ist unvollständig.

Der erste Erfolg braucht eine zulässige Startlinie

RFC 9623 unterscheidet gleichzeitiges, gestaffeltes und fehlergesteuertes Racing. Gleichzeitige Versuche sparen möglicherweise Zeit, verbrauchen aber Ressourcen und erzeugen ungenutzten Zustand; sie sollen nicht der Regelfall sein. Beim gestaffelten Verfahren beginnen Alternativen nach Verzögerungen. Beim Failover startet die nächste Option erst nach dem Scheitern der bevorzugten.

Diese Wahl ist selbst Politik. Soll ein Proxy genutzt werden, kann ein aggressives Rennen gegen den Direktpfad ihn wegen weniger Millisekunden umgehen. Ein harter Zwang oder echtes Failover schützt die Priorität.

RFC 8305 liefert mit Happy Eyeballs das bekannte Modell für Adressfamilien. TAPS erweitert es auf Pfade und Stapel. „Als Erster verbunden“ ist nur innerhalb einer korrekt zugelassenen Menge sinnvoll.

RFC 8922 ordnet Sicherheitsparameter in Transport Services ein. RFC 9623 warnt vor Angreifern, die den ersten Versuch blockieren und einen Fallback erzwingen. Ist der zweite Kandidat schwächer, wird Verfügbarkeit zum Downgrade. Alle Alternativen müssen harte Sicherheitsvorgaben bewahren und einer anerkannten Sicherheitsäquivalenz genügen.

Historie ist eine Eingabe, kein Naturgesetz

Gespeichert werden können DNS-Antworten, TLS-Sitzungszustand, TCP-Fast-Open-Informationen, RTT, Aufbauzeit und Erfolgsquote. RFC 9040 gibt den größeren Rahmen für gemeinsam genutzte TCP-Kontrollinformationen. Solche Werte können den nächsten Baum sortieren oder Zweige entfernen.

Das spart Arbeit, schafft aber Rückkopplung. Ein früher Fehler kann einen inzwischen reparierten Pfad weiterhin verdrängen. Der häufige Gewinner erzeugt mehr neue Messungen und bestätigt sich selbst. RFC 9621 fordert daher, benötigte Eigenschaften ausdrücklich zu setzen und sich nicht auf ein bestimmtes Cache-Verhalten zu verlassen.

Der Cache hat außerdem eine Datenschutzgrenze. Getrennte Connection Contexts können verhindern, dass TLS-Zustand oder Multiplexing zwei Aktivitäten miteinander verknüpfen. Ein Auswahlbeleg sollte Cache-Raum, Datenart, Alter und Verfallsgrund nennen, nicht Tickets, Schlüssel oder Personenkennungen kopieren.

Was Ready wirklich abschließt

RFC 9623 betrachtet den Aufbau als abgeschlossen, sobald mindestens ein Stapel Anwendungsdaten senden und empfangen kann. RFC 9622 meldet diesen Übergang mit Ready. Das ist ein wichtiger lokaler Beleg für einen hergestellten, nach den harten Regeln zulässigen Stapel.

Es ist kein Beleg für jede Präferenz, entfernte Kandidaten, die Verarbeitung durch die Gegenstelle oder den Nutzen beim Anwender. Eine belastbare Kette trennt Absicht, Politik, Cache, Kandidaten, Rennverlauf, Gewinner, Nachrichtenereignisse, entfernte Verarbeitung und Ergebnis.

RFC 9623 nennt Apples Network.framework, NEAT, NEATPy und PyTAPS als Implementierungen, die dem Ansatz in unterschiedlichem Maß folgen. Die Apple-Network-Dokumentation zeigt die praktische Verbindung von Protokollen und Pfadbedingungen. Sie zertifiziert weder vollständige Konformität noch identische Beobachtbarkeit.

Quellen