Zusammenfassung

  • RFC 3074 bildete Client-Kennung oder Hardwareadresse auf einen von 256 Werten ab und entschied mit einer gemeinsamen Bucket-Karte, welcher DHCP-Server bedienen sollte.
  • Der Text rechnete zugleich mit nicht verfügbarem oder adresslosem Zuständigen, unbelegten Buckets, falscher Clientzeit und manipulierten Karten. Der Hash belegte Konfiguration, nicht Betriebsfähigkeit.

DHCPDISCOVER wird per Broadcast gesendet. Mehrere Server können es empfangen und beantworten; ein BOOTP-Relay kann dieselbe Vervielfachung an alle Ziele erzeugen. B. Volz, S. Gonczi, T. Lemon und R. Stevens veröffentlichten RFC 3074 im Februar 2001 als Gegenmittel: Nach gemeinsamer Anfangskonfiguration berechnet jeder Teilnehmer selbst dieselbe Serve/Do-not-serve-Entscheidung.

Ausgangspunkt war die Service Transaction ID. Eine vorhandene Client Identifier Option musste verwendet werden; sonst lieferten hlen und höchstens sechzehn Bytes aus chaddr den Schlüssel. Der vorgeschriebene Pearson-Hash ergab 0 bis 255. Eine 32-Oktett-Hash-Bucket-Assignment markierte, welche Werte ein Server bedienen musste.

Das war echte Koordination. Gleiche Eingabe, Mischtabelle und HBA führten ohne laufende Verhandlung zum selben Verantwortlichen. Ein Relay konnte Server-ID/Bucket-Paare für das Weiterleitungsziel nutzen. Bestehende Clients mussten nichts davon wissen.

Die Funktion sah jedoch keinen Livezustand. Sie prüfte weder Prozess, Netzpfad, Lease-Datenabgleich noch geeignete freie Adresse. STID bezeichnete die Transaktion, HBA die administrative Zuständigkeit. Keines war Kapazitätstelemetrie.

RFC 3074 benennt den Unterschied ausdrücklich: Der vorgesehene Server kann nicht verfügbar oder ohne passende Adressen sein. Optionales Delayed Service gestattet einem normalerweise ausgeschlossenen Server nach S Sekunden eine Antwort. Die Rechnung wird nicht widerrufen; nach einer erfolglosen Erstchance ändert sich die zulässige Reaktion.

Auch die Zeitquelle ist unsicher. Ein nichtnuller secs-Wert sollte benutzt werden, doch manche Clients setzen ihn falsch um. Alternativ merkt sich der Server eine abgelehnte Anfrage und misst bis zur Wiederholung mit derselben Transaktions-ID. Das eine ist Clientangabe, das andere eine Verknüpfung zweier Beobachtungen. Beides erklärt nicht allein die Stille des ersten Servers.

Ohne Delayed Service gilt die Karte strikt. Nicht zugewiesene Buckets lassen Transaktionen ganz unbeantwortet; gelegentlich kann das beabsichtigt sein. Abdeckung ist deshalb ein eigener Beleg. Korrekte Software kann korrekt einen Wert berechnen, für den niemand zuständig ist.

Auch Prozente sind keine Momentaufnahme. Kurzfristig kann der reale Anteil von der Konfiguration abweichen und nähert sich erst mit mehr Anfragen. Der Hash misst weder CPU noch Warteschlange, freie Adressen oder Latenz. Er verteilt Kennungen, die ausreichend vielfältig, aber nicht zwingend eindeutig sein müssen.

Konfiguration gehört zum Ausführungspfad. HBAs können aus Datei, Windows-NT-Registry, EEPROM oder vereinbartem Algorithmus stammen und in anderen Nachrichten reisen. Das Verfahren selbst bietet keine Sicherheit. Übertragene Karten müssen gegen Manipulation geschützt werden, weil veränderte Buckets einzelnen oder allen Clients Dienst verweigern können. Identischer Code heilt keine abweichenden oder gemeinsam verfälschten Karten.

RFC 2131 erwartet mehrere Antworten und stellt DHCP unter lokale Verwaltungspolitik. Nach DISCOVER folgen noch OFFER, Auswahl, REQUEST, ACK und tatsächliche Nutzung. RFC 3074 optimiert den ersten Antwortberechtigten, nicht die ganze Kette. RFC 1542 erklärt Relays, beweist aber keine konkrete Implementierung dieses Auswahlverfahrens.

RFC 7031 bezeichnete später abweichende Partnerkonfiguration als häufiges Problem und hielt Load Balancing aus dem DHCPv6-Failover-Kern heraus. Das ist kein rückwirkender Einsatzbericht zu RFC 3074. Es bestätigt nur die sachliche Trennung von Eingangsverteilung, Zustandsabgleich und Fehlerübernahme.

Running-Code Primacy ordnet die Belege: STID-Quelle, Hash, HBA-Abdeckung, Server, Erreichbarkeit, Adresse, verzögerte Übernahme, OFFER, Auswahl, REQUEST, ACK und nutzbare Konfiguration. Reality Layers trennt die symbolische Bestimmtheit eines errechneten Besitzers von ausführbarer Wirkung. Diese späteren Linsen stammen nicht von den RFC-Autoren oder der IETF.

RFC 3074 beantwortete präzise, wer zuerst versuchen sollte. Der geringe Koordinationsaufwand war sein Erfolg. Dass Anwesenheit, Kapazität, Integrität und Ergebnis weiter beobachtet werden mussten, war keine Schwäche der Rechnung, sondern ihre notwendige Grenze.

Quellen