Post by Mat46bah, vai a prendere un qualsiasi testo di networking e vedrai che il
protocollo ICMP è un protocollo di livello 3.
Il che non è vero, anche se ti do ragione sul fatto che molti dei testi
vecchi riportano ICMP come layer 3.
In realtà strettamente parlando, non sarebbe vero: un ICMP è
semplicemente un IP con un payload particolare, e può essere pertanto
considerato appartenente al layer 4 (visto che ip è layer 3 e ICMP ci
si appoggia)...
Il fatto è che TCP/IP non è stato pensato "a livelli" in maniera così
stretta come si tende a considerarlo oggi: ci sono parecchi punti in
cui i livelli si sovrappongono, e ICMP, insieme a IGMP, è uno di
questi.
Ciò non toglie che, rigorosamente parlando, dire che I[CG]MP appartiene
al layer 3 non è corretto, e lo si dimostra facilmente:
crea un access list in cui neghi tutti i pacchetti IP e basta. I due
protocolli in questione passano ancora?!?!?
Post by Mat46quando tu fai un ping invii semplicemente un pacchetto ICMP di echo
request a cui l'host di destinazione se raggiungibile risponderà con
un echo reply.
Il che, strettamente parlando, non è sufficientemente granulare per
discernere quello di cui si discute: i livelli...
In realtà, quello che viene inviato, è un pacchetto IP, contenente un
ICMP message come payload. Questo , a sua volta è composto da una serie
di campi quali type, code e il checksum, per un totale di 32 bit, più
una parte di lunghezza e contenuto variabile.
Il che, se vogliamo fare uno schemino, è
+----------------------+
| IP Header |
+----------------------+
| ICMP Message |
| |
....
Il che non fa molta differenza rispetto a
+----------------------+
| IP Header |
+----------------------+
| TCP Header |
+----------------------+
| |
| TCP Payload |
....
Nel senso: entrambi viaggiano *dentro* ip, per cui sono da considerarsi
appartenenti al layer superiore.
Il fatto che ICMP venga spesso considerato non appartenente al layer 4 è
dovuto principalmente all'assenza, nella definizione del protocollo, di
SAP che permettano di multiplexare diverse comunicazioni all'interno di
uno stesso flusso IP-to-IP (ovvero quello che si chiama "porta" in TCP
e UDP, per intenderci...).
In effetti tutte le implementazioni in circolazione lo fanno ugualmente,
basandosi sul contenuto della famosa "parte variabile" di cui sopra.
Esemplifichiamo:
Macchina A: deve contattare B sulla porta 9100 TCP e 47 UDP
Macchina B: ha la porta 9100 TCP aperta, mentre ha un packet filter che
riponde a tutto il resto con ICMP Port Unreachable
Ipotizziamo che A inizi a contattare B "contemporaneamente" su entrambe
le suddette porte:
A:PortaEffimeraTCP -SYN-> B:9100
A:PotraEffimeraUDP -----> B:47
Ipotizziamo che, per pura casualità, la risposta della 47 arrivi per
prima: abbiamo un port-unreachable, proveniente da B e diretto ad A.
Ma se non c'è modo di multiplexare gli ICMP come può A capire che la
comunicazione "abortita" è quella UDP e non quella TCP? In teoria, non
potrebbe, ma in realtà non è così (ovviamente, altrimenti non
funzionerebbe piò una mazza...)
Il motivo è il fatto che l'ICMP di ritorno contiene (nella famosa "parte
variabile di cui sopra" una copia degli header di livello 3 e 4 del
pacchetto che ha "scatenato" la risposta.
A, pertanto, analizzando il contenuto dell'ICMP ha modo di sapere quale
delle due comunicazioni è effettivamente stata rifiutata.
Per quanto non inclusa nelle specifiche del protocollo, una modalità di
multiplexing di fatto c'è.
Volendo riportare lo schemino con cui lo Stevens esplica il
funzionamento di ICMP, abbiamo, in questo caso:
<---------------IP datagram---------------------------->
<-----------ICMP Message-------------------->
<---Data portion of ICMP message--->
+----------+----------+--------+--------------------+-------------+
| Ethernet | IP | ICMP | IP Header of the | UDP |
| Header | Header | Header | Original Datagram | Header |
+----------+----------+--------+--------------------+-------------+
.. e penso che lo Stevens possa considerarsi autorevole da questo punto
di vista. Facendo presente che lo stesso Stevens apre la spiegazione su
ICMP con le parole: "ICMP is often considered part of the IP layer",
segno evidente che in larga parte il posizionamento di ICMP è da sempre
piuttosto "confuso" ;-)
Post by Mat46Se poi per il fatto che il ci sia un comado ping da linea di comando e
che quindi interpretandolo come programma tu lo classifichi come
livello 7, potrebbe essere anche una interpretazione anche se penso
sia sbagliata. Per essere di livello 7 dovrebbe avere dentro di se
anche tutti quei concetti dei livelli intermedi, come le porte di una
connessione tcp, piuttosto che le sessioni del livello sucessivo....
Anche questo è un fraintendimento comune, dovuto allo stesso motivo:
TCP/IP *non* è nato sui 7 livelli poi entrati nella letteratura (e
"nati" quasi 15 anni dopo", ma ci è stato calato dentro.
TCP/IP considera solamente:
- Application
- Transport
- Network
- Link
Dove "Application" è genericamente tutto quello che si appoggia sul
Transport, sia un browser, sia ping, sia finger o quello che pare.
Genericamente, nel "gergo" TCP/IP, Application prende dentro tutti i 3
layer superiori del modello OSI.
Per questo motivo, parlare di livello 5,6 o 7, nell'ambito "storico" del
TCP/IP, è completamente privo di senso (e di riscontro).
In tali termini, comunque, ping appartiene al layer 7 della pila OSI,
poichè si interfaccia in maniera *diretta* con l'utente, e appartiene
anche al layer 5, poichè si appoggia direttamente al layer 4 (posto di
voler considerare ICMP appatrenente al layer 4).
Anche per questo motivo, non piazzerei, formalmente, ICMP al layer 3,
poichè se così fosse le funzionalità di multiplexing superiori (che
comprendono la capacità di discernere l'appartenenza di comunicazioni
ICMP parallele) poichè questo compito, AFAIK, se lo piglia direttamente
l'implementazione del protocollo...
Ciao
PS: non presterei troppa attenzione a questi formalismi, comunque:
l'importante è avere le idee chiare su come funziona il tutto, il resto
è poco utile e spesso sviante ;-)
--
Emanuele Balla aka Skull - Public Key #661E5CBF on www.keyserver.com
+----------------------------------------------------------------------+
"And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies." (By Linus Torvalds)