Zusammenfassung

  • RFC 9003 erlaubt bis zu 255 Oktette freien UTF-8-Text nur bei Administrative Shutdown oder Administrative Reset; die Spezifikation ersetzt RFC 8203 mit seinem 128-Oktett-Limit.
  • Die NOTIFICATION beendet die Verbindung. BGP bestätigt weder Empfang noch richtiges Verständnis; ohne Transportintegrität und -vertraulichkeit kann der Inhalt gefälscht oder beobachtet werden.
  • Erklärung, Route-Draining und Route-Retention sind unabhängige Flächen. Der Beweis reicht von Rohbytes und Empfängerlog bis zu Retry, RIB, FIB und Paketen.

Um 02:00 sendet ein Border-Router [CHG-4281] Edge-Upgrade; Rückkehr in etwa 30 Minuten und beendet TCP. Der fremde NOC erkennt eine mutmaßlich geplante Aktion. Er weiß noch nicht, ob eine berechtigte Person sie ausgelöst hat, ob die Zeit stimmt oder ob der Datenverkehr vorher verschoben wurde.

Ein sehr kleines Sprachfenster

RFC 4486 ordnet Cease-Ursachen. RFC 9003 öffnet das Freitextfeld ausschließlich für Subcode 2 und 4. Prefix-Limit, Peer-Deconfiguration, Collision und Ressourcenmangel behalten eigene strukturierte Gründe. Ein erläuternder Satz darf keine falsche Klassifizierung kaschieren.

Das Format besteht aus einem Längenoktett und genau so vielen UTF-8-Oktetten. Null heißt kein Text; es gibt keinen NUL-Abschluss, und die kürzeste UTF-8-Form ist Pflicht. 255 bezeichnet Oktette, nicht Zeichen. Mehrbyte-Schriften verbrauchen das Budget schneller—der praktische Grund, warum RFC 9003 den älteren 128-Oktett-Entwurf ablöst.

128 bleibt die Kompatibilitätsgrenze. Ist aktuelle Unterstützung bewiesen, darf der Sender 255 nutzen. Ist sie unbekannt, sollte er 128 nicht überschreiten. Ein reiner RFC-8203-Empfänger kann längere Daten als Fehler protokollieren und die terminale NOTIFICATION dennoch verarbeiten.

Das ist eine minimale Anfangsspezifikation: gemeinsamer Subcode, Länge und Encoding, aber keine globale Ticketplattform, Sprache, Offenlegungsregel oder Aufbewahrung. Zukunftsentscheidungen bleiben lokal.

Die letzte Aussage kann keine Antwort erhalten

Nach RFC 4271 schließt eine gesendete NOTIFICATION die BGP-Verbindung sofort. Auch ein Fehler darin kann nicht mit einer weiteren NOTIFICATION beantwortet werden. RFC 9003 stellt daher klar: Empfang und korrektes Verständnis lassen sich im Protokoll nicht quittieren.

Der Senderlog beweist einen lokalen Versuch. Packet Capture beweist gesendete Bytes. Remote Capture oder Daemonlog beweist Ankunft und Decode. Nichts davon beweist, dass ein Mensch gelesen, das Ticket gefunden oder der Aktion zugestimmt hat.

Eine gemeinsam verstandene Change-ID sollte zu einer authentisierten Out-of-Band-Mitteilung führen. Das ist knapper und sicherer als die interne Ticketgeschichte auf dem Draht. BGP liefert beim Verschwinden den Index; Genehmigung und Dialog gehören in einen dauerhaften Rückkanal.

Korrektes UTF-8 kann gefährlichen Inhalt tragen

Encoding-Validität schützt Parser, nicht Wahrheit. Ein syntaktisch korrekter String kann eine falsche Referenz, Unicode-Verwechslung oder Zeichenfolge enthalten, die im Syslog wie ein neuer lokaler Eintrag aussieht. shortest form entfernt illegale Varianten, nicht visuelle Täuschung.

Der Receiver muss Rohwert und sichere Darstellung trennen, Control Characters neutralisieren und Peer-Daten sichtbar kennzeichnen. Das Limit begrenzt Menge, aber säubert nichts.

Ohne Integrität ist Fälschung möglich; ohne Vertraulichkeit kann jemand mitlesen. Deshalb gelten Datenminimierung und klare Freigabe: gemeinsamer Schlüssel, grobe Change-Klasse, Zeitfenster. Personendaten, Credentials, Kunden, interne Hosts, Topologie und unreife Root-Cause gehören nicht hinein.

Selbst authentisierter Transport bestätigt nur den konfigurierten Endpunkt. Er signiert weder den Autor noch das Versprechen. Bis zur unabhängigen Bestätigung bleibt der Text eine Behauptung des Peers.

Erklärung ist kein Make-before-break

RFC 8326 senkt vor der Trennung die Pfadpräferenz, wartet auf Konvergenz und schließt danach. RFC 9003 spricht im Augenblick der Schließung. Der Text erzeugt keinen Alternativpfad und verschiebt kein Paket.

Ein guter Ablauf nutzt beides: messbares Draining, dann erklärter Shutdown. Beide Ergebnisse brauchen eigene Nachweise.

RFC 8538 fügt das Graceful-Notification-N-Bit hinzu. Nach beidseitigem Austausch kann eine NOTIFICATION außer Hard Reset stale Routes behalten. Cease 9 verlangt vollständigen Reset. Für Administrative Shutdown wird Hard Reset empfohlen; bei Administrative Reset bleibt Benutzerkontrolle. Das ist Orientierung, keine universelle Zuordnung.

Wird der Verwaltungsgrund in Hard Reset transportiert, trägt die äußere NOTIFICATION Subcode 9, während Subcode 2 oder 4 und Text innen liegen. Management, das nur außen protokolliert, verliert die Erklärung. Retained Routes können zugleich auf einen toten Next Hop zeigen; Retention ist kein Forwarding-Beweis.

Der Empfänger regiert seine Reaktion

Der Sender besitzt Schließung und Aussage. Der Empfänger besitzt Log, Redaction, Alarm, Retry und stale Policy. RFC 4486 empfiehlt bei langfristigen Ursachen wie Administrative Shutdown gedämpfte, begrenzte Wiederverbindungen und schließlich manuelle Intervention. In 30 Minuten zurück installiert keinen fremden Timer.

Automation folgt strukturiertem Subcode und lokaler autorisierter Policy. Ein bekanntes Ticket ergänzt Kontext; ein unbekanntes verlangt Prüfung. Falsche Klassifizierung kann endlose Retries oder unnötig lange Unterdrückung erzeugen, auch wenn der Satz plausibel klingt.

Akzeptanz endet erst beim Paket

Vorher werden Schreibberechtigung, Ticketnamespace, Wortschatz, verbotene Daten und Oktettlimit festgelegt. ASCII- und Mehrbyte-Canaries haben bekannte Größe; 255 wird nur mit bewiesener Unterstützung getestet.

Auf dem Draht erfasst man Endpunkte, Zeit, Code, Subcode, Länge, Bytes, Decode und Hard-Reset-Kapselung. Beim Receiver prüft man Rendering, Escaping, Syslog, Telemetrie, Ticketmatch, Retention und Redaction.

Danach folgen Socket, FSM, Retry, N-Bit, Withdrawal oder stale Markierung, Timer, RIB und FIB. Erst gemessener Traffic, Verlust und Recovery schließen den Beweis.

Rollback kann Freitext deaktivieren, auf 128 kürzen, kontrollierte Begriffe oder nur die Ticket-ID nutzen. Der echte Cease-Grund und der Out-of-Band-Datensatz bleiben erhalten.

RFC 9003 erreicht bewusst wenig: Eine sterbende Session hinterlässt einen interoperablen Hinweis. Autorisierung, minimale Offenlegung, Korrelation und Running Code machen daraus belastbare Evidenz. Der Sender darf erklären, nicht aus der Ferne bestimmen.