Zusammenfassung

  • RFC 2042 reservierte den Typwert 255 für die Entwicklung neuer BGP-Attribute. Für den tatsächlichen Interneteinsatz sollte das Attribut in einem RFC dokumentiert, von IANA mit einem eindeutigen type code versehen und danach in Dokumentation und Codebasis umgestellt werden.
  • Das Dokument lehnt eine Aufteilung des Raums in public/private sowie Internet/OSI ausdrücklich ab. 255 belegt daher weder eine Herstellererweiterung noch Interoperabilität, Deployment, Akzeptanz, Sicherheit, Kompatibilität oder Autorisierung.

Eine schwarze Marke auf mehreren Werkstücken ist brauchbar, solange alle Beteiligten wissen, an welchem Versuchstisch sie stehen. Im öffentlichen Verkehr wäre dieselbe Marke wertlos. Genau diese Grenze macht RFC 2042 sichtbar.

Das Memo erschien im Januar 1997 als Informational RFC. Der RFC Editor führt es heute im Legacy stream; der IETF Datatracker weist darauf hin, dass es nicht vom IETF gebilligt wurde und im IETF-Standardisierungsprozess keinen formalen Rang besitzt. Es dokumentiert einen historischen Koordinationsmechanismus, kein grenzenloses modernes Mandat.

Absichtlich keine eindeutige Kennung

RFC 1771 beschrieb seinerzeit BGP-4 und dessen Pfadattribute. Für ein neues Attribut stellte sich davor eine Entwicklungsfrage: Wie lässt sich das Format testen, ohne sofort eine öffentliche Nummer zu beanspruchen? RFC 2042 reservierte dafür den Oktettwert 255.

Reserviert war der Zweck, nicht der Eigentümer. Zwei unabhängige Prototypen konnten 255 mit völlig verschiedenen Längen, Flags und Nutzdaten verbinden. In einer kontrollierten Umgebung lieferte die lokale Vereinbarung den fehlenden Kontext. In einem isolierten Mitschnitt sagt die Zahl nicht, welche Grammatik folgt.

Diese Mehrdeutigkeit hielt kurzlebige Versuche aus dem öffentlichen Register heraus. Zugleich machte sie 255 als dauerhafte Kennung ungeeignet. Sobald Vorwissen zwischen Sender und Empfänger nicht mehr garantiert war, musste der Versuch die gemeinsame Marke verlassen.

Der geregelte Nummerntausch

Für die tatsächliche Nutzung im Internet verlangte RFC 2042 die Dokumentation in einem RFC und die Zuteilung eines eindeutigen type code durch IANA. Anschließend sollten Dokument und Codebasis auf den autorisierten Wert gebracht werden.

Jeder Schritt trägt eine andere Aussage. Das RFC macht die Semantik nachlesbar. Das Register verhindert einen öffentlichen Nummernkonflikt. Die Codeänderung lässt ein konkretes Programm die neue Kennung senden. Keine dieser Aussagen beweist, dass die anderen umgesetzt sind oder ein fremdes System die Daten korrekt verarbeitet.

Wechselt nur das Dokument, sendet der alte Build weiter 255. Wechselt nur der Sender, können alte Empfänger den rechtmäßig zugeteilten Code ablehnen. Bleiben Paketdissektoren oder Testvektoren zurück, entsteht ein Diagnosefehler. Ein belastbarer Übergang verknüpft daher Registerzeile, Spezifikationsstand, Commit, Build, Tests und beobachtete Ausführung.

RFC 2042 verwirft außerdem ausdrücklich eine Segmentierung in öffentliche und private Abschnitte sowie in Bereiche für Internet, OSI und andere Zwecke. 255 ist damit weder Herstellercode noch Unternehmensbereich. Die Zahl ist eine einzige gemeinsam nutzbare Entwicklungsmarke.

Die heutige Tabelle bestätigt diese Lesart

Im aktuellen IANA-Register BGP Path Attributes steht 255 weiterhin als „Reserved for development“ mit Verweis auf RFC 2042. Einen Private-Use-Bereich enthält diese Tabelle nicht. Andere Register in der Sammlung BGP Parameters können vendor-specific oder private-use Bereiche kennen. Deren Regeln gelten jedoch nur für das jeweils benannte Register.

Wer „255 in BGP“ sagt, ohne die Tabelle zu nennen, entfernt einen Teil der Semantik. Die gleiche Zahl kann in einem anderen BGP-Unterregister einer anderen Vergabepolitik unterliegen. Registername, Zeile, Stand und Referenz gehören deshalb gemeinsam zur Evidenz.

Das heutige Path-Attributes-Register nennt Standards Action als Verfahren und verweist auf RFC 4271, den späteren Standards-Track-Nachfolger von RFC 1771. RFC 8126 erläutert die moderne Terminologie solcher Vergaberegeln. Das beschreibt die Gegenwart, darf aber nicht als Wortlaut von RFC 2042 ins Jahr 1997 zurückprojiziert werden.

Auch eine eindeutige Zuteilung beweist nur Registerstatus. Sie belegt weder Implementierung noch Verbreitung, Interoperabilität, Sicherheit oder betriebliche Freigabe. Ein Register koordiniert Identität; es führt keinen Code aus.

Heng Lus Gedanke der running-code primacy schärft diese Trennung als redaktionelle Perspektive, nicht als IETF-Vorschrift. Dokument und Zuteilung sind institutionelle Tatsachen. Ein Build ist eine ausführbare Tatsache. Deployment und Peer-Verhalten sind betriebliche Tatsachen. Der Schluss darf nicht höher reichen als die beobachtete Schicht.

Das Erratum ändert die Regel nicht

Das offizielle Erratum 3681 korrigiert eine Literaturangabe: Das Dokument über BGP Route Reflection ist RFC 1966, nicht RFC 1998. Es ist als Editorial und Held for Document Update eingestuft. An 255, dem Zuteilungsablauf und der Ablehnung einer public/private-Teilung ändert es nichts.

Der sichtbare Tippfehler im englischen Wort „documentation“ ist nicht Gegenstand dieses Erratums. Die Unterscheidung schützt die Quellenarbeit davor, eine naheliegende Beobachtung als offiziell bestätigte Korrektur auszugeben.

Eine nützliche schwache Identität

255 war nützlich, weil die Zahl wenig versprach. Prototypen durften sich ändern oder verschwinden, ohne das öffentliche Register dauerhaft zu belasten. Diese Freiheit hing jedoch an lokaler Begrenzung, dokumentiertem Versuchskontext und einem klaren Ende.

Der gemeinsame Raum brauchte nur eine kleine deterministische Regel: Öffentliche Attributidentitäten müssen dokumentiert und eindeutig sein. Umsetzung, Einführung und Freigabe blieben nachgelagerte Entscheidungen mit eigener Evidenz.

IANA kann zeigen, welche Nummer öffentlich welches Attribut bezeichnet. Das Register kann nicht zeigen, ob es funktioniert. Und die gemeinsam genutzte 255 konnte allein nicht einmal zeigen, welchen Versuch sie bezeichnete.

Quellen