Bootstrap-protokoll

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 30 maj 2017; kontroller kräver 5 redigeringar .
BOOTP
namn Bootstrap-protokoll
Nivå (enligt OSI-modellen ) applicerad
Familj TCP/IP
Skapad i 1985
Port/ID 67/ UDP (server),
68/UDP (klient) [1]
Syftet med protokollet få nätverkskonfiguration
Specifikation RFC 951 , RFC 1542

BOOTP (från det engelska  bootstrap-protokollet ) är ett nätverksprotokoll för applikationslager som används för att automatiskt få en IP-adress av klienten . Detta händer vanligtvis medan datorn startar upp . BOOTP definieras i RFC 951 .

BOOTP, som RARP , tillåter en speciell server att bestämma klientens IP-adress från dess MAC- adress (till exempel vid uppstart av en enhet som inte har möjlighet att lagra sin egen IP-adress), och låter även klienter lära sig andra startparametrar (till exempel namnet på programmet, nedladdat via TFTP ) och använder UDP som transportlagerprotokoll. Detta gör att du kan använda routrar (bootp relay) för att skicka förfrågningar och svar från ett LAN-segment till ett annat. DHCP ( Dynamic Host Configuration Protocol ) är ett  tillägg för BOOTP (för kompatibilitet med bootp-relä) och låter servern tilldela IP-adresser till klienter dynamiskt under en begränsad period.

Historik

Underhållspersonal från dessa (?) år stod inför utmaningarna att ständigt ansluta och flytta nya enheter, samt behovet av att ändra nätverkskonfigurationen för att möta moderna nätverkskrav. Allt detta ledde till behovet av att skapa en mekanism för att automatisera konfigurationen av nätverksnoder, distribuerade operativsystem och nätverksprogramvara. Det mest effektiva sättet att implementera en sådan mekanism kan vara att lagra konfigurationsinställningar och programvarubilder på en eller flera startservrar. Under uppstart interagerar systemet med en sådan server, tar emot initiala konfigurationsparametrar från den och, om nödvändigt, laddar ner nödvändig programvara från den.

BOOTP introducerades i RFC 951 som en ersättning för den föråldrade RARP. BOOTP utvecklades ursprungligen för disklösa arbetsstationer . Moderna förhållanden har lett till behovet av att automatisera uppstarten av system som endast har grundläggande verktyg för IP , UDP och TFTP i ROM. Det ursprungliga startskriptet såg ut så här:

BOOTP-meddelandeformat

Nedladdningsbegäran och svaret använder samma meddelandeformat. I begäran har vissa fält nollvärden.

BOOTP-paketstruktur [2] :

Segmentoffset
_ 		Längd,
oktett 		Beskrivning
0 ett Operationskod
_
ett ett HType
Utrustningstyp
2 ett Hlen
Hårdvaruadresslängd
3 ett Humle
Antal humle
fyra fyra XID
Transaktions-ID
åtta 2 Sekunder Sekunder
räknare sedan den första begäran skickades av klienten
tio 2 Används inte i RFC 951
Flags  - Flags-fält i RFC 1542
12 fyra CIAddr klientens
IP-adress
16 fyra YIAddr
IP-adressen som servern tillhandahåller klienten
tjugo fyra SIAddr-serverns
IP-adress
24 fyra GIAddr
IP-adress för den mellanliggande routern
28 16 CHAddr Client
hårdvaruadress
44 64 SName
Server värdnamn
108 128 Filnamn
på startfilen
236 64 Vend
Developer Area och avancerade alternativ

Låt oss överväga alla parametrar mer i detalj.

Operationskod

Op-koden anger typen av meddelande:

Utrustningstyp

Anger typen av nätverkshårdvara som används, med värden som liknar fältet Hardware Type ( HType , HRD ) i ARP - protokollspecifikationen [3] [4] .

Några vanliga värden:

h typ Beskrivning
ett Ethernet (10 Mb)
6 IEEE 802-nätverk
7 ARCNET
femton ramrelä
16 Asynkront överföringsläge (ATM)
arton fiberkanal
tjugo seriell linje

Maskinvaruadresslängd

Anger längden på hårdvaruadressen i meddelandet. För Ethernet-nätverk och andra som använder IEEE 802 är värdet på denna parameter 6.

Ett liknande fält i ARP-paketet är HLN.

Antal överföringar

Detta segment används av reläer för att styra vidarebefordran av meddelanden. Fältvärdet sätts till 0 innan det skickas och ökas med 1 när det passerar genom varje relä.

Transaktions-ID

Transaktions-ID:t är ett 32-bitars heltal som ställs in av klienten och returneras av servern. Det låter klienten matcha svaret med begäran. Klienten ställer in detta fält till ett slumptal för varje begäran.

Sekunderräknare

När klienten skickar den första nedladdningsbegäran, sätts sekundräknarfältet till noll. Om förfrågan inte får något svar, efter att timeout löpt ut, skickar klienten förfrågan igen, vilket ändrar värdet i sekundräknarfältet. För timeout använder klienten ett slumpmässigt intervall som ökar upp till ett värde på 60 sekunder.

Detta fält har inget speciellt syfte. Dess innehåll kan kontrolleras av servern eller nätverksmonitorn för att avgöra hur länge klienten väntar på en nätverksnedladdning. Servern KAN använda värdena i sekundräknarfältet för att prioritera förfrågningar, men detta fält ignoreras för närvarande i de flesta implementeringar.

Flaggor

I den ursprungliga RFC 951 lämnades detta tvåbytefält tomt. Enligt RFC 1542 används den för att sätta flaggor [5] .

Flaggans namn Storlek, lite Beskrivning
B ett Broadcast: när det ursprungliga meddelandet skickas känner inte klienten till sin egen IP-adress, och denna flagga är inställd på "1". Detta tillstånd indikerar för BOOTP-servrarna och reläerna som tog emot paketet att begäran från den här klienten ska sändas .
Reserverad femton Reserverad och ej använd, värden satt till 0.

Klientens IP-adress

Om klienten redan känner till sin IP-adress, fyller den i klientens IP-adressfält. Om inte sätter klienten detta värde till 0. I det senare fallet infogar servern din IP-adress i fältet med klientens IP-adress. Serverns IP-adressfält fylls i av servern. Om en auktoritativ server används fyller den i gatewayens IP-adress.

IP-adressen som tillhandahålls till klienten av servern

Klienten måste ställa in sin klientmaskinvaruadress. Detta är samma värde som finns i Ethernet-huvudet och i UDP-fältet i datagrammet, vilket gör det tillgängligt för alla användarprocesser (som en BOOTP-server) som har tagit emot datagrammet. Det är vanligtvis svårt eller nästan omöjligt för en process som hanterar UDP-datagram att bestämma värdet i Ethernet-huvudfältet för det datagram i vilket UDP-datagrammet skickas.

Serverns värdnamn

Serverns värdnamn är en sträng som fylls i av servern (valfritt).

Startfilens namn

Servern kan också fylla i fältet för startfilnamn. Detta fält innehåller den fullständiga sökvägen till filen som används vid uppladdning.

Utvecklarområde

Ursprungligen användes det leverantörsspecifika området i meddelanden för att skicka implementeringsspecifik information. Men i början av BOOTP förblev detta område fritt, även om en stor mängd information (till exempel subnätmasken eller standardrouteradressen) inte formellt inkluderades i meddelandena. Utvecklarområdet fungerade som en plats för ytterligare konfigurationsalternativ samt utvecklarspecifik information. Det finns en hel del olika områden definierade inom detta område.

Portnummer

BOOTP har två förkända portar: 67 för servern och 68 för klienten. Det innebär att klienten inte väljer en oanvänd dynamiskt tilldelad port utan använder portnummer 68. Anledningen till att två portnummer valdes istället för att endast använda ett för servern är att servern kan skicka ett svar (även om det vanligtvis inte gör det ) på ett sändningssätt.

Om svaret från servern sändes ut och om klienten behövde välja ett dynamiskt tilldelat portnummer, skulle dessa sändningar också tas emot av andra applikationer på andra värdar som använder samma dynamiskt tilldelade portnummer. Således kan vi dra slutsatsen att det inte är rationellt att skicka en sändningsförfrågan till ett slumpmässigt (dynamiskt tilldelat) portnummer.

Om klienten använder serverns välkända port (67), kommer alla servrar i nätverket att tvingas lyssna på varje sändningssvar. (Om alla servrar "väcktes" skulle de behöva kontrollera op-koden, fastställa att det var ett svar och inte en förfrågan och "sova" igen.) Så valet gjordes på hur det görs nu, d.v.s. klienten har sin egen den enda kända porten som skiljer sig från serverns kända port.

Om flera klienter laddar ner samtidigt och om svar från servern sprids av sändningsförfrågningar, tittar varje klient på de svar som är avsedda för andra klienter. Klienter använder transaktions-ID-fältet i BOOTP-huvudet för att matcha svaret med begäran, eller så tittar servrar på den returnerade klientmaskinvaruadressen.

Se även

Anteckningar

  1. ↑ RFC951 , sid. 3: "BOOTP-protokollet använder två reserverade portnummer, 'BOOTP-klient' (68) och 'BOOTP-server' (67)".
  2. ↑ RFC951 , sid. 3-4.
  3. ↑ RFC951 , sid. 3: "Hårdvaruadresstyp, se ARP-avsnittet i RFC för "Tilldelade nummer".
  4. ↑ RFC1700 , Address Resolution Protocol Parameters, s. 163-164.
  5. ↑ RFC1542 , Definition av fältet "flaggor", s. 5-6: "Detta memo betecknar härmed detta tvåoktettfält som "flaggor"-fältet."

Länkar