Bootstrap protokoll

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.

Történelem

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 kliens UDP üzenetet küld a rendszerindítási információkhoz.
• A szerver visszaküldi a kliensnek az IP-címét és opcionálisan a letöltött fájl helyét.
• A legegyszerűbb fájlátviteli protokoll, a TFTP ( English  Trivial File Transfer Protocol ) segítségével a kliens betölti a szükséges szoftvert a saját memóriájába, és elkezd dolgozni.

BOOTP üzenetformátum

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] :

Tekintsük részletesebben az összes paramétert.

Műveleti kód

A műveleti kód az üzenet típusát jelzi:

• 1 - kérésre ( BOOTREQUEST );
• 2 - a válaszért ( BOOTREPLY ).

Berendezés típusa

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:

Hardvercím hossza

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.

Átigazolások száma

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.

Tranzakcióazonosító

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.

Másodpercszámlá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.

Flags

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] .

Kliens IP-címe

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.

A szerver által a kliensnek biztosított IP-cím

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.

Szerver hosztnév

A szerver gazdagépneve egy karakterlánc, amelyet a kiszolgáló tölt ki (nem kötelező).

Indító fájlnév

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.

Fejlesztői terület

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.

Portszámok

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.

Lásd még

• DHCP
• PXE

Jegyzetek

1. ↑ RFC951 , p. 3: "A BOOTP protokoll két lefoglalt portszámot használ, a "BOOTP klienst" (68) és a "BOOTP szervert" (67)".
2. ↑ RFC951 , pp. 3-4.
3. ↑ RFC951 , p. 3: "Hardvercím típusa, lásd az ARP szakaszt a "Hozzárendelt számok" RFC-ben".
4. ↑ RFC1700 , Address Resolution Protocol Parameters, pp. 163-164.
5. ↑ RFC1542 , A „zászlók” mező meghatározása, pp. 5-6: "Ez a feljegyzés ezt a két oktettből álló mezőt "zászlók" mezőnek jelöli."

Linkek

• Bill Croft , John Gilmore . Bootstrap Protocol (BOOTP  ) . IETF (1985. szeptember). Letöltve: 2017. május 29.
• J. Reynolds , J. Postel . Hozzárendelt számok  . IETF (1994. október). Letöltve: 2017. május 29.
• W. Wimer . A Bootstrap protokoll  pontosításai és kiterjesztései . IETF (1993. október). Letöltve: 2017. május 29.