# DHCP ## Hva det er DHCP, Dynamic Host Configuration Protocol, er måten en enhet som nettopp har koblet seg til et nettverk, finner ut hvor den hører hjemme på nettverket. En bærbar PC som kobler seg på et Wi-Fi-nettverk, kjenner sin egen maskinvareadresse og lite annet. DHCP gir den en IP-adresse, nettmasken, ruteren trafikken skal sendes gjennom, og DNS-serverne den skal spørre, uten at noen trenger å taste inn noe. Protokollen er definert i RFC 2131 fra mars 1997, der sammendraget beskriver den som et rammeverk for å overføre konfigurasjonsinformasjon til verter på et TCP/IP-nettverk. Den vokste ut av den eldre Bootstrap Protocol, BOOTP, og det viktigste den la til, var automatisk tildeling av adresser som kan gjenbrukes. RFC 2131 nevner tre måter å dele ut en adresse på. Ved automatisk tildeling får klienten en permanent adresse. Ved dynamisk tildeling får den en adresse for en begrenset periode, eller til den gir den tilbake. Ved manuell tildeling velger nettverksadministratoren adressen, og DHCP leverer den bare. Dynamisk tildeling er den eneste av de tre der en adresse av seg selv går tilbake til poolen når den som hadde den, ikke lenger trenger den, og det er den mekanismen resten av artikkelen handler om. Et slikt tidsbegrenset utlån kalles på fagspråket en lease. Klienten kan forlenge den, levere adressen tilbake før tiden og til og med be om en uendelig lease. RFC-en påpeker at en server likevel kan foretrekke lange, men endelige leaser, slik at den før eller siden oppdager en klient som er tatt ut av drift. Bak serveren ligger det RFC-en kaller vedvarende lagring: én oppføring per klient, med en identifikator som nøkkel og parameterne klienten har fått, som verdi. DHCP går over UDP. Klienter sender til serverens port 67, og servere svarer på klientens port 68. De såkalte options, innstillingene en server kan sende med, fra nettmasken til leasetiden, er spesifisert for seg i RFC 2132. IPv6 har sin egen protokoll, DHCPv6, som nå er spesifisert i RFC 9915, en internettstandard fra januar 2026 som erstattet RFC 8415. Den bruker andre porter, 546 for klienter og 547 for servere og reléagenter, og den kan kjøre enten i stedet for eller ved siden av tilstandsløs autokonfigurasjon av adresser (SLAAC). RFC 9915 kaller selv IPv4-protokollen DHCPv4 når de to må holdes fra hverandre, og den gjengir IETFs konsensus om at IPv4-konfigurasjon skal sendes over DHCPv4 og ikke over DHCPv6. ## Hvorfor det er viktig Hver enhet på et nettverk trenger de samme få innstillingene, og én feil verdi er nok til å kutte den av: en maske som ikke passer til subnettet, en ruteradresse som tilhører noen andre, en DNS-server som ble slått av i fjor. Uten DHCP må hver av disse verdiene tastes inn på hver enhet og holdes riktige hver gang noe endrer seg. Med DHCP bor de på ett sted, og å bytte DNS-server for et helt kontor blir en endring i serverens konfigurasjon i stedet for en runde i bygget. Leasen er det som får protokollen til å skalere. Fordi dynamisk tildeling låner ut adresser for en bestemt tid, kan en pool betjene flere enheter i løpet av en uke enn den har adresser, så lenge de ikke alle er til stede samtidig. RFC 2131 skriver at dynamisk tildeling er særlig nyttig for klienter som bare er tilkoblet midlertidig, og for å dele en begrenset pool mellom klienter som ikke trenger faste adresser. Og fordi en klient bare kan forsvinne, regner ikke protokollen med et farvel: RFC-en slår fast at protokollen fungerer riktig uten at klienten sender en frigivelsesmelding. En adresse kommer tilbake når leasen går ut, enten den som hadde den, sier fra eller ikke. Det gjør leasetiden til et reelt designvalg og ikke en standardverdi man lar stå. En lang lease holder adressene til enheter som for lengst er borte, låst lenger. En kort betyr mer fornyelsestrafikk og mindre tid til å reparere en server som har sluttet å svare, for en klient hvis lease går ut før den når fram til en server, må slutte å bruke adressen sin. DHCP er også et spørsmål om tillit. Det første svaret en enhet godtar, forteller den hvilken ruter all trafikken dens går gjennom, og hvilken DNS-server som oversetter hvert eneste navn den slår opp, så den som styrer det svaret, styrer hvor enheten havner. RFC 2131 legger ikke skjul på det: Avsnittet om sikkerhet kaller protokollen i sin nåværende form ganske usikker, fordi den er bygd direkte på UDP og IP, og fordi maskinene den skulle betjene, er vanskelige å utstyre med passord eller nøkler. Det samme avsnittet påpeker at uautoriserte servere er lette å sette opp og kan dele ut feil eller doble adresser og peke på forfalskede rutere og forfalskede navneservere. Beskyttelsen må komme fra nettverket rundt protokollen, ikke fra protokollen selv. ## Slik ser det ut i praksis Ta en bærbar PC med maskinvareadressen 00-00-5E-00-53-2A som kobler seg på et kontornett, 192.0.2.0/24, der én maskin på 192.0.2.1 er både ruter og DHCP-server. Den bærbare starter uten adresse, så den første meldingen sendes med avsenderadressen 0.0.0.0 som kringkasting til alle på linken. Fire meldinger senere er den konfigurert: ```text bærbar 00-00-5E-00-53-2A server 192.0.2.1 1 DHCPDISCOVER 0.0.0.0 -> 255.255.255.255, serverport 67 er det en server her? 2 DHCPOFFER tilbyr 192.0.2.50 i 86400 s, server-id 192.0.2.1 3 DHCPREQUEST kringkasting: server-id 192.0.2.1, ønsker 192.0.2.50 4 DHCPACK 192.0.2.50 er den bærbares i 86400 s ``` Et hvilket som helst antall servere kan svare på en DHCPDISCOVER, og klienten kan vente og samle inn mer enn ett tilbud. Så velger den ett og kringkaster en DHCPREQUEST som navngir den valgte serveren i optionen server identifier og ber om akkurat den adressen den serveren tilbød. Alle andre servere som ser kringkastingen, tolker den som et avslag på sitt eget tilbud. Den valgte serveren skriver bindingen ned i den vedvarende lagringen sin og bekrefter med en DHCPACK. Den bekreftelsen bærer innstillingene, hver av dem en nummerert option definert i RFC 2132. For den bærbare kunne den inneholde: ```text option 53 meldingstype 5 (DHCPACK) option 54 server-id 192.0.2.1 option 51 leasetid 86400 (sekunder, ett døgn) option 1 nettmaske 255.255.255.0 option 3 ruter 192.0.2.1 option 6 DNS-servere 192.0.2.53 ``` RFC 2132 krever at nettmasken kommer før ruter-optionen når begge er med, og lar en server oppgi flere rutere og flere navneservere i prioritert rekkefølge. Leasetiden og server-id-en er ikke valgfrie: RFC 2131 gjør begge obligatoriske i en DHCPACK som svarer på en DHCPREQUEST. Før den bærbare tar 192.0.2.50 i bruk, bør den sjekke at ingen andre allerede bruker adressen, for eksempel med ARP. Viser adressen seg å være opptatt, må klienten sende DHCPDECLINE og begynne på nytt. Ellers starter tidtakerne. Med mindre serveren sender egne verdier, er T1 halvparten av leasen og T2 sju åttendedeler av den, så med en lease på ett døgn ser det slik ut: ```text t = 0 s DHCPACK mottatt, leasen begynner t = 43200 s T1: RENEWING, unicast DHCPREQUEST til 192.0.2.1 t = 75600 s T2: REBINDING, DHCPREQUEST som kringkasting til alle servere t = 86400 s leasen går ut: slutt å bruke 192.0.2.50, begynn på nytt ``` RFC-en ber om en viss tilfeldig variasjon rundt begge tidtakerne, slik at et rom fullt av bærbare som slås på samtidig, ikke fornyer alle på en gang. Får en forespørsel ikke svar, venter klienten halvparten av den gjenværende tiden før den prøver igjen, men minst 60 sekunder. En frisk klient fornyer ved halvveismerket og kommer aldri i nærheten av slutten av leasen sin. Serveren trenger ikke å stå på subnettet til den bærbare. En ruter kan fungere som reléagent: Den fanger opp kringkastingen og sender den videre til en server et annet sted, og dens egen adresse, som står i giaddr-feltet i meldingen, forteller serveren hvor svaret skal sendes. Det regner RFC 2131 med, og den påpeker at reléagenter fjerner behovet for en DHCP-server på hvert nettverkssegment. Siden vår om [nettverk og VPN-oppsett](/nb/services/networking-vpn/) nevner konfigurering og installasjon av 1 000 Wi-Fi-rutere og administrasjon av nettverksinfrastrukturen for over 1 000 servere. I den skalaen er det ikke aktuelt å taste inn adresser for hånd, og utformingen av pooler, leaser og reléer blir en del av nettverksdesignet. ## Hvor det går galt **En fremmed server svarer først.** En hjemmeruter som er koblet feil vei, en testmaskin som er brokoblet inn på kontornettet, eller en bevisst angriper kan alle svare på en DHCPDISCOVER, og ingenting i protokollen forteller en klient hvilken server som er den ekte. RFC 2131 lister opp hva en slik server kan gjøre: dele ut feil eller doble adresser og sende klienter til en forfalsket ruter eller forfalskede navneservere. Svitsjer kan filtrere dette bort, og RFC 7610 påpeker at en tilsvarende mekanisme for IPv4, DHCP snooping, er mye brukt. Tillat DHCP-servermeldinger bare på svitsjportene som fører til de ekte serverne eller reléagentene deres, og kast dem alle andre steder. **Poolen går tom.** En pool har et fast antall adresser, og dynamisk tildeling får dem bare tilbake når leaser går ut. På et gjestenett der telefoner passerer i hundretall, betyr en lease på en uke at alle gjester fra den siste uken fortsatt har en adresse. RFC 2131 advarer også om at en ondsinnet klient kan legge beslag på alle ressursene og nekte legitime klienter tilgang til dem. Dimensjoner poolen etter antallet enheter som er til stede innenfor én leaseperiode, og kort ned leasen overalt der enheter kommer og går. **Et nytt subnett uten relé.** En DHCPDISCOVER sendes som kringkasting, og kringkastinger stopper ved ruteren. Et nytt VLAN eller en ny kontoretasje uten en konfigurert reléagent får ikke noe svar i det hele tatt. En vert som implementerer RFC 3927, kan da gi seg selv en link-lokal adresse fra 169.254/16, som bare virker på den ene linken, fordi rutere ikke skal videresende pakker til eller fra slike adresser. Konfigurer en reléagent på ruteren i hvert subnett med DHCP-klienter, og les en 169.254-adresse på en klient som et tegn på at ingen server svarte. **To servere som er uenige.** Å kjøre to servere for robusthetens skyld er fornuftig, men RFC 2131 sier at alle servere bør returnere de samme parameterne, bortsett fra selve adressen, slik at klienten oppfører seg forutsigbart uansett hvilket tilbud den tar imot, og gjør nettverksadministratoren ansvarlig for at de svarer likt. To servere med overlappende adresseområder kan dessuten låne ut den samme adressen til to klienter. Gi hver server sitt eget område, hold innstillingene identiske, og sammenlign de to etter hver endring. **Faste adresser inne i poolen.** En skriver som har fått en statisk adresse for hånd fra området DHCP låner ut av, vil før eller siden kollidere med en lease. Protokollen prøver å fange dette opp: En server bør teste en adresse den er i ferd med å gjenbruke, for eksempel med en ICMP echo request, og en klient som oppdager at den nye adressen er opptatt, må avvise den, hvoretter serveren merker adressen som utilgjengelig og bør varsle administratoren. Det er sikkerhetsnett, ikke et design. Hold håndkonfigurerte adresser utenfor poolen, eller bruk manuell tildeling, slik at serveren selv holder reservasjonen. **IPv6 blir oversett.** Å filtrere DHCPv4 gjør ingenting med DHCPv6, som går på andre porter, og som en klient kan starte når en Router Advertisement melder at DHCPv6 er tilgjengelig. RFC 9915 viser til RFC 7610, DHCPv6-Shield, for å demme opp for uautoriserte DHCPv6-servere, og RFC 7610 slår fast at falske Router Advertisements ligger utenfor området dens; dem tar Router Advertisement Guard seg av. Filtrer DHCPv6-servermeldinger på tilgangsportene slik dere filtrerer DHCPv4-meldingene, og kjør RA-Guard ved siden av. ## Les mer - [RFC 2131: Dynamic Host Configuration Protocol](https://www.rfc-editor.org/rfc/rfc2131) — selve protokollen: tildelingsmåtene, leaser, meldingsutvekslingen, tidtakerne T1 og T2 og avsnittet om sikkerhet. - [RFC 2132: DHCP Options and BOOTP Vendor Extensions](https://www.rfc-editor.org/rfc/rfc2132) — alle de nummererte optionene, fra nettmasken og ruterlisten til leasetiden og meldingstypen. - [RFC 9915: Dynamic Host Configuration Protocol for IPv6 (DHCPv6)](https://www.rfc-editor.org/rfc/rfc9915) — IPv6-protokollen, portene og meldingene dens, og hvordan den spiller sammen med SLAAC; den erstatter RFC 8415. - [RFC 7610: DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers](https://www.rfc-editor.org/rfc/rfc7610) — filtrering av servermeldinger på svitsjen, DHCP snooping som forbilde fra IPv4, og hva den overlater til RA-Guard. - [RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses](https://www.rfc-editor.org/rfc/rfc3927) — 169.254/16-adressene en vert kan gi seg selv når ingen server svarer, og hvorfor rutere aldri videresender dem.