Zusammenfassung

  • RFC 1542 verlangt, dass alle BOOTREQUEST-Nachrichten eines Clients an dasselbe Ziel oder denselben Zielsatz weitergeleitet werden.
  • Das Dokument beschreibt einen Relay-Agenten mit Round-Robin-Verteilung: Aufeinanderfolgende Anfragen desselben Clients konnten dadurch bei verschiedenen Servern landen.
  • Eine stabile Zuordnung anhand einer zuverlässigen Client-Kennung kann Last verteilen, ohne den Nachrichtenaustausch eines Clients aufzuteilen.

Ein Broadcast braucht einen Rückweg

BOOTP war für Geräte gedacht, die beim Start weder ihre eigene IP-Adresse noch den zuständigen Bootserver kennen mussten. RFC 951 beschrieb 1985 eine erste Phase zur Adressbestimmung und Auswahl der Bootdatei. Ein Client konnte BOOTREQUEST im lokalen Netz senden. Befand sich der Server in einem anderen Netz, wurde aus diesem begrenzten Broadcast durch gewöhnliches IP-Routing aber nicht automatisch eine Anfrage an den Server.

RFC 951 ermöglichte deshalb das Booten über kooperierende Gateways. Die Weiterleitung war optional und konnte im Gateway oder in einem anderen Agenten auf dem Client-Netz sitzen. Der Agent nahm BOOTREQUEST entgegen, trug bei Bedarf giaddr ein und erhöhte hops. Über giaddr erhielt der Server einen Rückweg zum Client-Netz. Der Mechanismus war skizziert, die Arbeit des Relay-Agenten jedoch noch nicht vollständig festgelegt.

RFC 1532 sollte BOOTP im Oktober 1993 präzisieren. Im selben Monat erschien RFC 1542, aktualisierte RFC 951 und löste RFC 1532 ab, nachdem bei dessen Redaktion Fehler entstanden waren. Die Zusammenfassung nennt das Verhalten von BOOTP-Relay-Agenten ausdrücklich als Klärungsbedarf. Damit wurde der Relay-Agent als Teilnehmer eines mehrteiligen Austauschs behandelt, nicht bloß als eine bequem platzierte Weiterleitungsfunktion.

Die Zuordnung bleibt beim Client

RFC 1542 ließ Betreibern Spielraum bei der Konfiguration. Ein Mechanismus zum Ein- und Ausschalten des Relays war vorgeschrieben; standardmäßig musste es ausgeschaltet sein. Anfragen mit einem hops-Wert über 16 waren zu verwerfen, ein niedrigerer konfigurierbarer Grenzwert sollte möglich sein. War giaddr null, musste der Agent eine Adresse der Empfangsschnittstelle eintragen, hops erhöhen und alle anderen BOOTP-Felder unverändert lassen. Auch die Zieladresse oder Zielmenge wurde konfiguriert.

Eine verbindliche Regel begrenzte diese Freiheit: Alle BOOTREQUEST-Nachrichten, die der Relay-Agent von einem bestimmten Client weiterleitete, mussten an dasselbe Ziel oder denselben Zielsatz gehen. Der erläuternde Text nennt mindestens eine bekannte Implementierung, die Last per Round-Robin verteilte. Jede neue Anfrage ging an den nächsten BOOTP-Server in einer Liste. So konnten zwei aufeinanderfolgende Nachrichten desselben Clients bei verschiedenen Servern ankommen.

Das Problem war nicht die Existenz mehrerer Server. Es war die erneute Auswahl für jedes einzelne Paket, obwohl ein Protokoll mehrere zusammenhängende Anfragen und Antworten verlangen kann. RFC 1542 erklärt, dass dieses Modell mit DHCP und möglicherweise weiteren BOOTP-Varianten schlecht funktioniert, wenn sie mehrere Austausche benötigen. Sieht ein Server den ersten Schritt und ein anderer den nächsten, kann der für die Fortsetzung nötige Kontext auseinanderfallen. Das Dokument beschreibt ein Protokollrisiko, keinen benannten Ausfall und keine Häufigkeit der betreffenden Implementierung.

Der Vorschlag für Lastverteilung ist ebenso eng umrissen. Ein Agent kann die Link-Layer-Adresse des Clients oder ein anderes verlässliches Identifikationsmerkmal hashen und damit ein stabiles Ziel auswählen. Unterschiedliche Clients lassen sich so auf mehrere Server verteilen, während die Nachrichten eines Clients zusammenbleiben. Am einfachsten ist es, alle Anfragen an denselben Zielsatz zu senden. Die Verteilung erfolgt damit pro Client statt pro Paket.

Reichweite der Regel

RFC 1542 garantiert weder, dass Server erreichbar sind, noch dass sie ihren Zustand teilen oder ein Client erfolgreich startet. Die Regel beschränkt allein die Zielwahl des Relay-Agenten für die Anfragen eines Clients. Sie schreibt auch keinen einzelnen Server für alle Clients vor: Ein Zielsatz und eine stabile Zuordnung pro Client bleiben möglich.

RFC 1534 beschrieb ebenfalls im Oktober 1993 die Interoperabilität von BOOTP und DHCP, deren Nachrichten auf dem BOOTP-Format aufbauen. RFC 2131 legte 1997 den DHCP-Ablauf ausführlicher fest: Der Client entdeckt Server, erhält Angebote, wählt einen Server und sendet weitere Anfragen. Das macht den Kontext mehrerer Austausche nachvollziehbar, belegt aber keinen konkreten Produktionsausfall durch das Round-Robin-Beispiel in RFC 1542.

Der RFC Editor führt einen verifizierten Erratum-Eintrag für RFC 1542. In §3.1.1 korrigiert er bei einer Erläuterung zum Broadcast-Flag die Bezeichnung BOOTREPLY zu BOOTREQUEST. Diese Stelle ist von der Zielregel in §4.1.1 getrennt und ändert sie nicht.

Die historische Lehre ist präzise: Clients lassen sich auf mehrere Server verteilen; werden die Pakete desselben Clients abwechselnd zu anderen Servern geschickt, kann ein mehrstufiger Austausch zerfallen. RFC 1542 machte diese Grenze explizit und überließ es dem Netzbetreiber, das Relay einzuschalten und eine stabile Verteilungsstrategie zu wählen.

Quellen