| BOOTP | |
|---|---|
| název | Bootstrap Protocol |
| Úroveň (podle modelu OSI ) | aplikovaný |
| Rodina | TCP/IP |
| Vytvořeno v | 1985 |
| Port/ID |
67/ UDP (server), 68/UDP (klient) [1] |
| Účel protokolu | získat konfiguraci sítě |
| Specifikace | RFC 951 , RFC 1542 |
BOOTP (z anglického bootstrap protocol ) je síťový protokol aplikační vrstvy používaný k automatickému získání IP adresy klientem . K tomu obvykle dochází při spouštění počítače . BOOTP je definován v RFC 951 .
BOOTP, stejně jako RARP , umožňuje speciálnímu serveru určit IP adresu klienta z jeho MAC adresy (například při spouštění zařízení, které nemá možnost uložit vlastní IP adresu), a také umožňuje klientům naučit se další parametry spouštění. (například název programu, staženého přes TFTP ) a jako protokol transportní vrstvy používá UDP . To vám umožňuje používat směrovače (bootp relay) k odesílání požadavků a odpovědí z jednoho segmentu LAN do druhého. DHCP ( Dynamic Host Configuration Protocol ) je doplněk pro BOOTP (pro kompatibilitu s bootp relay) a umožňuje serveru dynamicky přidělovat IP adresy klientům na omezenou dobu.
Pracovníci údržby těchto (?) let čelili výzvám neustálého připojování a přesouvání nových zařízení a také nutnosti měnit konfiguraci sítě tak, aby vyhovovala moderním síťovým požadavkům. To vše vedlo k potřebě vytvořit mechanismus pro automatizaci konfigurace síťových uzlů, distribuovaných operačních systémů a síťového softwaru. Nejúčinnějším způsobem implementace takového mechanismu může být uložení konfiguračních nastavení a obrazů softwaru na jednom nebo více zaváděcích serverech. Během spouštění systém s takovým serverem komunikuje, přijímá z něj počáteční konfigurační parametry a v případě potřeby si z něj stahuje potřebný software.
BOOTP byl zaveden v RFC 951 jako náhrada za zastaralý RARP. BOOTP byl původně vyvinut pro bezdiskové pracovní stanice . Moderní podmínky vedly k potřebě automatizovat spouštění systémů, které mají v ROM pouze základní nástroje pro IP , UDP a TFTP. Původní spouštěcí skript vypadal takto:
Požadavek na stažení a odpověď používají stejný formát zprávy. V požadavku mají některá pole hodnoty null.
Struktura balíčku BOOTP [2] :
| Odsazení segmentu |
Délka, oktet |
Popis |
|---|---|---|
| 0 | jeden | Operační kód |
| jeden | jeden | HType Typ zařízení |
| 2 | jeden | HLen Délka hardwarové adresy |
| 3 | jeden | Chmel Počet chmelů |
| čtyři | čtyři | ID transakce XID |
| osm | 2 | Secs Počítadlo sekund od prvního požadavku odeslaného klientem |
| deset | 2 | Nepoužívá se v RFC 951 Flags – pole Flags v RFC 1542 |
| 12 | čtyři | IP adresa klienta CIAddr |
| 16 | čtyři | YIAddr Adresa IP poskytnutá klientovi serverem |
| dvacet | čtyři | IP adresa serveru SIAddr |
| 24 | čtyři | GIAddr IP adresa zprostředkujícího routeru |
| 28 | 16 | Hardwarová adresa klienta CHAddr |
| 44 | 64 | Název hostitele SName Server |
| 108 | 128 | Soubor Název spouštěcího souboru |
| 236 | 64 | Prodejní oblast pro vývojáře a pokročilé možnosti |
Zvažme všechny parametry podrobněji.
Operační kód označuje typ zprávy:
Určuje typ používaného síťového hardwaru pomocí hodnot podobných poli Typ hardwaru ( HType , HRD ) ve specifikaci protokolu ARP [3] [4] .
Některé běžně používané hodnoty:
| h typ | Popis |
|---|---|
| jeden | Ethernet (10 Mb) |
| 6 | Sítě IEEE 802 |
| 7 | ARCNET |
| patnáct | rámové relé |
| 16 | Režim asynchronního přenosu (ATM) |
| osmnáct | vláknový kanál |
| dvacet | sériová linka |
Určuje délku hardwarové adresy ve zprávě. Pro sítě Ethernet a další sítě používající IEEE 802 je hodnota tohoto parametru 6.
Podobné pole v paketu ARP je HLN.
Tento segment používají relé k řízení předávání zpráv. Hodnota pole je před odesláním nastavena na 0 a při průchodu každým relé se zvyšuje o 1.
ID transakce je 32bitové celé číslo, které nastavuje klient a vrací server. Umožňuje klientovi spojit odpověď s požadavkem. Klient nastaví toto pole pro každý požadavek na náhodné číslo.
Když klient odešle první požadavek na stažení, pole počítadla sekund je nastaveno na nulu. Pokud požadavek neobdrží odpověď, po vypršení časového limitu klient odešle požadavek znovu a změní hodnotu v poli počítadla sekund. Pro časový limit klient používá náhodný interval, který se zvyšuje až na hodnotu 60 sekund.
Toto pole nemá žádný zvláštní účel. Jeho obsah může být zkontrolován serverem nebo síťovým monitorem a určit, jak dlouho klient čeká na stažení ze sítě. Server MŮŽE použít hodnoty v poli počítadla sekund k upřednostnění požadavků, ale toto pole je v současnosti ve většině implementací ignorováno.
V původním RFC 951 bylo toto dvoubajtové pole ponecháno prázdné. Podle RFC 1542 se používá k nastavení příznaků [5] .
| Název vlajky | Velikost, bit | Popis |
|---|---|---|
| B | jeden | Broadcast: při odesílání původní zprávy klient nezná svou vlastní IP adresu a tento příznak je nastaven na "1". Tento stav označuje servery BOOTP a přenosy, které přijaly paket, že požadavek od tohoto klienta by měl být vysílán . |
| Rezervováno | patnáct | Rezervováno a nepoužito, hodnoty nastaveny na 0. |
Pokud klient již zná svou IP adresu, vyplní pole IP adresa klienta. Pokud ne, klient nastaví tuto hodnotu na 0. V druhém případě server vloží vaši IP adresu do pole s IP adresou klienta. Pole IP adresa serveru je vyplněno serverem. Pokud je použit autoritativní server, vyplní IP adresu brány.
Klient musí nastavit hardwarovou adresu klienta. Jedná se o stejnou hodnotu, která se nachází v ethernetové hlavičce a v poli UDP datagramu, takže je k dispozici jakémukoli uživatelskému procesu (jako je server BOOTP), který datagram přijal. Pro proces zpracovávající datagramy UDP je obvykle obtížné nebo téměř nemožné určit hodnotu v poli záhlaví Ethernet datagramu, ve kterém je datagram UDP přenášen.
Server hostname je řetězec, který je vyplněn serverem (volitelné).
Server může také vyplnit pole spouštěcího souboru. Toto pole obsahuje úplnou cestu k souboru, který se použije při nahrávání.
Původně byla oblast specifická pro dodavatele používána ve zprávách k odesílání informací specifických pro implementaci. Na začátku BOOTP však tato oblast zůstávala volná, i když velké množství informací (například maska podsítě nebo výchozí adresa routeru) ve zprávách formálně zahrnuto nebylo. Oblast pro vývojáře sloužila jako místo pro další možnosti konfigurace a také informace specifické pro vývojáře. V této oblasti je definováno několik různých oblastí.
BOOTP má dva předem známé porty: 67 pro server a 68 pro klienta. To znamená, že klient si nezvolí nepoužívaný dynamicky přidělovaný port, ale používá číslo portu 68. Důvodem, proč byla pro server zvolena dvě čísla portu namísto použití pouze jednoho, je to, že server může odeslat odpověď (ačkoli obvykle ne ) vysílaným způsobem.
Pokud by byla odpověď ze serveru vysílaná a klient potřeboval vybrat dynamicky přiřazené číslo portu, tato vysílání by také přijaly jiné aplikace na jiných hostitelích, které používají stejné dynamicky přiřazené číslo portu. Můžeme tedy dojít k závěru, že odeslání požadavku na vysílání na náhodné (dynamicky přidělené) číslo portu není racionální.
Pokud klient používá známý port serveru (67), všechny servery v síti budou nuceny naslouchat každé odpovědi vysílání. (Pokud by byly všechny servery „probuzeny“, musely by zkontrolovat operační kód, určit, že se jednalo o odpověď, nikoli požadavek, a znovu „uspat“.) Bylo tedy rozhodnuto, jak se to dělá nyní, tj. vlastní jediný známý port, který se liší od známého portu serveru.
Pokud stahuje více klientů současně a jsou-li odpovědi ze serveru šířeny požadavky všesměrového vysílání, každý klient se podívá na odpovědi, které jsou určeny pro ostatní klienty. Klienti používají pole ID transakce v hlavičce BOOTP, aby porovnali odpověď s požadavkem, nebo se servery podívají na vrácenou hardwarovou adresu klienta.
| Základní protokoly TCP /IP podle vrstev modelu OSI | |
|---|---|
| Fyzický | |
| odvedeny | |
| síť | |
| Doprava | |
| zasedání | |
| Zastoupení | |
| Aplikovaný | |
| Uplatněno jiné | |
| Seznam portů TCP a UDP | |