BOOTP | |
---|---|
Név | Bootstrap protokoll |
Szint ( az OSI modell szerint ) | alkalmazott |
Család | TCP/IP |
Létrehozva: | 1985 |
Port/ID |
67/ UDP (szerver), 68/UDP (kliens) [1] |
A protokoll célja | hálózati konfiguráció lekérése |
Leírás | RFC 951 , RFC 1542 |
A BOOTP (az angol bootstrap protokollból ) egy alkalmazásszintű hálózati protokoll , amellyel az ügyfél automatikusan megkapja az IP-címet . Ez általában a számítógép indításakor történik . A BOOTP-t az RFC 951 határozza meg .
A BOOTP a RARP -hez hasonlóan lehetővé teszi egy speciális szerver számára, hogy a kliens IP-címét a MAC - címéből határozza meg (például olyan eszköz indításakor, amely nem képes saját IP-címet tárolni), és lehetővé teszi az ügyfelek számára, hogy megtanuljanak más rendszerindítási paramétereket. (például a TFTP -n keresztül letöltött program neve ), és az UDP -t használja szállítási réteg protokollként. Ez lehetővé teszi, hogy útválasztókat (bootp relay) használjon kérések és válaszok küldésére egyik LAN szegmensről a másikra. A DHCP ( Dynamic Host Configuration Protocol ) egy BOOTP-bővítmény (a rendszerindítási közvetítővel való kompatibilitás érdekében), és lehetővé teszi a szerver számára, hogy korlátozott ideig dinamikusan rendeljen IP-címeket az ügyfelekhez.
Az akkori (?) évek karbantartói szembesültek az új eszközök folyamatos csatlakoztatásának és mozgatásának kihívásaival, valamint a hálózati konfiguráció módosításának szükségességével, hogy megfeleljenek a modern hálózati követelményeknek. Mindez oda vezetett, hogy létre kellett hozni egy mechanizmust a hálózati csomópontok, az elosztott operációs rendszerek és a hálózati szoftverek konfigurációjának automatizálására. Az ilyen mechanizmus megvalósításának leghatékonyabb módja a konfigurációs beállítások és szoftverképek tárolása egy vagy több rendszerindító szerveren. Az indítás során a rendszer kapcsolatba lép egy ilyen szerverrel, megkapja onnan a kezdeti konfigurációs paramétereket, és szükség esetén letölti róla a szükséges szoftvert.
A BOOTP-t az RFC 951 -ben vezették be az elavult RARP helyett. A BOOTP-t eredetileg lemez nélküli munkaállomásokhoz fejlesztették ki . A modern körülmények ahhoz vezettek, hogy automatizálni kell az olyan rendszerek indítását, amelyek csak alapvető IP- , UDP- és TFTP-eszközökkel rendelkeznek ROM-ban. Az eredeti rendszerindító szkript így nézett ki:
A letöltési kérelem és a válasz ugyanazt az üzenetformátumot használja. A kérelemben néhány mező null értékkel rendelkezik.
BOOTP csomagstruktúra [2] :
Szegmens eltolás |
Hossz, oktett |
Leírás |
---|---|---|
0 | egy | Op Műveleti kód |
egy | egy | HType Berendezés típusa |
2 | egy | HLen Hardvercím hossza |
3 | egy | Komló Komlószám |
négy | négy | XID Tranzakcióazonosító |
nyolc | 2 | Másodperc másodpercek számlálója, amióta az első kérést elküldte az ügyfél |
tíz | 2 | Nem használt RFC 951 Flags - Flags mező az RFC 1542 -ben |
12 | négy | CIAddr kliens IP-címe |
16 | négy | YIAddr A szerver által az ügyfélnek biztosított IP-cím |
húsz | négy | SIAddr szerver IP-címe |
24 | négy | GIAddr A köztes útválasztó IP-címe |
28 | 16 | CHAddr Ügyfél hardvercíme |
44 | 64 | SName Szerver gazdagépneve |
108 | 128 | A rendszerindító fájl fájl neve |
236 | 64 | Vend fejlesztői terület és speciális beállítások |
Tekintsük részletesebben az összes paramétert.
A műveleti kód az üzenet típusát jelzi:
Megadja a használt hálózati hardver típusát, az ARP protokoll specifikációjában [3] [4] szereplő Hardvertípus ( HType , HRD ) mezőhöz hasonló értékek használatával .
Néhány gyakran használt érték:
h típusú | Leírás |
---|---|
egy | Ethernet (10Mb) |
6 | IEEE 802 hálózatok |
7 | ARCNET |
tizenöt | keretrelé |
16 | Aszinkron átviteli mód (ATM) |
tizennyolc | szál csatorna |
húsz | soros vonal |
Megadja az üzenetben szereplő hardvercím hosszát. Ethernet hálózatok és más IEEE 802 -t használó hálózatok esetén ennek a paraméternek az értéke 6.
Az ARP-csomag hasonló mezője a HLN.
Ezt a szegmenst a relék használják az üzenettovábbítás vezérlésére. A mező értéke 0-ra van állítva, mielőtt elküldené, és 1-gyel növekszik, amikor áthalad minden relén.
A tranzakcióazonosító egy 32 bites egész szám, amelyet az ügyfél állít be, és a kiszolgáló visszaad. Lehetővé teszi az ügyfél számára, hogy a választ a kéréssel párosítsa. Az ügyfél ezt a mezőt egy véletlen számra állítja be minden kérésnél.
Amikor az ügyfél elküldi az első letöltési kérelmet, a másodpercszámláló mező nullára kerül. Ha a kérésre nem érkezik válasz, az időkorlát lejárta után a kliens újra elküldi a kérést, megváltoztatva az értéket a másodpercszámláló mezőben. Az időtúllépéshez az ügyfél véletlenszerű intervallumot használ, 60 másodpercig növelve.
Ennek a mezőnek nincs különleges célja. Tartalmát a szerver vagy a hálózati monitor ellenőrizheti, hogy meghatározza, mennyi ideig vár a kliens a hálózati letöltésre. A szerver használhatja a másodpercszámláló mezőben található értékeket a kérések priorizálására, de ezt a mezőt jelenleg a legtöbb implementáció figyelmen kívül hagyja.
Az eredeti RFC 951 -ben ez a két bájtos mező üresen maradt. Az RFC 1542 szerint zászlók beállítására szolgál [5] .
Zászló neve | Méret, bit | Leírás |
---|---|---|
B | egy | Broadcast: az eredeti üzenet elküldésekor a kliens nem ismeri a saját IP-címét, és ez a jelző "1"-re van állítva. Ez az állapot jelzi a csomagot fogadó BOOTP - kiszolgálóknak és közvetítőknek , hogy az ügyféltől érkező kérést el kell küldeni . |
Fenntartott | tizenöt | Fenntartva és nem használt, az értékek 0-ra vannak állítva. |
Ha a kliens már ismeri az IP-címét, akkor kitölti a kliens IP-címe mezőt. Ha nem, a kliens ezt az értéket 0-ra állítja. Ez utóbbi esetben a szerver beszúrja az Ön IP-címét a kliens IP-címét tartalmazó mezőbe. A szerver IP címe mezőt a szerver tölti ki. Ha mérvadó szervert használnak, az kitölti az átjáró IP-címét.
Az ügyfélnek be kell állítania a kliens hardvercímét. Ez ugyanaz az érték, amely a datagram Ethernet fejlécében és UDP mezőjében található, így elérhetővé válik bármely felhasználói folyamat (például BOOTP-szerver) számára, amely megkapta a datagramot. Az UDP-datagramokat kezelő folyamatok számára általában nehéz vagy szinte lehetetlen meghatározni annak a datagramnak az Ethernet-fejléc mezőjében lévő értéket, amelyben az UDP-datagramot küldik.
A szerver gazdagépneve egy karakterlánc, amelyet a kiszolgáló tölt ki (nem kötelező).
A szerver a rendszerindító fájlnév mezőt is kitöltheti. Ez a mező tartalmazza a feltöltéshez használt fájl teljes elérési útját.
Eredetileg a szállítóspecifikus területet az üzenetekben használták a megvalósítás-specifikus információk küldésére. A BOOTP kezdetén azonban ez a terület szabad maradt, bár nagy mennyiségű információ (például az alhálózati maszk vagy az alapértelmezett útválasztó címe) formálisan nem szerepelt az üzenetekben. A fejlesztői terület további konfigurációs lehetőségek, valamint fejlesztőspecifikus információk helyeként szolgált. Ezen a területen jó néhány különböző terület van meghatározva.
A BOOTP-nek két előre ismert portja van: a 67-es a szerverhez és a 68-as az ügyfélhez. Ez azt jelenti, hogy a kliens nem választ egy nem használt, dinamikusan hozzárendelt portot, hanem a 68-as portszámot használja. Az oka annak, hogy két portszámot választottak ahelyett, hogy csak egyet használtak volna a szerver számára, mert a szerver tud választ küldeni (bár általában nem ) közvetített módon.
Ha a kiszolgáló válasza sugárzott, és az ügyfélnek dinamikusan hozzárendelt portszámot kell választania, akkor ezeket a szórásokat más alkalmazások is fogadnák más gazdagépeken, amelyek ugyanazt a dinamikusan hozzárendelt portszámot használják. Ebből arra következtethetünk, hogy egy véletlenszerű (dinamikusan hozzárendelt) portszámra küldeni egy broadcast kérést nem racionális.
Ha a kliens a kiszolgáló jól ismert portját (67) használja, a hálózat összes szervere kénytelen lesz figyelni minden üzenetszórási választ. (Ha az összes szervert „ébresztik”, ellenőrizniük kellene az opcode-ot, meg kellene állapítaniuk, hogy válasz volt-e, és nem kérés, majd ismét „alszik”.) Így a döntés megtörtént, hogy ez most hogyan történik, azaz a kliens az egyetlen ismert port, amely eltér a szerver által ismert porttól.
Ha egyszerre több kliens is tölt le, és ha a kiszolgálótól érkező válaszokat szórásos kérések továbbítják, akkor mindegyik kliens megvizsgálja a többi kliensnek szánt válaszokat. Az ügyfelek a BOOTP-fejlécben található tranzakcióazonosító mezőt használják a válasz és a kérés egyeztetésére, vagy a szerverek megnézik a visszaadott ügyfél hardvercímét.
TCP / IP protokollok az OSI modell rétegei szerint | Alapvető|
---|---|
Fizikai | |
csatornázott | |
hálózat | |
Szállítás | |
ülés | |
Reprezentáció | |
Alkalmazott | |
Egyéb alkalmazva | |
A TCP és UDP portok listája |