Zusammenfassung

  • RFC 9952 registriert 0x63 0x6f beziehungsweise co für CoAP über DTLS und erlaubt die Angabe in SVCB. Gleichzeitig bestätigt er, dass RFC 7252 ALPN im DTLS-Handshake nicht definierte und dass der neue Text keine RFC-8323-artigen Regeln einführt.
  • Registry und DNS koordinieren Name und Discovery-Absicht. Eine reale Aushandlung braucht ClientHello-Angebot und ServerHello-Auswahl oder Fehler. Peer-Identität, CoAP-Berechtigung und Wirkung folgen als eigene Nachweise.

Für CoAP über TLS existiert coap. RFC 9952 verwendet für DTLS bewusst einen anderen, zwei Byte kürzeren Wert. Ein gemeinsamer Name für verschiedene Transportlagen wäre missverständlich; auf 6LoWPAN kann außerdem jedes Byte nahe einer Fragmentierungsgrenze zählen.

Die Einsparung ist real. Die Schlussfolgerung „damit wird co in jeder CoAP/DTLS-Verbindung ausgehandelt“ ist es nicht.

Eine Registry-Zeile hat begrenzte Zuständigkeit

IANA legt fest, welche Bytefolge ein Profil verwendet, wenn es CoAP über DTLS per ALPN bezeichnet. Die Zeile sagt nichts über geladene Bibliothek, Feature-Schalter, Listener, Clientangebot oder Serverauswahl.

RFC 9952 schützt diese Grenze ausdrücklich. RFC 7252 definierte die Erweiterung nicht für seinen Handshake; das neue Dokument ändert daran nichts. Wer co verpflichtend machen will, braucht ein zusätzliches Profil und muss dessen Erfüllung beweisen.

Ein Konformitätsbericht sollte deshalb drei Aussagen nicht vermischen: Identifier bekannt; Identifier lokal aktiviert; Identifier in einer benannten Verbindung ausgewählt. Nur die letzte ist ein Negotiation-Beleg.

SVCB bleibt vor dem Handshake

Ein SVCB-Eintrag mit alpn=co veröffentlicht eine Dienstoption. Autorität, DNS-Validierung, TTL, Cachealter, Aliasverarbeitung und lokale Kandidatenwahl liegen davor. DNSSEC kann die Antwort absichern, nicht die Konfiguration des Prozesses am Ziel.

Rollouts können DNS und Server in verschiedene Generationen bringen. Clients können SVCB ignorieren oder eine andere Alternative wählen. Ein gemeinsamer Dashboard-Status verschleiert diese Verantwortlichkeiten.

RFC 7301 beschreibt dagegen die Wire-Zustände: geordnete Liste im ClientHello, genau ein daraus gewählter Wert im ServerHello oder der definierte Fehler. Ein Beleg enthält Verbindung, Endpunkte, DTLS-Version, vollständige Liste, Auswahl beziehungsweise Alert, Zeit und Beobachtungspunkt. Retry und Fallback erhalten neue Verbindungsidentitäten.

Zwei Byte sind noch keine Netzwerkmessung

Die Gesamtgröße hängt auch von Cipher Suites, Key Shares, Signaturen, Cookies, Zertifikaten und Erweiterungen ab. DTLS-Fragmentierung und 6LoWPAN-Linkfragmentierung sind verschiedene Schichten. MTU, Funkverlust und Retransmission bestimmen das Ergebnis.

Wer eine Verbesserung behauptet, braucht Vergleichsdaten für Handshakegröße, Linkfragmente, Wiederholungen, Dauer und Fehler. Der Standard liefert den Entwurfsgrund, nicht den Flottennachweis.

Auswahl endet nicht bei Autorisierung

Ein ausgewähltes co beweist nicht, dass Zertifikat oder Raw Public Key zur erwarteten Identität passen. Referenzname, Trust Anchor und Gültigkeit bleiben getrennt. Danach folgen CoAP-Parser, Token- und Message-ID-Korrelation, Method and Resource Policy, Antwort und Anwendungseffekt.

Die Kette lautet: Registry; DNS-Veröffentlichung; Kandidat; Angebot; Auswahl; Identität; CoAP-Austausch; Ressourcenberechtigung; Wirkung; Messung. Auch die umgekehrte Behauptung ist unzulässig: Fehlendes ALPN beweist keine RFC-9952-Verletzung, solange das konkrete Profil keine Pflicht definiert.

Lu Hengs Minimum Initial Specification erklärt die Architektur: Die gemeinsame Schicht enthält nur die interoperable Bezeichnung. Reality Layers verhindern, dass die Tabelle zur Paketspur und die Paketspur zur Geschäftsentscheidung erhoben wird. Running-Code Primacy verlangt die tatsächlich geladene Version und den beobachteten Austausch.

RFC 9952 ist kein unvollständiger Handshake-Standard. Er ist eine vollständige, schmale Registrierungsentscheidung. Genau so sollte er geprüft werden.

Ausnahmen gehören zum tatsächlichen Pfad

Eine Umstellung bewegt nicht gleichzeitig die gesamte Flotte. Manche Sensoren behalten ältere Firmware, Gateways sehen andere DNS-Antworten, SVCB-Datensätze liegen noch im Cache und statisch konfigurierte Clients führen gar keine Discovery aus. Diese Pfade entscheiden, ob ein Prozess die Ankündigung kennen, die Fähigkeit laden und den Wert anbieten konnte. Eine einzige Rollout-Prozentzahl verbirgt damit genau die Ursachen späterer Abweichungen.

Das Ausnahmeregister braucht Eigentümer, Population, Grund, Version, Ablaufdatum und Fallback-Verhalten. Ein abgelaufenes Datum schließt nichts; erst die Beobachtung, dass der letzte betroffene Endpunkt den alten Pfad verlassen hat, tut es. Solange ein alternativer Pfad besteht, braucht jede Verbindung eine eigene Identität und jeder CoAP-Effekt muss ihr zugeordnet werden. Der Erfolg des zweiten Versuchs darf den ersten nicht nachträglich umdeuten.

Ein Release-Beleg verbindet mindestens vier Artefakte: ausführbare Software mit Support, aktivierende Konfiguration, die vom Client gesehene DNS-Generation und eine Spur mit Angebot und Auswahl. Sie sind nicht austauschbar. Ein neues Paket kann alte Konfiguration lesen, neues DNS kann zu einem alten Listener führen, und ein erfolgreicher Canary sagt nichts über abweichende Populationen aus.

Damit werden auch Zuständigkeitsgrenzen sichtbar. DNS kann die Veröffentlichung, aber kein ClientHello belegen. Plattformbetrieb kann lokale Aktivierung, aber keine Serverauswahl belegen. Security kann die Identität bestätigen, aber keine Ressource freigeben. Die Anwendung kann eine Wirkung sehen, ohne den auslösenden Versuch zu kennen. Ein belastbarer Bericht hält diese Urteile zunächst getrennt und verbindet sie erst über gemeinsame Verbindungsdaten.

Quellen