Zusammenfassung

  • RFC 3091 wies einen Multicast-Anbieter an, π-Ziffern an die Gruppe 314.159.265.359 zu senden – das ist keine gültige IPv4-Multicastadresse.
  • Auch die TCP- und UDP-Ports 314159 und 220007 überschreiten das 16-Bit-Feld der Transportprotokolle; in der angegebenen Form konnten diese Zahlen nicht im Paket stehen.

Vom Zweck her wirkt die Idee zunächst unkompliziert: Ein Arbeitsplatzrechner ohne lokale π-Berechnung verbindet sich mit einem Server und empfängt Ziffern, fragt eine bestimmte Position ab oder hört eine Multicast-Sendung mit, aus der sich über die Zeit ein konsistenter Wert bilden soll. RFC 3091 beschreibt drei verschiedene Austauschformen. Jede setzt jedoch voraus, dass das Ziel überhaupt in die Adressfelder passt, die das Netz tatsächlich überträgt.

Am deutlichsten zeigt sich der Widerspruch beim Multicast. RFC 3091 nennt 314.159.265.359 als Gruppe. Eine IPv4-Adresse in Punkt-Dezimal-Schreibweise besteht aus vier Oktetten mit Werten zwischen 0 und 255. RFC 1112 legt IPv4-Hostgruppen in den Bereich 224.0.0.0 bis 239.255.255.255. Die RFC-Zeichenfolge hat fünf Komponenten, und schon die erste ist größer als 255. Es handelt sich nicht um eine gültige, lediglich noch nicht zugewiesene Multicastgruppe. Die Zeichenfolge bezeichnet überhaupt keine IPv4-Adresse; ein Host kann der wörtlich angegebenen Gruppe nicht beitreten.

Bei den Ports tritt derselbe Fehler auf. RFC 793 definiert TCP-Quell- und Zielports jeweils als 16-Bit-Felder; RFC 768 tut das für UDP ebenso. Der größte vorzeichenlose Wert ist 65.535. Trotzdem verlangt der verpflichtende TCP-Dienst in RFC 3091 Port 314159, und auch der optionale UDP-Dienst verwendet diese Zahl. Für Näherungsdienste zu 22/7 ist Port 220007 vorgesehen. Keine dieser Zahlen lässt sich als TCP- oder UDP-Port kodieren. Die in RFC 6335 beschriebenen IANA-Zuteilungsbereiche ordnen Werte innerhalb des darstellbaren Feldes; eine Registrierung kann dessen Breite nicht vergrößern.

Das ist mehr als eine kleine Zahlenspielerei. Die TCP-Variante sollte Ziffern liefern, bis der Client die Verbindung schließt. Bei UDP fragt der Client die n-te Stelle ab und erhält eine Antwort mit Index. Multicast verzichtet auf eine Anfrage: Ein Anbieter wartet dreißig Sekunden, ohne einen anderen Anbieter zu entdecken, und sendet dann eine zufällige Ziffernverteilung, die Clients mit der Zeit zusammensetzen sollen. Der Text entwirft einen Stream, eine Abfrage und eine verteilte Sammlung – aber in jedem Zweig ist der erste Schritt der Zugriff auf ein Ziel, das die Transport- oder Netzwerkschicht nicht darstellen kann.

Das Dokument trägt das Datum 1. April 2001 und die Kategorie Informational. Der IETF Datatracker führt es als Independent Submission und stellt ausdrücklich fest, dass es weder vom IETF gebilligt wird noch formellen Status im IETF-Standardisierungsprozess hat. Zusammen mit dem Datum, den nicht kodierbaren Konstanten und der Warnung, das Internet stehe ohne vertrauenswürdige PIgen-Server vor dem unmittelbar bevorstehenden Kollaps, liest sich der Text eindeutig wie ein Scherz. Das ist eine starke Kontextdeutung, aber kein unabhängiger Beleg für die private Absicht des Autors.

Sicher feststellbar ist nur: Ein RFC-artig veröffentlichtes Dokument beschrieb Dienste mit Zielen, die sich in den aufgerufenen Protokollen nicht ausdrücken lassen.

Auch eine RFC-Nummer belegt keine Implementierung. Der Veröffentlichungsdatensatz hält fest, was geschrieben wurde und über welchen Strom es erschien. Er beweist nicht, dass ein Host am angegebenen Port lauschte, die Multicastgruppe existierte, ein Betreiber die Konstanten für einen Einsatz korrigierte oder Clients π in einem echten Netz rekonstruierten. Hinweise auf Berechnungsmethoden und DNS-SRV-Dienstsuche verleihen dem Entwurf technische Details, lösen aber das Feldbreitenproblem nicht. SRV kann einen Port bekannt geben; das Transportprotokoll muss diesen Wert trotzdem tragen können.

RFC 3091 bietet damit eine kleine, konkrete Lektion aus der Internetgeschichte: Ein flüssig formulierter Entwurf kann an der Grenze zwischen einem Namen und seiner Darstellung auf dem Draht scheitern. Eine Zahl wird nicht deshalb zu einem Netzbezeichner, weil sie an π erinnert; eine Adresszeichenfolge wird nicht gültig, weil sie wie Dezimalziffern aussieht. Bevor Dienstsuche, Lastverteilung oder die Zusammenführung bei Empfängern diskutiert werden, muss zuerst feststehen, dass die verfügbaren Bits das Ziel überhaupt kodieren können.

Quellen