Zusammenfassung

  • RFC 5203 trennt Angebot, Antrag, Autorisierung, Fehler und Widerruf in eigene Nachrichten; eine erfolgreiche Registrierung ist kein Ausführungsbeleg des Dienstes.
  • Die gewährte Laufzeit gehört zu widerrufbarem Soft State. Sie garantiert weder Ressourcenerhalt im angebundenen Dienst noch spätere Paketverarbeitung.
  • Ein belastbarer Status verbindet beide Registrierungszustände mit Dienstquittung, Konfigurationsepoche, tatsächlicher Nutzung und beobachtetem Ergebnis.

Ein Ablaufdatum überlebt seinen Gegenstand

Ein Host erhält eine signierte REG_RESPONSE für einen HIP-Dienst, Laufzeit 120 Sekunden. Das Überwachungssystem berechnet das Ende und zeigt bis dahin Grün.

Nach dreißig Sekunden lädt der angebundene Dienst seine Konfiguration neu und verliert den betreffenden Zustand. Der Registrar bleibt erreichbar und sendet eine Antwort mit Laufzeit null, doch die Nachricht erreicht den Host nicht. Dessen nächste Dienstanfrage scheitert, während die Anzeige weiterläuft.

Das Beispiel ist konstruiert; es behauptet keinen realen Vorfall und kein Produktverhalten. Es zeigt, wie ein korrektes historisches Faktum seinen Gegenstand überdauern kann. Die Registrierung wurde erteilt. Der lokale Timer ist nicht abgelaufen. Der aktuelle Dienstzustand folgt daraus nicht.

Das Problem entsteht nicht durch eine falsche Signatur, sondern durch eine zu breite Frage an eine eng begrenzte Antwort.

Die gemeinsame Schicht endet vor der Dienstausführung

RFC 5203 erschien 2008 als Experimental RFC. Er definiert ein allgemeines HIP-Verfahren zur Registrierung bei Diensten, etwa Rendezvous-Servern oder Middleboxes. Diensterkennung, Suche nach dem Registrar und Interaktion nach der Registrierung liegen ausdrücklich außerhalb des Umfangs.

Diese Grenze erlaubt unterschiedlichen Diensten eigene Voraussetzungen. Sie verhindert zugleich, dass das allgemeine Registrierungsprotokoll eine Ausführung quittiert, die es nie gesehen hat.

Registrierung ist gemeinsamer Zustand bei Antragsteller und Registrar, endlich und per erneuter Registrierung auffrischbar. Der Zustand ermöglicht die Nutzung. Ermöglichung ist weder Inanspruchnahme noch Ergebnis.

Besonders wichtig ist die Formulierung, erfolgreiche Verarbeitung von REG_REQUEST erzeuge Zustand beim Registrar und möglicherweise beim Dienst. Das „möglicherweise“ macht aus zwei Komponenten keine atomare Einheit. Ein Datensatz beim Registrar füllt das Feld des Dienstes nicht automatisch.

Angebot, Wunsch und Entscheidung haben eigene Zeitpunkte

Mit REG_INFO kündigt ein Registrar an, welche Typen er anbieten kann und will. Ist er aufgrund vorübergehender Bedingungen nicht dienstfähig, soll er ein leeres REG_INFO senden. Ändert sich das Angebot, soll ein UPDATE den aktuellen Satz melden.

Die Ankündigung ist damit eine zeitgebundene Aussage, keine Kapazitätsreservierung. Der Antragsteller darf nur angekündigte Typen anfordern, doch zwischen Ankündigung und Nutzung kann der Dienstzustand wechseln.

REG_REQUEST enthält gewünschte Typen und Laufzeit. Der Registrar authentisiert die Host Identity und prüft lokale Richtlinien. REG_RESPONSE nennt genehmigte Typen und gewährte Laufzeit; REG_FAILED nennt nicht abgeschlossene Typen. Im ursprünglichen RFC bedeutet Fehler null zusätzliche Berechtigungsnachweise, Fehler eins Nichtverfügbarkeit des Typs.

Vier Nachrichtentypen in ein Feld service_up zu pressen entfernt Sprecher, Zeitpunkt und Reichweite. Was als Vereinfachung beginnt, endet als nicht untersuchbarer Status.

Laufzeit ist eine Soft-State-Grenze

Die angeforderte und die gewährte Laufzeit müssen nicht übereinstimmen. Selbst innerhalb der angekündigten Grenzen darf der Antragsteller den gewünschten Wert nicht erwarten.

Die gewährte Zeit steuert Erneuerung und Ablauf des Registrierungszustands. Sie ist keine unveränderliche Zusage. Null storniert. Antragsteller, Registrar und angebundener Dienst können vorzeitig beenden. Konfigurationsänderung, Angriff oder Ressourcenknappheit können dazu führen.

Eine ordentliche Historie benötigt Erzeugung, letzte Auffrischung, Konfigurationsepoche, gesendeten Widerruf, empfangenen Widerruf und erwarteten Ablauf. Dienstzustand braucht eine eigene Kennung und Löschursache.

„Kein Widerruf gesehen“ ist keine positive Bestätigung. Die Soll-Anforderung zum Senden garantiert nicht Erzeugung, Transport und Verarbeitung unter allen Fehlern. Schweigen bleibt fehlende Beobachtung.

Kryptografische Stärke erweitert keine Semantik

REG_RESPONSE ist für die Registrierungsfrage starkes Material. HIP schützt die Nachricht; Identität und Richtlinie wurden geprüft. Dieses Gewicht sollte erhalten bleiben.

Eine Signatur schützt jedoch Urheber und Inhalt. Sie fügt dem Inhalt keine Behauptung über Prozessspeicher, Pfad oder Anwendung hinzu. Der Registrar kann wahrheitsgemäß einen Typ gewähren, ohne für dessen späteren Nutzen sprechen zu können.

Gerade robuste Artefakte werden gern wiederverwendet: als Grund, Probes auszulassen, Alarme zu unterdrücken oder Lieferung im Audit abzuhaken. Der Schutz dagegen ist ein enger Metadatensatz aus Principal, Typen, Laufzeit, Policy und Epoche.

Für die nächsten Stufen liefern Dienst, Netz und Anwendung eigene Quittungen. So bleibt jede Signatur wertvoll und zurechenbar.

RFC 8003 verfeinerte Ablehnung, nicht Verfügbarkeit

RFC 8003 löste RFC 5203 im Jahr 2016 ab und brachte die Erweiterung auf den Standards Track. Er präzisierte die Bereitschaft gegenüber einem bestimmten Antragsteller, erweiterte zertifikatsgestützte Autorisierung und fügte unzureichende Ressourcen als Fehler hinzu.

Damit lassen sich fehlende Nachweise, ungültiges Zertifikat, nicht verfügbarer Typ und Ressourcenmangel besser unterscheiden. Die Grundstruktur aus Angebot, Antrag, Antwort, Fehler, Laufzeit und Widerruf bleibt.

Genauere Ablehnungsgründe sind noch keine Ausführungstelemetrie. Ebenso beweist die Veröffentlichung des Nachfolgers keine Migration einer Installation. Spezifikation, Binärstand, aktive Konfiguration und beobachtete Nachricht sind getrennte Belege.

RFC 5203 ist historisch und obsolet zu kennzeichnen. Seine Zuständigkeitsgrenze bleibt dennoch analytisch klar.

Der spezifische Dienst schließt die Beweiskette

Registrierungstypen dürfen zusätzliche HIP-Parameter verlangen. Deren Bedeutung legt die jeweilige Spezifikation fest. Der gemeinsame Mechanismus bleibt klein; lokale Funktionen liefern lokale Beweise.

Bei einem Rendezvous-Dienst könnten gespeicherte Bindung, später empfangenes I1, Weiterleitung und unabhängige Antwort dazugehören. Bei einer Middlebox wären installierte Regel, Match, Policy-Eigentümer, Laufzeit und beobachtete Pakete nötig. Dieselbe allgemeine Antwort kann beides nicht quittieren.

Die Kette lautet:

angeboten → beantragt → genehmigt → Registrar-Zustand → Dienstzustand → genutzt → Ergebnis.

Fehlt die Bestätigung einer Stufe, bleibt sie unbekannt. „Aktiv“ aus der vorherigen Stufe abzuleiten beseitigt nicht die Lücke, sondern versteckt sie.

Ein prüfbarer Datensatz

Ein kompakter Nachweis enthält:

  • HIP- und Erweiterungsversion, Build und Konfiguration;
  • HITs von Antragsteller und Registrar;
  • Fingerabdruck, Typen, Zeit und Laufzeiten aus REG_INFO;
  • Fingerabdruck, Typen und Wunschdauer aus REG_REQUEST;
  • authentisierte Identität, Credential, Policy und Entscheider;
  • REG_RESPONSE oder REG_FAILED, Ergebnis und gewährte Zeit;
  • Zustand beider Seiten, Erzeugung, Refresh und Ablauf;
  • explizite Dienstquittung mit Zustandskennung;
  • Widerruf, Eviction, Neustart und Konfigurationswechsel;
  • dienstspezifischen Vorgang, Pfad und Resultat;
  • ausdrücklich markierte Beobachtungslücken.

Nach einem Neustart darf eine neue Epoche das Grün der alten nicht blind übernehmen. Registrar und Dienst belegen ihren Zustand neu; erst dann aktualisiert die Automation ihr Urteil.

Die Lehre aus RFC 5203 lautet nicht, Registrierung sei wertlos. Sie lautet, dass Registrierung ihren eigenen Gegenstand hat. Wer ihn schützt, kann Verfügbarkeit dort messen, wo sie tatsächlich entsteht.

Quellen