Zusammenfassung
- RFC 9897 regelt die MP-DCCP-Aushandlung, Adressankündigung und authentisierte Aufnahme eines zusätzlichen Subflows in eine bestehende Verbindung.
MP_CONFIRMundMP_JOINbelegen begrenzte Steuerungsfakten; sie belegen weder Scheduler-Nutzung noch rechtzeitigen Empfang, Sortierung, Umschaltung oder Resilienz der Anwendung.
Die Betriebsanzeige ist grün. Ein zweiter Subflow hat den Handshake beendet, der Connection Identifier passt, und der HMAC bindet den Beitritt an die Parteien des ersten Flows. Dann fragt die Dienstverantwortliche: Welches wichtige Datagramm lief über diesen Pfad, als der primäre Pfad nachließ? Das Steuerungsprotokoll kann es nicht sagen.
RFC 9897 wurde im Januar 2026 als Proposed Standard veröffentlicht; der RFC-Editor-Datensatz fixiert seine Identität. Er erweitert DCCP aus RFC 4340. Dessen Dienst bleibt unzuverlässige, staukontrollierte Datagrammübertragung. Mehrere Subflows erscheinen der Anwendung als eine Verbindung, werden dadurch aber nicht zu einem zuverlässigen Bytestrom.
Der erste Subflow handelt Multipath-Fähigkeit aus und tauscht hostspezifisches Schlüsselmaterial. Ein weiterer führt MP_JOIN, den Identifier der Gegenstelle und einen frischen Nonce mit; MP_HMAC prüft die Zugehörigkeit zur ursprünglichen Verbindung. So wird ein authentisierter Verband von einer bloßen Behauptung unterschieden. Welches Anwendungspaket der Scheduler diesem Subflow zuweist, folgt daraus nicht.
Eine Adressmeldung liegt noch davor. MP_ADDADDR kündigt Adresse und optional Port an, wird per HMAC geschützt und per Sequenz gegen veraltete Daten abgegrenzt. Die Gegenstelle darf die Meldung speichern oder verwerfen. MP_CONFIRM macht den Optionsaustausch zuverlässig, doch die weitere Verarbeitung im Empfänger gehört ausdrücklich nicht zur Bestätigung. Bestätigte Ankündigung ist kein aufgebauter Subflow; ein aufgebauter Subflow ist keine beobachtete Datennutzung.
Diese Trennung ist Absicht. MP-DCCP liefert verbindungsweite Sequenznummern, RTT-Information und Prioritätshinweise. Sendeplanung, optionale Sortierung beim Empfänger sowie Zeitpunkt und Reihenfolge des Hinzufügens oder Entfernens bleiben den Endpunkten überlassen. Selbst die maximale Subflow-Zahl wird nicht ausgehandelt; Implementierungen müssen Ressourcen begrenzen.
In diesen lokalen Entscheidungen entsteht der Dienst. Eine Mobilitätsstrategie kann bei ungeeignetem Hauptpfad einen Ersatz versuchen, aber die Wahl des besten Quell-Ziel-Paars bleibt Implementierungssache. Bei gleichzeitiger Nutzung entscheidet der Scheduler pro Paket; Staukontrolle und mögliche Sortierung formen das Ergebnis. Mehrere Subflows können denselben Engpass teilen. Ihre Zahl beweist weder unabhängige Fehlerdomänen noch mehr Kapazität.
Auch die Sicherheitsgrenze ist schmal. RFC 9897 schützt Beitritte und ausgewählte Signale im eigenen Schlüsselmodell, bietet aber nicht automatisch alle kryptografischen Garantien einer Anwendung. Deshalb verweist er etwa auf DTLS über DCCP. Ein Address ID löst zudem nicht jedes Middlebox-Problem. DCCP-UDP beschreibt eine Kapselung zur Durchquerung, die RFC 9897 jedoch außerhalb von MP-DCCP hält.
Begriffe und Signalisierungsideen stammen teilweise aus RFC 8684; zur Pfadbegrenzung wird RFC 8041 zitiert. Das ist Kontext und überträgt weder MPTCP-Liefereigenschaften noch Betriebserfahrung. Das IANA-Register für DCCP-Parameter belegt die Zuteilung von Feature 10, Option 46, Version 0 und Suboptionen, nicht deren Implementierung.
Vier Nachweisbücher müssen zusammenfinden. Das Steuerungsbuch enthält Aushandlung, Meldungen, Bestätigungen, Beitritte, Nonces, Schlüsseltypen, Schließen und Rückfall. Das Pfadbuch enthält Scheduler-Entscheidungen, Vierertupel, staukontrollierte Sendeerlaubnis, Zeit, Verlust und gemeinsame Engpässe. Das Empfangsbuch enthält Ankunft, Lücken, Verspätung und Sortierung. Das Dienstbuch misst das konkrete Umschalt-, Latenz-, Kontinuitäts- oder Bündelungsziel.
Heng Lus minimale Anfangsspezifikation erklärt, warum der RFC keinen Universalscheduler festschreibt: Die gemeinsame Interoperabilität bleibt dünn, künftige Entscheidungen bleiben dort, wo sie beobachtbar und umkehrbar sind. Der Vorrang laufender Systeme verlangt Paket- und Dienstbelege. Die Realitätsebenen verhindern, dass ein authentisiertes Symbol spätere Ergebnisse beherrscht.
Der Standard gibt dem zweiten Pfad einen disziplinierten Beitritt. Resilienz beginnt erst, wenn die Beweiskette danach weitergeht.
Sources
- https://www.rfc-editor.org/rfc/rfc9897.html
- https://www.rfc-editor.org/info/rfc9897/
- https://www.rfc-editor.org/rfc/rfc4340.html
- https://www.rfc-editor.org/rfc/rfc8684.html
- https://www.rfc-editor.org/rfc/rfc5238.html
- https://www.rfc-editor.org/rfc/rfc6773.html
- https://www.rfc-editor.org/rfc/rfc8041.html
- https://www.iana.org/assignments/dccp-parameters
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten

