Configuratieprotocols 3: DHCP

Hoe werkt DHCP?
Net zoals bij BOOTP begint het met een client die een broadcast doet. Alleen heet die hier DHCPDISCOVER. Dit dient in eerste instantie om te weten te komen of er DHCP-servers in de buurt zijn en zo ja, welke. Zo’n DHPDISCOVER kan via een router naar andere netwerken gestuurd worden. Alle DHCP-servers die dit DHCPDISCOVER-bericht ontvangen, antwoorden met een DHCPOFFER. Die komen allemaal bij de client en die moet nu één zo’n aanbod uitkiezen.

voorbeeld van een toegewezen DHCP-configuratie

Zo’n aanbod omvat overigens een heel erg tijdelijk ip-adres (geldig voor hooguit een minuut of twee) waarmee de client nu volwaardig van het ip-netwerk gebruik kan maken zodat hij de rest van zijn onderhandelingen probleemloos kan uitvoeren. De client stuurt nu naar de uitgekozen server een DHCPREQUEST (in tegenstelling tot een BOOTPREQUEST is dit dus geen broadcast maar een unicast): "ik wil graag een adres hebben". In feite vraagt een client hier meer dan alleen een adres, hij geeft een volledige waslijst van instellingen op die hij ingevuld wil hebben. Deze instellingen heten de DHCP-opties. De uitgekozen server reageert met een DHCPACK (zoals als een BOOTPREPLY, de ‘ack’ staat voor ‘acknowledgement’ en dat betekent bevestiging) waarin dus het uiteindelijke ip-adres voorkomt samen met een huurtijd (dat is de voorziene duurtijd voor de client om van dit ip-adres gebruik te maken, daarna vervalt deze ‘huur’). Deze huurtijd wordt ingesteld door de netwerkbeheerder en kan enkele minuten, enkele uren of enkele dagen bedragen. Een permanente huur is ook mogelijk: dan reikt de server in feite een statisch adres uit. In dit DHCPACK-antwoord komen ook alle gevraagde opties ingevuld voor: de standaardgateway, één of meerdere dns-serveradressen, indien gewenst het wins-serveradres, en eventueel de adressen van andere servers zoals standaard webserver, ftp-server, mailserver en nog meer.
In de DHCP-standaard werden een aantal vaste opties voorgedefinieerd, maar je kunt ook zelf nog opties definiëren. Als een DHCP-huur (DHCP ‘lease’) vervalt, kan de client de huur vernieuwen zolang het adres vrij blijft en de server geen bezwaar heeft. Een server kan bezwaar hebben als de client vanuit een ander netwerk komt en hernieuwing vraagt van een adres dat helemaal niet in dit netwerk (of tenminste in dit DHCP-park) thuishoort. In zo’n geval krijgt de client van de server geen DHCPACK maar een DHCPNAK (negative acknowledgement of negatieve bevestiging, dat is dus een ontkenning: "nee, je mag dit adres niet gebruiken!". In dat geval moet de client helemaal opnieuw beginnen met DHCPDISCOVER (omdat de tot dan gebruikte DHCP-server immers niet de meest geschikte hoeft te zijn). Als de client bij het hernieuwen van een DHCP-huur vaststelt dat hij de server die hem die huur verstrekt had niet meer kan bereiken, mag hij de DCHPREQUEST zolang de huur nog geldig is uitsturen via een broadcast in plaats van een unicast in de hoop dat een back-up-DHCP-server actief is en de broadcast opvangt. Dan zal die back-upserver de huur vernieuwen.

Als de client echter geen antwoord krijgt (of een DHCPNAK), dan verliest hij zijn huur en moet hij helemaal opnieuw beginnen met DHCPDISCOVER. Dat geldt ook als de client de DHCPREQUEST niet binnen zijn huurtijd kan verzenden. Als de client via DHCPDISCOVER een server kan contacteren en dus een nieuwe huur onderhandelt, betekent dat wel dat aan die nieuwe huur dus een nieuw ip-adres en eventueel ook andere DHCP-opties vasthangen. In zo’n geval zouden uiteraard alle bestaande netwerkverbindingen verbroken worden op het moment dat de huur verviel.