1. Introduzione (INTRODUCTION)
Questo documento, insieme a un altro documento, definisce e discute i requisiti per l'implementazione dei sistemi host della famiglia di protocolli Internet. Questo RFC tratta i livelli di protocollo di comunicazione: il livello di collegamento, il livello Internet e il livello di trasporto; il suo documento complementare RFC "Requisiti per gli host Internet -- Applicazione e supporto" [INTRO:1] tratta i protocolli del livello applicativo. Questo documento dovrebbe inoltre essere letto con "Requisiti per i gateway Internet" [INTRO:2].
Questi documenti mirano a fornire linee guida ai fornitori, agli implementatori e agli utenti del software di comunicazione Internet. Rappresentano un consenso di esperienza tecnica e saggezza considerevole, contribuita dai membri della comunità di ricerca e dei fornitori Internet.
Questo RFC elenca i protocolli standard che un host connesso a Internet deve utilizzare e incorpora per riferimento gli RFC e altri documenti che descrivono le specifiche attuali di questi protocolli. Corregge inoltre gli errori dei documenti citati e aggiunge ulteriori discussioni e indicazioni per gli implementatori.
Per ogni protocollo, questo documento contiene inoltre un insieme di requisiti, raccomandazioni e opzioni esplicite. Il lettore deve comprendere che l'elenco dei requisiti di questo documento è di per sé incompleto; l'insieme completo dei requisiti per gli host Internet è definito principalmente nei documenti di specifica dei protocolli standard e comprende le correzioni, le revisioni e gli aggiunti di questo RFC.
Dopo aver letto attentamente l'RFC e aver avuto un certo scambio con la comunità tecnica Internet, implementando i protocolli in buona fede e seguendo le buone pratiche di ingegneria del software di comunicazione, l'implementazione risultante non dovrebbe differire dai requisiti di questo documento se non in modo trascurabile. Pertanto, in molti casi, i "requisiti" di questo RFC sono già stati enunciati o implicitati nei documenti di protocollo standard, sicché includerli è in un certo senso ridondante. Tuttavia, sono stati inclusi perché alcune implementazioni in passato hanno fatto scelte errate, causando problemi di interoperabilità, prestazioni e/o robustezza.
Questo documento contiene discussioni e spiegazioni di molti requisiti e raccomandazioni. Un semplice elenco di requisiti è pericoloso, poiché:
- Alcune caratteristiche richieste sono più importanti di altre, e alcune caratteristiche sono opzionali.
- Potrebbero esserci valide ragioni per cui un particolare prodotto venditore, progettato per un ambiente vincolato, potrebbe scegliere una specifica diversa.
Tuttavia, per raggiungere l'obiettivo generale dell'interoperabilità di qualsiasi host sulla diversità e complessità dei sistemi Internet, le norme di questo documento devono essere seguite. Sebbene la maggior parte delle implementazioni attuali fallisca in vari modi (a volte lievi, a volte rilevanti) nel soddisfare questi requisiti, questa specifica è l'ideale a cui dovremmo tendere.
Questi requisiti si basano sul livello attuale dell'architettura Internet. Questo file sarà aggiornato secondo necessità per fornire chiarimenti aggiuntivi o incorporare informazioni aggiuntive nei campi in cui le norme sono ancora in evoluzione.
Questa sezione introduttiva fornisce innanzitutto una breve panoramica dell'architettura Internet pertinente per gli host, quindi offre alcuni consigli generali ai fornitori di software host. Infine, fornisce indicazioni per la lettura del resto del documento e alcuni termini.
1.1 L'architettura Internet (The Internet Architecture)
Per un quadro generale e discussioni sull'architettura Internet e la famiglia di protocolli sottostante, vedere il DDN Protocol Handbook [INTRO:3]; i materiali di背景 includono ad esempio [INTRO:9], [INTRO:10] e [INTRO:11]. Il riferimento [INTRO:5] descrive la procedura per ottenere i documenti di protocollo Internet e [INTRO:6] contiene l'elenco dei numeri assegnati nei protocolli Internet.
1.1.1 Host Internet (Internet Hosts)
Un computer host, o semplicemente "host", è il consumatore finale dei servizi di comunicazione. Gli host in genere eseguono applicazioni per conto degli utenti e utilizzano i servizi di comunicazione di rete e/o Internet per supportare tale funzione. Un host Internet corrisponde al concetto di "sistema terminale (End-System)" utilizzato nella famiglia di protocolli OSI [INTRO:13].
Un sistema di comunicazione Internet è composto da reti a pacchetti interconnesse, che utilizzano i protocolli Internet per supportare la comunicazione tra i computer host. Queste reti sono interconnesse utilizzando computer a commutazione di pacchetto chiamati "gateway" o "router IP (IP routers)" (termine della comunità Internet), "sistemi intermedi (Intermediate Systems)" (mondo OSI) [INTRO:13]. L'RFC "Requisiti per i gateway Internet" [INTRO:2] contiene la specifica ufficiale per i gateway Internet. Questo RFC, insieme a questo documento e al suo documento complementare [INTRO:1], definisce le regole per l'implementazione dell'architettura Internet attuale.
Gli host Internet variano considerevolmente per dimensioni, velocità e funzione. Le loro dimensioni vanno dal microprocessore alla stazione di lavoro, al mainframe, al supercomputer. A livello funzionale, vanno dall'host a scopo singolo (come un server terminale) all'host a servizio completo che supporta molti servizi di rete online, in genere includendo login remoto, trasferimento file e posta elettronica.
Se un host possiede più interfacce verso la stessa rete o reti diverse, viene generalmente chiamato multihomed (multi-ospite). Vedere la sezione 3.3.4 sul multihoming.
1.1.2 Ipotesi architetturali (Architectural Assumptions)
L'architettura Internet attuale si basa su un insieme di ipotesi sui sistemi di comunicazione. Le ipotesi più pertinenti per gli host sono le seguenti:
(a) Internet è una rete di reti.
Ogni host è collegato direttamente a una rete particolare; la sua connessione a Internet è solo concettuale. Due host sulla stessa rete comunicano utilizzando lo stesso insieme di protocolli che quando comunicano con un host su una rete remota.
(b) I gateway non conservano informazioni di stato di connessione.
Per migliorare la robustezza del sistema di comunicazione, i gateway sono progettati per essere senza stato, inoltrando ogni datagramma IP indipendentemente da qualsiasi altro datagramma. Pertanto, percorsi ridondanti possono essere utilizzati per fornire un servizio robusto in caso di guasti di gateway e reti intermedie.
Tutte le informazioni di stato necessarie per il controllo di flusso e l'affidabilità end-to-end sono implementate negli host, nel livello di trasporto o nell'applicazione. Pertanto, tutte le informazioni di controllo di connessione risiedono con gli endpoint di comunicazione, cosicché vengono perse solo se un endpoint fallisce.
(c) La complessità del routing deve essere posta nei gateway.
Il routing è un problema complesso e difficile che deve essere eseguito dai gateway piuttosto che dagli host. Un obiettivo importante è isolare il software host dall'evoluzione inevitabile dell'architettura di routing Internet.
(d) I sistemi devono tollerare ampie differenze di rete.
Un obiettivo fondamentale della progettazione Internet è tollerare un'ampia gamma di caratteristiche di rete — ad esempio larghezza di banda, latenza, perdita di pacchetti, riordino e dimensione massima dei pacchetti. Un altro obiettivo è la robustezza contro guasti individuali di reti, gateway e host, sfruttando qualsiasi larghezza di banda ancora disponibile. L'obiettivo finale è l'"interconnessione di sistemi aperti" completa: un host Internet deve essere in grado di interoperare in modo robusto ed efficiente con qualsiasi altro host Internet su percorsi Internet diversi.
A volte gli implementatori di host progettano per un obiettivo meno ambizioso. Ad esempio, l'ambiente LAN è generalmente molto più mite dell'intero Internet; le LAN hanno bassa perdita di pacchetti, bassa latenza e non riordinano. Alcuni fornitori hanno immesso sul mercato implementazioni host adatte solo a semplici ambienti LAN, ma che funzionano male per l'interoperabilità generale. I fornitori giustificano tali prodotti con l'economicità nei mercati LAN vincolati. Tuttavia, le LAN isolate raramente rimangono isolate a lungo; vengono presto connesse le une alle altre, agli intranet organizzativi e infine al sistema Internet globale. Alla fine, il software host Internet incompleto o non qualificato nuoce sia al cliente che al fornitore.
I requisiti dettagliati in questo documento sono progettati per host Internet completamente funzionali, capaci di piena interoperabilità su qualsiasi percorso Internet.
1.1.3 La suite di protocolli Internet (Internet Protocol Suite)
Per comunicare utilizzando il sistema Internet, gli host devono implementare l'insieme di protocolli a strati che compongono la suite di protocolli Internet. Gli host in genere devono implementare almeno un protocollo di ciascun livello.
I livelli di protocollo utilizzati nell'architettura Internet sono i seguenti [INTRO:4]:
Livello applicativo (Application Layer)
Il livello applicativo è il livello più alto della suite di protocolli Internet. La suite di protocolli Internet non suddivide ulteriormente il livello applicativo, sebbene alcuni protocolli di livello applicativo Internet contengano effettivamente alcune sottostratificazioni interne. Il livello applicativo della suite di protocolli Internet combina essenzialmente le funzioni dei due livelli superiori del modello di riferimento OSI — il livello di presentazione e il livello applicativo.
Distinguamo due classi di protocolli di livello applicativo: i protocolli utente che forniscono servizi diretti agli utenti e i protocolli di supporto che forniscono funzioni di sistema generali. I requisiti per i protocolli utente e di supporto si trovano nel RFC complementare [INTRO:1].
I protocolli utente Internet più comuni sono:
- Telnet (login remoto)
- FTP (trasferimento file)
- SMTP (consegna posta elettronica)
Esistono molti altri protocolli utente standardizzati [INTRO:4] nonché molti protocolli utente privati.
I protocolli di supporto per il mapping dei nomi host, il bootstrap e la gestione includono SNMP, BOOTP, RARP e il sistema dei nomi di dominio (DNS).
Livello di trasporto (Transport Layer)
Il livello di trasporto fornisce servizi di comunicazione end-to-end alle applicazioni. Attualmente ci sono due protocolli di trasporto principali:
- Transmission Control Protocol (TCP)
- User Datagram Protocol (UDP)
TCP è un servizio di trasporto affidabile orientato alla connessione, che fornisce affidabilità end-to-end, riordino e controllo di flusso. UDP è un servizio di trasporto senza connessione ("datagramma").
La comunità di ricerca ha sviluppato altri protocolli di trasporto e la collezione ufficiale dei protocolli di trasporto Internet potrebbe espandersi in futuro.
I protocolli di trasporto sono discussi nel capitolo 4.
Livello Internet (Internet Layer)
Tutti i protocolli di trasporto Internet utilizzano il protocollo Internet (IP) per trasmettere dati dall'host sorgente all'host di destinazione. IP è un servizio internetwork senza connessione o datagramma che non fornisce garanzia di consegna end-to-end. Pertanto, i datagrammi IP possono arrivare all'host di destinazione corrotti, duplicati, fuori ordine, o non arrivare affatto. Quando è richiesta l'affidabilità, i livelli sopra IP sono responsabili di fornire un servizio di consegna affidabile. Il protocollo IP contiene disposizioni per l'indirizzamento, la specifica del tipo di servizio, la frammentazione e il riassemblaggio, nonché informazioni di sicurezza.
La caratteristica di datagramma o senza connessione del protocollo IP è una caratteristica fondamentale e distintiva dell'architettura Internet. L'IP Internet è il modello del protocollo di rete senza connessione OSI [INTRO:12].
ICMP è un protocollo di controllo considerato parte di IP, sebbene sia architetturalmente al di sopra di IP, cioè utilizza IP come i protocolli di trasporto come TCP o UDP per trasportare i suoi dati end-to-end. ICMP fornisce segnalazione errori, segnalazione di congestione e reindirizzamento del gateway di primo hop.
IGMP è un protocollo di livello Internet utilizzato per stabilire gruppi di host dinamici per il multicast IP.
I protocolli di livello Internet IP, ICMP e IGMP sono discussi nel capitolo 3.
Livello di collegamento (Link Layer)
Per comunicare sulla rete a cui è direttamente connesso, un host deve implementare i protocolli di comunicazione utilizzati per connettersi a tale rete. Chiamiamo questi protocolli di livello di collegamento o di livello di accesso al mezzo.
Esistono molti protocolli di livello di collegamento diversi, corrispondenti a molti tipi di reti diversi. Vedere il capitolo 2.
1.1.4 Codice gateway integrato (Embedded Gateway Code)
Alcuni software host Internet includono funzionalità di gateway integrate, che consentono a questi host di inoltrare pacchetti come gateway pur continuando a eseguire le funzioni di livello applicativo dell'host.
Questi sistemi a doppio scopo devono seguire l'RFC dei requisiti gateway [INTRO:2] nelle loro funzionalità di gateway e questo documento nelle loro funzionalità di host. In tutti i casi di sovrapposizione, le due specifiche devono essere coerenti.
La comunità Internet è divisa sulle funzionalità di gateway integrate. I principali argomenti sono i seguenti:
A favore (Pro): In ambienti LAN non ufficiali o internet isolati, può essere comodo ed economico utilizzare sistemi host esistenti come gateway.
C'è anche un argomento architetturale a favore delle funzionalità di gateway integrate: il multihoming è molto più comune di quanto inizialmente previsto e il multihoming costringe gli host a prendere decisioni di routing come i gateway. Se un host multihomed include un gateway integrato, possiederà una conoscenza completa del routing, permettendogli di prendere decisioni di routing migliori.
Contro (Con): Gli algoritmi e i protocolli gateway sono ancora in evoluzione e continueranno a cambiare man mano che il sistema Internet cresce. Cercare di includere una funzionalità gateway generica nel livello IP di un host obbligherà i responsabili della manutenzione dei sistemi host a seguire questi cambiamenti (più frequenti). Inoltre, un pool più ampio di implementazioni gateway renderà più difficile il coordinamento dei cambiamenti. Infine, la complessità del livello IP di un gateway è leggermente superiore a quella di un host, rendendo più complesse le attività di implementazione e gestione.
Inoltre, alcuni stili operativi degli host non si prestano a fornire un servizio gateway stabile e robusto.
Entrambi i punti di vista hanno una parte considerevole di ragione. Una conclusione che se ne può trarre è che gli amministratori host devono avere un controllo consapevole sul fatto che un determinato host agisca come gateway. I requisiti dettagliati sono nella sezione 3.1.
1.2 Considerazioni generali (General Considerations)
I fornitori di software host Internet hanno appreso due lezioni importanti che i nuovi fornitori dovrebbero prendere seriamente in considerazione.
1.2.1 L'evoluzione continua di Internet (Continuing Internet Evolution)
La crescita enorme di Internet ha rivelato problemi di gestione e scalabilità di un grande sistema di comunicazione a pacchetti basato su datagrammi. Questi problemi stanno essere risolti e pertanto le norme descritte in questo documento continueranno a evolvere. Questi cambiamenti saranno pianificati e controllati con cura, poiché fornitori e organizzazioni responsabili dell'operatività di rete vi partecipano ampiamente.
Sviluppo, evoluzione e revisione sono caratteristiche dei protocolli di rete informatica di oggi e continueranno per diversi anni. Un fornitore che sviluppa software di comunicazione per la suite di protocolli Internet (o qualsiasi altra suite di protocolli!) e poi non mantiene e aggiorna tale software di fronte a specifiche mutevoli lascerà una scia di clienti insoddisfatti. Internet è una grande rete di comunicazione in cui gli utenti rimangono in contatto continuo. L'esperienza mostra che la conoscenza dei difetti del software dei fornitori si diffonde rapidamente nella comunità tecnica Internet.
1.2.2 Principio di robustezza (Robustness Principle)
A ogni livello di protocollo, c'è una regola generale la cui applicazione porta enormi benefici in robustezza e interoperabilità [IP:1]:
"Sii liberale in ciò che accetti e conservativo in ciò che invii (Be liberal in what you accept, and conservative in what you send)"
Il software dovrebbe essere scritto per gestire qualsiasi errore concepibile, per quanto improbabile; prima o poi arriverà un pacchetto con quella particolare combinazione di errore e attributi e, a meno che il software non sia preparato, il caos può seguire. In generale, è bene presumere che la rete sia piena di entità malevole che inviano pacchetti progettati per produrre il peggior effetto. Questa supposizione guiderà verso un design di protezione appropriato, sebbene i problemi più gravi di Internet siano causati da meccanismi inaspettati innescati da eventi a bassa probabilità; la semplice malvagità umana non intraprenderebbe mai un percorso così indiretto!
Il software host Internet a tutti i livelli deve essere progettato per l'adattabilità al cambiamento. Un semplice esempio: considera una specifica di protocollo che contiene un'enumerazione dei valori per un particolare campo di intestazione — ad esempio un campo di tipo, un numero di porta o un codice di errore; si deve presumere che tale enumerazione sia incompleta. Pertanto, se la specifica definisce quattro possibili codici di errore, il software non deve mai andare in crash quando appare un quinto codice. I codici non definiti possono essere registrati (vedi sotto), ma non devono causare un guasto.
La seconda parte di questo principio è quasi altrettanto importante: il software su altri host può contenere difetti che rendono saggio non sfruttare caratteristiche di protocollo legittime ma oscure. Discostarsi dall'ovvio e semplice è pericoloso, per timore di causare effetti avversi altrove. La correlazione è "diffida degli host che si comportano male"; il software host non deve solo essere preparato a sopravvivere in presenza di altri host che si comportano male, ma anche cooperare per limitare l'entità dei danni che tali host possono infliggere alla struttura di comunicazione condivisa.
1.2.3 Registrazione errori (Error Logging)
Internet contiene una grande varietà di sistemi host e gateway, ciascuno dei quali implementa molti protocolli e livelli di protocollo, di cui alcuni contengono errori e caratteristiche difettose nel loro software di protocollo Internet. A causa della complessità, diversità e distribuzione delle funzionalità, la diagnosi dei problemi Internet è spesso molto difficile.
Se l'implementazione host include un meccanismo ben progettato per registrare errori o eventi di protocollo "strani", sarà utile per la diagnosi dei problemi. Quando si registrano errori, è importante includere quante più informazioni diagnostiche possibile. In particolare, è spesso utile registrare l'intestazione del pacchetto che ha causato l'errore. Tuttavia, si deve prestare attenzione affinché il registro errori non consumi risorse eccessive o non interferisca altrimenti con il funzionamento dell'host.
Eventi di protocollo anomali ma innocui possono far traboccare il file di registro errori; questo può essere evitato utilizzando un registro "circolare" o abilitando il registro solo durante la diagnosi di guasti noti. Può essere utile filtrare e contare i messaggi consecutivi duplicati. Una strategia che sembra funzionare bene è: (1) contare sempre le condizioni anomale e consentire l'accesso a questi contatori tramite un protocollo di gestione (vedi [INTRO:1]); e (2) consentire di abilitare selettivamente la registrazione di grandi quantità di eventi. Ad esempio, può essere utile poter "registrare tutto" o "registrare tutto dall'host X".
Notare che diversi amministratori possono avere strategie diverse su quanta registrazione errori desiderano generalmente abilitare. Alcuni dicono "finché non mi nuoce, non voglio saperlo", mentre altri preferiscono un atteggiamento più vigile e proattivo per rilevare ed eliminare le anomalie di protocollo.
1.2.4 Configurazione (Configuration)
Sarebbe ideale se l'implementazione host della suite di protocolli Internet fosse completamente autoconfigurabile. Ciò consentirebbe di implementare l'intera famiglia di protocolli in ROM o di masterizzarla nel silicio, semplificare le stazioni di lavoro senza disco e essere una benedizione per gli amministratori LAN indaffarati e i fornitori di sistemi. Non abbiamo ancora raggiunto questo ideale; in effetti, siamo ancora lontani.
In molti punti di questo documento, troverai un requisito secondo cui un determinato parametro deve essere un'opzione configurabile. Ci sono diverse ragioni diverse dietro tali requisiti. In pochi casi, c'è incertezza o disaccordo attuale sul miglior valore e potrebbe essere necessario aggiornare il valore consigliato in futuro. In altri casi, il valore dipende effettivamente da fattori esterni — ad esempio le dimensioni dell'host e la distribuzione del suo carico di comunicazione, o la velocità e la topologia delle reti vicine — e gli algoritmi di autoregolazione non sono disponibili e potrebbero essere insufficienti. In alcuni casi, la configurabilità è richiesta per esigenze di gestione.
Infine, alcune opzioni di configurazione sono necessarie per comunicare con implementazioni di protocollo obsolete o errate, ancora presenti in molti luoghi di Internet, che distribuiscono senza codice sorgente. Affinché un sistema corretto coesista con questi sistemi difettosi, gli amministratori devono spesso "configurare erroneamente" il sistema corretto. Con il ritiro dei sistemi difettosi, questo problema si autocorreggerà gradualmente, ma i fornitori non possono ignorarlo.
Quando diciamo che un parametro deve essere configurabile, non esigiamo che il suo valore sia letto esplicitamente da un file di configurazione a ogni avvio. Consigliamo agli implementatori di fornire un valore predefinito per ogni parametro, cosicché il file di configurazione venga utilizzato solo per sovrascrivere i valori predefiniti inadatti in una particolare installazione. Pertanto, il requisito di configurabilità è una garanzia che il valore predefinito possa essere sostituito se necessario, anche in un prodotto binario o basato su ROM.
Questo documento richiede in alcuni casi che questi valori predefiniti assumano valori specifici. Quando un elemento di configurazione controlla la compatibilità con sistemi difettosi esistenti, la scelta del valore predefinito è una questione sensibile. Affinché Internet converga verso una piena interoperabilità, i valori predefiniti integrati nelle implementazioni devono implementare il protocollo ufficiale, non una "configurazione errata" per accommodare implementazioni difettose. Sebbene considerazioni di mercato abbiano indotto alcuni fornitori a scegliere valori predefiniti configurati erroneamente, esortiamo i fornitori a scegliere valori predefiniti conformi agli standard.
Infine, notiamo che i fornitori devono fornire una documentazione adeguata per tutti i parametri di configurazione, i loro limiti e gli effetti.
1.3 Lettura di questo documento (Reading this Document)
1.3.1 Organizzazione (Organization)
La gerarchia dei protocolli viene generalmente utilizzata come principio di organizzazione per implementare il software di rete e per organizzare questo documento. Nella descrizione delle regole, presumiamo che le implementazioni mappino effettivamente la gerarchia dei protocolli in modo rigoroso. Pertanto, i tre capitoli principali seguenti specificano rispettivamente i requisiti per il livello di collegamento, il livello Internet e il livello di trasporto. Il RFC complementare [INTRO:1] copre il software di livello applicativo. Questa organizzazione gerarchica è stata scelta per semplicità e chiarezza.
Tuttavia, la stratificazione rigorosa è un modello imperfetto sia per la famiglia di protocolli che per il metodo di implementazione raccomandato. I protocolli di diversi livelli interagiscono in modi complessi e a volte sottili e particolari funzionalità coinvolgono spesso più livelli. Ci sono molte scelte di progettazione nelle implementazioni, molte delle quali comportano la rottura creativa della rigorosa stratificazione. Esortiamo ogni implementatore a leggere i riferimenti [INTRO:7] e [INTRO:8].
Questo documento utilizza una notazione funzionale ("chiamata di procedura") per descrivere le interfacce di servizio concettuali tra i livelli, simile a quella utilizzata nella specifica TCP [TCP:1]. Le implementazioni host devono supportare il flusso di informazioni logico implicito da queste chiamate, ma non devono necessariamente implementare letteralmente le chiamate stesse. Molte implementazioni, ad esempio, riflettono l'accoppiamento tra livello di trasporto e livello IP condividendo strutture dati comuni. Tali strutture dati, anziché chiamate di procedura esplicite, diventano il veicolo per trasmettere molte delle informazioni richieste.
In generale, ogni capitolo principale di questo documento è organizzato nelle seguenti sottosezioni:
- Introduzione (Introduction)
- Analisi del protocollo (Protocol Walk-Through) — esamina il documento di specifica del protocollo sezione per sezione, corregge errori, enuncia requisiti che potrebbero essere ambigui o scarsamente definiti e fornisce ulteriori chiarimenti o spiegazioni.
- Problemi specifici (Specific Issues) — discute problemi di progettazione e implementazione del protocollo non inclusi nell'analisi.
- Interfacce (Interfaces) — discute l'interfaccia di servizio verso il livello superiore successivo.
- Riepilogo (Summary) — contiene un riepilogo dei requisiti di questa sezione.
Sotto molti argomenti individuali di questo documento, ci sono materiali annotati "DISCUSSION" o "IMPLEMENTATION". Lo scopo di questi materiali è chiarire e spiegare il testo dei requisiti precedente. Includono inoltre alcuni suggerimenti su possibili direzioni o sviluppi futuri. I materiali di implementazione contengono approcci suggeriti che gli implementatori potrebbero voler considerare.
La sottosezione Riepilogo è destinata a fungere da guida e indice al testo principale, ma è inevitabilmente breve e incompleta. Il riepilogo non deve mai essere utilizzato o citato da solo, separato dall'RFC completo.
1.3.2 Requisiti (Requirements)
In questo documento, le parole utilizzate per definire l'importanza di ciascun requisito specifico sono scritte in maiuscolo. Queste parole sono:
"MUST" (DEVEREBBE)
Questa parola, o l'aggettivo "REQUIRED", indica che l'elemento è un requisito assoluto della norma.
"SHOULD" (DOVREBBE)
Questa parola, o l'aggettivo "RECOMMENDED", indica che potrebbero esserci valide ragioni per ignorare l'elemento in circostanze particolari, ma che tutte le implicazioni devono essere comprese e ponderate attentamente prima di scegliere un approccio diverso.
"MAY" (PUÒ)
Questa parola, o l'aggettivo "OPTIONAL", indica che l'elemento è effettivamente opzionale. Ad esempio, un fornitore potrebbe scegliere di includere l'elemento a causa di un'esigenza di mercato o per migliorare il prodotto; un altro fornitore può omettere lo stesso elemento.
Se un'implementazione non soddisfa uno o più requisiti MUST del protocollo che implementa, l'implementazione non è conforme alla specifica. Un'implementazione che soddisfa tutti i requisiti MUST e SHOULD del suo protocollo è detta "incondizionatamente conforme (unconditionally compliant)"; un'implementazione che soddisfa tutti i requisiti MUST ma non tutti i requisiti SHOULD è detta "condizionalmente conforme (conditionally compliant)".
1.3.3 Terminologia (Terminology)
Questo documento utilizza i seguenti termini tecnici:
Segmento (Segment)
Un segmento è l'unità di trasmissione end-to-end nel protocollo TCP. Un segmento è composto da un'intestazione TCP seguita da dati dell'applicazione. Un segmento viene trasportato venendo incapsulato in un datagramma IP.
Messaggio (Message)
Nella descrizione dei protocolli di livello inferiore, un messaggio è l'unità di trasmissione nel protocollo di trasporto. In particolare, un segmento TCP è un messaggio. Un messaggio è composto da un'intestazione del protocollo di trasporto seguita da dati del protocollo applicativo. Per essere trasportato end-to-end su Internet, un messaggio deve essere incapsulato in un datagramma.
Datagramma IP (IP Datagram)
Un datagramma IP è l'unità di trasmissione end-to-end nel protocollo IP. Un datagramma IP è composto da un'intestazione IP seguita da dati del livello di trasporto, cioè un'intestazione IP seguita da un messaggio.
Nella descrizione del livello Internet (sezione 3), il termine non qualificato "datagramma (datagram)" deve essere inteso come riferito a un datagramma IP.
Pacchetto (Packet)
Un pacchetto è l'unità di dati trasferita attraverso l'interfaccia tra il livello Internet e il livello di collegamento. Contiene un'intestazione IP e dati. Un pacchetto può essere un datagramma IP completo o un frammento di un datagramma IP.
Trama (Frame)
Una trama è l'unità di trasmissione nel protocollo di livello di collegamento ed è composta da un'intestazione di livello di collegamento seguita da un pacchetto.
Rete connessa (Connected Network)
La rete a cui un host è interfacciato è generalmente chiamata "rete locale (local network)" o "sottorete (subnetwork)" rispetto a quell'host. Tuttavia, questi termini possono essere fonte di confusione, quindi in questo documento utilizziamo il termine "rete connessa (connected network)".
Multihomed
Se un host possiede più indirizzi IP, viene detto multihomed. Per una discussione sul multihoming, vedere la sezione 3.3.4.
Interfaccia di rete fisica (Physical network interface)
Questa è l'interfaccia fisica verso la rete connessa e possiede un indirizzo di livello di collegamento (possibilmente unico). Più interfacce di rete fisiche su un singolo host possono condividere lo stesso indirizzo di livello di collegamento, ma tale indirizzo deve essere unico per gli host diversi sulla stessa rete fisica.
Interfaccia [di rete] logica (Logical [network] interface)
Definiamo l'interfaccia [di rete] logica come un percorso logico verso la rete connessa, distinto da un indirizzo IP unico. Vedere la sezione 3.3.4.
Indirizzo di destinazione specifico (Specific-destination address)
Questo è l'indirizzo di destinazione valido del datagramma, anche se si tratta di un indirizzo broadcast o multicast; vedere la sezione 3.2.1.3.
Percorso (Path)
In un dato momento, tutti i datagrammi IP da un particolare host sorgente a un particolare host di destinazione attraverseranno generalmente la stessa sequenza di gateway. Chiamiamo questa sequenza "percorso (Path)". Notare che il percorso è unidirezionale; non è raro avere percorsi diversi nelle due direzioni tra una data coppia di host.
MTU
Maximum Transfer Unit, cioè la dimensione massima del pacchetto che può essere trasmessa.
I termini trama, pacchetto, datagramma, messaggio e segmento sono illustrati dal seguente schema:
A. Trasmissione su una rete connessa:
_______________________________________________
| LL hdr | IP hdr | (data) |
|________|________|_____________________________|
<---------- Frame ----------------------------->
<----------Packet -------------------->
B. Prima della frammentazione IP o dopo il riassemblaggio IP:
______________________________________
| IP hdr | transport| Application Data |
|________|____hdr___|__________________|
<-------- Datagram ------------------>
<-------- Message ----------->
O, per TCP:
______________________________________
| IP hdr | TCP hdr | Application Data |
|________|__________|__________________|
<-------- Datagram ------------------>
<-------- Segment ----------->
1.4 Riconoscimenti (Acknowledgments)
Questo documento incorpora contributi e commenti di un gran numero di esperti di protocolli Internet (inclusi rappresentanti di università e laboratori di ricerca, fornitori e agenzie governative). È stato principalmente compilato dal Host Requirements Working Group dell'IETF (Internet Engineering Task Force).
L'editore desidera ringraziare in particolare le seguenti persone per il loro instancabile impegno, che hanno partecipato a molte lunghe riunioni negli ultimi 18 mesi e hanno prodotto 3 milioni di byte di posta elettronica per realizzare questo documento: Philip Almquist, Dave Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU) e James Van Bokkelen (FTP Software).
Inoltre, le seguenti persone hanno dato contributi significativi a questo lavoro: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology) e Mike StJohns (DCA). Le seguenti persone hanno anche dato contributi importanti in aree specifiche: Eric Allman (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco) e Rayan Zachariassen (Toronto).
Esprimiamo la nostra gratitudine a tutti, inclusi eventuali contributori che potrebbero essere stati omessi involontariamente dall'elenco.