Bootstrap-protokol

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 30. maj 2017; checks kræver 5 redigeringer .
BOOTP
Navn Bootstrap-protokol
Niveau (ifølge OSI-modellen ) anvendt
Familie TCP/IP
Oprettet i 1985
Port/ID 67/ UDP (server),
68/UDP (klient) [1]
Formål med protokollen få netværkskonfiguration
Specifikation RFC 951 , RFC 1542

BOOTP (fra den engelske  bootstrap-protokol ) er en applikationslagnetværksprotokol, der bruges til automatisk at opnå en IP-adresse af klienten . Dette sker normalt, mens computeren starter op . BOOTP er defineret i RFC 951 .

BOOTP, ligesom RARP , tillader en speciel server at bestemme klientens IP-adresse ud fra dens MAC -adresse (for eksempel ved opstart af en enhed, der ikke har mulighed for at gemme sin egen IP-adresse), og giver også klienter mulighed for at lære andre boot-parametre (for eksempel navnet på programmet, downloadet via TFTP ) og bruger UDP som transportlagsprotokollen. Dette giver dig mulighed for at bruge routere (bootp-relæ) til at sende anmodninger og svar fra et LAN-segment til et andet. DHCP ( Dynamic Host Configuration Protocol ) er en  tilføjelse til BOOTP (til kompatibilitet med bootp-relæ) og gør det muligt for serveren at tildele IP-adresser til klienter dynamisk i en begrænset periode.

Historie

Vedligeholdelsespersonale i disse (?) år stod over for udfordringerne med konstant at forbinde og flytte nye enheder, såvel som behovet for at ændre netværkskonfigurationen for at opfylde moderne netværkskrav. Alt dette førte til behovet for at skabe en mekanisme til at automatisere konfigurationen af ​​netværksknuder, distribuerede operativsystemer og netværkssoftware. Den mest effektive måde at implementere en sådan mekanisme på kan være at gemme konfigurationsindstillinger og softwarebilleder på en eller flere boot-servere. Under opstart interagerer systemet med en sådan server, modtager indledende konfigurationsparametre fra den og downloader om nødvendigt den nødvendige software fra den.

BOOTP blev introduceret i RFC 951 som en erstatning for den forældede RARP. BOOTP blev oprindeligt udviklet til diskløse arbejdsstationer . Moderne forhold har ført til behovet for at automatisere opstarten af ​​systemer, der kun har grundlæggende værktøjer til IP , UDP og TFTP i ROM. Det originale boot-script så således ud:

BOOTP-meddelelsesformat

Downloadanmodningen og svaret bruger det samme meddelelsesformat. I anmodningen har nogle felter null-værdier.

BOOTP-pakkestruktur [2] :


Segment offset		 Længde,
oktet 		Beskrivelse
0 en Driftskode
_
en en HType
Udstyrstype
2 en HLen
Hardwareadresselængde
3 en Humle
Antal humle
fire fire XID-
transaktions-id
otte 2 Sekunder Sekunder
tæller siden den første anmodning blev sendt af klienten
ti 2 Ikke brugt i RFC 951
Flag  - Flagfelt i RFC 1542
12 fire CIAddr klientens
IP-adresse
16 fire YIAddr Den
IP-adresse, der er givet til klienten af ​​serveren
tyve fire SIAddr-serverens
IP-adresse
24 fire GIAddr
IP-adressen på den mellemliggende router
28 16 CHAddr Client
hardwareadresse
44 64 SName
Server værtsnavn
108 128 Filnavn
på boot-filen
236 64 Vend
Developer Area og avancerede indstillinger

Lad os overveje alle parametrene mere detaljeret.

Operationskode

Opkoden angiver typen af ​​meddelelse:

Udstyrstype

Specificerer typen af ​​netværkshardware, der bruges, ved hjælp af værdier svarende til feltet Hardware Type ( HType , HRD ) i ARP -protokolspecifikationen [3] [4] .

Nogle almindeligt anvendte værdier:

h type Beskrivelse
en Ethernet (10 Mb)
6 IEEE 802 netværk
7 ARCNET
femten ramme relæ
16 Asynkron overførselstilstand (ATM)
atten fiberkanal
tyve seriel linje

Hardwareadresselængde

Angiver længden af ​​hardwareadressen i meddelelsen. For Ethernet-netværk og andre, der bruger IEEE 802 , er værdien af ​​denne parameter 6.

Et lignende felt i ARP-pakken er HLN.

Antal overførsler

Dette segment bruges af relæer til at styre videresendelse af meddelelser. Feltværdien sættes til 0, før den sendes, og øges med 1, når den passerer gennem hvert relæ.

Transaktions-id

Transaktions-id'et er et 32-bit heltal, der indstilles af klienten og returneres af serveren. Det giver klienten mulighed for at matche svaret med anmodningen. Klienten indstiller dette felt til et tilfældigt tal for hver anmodning.

Sekundetæller

Når klienten sender den første downloadanmodning, sættes sekundtællerfeltet til nul. Hvis forespørgslen ikke modtager et svar, efter at timeout er udløbet, sender klienten anmodningen igen og ændrer værdien i sekundtællerfeltet. Til timeout bruger klienten et tilfældigt interval, der stiger op til en værdi på 60 sekunder.

Dette felt har ikke noget særligt formål. Dens indhold kan kontrolleres af serveren eller netværksmonitoren for at bestemme, hvor længe klienten venter på en netværksdownload. Serveren MÅ bruge værdierne i sekundtællerfeltet til at prioritere anmodninger, men dette felt ignoreres i øjeblikket i de fleste implementeringer.

Flag

I den originale RFC 951 blev dette to-byte felt efterladt tomt. Ifølge RFC 1542 bruges den til at sætte flag [5] .

Flagnavn Størrelse, lidt Beskrivelse
B en Broadcast: når den originale besked sendes, kender klienten ikke sin egen IP-adresse, og dette flag er sat til "1". Denne tilstand indikerer til BOOTP-servere og relæer, der modtog pakken, at anmodningen fra denne klient skal udsendes .
Reserveret femten Reserveret og ikke brugt, værdier sat til 0.

Klientens IP-adresse

Hvis klienten allerede kender sin IP-adresse, udfylder den klientens IP-adressefelt. Hvis ikke, sætter klienten denne værdi til 0. I sidstnævnte tilfælde indsætter serveren din IP-adresse i feltet med klientens IP-adresse. Serverens IP-adressefelt udfyldes af serveren. Hvis der bruges en autoritativ server, udfylder den gatewayens IP-adresse.

IP-adressen givet til klienten af ​​serveren

Klienten skal indstille sin klienthardwareadresse. Dette er den samme værdi, som findes i Ethernet-headeren og i UDP-feltet i datagrammet, hvilket gør det tilgængeligt for enhver brugerproces (såsom en BOOTP-server), der har modtaget datagrammet. Det er sædvanligvis vanskeligt eller næsten umuligt for en proces, der håndterer UDP-datagrammer, at bestemme værdien i Ethernet-headerfeltet på det datagram, hvori UDP-datagrammet bæres.

Serverens værtsnavn

Serverens værtsnavn er en streng, der udfyldes af serveren (valgfrit).

Boot filnavn

Serveren kan også udfylde feltet for opstartsfilnavn. Dette felt indeholder den fulde sti til den fil, der bruges ved upload.

Udviklerområde

Oprindeligt blev det leverandørspecifikke område brugt i meddelelser til at sende implementeringsspecifik information. Men i begyndelsen af ​​BOOTP forblev dette område frit, selvom en stor mængde information (for eksempel subnetmasken eller standard routeradressen) ikke formelt var inkluderet i meddelelserne. Udviklerområdet tjente som et sted for yderligere konfigurationsmuligheder samt udviklerspecifik information. Der er en del forskellige felter defineret på dette område.

Portnumre

BOOTP har to forudkendte porte: 67 til serveren og 68 til klienten. Det betyder, at klienten ikke vælger en ubrugt dynamisk tildelt port, men bruger portnummer 68. Grunden til at der blev valgt to portnumre i stedet for kun at bruge et til serveren er, at serveren kan sende et svar (selvom det normalt ikke gør det ) på en udsendt måde.

Hvis svaret fra serveren blev udsendt, og hvis klienten skulle vælge et dynamisk tildelt portnummer, ville disse udsendelser også blive modtaget af andre applikationer på andre værter, der bruger det samme dynamisk tildelte portnummer. Således kan vi konkludere, at det ikke er rationelt at sende en udsendelsesanmodning til et tilfældigt (dynamisk tildelt) portnummer.

Hvis klienten bruger serverens velkendte port (67), vil alle servere på netværket blive tvunget til at lytte til hvert broadcast-svar. (Hvis alle servere blev 'vækket', ville de skulle tjekke op-koden, fastslå, at det var et svar og ikke en anmodning, og 'sove' igen.) Så valget blev truffet på, hvordan det gøres nu, dvs. klienten har sin egen den eneste kendte port, der er forskellig fra serverens kendte port.

Hvis flere klienter downloader på samme tid, og hvis svar fra serveren udbredes af udsendelsesanmodninger, ser hver klient på de svar, der er beregnet til andre klienter. Klienter bruger transaktions-id-feltet i BOOTP-headeren til at matche svaret med anmodningen, eller servere ser på den returnerede klienthardwareadresse.

Se også

Noter

  1. ↑ RFC951 , s. 3: "BOOTP-protokollen bruger to reserverede portnumre, 'BOOTP-klient' (68) og 'BOOTP-server' (67)".
  2. ↑ RFC951 , s. 3-4.
  3. ↑ RFC951 , s. 3: "Hardwareadressetype, se ARP-afsnittet i "Tildelte numre" RFC".
  4. ↑ RFC1700 , Address Resolution Protocol Parameters, s. 163-164.
  5. ↑ RFC1542 , Definition af 'flag'-feltet, s. 5-6: "Dette notat betegner hermed dette to-oktetfelt som 'flag'-feltet."

Links