5. Costanti DHCP
5. Costanti DHCP
Questa sezione descrive varie costanti di programma e di rete utilizzate da DHCP.
5.1. Indirizzi multicast
DHCP fa uso dei seguenti indirizzi multicast:
- All_DHCP_Relay_Agents_and_Servers (FF02::1:2) — Un indirizzo multicast con ambito di link (link-scoped) utilizzato da un client per comunicare con agenti di relay e server vicini (cioè sul link). Tutti i server e gli agenti di relay sono membri di questo gruppo multicast.
- All_DHCP_Servers (FF05::1:3) — Un indirizzo multicast con ambito di sito (site-scoped) utilizzato da un agente di relay per comunicare con i server, sia perché l'agente di relay vuole inviare messaggi a tutti i server sia perché non conosce gli indirizzi unicast dei server. Si noti che affinché un agente di relay possa usare questo indirizzo, deve avere un indirizzo di ambito sufficiente per essere raggiungibile dai server. Tutti i server all'interno del sito sono membri di questo gruppo multicast.
5.2. Porte UDP
I client ascoltano i messaggi DHCP sulla porta UDP 546. I server e gli agenti di relay ascoltano i messaggi DHCP sulla porta UDP 547.
5.3. Tipi di messaggio DHCP
DHCP definisce i seguenti tipi di messaggio. Maggiori dettagli su questi tipi di messaggio sono disponibili nelle sezioni 6 e 7. I tipi di messaggio non elencati qui sono riservati per usi futuri. La codifica numerica di ciascun tipo di messaggio è mostrata tra parentesi.
- SOLICIT (1) — Un client invia un messaggio Solicit per individuare i server.
- ADVERTISE (2) — Un server invia un messaggio Advertise per indicare che è disponibile per il servizio DHCP, in risposta a un messaggio Solicit ricevuto da un client.
- REQUEST (3) — Un client invia un messaggio Request per richiedere parametri di configurazione, inclusi gli indirizzi IP, a un server specifico.
- CONFIRM (4) — Un client invia un messaggio Confirm a qualsiasi server disponibile per determinare se gli indirizzi a esso assegnati sono ancora appropriati al link a cui il client è connesso.
- RENEW (5) — Un client invia un messaggio Renew al server che originariamente ha fornito gli indirizzi e i parametri di configurazione del client per estendere i tempi di vita sugli indirizzi assegnati al client e per aggiornare altri parametri di configurazione.
- REBIND (6) — Un client invia un messaggio Rebind a qualsiasi server disponibile per estendere i tempi di vita sugli indirizzi assegnati al client e per aggiornare altri parametri di configurazione; questo messaggio è inviato dopo che un client non riceve risposta a un messaggio Renew.
- REPLY (7) — Un server invia un messaggio Reply contenente indirizzi assegnati e parametri di configurazione in risposta a un messaggio Solicit, Request, Renew o Rebind ricevuto da un client. Un server invia un messaggio Reply contenente parametri di configurazione in risposta a un messaggio Information-request. Un server invia un messaggio Reply in risposta a un messaggio Confirm confermando o negando che gli indirizzi assegnati al client siano appropriati al link a cui il client è connesso. Un server invia un messaggio Reply per acknowledgment della ricezione di un messaggio Release o Decline.
- RELEASE (8) — Un client invia un messaggio Release al server che ha assegnato gli indirizzi al client per indicare che il client non utilizzerà più uno o più degli indirizzi assegnati.
- DECLINE (9) — Un client invia un messaggio Decline a un server per indicare che ha determinato che uno o più indirizzi assegnati dal server sono già in uso sul link a cui il client è connesso.
- RECONFIGURE (10) — Un server invia un messaggio Reconfigure a un client per informarlo che il server ha nuovi o aggiornati parametri di configurazione e che il client deve avviare una transazione Renew/Reply o Information-request/Reply con il server per ricevere le informazioni aggiornate.
- INFORMATION-REQUEST (11) — Un client invia un messaggio Information-request a un server per richiedere parametri di configurazione senza l'assegnazione di alcun indirizzo IP al client.
- RELAY-FORW (12) — Un agente di relay invia un messaggio Relay-forward per inoltrare messaggi ai server, direttamente o tramite un altro agente di relay. Il messaggio ricevuto, sia un messaggio client sia un messaggio Relay-forward da un altro agente di relay, è incapsulato in un'opzione nel messaggio Relay-forward.
- RELAY-REPL (13) — Un server invia un messaggio Relay-reply a un agente di relay contenente un messaggio che l'agente di relay consegna a un client. Il messaggio Relay-reply può essere inoltrato da altri agenti di relay per la consegna all'agente di relay di destinazione. Il server incapsula il messaggio client come un'opzione nel messaggio Relay-reply, che l'agente di relay estrae e inoltra al client.
5.4. Codici di stato
DHCPv6 usa codici di stato per comunicare il successo o il fallimento delle operazioni richieste nei messaggi da client e server e per fornire informazioni aggiuntive sulla causa specifica del fallimento di un messaggio. I codici di stato specifici sono definiti nella sezione 24.4.
5.5. Parametri di trasmissione e ritrasmissione
Questa sezione presenta una tabella di valori utilizzati per descrivere il comportamento di trasmissione dei messaggi di client e server.
| Parametro | Default | Descrizione |
|---|---|---|
| SOL_MAX_DELAY | 1 sec | Ritardo massimo del primo Solicit |
| SOL_TIMEOUT | 1 sec | Timeout iniziale del Solicit |
| SOL_MAX_RT | 120 secs | Valore massimo di timeout del Solicit |
| REQ_TIMEOUT | 1 sec | Timeout iniziale del Request |
| REQ_MAX_RT | 30 secs | Valore massimo di timeout del Request |
| REQ_MAX_RC | 10 | Tentativi massimi di ritrasmissione del Request |
| CNF_MAX_DELAY | 1 sec | Ritardo massimo del primo Confirm |
| CNF_TIMEOUT | 1 sec | Timeout iniziale del Confirm |
| CNF_MAX_RT | 4 secs | Timeout massimo del Confirm |
| CNF_MAX_RD | 10 secs | Durata massima del Confirm |
| REN_TIMEOUT | 10 secs | Timeout iniziale del Renew |
| REN_MAX_RT | 600 secs | Valore massimo di timeout del Renew |
| REB_TIMEOUT | 10 secs | Timeout iniziale del Rebind |
| REB_MAX_RT | 600 secs | Valore massimo di timeout del Rebind |
| INF_MAX_DELAY | 1 sec | Ritardo massimo del primo Information-request |
| INF_TIMEOUT | 1 sec | Timeout iniziale dell'Information-request |
| INF_MAX_RT | 120 secs | Valore massimo di timeout dell'Information-request |
| REL_TIMEOUT | 1 sec | Timeout iniziale del Release |
| REL_MAX_RC | 5 | Tentativi massimi del Release |
| DEC_TIMEOUT | 1 sec | Timeout iniziale del Decline |
| DEC_MAX_RC | 5 | Tentativi massimi del Decline |
| REC_TIMEOUT | 2 secs | Timeout iniziale del Reconfigure |
| REC_MAX_RC | 8 | Tentativi massimi del Reconfigure |
| HOP_COUNT_LIMIT | 32 | Conteggio massimo di hop in un messaggio Relay-forward |
5.6 Rappresentazione di valori temporali e di "Infinity" come valore temporale
Tutti i valori temporali per tempi di vita, T1 e T2 sono interi senza segno. Il valore 0xffffffff è interpretato come "infinity" (infinito) quando usato come tempo di vita (come in RFC2461 [17]) o come valore per T1 o T2.