Dynamic Host Configuration Protocol: differenze tra le versioni

Versione delle 14:51, 23 feb 2022

Versione attuale delle 15:28, 8 mar 2025

(31 versioni intermedie di 16 utenti non mostrate)

Riga 1:

'''Dynamic Host Configuration Protocol''' (in [[acronimo]] '''DHCP''', in italiano "protocollo di configurazione IP dinamica"), in [[telecomunicazioni]] e [[informatica]], indica un protocollo applicativo (ausiliario) che permette ai dispositivi o terminali di una certa [[rete locale]] di ricevere automaticamente ad ogni richiesta di accesso, da una rete IP (quale una [[Local area network|LAN]]), nonchè la configurazione [[indirizzo IP|IP]] necessaria per stabilire una [[connessione (informatica)|connessione]] e operare su una rete più ampia basata su [[Internet Protocol]].

Il protocollo è implementato come servizio di rete ovvero come tipologia di [[server]]: ad esempio nei sistemi [[Unix]] e [[Unix-like]] è implementato nel [[demone (informatica)|demone]] dhcpd, in quelli basati su [[Active Directory]] di [[Microsoft]] e/o [[Windows Server]] dal servizio server dhcp.

== Generalità ==

=== Descrizione e caratteristiche del DHCP ===

Esso consente l'[[interoperabilità]] con tutte le altre sotto-reti scambiandosi dati, purché anch'esse integrate allo stesso modo con il protocollo IP. Infatti in una rete basata sul protocollo [[Internet Protocol|IP]], ogni calcolatore ha bisogno di un [[indirizzo IP]], scelto in modo tale che appartenga all'insieme di indirizzi possibili assegnati all'intera [[sottorete]] (cioè al Net_ID) a cui è collegato e che sia univoco, cioè non ci siano altri calcolatori che stiano già utilizzando quell'indirizzo.

Riga 20:

=== Parametri gestiti ===

Il protocollo DHCP viene usato anche per assegnare al computer diversi parametri necessari per il suo corretto funzionamento sulla rete a cui è collegato. Tra i più comuni, oltre all'assegnazione dinamica dell'indirizzo IP, si possono citare:

* Maschera di [[sottorete]]

* Default [[gateway (informatica)|gateway]]

Riga 45 ⟶ 44:

È l'allocazione automatica di indirizzi temporanei.

L'allocazione dinamica per un periodo dato viene chiamata 'affitto' (lease). Il client la può estendere tramite ulteriore richiesta o può rilasciare l'indirizzo affittato in qualsiasi momento se non serve più. In caso di scarsita'scarsità di indirizzi, il server DHCP riutilizza indirizzi affittati col tempo scaduto

=== Allocazione automatica ===

Riga 51 ⟶ 50:

=== Allocazione manuale (comunemente chiamata allocazione statica) ===

Il server DHCP emette un indirizzo IP privato dipendente dal '[[Indirizzoindirizzo MAC|]] (''MAC address]]'') di ciascun client, basato su una mappatura predefinita da parte dell'amministratore. Questa funzione è denominata in vari modi : come assegnazione ''DHCP statica'' nel [[DD-WRT]], ''indirizzo fisso'' dalla documentazione dhcpd, ''prenotazione indirizzo'' da [[Netgear]], ''prenotazione DHCP'' o ''DHCP statico'' da parte di [[Cisco Systems|Cisco]] e [[Linksys]] e ''prenotazione indirizzo IP'' o ''binding indirizzo MAC/IP'' da vari altri produttori di router . Se non viene rilevata alcuna corrispondenza per il l'[[Macindirizzo address|MAC address]] del client, il server può facoltativamente non ricorrere all'assegnazione dinamica o automatica.

DHCP viene utilizzato per [[IPv4|Internet Protocol versione 4]] (IPv4), nonché per l'[[IPv6]]. Sebbene entrambe le versioni abbiano lo stesso scopo, i dettagli del protocollo per IPv4 e IPv6 differiscono sufficientemente da poter essere considerati due protocolli separati.<ref>{{cita libro |autore=Ralph Droms |autore2=Ted Lemon |anno=2003 |titolo=The DHCP Handbook |url=https://archive.org/details/dhcphandbook00drom |editore=Sams Publishing |p=[https://archive.org/details/dhcphandbook00drom/page/436 436] |ISBN=978-0672323270|lingua=en}}</ref> Per l'operazione [[IPv6]], i dispositivi possono utilizzare in alternativa l'autoconfigurazione dell'indirizzo stateless. Gli host IPv6 possono anche utilizzare l'indirizzamento locale del collegamento per ottenere operazioni limitate al collegamento di rete locale.

Riga 57 ⟶ 56:

== Richiesta e attribuzione dell'indirizzo ==

[[File:DHCP session.svg|thumb|right|upright=1.2|Un'immagine che mostra una sessione tipica DHCP; ogni messaggio potrebbe essere sia [[Broadcasting (informatica)|broadcast]] che [[unicast]], a seconda delle capacità del client DHCP<ref>[https://tools.ietf.org/html/rfc2131#section-4.1 RFC 2131, Section 4.1 Constructing and sending DHCP messages]</ref>]]

DHCP utilizza il [[protocollo di rete|protocollo]] [[User Datagram Protocol|UDP]], le porte registrate sono la 67 per il server e la 68 per il client.

Riga 62:

La procedura descritta dal protocollo consta di diversi [[handshake]] tra client e server, ovvero scambio di pacchetti, ovviamente tutti [[imbustamento|incapsulati]] in [[data frame|frame]] di [[livello datalink]], come [[Ethernet]]:

* In primis, il client invia un pacchetto chiamato DHCPDISCOVER in [[BroadcastBroadcasting (disambiguainformatica)|broadcast]], con indirizzo IP sorgente messo convenzionalmente a 0.0.0.0, e destinazione 255.255.255.255 ([[indirizzo di broadcast]]).

* In primis, il client invia un pacchetto chiamato DHCPDISCOVER in [[Broadcast (disambigua)|broadcast]], con indirizzo IP sorgente messo convenzionalmente a 0.0.0.0, e destinazione 255.255.255.255 ([[indirizzo di broadcast]]).

* Il pacchetto è ricevuto da tutti gli host presenti nello stesso [[dominio di broadcast]], e quindi da eventuali server DHCP presenti, i quali possono rispondere (o meno) con un pacchetto di DHCPOFFER in cui propongono un indirizzo IP e gli altri parametri di configurazione al client. Questo pacchetto di ritorno è indirizzato all'indirizzo di [[livello datalink]] del client (al suo MAC address - non ha ancora un indirizzo IP) ovvero in [[unicast]].

Riga 106 ⟶ 105:

== Aspetti dibattuti ==

=== Affidabilità delle comunicazioni ===

Il DHCP garantisce l'affidabilità in diversi modi: rinnovo periodico, rebinding<ref name="Nome BOOTPS">Droms, Ralph (March 1997).[httpsrfc://tools.ietf.org/html/rfc21312131 DHCP Options and BOOTP Vendor Extensions.] [[Internet Engineering Task Force|IETF.]] RFC 2131. Retrieved September 9, 2014.</ref> e failover. Ai client DHCP vengono assegnati leasing che durano per un certo periodo di tempo. I client iniziano a provare di rinnovare il leasing una volta che la metà dell'intervallo di lease è scaduto.<ref name="Nome BOOTPS"/> Lo fanno inviando un messaggio DHCPREQUEST in unicast al server DHCP che ha concesso il leasing originale. Se il server è inattivo o irraggiungibile,<ref name="Nome BOOTPS"/> non risponderà al DHCPREQUEST. Tuttavia, in questo caso il client ripete il DHCPREQUEST di volta in volta, quindi se il server DHCP viene ripristinato o diventa nuovamente raggiungibile, il client DHCP riuscirà a contattarlo e rinnovare il contratto di locazione.

Se il server DHCP è irraggiungibile per un lungo periodo di tempo,<ref name="Nome BOOTPS"/> il client DHCP tenterà di riassociare,rinnovare l'IP trasmettendo il suo DHCPREQUEST in broadcast piuttosto che in unicast. Una volta trasmesso, il messaggio DHCPREQUEST raggiungerà tutti i server DHCP disponibili.: Sese qualche altro server DHCP è in grado di rinnovare il leasing, lo farà in questo momento.

Affinché il rebinding funzioni, quando il client contatta con successo un server DHCP di backup, quel server deve disporre di informazioni accurate sull'associazione del client. Mantenere informazioni vincolanti precise tra due server è un problema complicato; se entrambi i server sono in grado di aggiornare lo stesso database di lease, deve esistere un meccanismo per evitare conflitti tra gli aggiornamenti sui server indipendenti. Una proposta per l'implementazione di server DHCP [[Tolleranza ai guasti|fault-tolerant]] è stata inviata alla Internet Engineering Task Force, ma mai formalizzata.<ref>Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (March 2003).[https://tools.ietf.org/html/draft-ietf-dhc-failover-12 DHCP Failover Protocol.] [[Internet Engineering Task Force|IETF.]] I-D draft-ietf-dhc-failover-12. Retrieved May 09, 2010.</ref>

Riga 128 ⟶ 127:

== Note ==

<references />

== Bibliografia ==

== ;Documenti standard IETF ==

* RFC 2131 - Dynamic Host Configuration Protocol

* RFC 1534 - Interoperation Between DHCP and BOOTP

* RFC 2132 - DHCP Options and BOOTP Vendor Extensions

* RFC 3046 - DHCP Relay Agent Information Option

* RFC 3118 - Authentication for DHCP Messages

== Voci correlate ==

Riga 135 ⟶ 142:

* [[DHCP snooping]]

* [[Network address translation]]

== Documenti standard IETF ==

* RFC 2131 - Dynamic Host Configuration Protocol

* RFC 1534 - Interoperation Between DHCP and BOOTP

* RFC 2132 - DHCP Options and BOOTP Vendor Extensions

* RFC 3046 - DHCP Relay Agent Information Option

* RFC 3118 - Authentication for DHCP Messages

== Altri progetti ==

{{interprogetto|preposizione=sul}}

== Collegamenti esterni ==

* {{FOLDOC}}

* [https://web.archive.org/web/20050102090919/http://www.isc.org/sw/dhcp/ Sito] del server DHCP prodotto dall'Internet Systems Consortium