2.3 PROTOCOLUL DE MESAJE DE CONTROL PENTRU INTERNET (ICMP)

� Protocolul IP = fără conexiune → se utilizează un mecanism (protocol) care permite oricărui ruter să semnaleze sistemului sursă o situaţie anormală apărută în rutarea unui pachet.

� Altă posibilă utilizare = testarea accesibilităţii unui sistem, adică dacă există o rută în funcţionare

normală până la acel sistem şi dacă sistemul este capabil să recepţioneze pachete.

� Soluţia = protocolul ICMP (Internet Control Message Protocol).

� Funcţiile ICMP:

o Ruterii transmit altor ruteri sau sistemelor mesaje de eroare sau de control (numai pentru

raportarea erorilor, nu pentru creşterea fiabilităţii IP); o Pentru datagrame fragmentate, mesajele ICMP sunt transmise numai pentru eventuale erori

produse în cazul primului fragment; o Mesajele ICMP nu sunt transmise ca răspuns la o problemă legată de o datagramă care nu are

adresa sursă ce desemnează un sistem unic (unicast) → adresa sursă nu poate fi zero, o adresă de transmisie în buclă (loopback), o adresă de difuzare (broadcast) sau o adresă de grup (multicast);

� Fiecare mesaj ICMP este inclus în câmpul de date al unui pachet (figura 2.28) (în antetul IP numărul de protocol ia valoarea 1 pentru ICMP, iar tipul de serviciu ia valoarea zero).

Fig. 2.28. Încapsularea mesajului ICMP.

� Pachetele care poartă mesaje ICMP sunt rutate la fel ca şi cele care transportă datele utilizatorului doar că, dacă apar erori în transmiterea acestor pachete ele nu generează alte mesaje ICMP.

� Există mai multe tipuri de mesaje ICMP, fiecare având formatul său propriu. Câmpul de date din

pachetul IP care conţine un mesaj ICMP este ilustrat în figura 2.29.

Fig. 2.29 Formatul mesajului ICMP.

� Identificator (tipul mesajului) – Acest câmp poate lua una dintre următoarele valori (8 biţi), în funcţie de tipul mesajului: o 0 - Răspuns ecou (Echo reply), o 3 - Destinaţie inaccesibilă (Destination unreachable), o 4 - Oprirea sursei (Source quench), o 5 - Redirectare, o 8 - Cerere ecou, o 9 - Anunţarea unui ruter, o 10 - Solicitarea unui ruter, o 11 - Depăşire timp, o 12 - Problemă legată de un parametru, o 13 - Cerere etichetă de timp, o 14 - Răspuns etichetă de timp, o 17 - Cerere mască de adrese, o 18 - Răspuns mască de adrese, o 30 - Descoperire rută (Traceroute), o 37 - Cerere nume domeniu, o 38 - Răspuns nume domeniu.

� Număr de secvenţă (cod) - Conţine codul erorii pentru datagrama raportată de acest mesaj ICMP.

Interpretarea acestui câmp depinde de tipul mesajului. Acest câmp furnizează informaţii suplimentare despre tipul mesajului.

� Suma de verificare - Conţine suma de verificare (16 biţi), folosind acelaşi algoritm ca şi IP dar

verificând numai mesajul ICMP, începând cu câmpul dedicat tipului mesajului. Dacă valoarea sumei nu coincide cu valoarea calculată la recepţie pe baza conţinutului recepţionat, atunci datagrama este eliminată.

� Câmpul de date al mesajului conţine informaţia corespunzătoare mesajului ICMP curent. De cele

mai multe ori, acest câmp conţine o porţiune din pachetul IP original, cel pentru care a fost generat mesajul ICMP curent.

Tipuri de mesaje ICMP:

� Mesajele de cerere ecou (echo request) şi răspuns ecou (echo replay). Un sistem de extremitate sau

un ruter poate transmite un mesaj cerere ecou către o anumită destinaţie. Sistemul sau ruterul de destinaţie care recepţionează acest mesaj răspunde prin mesajul răspuns ecou transmis către sursă. Cererea conţine un câmp de date opţionale. Răspunsul va conţine o copie a acestor date. În felul acesta se poate verifica dacă o anumită destinaţie este accesibilă şi răspunde.

� Destinaţie inaccesibilă (destination unreachable) este transmis de un ruter către sursă atunci când

acesta nu poate trece mai departe un pachet, spre un alt ruter sau direct spre sistemul de destinaţie.

� Mesajul de oprire a sursei (Source quench) este utilizat pentru a semnala înapoi la sursă o supraâncărcare a receptorului sau a sistemelor intermediare.

� Mesajul de redirectare este utilizat pentru a anunţa sursa să redirecteze pachetele pe o rută mai

bună. Dacă acest mesaj e recepţionat de la un ruter intermediar înseamnă că sistemul sursă ar trebui să trimită următoarele datagrame către ruterul a cărui adresă IP este specificată în mesajul ICMP. Acest ruter preferat va fi întotdeauna aflat în aceeaşi subreţea cu sistemul emitent al datagramei şi ruterul care a returnat datagrama.

� Mesajele Anunţare ruter şi Cerere ruter sunt utilizate numai dacă un sistem sau un ruter suportă un

protocol de descoperire a ruterilor. Ruterii anunţă periodic adresele lor IP în toate subreţelele pentru

care lucrează. Aceste anunţuri se transmit cu adresa de destinaţie multicast (224.0.0.1) sau cu adresa de difuzare limitată (255.255.255.255). Sistemele pot trimite, la rândul lor, mesaje de solicitare. Mesajele de solicitare sunt transmise tuturor ruterilor cu adresa multicast (224.0.0.2) sau cu adresa de difuzare limitată (255.255.255.255).

� Expirare timp. Dacă acest mesaj este recepţionat de la un ruter intermediar înseamnă că valoarea

din câmpul TTL a unui pachet IP a ajuns la zero. Dacă mesajul este recepţionat de la un sistem de destinaţie înseamnă că timpul TTL dintr-un fragment IP a expirat în timpul reasamblării, datorită întârzierii unui fragment.

� Mesajul Problemă cu parametrii indică producerea unei erori în timpul prelucrării parametrilor din

antetul IP. Acest mesaj conţine un pointer care indică octetul din pachetul IP original unde s-a produs problema.

� Mesajele Cerere etichetă de timp şi Răspuns etichetă de timp sunt utilizate pentru depanare şi

măsurare a performanţelor. Acestea nu sunt utilizate pentru sincronizarea de ceas. Transmiţătorul iniţializeză identificatorul şi numărul de secvenţă (care se utilizează în cazul în care sunt transmite mai multe etichete de timp), stabileşte eticheta iniţială de timp şi transmite pachetul către destinaţie. Staţie destinaţie actualizează etichetele de timp asociate recepţiei şi transmisiei, modifică tipul etichetei de timp din cerere în răspuns şi o returnează staţiei sursă. Pachetul conţine două etichete de timp dacă există o diferenţă semnificativă de timp între timpul de recepţie şi timpul de emisie.

� Mesajele Cerere de mască de adrese şi Răspuns cu mască de adrese. Cererea de mască de adrese

este utilizată de către un sistem pentru a determina masca subreţelei folosită în cadrul unei reţele asociate. Cele mai multe sisteme sunt configurate cu masca (sau măştile) de subreţea asociată. Totuşi, unele sisteme, cum ar fi staţiile de lucru fără disc, trebuie să obţină această informaţie de la server. Un sistem foloseşte protocolul RARP (Reverse Address Resolution Protocol) pentru a

obţine adresa sa IP. Pentru a obţine masca de subreţea, sistemul transmite prin difuzare cererea de mască de adresă.

� Mai există şi alte mesaje ICMP pentru semnalizarea unor situaţii de congestie (atunci când un ruter

este prea încărcat pentru a prelucra un nou pachet, care din acest motiv va fi pierdut), semnalizarea unei rutări ciclice (o rută infinită, propagare în buclă), etc.

2.4 PROTOCOLUL DE REZOLUŢIE A ADRESELOR (ARP)

� Protocoalele de rutare sunt responsabile pentru modul în care o datagramă IP ajunge în reţeaua fizică căreia îi este destinată, dar o altă procedură este necesară pentru modul în care o datagramă ajunge la sistemul sau ruterul din acea reţea.

� Datagramele IP conţin adrese globale logice, de nivel trei, dar interfaţa fizică hardware aflată în

sistemul destinaţie sau în ruterul destinaţie nu utilizează decât schema de adresare locală a acelei reţele. → Este nevoie să se efectueze translatarea adresei IP într-o adresă de nivel legătură de date care este înţeleasă de interfeţele din această reţea.

� Soluţie simplă: maparea unei adrese IP pe o adresă fizică, adică codarea adresei fizice a sistemului în

adresa IP a sistemului. De exemplu, un sistem cu o adresă fizică 0001000100101001 (care în zecimal înseamnă 33 pentru primul octet şi 81 pentru ultimul) poate avea adresa IP 128.96.33.81. Deşi această soluţie a fost adoptată pentru unele reţele, ea prezintă totuşi limitări din cauza faptului că adresa fizică nu poate fi mai mare de 16 biţi în acest exemplu (clasa B); pentru reţelele de clasă C nu poate depăşi 8 biţi. Această metodă nu funcţionează pentru adresele Ethernet pe 48 de biţi.

� O soluţie mai generală poate fi aceea ca fiecare sistem să menţină o tabelă de perechi de adrese, care să mapeze adresele IP pe cele fizice (dinamic sau static) → protocolul ARP (Address Resoludon Pro-tocol).

� Scopul ARP este acela de a permite fiecărui sistem din reţea să-şi construiască o tabelă de mapări

între adresele de IP şi cele fizice. Acest set de mapări este cunoscut sub numele de ARP cache sau tabelă ARP.

� Dacă un sistem doreşte să transmită o datagramă IP către un alt sistem aflat în aceeaşi reţea, acesta va

verifica în primul rând tabela ARP. Dacă nu este găsită maparea dorită, sistemul va trebui să invoce protocolul ARP prin reţea şi va face acest lucru prin transmiterea unei cereri ARP prin reţea (prin

difuzare). Această cerere conţine adresa IP dorită. Fiecare sistem recepţionează această cerere şi verifică dacă se potriveşte cu propria adresă IP. Dacă se potriveşte, sistemul implicat va trimite un mesaj de răspuns care conţine adresa de nivel legătură de date. Sursa cererii va adăuga şi această informaţie în propria tabelă ARP. Mesajul de cerere mai include şi adresa de nivel legătură de date şi cea IP ale sursei cererii.

� Figura 2.30 prezintă formatul pachetului ARP utilizat pentru maparea adreselor IP-către-Ethernet. De fapt, ARP poate fi utilizat pentru multe tipuri de mapări - diferenţa majoră fiind numai în dimensiunea adresei. Pe lângă adresele IP şi cele de nivel legătură de date ale sursei şi destinaţiei, pachetul mai conţine: o un câmp HardwareType, care specifică tipul reţelei fizice (exemplu, Ethernet); o un câmp ProtocolType, care specifică protocolul de nivel superior; o două câmpuri HLEN şi PLEN, care specifică lungimea adresei de nivel legătură de date şi

respectiv, pe cea a protocolului de nivel superior; o un câmp Operation, care specifică dacă acest pachet este de tip cerere sau răspuns; o adresele hardware şi de protocol pentru sursă şi destinaţie.

Fig. 2.30. Formatul pachetului ARP.

� Exemplu: Presupunem ca sistemul H1 doreşte să transmită un pachet IP către H3, dar nu cunoaşte adresa MAC a lui H3. H1 transmite mai întâi un pachet de cerere ARP, cerând informaţii despre sistemul de destinaţie identificat cu adresa de destinaţie IP-H3, aşteptând totodata şi răspunsul. Toate sistemele din reţea vor primi pachetul, dar unul singur îi va răspunde şi anume, sistemul H3. Pachetul de răspuns ARP conţine adresa MAC şi adresa IP a lui H3. Acum H1 ştie cum să trimită pachetul către H3. Pentru a evita trimiterea de fiecare data a unui pachet ARP către H3, H1 memorează în propria tabelă ARP atât adresa IP, cât şi adresa MAC ale lui H3, astfel fiind foarte uşor pentru H1 să trimită un pachet către H3 data viitoare.

Fig. 2.31. Exemplu de utilizare a ARP.

2.5 PROTOCOLUL DE REZOLUŢIE INVERSĂ A ADRESELOR (RARP)

� În această situaţie sistemul cunoaşte adresa MAC, dar nu cunoaşte adresa IP pentru un anumit sistem. De exemplu, la instalarea unui sistem de operare se poate citi adresa MAC de pe placa Ethernet, dar nu poate şti adresa IP. Aceasta este ţinută separat pe un disc local sau al unui server.

� Soluţia : protocolul de rezoluţie inversă a adreselor (RARP - Reverse Address Resolution Protocol),

care lucrează într-un mod asemănător cu ARP.

� Pentru a obţine adresa IP, sistemul trebuie să emită în reţea un pachet de cerere RARP, care să conţină propria adresă MAC. Toate sistemele din reţea vor primi pachetul, dar numai unul, serverul va răspunde transmiţând către sistemul sursă un pachet RARP care conţine adresa MAC şi adresa IP.

� O limitare pentru RARP ar fi dacă sistemul sursă s-ar afla într-o reţea diferită de cea a serverului.

2.6 PROTOCOLUL BOOTSTRAP (BOOTP)

� Protocolul de iniţializare BOOTP (Bootstrap Protocol) permite unei staţii client să pornească

(iniţializare) cu o stivă de protocoale IP minimală şi să solicite o adresă IP, o adresă a ruterului de ieşire (gateway) şi adresa unui server de nume, toate acestea fiind obţinute de la un server BOOTP.

� Deşi încă mai este utilizat intens pentru acest scop al sistemelor fără disc, BOOTP este de asemenea

utilizat ca un mecanism de livrare a informaţiei de configurare unui client care nu a fost configurat manual.

� Procesul BOOTP implică următorii paşi:

1. Clientul determină adresa fizică proprie; aceasta se află de obicei salvată într-o memorie ROM. 2. Un client BOOTP transmite adresa sa fizică într-un segment UDP către server. Figura 2.32

ilustrează conţinutul acestui segment. Dacă un client cunoaşte propria adresă IP sau adresa serverului, atunci le va utiliza, dar de cele mai multe ori clienţii BOOTP nu au deloc date de configurare IP. Dacă un client nu îşi cunoaşte adresa IP, atunci acesta va utiliza adresa 0.0.0.0. Dacă un client nu cunoaşte adresa IP a serverului, atunci acesta utilizează adresa de difuzare limitată (255.255.255.255).

3. Serverul primeşte segmementul UDP şi analizează adresa fizică a clientului pe care o caută în

fişierul său de configurare, care conţine şi adresa IP a clientului. Serverul completează câmpurile celelalte din segmentul UDP şi îl returnează clientului folosind un port UDP diferit. Pentru returnarea segmentului UDP se pot utiliza mai multe metode:

a. În cazul în care clientul îşi cunoaşte adresa IP (şi a fost inclusă în cererea BOOTP), serverul returnează segmentul direct către această adresă. Este foarte probabil ca lista ARP

să nu conţină adresa fizică corespunzătoare adresei IP. În acest caz se va utiliza protocolul ARP, ca într-o situaţie normală.

b. În cazul în care clientul nu îşi cunoaşte adresa IP (a fost 0.0.0.0 în cererea BOOTP), serverul trebuie să rezolve singur cererea consultând propria listă ARP.

c. ARP de la server nu poate fi utilizat pentru a găsi adresa fizică a clientului deoarece clientul nu îşi cunoaşte adresa IP şi astfel, nu se poate răspunde unei cereri ARP. Această problemă este cunoscută sub numele de “găina şi oul”. Există două posibile soluţii:

i. Dacă serverul are un mecanism pentru a actualiza direct propria listă ARP fără să folosească protocolul ARP, atunci serverul îl utilizează şi apoi trimite segmentul direct.

ii. Dacă serverul nu poate actualiza propria listă ARP, atunci trebuie să trimită un răspuns prin difuzare.

4. Atunci când primeşte un răspuns, clientul BOOTP va salva propria adresă IP (care îi va permite

să răspundă la cererile ARP) şi să înceapă procesul de iniţializare.

� În figura 2.32 se ilustrează formatul mesajului BOOTP.

Fig. 2.32. Formatul mesajului BOOTP.

Câmpurile din mesajul BOOTP au următoarele semnificaţii:

� Cod - Indică tipul mesajului, dacă este o cerere sau un răspuns: 1 – Cerere; 2 – Răspuns.

� Tip hardware - Indică tipul de reţea fizică, spre examplu:

1 – Ethernet; 6 – IEEE 802 Networks.

� Lungime – Specifică lungimea adresei fizice, în octeţi. Ethernet şi Token ring utilizează ambele

lungimea 6.

� Hop-uri – Clientul setează valoarea acestui câmp la 0. Această valoare este incrementată de către un ruter care retransmite cererea unui alt server şi este utilizată pentru a identifica buclele.

� Identificatorul tranzacţiei – Un număr aleator generat pentru a fi utilizat pentru a identifica

această cerere cu răspunsul primit.

� Secunde – Fixat de client. Acesta reprezintă timpul în secunde consumat din momentul în care clientul a demarat procesul de iniţializare.

� Fanioane – bitul cel mai semnificativ al acestui câmp este utilizat ca fanion de difuzare. Toţi

ceilalţi biţi trebuie setaţi cu valoarea zero, fiind rezervaţi pentru utilizări ulterioare. În mod normal, serverele BOOTP încearcă să livreze mesajele BOOTP de răspuns direct unui client folosind adresa de destinaţie unică. Adresa destinaţie din cadrul antetului IP este fixată cu valoarea adresei IP proprie BOOTP, iar adresa MAC este fixată cu valoarea adresei fizice –

client BOOTP. Dacă un sistem nu este capabil să primească un pachet IP cu destinaţie unică înainte de a-şi afla adresa sa IP, acest bit de difuzare trebuie fixat cu valoarea 1 pentru a indica serverului că răspunsul BOOTP trebuie transmis sub formă de difuzare la nivel IP şi MAC. În caz contrar, acest bit va avea valoarea 0.

� Adresa IP client – Fixat de client, fie cu valoarea adresei IP proprii (pe care o cunoaşte) sau cu 0.0.0.0.

� Adresa IP proprie – Fixat de server dacă câmpul de adresă IP client are valoarea 0.0.0.0.

� Adresa IP server – Fixat de server.

� Adresa IP ruter – Aceasta este adresa unui agent de redirectare BOOTP, care nu este un ruter

IP obişnuit şi va fi utilizată de către client.

� Adresa fizică client – Fixat de către client şi utilizat de server pentru a identifica clientul înregistrat care a demarat iniţializarea.

� Numele server-ului – Numele opţional al serverului, care se termină cu X'00'.

� Numele fişierului de iniţializare – Clientul fie lasă acest câmp cu valoarea nulă, fie specifică un

anumit nume, astfel încât să indice tipul de iniţializare care trebuie demarată. Serverul va returna numele fişierului de iniţializare, care este cel potrivit pentru cererea clientului.

� Identificatorul furnizorului – câmp opţional. Aceste opţiuni pot fi furnizate clientului la momentul iniţializării împreună cu adresa sa IP. Spre exemplu, clientul poate recepţiona în plus, adresa unui ruter implicit, adresa serverului de nume de domeniu şi masca subreţelei.

� După ce clientul BOOTP a procesat răspunsul, acesta poate demara transferul fişierului de

iniţializare şi să execute procesele de iniţializare.

2.7 PROTOCOLUL DE CONFIGURARE DINAMICĂ A SISTEMELOR (DHCP)

� Protocolul de configurare dinamică a sistemelor (hosturilor) DHCP (Dynamic Host Configuration Protocol) oferă un cadru pentru transferul informaţiilor de configurare către sisteme într-o reţea TCP/IP.

� DHCP se bazează pe protocolul BOOTP, adăugând capabilitatea de a aloca automat o adresă de

reţea şi opţiuni de configurare suplimentare.

� DHCP este constituit din două componente: o Un protocol care livrează parametrii pentru o configuraţie specifică hostului, de la un

server DHCP către un host. o Un mecanism de alocare temporară sau permanentă a unei adrese de reţea unui host.

� DHCP suportă trei mecanisme de alocare a adresei IP:

o Alocare automată: DHCP atribuie permanent o adresă IP unui host. o Alocare dinamică: DHCP atribuie temporar o adresă IP. O astfel de adresă este numită

lease. Acesta este unicul mecanism care permite utilizarea automată a unei adrese care nu mai este necesară hostului căruia îi fusese atribuită.

o Alocare manuală: Adresa hostului este atribuită manual de către un administrator de reţea.

2.7.1 Formatul mesajului DHCP

Fig. 2.33. Formatul mesajului DHCP.

� Majoritatea câmpurilor se regăsesc în mesajul BOOTP (vezi figura 2.32). Câmpurile care la DHCP au o seminficaţie diferită sunt următoarele:

� Adresa fizică client – Setată de client. DHCP defineşte un identificator opţional pentru client,

utilizat pentru identificarea clientului. Dacă această opţiune nu este utilizată, clientul va fi identificat după adresa MAC.

� Numele fişierului de iniţializare – Clientul fie lasă acest câmp cu valoarea nulă, fie specifică un anumit nume, astfel încât să indice tipul de iniţializare care trebuie demarată. Într-o cerere DHCPDISCOVER, este setat în zero. Serverul returnează numele complet pentru o cale de directoare în cererea DHCPOFFER. Valoarea este terminată în X’00’.

� Opţiuni - Primii patru octeţi conţin valoarea adresei speciale („magic cookie”) 99.130.83.99. Cei rămaşi indică parametrii doriţi.

2.7.2 Tipuri de mesaje DHCP

Mesajele DHCP formează următoarele categorii:

� DHCPDISCOVER: Transmis broadcast de către un client pentru a găsi un server DHCP disponibil; � DHCPOFFER: Răspunsul unui server la DHCPDISCOVER şi oferirea unei adrese IP şi a altor

parametri;

� DHCPREQUEST: Mesaj de la un client către server având una dintre semnificaţiile: o Cerere de parametri oferiţi de unul dintre servere, declinând orice altă ofertă; o Verifică o adresă alocată anterior după ce are loc o modificare de sistem sau reţea; o Cere prelungirea termenului pentru o adresă temporară.

� DHCPACK: Confirmare de la un server către un client, conţinând parametri, inclusiv adresa IP.

� DHCPNACK: Confirmare negativă de la server la client, indicând faptul că adresa temporară a

clientului a expirat sau că cererea de adresă IP este incorectă.

� DHCPDECLINE: Mesaj de la client spre server indicând că adresa oferită este deja în utilizare.

� DHCPRELEASE: Mesaj de la client către server prin care se cere înlocuirea unei adrese temporare cu una permanentă.

� DHCPINFORM: Mesaj de la un client care are adresă IP (configurată eventual manual), dar care

doreşte parametri de configurare de la un server DHCP. 2.7.3 Alocarea unei adrese de reţea

În continuare este prezentată interacţiunea client-server, situaţia în care clientul nu îşi cunoaşte adresa. Presupunem că serverul DHCP are un bloc de adrese de reţea din care poate satisface cereri de noi adrese. Fiecare server menţine o bază de date a adreselor alocate (permanent sau temporar) în memoria locală.

Procedura următoare descrie paşii din Figura 2.34: 1. Clientul transmite prin difuzare un mesaj DHCPDISCOVER în subreţeaua fizică locală. În acest moment clientul se găseşte în starea INIT. Mesajul DHCPDISCOVER poate include câteva opţiuni cum ar fi sugestii privind adresa de reţea sau durata unei adrese temporare (“lease”).

Fig. 2.34 Interacţiunea dintre clientul DHCP şi server-ul (-ele) DHCP.

2. Fiecare server răspunde cu un mesaj DHCPOFFER care include o adresă de reţea disponibilă (adresa IP proprie) şi alte opţiuni de configurare. Serverul memorează adresa oferită clientului pentru a preveni oferirea aceleiaşi adrese unui client care transmite un mesaj DHCPDISCOVER înainte ca primul client să-şi încheie configurarea.

3. Clientul recepţionează unul sau mai multe mesaje DHCPOFFER de la unul sau mai multe servere. Clientul alege unul, bazându-se pe parametrii de configurare oferiţi şi transmite broadcast mesajul DHCPREQUEST care include identificatorul serverului al cărui mesaj a fost ales şi adresa IP luată din câmpul de adresă IP proprie.

4. În cazul în care nu este recepţionată nici o ofertă, dacă clientul cunoaşte o adresă de reţea anterioară, va utiliza acea adresă dacă este încă validă până când va expira (este vorba despre o adresă “lease”).

5. Serverele recepţionează mesajul broadcast DHCPREQUEST. Acele servere care nu au fost selectate prin mesajul DHCPREQUEST utilizează mesajul pentru a notifica faptul că oferta lor a fost respinsă de către client. Serverul selectat în DHCPREQUEST marchează clientul ca fiind stabil, menţine datele corespunzătoare în memorie şi răspunde cu un mesaj DHCPACK conţinând parametrii de configurare ceruţi de către client. Combinaţia dintre hardware-ul clientului şi adresa de reţea atribuită constituie un identificator unic pentru adresa temporară (lease) a clientului şi este utilizat atât de către client, cât şi de către server pentru a identifica o referire la lease în orice mesaj DHCP. Câmpul de adresă IP proprie din mesajul DHCPACK va fi umplut cu adresa de reţea selectată.

6. Clientul recepţionează mesajul DHCPACK cu parametrii de configurare. Clientul realizează o verificare finală a parametrilor, de exemplu cu ARP pentru adresa de reţea alocată, şi notează durata de valabilitate a adresei şi identificatorul adresei din mesajul DHCPACK. În acest moment clientul s-a configurat.

7. Dacă detectează o problemă cu parametrii din mesajul DHCPACK (adresa se află deja în folosinţă în reţea), clientul va transmite către server un mesaj DHCPDECLINE şi reporneşte

procesul de configurare. La recepţia unui mesaj DHCPDECLINE serverul trebuie să marcheze faptul că adresa oferită nu este disponibilă (şi eventual informează administratorul de sistem că există o problemă de configurare).

8. În cazul în care clientul recepţionează un mesaj DHCPNACK, va reporni procesul de configurare.

9. Clientul poate alege să elibereze adresa temporară (lease) prin transmiterea unui mesaj DHCPRELEASE către server. Clientul identifică adresa lease pe care o vrea eliberată prin includerea în mesaj a adresei de reţea şi a adresei hardware.