SlideShare a Scribd company logo
1 of 12
BOOTP e DHCP
Sistemi e Reti
Prof. Pierpaolo Mannone
Il bootstrap dei sistemi
Per configurare in modo automatico gli host di una reteTCP/IP sono stati
definiti in ambito IETF alcuni protocolli. Uno dei primi e più diffusi è stato il
protocollo BOOTP (BOOTstrap Protocol), necessario per mettere in
comunicazione un computer privo di disco e un secondo host che gli deve
fornire le informazioni di rete.
BOOTP e DHCP
BOOTP e DHCP
• sono protocolli che permettono di assegnare ad un host tutti i valori necessari per consentirgli di operare
sulla rete
• l’indirizzo IP
• la netmask
• l’indirizzo di un router
• l’indirizzo di un name server
operano come applicazioni e non interagiscono direttamente con l’hardware
• DHCP è un’estensione di BOOTP
BOOTP
BOOTP
• usa le porte UDP 67 (server) e 68 (client)
• Il client spedisce il primo messaggio all’indirizzo 255.255.255.255 con indirizzo sorgente
0.0.0.0
• 255.255.255.255 è l’indirizzo di broadcast
• Il modulo IP invia un datagram all’indirizzo di broadcast limitato anche se non viene
specificato l’indirizzo sorgente
• I server BOOTP che ricevono il messaggio rispondono con i dati necessari „il client utilizza
solo la prima risposta ricevuta
Configurazione Dynamic Host Configuration
Protocol (DHCP)
Il protocollo DHCP, evoluzione di BOOTP, è nato per soddisfare le esigenze di
mobilità dei computer portatili. Si basa sul concetto di lease, «affitto», degli
indirizzi per un periodo limitato di tempo.
Con lo sviluppo di DHCP aumentano i parametri necessari per configurare un
host. Si analizzano nel dettaglio il life cycle dell’affitto di un indirizzo IP e i sei
stati di un DHCP Client, con le transizioni che avvengono tra essi.
La macchina a stati finiti (FSM) del DHCP Client
Gli stati del DHCP Client
• INITIALIZE : Quando un client viene inizializzato per la prima volta.
• SELECT: Quando tenta di acquisire un IP contattando i DHCP Server. In questo stato il client raccoglie le
risposte DHCPOFFER dai DHCP Server.
• REQUEST Il client deve scegliere una delle risposte e concordare con il server la durata del lease, inviando
al server un messaggio DHCPREQUEST.
• Per confermare la ricezione della richiesta e attivare il lease, il server risponde con il messaggio DHCPACK.
L’arrivo della conferma di ricezione fa sì che il client passi allo stato BOUND, in cui usa l’indirizzo
assegnatogli, memorizza i parametri che il server gli ha inviato e imposta due timer:
• renewal timer (T1): è il timer che indica al client quando è il momento di effettuare una richiesta di rinnovo dell’indirizzo;
• 2. rebinding timer (T2): è il timer che indica al client che è scaduto il tempo per rinnovare l’indirizzo IP.
• Lo stato di BOUND è il normale stato di funzionamento del client, che permane per tutto il tempo di utilizzo dell’indirizzo IP
acquisito
Il rinnovo del lease dell’indirizzo IP
Quando il DHCP Client entra nello stato BOUND, imposta i timer che controllano il rinnovo, la conferma e la
scadenza del lease. Il valore a cui impostare questi timer può essere specificato dal DHCP Server oppure il client può
usare quelli predefiniti. Il valore predefinito del renew al timer è la metà del tempo totale del lease; quando scade, il
client passa nello stato RENEW e invia un messaggio DHCPREQUEST al server da cui ha ottenuto il lease. In questo
messaggio è contenuto l’indirizzo IP del quale richiede l’estensione di utilizzo. Il server risponde in due modi:
• comunica al client di interrompere l’uso dell’indirizzo, inviando un messaggio DHCPNACK; il client ritorna nello
stato INITIALIZE;
• ne approva ancora l’utilizzo, inviando al client un messaggio DHCPACK che lo fa tornare nello stato BOUND
impostando nuovamente i timer.
Quando il client passa nello stato RENEW utilizza il rebinding timer per gestire il caso in cui il server al quale ha
inviato la richiesta di rinnovo non possa rispondere, perché è diventato inattivo o non è più raggiungibile. Questo
timer è impostato quando il client passa nellostato BOUND e il valore predefinito è l’87,5% del periodo di lease.
Quando scade questo timer il client passa nello stato REBIND e invia in broadcast sulla rete locale un messaggio
DHCPREQUEST.A questo punto si possono avere tre casi:
1. un server della rete risponde positivamente con un messaggio DHCPACK e il lease dell’indirizzo è prorogato, il
client ritorna nello stato BOUND e imposta nuovamente i timer;
2. un server della rete risponde negativamente con un messaggio DHCPNACK, il client deve smettere di usare
l’indirizzo IP e passare nello stato INITIALIZE per richiederne uno nuovo;
3. nessun server risponde alla richiesta del client (caso raro), scade il periodo di lease e il client deve smettere di
utilizzare l’indirizzo IP, passa quindi nello stato INITIALIZE e avvia la procedura per acquisirne uno nuovo.
DHCP relay agent
• I messaggi inviati in broadcast sono
propagati solo nella rete locale
• un relay agent (agente di
ritrasmissione) che riceve le richieste
da un DHCP Client e le inoltra al DHCP
Server, il quale invierà poi la risposta
al relay agent, che a sua volta la
inoltrerà al client.
DHCP relay agent
• Client Request: quando un client invia una richiesta, il relay agent la intercetta sulla porta
UDP 67, controlla se il campo hops è inferiore a 16 (in caso contrario scarta la richiesta) e
scrive il proprio indirizzo nel campo GIAddr (o, meglio, l’indirizzo dell’interfaccia dalla quale
ha ricevuto il messaggio, nell’esempio in figura 4 l’indirizzo dell’interfaccia del router è
192.204.18.1) e invia il messaggio al DHCP Server;
• Server Reply: il server verifica se il campo GIAddr contiene un valore diverso da zero, in tal
caso invia la risposta all’indirizzo del relay agent il quale, a sua volta, la inoltra al DHCP
Client. Il DHCP Server utilizza il campo GIAddr per determinare il pool di indirizzi dal quale
prelevare l’indirizzo IP da assegnare al client.
Sicurezza
Si affronta il problema della sicurezza nell’uso di DHCP sia lato server sia lato
client.
• DHCP Server non autorizzati: invio informazioni errate/malevoli ai client.
• DHCP Client non autorizzati: client spuffing o esaurimento degli indirizzi
tramite software malevoli.
Configurazione di un computer Linux in LAN

More Related Content

What's hot

2 Protocolli Applicativi
2 Protocolli Applicativi2 Protocolli Applicativi
2 Protocolli Applicativiacapone
 
9 Intranetting
9 Intranetting9 Intranetting
9 Intranettingacapone
 
Sistemi e reti : Il livello di trasporto
Sistemi e reti : Il livello di trasportoSistemi e reti : Il livello di trasporto
Sistemi e reti : Il livello di trasportoStefano Scarpellini
 
5 Protocolli Trasporto Parte1
5 Protocolli Trasporto Parte15 Protocolli Trasporto Parte1
5 Protocolli Trasporto Parte1Majong DevJfu
 
Lumit.Basic.Knowledge.Training.Introduzione.Tcp Ip
Lumit.Basic.Knowledge.Training.Introduzione.Tcp IpLumit.Basic.Knowledge.Training.Introduzione.Tcp Ip
Lumit.Basic.Knowledge.Training.Introduzione.Tcp IpLuca Astori
 
Hosting: gestione degli accessi FTP #TipOfTheDay
Hosting: gestione degli accessi FTP   #TipOfTheDayHosting: gestione degli accessi FTP   #TipOfTheDay
Hosting: gestione degli accessi FTP #TipOfTheDayAruba S.p.A.
 

What's hot (7)

2 Protocolli Applicativi
2 Protocolli Applicativi2 Protocolli Applicativi
2 Protocolli Applicativi
 
9 Intranetting
9 Intranetting9 Intranetting
9 Intranetting
 
Sistemi e reti : Il livello di trasporto
Sistemi e reti : Il livello di trasportoSistemi e reti : Il livello di trasporto
Sistemi e reti : Il livello di trasporto
 
Iperf
IperfIperf
Iperf
 
5 Protocolli Trasporto Parte1
5 Protocolli Trasporto Parte15 Protocolli Trasporto Parte1
5 Protocolli Trasporto Parte1
 
Lumit.Basic.Knowledge.Training.Introduzione.Tcp Ip
Lumit.Basic.Knowledge.Training.Introduzione.Tcp IpLumit.Basic.Knowledge.Training.Introduzione.Tcp Ip
Lumit.Basic.Knowledge.Training.Introduzione.Tcp Ip
 
Hosting: gestione degli accessi FTP #TipOfTheDay
Hosting: gestione degli accessi FTP   #TipOfTheDayHosting: gestione degli accessi FTP   #TipOfTheDay
Hosting: gestione degli accessi FTP #TipOfTheDay
 

Similar to bootp e dhcp sistemi e reti 2018/19

Servizi di consegna personalizzata dei contratti
Servizi di consegna personalizzata dei contrattiServizi di consegna personalizzata dei contratti
Servizi di consegna personalizzata dei contrattiFabio Bolo
 
Progetto e implementazione di uno script python per la gestione di richieste ...
Progetto e implementazione di uno script python per la gestione di richieste ...Progetto e implementazione di uno script python per la gestione di richieste ...
Progetto e implementazione di uno script python per la gestione di richieste ...AndreaMajcen
 
3 Livello Trasporto
3 Livello Trasporto3 Livello Trasporto
3 Livello Trasportoacapone
 
Protocol Rollercoaster: da HTTP a AMQP, passando per CoAP e MQTT
Protocol Rollercoaster: da HTTP a AMQP, passando per CoAP e MQTTProtocol Rollercoaster: da HTTP a AMQP, passando per CoAP e MQTT
Protocol Rollercoaster: da HTTP a AMQP, passando per CoAP e MQTTStefano Valle
 
IoT: protocolli, dispositivi, architetture
IoT: protocolli, dispositivi, architettureIoT: protocolli, dispositivi, architetture
IoT: protocolli, dispositivi, architettureStefano Valle
 

Similar to bootp e dhcp sistemi e reti 2018/19 (6)

Servizi di consegna personalizzata dei contratti
Servizi di consegna personalizzata dei contrattiServizi di consegna personalizzata dei contratti
Servizi di consegna personalizzata dei contratti
 
Progetto e implementazione di uno script python per la gestione di richieste ...
Progetto e implementazione di uno script python per la gestione di richieste ...Progetto e implementazione di uno script python per la gestione di richieste ...
Progetto e implementazione di uno script python per la gestione di richieste ...
 
Gnutella
GnutellaGnutella
Gnutella
 
3 Livello Trasporto
3 Livello Trasporto3 Livello Trasporto
3 Livello Trasporto
 
Protocol Rollercoaster: da HTTP a AMQP, passando per CoAP e MQTT
Protocol Rollercoaster: da HTTP a AMQP, passando per CoAP e MQTTProtocol Rollercoaster: da HTTP a AMQP, passando per CoAP e MQTT
Protocol Rollercoaster: da HTTP a AMQP, passando per CoAP e MQTT
 
IoT: protocolli, dispositivi, architetture
IoT: protocolli, dispositivi, architettureIoT: protocolli, dispositivi, architetture
IoT: protocolli, dispositivi, architetture
 

Recently uploaded

Lorenzo D'Emidio_Francesco Petrarca.pptx
Lorenzo D'Emidio_Francesco Petrarca.pptxLorenzo D'Emidio_Francesco Petrarca.pptx
Lorenzo D'Emidio_Francesco Petrarca.pptxlorenzodemidio01
 
XIII Lezione - Arabo G.Rammo @ Libera Accademia Romana
XIII Lezione - Arabo G.Rammo @ Libera Accademia RomanaXIII Lezione - Arabo G.Rammo @ Libera Accademia Romana
XIII Lezione - Arabo G.Rammo @ Libera Accademia RomanaStefano Lariccia
 
Lorenzo D'Emidio_Vita e opere di Aristotele.pptx
Lorenzo D'Emidio_Vita e opere di Aristotele.pptxLorenzo D'Emidio_Vita e opere di Aristotele.pptx
Lorenzo D'Emidio_Vita e opere di Aristotele.pptxlorenzodemidio01
 
XI Lezione - Arabo LAR Giath Rammo @ Libera Accademia Romana
XI Lezione - Arabo LAR Giath Rammo @ Libera Accademia RomanaXI Lezione - Arabo LAR Giath Rammo @ Libera Accademia Romana
XI Lezione - Arabo LAR Giath Rammo @ Libera Accademia RomanaStefano Lariccia
 
Lorenzo D'Emidio_Vita di Cristoforo Colombo.pptx
Lorenzo D'Emidio_Vita di Cristoforo Colombo.pptxLorenzo D'Emidio_Vita di Cristoforo Colombo.pptx
Lorenzo D'Emidio_Vita di Cristoforo Colombo.pptxlorenzodemidio01
 
Lorenzo D'Emidio- Lavoro sulla Bioarchittetura.pptx
Lorenzo D'Emidio- Lavoro sulla Bioarchittetura.pptxLorenzo D'Emidio- Lavoro sulla Bioarchittetura.pptx
Lorenzo D'Emidio- Lavoro sulla Bioarchittetura.pptxlorenzodemidio01
 

Recently uploaded (6)

Lorenzo D'Emidio_Francesco Petrarca.pptx
Lorenzo D'Emidio_Francesco Petrarca.pptxLorenzo D'Emidio_Francesco Petrarca.pptx
Lorenzo D'Emidio_Francesco Petrarca.pptx
 
XIII Lezione - Arabo G.Rammo @ Libera Accademia Romana
XIII Lezione - Arabo G.Rammo @ Libera Accademia RomanaXIII Lezione - Arabo G.Rammo @ Libera Accademia Romana
XIII Lezione - Arabo G.Rammo @ Libera Accademia Romana
 
Lorenzo D'Emidio_Vita e opere di Aristotele.pptx
Lorenzo D'Emidio_Vita e opere di Aristotele.pptxLorenzo D'Emidio_Vita e opere di Aristotele.pptx
Lorenzo D'Emidio_Vita e opere di Aristotele.pptx
 
XI Lezione - Arabo LAR Giath Rammo @ Libera Accademia Romana
XI Lezione - Arabo LAR Giath Rammo @ Libera Accademia RomanaXI Lezione - Arabo LAR Giath Rammo @ Libera Accademia Romana
XI Lezione - Arabo LAR Giath Rammo @ Libera Accademia Romana
 
Lorenzo D'Emidio_Vita di Cristoforo Colombo.pptx
Lorenzo D'Emidio_Vita di Cristoforo Colombo.pptxLorenzo D'Emidio_Vita di Cristoforo Colombo.pptx
Lorenzo D'Emidio_Vita di Cristoforo Colombo.pptx
 
Lorenzo D'Emidio- Lavoro sulla Bioarchittetura.pptx
Lorenzo D'Emidio- Lavoro sulla Bioarchittetura.pptxLorenzo D'Emidio- Lavoro sulla Bioarchittetura.pptx
Lorenzo D'Emidio- Lavoro sulla Bioarchittetura.pptx
 

bootp e dhcp sistemi e reti 2018/19

  • 1. BOOTP e DHCP Sistemi e Reti Prof. Pierpaolo Mannone
  • 2. Il bootstrap dei sistemi Per configurare in modo automatico gli host di una reteTCP/IP sono stati definiti in ambito IETF alcuni protocolli. Uno dei primi e più diffusi è stato il protocollo BOOTP (BOOTstrap Protocol), necessario per mettere in comunicazione un computer privo di disco e un secondo host che gli deve fornire le informazioni di rete.
  • 3. BOOTP e DHCP BOOTP e DHCP • sono protocolli che permettono di assegnare ad un host tutti i valori necessari per consentirgli di operare sulla rete • l’indirizzo IP • la netmask • l’indirizzo di un router • l’indirizzo di un name server operano come applicazioni e non interagiscono direttamente con l’hardware • DHCP è un’estensione di BOOTP
  • 4. BOOTP BOOTP • usa le porte UDP 67 (server) e 68 (client) • Il client spedisce il primo messaggio all’indirizzo 255.255.255.255 con indirizzo sorgente 0.0.0.0 • 255.255.255.255 è l’indirizzo di broadcast • Il modulo IP invia un datagram all’indirizzo di broadcast limitato anche se non viene specificato l’indirizzo sorgente • I server BOOTP che ricevono il messaggio rispondono con i dati necessari „il client utilizza solo la prima risposta ricevuta
  • 5. Configurazione Dynamic Host Configuration Protocol (DHCP) Il protocollo DHCP, evoluzione di BOOTP, è nato per soddisfare le esigenze di mobilità dei computer portatili. Si basa sul concetto di lease, «affitto», degli indirizzi per un periodo limitato di tempo. Con lo sviluppo di DHCP aumentano i parametri necessari per configurare un host. Si analizzano nel dettaglio il life cycle dell’affitto di un indirizzo IP e i sei stati di un DHCP Client, con le transizioni che avvengono tra essi.
  • 6. La macchina a stati finiti (FSM) del DHCP Client
  • 7. Gli stati del DHCP Client • INITIALIZE : Quando un client viene inizializzato per la prima volta. • SELECT: Quando tenta di acquisire un IP contattando i DHCP Server. In questo stato il client raccoglie le risposte DHCPOFFER dai DHCP Server. • REQUEST Il client deve scegliere una delle risposte e concordare con il server la durata del lease, inviando al server un messaggio DHCPREQUEST. • Per confermare la ricezione della richiesta e attivare il lease, il server risponde con il messaggio DHCPACK. L’arrivo della conferma di ricezione fa sì che il client passi allo stato BOUND, in cui usa l’indirizzo assegnatogli, memorizza i parametri che il server gli ha inviato e imposta due timer: • renewal timer (T1): è il timer che indica al client quando è il momento di effettuare una richiesta di rinnovo dell’indirizzo; • 2. rebinding timer (T2): è il timer che indica al client che è scaduto il tempo per rinnovare l’indirizzo IP. • Lo stato di BOUND è il normale stato di funzionamento del client, che permane per tutto il tempo di utilizzo dell’indirizzo IP acquisito
  • 8. Il rinnovo del lease dell’indirizzo IP Quando il DHCP Client entra nello stato BOUND, imposta i timer che controllano il rinnovo, la conferma e la scadenza del lease. Il valore a cui impostare questi timer può essere specificato dal DHCP Server oppure il client può usare quelli predefiniti. Il valore predefinito del renew al timer è la metà del tempo totale del lease; quando scade, il client passa nello stato RENEW e invia un messaggio DHCPREQUEST al server da cui ha ottenuto il lease. In questo messaggio è contenuto l’indirizzo IP del quale richiede l’estensione di utilizzo. Il server risponde in due modi: • comunica al client di interrompere l’uso dell’indirizzo, inviando un messaggio DHCPNACK; il client ritorna nello stato INITIALIZE; • ne approva ancora l’utilizzo, inviando al client un messaggio DHCPACK che lo fa tornare nello stato BOUND impostando nuovamente i timer. Quando il client passa nello stato RENEW utilizza il rebinding timer per gestire il caso in cui il server al quale ha inviato la richiesta di rinnovo non possa rispondere, perché è diventato inattivo o non è più raggiungibile. Questo timer è impostato quando il client passa nellostato BOUND e il valore predefinito è l’87,5% del periodo di lease. Quando scade questo timer il client passa nello stato REBIND e invia in broadcast sulla rete locale un messaggio DHCPREQUEST.A questo punto si possono avere tre casi: 1. un server della rete risponde positivamente con un messaggio DHCPACK e il lease dell’indirizzo è prorogato, il client ritorna nello stato BOUND e imposta nuovamente i timer; 2. un server della rete risponde negativamente con un messaggio DHCPNACK, il client deve smettere di usare l’indirizzo IP e passare nello stato INITIALIZE per richiederne uno nuovo; 3. nessun server risponde alla richiesta del client (caso raro), scade il periodo di lease e il client deve smettere di utilizzare l’indirizzo IP, passa quindi nello stato INITIALIZE e avvia la procedura per acquisirne uno nuovo.
  • 9. DHCP relay agent • I messaggi inviati in broadcast sono propagati solo nella rete locale • un relay agent (agente di ritrasmissione) che riceve le richieste da un DHCP Client e le inoltra al DHCP Server, il quale invierà poi la risposta al relay agent, che a sua volta la inoltrerà al client.
  • 10. DHCP relay agent • Client Request: quando un client invia una richiesta, il relay agent la intercetta sulla porta UDP 67, controlla se il campo hops è inferiore a 16 (in caso contrario scarta la richiesta) e scrive il proprio indirizzo nel campo GIAddr (o, meglio, l’indirizzo dell’interfaccia dalla quale ha ricevuto il messaggio, nell’esempio in figura 4 l’indirizzo dell’interfaccia del router è 192.204.18.1) e invia il messaggio al DHCP Server; • Server Reply: il server verifica se il campo GIAddr contiene un valore diverso da zero, in tal caso invia la risposta all’indirizzo del relay agent il quale, a sua volta, la inoltra al DHCP Client. Il DHCP Server utilizza il campo GIAddr per determinare il pool di indirizzi dal quale prelevare l’indirizzo IP da assegnare al client.
  • 11. Sicurezza Si affronta il problema della sicurezza nell’uso di DHCP sia lato server sia lato client. • DHCP Server non autorizzati: invio informazioni errate/malevoli ai client. • DHCP Client non autorizzati: client spuffing o esaurimento degli indirizzi tramite software malevoli.
  • 12. Configurazione di un computer Linux in LAN