| DHCP | |
|---|---|
| namn | Dynamic Host Configuration Protocol |
| Nivå (enligt OSI-modellen ) | Tillämpad [1] |
| Familj | TCP/IP |
| Skapad i | 1990 |
| Port/ID | 67, 68/ UDP |
| Syftet med protokollet | Hämtar nätverkskonfiguration |
| Specifikation | RFC 2131 |
| Huvudsakliga implementeringar (klienter) | ISC DHCP , Windows -kärnan |
| Kärnimplementationer ( servrar ) | dhcpd, ISC DHCP-server, Infoblox |
| Mediafiler på Wikimedia Commons | |
DHCP ( Dynamic Host Configuration Protocol - dynamiskt värdkonfigurationsprotokoll ) är ett applikationsprotokoll som tillåter nätverksenheter att automatiskt få en IP-adress och andra parametrar som är nödvändiga för att fungera på ett TCP/IP-nätverk . Detta protokoll fungerar på en klient-server- modell . För automatisk konfiguration kommer klientdatorn vid nätverksenhetskonfigurationen åt den så kallade DHCP-servern och tar emot de nödvändiga parametrarna från den. Nätverksadministratören kan ställa in adresser som distribueras av servern till datorer. Detta undviker manuell konfiguration av datorer i nätverket och minskar antalet fel. DHCP används på de flesta TCP/IP-nätverk.
DHCP är en förlängning av BOOTP- protokollet , som tidigare användes för att förse disklösa arbetsstationer med IP-adresser när de startar upp. DHCP är bakåtkompatibelt med BOOTP.
DHCP - protokollstandarden antogs i oktober 1993 . Den aktuella versionen av protokollet (mars 1997 ) beskrivs i RFC 2131 . Den nya versionen av DHCP avsedd för användning i en IPv6- miljö kallas DHCPv6 och definieras i RFC 3315 (juli 2003 ).
DHCP-protokollet ger tre sätt att allokera IP-adresser :
Vissa implementeringar av DHCP-tjänsten kan automatiskt uppdatera DNS- posterna som motsvarar klientdatorerna när nya adresser tilldelas dem. Detta görs med hjälp av DNS-uppdateringsprotokollet som beskrivs i RFC 2136 .
Förutom IP-adressen kan DHCP även förse klienten med ytterligare parametrar som är nödvändiga för normal nätverksdrift. Dessa alternativ kallas DHCP-alternativ . En lista över standardalternativ finns i RFC 2132 .
Alternativfältet varierar i längd, men DHCP-klienten måste vara beredd att acceptera ett 576-byte DHCP-meddelande (alternativfältet i detta meddelande är 340 byte långt).
Alternativfältet börjar med ett "magiskt tal" - fyra byte med värdena 99, 130, 83, 99 (0x63, 0x82, 0x53, 0x63 i hexadecimal), vilket gör att servern kan bestämma närvaron av detta fält.
Varje alternativ kodas av sekvensen "kod" (en byte), "längd" (en byte), "värde" - ett fält med variabel längd, vars storlek är lika med värdet på fältet "längd", inklusive noll .
Undantag görs för två koder:
| Koden | Längd | Beskrivning |
|---|---|---|
| 0 | (saknas) | används för att utfylla och justera data |
| ett | fyra | Subnätmask |
| 2 | fyra | Tidszon, signerat nummer, offset från UTC i sekunder. |
| 3 | 4*n | Lista över gateways, i prioritetsordning. |
| fyra | 4*n | Lista över Protocol |
| 5 | 4*n | Lista över IEN 116-namnservrar. |
| 6 | 4*n | Lista över DNS- servrar |
| 7 | 4*n | Lista över loggservrar (MIT-LCS UDP) |
| åtta | 4*n | Lista över cookie-servrar ( RFC 865 ) |
| 9 | 4*n | Lista över LPR-servrar ( RFC 1179 ) |
| tio | 4*n | Lista över Imagen Impress-servrar |
| elva | 4*n | Lista över resursupptäcktsservrar ( RFC 887 ) |
| 12 | n | Klientens värdnamn, sträng. |
| 13 | 2 | Storlek (i 512-oktettblock) på startavbildningen för klienten |
| fjorton | n | Filsökväg där klienten sparar dumpen vid kraschar |
| femton | n | domän namn |
| 16 | fyra | Byt server |
| 17 | n | Rotkatalogens sökväg för klienten. |
| arton | n | BOOTP-tilläggssökväg |
| 19 | ett | Om klienten ska aktivera IP-vidarebefordran (tar värdet 1 eller 0) |
| tjugo | ett | Om klienten ska aktivera vidarebefordran av datagram från icke-lokala källor (inställd på 1 eller 0) |
| 21 | 8*n | Lista över giltiga nätverksadresser och masker för icke-lokala källor |
| 22 | ett | Maximal datagramstorlek (minsta värde 576) |
| 23 | ett | Standard IP TTL - värde |
| 24 | fyra | Timeout (i sekunder) för Path MTU-värden att löpa ut ( RFC 1191 ) |
| 25 | 2*n | Lista över MTU-värden när du utför Path MTU Discovery ( RFC 1191 ) |
| 26 | 2 | MTU-värde för detta gränssnitt (minsta värde 68) |
| 27 | ett | Flagga att alla undernät använder den aktuella MTU-konfigurationen (tar värdet 0 eller 1) |
| 28 | fyra | Sändningsadress _ |
| 29 | ett | Om klienten ska begära subnätmasken via ICMP (tar värdet 0 eller 1) |
| trettio | ett | Om klienten ska svara på maskförfrågningar via ICMP (tar värdet 0 eller 1) |
| 31 | ett | Om klienten ska fråga routrar med RFC 1256- mekanismen (tar värdet 0 eller 1) |
| 32 | fyra | Adressen som klienten ska skicka routerförfrågningar till |
| 33 | 8*n | En statisk routinglista består av "destinationsadress" - "routeradress"-par. |
| 34 | ett | Tecken på tillåtligheten av att använda trailers för ARP-förfrågningar (tar värdet 0 eller 1) |
| 35 | fyra | ARP-cache-timeout, i sekunder. |
| 36 | ett | Flagga för att använda IEEE 802.3-inkapsling ( RFC 1042 ) istället för Ethernet version 2 ( RFC 894 ) (inställd på 0 eller 1) |
| 37 | ett | Standard TTL- värde för TCP |
| 38 | fyra | Tidsintervall (i sekunder) innan du skickar en Keepalive |
| 39 | ett | Om Keepalives ska skickas med en extra sopoktett (tar värdet 0 eller 1) |
| 40 | n | NIS-domännamn (sträng) |
| 41 | 4*n | Lista över NIS-servrar |
| 42 | 4*n | Lista över NTP- tidsservrar |
| 43 | n | Leverantörsspecifik information |
| 44 | 4*n | Lista namnservrar (NBNS) NetBIOS |
| 45 | 4*n | Lista över NetBIOS-servrar för datagramdistribution (NBDD). |
| 46 | ett | NetBIOS-nodtyp: 0x1 - B-nod; 0x2 - P-nod; 0x4 - M-nod; 0x8 - H-nod |
| 47 | n | NetBIOS-området |
| 48 | 4*n | Lista över X Window System Font Servers |
| 49 | 4*n | X Window System Visa adresslista |
| femtio | fyra | Begärd IP-adress |
| 51 | fyra | IP-adress leasingtid , i sekunder |
| 52 | ett | Flagga för att använda fälten 'fil' (1) och 'namn' (2) eller båda (3) för alternativ |
| 53 | ett | DHCP-meddelandetyp (1 - DHCPDISCOVER; 2 - DHCPOFFER; 3 - DHCPREQUEST; 4 - DHCPDECLINE; 5 - DHCPACK; 6 - DHCPNAK; 7 - DHCPRELEASE; 8 - DHCPINFORM) |
| 54 | fyra | DHCP-server-ID |
| 55 | n | Lista över begärda parametrar (varje byte är en parameterkod) |
| 56 | n | Feltextmeddelande (sträng) |
| 57 | 2 | Den maximala storleken på ett DHCP-meddelande. Minsta värde 576 |
| 58 | fyra | Tid T1, innan IP-adressen uppdateras (i sekunder) |
| 59 | fyra | T2 tid före återbindning (i sekunder) |
| 60 | n | Leverantörstypsidentifierare (sträng) |
| 61 | n | Klient-ID (sträng) |
| 64 | n | NIS+ domännamn |
| 65 | 4*n | Lista över NIS+-servrar |
| 66 | n | TFTP-servernamn (sträng) om fältet 'namn' används för alternativ |
| 67 | n | Namnet på startfilen (strängen) om fältet 'fil' används för alternativ |
| 68 | 4*n | Adresslista för mobil IP-hemagent |
| 69 | 4*n | Lista över SMTP- servrar |
| 70 | 4*n | Lista över POP3- servrar |
| 71 | 4*n | Lista över NNTP- servrar |
| 72 | 4*n | Lista över WWW-servrar |
| 73 | 4*n | Fingerserverlista |
| 74 | 4*n | Lista över IRC- servrar |
| 75 | 4*n | Lista över StreetTalk-servrar |
| 76 | 4*n | StreetTalk Directory Assistance Server List |
| 255 | (saknas) | Slut på alternativlistan |
Några av de mest använda alternativen är:
Vissa programvaruleverantörer kan definiera sina egna, ytterligare DHCP-alternativ.
DHCP-protokollet är klient-server , det vill säga en DHCP- klient och en DHCP -server deltar i dess drift . Data överförs med UDP-protokollet . Som standard görs förfrågningar från klienten till servern på port 67, servern svarar i sin tur på klienten på port 68 med en IP-adress och annan nödvändig information såsom nätmask, router och DNS-servrar.
Alla DHCP-meddelanden är indelade i fält, som vart och ett innehåller viss information. Alla utom det sista fältet (DHCP-alternativfält) har fast längd.
| Fält | Beskrivning | Längd (i byte ) |
|---|---|---|
| op | Meddelandetyp. Till exempel kan det ta värdena: BOOTREQUEST (0x01, begäran från klienten till servern) och BOOTREPLY (0x02, svar från servern till klienten). | ett |
| htype | Maskinvaruadresstyp. Giltiga värden för detta fält är definierade i RFC 1700 "Tilldelade nummer". Till exempel, för en Ethernet MAC-adress är detta fält 0x01. | ett |
| hlen | Längden på hårdvaruadressen i byte. För Ethernet MAC-adressen är den 0x06. | ett |
| humle | Antalet mellanliggande routrar (kallade DHCP-reläagenter ) som meddelandet passerade genom. Klienten ställer in detta fält till 0x00. | ett |
| xid | Ett unikt 4-byte transaktions-ID som genereras av klienten i början av adressinhämtningen. | fyra |
| sek | Tiden i sekunder sedan starten av adressinhämtningen. Får inte användas (i så fall är den inställd på 0x0000). | 2 |
| flaggor | Fältet för flaggor är speciella parametrar för DHCP-protokollet. | 2 |
| ciaddr | klientens IP-adress. Fylls endast i om klienten redan har sin egen IP-adress och kan svara på ARP- förfrågningar (detta är möjligt om klienten utför en adressförnyelseprocedur efter att hyresavtalet löper ut). | fyra |
| yiaddr | Den nya klientens IP-adress som föreslås av servern. | fyra |
| siaddr | IP-adressen för nästa server i tjänstekedjan. Servern KAN returnera sin egen adress i detta fält. Alternativ 54 används för att identifiera servern. | fyra |
| giaddr | IP-adressen för reläagenten, om en sådan var inblandad i leveransen av DHCP-meddelandet till servern. | fyra |
| chaddr | Hårdvaruadressen (vanligtvis MAC-adress ) för klienten. | 16 |
| namn | Valfritt servernamn som en noll-terminerad sträng . | 64 |
| fil | Ett valfritt filnamn på servern som används av disklösa arbetsstationer vid fjärrstart. Liksom sname representeras den som en nollterminerad sträng. | 128 |
| alternativ | DHCP -alternativfält . Olika ytterligare konfigurationsalternativ specificeras här. I början av detta fält indikeras fyra speciella bytes med värdena 99, 130, 83, 99 ("magiska siffror"), vilket gör att servern kan bestämma närvaron av detta fält. Fältet varierar i längd, men DHCP-klienten måste vara beredd att acceptera ett 576-byte DHCP-meddelande ( alternativfältet i detta meddelande är 340 byte långt). | variabel |
Låt oss titta på ett exempel på hur en klient får en IP-adress från en DHCP-server. Anta att klienten ännu inte har sin egen IP-adress, men den känner till sin tidigare adress - 192.168.1.100. Processen består av fyra steg. Dessa stadier förkortas ofta som DORA (Discovery, Offer, Request, and Acknowledgement)
DHCP DiscoveryKlienten sänder först en begäran till hela det fysiska nätverket för att upptäcka tillgängliga DHCP-servrar. Den skickar ett meddelande av typen DHCPDISCOVER (värdet för alternativet Message Type är 1), med källans IP-adress 0.0.0.0 (om datorn inte redan har sin egen IP-adress) och sändningsadressen 255.255 som destinationsadress 255,255.
Klienten fyller flera meddelandefält med initiala värden:
DHCPDISCOVER-meddelandet kan spridas utanför det lokala fysiska nätverket genom att använda speciellt konfigurerade DHCP-reläagenter för att vidarebefordra DHCP-meddelanden från klienter till servrar på andra undernät.
Processen att erhålla en IP-adress börjar inte alltid med DHCPDISCOVER . Om klienten tidigare har fått en IP-adress och dess hyresavtal ännu inte har löpt ut, kan klienten hoppa över DHCPDISCOVER-steget, med början med en DHCPREQUEST- förfrågan som skickas med identifieraren för servern som utfärdade adressen senast. Om det inte finns något svar från DHCP-servern som utfärdade inställningarna förra gången, skickar klienten en DHCPDISCOVER . Således startar klienten mottagningsprocessen från början och adresserar alla DHCP-servrar i nätverkssegmentet.
DHCP-erbjudandeEfter att ha tagit emot ett meddelande från klienten bestämmer servern den nödvändiga konfigurationen av klienten i enlighet med inställningarna som specificerats av nätverksadministratören. I detta fall accepterar DHCP-servern adressen 192.168.1.100 som begärts av klienten. Servern skickar ett DHCPOFFER- svar (värdet för alternativet Message Type är 2), där den erbjuder en konfiguration. IP-adressen som erbjuds klienten anges i fältet yiaddr . Andra parametrar (som router- och DNS-serveradresser ) anges som alternativ i motsvarande fält.
Detta meddelande skickas av DHCP-servern till värden som skickade DHCPDISCOVER på sin MAC, under vissa omständigheter kan meddelandet spridas som en broadcast. En klient kan få flera olika DHCP-erbjudanden från olika servrar; av dem måste han välja den som passar honom.
DHCP-förfråganEfter att ha valt en av konfigurationerna som erbjuds av DHCP-servrar, skickar klienten en DHCPREQUEST- begäran (värdet för alternativet Message Type är 3). Det sänds; utöver de alternativ som anges av klienten i DHCPDISCOVER-meddelandet, läggs ett speciellt alternativ till - serveridentifieraren - som anger adressen till DHCP-servern som valts av klienten (i detta fall 192.168.1.1).
Samma begäran används när adresshyresavtalet är på väg att löpa ut, för att förlänga tiden (förnya) eller återbindningsförfarandet. I dessa fall utelämnas alternativen "server-id" och "begärd IP-adress", och ciaddr-fältet fylls i med den tidigare tilldelade klientadressen. Om tiden förlängs skickas begäran inte utsänd, utan adresserad till den utfärdande servern. Endast om servern inte svarar inom den tilldelade tiden initieras återbindningsproceduren med sändningsförfrågningar.
Begäran används också för initiering efter att klienten har startat om (init-reboot), när den redan känner till den tidigare tilldelade adressen. I det här fallet exekveras inte DHCPDISCOVER, utan en DHCPREQUEST-sändning skickas omedelbart utan att ange alternativet "server-ID", men med en känd adress i alternativet "begärd IP-adress". ciaddr-fältet lämnas tomt.
DHCP-handslagSlutligen bekräftar servern begäran och skickar en DHCPACK-bekräftelse (meddelandetyp är 5) till klienten. Klienten måste sedan konfigurera sitt nätverksgränssnitt med hjälp av de tillhandahållna alternativen.
Typ av meddelandenFöljande är exempel på värden för varje fält för vart och ett av de DHCP-meddelanden som skickas i processen. I exemplet begär en enhet med en MAC-adress på 00:1D:60:57:ED:80 en IP-adress från en DHCP-server . Klienten skickar sin senast kända IP-adress 192.168.1.100 som ett förslag
|
DHCP Discovery DHCPDISCOVER
|
DHCP erbjuder DHCPOFFER
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
DHCP-förfrågan DHCPREQUEST
|
DHCP -bekräftelse DHCPACK
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Utöver de meddelanden som krävs för att klienten initialt ska få en IP-adress, tillhandahåller DHCP flera ytterligare meddelanden för att utföra andra uppgifter.
DHCP-felOm klienten, efter att ha mottagit en bekräftelse (DHCPACK) från servern, upptäcker att adressen som specificerats av servern redan används i nätverket, skickar den ett DHCPDECLINE-avslagsmeddelande (värdet på alternativet Meddelandetyp är 4), varefter proceduren för att erhålla en IP-adress upprepas. Användningen av en IP - adress av en annan klient kan upptäckas genom att utfärda en ARP - begäran .
Avbrytande av DHCPI situationer där servern inte kan tilldela den begärda adressen till klienten, till exempel, om ett ogiltigt värde skickas från klienten för alternativet "begärd IP-adress" från klienten när en DHCPREQUEST körs, skickar servern en DHCPNAK Cancel Broadcast-meddelande (värdet för alternativet "Meddelandetyp" är 6). Efter mottagandet av ett sådant meddelande måste motsvarande klient upprepa adressinhämtningsproceduren.
Släpp DHCPKunden kan uttryckligen säga upp IP-adressleasingavtalet. För att göra detta skickar den ett DHCPRELEASE-meddelande (värdet för alternativet Message Type är 7) till servern som hyrde adressen till den. Till skillnad från andra DHCP-meddelanden sänds inte DHCPRELEASE.
DHCP-informationInformationsmeddelandet DHCPINFORM (värdet på alternativet Message Type är 8) är avsett att bestämma ytterligare TCP/IP- parametrar (till exempel adressen till standardroutern , DNS- servrar, etc.) för de klienter som inte behöver en dynamisk IP-adress (det vill säga det finns en adress som konfigureras manuellt). Servrar svarar på en sådan begäran med ett bekräftelsemeddelande (DHCPACK) utan att tilldela en IP-adress.
När DHCPOFFER- och DHCPACK-meddelanden skickas som svar på en DHCPREQUEST, fyller servern i värdet för alternativ 51 "Lease Time", ett 32-bitars värde som uttrycker den relativa tiden i sekunder för vilken en IP-adress tilldelas klienten.
Alternativt rapporterar servern värdena för två ytterligare tidsintervall T1 och T2 i alternativ 42 respektive 43. Om dessa alternativ inte är specificerade, beräknar klienten T1 lika med 1/2 av leasingtiden och T2 lika med 7/8 av leasingtiden.
Efter T1 går klienten in i tillståndet för förnyelse av hyrestiden (förnyar) och försöker förnya uthyrningen av IP-adressen genom att skicka en unicast DHCPREQUEST-begäran till servern, med angivande av dess adress i ciaddr- fältet , utan att skicka alternativen "serveridentifierare " och " begärde IP-adressen. Servern svarar på denna begäran med ett DHCPACK som indikerar det nya leasingintervallet i förhållande till den aktuella tiden.
Om servern inte svarar görs försök att skicka begäran igen efter halva tiden som återstår till T2 , men inte mindre än 60 sekunder senare.
Kunden kan begära en förlängning av hyresavtalet redan innan T1-intervallet löper ut.
Om svaret från servern inte har mottagits efter utgången av tiden T2 , går klienten in i återbindningstillståndet. I det här fallet börjar klienten sända liknande DHCPREQUEST-förfrågningar, även, om nödvändigt, upprepade försök att skicka efter halva tiden som återstår tills slutet av hyresavtalet löper ut, men inte snabbare än 60 sekunder senare.
Tills hyresavtalet löper ut, även om T1 och T2 löper ut, fortsätter klienten att använda den tilldelade IP-adressen som tidigare. Men när hyresavtalet löper ut, MÅSTE klienten stoppa nätverksaktivitet och försöka få en ny adress, som börjar med en DHCPDISCOVER-begäran.
Microsoft inkluderade först en DHCP-server med serverversionen av Windows NT 3.5 som släpptes 1994 . Från och med Windows 2000 Server tillåter Microsofts DHCP-serverimplementering dynamiska uppdateringar av DNS- poster , vilket är det som används i Active Directory .
Internet Systems Consortium släppte den första versionen av ISC DHCP Server (för Unix -liknande system) den 6 december 1997 . Den 22 juni 1999 släpptes version 2.0, som bättre matchade standarden.
Cisco inkluderade en DHCP-server i Cisco IOS 12.0 i februari 1999. Sun lade till en DHCP-server till Solaris 8 i juli 2001 .
För närvarande finns det implementeringar av DHCP-servern för Windows OS i form av separata program, inklusive öppna [5] , som tillåter datorer som kör icke-serverversioner av detta OS att fungera som en DHCP-server.
| Grundläggande TCP / IP-protokoll efter lager av OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliserad | |
| nätverk | |
| Transport | |
| session | |
| Representation | |
| Applicerad | |
| Annat ansökt | |
| Lista över TCP- och UDP-portar | |