1.1 Protocolul IPX. Avantaje si dezavantaje Netware IPX este un protocol bazat pe datagrame (fără conexiune). Termenul fără conexiune înseamnă că atunci când o aplicaţie foloseşte IPX pentru a comunica cu alte aplicaţii din cadrul reţelei, nu este stabilită nici o conexiune sau cale de date între cele două aplicaţii. Deci, pachetele IPX sunt trimise către destinaţiile lor, dar nu se garantează şi nici nu se verifică faptul că acestea ajung sau nu la destinaţie. Termenul datagramă (datagram) desemnează faptul că un pachet este tratat ca o entitate individuală, care nu are nici o legătură sau relaţie secvenţială cu alte pachete.

IPX execută funcţii echivelente nivelului reţea din modelul OSI. Aceste funcţii includ adresare, rutare şi transfer de pachete pentru schimburi de informaţie, funcţiile IPX fiind dedicate transmisiei de pachete în cadrul reţelei. Avantaje şi dezavantaje Deoarece IPX execută doar sarcinile nivelului reţea din modelul OSI, oferă beneficiile vitezei şi performanţei care rezultă din încărcarea mică pe care o produce. Totuşi, serviciile IPX sunt insuficiente dacă sunt necesare garanţiile nivelului transport. IPX este deci folosit în cazul în care este potrivit tipului particular de aplicaţie.

Principalele avantaje şi dezavantaje ale IPX sunt:

• Disponibilitatea simultană a sursei şi destinaţiei nu este necesară, deoarece nu există o conexiune predeterminată. Totuşi, sursa nu primeşte nici o confirmare a faptului că destinaţia a primit datele; • Flexibilitatea în rutarea pachetelor este mare, deoarece nu este necesară o rută predeterminată a pachetelor; • Pachetele pot fi trimise către destinaţii multiple pur şi simplu prin duplicarea pachetului şi schimbarea adresei destinaţie. Un mesaj se poate trimite folosind IPX prin plasarea mesajului în porţiunea de date a unui pachet IPX, la fel ca şi punerea unui mesaj într-un plic. Headerul pachetului IPX trebuie să conţină reţeaua destinaţie, numerele de nod şi soclu (adică adresa la care trebuie trimis pachetul). IPX trimite fiecare pachet individual prin diferite subreţele (posibil pe diferite rute pentru a profita de traficul mai scăzut) până când pachetul atinge destinaţia. Deoarece fiecare pachet este o entitate individuală, rutarea şi secvenţierea pachetelor poate să varieze. Când pachetul ajunge, sursa nu primeşte nici o informaţie privind livrarea cu succes a pachetului. Doar dacă destinaţia ia hotărârea să trimită un pachet către sursă, sursa poate fi sigură de ajungerea pachetului la destinaţie. Oricum, IPX trimite cu succes aproximativ 95% din numărul pachetelor.

1.2 Structura pachetului IPX Pachetul IPX este identic din punct de vedere al structurii cu un pachet Xerox IDP. El are două părţi: un header de 30 de octeţi şi o porţiune de date cu o lungime între 0 şi 546 octeţi. Lungimea minimă a pachetului este 30 octeţi (doar headerul), iar lungimea sa maximă este 576 octeţi (30+546). Structura pachetului IPX este prezentată în tabelul 1. Toate câmpurile sunt structurate high-low, adică cel mai semnificativ octet al câmpului este primul.

Offset Conţinut Tip

0 Checksum BYTE[2]

2 Length BYTE[2]

4 Transport Control BYTE

5 Packet Type BYTE

6 Destination Network BYTE[4]

10 Destination Node BYTE[6]

16 Destination Socket BYTE[2]

18 Source Network BYTE[4]

22 Source Node BYTE[6]

28 Source Socket BYTE[2]

30 Data Portion byte[0÷546]

Tabelul 1. Structura pachetului IPX. Semnificaţia câmpurilor headerului este următoarea: Checksum (Suma de control) Acest câmp a fost inclus pentru conformitate cu headerul original Xerox. IPX îl încarcă totdeauna cu valoarea 0FFFFh. Cartelele de reţea aplică sume de control întregului pachet IPX, deci acest câmp nu este necesar. Length (Lungime) Acest câmp conţine lungimea întregului pachet (header+date). Valoarea lui minimă este 30, iar cea maximă 576. IPX setează acest câmp. Transport Control (Controlul transportului) Acest câmp este folosit de bridge-urile inter-reţea NetWare. IPX îl încarcă cu valoarea 0. Packet Type (Tipul pachetului) Acest câmp indică tipul de serviciu oferit sau cerut de către pachet. Xerox a definit următoarele valori (totuşi, utilizatorii IPX trebuie să seteze valoarea acestui câmp la 0 sau 4): • 0 - Pachet necunoscut; • 1 - Pachet care conţine informaţii de rutare;

• 2 - Pachet în ecou; • 3 - Pachet de eroare; • 4 - Packet Exchange Packet (pachet IPX); • 5 - Sequenced Packet Protocol Packet (pachet SPX);

• 1631 - Protocoale experimentale; • 17 - Protocol NetWare Core (Core = miez). Utilizatorii IPX trebuie să seteze tipul pachetului la 0 sau 4, iar utilizatorii SPX trebuie să-i dea valoarea 5. Destination Network (Reţeaua destinaţie) Acest câmp conţine numărul reţelei căreia îi aparţine nodul destinaţie. în cazul NetWare, reţelele din cadrul unei reţele globale primesc de la administratorul reţelei globale un număr unic de 4 octeţi. Când acest câmp este 0, nodul destinaţie este în aceeaşi reţea ca şi nodul sursă, pachetul nefiind procesat de un bridge inter-reţea. Destination Node (Nodul destinaţie) Acest câmp conţine adresa fizică a nodului destinaţie. Lungimea acestui câmp este variabilă în funcţie de topologia reţelei. Un nod din cadrul unei reţele Ethernet va avea o adresă fizică de 6 octeţi, pe când un nod din cadrul unei reţele Omninet va avea o adresă de un octet. Dacă o adresă fizică are lungimea mai mică de 6 octeţi, adresa trebuie să ocupe cea mai putin semnificativă poziţie în cadrul câmpului, prima parte a acestuia trebuind completată cu zero. O adresă de nod egală cu 0FFFFFFFFFFFFh (6 octeţi formaţi numai din biţi unu) identifică un pachet broadcast. Destination Socket (Soclul destinaţie) Acest câmp conţine adresa soclului procesului destinaţie a pachetului. Soclurile rutează pachetele către diferite destinaţii în cadrul aceluiaşi nod. Xerox a rezervat următoarele numere de socluri: • 1 - Routing Information Packet; • 2 - Echo Protocol Packet; • 3 - Error Handler Packet;

• 20h03Fh - Experimental;

• 10BB8h - Registered with Xerox; Xerox a asignat pentru Novell un set de socluri pentru folosirea de către NetWare: • 451 - File Service Packet; • 452 - Service Advertising Packet; • 453 - Routing Informaton Packet; • 455 - NetBIOS Packet; • 456 - Diagnostic Packet. De exemplu, serverele NetWare acceptă cereri adresate soclului 451. Source Network (Reţeaua sursă) Source Node (Nodul sursă) Source Socket (Soclul sursă) Aceste trei câmpuri au semnificaţii similare cu cele corespunzătoare destinaţiei.

1.3 Protocolul SPX SPX este identic cu IPX cu excepţia faptului că oferă servicii suplimentare conferite de faptul că se află la nivelul transport din modelul OSI, spre deosebire de IPX, aflat la nivelul reţea. Aceste funcţii suplimentare fac din SPX un protocol orientat către conexiune. Aceasta înseamnă că înainte ca un pachet SPX să fie trimis, se stabileşte o conexiune între sursă şi destinaţie. SPX garantează livrarea datelor, secvenţierea pachetelor, detectarea şi corectarea erorilor şi suprimarea pachetelor duplicate. Avantaje şi dezavantaje În schimbul acestor garanţii, SPX nu are viteza şi performanţele IPX. Proiectantul de aplicaţii trebuie să determine ce este mai important pentru aplicaţiile sale: viteza sau siguranţa livrărilor. Astfel, el va alege IPX sau SPX. Iată în continuare câteva dintre avantajele şi dezavantajele folosirii SPX: • Livrarea garantată a datelor; conexiunea este stabilită înainte ca informaţia să fie trimisă şi la sursă se întorc informaţii privind livrarea cu succes. Trimiterea de pachete broadcast este greoaie, deoarece trebuie stabilită o conexiune cu fiecare potenţial receptor înainte. De asemenea, unele aplicaţii nu au nevoie de garantarea livrării fiecărui pachet; • Secvenţiere garantată a pachetelor; deci, oricâte pachete ar cere transmiterea unui flux de date, acestea vor ajunge în ordine; • Suprimarea pachetelor duplicat; în timpul procesului de garantare a livrării (care include retransmiterea pachetelor considerate pierdute), este posibilă apariţia unor pachete duplicat care ajung ambele la nodul destinaţie; SPX elimină astfel de pachete, deci aplicaţia primeste doar o copie a datelor trimise de către partenerul de comunicaţie.

1.4 Structura pachetelor SPX Un pachet SPX este identic ca structură cu un pachet IPX, cu excepţia faptului că are 12 octeţi suplimentari în header. Pachetul SPX constă din două părţi: un header de 42 de octeţi şi un câmp de date care poate conţine între 0 si 534 octeţi. Lungimea minimă a pachetului este de 42 octeţi (doar headerul), iar cea maximă de 576 octeţi (42+534). Câmpurile pachetului SPX care au aceeaşi denumire ca şi cele din cadrul pachetelor IPX au şi aceeaşi semnificaţie ca şi acestea, cu specificarea că niciodată în cadrul unui pachet SPX nu se permite o valoare 0FFFFFFFFFFFFh a adresei nodului destinaţie (nu sunt permise broadcast-uri), iar SPX încarcă totdeauna valoarea 5 în câmpul Packet Type. În tabelul 2 este prezentată structura pachetului SPX:

Offset Conţinut Tip

0 Checksum BYTE2

2 Length BYTE2

4 Transport Control BYTE

5 Packet Type BYTE

6 Destination Network BYTE4

10 Destination Node BYTE6

16 Destination Socket BYTE2

18 Source Network BYTE4

22 Source Node BYTE6

28 Source Socket BYTE2

30 Connect. Control BYTE

31 Data Stream Type BYTE

32 Source Connect. ID BYTE2

34 Dest. Connect ID BYTE2

36 Sequence Number BYTE2

38 Acknowledge Number BYTE2

40 Allocation Number BYTE2

42 Data Portion BYTE0534

Tabelul 2. Structura pachetului SPX. Ordinea octeţilor în cadrul câmpurilor este high-low, ca şi în cazul IPX. Semnificaţiile câmpurilor suplimentare faţă de cele din cadrul headerului IPX sunt: Connection Control (Controlul conexiunii) Acest câmp conţine 4 indicatori de 1 bit folosiţi de SPX şi clienţii săi pentru a controla fluxul bidirecţional de date de-a lungul unei conexiuni:

• 18 - Valori nedefinite de către Xerox Sequenced Packet Protocol. SPX îi ignoră; • 10h - Sfârşitul unui mesaj; clientul setează acest bit pentru a semnala sfârşitul

mesajului partenerului său; SPX ignoră acest bit şi îl livrează neschimat partenerului; • 20h - Atenţie; clientul setează acest indicator dacă pachetul este un pachet de

atenţionare; această facilitate nu a fost implementată; SPX ignoră acest bit şi îl livrează neschimat partenerului;

• 40h - Se cere confirmare; SPX setează acest bit dacă este necesar un pachet de confirmare; deoarece SPX controlează cererile şi răspunsurile de confirmare, clientul trebuie să ignore acest indicator;

• 80h - Pachet sistem; SPX setează acest bit dacă pachetul este un pachet sistem; aceste pachete sunt folosite intern şi nu sunt livrate clienţilor.

Clienţii nu trebuie să folosească sau să modifice niciodată biţii nedefiniţi, de confirmare sau sistem. Aceştia sunt rezervaţi pentru folosirea de către SPX. Data Stream Type (Tipul fluxului de date) Acest câmp este un indicator de un octet care arată tipul datelor care au fost găsite în cadrul pachetului. Valorile posibile sunt arătate în continuare:

• 00FDh - Definit de client; SPX ignoră aceste valori; • 0FEh - Sfârşitul conexiunii; când un client execută un apel pentru a termina o

conexiune activă, SPX va genera un pachet de terminare a conexiunii. Acesta va fi ultimul pachet trimis partenerului în cadrul conexiunii;

• 0FFh - Confirmarea sfârşitului conexiunii; SPX generează un pachet de confirmare a sfârşitului conexiunii automat; acest pachet este marcat sistem şi nu este livrat clienţilor.

Source Connection ID (Identificatorul sursei) Acest câmp conţine un număr de identificare asignat de către SPX sursei pachetului. Destination Connection ID (Identificatorul destinaţiei) Acest câmp contine un număr de identificare asignat de către SPX destinaţiei pachetului şi folosit pentru demultiplexarea pachetelor sosite în cadrul multiplelor conexiuni care ajung la acelaşi soclu; demultiplexarea este necesară deoarece conexiunile active concurente de pe orice maşină pot folosi acelaşi număr de soclu. Sequence Number (Numărul de secvenţă)

Acest câmp reţine numărul pachetelor schimbate într-o direcţie a conexiunii. Fiecare parte a conexiunii ţine propriul contor. Numărul ia valoarea zero după ce depăşeşte 0FFFFh. Deoarece SPX controlează acest câmp, clienţii nu sunt interesaţi de valoarea lui. Acknowledge Number (Număr de confirmare) Acest câmp indică numărul de secvenţă al următorului pachet pe care SPX se aşteaptă să îl recepţioneze. Orice pachet cu un număr de secvenţă mai mic decât valoarea acestui câmp este în secvenţa corectă şi nu trebuie retransmis. Deoarece SPX controlează acest câmp, clienţii nu sunt interesaţi de valoarea lui. Allocation Number (Număr de buffere alocate) Acest câmp indică numărul de buffere de ascultare disponibile într-o direcţie a conexiunii. SPX poate să trimită pachete doar până când numărul de secvenţă devine egal cu numărul de buffere alocate la celălalt capăt al conexiunii. Deoarece SPX controlează acest câmp, clienţii nu sunt interesaţi de valoarea lui.

1.5 Protocolul INTERNET. Headerul IP. Fragmentarea si reasamblarea pachetelor.

Protocolul INTERNET IP(Intenet Protocol) este limitat la funcţiile de bază necesare transmisiei unui bloc de

date (datagram) prin internet. Fiecare bloc de date este o entitate independentă, nefiind legată de alte "datagrame" (mesaj fără confirmare). Nivelul IP al hostului asigură servicii protocoalelor de la nivelul transport şi foloseşte serviciile nivelului legăturii de date pentru a transmite datagramele hostului destinaţie. IP nu pretinde că ar oferi servicii sigure. Calculatoarele gazdă (hosts) vor ignora datagramele atunci când nu au resurse suficiente pentru procesare şi nu vor detecta datagramele pierdute sau ignorate de către nivelul legăturii de date.

IP izolează protocoalele de pe nivelele superioare de caracteristicile specifice reţelei. Serviciile adiţionale furnizate de către IP includ diferite nivele de comportare a transmisiei, implicând caracteristici ca: precedenţă, nivel de încredere, întârzieri. IP permite de asemenea etichetarea datelor, necesară în medii sigure, pentru a asocia datelor informaţii de securitate.

Transmisia începe atunci când un protocol de pe nivelul superior transmite date către IP pentru livrare. IP împachetează datele în format internet datagram şi le transmite protocolului de pe nivelul legăturii de date pentru transmisie prin reţeaua locală. Dacă hostul destinaţie se află legat direct în reţeaua locală, IP trimite pachetul direct acestui host. Dacă destinaţia se află într-o altă reţea, IP trimite pachetul unui gateway IP local pentru transmisie. Acest gateway va trimite pachetul prin următoarea reţea hostului destinaţie sau unui alt gateway. Astfel, datagrama se propagă prin setul de reţele interconectate de la un modul IP la altul, până când aceasta ajunge la destinaţie.

Figura 2. Transmisia datelor prin intermediul IP

Gateway-urile, uneori numite "Routere IP" (sau "Local Bridges" ori "Remote Bridges") sunt de fapt un fel de "relee de pachete" care interconectează două sau mai multe reţele sau subreţele. Fiecare gateway conţine un modul IP aflat deasupra a două sau mai multe procese bazate pe protocoale aflate la nivelul legăturii de date.

Modulele IP folosesc reguli comune pentru interpretarea adreselor internet necesare în procesul stabilirii traseului pe care pachetul trebuie să-l urmeze pentru a ajunge la destinaţie. Rutarea executată de către un gateway se bazează pe câmpul network/subnetwork al adresei internet de destinaţie.

Echipamentele gateway care conectează un set de reţele private din punct de vedere al proprietăţii şi administrării pot să folosească orice protocol, fără restricţii. De obicei, un asemenea protocol privat se numeşte Interior Gateway Protocol (IGP). În termeni IP, fiecare astfel de reţea administrată independent este numită sistem autonom (Autonomous System).

Pe de altă parte, toate echipamentele gateway care fac legătura între reţele private şi reţele publice de date (DDN, Digital Data Networks) trebuie să folosească un protocol oficial simplu şi bine definit numit Exterior Gateway Protocol. Headerul IP

Pachetele (datagramele) IP au un antet (header) bine definit, header definit de standardele DoD (U.S.A. Department of Defense). Acest header are structura prezentată în figura 3. În continuare sunt prezentate câmpurile care compun acest header:

Version (Versiune) Abreviere: VER Lungimea câmpului: 4 biţi Câmpul Version indică formatul headerului IP. Va fi prezentată în continuare

versiunea 4, ultima până la data apariţiei materialului bibliografic avut la dispoziţie (1988). Versiunile 1÷3 nu mai erau deja folosite încă la acea dată.

Câmpul Version indică versiunea protocolului căreia îi aparţine pachetul. Includerea versiunii protocolului în fiecare pachet face posibilă dezvoltarea de noi protocoale şi testarea acestora fără a afecta buna funcţionare a reţelei.

Internet Header Length (Lungimea headerului Internet) Abreviere: IHL Lungimea câmpului: 4 biţi Unitate: Grupe de câte 4 octeţi Gamă: 5÷15 (implicit 5)

Pachetele transmise de către hostul numărul 1 pot să circule pe una dintre cele două căi prezentate. (figura 2)

Câmpul Internet Header Length indică lungimea headerului IP exprimată în multipli de unităţi de 32 biţi. Acest câmp este necesar deoarece headerul IP are o lungime variabilă datorită faptului că lungimea cimpului Options nu este constant.

Type of Service (Tipul de serviciu) Abreviere: TOS Lungimea câmpului: 8 biţi Câmpul Type of Service conţine parametrii IP care descriu calitatea serviciului dorită

pentru prezentul pachet transmis. Câmpul permite calculatorului gazdă să specifice reţelelor de tranzit tipul de serviciu pe care îl doreşte. Câmpul permite specificarea precedenţei pachetului, nivelul dorit de încredere şi nivelul presupus de consumare a resurselor, după cum se va arăta mai jos.

Tipul de serviciu se foloseşte pentru a specifica reţelelor de tranzit ce serviciu se doreşte de la acestea. Reţelele de tranzit decid dacă pot sau doresc să se achite de serviciile cerute.

Total Length (Lungimea totală) Abreviere: TL Lungimea câmpului: 16 biţi

Total Length este lungimea pachetului, măsurată în de date ale pachetului. Se observă că lungimea câmpului Total Length pachetului de 65.536 octeţi.

Identification (Identificare) Abreviere: ID Lungimea câmpului: 16 biţi Câmpul reprezintă o valoare de identificare folosită pentru a asocia fragmentele unui pachet. ULP (Upper Layer Protocol) care transmite de obicei generează această valoare ca pe un parametru al interfeţei. Altfel, IP generează acest câmp în aşa fel încât el să fie unic pentru fiecare ULP care transmite.

Câmpul Identification indică numărul pachetului pentru a permite calculatorului gazdă destinaţie să determine cărui pachet îi aparţine fragmentul care tocmai a sosit.

Flags (Indicatori) Abreviere: - Lungimea câmpului: 3 biţi Acest câmp conţine indicatorii de control Don't Fragment (a nu se fragmenta, care

inhibă fragmentarea pachetului de către IP) şi More Fragments (care ajută la identificarea poziţiei unui fragment în pachetul original).

Indicatorul Don't Fragment este destinat pentru folosirea cu calculatoare gazdă care nu sunt capabile să reconstituie pachetul din fragmentele din care este format. De fapt, multe implementări ale TCP/IP nu permit fragmentarea şi reconstituirea pachetelor.

Fragment Offset (Offsetul fragmentului) Abreviere: FO Lungimea câmpului: 13 biţi Unitate: Grupe de câte 8 octeţi Gamă: 0÷8191 (implicit 0) Câmpul indică poziţia fragmentului relativ la începutul datelor în pachetul original.

Atât un pachet complet, cât şi primul fragment al unui pachet au acest câmp resetat. Fragment Offset localizează poziţia fragmentului curent într-un pachet ca multiplu de

8 biţi. Pentru aceasta, lungimea câmpului este de 13 biţi, deci sunt permise maximum 8.192 fragmente pentru fiecare pachet, în acest caz extrem, primele 8.191 fragmente vor avea lungimea de un octet.

Time-to-Live (Timp de viaţă) Abreviere: TTL Lungimea âmpului: 8 biţi Unitate: secunde Gamă: 0÷255 (255=4,25 minute)

Acest câmp indică timpul maxim cât poate să rămână pachetul în internet. Când valoarea acestui câmp, după decrementare, ia valoarea zero, pachetul ar trebui distrus.

Unitatea de timp utilizată pentru măsurarea timpului de viaţă al pachetului este secunda, deci timpul maxim de viaţă al unui pachet este 255 secunde (4,25 minute).

Valoarea câmpului este scăzută cu cel puţin 1 de către fiecare router prin care trece pachetul. Protocol (Protocol)

Abreviere: PROT Lungimea câmpului: 16 biţi Acest câmp arată care ULP (Upper Level Protocol) trebuie să recepţioneze

porţiunea de date a unui pachet. Numerele asignate ULP-urilor uzuale sunt disponibile de la DoD Executive Agent for Protocols. Unele vor fi arătate mai jos, în tabelul 3.

Câmpul Protocol specifică protocolul particular de la nivelul 4 căruia îi aparţine pachetul (de exemplu, TCP sau alt protocol echivalent).

Header Checksum (Suma de control a headerului) Lungimea câmpului: 16 biţi Acest câmp conţine o sumă de control aplicată doar headerului IP. Suma de control

ajută la detectarea unor eventuale erori apărute în timpul transmisiei. Algoritmul după care se generează această sumă de control este: se adună complementele faţă de 1 ale tuturor entităţilor headerului (grupate pe câte 16 biţi) şi apoi se complementează suma faţă de 1.

Suma de control a headerului se foloseşte doar pentru a verifica validitatea datelor din cadrul headerului. Ori de câte ori pachetul trece printr-un gateway, această sumă de control este recalculată (deoarece de fiecare dată este modificat câmpul TTL). Source Address (Adresa sursei) Abreviere: SOURCE Lungimea câmpului: 32 biţi Acest câmp conţine adresa Internet a calculatorului gazdă care a generat pachetul. Destinaton Adress (Adresa de destinaţie) Abreviere: DEST Lungimea câmpului: 32 biţi Câmpul conţine adresa Internet a hostului destinaţie.

Adresele sursă şi destinaţie indică numărul reţelei folosind 8^24 biţi. Biţii nefolosiţi pentru identificarea reţelei sunt folosiţi pentru a referi numărul hostului şi, opţional, numărul subreţelei.

Options (Opţiuni) Abreviere: OPT Lungimea câmpului: variabilă Acest câmp a fost prevăzut pentru a permite unor versiuni ulterioare ale protocolului

să includă informaţii care nu sunt prezente în implementarea originală, să permită

Număr

(zecimal)

Prescurtare Descriere

0 Reserved

1 ICMP Internet Control Message

5 ST Stream

6 TCP Transmission Control Protocol

8 EGP Exterior Gateway Protocol

9 IGP Any private interior gateway protocol

11 NVP Network Voice Protocol

17 UDP User Datagram Protocol

20 HMP Host Monitoring Protocol

22 XNS-IDP Xerox Network Systems Internet Datagram

Protocol

27 RDP Reliable Data Protocol

28 IRTP Internet Reliable Transaction Protocol

29 ISO-TP4 ISO Transport Protocol Class 4

30 NETBLT Bulk Data Transfer Protocol

61 Any host internal protocol

Tabelul 3. Numere de protocol asignate în cadrul headerului IP.

experimentatorilor s încerce noi idei şi să evite alocarea permanentă a unor biţi în cadrul headerului pentru informaţii rar folosite.

Lungimea acestui câmp depinde de numărul şi tipurile opţiunilor asociate cu pachetul. Opţiunile definite oficial sunt:

- Security - etichetează nivelul, compartimentul, grupul de utilizatori şi restricţiile de manipulare, aşa cum sunt ele cerute de DoD;

- Loose Source Routing - permite celui care trimite pachetul să ceară ca pachetul să urmeze o cale oarecare (generală) prin reţea;

- Strict Source Routing - cere ca pachetul să urmeze o cale specificată; - RecordRoute - înregistrează calea urmată de pachet; - Stream ID - permite unui gateway să manipuleze o colecţie de pachete în acelaşi

fel; - Timestamp - permite o înregistrare a căii pe care o urmează un pachet prin reţea

cu înregistrarea de asemenea a momentelor în care pachetul a ajuns în diferite locuri.

Fragmentarea şi reasamblarea pachetelor

Reţelele întotdeauna impun o lungime maximă a pachetelor, din cauza:

- limitărilor hardware (lăţimea unui slot de transmisie); - limitărilor software ale unui sistem de operare particular (de exemplu, un sistem

de operare ar putea cere ca lungimea pachetelor pe care le manipuleaăÎ să nu depăşească 512 octeţi);

- protocoalele folosite (restricţii privind numărul de biţi în câmpul de lungime a pachetelor);

- restricţii impuse de standard; - măsuri luate pentru reducerea numărului de erori; - limitări privind durata cât un pachet poate ocupa un canal.

În continuare, în tabelul 4, se prezintă un tabel care demonstrează diversitatea lungimii maxime a pachetelor impusă de diferite reţele.

Numele reţelei Maxim [biţi]

Bell Labs' Spider 256

ALOHANET (University of Hawaii) 640

X.25 (implicit) 1.024

ARPA Packet Radio Network 2.024

ARPANET 8.192

X.25 (maxim) 8.192

Ethernet 12.144

Tabelul 4. Lungimea maximă a pachetului în funcţie de reţea.

Pachetele IP de nivel 3 în tranzit pot să traverseze subreţele a căror lungime maximă a pachetelor este mai mică decât lungimea pachetului. Pentru a se rezolva această problemă, IP prevede mecanismele de fragmentare şi reconstituire a pachetelor.

Atunci când un gateway ar trebui să trimită un pachet într-o reţea care nu poate primi pachetul din cauza lungimii sale, echipamentul gateway trebuie să fragmenteze pachetul

original în mai multe subpachete, numite fragmente de pachet (datagram fragments), care sunt suficient de mici pentru a putea fi transmise.

Datagramele IP sunt transmise independent, deci datagramele fragmentate pot să nu se "întâlnească" până când ajung la calculatorul gazdă destinaţie şi pot chiar să ajungă în altă ordine decât cea originală. Deci, toate host-urile care pot să recepţioneze pachete trebuie să fie capabile să le şi reasambleze.

Modulul IP din host-ul destinaţie va reasambla datagramele fragmentate într-o singură datagramă pentru livrare către clientul său de pe nivelul transport (4).

Figura 4 ilustrează procesul fragmentării pachetelor. Pentru claritate, figura este simplificată, neincluzând headere etc.

Trebuie remarcat că nu toate protocoalele efectuează fragmentarea şi reasamblarea în acelaşi fel. XNS (Xerox Network Standard) cere ca reasamblarea să fie făcută de către reţeaua care a fragmentat datagrama, ceea ce simplifică implementarea pentru host-urile receptoare. XNS impune o restricţie importantă rutării inter-reţea şi caracteristicilor reţelei finale (receptoare) şi anume ca cele două reţele să admită pachete de aceeaşi lungime maximă.

1.6 Asignarea adreselor IP în funcţie de confguraţia reţelei (Adresarea IP)

Unul dintre scopurile IP este de a asigura servicii într-o mare varietate de medii (reţele şi reţele globale). Mecanismul de adresare IP este astfel conceput încât să permită trei clase diferite de configuraţii ale reţelelor. Cele trei clase de adrese IP, notate A, B, C, sunt prevăzute pentru reţele care au:

• A - multe hosturi distribuite în reţele puţine; • B - o distribuţie medie a hosturilor şi reţelelor; • C - puţine hosturi în multe reţele.

Aceste situaţii sunt ilustrate în figura 5.

Doar 32 de biţi sunt alocaţi pentru a exprima o adresă IP completă, care constă atât

din adresa reţelei, cât şi din adresa hostului. O reţea globală care conţine doar câteva reţele va avea nevoie doar de câţiva biţi pentru a identifica reţeaua. Prin convenţie, aceştia vor fi cei mai semnificativi biţi dintre cei 32 biţi disponibili pentru adresare. Pe de altă parte, o retea globală cu multe reţele va avea nevoie de mai mulţi biţi pentru a exprima toate adresele de reţele componente, deci va ocupa mai mulţi biţi dintre cei 32 disponibili pentru a exprima adresa reţelei (aceşti biţi vor fi tot cei mai seminficativi biţi ai adresei).

În cadrul unei reţele, hosturile pot fi organizate în comunităţi mai mici, numite subreţele. Forma adreselor IP permite, pentru proiectarea subreţelelor, mascarea unor biţi pentru a putea fi folosiţi pentru identificarea subreţelelor.

De exemplu, un campus poate avea o adresă clasă B, care cere 2 octeţi pentru porţiunea alocată reţelei şi doi octeţi pentru porţiunea alocată hostului. În loc să existe 65.536 adrese de hosturi, se poate alege soluţia divizării campusului în 254 subreţele (un octet), fiecare având câte 254 de hosturi (celălalt octet). Trebuie făcută observaţia că doar 254 de hosturi, respectiv reţele sunt posibile, deoarece valorile 0 şi 255 sunt rezervate).

Adresele IP, măştile şi formatele pentru cele trei clasificări sunt ca în tabelul 5:

Clasa Cei 3 biţi mai

semnif.

Biţi pt. id. reţea Biţi pt. id.

HOST

Mască pt. id. reţea

(hex)

A 0XX 7 24 FF000000

B 10X 14 16 FFFF0000

C 110 21 8 FFFFFF00

Tabelul 5. Clasificarea tipurilor de reţele.

După cum se poate observa din tabelul de mai sus, inspectând primii trei biţi ai unei adrese de IP se poate şti dacă este o adresă de clasă A, B sau C. Dacă primul (cel mai semnificativ) bit este 0, atunci adresa este o adresă clasă A. Dacă primul bit este 1, trebuie inspectat al doilea bit. Dacă primul bit este 0 şi al doilea bit este 0, atunci adresa este de clasă B. Dacă primii trei biţi sunt 110, adresa este de clasă C. Dacă primii trei biţi sunt 111, atunci avem de a face cu o adresă clasă D, care nu este folosită (este o combinaţie păstrată pentru dezvoltări ulterioare). Aceste combinaţii sunt prezentate în tabelul 6:

O adresă IP este de obicei reprezentată ca patru câmpuri separate de câte un punct, fiecare câmp reprezentând un octet (având deci valori cuprinse între 0 şi 255). Diferenţele în interpretările acestor câmpuri depind de clasa căreia îi aparţine adresa respectivă. Se observă posibilitatea identificării clasei unei aderse IP prin examinarea primului octet al adresei, ca în tabelul 7.

Tabelul 7. Identificarea clasei unei reţele în funcţie de primul octet al adresei IP

De exemplu, 10.1.17.1 este o adresă de clasă A, 128.203.5.17 este o adresă de clasă B, iar 192.1.2.10 este o adresă de clasă C.

Clasă A primul bit 0

Clasă B primul bit 1 al doilea bit 0

Clasă C primul bit 1 al dilea bit 1 al treilea bit 0

Clasă D primul bit 1 al doilea bit 1 al treilea bit 1

Tabelul 6. Tipuri posibile de reţele.

1.7 Protocolul ICMP

ICMP este un protocol care funcţionează la nivelul 3 al modelului OSI (nivelul reţea. El este o parte componenta a protocolului IP. Acest protocol permite încapsularea în interiorul cadrului IP a unor informaţii, care o dată ajunse la destinaţia specificată, determină generarea unui răspuns către sursa ICMP, din care se poate deduce timpul de răspuns pe un canal de comunicaţie.

În general, mesaje ICMP sunt generate de către staţii care percep o eroare sau o problemă în cadrul unui pachet pe care un alt host l-a transmis. Eroarea poate fi detectată ori de hostul destinaţie, ori de un echipament gateway intermediar. Dacă reţeaua, maşina sau portul destinaţie nu pot fi atinse, un gateway poate folosi ICMP pentru a avertiza hostul sursă asupra acestui fapt. ICMP poate de asemenea avertiza hostul sursă asupra rutelor preferate sau asupra congestiei reţelei.

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.

Valoare Clasă

0÷127 A

128÷191 B

192÷223 C

224÷255 D

Antet ICMP Date ICMP

Antet pachet Date pachet

Antet cadru Date cadru Sfârşit cadru

0 8

Identificator Număr de secvenţă Sumă de verificare

Date ICMP (depinde de tipul mesajului)

31

Fig. 2.29 Formatul mesajului ICMP.

16 31

Identificator (tipul mesajului) - Acest câmp poate lua una dintre următoarele valori (8 biţi), în funcţie de tipul mesajului:

0 - Răspuns ecou (Echo reply), 3 - Destinaţie inaccesibilă (Destination unreachable), 4 - Oprirea sursei (Source quench), 5 - Redirectare, 8 - Cerere ecou, 9 - Anunţarea unui ruter,

10 - Solicitarea unui ruter, 11 - Depăşire timp, 12 - Problemă legată de un parametru, 13 - Cerere etichetă de timp, 14 - Răspuns etichetă de timp, 17 - Cerere mască de adrese, 18 - Răspuns mască de adrese, 30 - Descoperire rută (Traceroute), 37 - Cerere nume domeniu, 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.

1.8 Protocolul de control al transmisiei (TCP). Caracteristici generale ale TCP. Formatul TCP.

TCP reprezintă baza unui mecanism de comunicaţie interprocese aşezat peste câteva nivele care oferă servicii nedemne de încredere, nivele în care pot să apară pierderi, duplicări, întârzieri, erori sau dezordonări ale pachetelor. Este un protocol complex, care trebuie să se ocupe, de exemplu, de detecţia pachetelor pierdute, retransmisia automată şi probleme "patologice", cum ar fi apariţia unor pachete duplicat întârziate.

Potenţialul de a asigura robusteţe în faţa unui mediu de transmisie nesigur, fac din TCP un protocol foarte dorit de o multitudine de aplicaţii care fac apel la intercomunicaţie.

TCP poate lucra şi în medii constituite din reţele interconectate. A fost special proiectat să lucreze deasupra protocolului IP, aflat la nivelul trei din modelul ISO OSI (nivelul reţea), ca în figura 9:

Caracteristici generale ale TCP

TCP are sarcina de a asigura servicii de comunicaţie sigure între procese pereche aflate în cadrul unor calculatoare gazdă distincte legate în aceeaşi reţea sau în cadrul unui set de reţele interconectate. Oferă transferuri de date orientate pe conexiune la nivelul transport - aceleaşi servicii de bază ca şi Sequenced Packet Protocol (SPP) realizat în cadrul XNS.

TCP acceptă o gamă largă de ULP care au nevoie să trimită date perechilor lor aflate pe alte calculatoare gazdă. TCP nu încearcă să impună vreo structură a datelor trimise de către un protocol de la nivel superior.

TCP tratează datele primite ca pe un şir continuu, lăsând structurarea mesajelor pe seama ULP, spre deosebire de SPP, care ajută propriii clienţi la demarcarea mesajelor. TCP încearcă, totuşi, să segmenteze datele în unităţi distincte astfel încât ele să poată fi transmise şi recepţionate ca pachete individuale. Fiecare astfel de unitate este numită segment.

Dacă este nevoit să retransmită o serie de segmente, TCP poate să reîmpacheteze datele, combinând două segmente mai mici într-un segment mai mare, de exemplu. Acest mecanism, motivat de dorinţa de a spori eficienţa transmisiei în cadrul unor reţele larg distribuite, unde se pune problema minimizării raportului între numărul de biţi ai headerului şi numărul de biţi de date, face ca TCP să fie mai complex decât alte protocoale de transport.

Transmisia unui pachet folosind TCP poate să decurgă după cum urmează (figura 10):

(1) ULP sursă trimit un flux de date către TCP pentru transmisie;

(2) TCP împarte fluxul de date în segmente, eventual înzestrate cu informaţii privind retransmisiile, ordonarea, codificarea nivelelor de precedenţă şi de securitate, controlul fluxului de date şi contolul erorilor. Apoi, segmentul este trimis către IP.

(3) IP execută propriile atribuţiuni (creând datagramele, executând eventualele fragmentări etc.) şi transmite datagramele prin nivelul legăturii de date şi nivelul fizic de-a lungul reţelei până la IP destinaţie;

(4) IP destinaţie execută procesele de control sau reasamblare necesare şi livrează datagramele ca segmente către TCP destinaţie;

(5) TCP destinaţie îşi execută propriile servicii (inverse celor de la pasul 2), restaurând datele fragmentate pentru a reconstitui fluxul original de date transmis şi livrează aceste date către ULP destinaţie.

O descriere completă a serviciilor menţionate la pasul doi de mai sus este: - Full-duplex - o conexiune TCP permite transmisia simultană în ambele direcţii a datelor între ULP corespunzătoare; - Timely - atunci când condiţiile din cadrul sistemului nu permit trimiterea la timp a datelor, aşa cum a fost specificat de un parametru de time-out al ULP, TCP anunţă ULP asupra eşecului şi ULP poate atunci termina conexiunea sau să ia o altă decizie adecvată; - Ordered - TCP livrează datele către ULP destinaţie în ordinea în care le-a primit de la ULP sursă; - Labeled - TCP asociază fiecărei conexiuni nivelele de precedenţă şi securitate care i-au fost indicate de către ULP în timpul stabilirii conexiunii. Atunci când informaţiile nu sunt indicate de către ULP-urile pereche, TCP va folosi nişte valori implicite. TCP stabileşte o conexiune între o pereche de ULP doar dacă informaţiile de securitate indicate de cele două ULP care formează perechea sunt identice. Fiecare segment TCP este etichetat cu valoarea negociată a indicatorului de securitate. Dacă apare o neconcordanţă a nivelului de securitate în timpul unei conexiuni faţă de nivelul negociat la început, TCP va termina conexiunea; - Flow controlled - TCP regularizează fluxul de date prin conexiune pentru a preveni, printre altele, congestia internă a TCP, care ar duce la degradarea sau eşecul serviciilor oferite;

(6) Error checked - TCP livrează datele lipsite de erori, garantând că datele sunt lipsite de erori în măsura în care se poate garanta acest lucru bazându-se pe o sumă de control.

Formatul TCP Headerul TCP este relativ mare, structura sa fiind prezentată în figura 11.

Destination Port (Portul destinaţie) Abreviere: DEST PORT Lungimea câmpului: 16 biţi Acesta este un câmp care identifică procesul sau serviciul în cardul calculatorului

gazdă receptor. Câmpurile Source Port şi Destination Port sunt sub controlul calculatoarelor gazdă.

Fiecare host poate să decidă pentru sine cum să aloce porturile.

Sequence Number (Număr în cadrul secvenţei) Abreviere: SEQ Lungimea câmpului: 32 biţi Unitate: octeţi Gamă: 0÷232 -1 Această valoare reprezintă poziţia în cadrul secvenţei de octeţi a primului octet al

unui segment. Totuşi, dacă este prezent un SYN, atunci valoarea acestui câmp reprezintă prima poziţie în cadrul secvenţei (Initial Sequence Number - ISN) pentru acea conexiune; primul octet de date este numerotat ISN+1.

Câmpurile Sequence Number şi Acknowledgement au ambele lungimea de 32 biţi, permiţând astfel specificarea unui spaţiu de secvenţiere foarte mare. (La o rată de transfer al datelor de 1000 octeţi pe secundă, ar fi necesare aproximativ 50 de zile pentru a fi necesară reluarea numerotării cu numărul în cadrul secvenţei zero. Dată fiind durata maximă de viaţă a unui pachet - 255 secunde - nu este posibil ca un pachet vechi să aibă acelaşi număr de secvenţă ca şi unul nou şi să pară că ar fi un pachet duplicat sau să fie recepţionat în locul unui pachet care nu a fost livrat din cauza unor erori).

Acknowledgement Number (Număr de confirmare) Abreviere: ACK Lungimea câmpului: 32 biţi Unitate: octeţi Gamă: 0÷232 -1 Dacă este setat bitul de control ACK, acest câmp conţine valoarea numărului de

secvenţă al următorului octet pe care receptorul se aşteaptă să-l primească.

Data Offset (Deplasamentul datelor) Lungimea câmpului: 4 biţi Unitate: 32 biţi Gamă: 5÷15, implicit 5 Acest câmp indică numărul de cuvinte de 32 de biţi conţinute în cadrul headerului

TCP. Folosind această valoare, poate fi calculat deplasamentul datelor în cadrul pachetului. Această informaţie este necesară datorită lungimii variabile a câmpului Options. Headerul TCP, chiar dacă include un câmp Options, are o lungime care este un multiplu de 32 biţi.

Reserved (Rezervat) Lungimea câmpului: 6 biţi Acest câmp este rezervat pentru extensii ulterioare. Trebuie să aibă toţi biţii zero.

Control Flags (Indicatori de

control) Lungimea câmpului: 6 biţi

Acest câmp conţine un număr de indicatori de câte un bit fiecare, folosiţi pentru stabilirea, terminarea şi menţinerea unei conexiuni:

- URG - Urgent Pointer. URG=1 indică faptul că este folosit câmpul Urgent Pointer pentru a localiza date urgente, prin intermediul unui offset exprimat în octeţi faţă de numărul de secvenţă curent. Acest pointer poate fi necesar în cazul apariţiei unei întreruperi. Dacă indicatorul URG nu este setat, atunci câmpul Urgent Pointer trebuie ignorat.

- SYN - Este folosit pentru a stabili o conexiune. SYN=1 semnifică cererea de stabilire a unei conexiuni.

- ACK - Indică faptul că are semnificaţie câmpul Acknowlwdgement. - RST - Poate reseta o conexiune în cazul apariţiei unor pachete întârziate cu bitul

SYN setat, în cazul căderii calculatorului gazdă sau în alte cazuri. RST=1 înseamnă că trebuie resetată conexiunea.

- PSH - PSH=1 transmite TCP-ului receptor să transmită imediat datele din cadrul segmentului către ULP receptor. Acest bit poate fi folosit pentru a indica faptul că nu vor apărea date de la ULP sursă imediat.

- FIN - Este folosit pentru a termina o conexiune. FIN=1 înseamnă că sursa nu va mai transmite date către ULP receptor.

Window (Fereastră) Abreviere: WNDW Lungimea câmpului: 16 biţi Unitate: octeţi Gamă: 0÷216-1 Această valoare reprezintă numărul octeţilor de date, începând cu cel indicat în

cadrul câmpului Acknowledgement, pe care hostul sursă este dispus sâ îi accepte. Window este parametrul care permite controlul fluxului în cadrul TCP. Window este

un câmp relativ lung deoarece numără octeţii care vor putea fi recepţionaţi după octetul confirmat, în loc să numere pachetele care ar putea fi trimise (cum se face în cazul SPP-XNS).

Checksum (Sumă de control) Lungimea câmpului: 16 biţi Acest câmp se aplică tuturor cuvintelor de 16 biţi din cadrul headerului şi datelor. El

de asemenea acoperă un pseudo-header de 96 biţi care conceptual precede headerul TCP. Acest pseudoheader conţine adresa sursei, adresa destinaţiei, identificatorul de protocol şi lungimea segmentului TCP.

Checksum conţine complementul faţă de 1 al sumei complementelor faţă de 1 ale tuturor cuvintelor de 16 biţi din header şi din cadrul câmpului de date.

Urgent Pointer (Pointer urgent) Abreviere: URGPTR Lungimea câmpului: 16 biţi Unitate: octeţi Gamă: 0÷216-1 Acest câmp specifică ultimul octet de date urgente. Valoarea câmpului este un deplasament pozitiv faţă de numărul de secvenţă în

cadrul segmentului. Adunând URGPTR la SEQ se poate afla numărul din cadrul secvenţei al ultimului octet de date urgent. Acest câmp are semnificaţie doar dacă este setat bitul de control URG.

Options (Opţiuni) Abreviere: OPT Lungimea câmpului: variabilă Dacă este prezent, acest câmp ocupă spaţiu la sfârşitul headerului TCP. Toate

opţiunile sunt incluse în Checksum. Orice opţiune ocupă un număr întreg de octeţi. Options este rezervat pentru diferite lucruri. Singura opţiune oficială interesantă

definită până în prezent comunică lungimea maximă a unui segment şi este trimisă în timpul stabilirii conexiunii.

1.9 Protocolul UDP(User Datagram Protocol). Numerele porturilor utilizate de

protocoalele de transport

UDP este descris de către RFC 768 — User Datagram Protocol. UDP reprezinta alaturi

de TCP unul dintre cele mai importante protocoale de transport . Acesta nu garanteaza

corectitudinea transmisiunii asa cum o face TCP . Datagramele pot ajunge la destinatie

neordonate , duplicate sau chiar lipsa fara sa se observe . El nu adauga nici un fel de

siguranţa, control al transmisiei sau recuperare de erori la IP. El foloseste portul drept

multiplexor/demultiplexor pentru trimiterea si primirea datagramelor asa cum este

ilustrat in figura urmatoare.

Insa tocmai evitarea de a consuma resursele face ca UDP sa fie mai rapid si mai eficient

petru aplicatiile care nu necesita garantarea livrarii pachetelor .

Spre deosebire de TCP , UDP poate fi utilizat atat pentru transmisiuni broadcast cat

si multicast .

Dintre aplicatiile care folosesc UDP ca protocol de transport pot fi enumerate:

Serverul de nume DNS (Domain Name System)

Dynamic Host Configuration Protocol – DHCP

Trivial File Transfer Protocol (TFTP)

Voice over IP – VoIP

Remote Procedure Call (RPC), utilizat de catre NFS (Network File System)

Ca exemplu , protocolul UDP este folosit de protocoalele de rutare pentru a

transmite up-date-uri de rutare intre ele . Aceste up-date-uri sunt folosite de rutere

pentru a aduce reteaua la starea de convergenta sau pentru a mentine functionalitatea

tabelelor de rutare . Este evident faptul ca in acest caz pierderea unui up-date de rutare

are o mai mica importanta decat conservarea resurselor de procesare .

Structura unui pachet UDP :

Portul sursa indica portul atribuit aplicatiei de catre statia sursa . Avand in vedere ca

in cazul UDP nu este nevoie sa se returneze nimic de la destinatie la sursa , acest cimp

poate fi 0 .

Portul destinatie identifica aplicatia de pe statia destinatie si este absolut necesar.

Lungimea este un camp de 16 biti care specifica lungimea in biti a intregii

datagrame incluzand header-ul si data.

CheckSum este reprezentat de un camp de 16 biti care are rolul de a oferii un

control al erorii prin compararea valorii cheksum-ului cu numarul de biti primiti de statia

destinatie.

Campul data reprezinta informatia in sine care trebuie transmisa.

Formatul datagramelor UDP

In limbajul curent unitatile de transmisie a informatiei pentru UDP se numesc datagrame

UDP. Fiecare datagrama UDP este trimisa intr-o singura datagrama IP. Cu toate ca,

datagrama IP poate fi fragmentata in timpul transmisiei, implementarea IP a hostului

destinatie o va reasambla inainte de a prezenta-o stratului UDP. Toate implementarile

IP trebuie sa accepte datagrame de pana la 576 octeti, ceea ce inseamna ca, pentru un

antet IP de 60 octeti maxim, o datagrama UDP de 516 octeti va fi acceptata de toate

implementarile. Multe implementari vor accepta datagrame mai mari, dar acest lucru nu

este garantat.

Numerele porturilor utilizate de protocoalele de transport

Fiecare proces care necesită comunicarea cu un alt proces se identifică în cadrul

unei stive TCP/IP printr-un port sau mai multe.

Un ID port este un număr reprezentat pe 16 biţi utilizat de către un protocol capăt la

capăt pentru a identifica cărui protocol de nivel superior sau program (proces) de

aplicaţie trebuie să-i livreze mesajele recepţionate. Acestea sunt reprezentate prin

numere de la 1 la 65535.

Există două tipuri de porturi:

- Porturi consacrate: aceste porturi aparţin unor servere standard, cum ar fi

serverul Telnet care foloseşte portul 23. Numerele asociate porturilor consacrate aparţin

intervalului de la 1 la 1023. Cele mai multe servere necesită numai un singur port.

Excepţie fac serverul BOOTP, care foloseşte două porturi (67 şi 68) şi serverul FTP,

care foloseşte două porturi (20 şi 21). Porturile consacrate sunt controlate şi alocate

de către Autoritatea de Asociere a Numerelor în Internet, IANA (Internet Assigned

Number Authority) şi în cele mai multe sisteme nu pot fi alocate decât proceselor sistem

sau programelor executate de utilizatorii cu drepturi speciale. Porturile consacrate

permit clienţilor să găsească serverele fără a necesita informaţii de configurare

suplimentare.

- Porturi temporare: unii clienţi nu necesită numere de porturi consacrate

deoarece aceştia iniţiază comunicaţiile cu serverele, iar numărul portu lui utilizat de

fiecare dintre clienţi este conţinut în mesajul UDP/TCP transmis către server. Fiecărui

proces client i se asociază un număr de port, de către sistemul pe care acesta rulează,

pentru un interval de timp nedefinit, cât necesită procesul client să transfere datele.

Numerele porturilor temporare au valori mai mari decât 1023, uzual fiind în intervalul de

la 1024 la 65535. Porturile temporare nu sunt controlate de IANA şi pot fi utilizate în

oricare sistem, de către orice program dezvoltat de către utilizator. Confuziile posibile

care pot apare atunci când două aplicaţii diferite încearcă să utilizeze aceleaşi numere

de porturi, într-un acelaşi sistem, se pot evita prin configurarea acelor aplicaţii să solicite

un port disponibil în stiva locală TCP/IP. Deoarece numărul de port este alocat dinamic,

acesta poate fi diferit de la o cerere la alta a aplicaţiei.

Observaţie: În mod uzual, un server foloseşte fie TCP, fie UDP, dar există şi

excepţii. Spre exemplu, aplicaţia DNS (Domain Name System), utilizează atât portul

53 al UDP, cât şi portul 53 al TCP.

In tabelul de mai jos putem vedea unele din cele mai utilizate servicii, respectiv

numarul de port si protocolul utilizat:

Nr. portului Protocolul utilizat Serviciul

110 TCP POP3

80 TCP HTTP

53 TCP / UDP DNS

161 UDP SNMP

79 TCP Finger

69 UDP TFTP

25 TCP SMTP

1.10 PROTOCOALE DE ADRESARE(ARP, RARP, DHCP) 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.

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 Protocol).

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 broadcast). 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.

Când recepţionează pachetul de răspuns, sursa îşi completează tabelul ARP cu noile adrese(MAC si IP).

Dacă sursa nu primeşte nici un răspuns, atunci cererea este retransmisă. Dacă nici la retransmisie nu se răspunde, sursa recepţionează un mesaj de eroare generat de protocolul ICMP. în cazul în care destinaţia nu se află în reţeaua locală, ruterul de legătură cu WAN-ul răspunde cu propria sa adresă, prin tehnica numită Proxy ARP (RFC 1027), dacă prin configurarea conexiunii gazdei cu reţeaua nu este dezactivată opţiunea proxy.

Protocolul RARP Protocolul RARP (Reverse Address Resolution Protocol) face conversia inversă,

a adreselor fizice în adrese de reţea. Dacă o staţie de lucru nu-şi cunoaşte adresa IP, atunci trimite serverului RARP

un pachet cu o cerere RARP (cu semnificaţia "Care este adresa mea IP?"), în modul broadcast (pentru Ethernet,se foloseşte adresa IP de destinaţie cu toţi biţii din câmpul gazdei egali cu 1).

Pachetul RARP include adresele MAC ale sursei şi destinaţiei, adresa IP de broadcast, un câmp de adresă IP necompletat pentru adresa IP proprie si codul cererii RARP, conţinut în memoria sa ROM. Serverul RARP răspunde cererii cu un pachet conţinând adresa IP solicitată.

Formatul pachetului conţinând cererea RARP

Routerele nu retransmit în afara LAN cererile ARP/RARP în mod broadcast, evitând propagarea infinită a lor în WAN.

Dynamic Host Configuration Protocol - DHCP Este o modalitate rapida si simpla de a aloca adrese IP unui numar mare

de clienti, moment in care BOOTP ar deveni greoi de utilizat si ineficient. Exista nevoia de a defini un interval de IP-uri valide si de a aloca automat clientilor din retea; de asemenea, a aparut nevoia de a defini o durata de viata unui IP.

Metoda de a introduce manual adresa IP poate avea si ea utilitatea ei. Spre exemplu, ofera accesul imediat la datele vitale pentru functionarea in retea ale fiecarui calculator. Totusi, metoda este consumatoare de timp si este expusa erorilor.

Functionarea DHCP DHCP implementeaza un model client-server si un agent cu rol de releu

(relay agent). Acest agent gestioneaza interactiunea dintre clienti si server. Deoarece clientul este principalul partener de comunicatie in aceasta situatie, el initiaza toate sesiunile cu serverul, lucru care are loc in faza de bootare. DHCP are urmatoarele facilitati:

- suporta alocarea dinamica - suporta alocarea statica

- conlucreaza cu BOOTP - repartizeaza adrese - suporta repartizarea persistenta - reintegreaza repartitiile expirate In esenta, DHCP este insarcinat cu manipularea a doua seturi de date:

repartitiile (IP-urile alocate) si fondul de adrese (IP-uri disponibile). Repartitiile sint alocate clientilor conform unei proceduri, care este destul de simpla.

Cum primesc clientii numere IP Iata modul de functionare a DHCP din acest punct de vedere: 1. Clientul cere un IP printr-o difuzare de tip DhcpDiscover. Daca clientul are o

repartitie persistenta, poate cere acea repartitie initial. 2. Serverul alege un IP din fondul de adrese si intoarce un pachet DhcpOffer cu

un IP disponibil atasat. 3. In cazul in care clientul doreste mai multe oferte IP, o va alege pe prima sau

pe cea cu repartitia dorita. 4. Clientul difuzeaza un pachet DhcpRequest cu un identificator pentru un server

si trece in asteptare 5. Fiecare server care analizeaza pachetul si nu isi detecteaza identificatorul va

ignora pachetul. Dupa ce serverul cu identificatorul corespunzator primeste pachetul, el va trimite un DhcpAck (sau DhcpNak, daca IP-ul cerut este deja alocat, ceea ce inseamna ca repartitia a expirat).

6. Dupa ce clientul primeste pachetul DhcpAck, el incepe sa foloseasca IP-ul alocat. In cazul in care primeste DhcpNak, va rula de la inceput secventa de cerere a unui IP. Daca IP-ul reprezinta o problema din punct de vedere al clientului, acesta trimite un pachet DhcpDecline catre server si reia secventa de cerere a unui IP.

Repartitiile DHCP gestioneaza adrese IP distribuite prin oferirea de repartitii (leases –

inchirieri). In principiu, se defineste un interval de timp in care un IP ramine asociat unei masini. Daca repartitia expira (intervalul de timp stabilit expira inainte de refolosirea conexiunii), clientul trebuie sa ceara o noua adresa IP.

Aceasta este o metoda de a gestiona repartitiile permanente in medii dinamice care au disponibile putine IP-uri, dar prefera sa mentina o anumita adresa IP pentru un utilizator anume. Daca este nevoie de acel IP, el poate fi alocat unei alte masini, dar va fi alocat din nou masinii care l-a cerut initial cind va fi iarasi disponibil. A se retine ca un client trebuie sa se deconecteze de la retea pentru a putea cere din nou un IP.

1.11 Protocolul Telnet, Finger Scopul protocolului TELNET este de a oferi facilitati generale, bi-directionale, orientate pe octeti de opt biti. Scopul sau primar este de a permite o metoda standard de interfata intre dispozitivele de terminal si procesele orientate pe rularea intr-un terminal.

CONSIDERATII GENERALE O conexiune TELENT este o conexiune TCP (Transmission Control Protocol - Protocol de control al transmiterii) utilizata la transmiterea de date, continanad in plus informatii de control TELNET. Protocolul TELNET este constriut pe trei idei principale: prima, conceptului "terminalului virtual de retea"; a doua, principiul optiunilor negociate; si a treia, o vedere simetrica a terminalelor si proceselor. 1. Cand este stabilita pentru prima oara o conexiune TELNET, fiecare capat se presupune ca incepe sau se termina intr-un "Terminal virtual de retea" (NVT - "Network Virtual Terminal"). Un NVT este un dispozitiv imaginar care ofera o reprezentare standard, pentru toate retelele, intermediara a unui terminal canonic. Acesta elimina necesitatea ca gazdele "server" sau "utilizator" sa pastreze informatii despre caracteristicile terminalelor fiecareia si conventiile manevrarii teminalelor. Toate gazdele, atat utilizator cat si server, isi mapeaza caracteristicile locale ale dispozitivelor si conventiilor asa incat aparent sa para ca interactioneaza cu un NVT din retea, si fiecare presupune ca acelasi lucru se intampla si la partenerii lor de comunicatie. NVT-ul intentioneaza sa echilibreze tendinta de a fi prea restricitv (neacordand gazdelor un vocabular destul de bogat pentru maparea locala a caracterisitcilor proprii), si de a fi prea intelegator (penalizand utilizatorii cu terminale modeste). Telnet-ul oferă acces la un protocol aflat la distanţă, rulînd peste TCP. El permite unui utilizator de a stabili un circuit de conexiune virtuală la un sistem aflat la distanţă şi introducerea intrărilor de la tastatura locală către calculatorul aflat la distanţă. Utilizînd Telnetul, un utilizator de la un host se poate loga la alt host, de parcă acesta s-ar afla chiar direct în faţa sistemei aglate la distanţă; aceasta şi reprezintă o definiţie TCP/IP a terminalelor virtuale.

Figura 2.1.1 Interacţiunea clientului şi serverului prin intermediul protocolului Telnet

Telnet-ul utilizează o structură client-server şi oferă trei servicii de bază. Mai întîi de toate, el defineşte un terminal vitual de reţea (NVT), care asigură interfaţa sistemului aflat la distanţă unde procesul de aplicaţie rezidă. În al doilea rînd el oferă un mecanism care permite clienţilor şi serverilor să facă negocieze parametrii. Şi în final, Telnet tratează ambele capete ale conexiunii în mod simetric, adică orice capăt a conexiunii poate servi ca utilizator sau ca host. Modelul client-server a Telnet-ului este foarte simplu. Clientul interacţionează cu terminalul utilizatorului pentru a converta caracteristicile fizice a terminalului în NVT. Serverul (host) interaţionează cu procesul aplicaţiei la sistemul gazdă. Acesta interacţionează ca un terminal de manipulare de schimb, aşa că terminalul de la distanţă apare ca terminalul local la sistemul gazdă.

Utilizează Port/ID-ul 23 peste TCP. Protocolul Finger

Finger este un protocol simplu de tip serviciu Internet, bazat pe modelul clicnt-scrvcr, care permite unui client Fingcr să obţină dc la un server Fingcr informaţii cu caractcr public despre un anumit utilizator sau despre toţi cei activi în reţea, la un moment dat.

Interogarea serverului Finger se face pe portul de protocol 79 şi se exprimă în formatul NVT ASCII definit de Telnet, având ca simbol de sfarsit de linie combinaţia de caractere CR-LF(Carriage Return - Line Feeder).

Serviciul Finger este orientat pe conexiunea dintre două socket-uri (prin sockct, se înţelege un pointer la o structură de date memorată într-un buffer). După stabilirea conexiunii folosind TCP, se transmite cererea Finger.

Dacă apelul e realizat printr-o linie vidă (numai CR-LF), atunci serverul răspunde cu lista completă a tuturor utilizatorilor concctaţi la server în accl moment. Comanda folosită în acest caz finger

Dacă lista complctă a utilizatorilor arc o dimensiune carc depăşeşte lungimea maximă a unităţii dc transmisie din rctca (MTU), atunci TCP transmite datele în mai multe segmente de mesaj.

Comanda de interogare Finger poate să includă numele real al unui utilizator conectat la server: finger {nume} sau ID-ul utilizatorului si numele calculatonilui-gazdă, cu sintaxa:

finger {nume_utilizator}@{nume_calculator_gazda} Răspunsul constă în informaţiile disponibile despre acesta: numele de utilizator,

numele real al persoanei, contul curent al acesteia (horne directory), ultima dată la care s-a conectat la reţea, numele statici la care s-a tăcut concxiunca, informaţii privind folosirea serviciului dc postă electronică de către utilizator etc.

Dacă serverul Finger recepţionează orice în afara unei linii vide, atunci acesta presupune că textul identifică un anumit utilizator si returnează toate informaţiile publice despre utilizatorii cu numele sau ID-ul asemănător textului.

Serverul Fingcr transmite mesajul dc răspuns staţiei sau sesiunii Tclnct dc la carc s-a iniţiat cererea. Clientul recepţionează datele fie sub forma unui sir de octeţi (byte stream), fie prin datagrame, si le memorează într-un buflfer local. în cazul în care volumul datelor depăşeşte capacitatea dc memorare a accstuia, atunci datele se pierd si se returnează un mesaj dc eroare. Clientul recepţionează un mesaj dc eroare, prin intermediul ICMP, desi conexiunea a functional corect si transmisia este considerată reuşită.

Serverul Finger închide automat conexiunea după ce a transmis toate datele solicitate.

Pe durata unei conexiuni active, este necesară aplicarea unor măsuri de securitate pentru a evita accesul nedorit al unui utilizator neautorizat la resursele unui calculator-gazdâ implicat în acea conexiune. Un server Fingcr poate fi configurat astfel încât o cerere Fingcr adresată lui de la distanţă, să iniţieze pe server un fişier capabil să ruleze comenzi dc sistem (scripting).

1.12 POSTA ELECTRONICĂ

Posta electronică (e-mail / electronic mai/) este unul dintre cele mai utilizate servicii

de

comunicaţii din Internet.

Dupa cum vedem in figura de mai jos (Fig. I.) într-o reţea de calculatoare, sistemul de

postă electronică are următoarele componente:

1. memorie de stocare a mesajelor ce urmează a fi transmise ("coadă de ieşire");

2. procesul client de mail;

3. procesul server de mail;

4. cutiile poştale (mailbox) ale utilizatorilor pentru stocarea mesajelor primite.

Programul de postă electronică de pe un calculator, denumit agent utilizator (UA – User

Agent) oferă utilizatorului o interfaţă spre sistemul de postă electronică din Internet, care,

în general, nu este considerată parte componentă a acestuia. Scopul UA este de a facilita

accesul utilizatorului la serviciul de e-mail din reţea (Fig.I.)

Procesele (client sau server) care realizează serviciul de postă electronică, prin

transferul mesajelor în sau din Internet se numesc agenţi de transfer a mesajelor (MTA -

Message Transfer Agent).

Fig. I. Structura sistemului de postă electronică

Intre doi agenţi de transfer a mesajelor se stabileste o conexiune TCP, iar comunicarea

se face pe baza protocoalelor de poştă electronică (de exemplu, SMTP - Simple Message

Transfer Protocol, POP - Post-Office Protocol).

Majoritatea MTA folosesc SMTP pentru transferul mesajelor în format NVT ASCII, prin

conexiuni TCP la portul 25 (RFC 821).

SMTP permite comunicaţii duplex între client şi server, pentru transmisia secvenţelor

de comandă în format NVT ASCII.

Se poate utiliza SMTP pentru transmisia mesajelor de tip text, dar si de altă natură

(imagine, audio, video) prin definirea unor extensii ale protocolului.

SMTP este implicat în transmisia poştei electronice spre serverul de mail si spre

Internet. Preluarea mesajelor de postă de la cutiile poştale sau din Internet se face

conform protocolului POP.

Orice mesaj de e-mail este compus din antet şi corp (RFC 822). în antetul introdus de

UA si transmis către MTA, în funcţie de programul de e-mail folosit, pot să apară mai

multe câmpuri (Date. Front. Subject, Reply-To, cc, Atachenient, Continent. Message-ID,

X-Special-Action etc ). La nivelul MTA se împachetează mesajul cu informaţii

suplimentare (eventual se specifică o calc cu agenţi de comutare) în asa-numita anvelopă

si se transmite altui MTA sau agentului de comutare local.

Se pot defini extensii ale protocolului SMTP pentru transmisia prin sistemul de e-mail

a unor documente de tip multimedia (RFC 1425, RFC 1427, RFC 1521) precum ar fi

protocolul MIME.

Fig.3.1 Dialogul SMTP pentru transferul unui mesaj de la client la server.

SMTP este responsabil de livrarea poştei electronice în Internet. Pentru preluarea

mesajelor de e-mail din Internet se utilizează protocolul POP, orientat pe conexiunea

dintre client si server.

UA Server POP

Fig. II. 12 Configuraţia client-server POP

Desi oferă servicii relativ similare, versiunile POP2 (RFC 937) si POP3 (RFC 1225)

sunt incompatibile si au asociate porturi de protocol diferite (109, 110).

POP2, corespondent fidel al SMTP, având comenzi asemănătoare, se aplică numai

local.

Din motive de securitate, unii administratori de reţea dezactivează serviciul de acces

de la distantă (remote login) în LAN.

Versiunea POP3 permite accesul de la distanţă la serviciul dc postă electronică, mai

precis la căsuţa poştală rezervată utilizatorului.

O sesiune POP3 are trei stări: autorizare, tranzacţie si încheiere.

Protocolul utilizat pentru extragerea mesajelor unui utilizator de pe un calculator

server care îi gestionează casuţa poştală se numeşte POP3 (Post Office Protocol Version

3). Portul TCP standard pentru protocolul POP3 este 110. Rolul acestui protocol este de

a permite utilizatorilor să îşi aducă mesajele de pe calculatorul server (care are rolul de

oficiu poştal) pe propriul calculator.

Etapa de recepţionare a unui e-mail presupune că utilizatorul căruia îi este destinat

mesajul să pornească aplicaţia client pentru serviciul de poştă electronică şi să îi

specifice acesteia să extragă de pe calculatorul server (care are rolul de oficiu poştal)

noile mesaje asociate căsuţei sale poştale.

Protocolul POP3 defineşte un limbaj de comunicare între procesul care cere

informaţiile (client) şi procesul care executa comenzile şi transmite mesajele cerute de

către client (server).

Principalele avantaje oferite de către acest protocol sunt:

1) Extragerea mesajelor de pe calculatorul server;

2) Ştergerea mesajelor (care au fost sau nu recepţionate) de pe calculatorul server;

3) Posibilitate utilizării versiunii securizate, POPS3, care criptează informaţiile transmise

între procesul client şi procesul server, pentru a preveni astfel interceptarea acestora.

Comunicaţia între procesul client şi procesul server se efectuează in modul urmator:

clientul trimite o comanda serverului, acesta o execută şi returnează clientului un cod

numeric.

Comenzile POP3 constă din codul comenzii format din patru litere şi urmat opţional

de un parametru. Acestea pot fi scrise atît cu minuscule cît şi cu majuscule şi reprezintă

o combinaţie de prescurtări de cuvinte specifice din limba engleză.

Principalele comenzi definite de protocolul POP3 sunt:

a) USER <utilizator> - specifică procesului server numele utilizatorului pentru care

să deschidă căsuţa poştală;

b) PASS <parola> - trimite procesului server parola contului de utilizator asociată

cu contul de utilizator specificat la comanda precedentă;

c) LIST [<numar_mesaj>] – cere procesului server să listeze toate mesajele

utilizatorului;

d) RETR <numar_mesaj> - cere procesului server să listeze continutul mesajului

cu numărul de identificare specificat de parametrul <numar_mesaj>;

e) DELE <numar_mesaj> - şterge mesajul cu numărul specificat de parametrul

<numar_mesaj>;

f) QUIT - inchide canalul de comunicaţie dintre client şi server;

g) STAT – cere procesului server să afişeze informaţii statistice despre căsuţa

poştală a utilizatorului curent (şi numărul de mesaje din căsuţa poştală şi

dimensiunea totală a acestora);

h) LAST – cere procesului server să afişeze numărul de identificare al ultimului

mesaj venit în căsuţa poştală;

i) TOP <numar_mesaj> <numar_linii> – specifică procesului server să listeze din

mesajul cu numărul de identificare specificat de parametrul <numar_mesaj>

primele <numar_linii> de conţinut;

j) RSET – resetează starea mesajelor din casuţa poştala (refacand mesajele

şterse).

Modul de recepţionare a unui mesaj

Pentru a testa comenzile implementate în protocolul POP3 şi a stimula un dialog

dintre un proces client POP3 si un proces server POP3 se poate utiliza aplicatia telnet,

procesul fiind constituit din următoarele etape:

conectarea la calculatorul serverul;

autentificarea clientului POP3;

listarea sumara a mesajelor din casuta postala;

listarea continutului unui mesaj;

stergerea unui mesaj;

inchiderea conexiunii.

Fig. 2.1 Proocesul de comunicare între server şi client utilizînd protocolul POP3

1.13 Protocoale pentru transferal fisierelor (FTP, TFTP) Servere FTP. FTP anonim şi autentificat

File Transfer Protocol (FTP) este în acelaşi timp un protocol al nivelului aplicaţie TCP/IP şi un serviciu care permite schimbul de fişiere prin Internet. Pentru utilizarea FTP în scopul transmiterii şi recepţionării de fişiere prin Internet, avem nevoie de două aplicaţii diferite: un server FTP şi un client FTP. Menţionăm faptul că FTP este un bun exemplu de arhitectură client/server, în care aplicaţiile necesare pentru transferul fişierelor sunt împărţite între server şi client.

Modalităţi de transmisie a datelor prin FTP

Pentru transmiterea de date FTP utilizează protocolul TCP. Comenzile şi datele spre deosebire de majoritatea altor protocoale se transmit prin porturi diferite. Portul 20 este utilizat pentru transmiterea de date, portul 21 pentru transmiterea de comenzi. În cazul în care transmiterea fişierului a fost întreruptă,din cauza oricărui motiv, protocolul dispune de mijloace pentru reluarea acestuia, fapt care este foarte comod în cazul transmiterii unor fişiere mari. Un server FTP poate să suporte două moduri de conexiune a clienţilor, depinzând de metoda care este specificată de client. Modalitatea de transmisie prin FTP este specificată în RFC 959. Spre deosebire de HTTP şi marea majoritate a protocoalelor utilizate pe

Internet, protocolul FTP utilizează minimum două conexiuni în timpul unei sesiuni: o conexiune de tip half-duplex pentru control şi o conexiune de tip full-duplex pentru transferul datelor. Portul implicit utilizat pentru controlul conexiunii este 21, iar conexiunea pentru date este determinată de metoda utilizată de client pentru conexiunea la server. Conexiunile FTP active sau gestionate de client sunt create prin intermediul unei comenzi PORT date de client către server (prin intermediul conexiunii de control) prin care se cere serverului să stabilească o conexiune de la portul TCP 20 de pe server către client, utilizând portul TCP specificat de comanda PORT. Conexiunile FTP pasive sau gestionate de server sunt create prin intermediul comenzii PASV împreună cu un port virtual care va fi utilizat ca şi port la nivel de server pentru conexiunea de date. După stabilirea unei comenzi de către client, serverul se conectează la client utilizând portul imediat superior portului pentru controlul conexiunii la nivel de client. Cea mai frecventă problemă întâlnită cu FTP pe Internet priveşte transferul de date prin intermediul unui server proxy, firewall sau dispozitiv NAT (Network Address Translation). În cele mai multe cazuri aceste dispozitive sau aplicaţii de reţea permit controlul conexiunii prin portul TCP 21 (pentru login în serverul FTP), dar când se încearcă un transfer de date printr-o comandă de tip DIR, LS, GET sau PUT, clientul FTP se blochează deoarece dispozitivul / aplicaţia de acces în reţea blochează portul pentru transfer de date specificat de client. În cazul în care dispozitivul sau aplicaţia de reţea suportă jurnalizarea, se poate verifica acest lucru prin vizualizarea jurnalelor de respingere a pachetelor.

TFTP

TFTP este un protocol simplu de transfer al fişierelor şi de aceea a fost denumit Protocolul pentru Transferul Trivial al Fişierelor.

TFTP a fost implementat utilizând protocolul de transport UDP Internet User Datagram Protocol (UDP sau Datagram) pentru a putea fi folosit la transferul fişierelor între maşini aflate pe reţele diferite ce implementează UDP. (Aceasta nu exclude posibilitatea ca TFTP sâ fie bazat şi pe alte tipuri de protocoale datagramă.) Este proiectat pentru a putea fi uşor de implementat. Tocmai de aceea îi vor lipsi majoritatea caracteristicilor unui FTP. Singurul lucru pe care îl face este să scrie şi să citească fişiere (sau mesaje) de la/spre un server de la distanţă. Nu poate lista directoare, şi momentan nu are facilităţi pentru autentificarea unui utilizator. în comun cu celelalte protocoale Internet estetransmisia a 8 biti de date. Cum am menţionat mai sus, TFTP este proiectat pentru a fi implementat pe modelul UDP. Şi pentru că protocolul Datagram este implementat pe Internet Protocol, pachetele vor avea un header Internet, un header Datagrama, şi un header TFTP. în plus, pachetele pot avea un alt header (LNI, header ARPA,etc.) pentru a permite accesul prin transportul medium local. Cum arată şi figura 3.1 , ordinea conţinuturilor pachetului va fi: header mediu local, dacă e folosit, header Internet, header Datagramă, header TFTP, urmatde restul rămas din pachetul TFTP (acesta poate reprezenta sau nu date dependente de tipul pachetului aşa cum e specificat în headerul TFTP). TFTP nu specifică nici un fel de valori în headerul Internet. Pe de altă parte, câmpurile porturilor sursă şi destinaţie ale header-ului Datagramă (formatul său este dat în appendix) sunt folosite de TFTP şi lungimea câmpului reflectă mărimea unui pachet TFTP. Identificatorii Transferului(TID) folosiţi de TFTP sunt preluaţi de layer-ul Datagrama pentru a fi folosiţi ca porturi; tocmai de aceea ar trebui sâ se încadreze între 0 şi 65,535. Iniţializarea TID-urilor este discutată în secţiunea următoare.

Header-ul TFTP conţine un câmp cu 2 octeti cod (opcodes) care indică tipul pachetului (de exemplu DATA, ERROR, etc.). Aceşti cod operatori şi formatul diferitelor tipuri de pachete sunt discutate mai incolo în secţiunea pachetelor TFTP.

____________________________________ | Local Medium | Internet | Datagram | TFTP | ---------------------------------------------------------

Figura 3-1 : Ordinea Header-elor

1.14 Functiile si avantajele – Protocolului SSH SSH (secure shell) 1 Noţiuni generale

SSH (Secure Shell ― "membrană sigură") este un protocol de reţea a Nivelului Sesiune şi Aplicaţie, care permite gestionarea de la distanţă a sistemei de operare şi securizarea conexiunilor TCP cu ajutorul unui tunel (ex. în cazul transmiterii de date). Se aseamănă după funcţionalitate cu protocoalele Telnet şi rlogin, dar spre deosebire de ele criptează tot traficul, inclusiv şi parolele transmise. Astfel SSH permite transmiterea sigură a datelor într-un mediu nesigur, practic oricărui protocol de reţea. În aşa mod este posibil nu numai lucru de la distanţă la calculator prin intermediul tunelului securizat, dar şi transmiterea prin acest canal a fluxului audio şi video. Deasemenea el ajută la comprimarea datelor pentru criptarea lor ulterioară. Portul/ID utilizat este 22/TCP.

SSH este utilizat în general pentru a accesa un calculator de la distanţă şi pentru a

executa comenzi. SSH oferă de asemenea securizarea transferului de fişiere între maşini prin executarea copierii securizate (SCP) şi a transferului de fişiere securizat (SFTP). SSH poate ajuta de asemenea în securizarea traficului X11 prin trimiterea acestuia printr-un tunel criptat. În acest fel SSH a fost utilizat pentru a defini o formă primitivă de reţea privată virtuală între gazde.

Componentele SSH cuprind serverul (SSHD), clientul (SSH), copierea (SCP) securizată a fişierelor şi ssh-keygen – o aplicaţie utilizată pentru a crea chei publice şi private utilizate pentru autentificarea maşinilor.

SSH oferă facilităţi de bază pentru translatarea porturilor, prin aceasta permiţându-se utilizatorilor să creeze tuneluri pentru protocoalele existente prin conexiunile SSH existente. De exemplu, transferul de date prin POP (care în mod normal trimite numele de utilizator şi parola sub formă de text clar), pot fi securizate prin SSH. Există şi limitări ale translatării porturilor, deoarece nici intervalele de porturi, nici porturile dinamice nu pot fi specificate.

Deşi translatarea porturilor ajută în securizarea protocoalelor, precum POP, există şi riscuri prin activarea acestei opţiuni – de exemplu, prin activarea unei conexiuni SSH de ieşire se poate permite unui utilizator să traverseze un firewall prin transformarea protocoalelor (tuneluri) de intrare care nu sunt permise de firewall prin sesiuni criptate SSH.

Utilizarea opţiunilor de autentificare a SSH protejează utilizatorii şi maşinile împotriva atacurilor de tip IP Spoofing, rutarea sursei IP, spoofing DNS etc. SSH constă în trei niveluri: nivelul /protocolul de transport, nivelul de autentificare precum şi nivelul conexiune. Protocolul transport este responsabil pentru gestionarea negocierii cheilor de criptare, cererilor de regenerare a cheilor, mesajelor de cereri de servicii precum şi a mesajelor de deconectare a serviciilor. Protocolul de autentificare este responsabil pentru negocierea tipurilor de autentificare, verificarea canalelor securizate înaintea trimiterii informaţiilor de autentificare precum şi pentru cererile de modificare a parolelor. Protocolul de conectare controlează deschiderea şi închiderea canalelor precum şi a translatării porturilor.

Există două versiuni de SSH – v1 şi v2, iar clienţi SSH există pentru mai multe platforme – Unix, Windows, Machintosh, OS/2. Există şi versiuni de componente de server pentru Windows NT/2000.

Autentificarea prin SSH SSH oferă câteva mecanisme pentru autentificarea utilizatorilor în funcţie de

versiunea SSH utilizată. Cea mai slabă formă de autentificare este realizată prin intermediului fişierelor .rhosts, această metodă nefiind recomandată a fi selectată deoarece este foarte puţin sigură.

Altă metodă de autentificare este oferită de criptarea prin RSA. Utilizând această metodă, utilizatorul creează o pereche publică/privată de chei prin utilizarea programului ssh-keygen, cheia publică fiind stocată în directorul părinte al utilizatorului. În momentul în care clientul se autentifică în faţa serverului, trimite numele de utilizator şi cheia publică spre gazda de la distanţă. Serverul returnează cheia de sesiune criptată cu cheia publică a utilizatorului. Această cheie de sesiune va fi decriptată cu cheia privată a utilizatorului.

Metoda principală de autentificare în SSH este prin intermediul fişierelor .rhosts combinată cu autentificarea RSA. Această metodă autentifică clientul şi serverul şi le protejează împotriva atacurilor curente de tip IP Spoofing, DNS Spoofing etc. Există şi posibilitatea instalării de TCPWrapper în locul utilizării fişierelor .rhosts, existând astfel un control mai mare asupra utilizatorilor care încearcă să se conecteze la un serviciu.

În cele din urmă, unui utilizator îi poate fi cerută o combinaţie de nume de utilizator / parolă printr-un canal criptat. De asemenea, în diverse implementări există suport pentru Kerberos, S/KEY şi SecurID.

Stabilirea unei conexiuni SSH este iniţiată de comenzile slogin sau ssh, fapt care duce la verificare autentificării cu cheia publică atât pentru server cât şi pentru client apoi fiind stabilit un canal de comunicaţie sigur.

SSH 1 Versiunea originală a SSH, versiunea 1, este distribuită în mod gratuit pentru

utilizare necomercială, împreună cu codul sursă. SSH1 are şi variante majore (1.2, 1.3 şi 1.5). Deşi s-au descoperit câteva probleme de securitate, SSH este considerat în continuare sigur, dată fiind atenţia acordată metodei de autentificare şi cifrului utilizat.

De exemplu, SSH1 este vulnerabil la atacurile prin inserarea datelor, deoarece acesta utilizează CRC pentru verificarea integrităţii datelor. Dar utilizarea algoritmului de criptare Triple-DES rezolvă această problemă.

SSH 1 suportă o mai mare varietate de metode de autentificare faţă de versiunea 2, între care se numără AFS (bazat pe Andrew File System dezvoltat la Carnegie-Mellon) şi Kerberos.

SSH 2 SSH 2 este o rescriere completă a SSH1 prin care se adaugă noi facilităţi,

inclusiv suport pentru protocoalele FTP şi TLS. Din cauza diferenţelor de implementare a protocoalelor, cele două versiuni nu sunt compatibile în întregime. SSH2 oferă îmbunătăţiri în ceea ce priveşte securitatea şi portabilitatea. SSH2 necesită mai puţin cod care să ruleze cu privilegii de root, fiind mai puţin expus exploatărilor de tip buffer overflow; astfel este mai puţin probabil ca un atacator să rămână pe server cu drepturi de root.

SSH2 nu oferă aceleaşi implementări de reţea ca şi SSH 1, deoarece criptează părţi diferite ale pachetelor. SSH2 nu suportă metoda de autentificare prin fişierele .rhosts. De asemenea, în SSH2 algoritmul RSA este înlocuit de Digital Signature

Algorithm (DSA) şi de Diffie-Hellman, dar, deoarece patentele RSA au expirat, este de aşteptat suportul în continuare pentru algoritmul RSA în versiunile următoare. SSH2 suportă Triple-DES, Blowfish, CAST-128 şi Arcfour.

Stabilirea conexiunii Stabilirea unei conexiuni SSH decurge în urmatoarele etape:

1. Clientul şi serverul se înteleg asupra unei chei de sesiune, folosind în acest scop

protocolul Diffie-Helman. În continuare, întreaga comunicaţie este criptată cu cheia

de sesiune.

2. Clientul autentifică serverul. În acest scop, serverul trimite rezultatul semnării cheii

de sesiune cu cheia sa secretă. Clientul verifica semnatura folosind în acest scop

cheia publică a serverului.

Pentru uşurarea utilizării sistemului, serverul îşi trimite şi cheia publică. Dacă clientul nu are cheia publică a serverului, o poate folosi pe cea trimisă de server - evident opţiunea este nesigură, deoarece serverul înca nu a fost autentificat şi deci s-ar putea să fie un intrus. Utilizatorul este avertizat asupra acestui risc, şi cheia publică a serverului este înregistrată în baza de date a clientului, la urmatoarea conectare la acelaşi server cheia publică urmînd sa fie luată din baza de date.

3. Serverul autentifică clientul. În funcţie de configuraţia serverului, poate accepta

autentificare cu criptografie asimetrică, folosind acelaşi protocol (dar bineînţeles

fără posibilitatea trimiterii de către client a cheii sale publice), sau poate cere

clientului o parola.

Serviciile SSH

SSH nu permite numai sesiuni de lucru prin reţea, ci şi alte aplicaţii. Astfel, o dată deschis un canal securizat, pachetele vehiculate pot fi destinate mai multor aplicaţii, lista celor mai importante fiind:

sesiune de lucru (în mod text);

transfer de fişiere (cunoscut şi ca sftp sau scp; există totuşi o mică diferenţă între

cele două);

forwardarea unor porturi TCP;

forwardarea unui server X (clientul SSH acţioneaza ca server X pe maşina locală,

dar cererile de la clienţii X le forwardează serverului X de pe maşina server SSH);

forwardarea unui agent de autentificare

1.15 Protocoale de management (SNMP)

Gestionarea reţelelor de calculatoare se realizează pe baza protocoalelor de

management de reţea.

Suita TCP/IP include protocolul de management SNMP (Sîn.ple Network

Management Protocol) definit în RFC 1155 - 1157, care implementează un mecanism de

gestionare a resurselor reţelei, folosind baze de date MIB Management Information

Base), cu informaţii referitoare la toate componentele reţelei (RFC 1514 - Host Resources

MIB; RFC 1398 - Bhernet-like Interface TypesMIB; RFC 1493 - Bridge MIB si altele). RFC

1213 defineşte MIB-II care include obiectele gestionate pentru reţelele bazate pe suita

TCP/IP.

SNMP poate folosi oricare din protocoalele de transport din suita TCP/IP dar în cele

mai multe cazuri utilizează UDP. pe porturile de aplicaţii 161 si 162.

Un sistem de management a reţelelor de calculatoare include trei categorii de

componente (Fig. 1):

1. componente gestionate (managed device);

2. staţii de gestionare sau de management (network management station);

3. protocolul de management (management protocol) utilizat pentru comunicaţia

dintre celelalte componente ale sistemului de management.

Fig. 1 Structura de bază a sistemului de management al reţelei

RFC 1155 descrie un mecanism de identificare si descriere a obiectelor din MIB,

denumit SMI (Structure cf Management Information), care defineşte schema de

organizare a colecţiei de obiecte gestionate din MIB, pe baza unei diagrame 'arbore', cu

mai multe nivele (Fig.II. 16).

Fiecare nod din această diagramă este numerotat si, eventual, i se asociază si un

scurt text descriptiv.

Observăm că în MIB I sunt incluse ca obiecte protocoalele din suita TCP/IP (în figură

au fost reprezentate doar câteva dintre acestea).

Referitor la fiecare obiect, în MIB sunt incluse informaţii de natură administrativă si

operaţională.

Fiecare obiect se specifică numele, sintaxa, modul de acces, starea si o descriere a

acestuia.

Numele reprezintă un identificator global, unic al obiectului, care rezultă urmărind

calea care leagă nodul-rădăcină si obiectul gestionat din MIB. Acesta poate fi exprimat în

trei formate diferite, echivalente:

1. numeric cu puncte;

2. text cu separare prin puncte, încadrat de paranteze pătrate;

3. combinat (text si numere de noduri).

Prin starea unui obiect se exprimă condiţiile de implementare ale acestuia:

1. mandatar: componenta gestionată de NMS implementează în mod obligatoriu

acel obiect;

2. opţional: componenta gestionată de NMS implementează opţional acel obiect;

3. depăşit: componenta gestionată de NMS nu mai implementează acel obiect;

4. depreciat: componenta gestionată de NMS poate implementa acel obiect, dar

există un nou obiect în MIB superior acestuia.

Descrierea obiectului se poate face printr-un scurt text descriptiv asociat acestuia.

Protocolul SNMP este utilizat de staţia de management (NMS) pentru a transmite

mesaje componentei gestionate, mai precis agentului de management din cadrul

acesteia.

în general, SNMP acţionează în mod recursiv, prin interogarea periodică (poîiing) a

agenţilorde management ai componentelor gestionate de NMS.

Numai în situaţii critice, un agent poate iniţia schimbul de informaţii cu NMS, pentru a

o înştiinţa de modificările apărute, transmiţând mesaje-cap cană (trap) care întrerup

procesul de polling. Un agent nu poate transmite oricât de multe mesaje-capcană spre

NMS, pentru a evita pierderea controlului asupra întregii reţele.

Un mesaj SNMP (figura 2) include un câmp de versiune a protocolului, un câmp

referitor la grupul de utilizatori cărora li se adresează mesajul si un câmp de date.

Fig. 2 Formatul mesajului SNMP

Prin stabilirea adresabilităţii protocolului, se realizează o procedură simplă de

autentificare a mesajelor.

Unitatea de date sau mesajul SNMP (PDU - Protocol Data Unit) poate ti denumită în

cinci

moduri distincte, în funcţie de natura informaţiei transmise:

1. cerere simplă (get-request) - NMS cere unui agent de management informaţii

despre un obiect;

2. cerere recursivă(get-next-request) - NMS cere unui agent de management

informaţii despre obiectul următordin MIB;

3. cerere de impunere (set-rec/nest) - NMS impune o anumită valoare pentru un

obiect din MIB-ul agentului;

4. răspuns (get-response) - un agent trimite informaţii spre NMS, despre un obiect,

ca răspuns la cererea acesteia;

5. "capcană" (trap) - un agent transmite spre MIB informaţii referitoare la un

eveniment extraordinar care a afectat componenta gestionată prin intermediul

său(reiniţializarea agentului de management, schimbarea stării unei interfeţe,

nerespectarea unor condiţii de autentilicăre etc).

Există şapte tipuri de mesaje-capcană SNMP.

Primele patru tipuri de mesaje SNMP se transmit prin UDP, pe portul 161. Numai

mesajele-capcană sc transmit pe portul de aplicaţic 162.

SNMP este considerat a fi un protocol simplu deoarece nu arc decât cinci operaţii,

corespunzătoare celor cinci tipuri dc mesaje SNMP (get, get-next, set, get-response si

trop).

în funcţie dc modul dc acces, sc poate folosi un număr mai mic dc mesaje SNMP.

Obiectele din MIB pot fi grupate în subseturi (SNMP MIB View), în funcţic de

accesibilitatea acestora: parţială (read-only) sau totală (read-write).

Pentru agenţii de management, se definesc profile prin carc se stabilesc drepturile de

acces la diferitele subseturi de obiecte din MIB, total sau parţial accesibile:

1. cu drept dc citire (read-only);

2. cu drept dc scriere (write-only);

3. cu drepturi dc citirc si dc seri ere (read-write);

4. fără drepturi dc acces la MIB (not-accessible).