Dynamic Host Configuration Protocol: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
fix |
|||
| (33 versioni intermedie di 18 utenti non mostrate) | |||
Riga 1:
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 ===
Il compito di assegnare ''manualmente'' gli indirizzi IP ai calcolatori comporta infatti un rilevante onere per gli [[sistemista|amministratori di rete]], soprattutto in reti di grandi dimensioni o in caso di numerosi [[computer]] che si connettono a rotazione solo a ore o giorni determinati. Inoltre gli indirizzi [[IPv4]] disponibili (attualmente usati nella quasi totalità delle reti al mondo) con l'aumentare dei computer connessi a [[Internet]] hanno cominciato a scarseggiare, diminuendo la disponibilità di IP fissi per eventuali configurazioni ''statiche''.
Riga 9 ⟶ 11:
DHCP supporta questo compito automaticamente e in maniera dinamica, cioè solo quando richiesto dall'host. Viene utilizzato soprattutto in [[rete locale|reti locali]], in particolare su [[Ethernet]]. In altri contesti, funzioni simili sono svolte all'interno di [[Point-to-Point Protocol|PPP]]. Una volta ricevuta la configurazione di rete la stazione o [[computer]] della rete locale diventa a tutti gli effetti un [[host]] (''ospite'') della rete Internet e può intraprendere sessioni di navigazione [[Web]] e tutti gli altri servizi offerti dalla rete stessa. Infatti, un servizio DHCP è svolto anche da un semplice [[router]] di casa.
A seconda dell'implementazione, il server DHCP può avere tre metodi di allocazione degli indirizzi IP:▼
=== Allocazione dinamica ===▼
È 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' di indirizzi, il server DHCP riutilizza indirizzi affittati col tempo scaduto▼
=== Allocazione automatica ===▼
Il server DHCP assegna automaticamente un indirizzo IP a un client richiedente nell'intervallo definito dall'amministratore. Questo è come nell'allocazione dinamica, ma il server DHCP mantiene una tabella delle assegnazioni degli indirizzi IP passati, in modo che possa assegnare preferenzialmente a un client lo stesso indirizzo IP precedente.▼
=== Allocazione manuale (comunemente chiamata allocazione statica) ===▼
Il server DHCP emette un indirizzo IP privato dipendente dal [[Indirizzo 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 [[Mac 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.▼
▲== Componenti del protocollo ==
Il [[client]] DHCP è un calcolatore che ha bisogno di ottenere un indirizzo IP valido per la sottorete a cui è collegato, è anche il programma che si occupa di richiedere l'indirizzo IP e configurarlo.
Riga 32 ⟶ 18:
Il DHCP ''relay'' è il calcolatore (o più spesso una funzione implementata in un [[router]]) che si occupa di inoltrare le richieste DHCP ad un server, qualora questo non sia sulla stessa sottorete. Questo componente è necessario solo se un server DHCP deve servire molteplici sottoreti. Deve esistere almeno un DHCP relay per ciascuna sottorete servita. Ogni relay deve essere esplicitamente configurato per inoltrare le richieste a uno o più server.
=== 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 46 ⟶ 30:
Nel protocollo c'è comunque il supporto per assegnare tramite DHCP molti altri parametri, definiti nell'RFC 2132.
Nelle piccole reti, in cui viene gestita una sola subnet IP, i client DHCP comunicano direttamente con i server DHCP. Tuttavia, i server DHCP possono anche fornire indirizzi IP per più sottoreti. In questo caso, un client DHCP che non ha ancora acquisito un indirizzo IP non può comunicare direttamente con il server DHCP utilizzando il routing IP, perché non ha un indirizzo IP con router, non conosce l'indirizzo IP di un router e non conosce l'indirizzo IP del server DHCP.▼
Per consentire ai client DHCP su sottoreti non direttamente servite dai server DHCP di comunicare con i server DHCP, è possibile installare agenti di inoltro DHCP su queste sottoreti. Il client DHCP trasmette sul collegamento locale; il relay agent riceve la trasmissione e la trasmette a uno o più server DHCP utilizzando l'[[unicast]]. Il relay agent memorizza il proprio indirizzo IP nel campo GIADDR del pacchetto DHCP. Il server DHCP utilizza GIADDR per determinare la sottorete su cui il relay agent ha ricevuto la trasmissione e assegna un indirizzo IP su quella sottorete. Quando il server DHCP risponde al client, invia la risposta all'indirizzo GIADDR, usando ancora l'unicast. Il relay agent quindi ritrasmette la risposta sulla rete locale.▼
In questa situazione, la comunicazione tra il relay agent e il server DHCP, utilizza in genere la porta 67 UDP di origine e di destinazione. ▼
== Modalità di assegnazione indirizzi IP ==
▲A seconda dell'implementazione, il server DHCP può avere tre metodi di allocazione degli indirizzi IP:
▲=== Allocazione dinamica ===
▲È 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
▲=== Allocazione automatica ===
▲Il server DHCP assegna automaticamente un indirizzo IP a un client richiedente nell'intervallo definito dall'amministratore. Questo è come nell'allocazione dinamica, ma il server DHCP mantiene una tabella delle assegnazioni degli indirizzi IP passati, in modo che possa assegnare preferenzialmente a un client lo stesso indirizzo IP precedente.
▲=== Allocazione manuale (comunemente chiamata allocazione statica) ===
▲Il server DHCP emette un indirizzo IP privato dipendente dal
▲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.
== 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 54 ⟶ 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 [[
▲* 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 62 ⟶ 69:
* Il client aspetta per un certo tempo di ricevere una o più offerte, dopodiché ne seleziona una, e invia un pacchetto di DHCPREQUEST (o DHCPACCEPT) in broadcast, indicando all'interno del pacchetto, con il campo "server identifier", quale server ha selezionato. Anche questo pacchetto raggiunge tutti i server DHCP presenti sulla rete (direttamente o tramite un relay).
* Il server che è stato selezionato conferma l'assegnazione dell'indirizzo con un pacchetto di DHCPACK (nuovamente indirizzato in
=== Scadenza e rinnovo degli indirizzi ===
A questo punto, il client è autorizzato a usare l'indirizzo ricevuto per un tempo limitato, detto ''tempo di lease''. Prima della scadenza, dovrà tentare di rinnovarlo inviando un nuovo pacchetto DHCPREQUEST al server, che gli risponderà con un DHCPACK se vuole prolungare l'assegnazione dell'indirizzo. Questi sono normali pacchetti IP [[unicast]] scambiati tra due calcolatori che hanno indirizzi validi. Se il client non riesce a rinnovare l'indirizzo, tornerà allo stato iniziale cercando di farsene attribuire un altro.
=== Identificazione e autenticazione dei client ===
Il client si identifica verso il server attraverso un campo client-id dei pacchetti DHCP. Questo campo ha normalmente come valore l'[[indirizzo MAC]] della scheda di rete per cui si richiede l'indirizzo, ma può anche essere configurato manualmente. Questa è l'unica forma di autenticazione disponibile per DHCP, ed è piuttosto debole, in quanto utilizza un dato che viene inviato in broadcast sulla rete locale, e quindi può essere facilmente trovato da qualunque altro calcolatore connesso alla stessa rete. Per controllare l'accesso a una rete esistono metodi più solidi che, però, richiedono un supporto da parte degli [[switch]] a cui sono collegati gli utenti, come [[IEEE 802.1x]].
Riga 81 ⟶ 86:
=== Identificazione del server ===
Il server si identifica verso il client con il proprio indirizzo IP. Un client potrebbe quindi decidere di accettare indirizzi solo da un server già noto.
Riga 92 ⟶ 96:
Per prevenire questi rischi, alcuni [[switch]] offrono una funzionalità detta [[DHCP snooping]], per cui analizzano tutti i pacchetti DHCP che li attraversano, fermando quelli che non sono originati da server autorizzati.
== Visualizzazione della configurazione IP ==▼
▲== Inoltro DHCP ==
I sistemi Windows offrono un comando da digitare direttamente da [[Shell (informatica)|shell]], detto ''ipconfig (Interface configuration),'' che permette di conoscere la configurazione IP del proprio computer. Il comando ''ipconfig'' permette di avere numerose informazioni sulla configurazione e sullo stato dell'interfaccia di rete. Il comando:▼
▲Nelle piccole reti, in cui viene gestita una sola subnet IP, i client DHCP comunicano direttamente con i server DHCP. Tuttavia, i server DHCP possono anche fornire indirizzi IP per più sottoreti. In questo caso, un client DHCP che non ha ancora acquisito un indirizzo IP non può comunicare direttamente con il server DHCP utilizzando il routing IP, perché non ha un indirizzo IP con router, non conosce l'indirizzo IP di un router e non conosce l'indirizzo IP del server DHCP.
* ipconfig /all▼
permette di visualizzare tutte le interfacce di rete presenti su un computer, e fornisce informazioni più dettagliate rispetto al precedente comando.▼
I sistemi [[Unix]] e [[Unix-like]] come LINUX offrono il comando [[ifconfig]] da digitare da [[Shell (informatica)|shell]] che permette di conoscere la configurazione IP del proprio computer. ▼
▲Per consentire ai client DHCP su sottoreti non direttamente servite dai server DHCP di comunicare con i server DHCP, è possibile installare agenti di inoltro DHCP su queste sottoreti. Il client DHCP trasmette sul collegamento locale; il relay agent riceve la trasmissione e la trasmette a uno o più server DHCP utilizzando l'[[unicast]]. Il relay agent memorizza il proprio indirizzo IP nel campo GIADDR del pacchetto DHCP. Il server DHCP utilizza GIADDR per determinare la sottorete su cui il relay agent ha ricevuto la trasmissione e assegna un indirizzo IP su quella sottorete. Quando il server DHCP risponde al client, invia la risposta all'indirizzo GIADDR, usando ancora l'unicast. Il relay agent quindi ritrasmette la risposta sulla rete locale.
== Aspetti dibattuti ==
▲In questa situazione, la comunicazione tra il relay agent e il server DHCP, utilizza in genere la porta 67 UDP di origine e di destinazione.
=== Affidabilità delle comunicazioni ===▼
Il DHCP garantisce l'affidabilità in diversi modi: rinnovo periodico, rebinding<ref name="Nome BOOTPS">Droms, Ralph (March 1997).[
Se il server DHCP è irraggiungibile per un lungo periodo di tempo,<ref name="Nome BOOTPS"/> il client DHCP tenterà di
▲== Affidabilità ==
▲Il DHCP garantisce l'affidabilità in diversi modi: rinnovo periodico, rebinding<ref name="Nome BOOTPS">Droms, Ralph (March 1997).[https://tools.ietf.org/html/rfc2131 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, trasmettendo il suo DHCPREQUEST piuttosto che in unicast. Una volta trasmesso, il messaggio DHCPREQUEST raggiungerà tutti i server DHCP disponibili. Se 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 108 ⟶ 113:
Se il rebinding fallisce, il lease alla fine scadrà. Quando il lease scade, il client deve smettere di utilizzare l'inidirizzo IP a esso concesso nel suo leasing.<ref name="Nome BOOTPS"/> A quel punto riavvierà il processo DHCP dall'inizio trasmettendo un messaggio DHCPDISCOVER. Dal momento che il leasing è scaduto, accetterà qualsiasi indirizzo IP offerto. Una volta che ha un nuovo indirizzo (presumibilmente da un server DHCP diverso) sarà di nuovo in grado di utilizzare la rete. Tuttavia, poiché il suo indirizzo IP è cambiato, tutte le connessioni in corso verranno interrotte.
== Sicurezza informatica ==
Il DHCP base non include alcun meccanismo per l'autenticazione.<ref name="Nome AUTENTICAZIONE">Michael Patrick (January 2001).[https://tools.ietf.org/html/rfc3046#section-7 "RFC 3046-DHCP Relay Agent Information Option".] Network Working Group.</ref> Per questo motivo, è vulnerabile a vari attacchi. Questi attacchi si dividono in tre categorie principali:
*I server DHCP non autorizzati forniscono informazioni false ai client.<ref name="Nome RFC2131">Ralph Droms (March 1997).[https://tools.ietf.org/html/rfc2131#section-7 "RFC 2131-Dynamic Host Configuration Protocol".] Network Working Group.</ref>
Riga 120 ⟶ 124:
Un libro del 2007 sulle tecnologie DSL ha rilevato che "sono state individuate numerose vulnerabilità di sicurezza contro le misure di sicurezza proposte da RFC 3118. Questo fatto, combinato con l'introduzione di [[IEEE 802.1x|802.1x]], ha rallentato la distribuzione e il tasso di DHCP autenticati e non è mai stato ampiamente diffuso ".<ref>Philip Golden; Hervé Dedieu; Krista S. Jacobsen (2007).[https://books.google.it/books?id=Jjkd74jY47oC&pg=PA484&redir_esc=y#v=onepage&q&f=false Implementation and Applications of DSL Technology] Taylor & Francis. p. 484.ISBN 978-1-4200-1307-8</ref> Un libro del 2010 rileva che "ci sono state pochissime implementazioni di autenticazione DHCP. I problemi di gestione delle chiavi e dei ritardi di elaborazione sono stati ritenuti un prezzo troppo alto da pagare per benefici percepiti".<ref>Timothy Rooney (2010).[https://books.google.it/books?id=QgRDxkuI1MkC&pg=PA181&redir_esc=y#v=onepage&q&f=false Introduction to IP Address Management] John Wiley & Sons. pp. 181–182.ISBN 978-1-118-07380-3</ref>
Delle proposte architettoniche più recenti (2008) implicano l'autenticazione delle richieste DHCP usando 802.1x o [[Protocol for Carrying Authentication for Network Access|PANA]] (i quali trasportano l'[[Extensible Authentication Protocol|EAP]]).<ref>Rebecca Copeland (2008).[https://books.google.it/books?id=ruWv8RGkBGgC&pg=PA142&redir_esc=y#v=onepage&q&f=false Converging NGN Wireline and Mobile 3G Networks with IMS] Taylor & Francis. pp. 142–143.ISBN 978-1-4200-1378-8</ref> Una proposta di IETF è stata fatta per includere EAP in DHCP stesso, il cosiddetto EAPoDHCP;<ref>Ramjee Prasad; Albena Mihovska (2009).[https://books.google.it/books?id=w9bEwBwd33MC&pg=PA339&redir_esc=y#v=onepage&q&f=false New Horizons in Mobile and Wireless Communications:Networks, services, and applications.] 2. Artech House. p. 339. ISBN 978-1-60783-970-5</ref> questo non sembra aver superato il livello di IETF, l’ultimo del quale risale al 2010.<ref>[https://web.archive.org/web/20150403091552/http://tools.ietf.org/search/draft-pruss-dhcp-auth-dsl-07 "Archived copy"] Archived from[https://tools.ietf.org/search/draft-pruss-dhcp-auth-dsl-07 the original] on 2015-04-03. Retrieved 2013-12-12.</ref>
▲== Visualizzazione della configurazione IP ==
▲I sistemi Windows offrono un comando da digitare direttamente da [[Shell (informatica)|shell]], detto ''ipconfig (Interface configuration),'' che permette di conoscere la configurazione IP del proprio computer. Il comando ''ipconfig'' permette di avere numerose informazioni sulla configurazione e sullo stato dell'interfaccia di rete. Il comando:
▲* ipconfig /all
▲permette di visualizzare tutte le interfacce di rete presenti su un computer, e fornisce informazioni più dettagliate rispetto al precedente comando.
▲I sistemi [[Unix]] e [[Unix-like]] come LINUX offrono il comando [[ifconfig]] da digitare da [[Shell (informatica)|shell]] che permette di conoscere la configurazione IP del proprio computer.
== Note ==
<references />
== Bibliografia ==
* 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 137 ⟶ 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
| |||