Zusammenfassung

  • RFC 3679 unterschied rückgewinnbare vorgeschlagene Optionsnummern von PXE- und Apple-Codes, die bereits genutzt wurden, obwohl eine Beschreibung in einem veröffentlichten RFC fehlte.
  • RFC 3942 legte ein Übergangsverfahren für Codes aus dem privaten Bereich fest. Später verlegte RFC 8910 das Captive-Portal-Signal von Code 160 weg, nachdem ein Versuch eine konkurrierende Polycom-Nutzung offengelegt hatte. Ein Register dokumentiert Koordination, keine Vollerhebung eingesetzter Geräte.

Eine leere Bibliografie bedeutete kein leeres Netz

DHCP überträgt bei der Adresskonfiguration kleine Parameter wie Subnetzmaske, Routeradresse oder weitere Dienstinformationen. Optionsnummern bilden einen gemeinsam genutzten Namensraum. Bleibt der Code eines aufgegebenen Vorschlags für immer reserviert, fehlt er späteren Arbeiten. Wird hingegen ein tatsächlich eingesetzter Code neu vergeben, können zwei Geräte dasselbe Feld unterschiedlich interpretieren.

RFC 3679 behandelte im Januar 2004 beide Risiken. Er führte frühere Zuweisungen auf, deren Vorschläge ausgelaufen waren, nie eine veröffentlichte Definition erreicht hatten oder im damaligen Failover-Protokoll nicht mehr verwendet wurden. Diese Codes konnten in den verfügbaren IANA-Pool zurückkehren. Ein anderer Abschnitt hielt jedoch fest, dass die PXE-Optionen 93, 94 und 97 trotz fehlender Veröffentlichung in einem RFC weit verbreitet waren. Ebenso nannte er Apple-Nutzungen der Codes 95 und 112–114 ohne RFC-Dokumentation. Diese Zuweisungen sollten bestehen bleiben, bis die DHC-Arbeitsgruppe über das weitere Vorgehen entschied. Ausschlaggebend war nicht allein die Veröffentlichung, sondern die berichtete Nutzung. RFC 3679

Damit wurde nicht behauptet, jede undokumentierte Nutzung verdiene dauerhaft eine öffentliche Nummer. RFC 3679 nannte die Gründe für die Rückgabe einzeln und behandelte die bekannten PXE- und Apple-Fälle gesondert. Die rückgewinnbaren Codes sollten erst dann in den verfügbaren Pool gelangen, wenn nie vergebene oder zuvor zurückgegebene Nummern ausgeschöpft waren. Das Dokument ist Informational und beweist weder, dass jede genannte Implementierung noch existiert, noch dass alle Zuweisungen in der Praxis geklärt sind. Status von RFC 3679

Von der Liste zum Übergang

Noch 2004 erweiterte RFC 3942 den öffentlich definierten DHCPv4-Optionsraum von 1–127 auf 1–223 und stufte den oberen Bereich um, der zuvor für private Nutzung reserviert war. Bestehende lokale Konfigurationen ließen sich dadurch nicht löschen. Deshalb sah der Standard einen Übergang vor: Ein Code mit bekannter privater Nutzung konnte als nicht verfügbar gelten, während Anbieter die Arbeitsgruppe und die IANA benachrichtigten. Für eine vorläufige öffentliche Zuweisung galt eine sechsmonatige Benachrichtigungsfrist und danach eine Frist von 18 Monaten für einen Internet-Draft. Standorte sollten in den verbleibenden privaten Bereich umnummerieren. RFC 3942

Die Kollisionsregel war strenger. Wenn mehrere Anbieter eine einigermaßen weit verbreitete Nutzung derselben Nummer belegten, durfte keiner sie als eigenen privaten Code behalten; jeder musste eine reguläre öffentliche Zuweisung beantragen. Das erklärte private Nutzung nicht für illegitim. Es erkannte an, dass eine Nummer nicht zwei unvereinbare Bedeutungen koordinieren kann, nur weil jeder Anbieter sie lokal verwendet hat. RFC 3942 verwarf auch eine 16-Bit-Erweiterung, die frühe Anwender belastet hätte, sowie ein neues Format oder Magic Cookie, die Kompatibilitäts- und Erkennungskosten erhöht hätten.

Der spätere Konflikt macht den Unterschied greifbar

RFC 4578 beschrieb später die PXE-Optionen 93, 94 und 97 als weit verbreitet. Zugleich hielt er fest, dass PXE-Clients auch die Codes 128–135 anforderten, die PXE nicht offiziell zugewiesen waren und im selben Netz mit anderen Nutzungen kollidieren konnten. Eine Client-Anfrage macht aus einem Code also noch keine offizielle Zuweisung.

Ein noch deutlicherer Fall entstand bei Captive Portals. RFC 7710 verwendete anfangs DHCPv4-Option 160, um eine Portal-URI bekanntzugeben. Bei einem Netzversuch auf der IETF 106 nutzten manche Polycom-Geräte die 160 für andere Zwecke; mit der Portal-URI in diesem Feld funktionierten sie nicht wie gewünscht. RFC 8910 verlegte das Signal daher auf Option 114, aktualisierte RFC 3679 und gab 160 als „Unassigned“ zurück, wobei die bekannte Polycom-Nutzung vermerkt blieb. Die Autoren beschreiben einen im Versuch beobachteten Konflikt, nicht seine Verbreitung in allen Netzen. RFC 7710 RFC 8910

Das heutige IANA-Register zeigt, was aus einigen Nummern wurde: 83 dient später iSNS, 88 und 89 BCMCS-Optionen, 114 Captive-Portal; 96 bleibt nicht zugewiesen. Auch 126 und 127 sind nicht zugewiesen. Das sind Registerstände, kein Beleg dafür, dass Geräte in aktiven Netzen diese Werte nicht senden. Eine spätere Zuweisung beweist ebenso wenig, dass alle früheren Implementierungen verschwunden sind. IANA-Register BOOTP/DHCP RFC 4174 RFC 4280

Lu Hengs spätere Note 72 bietet einen begrenzten analytischen Vergleich: Ein Koordinierungsregister und die betriebliche Wirklichkeit sind unterschiedliche Belegarten. Die Note behandelt die Eindeutigkeit von Internetnummern, nicht die Zuweisung von DHCP-Optionen; sie hat diese RFC-Entscheidungen weder verursacht noch bestätigt. Die praktische Lehre steht in den DHCP-Dokumenten selbst: Vor der Rückgewinnung einer Nummer muss ihre Nutzung geprüft werden, und eine Neuzuweisung ist ein Übergang, keine redaktionelle Korrektur. Note 72

Quellen

Ergänzende Protokollquellen