3. PROTOCOLLI DEL LIVELLO INTERNET (INTERNET LAYER PROTOCOLS)
3.1 INTRODUZIONE (INTRODUCTION)
Il protocollo Internet (Internet Protocol, IP) è il protocollo centrale della suite di protocolli Internet. Tutti i protocolli di trasporto Internet utilizzano IP per trasportare i dati dall'host di origine all'host di destinazione. IP è un servizio di internetwork senza connessione o datagramma, e include disposizioni per l'indirizzamento, la specifica del tipo di servizio, la frammentazione e il riassemblaggio, e le informazioni di sicurezza.
Il livello Internet include anche il protocollo dei messaggi di controllo Internet (Internet Control Message Protocol, ICMP), che fornisce funzioni di controllo e segnalazione, e il protocollo di gestione dei gruppi Internet (Internet Group Management Protocol, IGMP), che viene utilizzato per il multicasting.
Tutti gli host Internet devono implementare IP e ICMP (MUST). Gli host che supportano il multicasting IP devono anche implementare IGMP (MUST).
3.2 PERCORSO DEL PROTOCOLLO (PROTOCOL WALK-THROUGH)
3.2.1 Protocollo Internet -- IP (Internet Protocol)
Il protocollo Internet è definito in RFC 791 [IP:1]. Il formato dell'intestazione IP e la semantica di ciascun campo sono ben definiti e documentati. Tuttavia, ci sono diverse aree che richiedono chiarimenti o specifiche aggiuntive per le implementazioni degli host.
3.2.1.1 Numero di versione (Version Number)
Un host deve rifiutare silenziosamente qualsiasi datagramma IP il cui numero di versione non sia 4 (MUST) (il numero di versione corrente del protocollo Internet).
3.2.1.2 Checksum (Checksum)
Un host deve verificare il checksum dell'intestazione IP su ogni datagramma ricevuto e rifiutare silenziosamente ogni datagramma con un checksum errato (MUST).
3.2.1.3 Indirizzamento (Addressing)
Ogni datagramma IP include un indirizzo IP di origine e un indirizzo IP di destinazione. Un indirizzo IP ha due componenti: un numero di rete e un numero di host.
Il numero di rete identifica una rete fisica a cui l'host è collegato. Il numero di host identifica un particolare host su quella rete.
Un host deve supportare i seguenti indirizzi speciali (MUST):
- Broadcast limitato (Limited Broadcast): 255.255.255.255
- Broadcast diretto (Directed Broadcast): tutti 1 nella parte host
- Questo host su questa rete (This Host on This Network): 0.0.0.0
- Host su questa rete (Host on This Network):
{network, host} - Loopback: 127.x.x.x
3.2.1.4 Frammentazione e riassemblaggio (Fragmentation and Reassembly)
Ogni modulo Internet deve essere in grado di inoltrare un datagramma di 68 byte senza frammentazione (MUST). Un host deve essere in grado di riassemblare datagrammi frammentati di almeno 576 byte (MUST).
3.2.1.5 Identificazione (Identification)
Quando si invia una copia identica di un datagramma, il campo di identificazione IP deve essere lo stesso di quello del datagramma originale (MUST).
Quando un host frammenta un datagramma IP, deve copiare il campo di identificazione dall'intestazione IP originale in tutte le intestazioni dei frammenti (MUST).
3.2.1.6 Tipo di servizio (Type-of-Service)
Il byte del tipo di servizio (Type-of-Service, TOS) nell'intestazione IP viene utilizzato per indicare la qualità del servizio desiderata per un particolare datagramma. Il valore TOS specifica l'importanza relativa di throughput, ritardo, affidabilità e costo.
Un'applicazione deve essere in grado di specificare un valore TOS per i pacchetti che invia (MUST). Il livello IP deve passare il valore TOS invariato al livello di collegamento (MUST).
3.2.1.7 Tempo di vita (Time-to-Live)
Il campo tempo di vita (Time-to-Live, TTL) è definito dal mittente e decrementato da ogni router che inoltra il datagramma. Quando il TTL raggiunge zero, il datagramma viene scartato.
Un host non deve inviare un datagramma con un valore di tempo di vita (TTL) di zero (MUST NOT). Un host non deve rifiutare un datagramma semplicemente perché è stato ricevuto con TTL inferiore a 2 (MUST NOT).
3.2.1.8 Opzioni (Options)
Sono definite diverse opzioni IP:
- Registrazione del percorso (Record Route): Registra il percorso preso da un datagramma
- Timestamp: Registra i timestamp ai router lungo il percorso
- Percorso sorgente (Source Route): Specifica il percorso che un datagramma deve seguire
- Sicurezza (Security): Fornisce restrizioni di sicurezza e gestione
Un host deve essere in grado di agire su tutte le opzioni IP che riceve (MUST). Alcune opzioni richiedono l'elaborazione da parte di ogni host che le riceve; altre richiedono l'elaborazione solo da parte dell'host di destinazione.
3.2.2 Protocollo dei messaggi di controllo Internet -- ICMP (Internet Control Message Protocol)
ICMP [IP:8] viene utilizzato per segnalare errori e altre informazioni sull'elaborazione dei pacchetti IP alla sorgente. I messaggi ICMP vengono inviati nei datagrammi IP.
Ogni host deve implementare ICMP (MUST). Un messaggio di errore ICMP non deve essere inviato (MUST NOT) come risultato della ricezione di:
- Un messaggio di errore ICMP
- Un datagramma destinato a un indirizzo di broadcast IP o multicast IP
- Un datagramma inviato come broadcast del livello di collegamento
- Un frammento non iniziale
- Un datagramma il cui indirizzo di origine non è valido
3.2.2.1 Destinazione irraggiungibile (Destination Unreachable)
Il messaggio Destination Unreachable viene inviato quando un datagramma non può essere consegnato alla sua destinazione per motivi diversi dalla congestione.
Un host dovrebbe generare messaggi Destination Unreachable con i seguenti codici (SHOULD):
- 2 (Protocol Unreachable): Inviato quando il protocollo di trasporto designato in un datagramma non è supportato
- 3 (Port Unreachable): Inviato quando il protocollo di trasporto di destinazione non è in grado di demultiplexare il datagramma
3.2.2.2 Reindirizzamento (Redirect)
Un messaggio Redirect viene inviato da un router a un host per informarlo di un percorso migliore verso una particolare destinazione.
Un host deve essere in grado di agire sui messaggi Redirect (MUST). Un host deve aggiornare la sua tabella di routing quando riceve un Redirect (MUST).
3.2.2.3 Source Quench
Source Quench è un meccanismo di controllo della congestione. Quando un host o un router deve scartare un datagramma a causa di un overflow del buffer, può inviare un messaggio Source Quench alla sorgente (MAY).
Un host che riceve un messaggio Source Quench deve ridurre la velocità con cui invia datagrammi alla destinazione specificata (MUST).
3.2.2.4 Tempo superato (Time Exceeded)
Un messaggio Time Exceeded viene inviato da un router quando un datagramma viene scartato perché il suo campo Time-to-Live ha raggiunto zero.
Un messaggio Time Exceeded viene anche inviato da un host di destinazione quando il riassemblaggio dei frammenti non può essere completato entro un timeout.
3.2.2.5 Problema di parametro (Parameter Problem)
Un messaggio Parameter Problem indica che è stato rilevato un problema durante l'elaborazione di un parametro dell'intestazione IP e il datagramma è stato scartato.
3.2.2.6 Richiesta/Risposta Echo (Echo Request/Reply)
Ogni host deve implementare una funzione server ICMP Echo che riceve richieste Echo e invia risposte Echo corrispondenti (MUST).
Una richiesta ICMP Echo destinata a un indirizzo di broadcast IP o multicast IP può essere rifiutata silenziosamente (MAY).
3.2.2.7 Richiesta/Risposta informazioni (Information Request/Reply)
I messaggi Information Request e Reply sono obsoleti e non dovrebbero essere implementati (SHOULD NOT).
3.2.2.8 Timestamp e risposta timestamp (Timestamp and Timestamp Reply)
I messaggi Timestamp e Timestamp Reply vengono utilizzati per misurare i tempi di andata e ritorno e sincronizzare gli orologi.
Un host può implementare ICMP Timestamp (MAY). Se lo fa, deve seguire il formato specificato per i timestamp (MUST).
3.2.2.9 Richiesta/Risposta maschera di indirizzo (Address Mask Request/Reply)
I messaggi Address Mask Request e Reply consentono a un host di ottenere la maschera di sottorete per una rete locale.
Un host deve supportare i messaggi ICMP della maschera di sottorete se supporta il subnetting (MUST). Se lo fa, deve rispondere alle richieste Address Mask (MUST) e dovrebbe avere un'opzione di configurazione per inviare richieste Address Mask durante l'avvio (SHOULD).
3.2.3 Protocollo di gestione dei gruppi Internet -- IGMP (Internet Group Management Protocol)
IGMP [IP:4] viene utilizzato dagli host e dai router adiacenti per stabilire le appartenenze ai gruppi multicast.
Un host deve implementare IGMP se supporta il multicasting IP (MUST). La conformità di livello 2 (implementazione IGMP completa) è richiesta (REQUIRED).
3.3 PROBLEMI SPECIFICI (SPECIFIC ISSUES)
3.3.1 Routing dei datagrammi in uscita (Routing Outbound Datagrams)
3.3.1.1 Introduzione (Introduction)
Quando un host invia un datagramma IP, deve decidere quale interfaccia fisica utilizzare e quale gateway costituisce il primo hop (a meno che l'host di destinazione non si trovi nella rete connessa). Questo processo decisionale è chiamato "routing".
Un host DEVE (MUST) utilizzare la maschera di indirizzo quando decide tra "locale" (rete connessa) e "remoto" (non connessa).
Un host DEVE (MUST) essere in grado di funzionare normalmente in una rete connessa senza alcun gateway configurato.
DISCUSSION (DISCUSSION):
Il routing è uno dei settori più complessi e ancora in evoluzione dell'architettura Internet. Gli host non dovrebbero implementare l'intero protocollo di routing dei gateway, ma fare affidamento su meccanismi semplici: gateway predefinito, messaggi Redirect e cache di routing.
3.3.1.2 Cache di routing e route statiche (Route Cache and Static Routes)
Un host DEVE (MUST) mantenere una "cache di routing" (route cache) che registri il gateway del prossimo hop per ciascuna rete/host di destinazione. Un host DEVE (MUST) utilizzare il gateway predefinito quando non viene trovata alcuna voce nella cache. Un host DEVE (MUST) supportare più gateway predefiniti.
Un host PUÒ (MAY) fornire una tabella di route statiche (static routes); tali route statiche POSSONO (MAY) essere contrassegnate come sovrascrivibili o meno dai Redirect.
DISCUSSION (DISCUSSION):
Il messaggio Redirect viene inviato da un gateway per informare un host su un gateway migliore per il primo hop verso un determinato indirizzo di destinazione. Quando un host riceve un messaggio Redirect, DEVE (MUST) aggiornare la propria cache di routing. Un host DEVE (MUST) trattare allo stesso modo gli Host Redirect e i Net Redirect.
Un messaggio Redirect non valido (ad esempio, che punta a un gateway non presente in una rete direttamente connessa) DOVREBBE (SHOULD) essere ignorato.
3.3.1.3 Indicizzazione della cache di routing (Route Cache Keying)
La cache di routing DOVREBBE (SHOULD) essere indicizzata sull'indirizzo host di destinazione (anziché sull'indirizzo di rete) e DOVREBBE (SHOULD) includere il valore TOS nella cache.
DISCUSSION (DISCUSSION):
L'indicizzazione per host evita problemi in cui host diversi nella stessa rete seguono percorsi differenti e consente un controllo più fine per host di destinazione.
3.3.1.4 Rilevamento dei gateway morti (Dead Gateway Detection)
Un host DEVE (MUST) essere in grado di rilevare il guasto del gateway del prossimo hop. Un host NON DEVE (MUST NOT) presumere che una rotta rimanga valida per sempre.
DISCUSSION (DISCUSSION):
Diverse tecniche possono rilevare un gateway guasto. Un metodo consiste nel fare ping continuo al gateway, ma ciò genera troppo traffico; si DOVREBBE (SHOULD) pertanto effettuare il ping solo quando vi è effettivamente traffico da inviare e DOVREBBE (SHOULD) farlo solo in assenza di un'indicazione positiva. I livelli superiore e inferiore possono fornire consigli (advice) di successo/errore.
Un'altra tecnica diffusa (ascolto passivo dei protocolli di routing dei gateway) non è raccomandata (vedere sotto).
3.3.1.5 Selezione di un nuovo gateway (New Gateway Selection)
Se il gateway guasto non è il gateway predefinito corrente, il livello IP può passare immediatamente a un altro gateway predefinito. Se il gateway guasto è il gateway predefinito corrente, il livello IP DEVE (MUST) sceglierne un altro (se ne sono noti diversi), sia per la rotta guasta sia per costruirne di nuove.
DISCUSSION (DISCUSSION):
Quando un gateway si guasta, altri gateway nella rete connessa vengono informati tramite un protocollo di routing gateway-to-gateway, ma ciò non avviene immediatamente (il tempo di stabilizzazione è tipicamente di 30–60 secondi). Se l'host passa a un gateway sostitutivo prima che i gateway si accordino, il nuovo gateway di destinazione probabilmente inoltrerà i datagrammi al gateway guasto e invierà un Redirect a quest'ultimo. Ciò causa una rapida oscillazione del contenuto della cache di routing dell'host durante la stabilizzazione. È stato proposto di dotare la logica dei gateway morti di una certa isteresi per evitare tale oscillazione, ma l'esperienza mostra che è innocua.
IMPLEMENTATION (IMPLEMENTATION):
Una tecnica di implementazione per la selezione di un nuovo gateway predefinito consiste semplicemente nello scorrere la lista dei gateway predefiniti in round-robin; un'altra nell'ordinare i gateway per priorità ed effettuare il ping dei gateway a priorità più alta quando non sono il gateway predefinito corrente.
3.3.1.6 Inizializzazione (Initialization)
Le seguenti informazioni DEVONO (MUST) essere configurabili:
(1) Indirizzo/i IP (uno o più). (2) Maschera/e di indirizzo (una o più). (3) Elenco dei gateway predefiniti, con priorità.
DEVE (MUST) essere fornito un metodo per l'inserimento manuale di questi dati di configurazione. Inoltre, possono essere utilizzati vari metodi per il rilevamento dinamico di tali informazioni (vedere il capitolo "Host Initialization" in [INTRO:1]).
DISCUSSION (DISCUSSION):
Alcune implementazioni host individuano i gateway esistenti ascoltando i protocolli di gateway sulla rete broadcast. Un metodo standard per il rilevamento del gateway predefinito è attualmente in fase di elaborazione.
3.3.2 Riassemblaggio (Reassembly)
La funzione di riassemblaggio IP DEVE (MUST) soddisfare i seguenti requisiti:
- Un host DEVE (MUST) essere in grado di riassemblare datagrammi frammentati di almeno 576 byte.
- Il timeout di riassemblaggio DEVE (MUST) essere di almeno 60 secondi, ma non deve superare i 120 secondi.
- Quando un datagramma viene scartato a causa dello scadere del timeout di riassemblaggio, l'host DEVE (MUST) inviare un messaggio ICMP "Time Exceeded" (codice 1) alla sorgente del datagramma.
- L'host DEVE (MUST) fornire al livello di trasporto un meccanismo per apprendere la dimensione massima del messaggio di trasporto ricevibile (MMS_R); tali informazioni sono normalmente derivate dalla dimensione massima effettiva del datagramma (EMTU_R). Il valore EMTU_R DOVREBBE (SHOULD) essere configurabile dall'operatore o DOVREBBE (SHOULD) essere considerato illimitato.
DISCUSSION (DISCUSSION):
Il valore di 576 byte per la dimensione minima garantita del datagramma è storicamente legato ai limiti della tecnologia LAN iniziale; dovrebbe essere sufficiente per la maggior parte delle intestazioni dei protocolli superiori a IP. Notare che il requisito di riassemblare almeno 576 byte è distinto dal requisito di trasmettere datagrammi di tale dimensione.
3.3.3 Frammentazione (Fragmentation)
Un host DEVE (MUST) supportare la frammentazione IP locale. Quando frammenta un datagramma, un host DEVE (MUST) copiare i campi dell'intestazione IP appropriati in ciascuna intestazione di frammento. L'host DEVE (MUST) fornire al livello di trasporto la dimensione massima del messaggio di trasporto inviabile (MMS_S). Se l'host non frammenta i propri datagrammi in uscita, NON DEVE (MUST NOT) inviare datagrammi più grandi dell'MMS_S fornito al livello di trasporto.
DISCUSSION (DISCUSSION):
La frammentazione è importante per l'interoperabilità. Tuttavia comporta un sovraccarico e una minore affidabilità (se un frammento va perso, l'intero datagramma deve essere ritrasmesso). Appena possibile, gli host DOVREBBERO (SHOULD) evitare la frammentazione utilizzando l'MMS_S corretto per la destinazione.
Un host DOVREBBE (SHOULD) inviare datagrammi di al massimo 576 byte alle destinazioni fuori rete (off-net), salvo diversa indicazione fornita dal percorso MTU.
Può essere fornito un flag di configurazione "All-Subnets-MTU".
3.3.4 Multihoming locale (Local Multihoming)
Un host multihomed possiede più indirizzi IP, che possono trovarsi sulle stesse reti o su reti diverse. Un host con più indirizzi IP DEVE (MUST) essere in grado di inviare e ricevere datagrammi utilizzando uno qualsiasi dei propri indirizzi IP.
Un host multihomed DEVE (MUST) essere in grado di rispondere a un datagramma in arrivo con lo stesso indirizzo dell'indirizzo di destinazione specifico (specific-destination) del datagramma originale. L'host DEVE (MUST) consentire a un'applicazione di scegliere l'indirizzo IP locale di origine per i datagrammi che invia.
DISCUSSION (DISCUSSION):
Il multihoming è complesso. Quando un datagramma arriva su un'interfaccia che non corrisponde all'indirizzo di destinazione, l'host DOVREBBE (SHOULD) scartare silenziosamente il datagramma, a meno che non si tratti di un indirizzo broadcast o multicast valido su tale interfaccia. Viceversa, l'host NON DOVREBBE (SHOULD NOT) inviare un datagramma tramite un'interfaccia "errata" per l'indirizzo di origine scelto, salvo diversa configurazione.
3.3.5 Inoltro del percorso sorgente (Source Route Forwarding)
Con le seguenti restrizioni, un host PUÒ (MAY) agire come hop intermedio in un percorso sorgente inoltrando un datagramma a percorso sorgente al successivo hop specificato.
Nell'eseguire tale funzione di tipo gateway, l'host DEVE (MUST) rispettare tutte le regole applicabili all'inoltro di datagrammi a percorso sorgente da parte di un gateway [INTRO:2]. Ciò include quanto segue (queste clausole particolari sostituiscono le corrispondenti clausole per host riportate in precedenza in questo documento):
(A) TTL (vedere sezione 3.2.1.7)
Il campo TTL **DEVE (MUST)** essere decrementato come specificato per i gateway in [INTRO:2], e il datagramma può pertanto essere scartato.
(B) ICMP Destination Unreachable (vedere sezione 3.2.2.1)
L'host **DEVE (MUST)** essere in grado di generare messaggi "Destination Unreachable" con i seguenti codici:
4 (Fragmentation Needed but DF Set — Necessaria frammentazione ma DF impostato) — quando un datagramma a percorso sorgente non può essere frammentato per adattarsi alla rete di destinazione;
5 (Source Route Failed — Percorso sorgente fallito) — quando un datagramma a percorso sorgente non può essere inoltrato, ad esempio a causa di un problema di routing o perché il successivo hop di un percorso sorgente strict non si trova nella rete connessa.
(C) Indirizzo IP sorgente (vedere sezione 3.2.1.3)
Il datagramma a percorso sorgente inoltrato **PUÒ (MAY)** (e di norma lo farà) avere un indirizzo di sorgente che non è uno degli indirizzi IP dell'host inoltratore.
(D) Opzione Record Route (vedere sezione 3.2.1.8d)
Un host che inoltra un datagramma a percorso sorgente contenente un'opzione Record Route **DEVE (MUST)** aggiornare tale opzione (se vi è ancora spazio).
(E) Opzione Timestamp (vedere sezione 3.2.1.8e)
Un host che inoltra un datagramma a percorso sorgente contenente un'opzione Timestamp **DEVE (MUST)** aggiungere il timestamp corrente all'opzione, secondo le regole di tale opzione.
Per definire le restrizioni alle quali un host inoltra datagrammi a percorso sorgente, utilizziamo i termini "routing di sorgente locale (local source-routing)" per il caso in cui il successivo hop venga raggiunto tramite la stessa interfaccia fisica da cui il datagramma è arrivato; altrimenti si tratta di "routing di sorgente non locale (non-local source-routing)".
- Un host può effettuare il routing di sorgente locale senza restrizioni.
- Un host che supporta il routing di sorgente non locale DEVE (MUST) disporre di un interruttore configurabile per disabilitare l'inoltro, e tale interruttore DEVE (MUST) essere disabilitato per impostazione predefinita.
- Un host DEVE (MUST) soddisfare tutti i requisiti gateway dei filtri di policy configurabili di [INTRO:2] che limitano l'inoltro non locale.
Se un host riceve un datagramma a percorso sorgente incompleto ma per qualche motivo non lo inoltra, DOVREBBE (SHOULD) restituire un messaggio ICMP "Destination Unreachable (codice 5, Source Route Failed)", a meno che il datagramma non sia esso stesso un messaggio di errore ICMP.
3.3.6 Broadcast
La sezione 3.2.1.3 definisce quattro forme standard di indirizzi IP broadcast:
Broadcast limitato (Limited Broadcast): {-1, -1}
Broadcast diretto (Directed Broadcast): {
Broadcast diretto di sottorete (Subnet Directed Broadcast): {
Broadcast diretto di tutte le sottoreti (All-Subnets Directed Broadcast): {
Un host DEVE (MUST) riconoscere ciascuna delle forme sopra nel campo dell'indirizzo di destinazione di un datagramma in arrivo.
Esiste una classe di host* che utilizza forme non standard di indirizzi broadcast, sostituendo -1 con 0. Tutti gli host DOVREBBERO (SHOULD) riconoscere e accettare ciascuno di questi indirizzi broadcast non standard come indirizzo di destinazione di un datagramma in arrivo. Un host PUÒ (MAY) fornire facoltativamente, per ciascuna interfaccia fisica, un'opzione di configurazione per scegliere la forma 0 o la forma -1 dell'indirizzo broadcast, ma tale opzione DOVREBBE (SHOULD) essere per impostazione predefinita la forma standard (-1).
*Sistemi derivati da Unix 4.2BSD e successivi, ad eccezione di 4.3BSD.
Quando un host invia un datagramma a un indirizzo broadcast di link-layer, l'indirizzo di destinazione IP DEVE (MUST) essere un indirizzo broadcast IP o multicast IP valido.
Un host DOVREBBE (SHOULD) ignorare silenziosamente i datagrammi ricevuti tramite un broadcast di link-layer (vedere sezione 2.4) ma che non specificano un indirizzo di destinazione multicast o broadcast IP.
Un host DOVREBBE (SHOULD) utilizzare l'indirizzo broadcast limitato per il broadcast sulla rete connessa.
DISCUSSION (DISCUSSION):
L'uso dell'indirizzo broadcast limitato anziché dell'indirizzo broadcast diretto può migliorare la robustezza del sistema. I problemi sono spesso causati da macchine che non comprendono la grande varietà di indirizzi broadcast (vedere sezione 3.2.1.3), o che hanno un'opinione diversa sugli indirizzi broadcast utilizzati. Un tipico esempio di quest'ultimo caso è una macchina che non comprende il subnetting ma è connessa a una rete che è stata suddivisa in sottoreti. L'invio di un broadcast di sottorete per la rete connessa disorienterà tali macchine, che lo vedranno come un messaggio destinato a un altro host.
La questione se i datagrammi indirizzati all'indirizzo broadcast limitato debbano essere emessi da tutte le interfacce di un host multihomed è stata oggetto di discussione. La presente specifica non prende posizione in merito.
3.3.7 Multicasting IP (IP Multicasting)
Un host DOVREBBE (SHOULD) supportare il multicasting IP locale su tutte le reti connesse per le quali è definita una mappatura di indirizzi IP di classe D su indirizzi di link-layer (vedere sotto). Il supporto del multicasting IP locale comprende l'invio di datagrammi multicast, l'adesione a gruppi multicast e la ricezione di datagrammi multicast, nonché l'uscita dai gruppi multicast. Ciò implica il supporto dell'intero [IP:4] (ad eccezione del protocollo IGMP stesso, che è OPZIONALE (OPTIONAL)).
DISCUSSION (DISCUSSION):
IGMP fornisce ai gateway in grado di routing multicast le informazioni necessarie per supportare il multicasting IP attraverso più reti. Attualmente i gateway di routing multicast sono ancora in fase sperimentale e non sono ampiamente disponibili. Per gli host non connessi a una rete dotata di gateway di routing multicast, o che non devono ricevere datagrammi multicast provenienti da altre reti, IGMP è inutile e pertanto rimane opzionale per il momento. Tuttavia, il resto di [IP:4] è attualmente raccomandato, al fine di fornire a livello IP l'accesso all'indirizzamento multicast locale della rete, come desiderabile alternativa all'indirizzamento broadcast locale. Ci si aspetta che in futuro, man mano che i gateway di routing multicast diventeranno più diffusi, IGMP diventi raccomandato.
Se IGMP non è implementato, l'host DOVREBBE (SHOULD) comunque aderire al gruppo "all-hosts" (tutti gli host) (224.0.0.1) all'inizializzazione del livello IP, e mantenere tale adesione finché il livello IP è attivo.
DISCUSSION (DISCUSSION):
L'adesione al gruppo "all-hosts" supporta l'uso strettamente locale del multicasting, ad esempio i protocolli di rilevamento dei gateway, anche senza implementazione di IGMP.
La mappatura di indirizzi IP di classe D su indirizzi locali è attualmente specificata per i seguenti tipi di rete:
-
Ethernet/IEEE 802.3, come definito in [IP:4].
-
Qualsiasi rete che supporti il broadcast ma non il multicast: tutti gli indirizzi IP di classe D sono mappati sull'indirizzo broadcast locale.
-
Qualsiasi tipo di collegamento point-to-point (ad esempio linee SLIP o HDLC): non è necessaria alcuna mappatura. Tutti i datagrammi multicast IP vengono inviati così come sono nel frame locale.
Le mappature per altri tipi di rete saranno specificate in seguito.
Un host DOVREBBE (SHOULD) fornire un mezzo mediante il quale i protocolli o le applicazioni di livello superiore possano determinare quali delle reti connesse supportano l'indirizzamento multicast IP.
3.3.8 Segnalazione errori (Error Reporting)
Per quanto possibile, un host DEVE (MUST) restituire un datagramma di errore ICMP quando viene rilevato un errore, eccetto nei casi in cui la restituzione di messaggi di errore ICMP è esplicitamente vietata.
DISCUSSION (DISCUSSION):
Un fenomeno comune nelle reti a datagramma è la "malattia del buco nero (black hole disease)": i datagrammi vengono inviati, ma non torna nulla. Senza alcun messaggio di errore, l'utente fatica a capire dove si trovi il problema.
3.4 INTERFACCIA LIVELLO INTERNET/LIVELLO DI TRASPORTO (INTERNET/TRANSPORT LAYER INTERFACE)
L'interfaccia tra livello Internet e livello di trasporto DEVE (MUST) fornire pieno accesso a tutti i meccanismi del livello Internet, incluse opzioni, tipo di servizio e tempo di vita. Il livello di trasporto DEVE (MUST) disporre di un meccanismo per impostare tali parametri di interfaccia, o di un percorso per trasmetterli in modo trasparente dall'applicazione, o entrambi.
DISCUSSION (DISCUSSION):
Si esorta le applicazioni a sfruttare tali meccanismi ove applicabili, anche se non ancora efficaci nell'odierna Internet (ad esempio il TOS). Ciò consentirà loro di essere immediatamente disponibili quando lo diventeranno, senza richiedere una ristrutturazione massiccia del software host.
Descriviamo ora l'interfaccia concettuale tra livello di trasporto e livello IP come un insieme di chiamate di procedura. Si tratta di un'estensione delle informazioni della sezione 3.3 di RFC-791 [IP:1].
-
Inviare un datagramma (Send Datagram)
SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result )
I parametri sono definiti in RFC-791. Il passaggio del parametro Id è opzionale; vedere sezione 3.2.1.5.
-
Ricevere un datagramma (Receive Datagram)
RECV(BufPTR, prot => result, src, dst, SpecDest, TOS, len, opt)
Tutti i parametri sono definiti in RFC-791, ad eccezione di:
SpecDest = l'indirizzo di destinazione specifico del datagramma (definito nella sezione 3.2.1.3)
Il parametro result dst contiene l'indirizzo di destinazione del datagramma. Poiché tale indirizzo può essere un indirizzo broadcast o multicast, il parametro SpecDest DEVE (MUST) essere trasmesso (non mostrato in RFC-791). Il parametro opt contiene tutte le opzioni IP ricevute nel datagramma; tali opzioni DEVONO (MUST) anch'esse essere trasmesse al livello di trasporto.
-
Selezionare l'indirizzo sorgente (Select Source Address)
GET_SRCADDR(remote, TOS) -> local
remote = indirizzo IP remoto TOS = tipo di servizio local = indirizzo IP locale
Vedere sezione 3.3.4.3.
-
Trovare le dimensioni massime del datagramma (Find Maximum Datagram Sizes)
GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
MMS_R = dimensione massima del messaggio di trasporto ricevibile. MMS_S = dimensione massima del messaggio di trasporto inviabile. (local, remote, TOS definiti come sopra)
Vedere sezioni 3.3.2 e 3.3.3.
-
Avviso di successo di consegna (Advice on Delivery Success)
ADVISE_DELIVPROB(sense, local, remote, TOS)
Qui il parametro sense è un flag di 1 bit che indica se l'avviso è positivo o negativo; vedere la discussione nella sezione 3.3.1.4. Gli altri parametri sono definiti in precedenza.
-
Inviare un messaggio ICMP (Send ICMP Message)
SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt) -> result
(i parametri sono definiti in RFC-791).
Il passaggio del parametro Id è opzionale; vedere sezione 3.2.1.5. Il livello di trasporto DEVE (MUST) essere in grado di inviare determinati messaggi ICMP: porta non raggiungibile o qualsiasi messaggio di tipo richiesta. Naturalmente, questa funzione può essere considerata un caso particolare della chiamata SEND(); la descriviamo separatamente per chiarezza.
-
Ricevere un messaggio ICMP (Receive ICMP Message)
RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
(i parametri sono definiti in RFC-791).
Il livello IP DEVE (MUST) trasmettere determinati messaggi ICMP alle corrispondenti routine del livello di trasporto. Anche questa funzione può essere considerata un caso particolare della chiamata RECV(); la descriviamo separatamente per chiarezza.
Per i messaggi di errore ICMP, i dati trasmessi verso l'alto DEVONO (MUST) includere l'intestazione Internet originale più tutti i byte del messaggio originale contenuti nel messaggio ICMP. Il livello di trasporto utilizzerà questi dati per localizzare le informazioni di stato della connessione (se presenti).
In particolare, i seguenti messaggi ICMP DOVREBBERO (SHOULD) essere trasmessi verso l'alto:
- Destination Unreachable (Destinazione non raggiungibile)
- Source Quench (Sorgente esaurita)
- Echo Reply (Risposta echo) (all'interfaccia utente ICMP, a meno che la richiesta echo non provenga dal livello IP)
- Timestamp Reply (Risposta timestamp) (all'interfaccia utente ICMP)
- Time Exceeded (Tempo scaduto)
DISCUSSION (DISCUSSION):
In futuro, a questa interfaccia potranno essere aggiunte estensioni per trasmettere dati di percorso tra livello IP e livello di trasporto (vedere sezione 3.3.1.3).
3.5 RIEPILOGO DEI REQUISITI DEL LIVELLO INTERNET (INTERNET LAYER REQUIREMENTS SUMMARY)
| Funzione | Sezione | Must | Should | May | Should Not | Must Not |
|---|---|---|---|---|---|---|
| Implementare IP e ICMP (Implement IP and ICMP) | 3.1 | x | ||||
| Gestire il multihoming remoto nel livello applicazione (Handle remote multihoming in application layer) | 3.1 | x | ||||
| Supportare il multihoming locale (Support local multihoming) | 3.1 | x | ||||
| Soddisfare le specifiche gateway se si inoltrano datagrammi (Meet gateway specs if forward datagrams) | 3.1 | x | ||||
| Interruttore di configurazione per gateway integrato (Configuration switch for embedded gateway) | 3.1 | x | 1 | |||
| - L'interruttore di configurazione predefinito è non-gateway (- Config switch default to non-gateway) | 3.1 | x | 1 | |||
| - Auto-config in base al numero di interfacce (- Auto-config based on number of interfaces) | 3.1 | x | ||||
| Essere in grado di registrare i datagrammi scartati (Able to log discarded datagrams) | 3.1 | x | ||||
| - Registrare in un contatore (- Record in counter) | 3.1 | x | ||||
| Scartare silenziosamente Version != 4 (Silently discard Version != 4) | 3.2.1.1 | x | ||||
| Verificare il checksum IP, scartare silenziosamente i datagrammi errati (Verify IP checksum, silently discard bad dgram) | 3.2.1.2 | x | ||||
| Indirizzamento (Addressing): | ||||||
| - Indirizzamento di sottorete (RFC-950) (- Subnet addressing (RFC-950)) | 3.2.1.3 | x | ||||
| - L'indirizzo sorgente deve essere l'indirizzo IP proprio dell'host (- Src address must be host's own IP address) | 3.2.1.3 | x | ||||
| - Scartare silenziosamente il datagramma con indirizzo di destinazione errato (- Silently discard datagram with bad dest addr) | 3.2.1.3 | x | ||||
| - Scartare silenziosamente il datagramma con indirizzo sorgente errato (- Silently discard datagram with bad src addr) | 3.2.1.3 | x | ||||
| Supportare il riassemblaggio (Support reassembly) | 3.2.1.4 | x | ||||
| Conservare lo stesso campo Id in un datagramma identico (Retain same Id field in identical datagram) | 3.2.1.5 | x | ||||
| TOS: | ||||||
| - Consentire al livello di trasporto di impostare il TOS (- Allow transport layer to set TOS) | 3.2.1.6 | x | ||||
| - Trasmettere il TOS ricevuto al livello di trasporto (- Pass received TOS up to transport layer) | 3.2.1.6 | x | ||||
| - Utilizzare le mappature di link-layer RFC-795 per il TOS (- Use RFC-795 link-layer mappings for TOS) | 3.2.1.6 | x | ||||
| TTL: | ||||||
| - Inviare un pacchetto con TTL di 0 (- Send packet with TTL of 0) | 3.2.1.7 | x | ||||
| - Scartare i pacchetti ricevuti con TTL < 2 (- Discard received packets with TTL < 2) | 3.2.1.7 | x | ||||
| - Consentire al livello di trasporto di impostare il TTL (- Allow transport layer to set TTL) | 3.2.1.7 | x | ||||
| - TTL fisso configurabile (- Fixed TTL is configurable) | 3.2.1.7 | x | ||||
| Opzioni IP (IP Options): | ||||||
| - Consentire al livello di trasporto di inviare opzioni IP (- Allow transport layer to send IP options) | 3.2.1.8 | x | ||||
| - Trasmettere tutte le opzioni IP ricevute al livello superiore (- Pass all IP options rcvd to higher layer) | 3.2.1.8 | x | ||||
| - Il livello IP ignora silenziosamente le opzioni sconosciute (- IP layer silently ignore unknown options) | 3.2.1.8 | x | ||||
| - Opzione Security (- Security option) | 3.2.1.8a | x | ||||
| - Inviare l'opzione Stream Identifier (- Send Stream Identifier option) | 3.2.1.8b | x | ||||
| - Ignorare silenziosamente l'opzione Stream Identifer (- Silently ignore Stream Identifer option) | 3.2.1.8b | x | ||||
| - Opzione Record Route (- Record Route option) | 3.2.1.8d | x | ||||
| - Opzione Timestamp (- Timestamp option) | 3.2.1.8e | x | ||||
| Opzione Source Route (Source Route Option): | ||||||
| - Originare e terminare le opzioni Source Route (- Originate & terminate Source Route options) | 3.2.1.8c | x | ||||
| - Datagramma con SR completata passato al TL (- Datagram with completed SR passed up to TL) | 3.2.1.8c | x | ||||
| - Costruire un percorso di ritorno corretto (non ridondante) (- Build correct (non-redundant) return route) | 3.2.1.8c | x | ||||
| - Inviare più opzioni SR in un unico header (- Send multiple SR options in one header) | 3.2.1.8c | x | ||||
| ICMP: | ||||||
| - Scartare silenziosamente un msg ICMP di tipo sconosciuto (- Silently discard ICMP msg with unknown type) | 3.2.2 | x | ||||
| - Includere più di 8 ottetti del datagramma originale (- Include more than 8 octets of orig datagram) | 3.2.2 | x | ||||
| - Gli ottetti inclusi identici a quelli ricevuti (- Included octets same as received) | 3.2.2 | x | ||||
| - Demultiplexare l'errore ICMP al protocollo di trasporto (- Demux ICMP Error to transport protocol) | 3.2.2 | x | ||||
| - Inviare un messaggio di errore ICMP con TOS=0 (- Send ICMP error message with TOS=0) | 3.2.2 | x | ||||
| - Inviare un messaggio di errore ICMP per: (- Send ICMP error message for: ) | ||||||
| - msg di errore ICMP (- ICMP error msg) | 3.2.2 | x | ||||
| - broadcast IP o multicast IP (- IP b'cast or IP m'cast) | 3.2.2 | x | ||||
| - broadcast di link-layer (- Link-layer b'cast) | 3.2.2 | x | ||||
| - frammento non iniziale (- Non-initial fragment) | 3.2.2 | x | ||||
| - datagramma con indirizzo sorgente non univoco (- Datagram with non-unique src address) | 3.2.2 | x | ||||
| - Restituire i messaggi di errore ICMP (se non proibito) (- Return ICMP error msgs (when not prohibited)) | 3.3.8 | x | ||||
| - Destination Unreachable: | ||||||
| Generare Destination Unreachable (codice 2/3) (Generate Dest Unreachable (code 2/3)) | 3.2.2.1 | x | ||||
| Trasmettere ICMP Dest Unreachable al livello superiore (Pass ICMP Dest Unreachable to higher layer) | 3.2.2.1 | x | ||||
| Il livello superiore agisce su Dest Unreach (Higher layer act on Dest Unreach) | 3.2.2.1 | x | ||||
| Interpretare Dest Unreach come semplice indizio (Interpret Dest Unreach as only hint) | 3.2.2.1 | x | ||||
| - Redirect: | ||||||
| L'host invia Redirect (Host send Redirect) | 3.2.2.2 | x | ||||
| Aggiornare la cache di routing alla ricezione di Redirect (Update route cache when recv Redirect) | 3.2.2.2 | x | ||||
| Gestire sia Host che Net Redirects (Handle both Host and Net Redirects) | 3.2.2.2 | x | ||||
| Scartare un Redirect illegale (Discard illegal Redirect) | 3.2.2.2 | x | ||||
| - Source Quench: | ||||||
| Inviare Source Quench se il buffering è superato (Send Source Quench if buffering exceeded) | 3.2.2.3 | x | ||||
| Trasmettere Source Quench al livello superiore (Pass Source Quench to higher layer) | 3.2.2.3 | x | ||||
| Il livello superiore agisce su Source Quench (Higher layer act on Source Quench) | 3.2.2.3 | x | ||||
| - Time Exceeded: trasmettere al livello superiore (Time Exceeded: pass to higher layer) | 3.2.2.4 | x | ||||
| - Parameter Problem: | ||||||
| Inviare messaggi Parameter Problem (Send Parameter Problem messages) | 3.2.2.5 | x | ||||
| Trasmettere Parameter Problem al livello superiore (Pass Parameter Problem to higher layer) | 3.2.2.5 | x | ||||
| Segnalare Parameter Problem all'utente (Report Parameter Problem to user) | 3.2.2.5 | x | ||||
| - Richiesta/Risposta ICMP Echo (ICMP Echo Request or Reply): | ||||||
| Server Echo e client Echo (Echo server and Echo client) | 3.2.2.6 | x | ||||
| Client Echo (Echo client) | 3.2.2.6 | x | ||||
| Scartare la Richiesta Echo all'indirizzo broadcast (Discard Echo Request to broadcast address) | 3.2.2.6 | x | ||||
| Scartare la Richiesta Echo all'indirizzo multicast (Discard Echo Request to multicast address) | 3.2.2.6 | x | ||||
| Utilizzare l'indirizzo di dest. specifico come sorgente Echo Reply (Use specific-dest addr as Echo Reply src) | 3.2.2.6 | x | ||||
| Inviare gli stessi dati nell'Echo Reply (Send same data in Echo Reply) | 3.2.2.6 | x | ||||
| Trasmettere Echo Reply al livello superiore (Pass Echo Reply to higher layer) | 3.2.2.6 | x | ||||
| Riflettere le opzioni Record Route, Timestamp (Reflect Record Route, Time Stamp options) | 3.2.2.6 | x | ||||
| Invertire e riflettere l'opzione Source Route (Reverse and reflect Source Route option) | 3.2.2.6 | x | ||||
| - Richiesta/Risposta maschera indirizzo ICMP (ICMP Address Mask Request and Reply): | ||||||
| Fonte maschera indirizzo configurabile (Addr Mask source configurable) | 3.2.2.9 | x | ||||
| Supportare la configurazione statica della maschera indirizzo (Support static configuration of addr mask) | 3.2.2.9 | x | ||||
| Ottenere dinamicamente la maschera indirizzo durante l'avvio (Get addr mask dynamically during booting) | 3.2.2.9 | x | ||||
| Ottenere l'indirizzo tramite Richiesta/Risposta maschera ICMP (Get addr via ICMP Addr Mask Request/Reply) | 3.2.2.9 | x | ||||
| Ritrasmettere la richiesta maschera se nessuna risposta (Retransmit Addr Mask Req if no Reply) | 3.2.2.9 | x | 3 | |||
| Assumere la maschera predefinita se nessuna risposta (Assume default mask if no Reply) | 3.2.2.9 | x | 3 | |||
| Aggiornare la maschera indirizzo solo dalla prima risposta (Update address mask from first Reply only) | 3.2.2.9 | x | 3 | |||
| Controllo di plausibilità della maschera indirizzo (Reasonableness check on Addr Mask) | 3.2.2.9 | x | ||||
| Inviare messaggi di risposta maschera non autorizzati (Send unauthorized Addr Mask Reply msgs) | 3.2.2.9 | x | ||||
| Esplicitamente configurato come agente (Explicitly configured to be agent) | 3.2.2.9 | x | ||||
| Config statica => flag Addr-Mask-Authoritative (Static config=> Addr-Mask-Authoritative flag) | 3.2.2.9 | x | ||||
| Trasmettere in broadcast la risposta maschera all'inizializzazione (Broadcast Addr Mask Reply when init.) | 3.2.2.9 | x | 3 | |||
| Routing dei datagrammi in uscita (ROUTING OUTBOUND DATAGRAMS): | ||||||
| - Utilizzare la maschera indirizzo nella decisione locale/remoto (Use address mask in local/remote decision) | 3.3.1.1 | x | ||||
| - Funzionare senza gateway nella rete connessa (Operate with no gateways on conn network) | 3.3.1.1 | x | ||||
| - Mantenere una "cache di routing" dei gateway del prossimo hop (Maintain "route cache" of next-hop gateways) | 3.3.1.2 | x | ||||
| - Trattare Host e Net Redirect allo stesso modo (Treat Host and Net Redirect the same) | 3.3.1.2 | x | ||||
| - In assenza di voce in cache, usare il gateway predefinito (If no cache entry, use default gateway) | 3.3.1.2 | x | ||||
| Supportare più gateway predefiniti (Support multiple default gateways) | 3.3.1.2 | x | ||||
| - Fornire una tabella di route statiche (Provide table of static routes) | 3.3.1.2 | x | ||||
| Flag: rotta sovrascrivibile dai Redirect (Flag: route overridable by Redirects) | 3.3.1.2 | x | ||||
| - Indicizzare la cache di routing sull'host, non sulla rete (Key route cache on host, not net address) | 3.3.1.3 | x | ||||
| - Includere il TOS nella cache di routing (Include TOS in route cache) | 3.3.1.3 | x | ||||
| - Essere in grado di rilevare il guasto del gateway del prossimo hop (Able to detect failure of next-hop gateway) | 3.3.1.4 | x | ||||
| - Presumere che la rotta sia valida per sempre (Assume route is good forever) | 3.3.1.4 | x | ||||
| - Effettuare ping continuo ai gateway (Ping gateways continuously) | 3.3.1.4 | x | ||||
| - Effettuare ping solo quando viene inviato traffico (Ping only when traffic being sent) | 3.3.1.4 | x | ||||
| - Effettuare ping solo in assenza di indicazione positiva (Ping only when no positive indication) | 3.3.1.4 | x | ||||
| - I livelli superiore e inferiore forniscono consigli (Higher and lower layers give advice) | 3.3.1.4 | x | ||||
| - Passare dal gateway predefinito guasto a un altro (Switch from failed default g'way to another) | 3.3.1.5 | x | ||||
| - Metodo manuale per inserire le info di config (Manual method of entering config info) | 3.3.1.6 | x | ||||
| Riassemblaggio e frammentazione (REASSEMBLY and FRAGMENTATION): | ||||||
| - Essere in grado di riassemblare i datagrammi in arrivo (Able to reassemble incoming datagrams) | 3.3.2 | x | ||||
| Datagrammi di almeno 576 byte (At least 576 byte datagrams) | 3.3.2 | x | ||||
| EMTU_R configurabile o illimitato (EMTU_R configurable or indefinite) | 3.3.2 | x | ||||
| - Il livello di trasporto può apprendere MMS_R (Transport layer able to learn MMS_R) | 3.3.2 | x | ||||
| - Inviare ICMP Time Exceeded in caso di timeout di riassemblaggio (Send ICMP Time Exceeded on reassembly timeout) | 3.3.2 | x | ||||
| Valore fisso di timeout di riassemblaggio (Fixed reassembly timeout value) | 3.3.2 | x | ||||
| - Trasmettere MMS_S ai livelli superiori (Pass MMS_S to higher layers) | 3.3.3 | x | ||||
| - Frammentazione locale dei pacchetti in uscita (Local fragmentation of outgoing packets) | 3.3.3 | x | ||||
| Altrimenti non inviare più grande di MMS_S (Else don't send bigger than MMS_S) | 3.3.3 | x | ||||
| - Inviare al massimo 576 a destinazione off-net (Send max 576 to off-net destination) | 3.3.3 | x | ||||
| - Flag di configurazione All-Subnets-MTU (All-Subnets-MTU configuration flag) | 3.3.3 | x | ||||
| Multihoming: | ||||||
| - Rispondere con lo stesso indirizzo dell'ind. di dest. specifica (Reply with same addr as spec-dest addr) | 3.3.4.2 | x | ||||
| - Consentire all'applicazione di scegliere l'indirizzo IP locale (Allow application to choose local IP addr) | 3.3.4.2 | x | ||||
| - Scartare silenziosamente il datagramma su interfaccia "errata" (Silently discard d'gram in "wrong" interface) | 3.3.4.2 | x | ||||
| - Inviare il datagramma solo tramite l'interfaccia "giusta" (Only send d'gram through "right" interface) | 3.3.4.2 | x | 4 | |||
| Inoltro del percorso sorgente (SOURCE-ROUTE FORWARDING): | ||||||
| - Inoltrare il datagramma con opzione Source Route (Forward datagram with Source Route option) | 3.3.5 | x | 1 | |||
| Rispettare le corrispondenti regole gateway (Obey corresponding gateway rules) | 3.3.5 | x | 1 | |||
| Aggiornare TTL secondo le regole gateway (Update TTL by gateway rules) | 3.3.5 | x | 1 | |||
| Essere in grado di generare i codici di errore ICMP 4, 5 (Able to generate ICMP err code 4, 5) | 3.3.5 | x | 1 | |||
| Indirizzo IP sorgente non host locale (IP src addr not local host) | 3.3.5 | x | 1 | |||
| Aggiornare le opzioni Timestamp, Record Route (Update Timestamp, Record Route options) | 3.3.5 | x | 1 | |||
| Interruttore configurabile per SR non locale (Configurable switch for non-local SRing) | 3.3.5 | x | 1 | |||
| Disabilitato per impostazione predefinita (Defaults to OFF) | 3.3.5 | x | 1 | |||
| Soddisfare le regole di accesso gateway per SR non locale (Satisfy gwy access rules for non-local SRing) | 3.3.5 | x | 1 | |||
| Se non inoltrato, inviare Dest Unreach (cd 5) (If not forward, send Dest Unreach (cd 5)) | 3.3.5 | x | 2 | |||
| Broadcast (BROADCAST): | ||||||
| - Indirizzo broadcast come indirizzo IP sorgente (Broadcast addr as IP source addr) | 3.2.1.3 | x | ||||
| - Ricevere formati broadcast 0 o -1 OK (Receive 0 or -1 broadcast formats OK) | 3.3.6 | x | ||||
| - Opzione configurabile per inviare broadcast 0 o -1 (Config'ble option to send 0 or -1 b'cast) | 3.3.6 | x | ||||
| Predefinito broadcast -1 (Default to -1 broadcast) | 3.3.6 | x | ||||
| - Riconoscere tutti i formati di indirizzo broadcast (Recognize all broadcast address formats) | 3.3.6 | x | ||||
| - Usare indirizzo IP b'cast/m'cast nel b'cast link-layer (Use IP b'cast/m'cast addr in link-layer b'cast) | 3.3.6 | x | ||||
| - Scartare silenziosamente i datagrammi solo broadcast link-layer (Silently discard link-layer-only b'cast dg's) | 3.3.6 | x | ||||
| - Usare l'indirizzo broadcast limitato per la rete connessa (Use Limited Broadcast addr for connected net) | 3.3.6 | x | ||||
| Multicast (MULTICAST): | ||||||
| - Supportare il multicasting IP locale (RFC-1112) (Support local IP multicasting (RFC-1112)) | 3.3.7 | x | ||||
| - Supportare IGMP (RFC-1112) (Support IGMP (RFC-1112)) | 3.3.7 | x | ||||
| - Unirsi al gruppo all-hosts all'avvio (Join all-hosts group at startup) | 3.3.7 | x | ||||
| - I livelli superiori apprendono la capacità m'cast dell'iface (Higher layers learn i'face m'cast capability) | 3.3.7 | x | ||||
| Interfaccia (INTERFACE): | ||||||
| - Consentire al livello di trasporto di usare tutti i meccanismi IP (Allow transport layer to use all IP mechanisms) | 3.4 | x | ||||
| - Trasmettere l'identificatore di interfaccia al livello di trasporto (Pass interface ident up to transport layer) | 3.4 | x | ||||
| - Trasmettere tutte le opzioni IP al livello di trasporto (Pass all IP options up to transport layer) | 3.4 | x | ||||
| - Il livello di trasporto può inviare determinati messaggi ICMP (Transport layer can send certain ICMP messages) | 3.4 | x | ||||
| - Trasmettere i messaggi ICMP specificati al livello di trasporto (Pass spec'd ICMP messages up to transp. layer) | 3.4 | x | ||||
| Includere intestazione IP + almeno 8 ottetti dall'originale (Include IP hdr+8 octets or more from orig.) | 3.4 | x |
Note a piè di pagina (Footnotes):
(1) Solo se la funzionalità è implementata. (2) Questo requisito decade se il datagramma è un messaggio di errore ICMP. (3) Solo se la funzionalità è implementata e configurata su "attivo". (4) Salvo che disponga della funzionalità gateway integrato o sia soggetta a routing di sorgente.