Passa al contenuto principale

References (Riferimenti)

[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.

[ICMPv6] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.

[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.

[RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.

[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html

[RFC-1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

CHANGES SINCE RFC-1883 (Modifiche rispetto a RFC 1883)​

Questo memo include le seguenti modifiche rispetto a RFC 1883. I numeri identificano la versione Internet-Draft in cui la modifica è stata apportata.

02) Rimossi tutti i riferimenti ai jumbograms e alla Jumbo Payload option, spostati in un documento separato.

02) Spostata gran parte della descrizione di Flow Label dalla Sezione 6 alla nuova Appendice A.

02) Nella descrizione di Flow Label, ora nell'Appendice A, corretto il valore massimo di Flow Label da FFFFFF a FFFFF, cioè con una "F" in meno, dato che la dimensione del campo Flow Label è stata ridotta da 24 bit a 20 bit.

02) Rinumerata, o rinominata, la precedente Appendice A come Appendice B.

02) Modificato il testo della sezione Security Considerations per evitare una dipendenza circolare tra questa specifica e le specifiche IPsec.

02) Aggiornati l'indirizzo email e l'affiliazione aziendale di R. Hinden.

01) Nella Sezione 3, cambiato il nome del campo da "Class" a "Traffic Class" e aumentata la sua dimensione da 4 bit a 8 bit. La dimensione del campo Flow Label è stata ridotta da 24 bit a 20 bit per compensare l'aumento del campo Traffic Class.

01) Nella Sezione 4.1, ripristinato l'ordine di Authentication Header ed ESP header, che era stato scambiato erroneamente nella versione 00 di questo memo.

01) Nella Sezione 4.4, rimossi il campo Strict/Loose Bit Map e la funzionalità di routing stretto dalla Type 0 Routing header, e rimossa la limitazione sul numero di indirizzi che può essere trasportato in una Type 0 Routing header, precedentemente limitato a 23 indirizzi a causa della dimensione della bitmap strict/loose.

01) Nella Sezione 5, cambiata la MTU minima IPv6 da 576 ottetti a 1280 ottetti, e aggiunta la raccomandazione di configurare i link con MTU configurabile, ad esempio i link PPP, con una MTU di almeno 1500 ottetti.

01) Nella Sezione 5, rimosso il requisito secondo cui un nodo non deve inviare pacchetti frammentati che dopo il riassemblaggio superino 1500 ottetti senza conoscere la dimensione del buffer di riassemblaggio della destinazione, sostituendolo con una raccomandazione secondo cui i protocolli o le applicazioni di livello superiore non dovrebbero farlo.

01) Sostituito il riferimento alla specifica IPv4 Path MTU Discovery, RFC 1191, con un riferimento alla specifica IPv6 Path MTU Discovery, RFC 1981, e rimossa la nota su Path MTU Discovery alla fine della Sezione 5, poiché tali dettagli sono ora coperti da RFC 1981.

01) Nella Sezione 6, rimossa la specifica della creazione "opportunistic (opportunistica)" dei flussi e rimossi tutti i riferimenti alla durata massima di 6 secondi dello stato dei flussi creati opportunisticamente.

01) Nella Sezione 7, rimossa la descrizione provvisoria della struttura interna e della semantica del campo Traffic Class, e specificato che tale descrizione sarà fornita in documenti separati.

00) Nella Sezione 4, corretto il valore Code del messaggio ICMP Parameter Problem che indica "unrecognized Next Header type encountered (tipo di Next Header non riconosciuto)", cambiandolo da 2 a 1.

00) Nella descrizione del campo Payload Length nella Sezione 3 e nella descrizione del campo Jumbo Payload Length nella Sezione 4.3, chiarito che le intestazioni di estensione sono incluse nel conteggio della lunghezza del payload.

00) Nella Sezione 4.1, scambiato l'ordine di Authentication header ed ESP header. Nota: questo era un errore, e la modifica è stata annullata nella versione 01.

00) Nella Sezione 4.2, chiarito che un'opzione è identificata dall'intero Option Type a 8 bit, non dai 5 bit meno significativi di Option Type. Inoltre, specificato che Hop-by-Hop Options e Destination Options headers usano lo stesso spazio di numerazione Option Type.

00) Nella Sezione 4.4, aggiunta una frase che richiede a un nodo che elabora una Routing header di inviare un messaggio ICMP Packet Too Big in risposta a un pacchetto troppo grande per il link di next hop, invece, ad esempio, di eseguire la frammentazione.

00) Cambiato il nome del campo IPv6 Priority in "Class" e sostituita la precedente descrizione di Priority nella Sezione 7 con una descrizione del campo Class. Inoltre, escluso tale campo dall'insieme dei campi che, secondo la Sezione 6, devono rimanere uguali per tutti i pacchetti dello stesso flusso.

00) Nella pseudo-intestazione della Sezione 8.1, cambiato il nome del campo "Payload Length" in "Upper-Layer Packet Length". Inoltre, chiarito che, per i protocolli che trasportano le proprie informazioni di lunghezza, come UDP non jumbogram, nella pseudo-intestazione viene usata la lunghezza derivata dal livello superiore, non quella derivata dal livello IP.

00) Aggiunta la Sezione 8.4, che specifica che i protocolli di livello superiore non devono includere nei pacchetti di risposta l'inverso della Routing header ricevuta quando rispondono a un pacchetto ricevuto che trasporta una Routing header, a meno che la Routing header ricevuta sia stata autenticata.

00) Corretti alcuni errori di ortografia e grammatica.

00) Aggiornate le informazioni di contatto degli autori.

Copyright (C) The Internet Society (1998). All Rights Reserved.

Questo documento e le sue traduzioni possono essere copiati e forniti ad altri, e possono essere preparate, copiate, pubblicate e distribuite opere derivate che commentano o spiegano il documento o assistono nella sua implementazione, in tutto o in parte, senza alcuna restrizione, a condizione che l'avviso di copyright sopra riportato e questo paragrafo siano inclusi in tutte tali copie e opere derivate. Tuttavia, questo documento stesso non può essere modificato in alcun modo, ad esempio rimuovendo l'avviso di copyright o i riferimenti a Internet Society o ad altre organizzazioni Internet, salvo quanto necessario allo scopo di sviluppare standard Internet, nel qual caso devono essere seguite le procedure di copyright definite nel processo degli standard Internet, oppure secondo quanto necessario per tradurlo in lingue diverse dall'inglese.

Le autorizzazioni limitate concesse sopra sono perpetue e non saranno revocate da Internet Society o dai suoi successori o aventi causa.

Questo documento e le informazioni in esso contenute sono forniti su base "AS IS (così come sono)", e THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE declinano ogni garanzia, espressa o implicita, incluse, ma non limitate a, qualsiasi garanzia che l'uso delle informazioni qui contenute non violi alcun diritto o qualsiasi garanzia implicita di commerciabilità o idoneità a uno scopo particolare.

Ultimo aggiornamento il