2.

2 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.10) (în antetul IP
numărul de protocol ia valoarea 1 pentru ICMP, iar tipul de serviciu ia valoarea zero).

Fig. 2.10. Î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.11.

Fig. 2.11 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.12 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, Etliernet);
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.12. 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.13. Exemplu de utilizare a ARP.

2.3 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.4 PROTOCOLUL BOOTSTRAP (BOOTP)

Protocolul de iniţializare BOOTP (Bootstrap Protocol) permite unui 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 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.14
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.14 se ilustrează formatul mesajului BOOTP.

Fig. 2.14. 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 producătorului – 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.5 Dynamic Host Configuration Protocol (DHCP)
Protocolul de configurare dinamică a hosuturilor oferă un cadru pentru transferul informa iilor de
configurare către hosturi î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. Mesajele
DHCP utilizează portul UDP 67, port pentru servere BOOTP i portul UDP 68, port pentru clien i
BOOTP.
DHCP constă din două componente:
- Un protocol care livrează parametrii pentru o configura ie specifică hostului de la un server DHCP
către un host.
- Un mecanism de alocare temporară sau permanentp a unei adrese de re ea unui host.
DHCP suportă trei mecanisme de alocare a adresei IP:
- Alocare automată: DHCP atribuie permanent o adresă IP unui host.
- 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ă.
- Alocare manuală: Adresa hostului este atribuită manual de către un administrator de re ea.
Figura 2.15: Formatul mesajului DHCP
Figura 2.16: Interac iunea dintre client DHCP i server DHCP