Discussioni template:Suite di protocolli Internet

ancora livello di ARP - riunificare la discussione[modifica wikitesto]

ciao, se non vi spiace provo a ricomporre qui sotto la discussione sul livello di ARP, copiando da altre sezioni di questa discussione. colpa anche mia che non avevo notato la motivazione di leitfaden. vi prego di continuare in questa sezione--hce 21:42, 21 giu 2007 (CEST)[rispondi]


L'errore, piuttosto, riguarda proprio ARP: l'ho spostato dal livello 3 al livello 2 perché i messaggi ARP:

  1. non vengono incapsulati in datagrammi IP, ma direttamente nell'area dati di frame Ethernet;
  2. vengono inviati solo ad altri computer direttamente collegati al canale fisico (non oltrepassano il confine rappresentato dai router);
  3. sono espressamente attribuiti al livello 2 dall'RFC 1122.

Mi pare anche utile correggere il nome del livello 3. Il modello OSI riguarda le reti, il modello TCP/IP riguarda invece le internet (le reti di reti). Nel modello OSI il livello 3 è un livello di rete, nel modello TPC/IP il livello 3 è un livello di internet. Per evitare ambiguità ("internet" fa pensare alla Internet, e magari al web, mentre si possono ben avere internet non connesse a Internet) ho corretto "Livello di rete" in "Livello di internetworking".

--Leitfaden 09:57, 2 dic 2006 (CET)[rispondi]

Scusatemi se sbaglio ma io ho sempre saputo che ARP fosse un protocollo di livello rete (qui detto internetworking), mentre qui è classificato come protocollo di livello collegamento.
Per quanto in effetti stia a cavallo tra i due, formalmente utilizzando i servizi di livello collegamento, si trova al di sopra di essi. Acchiappasogni 16:45, 20 giu 2007 (CEST)[rispondi]
concordo con lui:
  • ARP utilizza i servizi di un protocollo di livello collegamento, e contribuisce a fornire i servizi del livello di internetworking
  • ARP si appoggia su ethernet con un proprio ethertype, come fa IP, e quindi nell'incapsulameno si trova allo stesso livello di IP, non sotto.
quindi penso anch'io che ARP andrebbe (ri)spostato al livello internetworking
visto che ARP è già stato oggetto di spostamenti all'interno del template, aspetto qualche giorno a correggerlo, nel caso qualcuno avesse buone ragioni per tenerlo a livello collegamento.
--hce 09:04, 21 giu 2007 (CEST)[rispondi]
Da quanto ho capito, la tua decisione si basa tutta sulla premessa che ARP sia di livello (OSI) 2. Ma se (come ho già fatto notare nella Discussione:Address Resolution Protocol ARP utilizza i servizi di livello (OSI) 2, allora va inserito allo stesso livello di IP. Se infatti, come tu sostieni, i messaggi ARP venissero incapsulati in datagrammi IP allora ARP sarebbe di livello superiore a IP e quindi di livello applicativo.
Inoltre i mssaggi ARP non vengono propagati al di fuori della rete locale esclusivamente perché fanno uso di broadcast, come noto bloccato dai router.
In definitiva, io (ri)sposterei ARP nel livello (OSI) 3 e "accorperei" i due livelli invefiori in un unico livello segnalando esclusivamente i protocolli di livello (OSI) 2 che sono quelli effettivamente usati dai protocolli IP, ARP, ICMP ecc.
--Acchiappasogni 09:29, 21 giu 2007 (CEST)[rispondi]
rispondo agli argomenti di laitfaden
non vengono incapsulati in datagrammi IP, ma direttamente nell'area dati di frame Ethernet;
anche i pacchetti IP vengono incapsulati in ethernet, quindi questa osservazione dimostra che ARP stà allo stesso livello di IP, non sotto
vengono inviati solo ad altri computer direttamente collegati al canale fisico (non oltrepassano il confine rappresentato dai router);
vero, ma anche la maggior parte dei protocolli di routing scambia pacchetti tra host che stanno sullo stesso segmento L2, eppure stanno giustamente al livello 3 del modello TCP/IP. e lo stesso si può dire di ICMP e IGMP, che sono pure incapsulati in ethernet.
come i protocolli di routing, ICMP e IGMP, ARP è un protocollo di servizio che contribuisce a realizzare le funzioni dello strato di rete nel modello TCP/IP: i protocolli di routing determinano la strada dei pacchetti nella rete, ARP permette la consegna di pacchetti IP su reti ethernet (o analoghe), ICMP trasporta messaggi di errore e altre cose belle, IGMP gestisce l'appartenenza degli host ai gruppi multicast su reti broadcast.
--hce 21:42, 21 giu 2007 (CEST)[rispondi]

Correttezza formale[modifica wikitesto]

Mi chiedo.. Se questo è un template per mettere in risalto i rapporti tra il Modello ISO/OSI e lo stack reale, allora mancano il livello di sessione e presentazione. Se invece è incentrato su TCP/IP, occorre mettere insieme livello fisico e e collegamento dati (livello Host-to-network). Altrimenti così è un'ibrido non corretto --Piffy 07:47, 15 set 2006 (CEST)

A me pare che si tratti solo del modello TCP/IP. Non mi pare necessario né opportuno mettere insieme i primi due livelli (Andrew Tanenbaum lo fa, ma Douglas Comer - a mio avviso più correttamente - no). Tra i due livelli c'è infatti una differenza non trascurabile: TCP/IP prescinde dal livello fisico (può essere "qualsiasi"), ma usa ARP al livello 2.

L'errore, piuttosto, riguarda proprio ARP: l'ho spostato dal livello 3 al livello 2 perché i messaggi ARP:

  1. non vengono incapsulati in datagrammi IP, ma direttamente nell'area dati di frame Ethernet;
  2. vengono inviati solo ad altri computer direttamente collegati al canale fisico (non oltrepassano il confine rappresentato dai router);
  3. sono espressamente attribuiti al livello 2 dall'RFC 1122.

Mi pare anche utile correggere il nome del livello 3. Il modello OSI riguarda le reti, il modello TCP/IP riguarda invece le internet (le reti di reti). Nel modello OSI il livello 3 è un livello di rete, nel modello TPC/IP il livello 3 è un livello di internet. Per evitare ambiguità ("internet" fa pensare alla Internet, e magari al web, mentre si possono ben avere internet non connesse a Internet) ho corretto "Livello di rete" in "Livello di internetworking".

--Leitfaden 09:57, 2 dic 2006 (CET)[rispondi]

Da quanto ho capito, la tua decisione si basa tutta sulla premessa che ARP sia di livello (OSI) 2. Ma se (come ho già fatto notare nella Discussione:Address Resolution Protocol ARP utilizza i servizi di livello (OSI) 2, allora va inserito allo stesso livello di IP. Se infatti, come tu sostieni, i messaggi ARP venissero incapsulati in datagrammi IP allora ARP sarebbe di livello superiore a IP e quindi di livello applicativo.
Inoltre i mssaggi ARP non vengono propagati al di fuori della rete locale esclusivamente perché fanno uso di broadcast, come noto bloccato dai router.
In definitiva, io (ri)sposterei ARP nel livello (OSI) 3 e "accorperei" i due livelli invefiori in un unico livello segnalando esclusivamente i protocolli di livello (OSI) 2 che sono quelli effettivamente usati dai protocolli IP, ARP, ICMP ecc.
--Acchiappasogni 09:29, 21 giu 2007 (CEST)[rispondi]
Oltretutto lo stack di livelli internet è di soli 4 livelli, in cui i livelli OSI 1 e 2 sono accorpati tra loro, così come i livelli OSI 5, 6 e 7.
In effetti però, dopo alcune ricerche in rete, ho notato che su questo punto le discordanze sono diffuse. A mio parere occorrerebbe fare una scelta citando la fonte a cui ci si attiene (es. Tanenbaum) e seguire quella.Acchiappasogni 22:24, 21 giu 2007 (CEST)[rispondi]


Ho fatto un template sullo stack ISO/OSI Template:ISO/OSI ridotto all'essenziale per usarlo per cambiare velocemente pagina tra quelle dedicate ai sette livelli. Inserendolo dopo questo, finisce di fianco e non sotto come speravo. Ho inserito il nuovo template nelle pagine relative e attendo che qualcuno riesca a inserire anche questo in modo non invasivo (ad esempio sotto). Per non rendere questo un danno ho inserito nelle "voci correlate" di ogni livello i protocolli indicati nel template IPstack per quel livello. Chi ha un'idea la posti qui o nella discussione relativa al nuovo template.

--Mar.pollo 17:33, 3 giu 2007 (CEST)[rispondi]

Universal Plug and Play[modifica wikitesto]

L'UPnP può essere incluso in questi protocolli? in quale categoria?--Buzz Lightyear 16:20, 4 mag 2007 (CEST)[rispondi]

ancora livello di ARP[modifica wikitesto]

ciao, Discussione:Address Resolution Protocol, Acchiappasogni nota:

Scusatemi se sbaglio ma io ho sempre saputo che ARP fosse un protocollo di livello rete (qui detto internetworking), mentre qui è classificato come protocollo di livello collegamento.
Per quanto in effetti stia a cavallo tra i due, formalmente utilizzando i servizi di livello collegamento, si trova al di sopra di essi. Acchiappasogni 16:45, 20 giu 2007 (CEST)[rispondi]

concordo con lui:

  • ARP utilizza i servizi di un protocollo di livello collegamento, e contribuisce a fornire i servizi del livello di internetworking
  • ARP si appoggia su ethernet con un proprio ethertype, come fa IP, e quindi nell'incapsulameno si trova allo stesso livello di IP, non sotto.

quindi penso anch'io che ARP andrebbe (ri)spostato al livello internetworking

visto che ARP è già stato oggetto di spostamenti all'interno del template, aspetto qualche giorno a correggerlo, nel caso qualcuno avesse buone ragioni per tenerlo a livello collegamento. --hce 09:04, 21 giu 2007 (CEST)[rispondi]

Non aspettavo tanta discussione ;-) Diciamo che a me basta l'RFC 1122, ma so che l'argomento è controverso (in sintesi, in ambito commerciale è considerato di livello 3, in ambito accademico di livello 2). Se si vuole riportarlo a livello 3... lo lascerò lì ;-) --Leitfaden 23:10, 23 giu 2007 (CEST)[rispondi]

Va be', forse posso aggiungere qualcosa ;-) Ho visto che Acchiappasogni fa riferimento al modello OSI. Due osservazioni:

  • mi pare più corretto fare riferimento al modello TCP/IP (in fondo stiamo parlando di IPstack...), nel quale, appunto, il "livello rete" viene detto "livello internet" (ho usato "livello internetworking" per evitare confusione tra una "internet" in generale e LA "Internet") ed ha come scopo quello di consegnare i pacchetti al destinatario scegliendo il cammino che devono seguire; IP appartiene ovviamente a questo livello, e in IP i pacchetti hanno un indirizzo IP di destinazione; i pacchetti ARP vengono invece trasmessi in broadcast e lo scopo di ARP è solo quello di evitare di associare fisicamente un indirizzo IP ad un'interfaccia; per dirla con Douglas Comer: "ARP è un protocollo di basso livello che nasconde l'indirizzamento fisico di rete sottostante, permettendo di assegnare un indirizzo IP arbitrario a ogni macchina. ARP può essere considerato parte del sistema fisico di rete e non parte dei protocolli di internet" (Internetworking con TPC/IP. Principi, protocolli e architetture, Vol. 1, Milano, 2006, p. 60);
  • anche nel modello OSI il problema del livello 3 è quello del percorso dei pacchetti, infatti "nelle reti broadcast il problema del cammino da scegliere per far viaggiare i pacchetti (problema del routing) è semplice, così il livello di rete è spesso sottile o assente" (A. Tanenbaum, Reti di computer, Torino, 1998, p. 30) e ARP, appunto, trasmette in broadcast.

In sintesi, potremmo dire che ARP opera a livello 2, non si occupa dell'inoltro di pacchetti, si limita ad associare un indirizzo IP ad un'interfaccia. Fornisce così un servizio senza il quale il livello 3 non potrebbe funzionare e, secondo alcuni (anche in questa discussione), questo vuol dire che ARP è "a cavallo" tra i due livelli. Personalmente non sono d'accordo, continuo a preferire le considerazioni di Comer e mi attengo all'ufficialità dell'RFC 1122 (che pone ARP al "link layer" e non è stato corretto in questo dagli aggiornamenti contenuti in RFC 1349 e RFC 4379). Se qualcuno preferisce allinearsi a CISCO.. amen ;-) --Leitfaden 08:10, 24 giu 2007 (CEST)[rispondi]

Protocolli di routing[modifica wikitesto]

  • I protocolli di routing BGP e RIP sono di livello application come tutti i servizi che si basano su TCP o UDP, anche se per molti aspetti possono essere considerati di livello Internet.
  • OSPF è invece stato classificato di livello Link dalla RFC 2740.
--Abisys (msg) 22:33, 16 ott 2008 (CEST)[rispondi]
Ciao. Secondo me c'e' un'imprecisione. OSPF e' un proto di livello link ma solo per IPv6. In IPv4 e' un protocollo di livello 3 (di supporto a IP), quindi nel template andrebbero discriminati i due casi. [1] --Guignol (msg) 09:42, 23 mar 2009 (CET)[rispondi]
La suddivisione dello stack IP in livelli ISO/OSI non è così precisa. L'interpretazione data nella RFC 2470 mi sembra valida anche per IPv4, proprio perché è un protocollo di supporto a IP è un po' sul confine. Non mi sembra che le considerazioni fatte nell'RFC non siano applicabili anche ad IPv4, in ogni modo non è così fondamentale su OSPF come su MPLS definire con precisione il livello perché alcune funzionalità sono di livello 2 alte di livello 3 altre ancora di livello 7. --Abisys (msg) 18:53, 24 mar 2009 (CET)[rispondi]

MPLS ha caratteristiche di livello 2 (Link) e livello 3 (Internet), e quindi solitamente viene definito di livello 2,5 ma solitante si inserisce come tutti i protocolli di tunneling nel livello 2. --Abisys (msg) 22:33, 16 ott 2008 (CEST)[rispondi]

Livello fisico[modifica wikitesto]

Non mi sembra corretto indicarlo in questo template, quindi l'ho commentato per consentire un ripristino se la mia interpretazione non è condivisa. Cercherò anche di rivedere la voce Suite di protocolli Internet allineandola a quella en:. --Abisys (msg) 22:33, 16 ott 2008 (CEST)[rispondi]

Livello 2,5 e 3,5[modifica wikitesto]

Non li inserirei perché sono oscuri ai più e non utili su un template di navigazione. È corretto inserirli nelle voci ma lo scopo ti questo template è quello di garantire un veloce accesso ad una determinata voce. Teniamo poi presente che lo stack IP non è stato pensato con il modello ISO/OSI in mente quindi non esasperiamo troppo questi aspetti, eventuali approfondimenti si possono anche inserire in Suite di protocolli Internet. --Abisys (msg) 23:43, 5 apr 2009 (CEST)[rispondi]

Perchè mancano i protocolli SDH e PDH a livello fisico...?--151.28.50.180 (msg) 19:51, 15 set 2012 (CEST)[rispondi]

Visibilità[modifica wikitesto]

E se il template fosse più visibile senza dover cliccare sul pulsante un pò come era prima...? --151.28.50.180 (msg) 19:57, 15 set 2012 (CEST)[rispondi]

Rimuovo livello fisico[modifica wikitesto]

Il livello fisico non appare nelle RFC 1122 e RFC 1123 quindi lo elimino per creare confusione. --Abisys (msg) 21:11, 18 apr 2016 (CEST)[rispondi]