Protocolul Bootstrap

Versiunea actuală a paginii nu a fost încă revizuită de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită la 30 mai 2017; verificările necesită 5 modificări .
BOOTP
Nume Protocolul Bootstrap
Nivel (conform modelului OSI ) aplicat
Familie TCP/IP
Creat în 1985
Port/ID 67/ UDP (server),
68/UDP (client) [1]
Scopul protocolului obțineți configurația rețelei
Specificație RFC 951 , RFC 1542

BOOTP (din limba engleză  bootstrap protocol ) este un protocol de rețea de nivel de aplicație utilizat pentru a obține automat o adresă IP de către client . Acest lucru se întâmplă de obicei în timp ce computerul pornește . BOOTP este definit în RFC 951 .

BOOTP, precum RARP , permite unui server special să determine adresa IP a clientului din adresa sa MAC (de exemplu, la pornirea unui dispozitiv care nu are capacitatea de a stoca propria adresă IP) și, de asemenea, permite clienților să învețe alți parametri de pornire (de exemplu, numele programului, descărcat prin TFTP ) și utilizează UDP ca protocol de nivel de transport. Acest lucru vă permite să utilizați routere (bootp relay) pentru a trimite cereri și răspunsuri de la un segment LAN la altul. DHCP ( Dynamic Host Configuration Protocol ) este un  add-on pentru BOOTP (pentru compatibilitate cu bootp relay) și permite serverului să aloce adrese IP clienților în mod dinamic pentru o perioadă limitată.

Istorie

Personalul de întreținere din acei (?) ani s-a confruntat cu provocările legate de conectarea și mutarea constantă a noilor dispozitive, precum și nevoia de a schimba configurația rețelei pentru a îndeplini cerințele moderne ale rețelei. Toate acestea au dus la necesitatea creării unui mecanism de automatizare a configurației nodurilor de rețea, a sistemelor de operare distribuite și a software-ului de rețea. Cel mai eficient mod de a implementa un astfel de mecanism poate fi stocarea setărilor de configurare și a imaginilor software pe unul sau mai multe servere de pornire. În timpul pornirii, sistemul interacționează cu un astfel de server, primește parametrii inițiali de configurare de la acesta și, dacă este necesar, descarcă software-ul necesar de pe acesta.

BOOTP a fost introdus în RFC 951 ca înlocuitor pentru RARP depreciat. BOOTP a fost dezvoltat inițial pentru stațiile de lucru fără disc . Condițiile moderne au dus la necesitatea de a automatiza pornirea sistemelor care au doar instrumente de bază pentru IP , UDP și TFTP în ROM. Scriptul de pornire original arăta astfel:

Format mesaj BOOTP

Cererea de descărcare și răspunsul folosesc același format de mesaj. În cerere, unele câmpuri au valori nule.

Structura pachetului BOOTP [2] :


Segment Offset		 Lungime,
octet 		Descriere
0 unu Op
Cod de operare
unu unu HType
Tip echipament
2 unu HLen
Lungimea adresei hardware
3 unu Hamei
Numărul de hamei
patru patru XID
ID tranzacție
opt 2 Contor de secunde
de când prima solicitare a fost trimisă de client
zece 2 Nu este utilizat în RFC 951
Flags  - Câmpul Flags în RFC 1542
12 patru
Adresa IP a clientului CIAddr
16 patru YIAddr Adresa
IP furnizată clientului de către server
douăzeci patru
Adresa IP a serverului SIAdr
24 patru GIAddr
Adresa IP a routerului intermediar
28 16
Adresa hardware a clientului CHAddr
44 64 Nume gazdă SNname
Server
108 128 Numele fișierului
de pornire
236 64 Zona
pentru dezvoltatori de vânzări și Opțiuni avansate

Să luăm în considerare toți parametrii mai detaliat.

Cod operațiune

Opcode-ul indică tipul de mesaj:

Tip echipament

Specifică tipul de hardware de rețea utilizat, utilizând valori similare câmpului Hardware Type ( HType , HRD ) din specificația protocolului ARP [3] [4] .

Câteva valori frecvent utilizate:

tipul h Descriere
unu Ethernet (10 Mb)
6 Rețele IEEE 802
7 ARCNET
cincisprezece releu cadru
16 Mod de transfer asincron (ATM)
optsprezece canal de fibră
douăzeci linie serială

Lungimea adresei hardware

Specifică lungimea adresei hardware din mesaj. Pentru rețelele Ethernet și altele care utilizează IEEE 802 , valoarea acestui parametru este 6.

Un câmp similar în pachetul ARP este HLN.

Numărul de transferuri

Acest segment este utilizat de relee pentru a controla transmiterea mesajelor. Valoarea câmpului este setată la 0 înainte de a fi trimisă și incrementată cu 1 pe măsură ce trece prin fiecare releu.

ID tranzacție

ID-ul tranzacției este un număr întreg de 32 de biți care este setat de client și returnat de server. Acesta permite clientului să potrivească răspunsul cu cererea. Clientul setează acest câmp la un număr aleator pentru fiecare cerere.

Contor de secunde

Când clientul trimite prima cerere de descărcare, câmpul contorului de secunde este setat la zero. Dacă cererea nu primește răspuns, după expirarea timpului de expirare, clientul trimite din nou cererea, modificând valoarea din câmpul contor secunde. Pentru timeout, clientul folosește un interval aleator, crescând până la o valoare de 60 de secunde.

Acest domeniu nu are un scop special. Conținutul acestuia poate fi verificat de server sau de monitorul rețelei pentru a determina cât timp așteaptă clientul pentru o descărcare în rețea. Serverul POATE folosi valorile din câmpul contor de secunde pentru a prioritiza cererile, dar acest câmp este în prezent ignorat în majoritatea implementărilor.

Steaguri

În RFC 951 original , acest câmp de doi octeți a fost lăsat necompletat. Conform RFC 1542 este folosit pentru a seta steaguri [5] .

Numele steagului Dimensiune, un pic Descriere
B unu Broadcast: la trimiterea mesajului original, clientul nu își cunoaște propria adresă IP, iar acest flag este setat la „1”. Această stare indică serverelor și releelor ​​BOOTP care au primit pachetul că cererea de la acest client ar trebui să fie difuzată .
Rezervat cincisprezece Rezervat și neutilizat, valorile setate la 0.

Adresa IP a clientului

Dacă clientul își cunoaște deja adresa IP, completează câmpul pentru adresa IP a clientului. Dacă nu, clientul setează această valoare la 0. În acest din urmă caz, serverul introduce adresa dumneavoastră IP în câmpul cu adresa IP a clientului. Câmpul pentru adresa IP a serverului este completat de server. Dacă este utilizat un server autorizat, acesta completează adresa IP a gateway-ului.

Adresa IP furnizată clientului de către server

Clientul trebuie să-și seteze adresa hardware client. Aceasta este aceeași valoare găsită în antetul Ethernet și în câmpul UDP al datagramei, făcându-l disponibil oricărui proces utilizator (cum ar fi un server BOOTP) care a primit datagrama. De obicei, este dificil sau aproape imposibil ca un proces care manipulează datagramele UDP să determine valoarea din câmpul antet Ethernet al datagramei în care este trimisă datagrama UDP.

Nume gazdă server

Numele de gazdă al serverului este un șir care este completat de server (opțional).

Numele fișierului de pornire

Serverul poate completa și câmpul pentru numele fișierului de pornire. Acest câmp conține calea completă către fișierul care este utilizat la încărcare.

Zona pentru dezvoltatori

Inițial, zona specifică furnizorului a fost folosită în mesaje pentru a trimite informații specifice implementării. Cu toate acestea, la începutul BOOTP, această zonă a rămas liberă, deși o cantitate mare de informații (de exemplu, masca de subrețea sau adresa implicită a routerului) nu a fost inclusă oficial în mesaje. Zona pentru dezvoltatori a servit drept loc pentru opțiuni de configurare suplimentare, precum și informații specifice dezvoltatorului. Există destul de multe domenii diferite definite în acest domeniu.

Numerele portului

BOOTP are două porturi precunoscute: 67 pentru server și 68 pentru client. Aceasta înseamnă că clientul nu alege un port alocat dinamic nefolosit, ci folosește numărul portului 68. Motivul pentru care au fost alese două numere de port în loc să folosească doar unul pentru server este că serverul poate trimite un răspuns (deși de obicei nu ) într-o manieră difuzată.

Dacă răspunsul de la server ar fi difuzat și dacă clientul trebuie să selecteze un număr de port alocat dinamic, acele transmisii ar fi primite și de alte aplicații pe alte gazde care folosesc același număr de port alocat dinamic. Astfel, putem concluziona că trimiterea unei cereri de difuzare către un număr de port aleatoriu (alocat dinamic) nu este rațională.

Dacă clientul folosește portul bine-cunoscut al serverului (67), toate serverele din rețea vor fi forțate să asculte fiecare răspuns de difuzare. (Dacă toate serverele ar fi „trezite”, ar trebui să verifice opcode-ul, să stabilească că a fost un răspuns și nu o solicitare și să „somnească” din nou.) Deci s-a ales cum se face acum, adică clientul are propriu, singurul port cunoscut care este diferit de portul cunoscut al serverului.

Dacă mai mulți clienți se descarcă în același timp și dacă răspunsurile de la server sunt propagate prin cereri de difuzare, fiecare client se uită la răspunsurile care sunt destinate altor clienți. Clienții folosesc câmpul ID tranzacției din antetul BOOTP pentru a potrivi răspunsul cu cererea, sau serverele se uită la adresa hardware a clientului returnată.

Vezi și

Note

  1. ↑ RFC951 , p. 3: „Protocolul BOOTP utilizează două numere de porturi rezervate, „client BOOTP” (68) și „server BOOTP” (67)”.
  2. ↑ RFC951 , pp. 3-4.
  3. ↑ RFC951 , p. 3: „Tipul de adresă hardware, consultați secțiunea ARP din RFC „Numere atribuite”.
  4. ↑ RFC1700 , Address Resolution Protocol Parameters, pp. 163-164.
  5. ↑ RFC1542 , Definiția câmpului „steaguri”, pp. 5-6: „Acest memoriu desemnează prin prezenta acest câmp de doi octeți drept câmpul „steaguri”.

Link -uri