Zusammenfassung

  • RFC 3315 erlaubte einem DHCPv6-Client, Solicit–Reply statt Solicit–Advertise–Request–Reply anzufordern; der Server konnte diese Abkürzung nach eigener Richtlinie und Konfiguration ablehnen.
  • Bei Rapid Commit legte sich der Server auf die Lease fest, bevor er Reply sendete. Antworten mehrere Server, können sie Adressen festlegen, obwohl der Client nur die Leases eines Servers nutzt; eine verlorene Antwort trennt außerdem den Servereintrag von dem, was den Client erreicht hat.

Die vier Nachrichten enthielten eine Auswahlstufe. Auf Solicit konnten mehrere Server mit Advertise reagieren. Der Client verglich die Angebote, wählte einen Server und schickte Request; Reply bestätigte danach die Zuweisung. RFC 3315, im Juli 2003 als Standards-Track-Dokument veröffentlicht, definierte DHCP für IPv6 und ermöglichte zugleich, diesen Weg unter bestimmten Bedingungen zu verkürzen.

Dafür fügte der Client die leere Option Rapid Commit in Solicit ein. Sie signalisierte: Eine unmittelbare Reply ist willkommen. Sie verpflichtete die Server jedoch nicht. Jeder Server musste weiterhin nach seiner Verwaltungspolitik entscheiden, ob er für eine direkte, bereits festgelegte Zuweisung konfiguriert war. Andernfalls konnte er die Option ignorieren und Advertise senden; der Client blieb dann beim üblichen Auswahlverfahren. Ein Server, der Rapid Commit akzeptierte, legte die Adresse fest, bevor er Reply übermittelte.

Hier verschob sich die Entscheidung. Nach einer gültigen Reply mit Rapid Commit konnte der Client die enthaltene Konfiguration verwenden, ohne Request zu senden. Der Server erhielt jedoch keine spätere Bestätigung, dass die Antwort beim Client angekommen war. RFC 3315 benennt die Folge für mehrere Antwortende: Jeder Server kann eine Adresse festlegen, während der Client nur die Leases eines Servers nutzt. Die Zuweisungen der anderen sind dann festgelegt, aber ungenutzt. Geht Reply auf dem Weg verloren, kann auf dem Server ebenfalls eine Lease stehen, die den Client nie erreicht hat.

Weniger Nachrichten beseitigen die Unsicherheit also nicht; sie verlagern sie. Advertise und Request lassen den Client vor der endgültigen Zuweisung zwischen Servern wählen. Solicit und Reply bringen die Zuweisung voran, können aber den Pool mehrerer unabhängig antwortender Server belasten, bevor klar ist, welche Antwort der Client erhielt und verwendete. Das beweist weder eine Adresskollision noch, dass jede ungenutzte Lease einen Schaden verursacht. Es ist eine im Protokoll vorgesehene Möglichkeit, die den Betrieb betrifft.

RFC 3315 empfiehlt für Dienste mit Solicit–Reply üblicherweise nur einen antwortenden Server und nennt kürzere Anfangslaufzeiten als weitere Möglichkeit, ungenutzte Zuweisungen zu begrenzen. Das sind Architekturmaßnahmen, keine Garantie für eine dauerhaft einzelne Instanz oder synchronisierte Zustände. Rapid Commit lässt sich am klarsten einsetzen, wenn die Auswahl der Antwortenden bewusst kontrolliert wird.

RFC 4039 führte 2005 eine Rapid-Commit-Option für DHCPv4 ein und verwies auf Umgebungen mit hoher Mobilität, in denen sich der Netzzugangspunkt häufig ändert. Zugleich erklärte die Spezifikation den Redundanzvorteil des Vier-Nachrichten-Ablaufs: Angebote bleiben vorläufig, bis der Client eines auswählt. Das ist ein Hinweis auf die Entwicklung des Entwurfs, kein Nachweis allgemeiner Nutzung oder gemessener Startzeitgewinne.

RFC 8415 bündelte DHCPv6 2018; RFC 9915 ersetzte es 2026 und bewahrte die Trennung: Der Client kann beschleunigte Zuweisung anfragen, der Server muss sie nicht annehmen und der Hinweis auf festgelegte, aber ungenutzte Leases bleibt bestehen.

Die Geschichte von Rapid Commit handelt daher nicht nur von Latenz. Entscheidend ist, wann der Server Ressourcen bindet, wie viele Server das tun dürfen und welcher Nachweis beiden Seiten zeigt, dass der Client den Wert tatsächlich empfangen und genutzt hat. Eine eingesparte Runde ist auch eine entfallene Auswahl- und Bestätigungsstufe.

Quellen: RFC 3315, RFC 4039, RFC 8415 und RFC 9915.