![[successivo]](../icons/right.gif){kind=icon}
![[precedente]](../icons/left.gif){kind=icon}
![[indice]](../icons/contents.gif){kind=icon}
Il Bootstrap Protocol fornisce un metodo per una stazione senza disco fisso di compiere un bootstrap ottenendo le informazioni necessarie al boot da un server di rete. Il protocollo BOOTP e' documentato in RFC1532.
I messaggi BOOTP sono contenuti in datagrammi UDP. Il formato e' comune ai due tipi di messaggio, Richiesta e Reponso.
Il campo Codice vale 1 per una Richiesta e 2 per un Responso.
Il campo Tipo Hardware e' lo stesso del corrispondente campo in una trama ARP, e vale 1 per un collegamento Ethernet a 10 Mbit/sec. Il campo Lunghezza Indirizzo Hardware vale 6 per Ethernet. Il campo Numero Hop e' settato a zero dal client e puo' essere usato da un server proxy.
Lo ID Transazione e' un intero settato dal client in modo casuale e serve ad identificare il collegamento specifico tra client e server in presenza di piu' collegamenti simultanei nella rete. Il server pone lo stesso identificativo nel messaggio Responso.
Il campo Numero Secondi viene settato dal client ad un valore determinato dall'implementazione. I server BOOTP in rete esaminano questo campo, e i server secondari intervengono allo scadere di questo tempo se non e' stato inviato alcun responso da parte del server primario.
Se il client conosce il proprio Indirizzo IP allora riempie il campo corrispondente, altrimenti lo pone a zero. Se il campo e' zero, il server pone l'Indirizzo IP giusto nel Responso nel campo Indirizzo Richiesto.
Il campo Indirizzo Server e' settato dal server che risponde. Se il server e' su un'altra rete ed e' in uso un server proxy, questi riempie il campo Indirizzo Gateway.
Il client setta il campo Indirizzo Hardware. Questo campo e' allineato a 32 bit, eventialmente ponendo al termine un pad di zeri.
Il server pone il proprio nome nel campo Nome Server come stringa terminata da un NUL, e se applicabile il Nome File di boot, anch'esso come stringa. Il client successivamente puo' eseguire il download del file di boot con un altro protocollo, p.es TFTP.
Il campo Opzioni Venditore puo' contenere informazioni aggiuntive specifiche dell'implementazione.
La Richiesta BOOTP e' trasmessa all'indirizzo di broadcast locale 255.255.255.255, con indirizzo mittente settato a 0.0.0.0 poiche' il client spesso non conosce il proprio indirizzo.
BOOTP usa i porti 67 per il server e 68 per il client. Il client non usa un porto effimero. La ragione e' che i server trasmettono il messaggio Responso in modo broadcast e vi potrebbero essere interferenze con altri servizi di altre stazioni che usassero lo stesso porto effimero del client richiedente.
Ogni client riceve tutti i Responsi BOOTP, ma riesce a distinguere il suo tremite il campo ID Transazione del messaggio.
Il problema e' che il server conosce l'indirizzo hardware del client e anche l'indirizzo IP, letto da un file di configurazione, ma il client non conosce il proprio indirizzo IP e quindi non potrebbe determinare che il messaggio Responso e' destinato a lui.
Vi sono due soluzioni. La prima e' che il server usi l'indirizzo hardware del client per aggiornare la cache ARP; questo richiede privilegi da parte del server. E' la soluzione tipica dei server UNIX.
Il secondo modo e' di inviare un Responso broadcast al porto 68 di tutti i client. Il client giusto riconosce il proprio Responso dal campo ID Transazione. Non sono richiesti privilegi da parte del server.
Un server BOOTP su un router puo' essere configurato come proxy, o meglio come "BOOTP Relay Agent". Alla ricezione di Richieste tale server pone l'indirizzo dell'interfaccia su cui e' giunta la richiesta nel campo Indirizzo Gateway e trasmette la richiesta al vero server. Inoltre incrementa il campo Numero Salti di uno, per impedire effetti perversi di ridirezioni infinite (se il campo super 255 la richiesta e' scartata).
Il server vero sa' che la richiesta e' stata smistata dal fatto che il campo Indirizzo Gateway e' discreto, formula il responso e lo invia al server proxy, non al cliente. Il server proxy la fa proseguire fino al cliente.
Queste opzioni sono specificate in RFC1533, e consistono in informazioni opzionali ritornate al client.
Se le informazioni esistono, i primi 4 byte di questo campo sono settati al magic cookie 99.130.83.99, che non e' da considerarsi un indirizzo IP. Segue una lista di opzioni, ciascuna allineata al confine di 32 bit da un'opzione Pad.
L'opzione Maschera di Sottorete indica al client l'esistenza e il valore della sottorete in vigore. L'opzione Time Offset e' il numero di secondi dalla mezzanotte GMT del 1 Gennaio 1900.
L'opzione Gateway fornisce al client l'indirizzo del gateway di default e opzionalmente di altri gateways. La lunghezza e' sempre un multiplo di 4 byte.
Vi sono numerose altre opzioni definite, tra cui Server DNS, Printer Server, Time Server, eccetera. La dimensione massima del campo Opzioni Venditore e' comunque limitata a 64 byte.