| DHCP | |
|---|---|
| Navn | Dynamic Host Configuration Protocol |
| Niveau (ifølge OSI-modellen ) | Anvendt [1] |
| Familie | TCP/IP |
| Oprettet i | 1990 |
| Port/ID | 67, 68/ UDP |
| Formål med protokollen | Henter netværkskonfiguration |
| Specifikation | RFC 2131 |
| Vigtigste implementeringer (klienter) | ISC DHCP , Windows -kerne |
| Kerneimplementeringer ( servere ) | dhcpd, ISC DHCP-server, Infoblox |
| Mediefiler på Wikimedia Commons | |
DHCP ( Dynamic Host Configuration Protocol - dynamisk værtskonfigurationsprotokol ) er en applikationsprotokol , der tillader netværksenheder automatisk at opnå en IP - adresse og andre parametre , der er nødvendige for at fungere på et TCP / IP - netværk . Denne protokol fungerer på en klient-server- model . Til automatisk konfiguration får klientcomputeren på netværksenhedens konfigurationstrin adgang til den såkaldte DHCP-server og modtager de nødvendige parametre fra den. Netværksadministratoren kan indstille rækkevidden af adresser, der distribueres af serveren til computere. Dette undgår manuel konfiguration af computere på netværket og reducerer antallet af fejl. DHCP bruges på de fleste TCP/IP-netværk.
DHCP er en udvidelse af BOOTP -protokollen , som tidligere blev brugt til at give diskløse arbejdsstationer IP-adresser, når de starter op. DHCP er bagudkompatibel med BOOTP.
DHCP-protokolstandarden blev vedtaget i oktober 1993 . Den aktuelle version af protokollen (marts 1997 ) er beskrevet i RFC 2131 . Den nye version af DHCP beregnet til brug i et IPv6- miljø kaldes DHCPv6 og er defineret i RFC 3315 (juli 2003 ).
DHCP-protokollen giver tre måder at allokere IP-adresser på :
Nogle implementeringer af DHCP-tjenesten er i stand til automatisk at opdatere de DNS -poster, der svarer til klientcomputere, når nye adresser tildeles dem. Dette gøres ved hjælp af DNS-opdateringsprotokollen beskrevet i RFC 2136 .
Ud over IP-adressen kan DHCP også give klienten yderligere parametre, der er nødvendige for normal netværksdrift. Disse muligheder kaldes DHCP-indstillinger . En liste over standardindstillinger kan findes i RFC 2132 .
Indstillingsfeltet er variabel i længden, men DHCP-klienten skal være forberedt på at acceptere en 576-byte DHCP-meddelelse (indstillingsfeltet i denne meddelelse er 340 byte langt).
Indstillingsfeltet starter med et "magisk tal" - fire bytes med værdierne 99, 130, 83, 99 (0x63, 0x82, 0x53, 0x63 i hexadecimal), hvilket gør det muligt for serveren at bestemme tilstedeværelsen af dette felt.
Hver mulighed er kodet af sekvensen "kode" (én byte), "længde" (en byte), "værdi" - et felt med variabel længde, hvis størrelse er lig med værdien af "længde"-feltet, inklusive nul .
Der er gjort undtagelser for to koder:
| Koden | Længde | Beskrivelse |
|---|---|---|
| 0 | (mangler) | bruges til at udfylde og justere data |
| en | fire | Undernetmaske |
| 2 | fire | Tidszone, signeret nummer, forskudt fra UTC i sekunder. |
| 3 | 4*n | Liste over gateways i præferencerækkefølge. |
| fire | 4*n | Liste Protocol |
| 5 | 4*n | Liste over IEN 116 navneservere. |
| 6 | 4*n | Liste over DNS -servere |
| 7 | 4*n | Liste over logservere (MIT-LCS UDP) |
| otte | 4*n | Liste over cookie-servere ( RFC 865 ) |
| 9 | 4*n | Liste over LPR-servere ( RFC 1179 ) |
| ti | 4*n | Liste over Imagen Impress-servere |
| elleve | 4*n | Liste over ressourceopdagelsesservere ( RFC 887 ) |
| 12 | n | Klientens værtsnavn, streng. |
| 13 | 2 | Størrelse (i 512-oktetblokke) af opstartsbilledet for klienten |
| fjorten | n | Filsti, hvor klienten gemmer dumpet ved nedbrud |
| femten | n | domænenavn |
| 16 | fire | Skift server |
| 17 | n | Rodbiblioteksstien til klienten. |
| atten | n | BOOTP-udvidelsessti |
| 19 | en | Om klienten skal aktivere IP-videresendelse (tager værdien 1 eller 0) |
| tyve | en | Om klienten skal aktivere videresendelse af datagram fra ikke-lokale kilder (indstillet til 1 eller 0) |
| 21 | 8*n | Liste over gyldige netværksadresser og masker for ikke-lokale kilder |
| 22 | en | Maksimal datagramstørrelse (minimumsværdi 576) |
| 23 | en | Standard IP TTL - værdi |
| 24 | fire | Timeout (i sekunder) for at Path MTU-værdier udløber ( RFC 1191 ) |
| 25 | 2*n | Liste over MTU-værdier, når du udfører Path MTU Discovery ( RFC 1191 ) |
| 26 | 2 | MTU-værdi for denne grænseflade (minimumsværdi 68) |
| 27 | en | Marker, at alle undernet bruger den aktuelle MTU-konfiguration (tager værdien 0 eller 1) |
| 28 | fire | Udsendelsesadresse _ |
| 29 | en | Om klienten skal anmode om undernetmasken via ICMP (tager værdien 0 eller 1) |
| tredive | en | Om klienten skal svare på maskeanmodninger via ICMP (tager værdien 0 eller 1) |
| 31 | en | Om klienten skal forespørge routere ved hjælp af RFC 1256- mekanismen (tager værdien 0 eller 1) |
| 32 | fire | Adressen, som klienten skal sende routeranmodninger til |
| 33 | 8*n | En statisk routingliste består af "destinationsadresse" - "routeradresse"-par. |
| 34 | en | Tegn på, om det er tilladt at bruge trailere til ARP-anmodninger (tager værdien 0 eller 1) |
| 35 | fire | ARP cache timeout, i sekunder. |
| 36 | en | Flag for brug af IEEE 802.3-indkapsling ( RFC 1042 ) i stedet for Ethernet Version 2 ( RFC 894 ) (indstillet til 0 eller 1) |
| 37 | en | Standard TTL- værdi for TCP |
| 38 | fire | Tidsinterval (i sekunder) før afsendelse af en Keepalive |
| 39 | en | Om Keepalives skal sendes med en ekstra skraldeoktet (tager værdien 0 eller 1) |
| 40 | n | NIS domænenavn (streng) |
| 41 | 4*n | Liste over NIS-servere |
| 42 | 4*n | Liste over NTP- tidsservere |
| 43 | n | Leverandørspecifikke oplysninger |
| 44 | 4*n | Liste navneservere (NBNS) NetBIOS |
| 45 | 4*n | Liste over NetBIOS datagram distribution (NBDD) servere |
| 46 | en | NetBIOS node type: 0x1 - B-node; 0x2 - P-node; 0x4 - M-node; 0x8 - H-node |
| 47 | n | NetBIOS-området |
| 48 | 4*n | Liste over X Window System Font-servere |
| 49 | 4*n | X Window System Vis adresseliste |
| halvtreds | fire | Anmodet IP-adresse |
| 51 | fire | Lejetid for IP-adresse i sekunder |
| 52 | en | Flag for at bruge felterne 'fil' (1) og 'navn' (2) eller begge (3) for valgmuligheder |
| 53 | en | DHCP-meddelelsestype (1 - DHCPDISCOVER; 2 - DHCPOFFER; 3 - DHCPREQUEST; 4 - DHCPDECLINE; 5 - DHCPACK; 6 - DHCPNAK; 7 - DHCPRELEASE; 8 - DHCPINFORM) |
| 54 | fire | DHCP-server-id |
| 55 | n | Liste over ønskede parametre (hver byte er en parameterkode) |
| 56 | n | SMS-fejl (streng) |
| 57 | 2 | Den maksimale størrelse af en DHCP-meddelelse. Minimumværdi 576 |
| 58 | fire | Tid T1, før opdatering af IP-adressen (i sekunder) |
| 59 | fire | T2 tid før genbinding (i sekunder) |
| 60 | n | Leverandørtype-id (streng) |
| 61 | n | Klient-id (streng) |
| 64 | n | NIS+ domænenavn |
| 65 | 4*n | Liste over NIS+ servere |
| 66 | n | TFTP-servernavn (streng), hvis feltet 'navn' bruges til valgmuligheder |
| 67 | n | Navnet på opstartsfilen (streng), hvis feltet 'fil' bruges til valgmuligheder |
| 68 | 4*n | Mobile IP Home Agent Adresseliste |
| 69 | 4*n | Liste over SMTP- servere |
| 70 | 4*n | Liste over POP3- servere |
| 71 | 4*n | Liste over NNTP- servere |
| 72 | 4*n | Liste over WWW-servere |
| 73 | 4*n | Liste over fingerservere |
| 74 | 4*n | Liste over IRC- servere |
| 75 | 4*n | Liste over StreetTalk-servere |
| 76 | 4*n | StreetTalk Directory Assistance Server List |
| 255 | (mangler) | Slut på valgliste |
Nogle af de mest brugte muligheder er:
Nogle softwareleverandører kan definere deres egne, yderligere DHCP-muligheder.
DHCP-protokollen er klient-server , det vil sige, at en DHCP- klient og en DHCP -server deltager i dens drift . Data overføres ved hjælp af UDP-protokollen . Som standard sendes anmodninger fra klienten til serveren på port 67, serveren svarer igen til klienten på port 68 med en IP-adresse og andre nødvendige oplysninger såsom netmaske, router og DNS-servere.
Alle DHCP-meddelelser er opdelt i felter, som hver indeholder visse oplysninger. Alle undtagen det sidste felt (DHCP-indstillingsfelter) har en fast længde.
| Mark | Beskrivelse | Længde (i bytes ) |
|---|---|---|
| op | Meddelelsestype. For eksempel kan det tage værdierne: BOOTREQUEST (0x01, anmodning fra klienten til serveren) og BOOTREPLY (0x02, svar fra serveren til klienten). | en |
| htype | Hardwareadressetype. Gyldige værdier for dette felt er defineret i RFC 1700 "Tildelte numre". For en Ethernet MAC-adresse er dette felt f.eks. 0x01. | en |
| hlen | Længden af hardwareadressen i bytes. For Ethernet MAC-adressen er den 0x06. | en |
| humle | Antallet af mellemroutere (kaldet DHCP-relæagenter ), som meddelelsen passerede igennem. Klienten indstiller dette felt til 0x00. | en |
| xid | Et unikt 4-byte transaktions-id genereret af klienten i begyndelsen af adresseoptagelsesprocessen. | fire |
| sek | Tiden i sekunder siden starten af adressehentningsprocessen. Må ikke bruges (i så fald er den indstillet til 0x0000). | 2 |
| flag | Feltet for flag er specielle parametre for DHCP-protokollen. | 2 |
| ciaddr | klientens IP-adresse. Kun udfyldt, hvis klienten allerede har sin egen IP-adresse og er i stand til at svare på ARP -anmodninger (dette er muligt, hvis klienten udfører en adressefornyelsesprocedure efter lejekontraktens udløb). | fire |
| yiaddr | Den nye klient IP-adresse foreslået af serveren. | fire |
| siaddr | IP-adressen på den næste server i servicekæden. Serveren KAN returnere sin egen adresse i dette felt. Mulighed 54 bruges til at identificere serveren. | fire |
| giaddr | IP-adressen på relæagenten, hvis en var involveret i leveringen af DHCP-meddelelsen til serveren. | fire |
| chaddr | Hardwareadressen (normalt MAC-adresse ) på klienten. | 16 |
| efternavn | Valgfrit servernavn som en null-termineret streng . | 64 |
| fil | Et valgfrit filnavn på serveren, der bruges af diskløse arbejdsstationer ved fjernopstart. Ligesom sname er den repræsenteret som en null-termineret streng. | 128 |
| muligheder | Feltet DHCP-indstillinger . Forskellige yderligere konfigurationsmuligheder er specificeret her. I begyndelsen af dette felt er fire specielle bytes med værdierne 99, 130, 83, 99 ("magiske tal") angivet, hvilket gør det muligt for serveren at bestemme tilstedeværelsen af dette felt. Feltet er variabel i længden, men DHCP-klienten skal være forberedt på at acceptere en 576-byte DHCP-meddelelse ( indstillingsfeltet i denne meddelelse er 340 byte langt). | variabel |
Lad os se på et eksempel på, hvordan en klient får en IP-adresse fra en DHCP-server. Antag, at klienten endnu ikke har sin egen IP-adresse, men den kender sin tidligere adresse - 192.168.1.100. Processen består af fire trin. Disse stadier forkortes ofte som DORA (Discovery, Offer, Request, and Acknowledgement)
DHCP DiscoveryKlienten udsender først en anmodning til hele det fysiske netværk for at finde tilgængelige DHCP-servere. Den sender en besked af typen DHCPDISCOVER (værdien af indstillingen Message Type er 1), med kilde-IP-adressen 0.0.0.0 (hvis computeren ikke allerede har sin egen IP-adresse), og broadcast-adressen 255.255 som destinationsadressen 255,255.
Klienten udfylder flere meddelelsesfelter med startværdier:
DHCPDISCOVER-meddelelsen kan spredes uden for det lokale fysiske netværk ved at bruge specielt konfigurerede DHCP- relæagenter til at videresende DHCP-meddelelser fra klienter til servere på andre undernet.
Det er ikke altid, at processen med at opnå en IP-adresse starter med DHCPDISCOVER . Hvis klienten tidligere har modtaget en IP-adresse, og dens lejekontrakt endnu ikke er udløbet, kan klienten springe DHCPDISCOVER-stadiet over, begyndende med en DHCPREQUEST- anmodning sendt med identifikatoren for den server, der udstedte adressen sidste gang. Hvis der ikke er noget svar fra den DHCP-server, der udstedte indstillingerne sidste gang, sender klienten en DHCPDISCOVER . Klienten starter således modtageprocessen fra begyndelsen og adresserer alle DHCP-servere i netværkssegmentet.
DHCP-tilbudEfter at have modtaget en besked fra klienten, bestemmer serveren den nødvendige konfiguration af klienten i overensstemmelse med indstillingerne specificeret af netværksadministratoren. I dette tilfælde accepterer DHCP-serveren adressen 192.168.1.100, som klienten anmoder om. Serveren sender den et DHCPOFFER- svar (værdien af indstillingen Message Type er 2), hvori den tilbyder en konfiguration. IP-adressen, der tilbydes til klienten, er angivet i feltet yiaddr . Andre parametre (såsom router- og DNS-serveradresser ) er angivet som muligheder i det tilsvarende felt.
Denne meddelelse sendes af DHCP-serveren til værten, der sendte DHCPDISCOVER på sin MAC, under visse omstændigheder kan meddelelsen udbredes som en udsendelse. En klient kan modtage flere forskellige DHCP-tilbud fra forskellige servere; af dem skal han vælge den, der passer ham.
DHCP-anmodningEfter at have valgt en af de konfigurationer, der tilbydes af DHCP-servere, sender klienten en DHCPREQUEST- anmodning (værdien af indstillingen Message Type er 3). Det udsendes; ud over de muligheder, der er specificeret af klienten i DHCPDISCOVER-meddelelsen, tilføjes en særlig mulighed - server-id'en - der angiver adressen på den DHCP-server, som klienten har valgt (i dette tilfælde 192.168.1.1).
Samme anmodning anvendes, når adresselejekontrakten er ved at udløbe, til at forlænge tiden (fornyelse) eller genbindingsproceduren. I disse tilfælde udelades indstillingerne "server-id" og "anmodet IP-adresse", og ciaddr-feltet udfyldes med den tidligere tildelte klientadresse. Hvis tiden forlænges, sendes anmodningen ikke broadcast, men adresseres til den udstedende server. Kun hvis serveren ikke reagerer inden for den tildelte tid, indledes genbindingsproceduren med udsendelsesanmodninger.
Anmodningen bruges også til initialisering efter at klienten er genstartet (init-reboot), når den allerede kender den tidligere tildelte adresse. I dette tilfælde udføres DHCPDISCOVER ikke, men en DHCPREQUEST-udsendelse sendes øjeblikkeligt uden at angive "server-id", men med en kendt adresse i "anmodet IP-adresse". ciaddr-feltet efterlades tomt.
DHCP-håndtrykTil sidst bekræfter serveren anmodningen og sender en DHCPACK-bekræftelse (meddelelsestype er 5) til klienten. Klienten skal derefter konfigurere sin netværksgrænseflade ved hjælp af de angivne muligheder.
Type meddelelserFølgende er eksempler på værdier for hvert felt for hver af de DHCP-meddelelser, der sendes i processen. I eksemplet anmoder en enhed med en MAC-adresse på 00:1D:60:57:ED:80 en IP-adresse fra en DHCP-server . Klienten sender sin sidst kendte IP-adresse 192.168.1.100 som foreslået
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ud over de meddelelser, der kræves for, at klienten indledningsvis kan opnå en IP-adresse, giver DHCP flere yderligere meddelelser til at udføre andre opgaver.
DHCP-fejlHvis klienten, efter at have modtaget en bekræftelse (DHCPACK) fra serveren, registrerer, at adressen angivet af serveren allerede er i brug på netværket, sender den en DHCPDECLINE afvisningsudsendelsesmeddelelse (værdien af indstillingen Message Type er 4), hvorefter proceduren for at opnå en IP-adresse gentages. Brugen af en IP-adresse af en anden klient kan detekteres ved at udstede en ARP -anmodning .
Annullering af DHCPI situationer, hvor serveren ikke er i stand til at tildele den anmodede adresse til klienten, for eksempel, hvis en ugyldig værdi sendes fra klienten for den "anmodede IP-adresse"-indstilling fra klienten, når en DHCPREQUEST udføres, sender serveren en DHCPNAK- annullering Broadcast-meddelelse (værdien af "Meddelelsestype"-indstillingen er 6). Efter modtagelse af en sådan meddelelse skal den tilsvarende klient gentage adresseoptagelsesproceduren.
Slip DHCPKlienten kan udtrykkeligt opsige IP-adresselejekontrakten. For at gøre dette sender den en DHCPRELEASE-meddelelse (værdien af indstillingen Message Type er 7) til den server, der har lejet adressen til den. I modsætning til andre DHCP-meddelelser udsendes DHCPRELEASE ikke.
DHCP-oplysningerDHCPINFORM- informationsmeddelelsen (værdien af indstillingen Message Type er 8) er beregnet til at bestemme yderligere TCP/IP- parametre (f.eks. adressen på standardrouteren , DNS - servere osv.) for de klienter, der ikke har brug for en dynamisk IP-adresse (dvs. der er en adresse, som er konfigureret manuelt). Servere svarer på en sådan anmodning med en bekræftelsesmeddelelse (DHCPACK) uden at tildele en IP-adresse.
Når der sendes DHCPOFFER- og DHCPACK-meddelelser som svar på en DHCPREQUEST, udfylder serveren værdien af mulighed 51 "Lease Time", en 32-bit værdi, der udtrykker den relative tid i sekunder, som en IP-adresse tildeles til klienten.
Eventuelt rapporterer serveren værdierne af to ekstra tidsintervaller T1 og T2 i henholdsvis valgmuligheder 42 og 43. Hvis disse muligheder ikke er specificeret, så beregner klienten T1 svarende til 1/2 af lejetiden og T2 lig med 7/8 af lejetiden.
Efter T1 går klienten ind i leasing-tidsfornyelsestilstanden (fornyelse) og forsøger at forny leasing af IP-adressen ved at sende en unicast DHCPREQUEST-anmodning til serveren med angivelse af dens adresse i ciaddr- feltet uden at videregive indstillingerne "server-id" " og " anmodede om IP-adresse. Serveren svarer på denne anmodning med en DHCPACK, der angiver det nye lejeinterval i forhold til det aktuelle tidspunkt.
Hvis serveren ikke reagerer, forsøges der igen at sende anmodningen efter halvdelen af den resterende tid indtil T2 , men ikke mindre end 60 sekunder senere.
Kunden kan anmode om en lejeforlængelse allerede inden udløbet af T1-intervallet.
Hvis svaret fra serveren ikke er blevet modtaget efter udløbet af tid T2 , går klienten i genbindingstilstand. I dette tilfælde begynder klienten at udsende lignende DHCPREQUEST-anmodninger, også, om nødvendigt, gentagne forsøg på at sende efter halvdelen af den resterende tid, indtil slutningen af lejekontrakten udløber, men ikke hurtigere end 60 sekunder senere.
Indtil lejekontrakten udløber, selvom T1 og T2 udløber, fortsætter klienten med at bruge den tildelte IP-adresse som hidtil. Men når lejekontrakten udløber, SKAL klienten stoppe netværksaktivitet og forsøge at få en ny adresse, startende med en DHCPDISCOVER-anmodning.
Microsoft inkluderede først en DHCP-server med serverversionen af Windows NT 3.5 udgivet i 1994 . Fra og med Windows 2000 Server tillader Microsofts DHCP-serverimplementering dynamiske opdateringer af DNS -poster , hvilket er det, der bruges i Active Directory .
Internet Systems Consortium udgav den første version af ISC DHCP Server (til Unix -lignende systemer) den 6. december 1997 . Den 22. juni 1999 blev version 2.0 udgivet, som mere matchede standarden.
Cisco inkluderede en DHCP-server i Cisco IOS 12.0 i februar 1999. Sun tilføjede en DHCP-server til Solaris 8 i juli 2001 .
I øjeblikket er der implementeringer af DHCP-serveren til Windows OS i form af separate programmer, inklusive åbne [5] , der tillader computere, der kører ikke-serverversioner af dette OS, at fungere som en DHCP-server.
| Grundlæggende TCP / IP-protokoller efter lag af OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliseret | |
| netværk | |
| Transportere | |
| session | |
| Repræsentation | |
| Anvendt | |
| Andet anvendt | |
| Liste over TCP- og UDP-porte | |