Passa al contenuto principale

6. Updates to Existing Standards (Aggiornamenti agli standard esistenti)

Le sezioni seguenti trattano le modifiche specifiche ai protocolli esistenti indicate da questo documento.

6.1. Updates to RFC 791 (Aggiornamenti alla RFC 791)​

La RFC 791 afferma che:

Il modulo di protocollo di origine di un datagramma internet imposta il campo identification a un valore che deve essere univoco per quella coppia sorgente-destinazione e protocollo per il tempo in cui il datagramma sarà attivo nel sistema internet.

In seguito afferma che:

Pertanto, il mittente deve scegliere l'Identifier in modo che sia univoco per questa coppia sorgente, destinazione e protocollo per il tempo in cui il datagramma (o qualsiasi suo frammento) potrebbe essere attivo in internet.

Sembra quindi che un modulo di protocollo mittente debba mantenere una tabella di Identifier, una voce per ogni destinazione con cui ha comunicato nell'ultima durata massima del datagramma per internet.

Tuttavia, poiché il campo Identifier consente 65.536 valori diversi, qualche host potrebbe essere in grado di utilizzare semplicemente identificatori univoci indipendentemente dalla destinazione.

È appropriato che alcuni protocolli di livello superiore scelgano l'identifier. Ad esempio, i moduli del protocollo TCP possono ritrasmettere un segmento TCP identico, e la probabilità di ricezione corretta sarebbe accresciuta se la ritrasmissione portasse lo stesso identifier della trasmissione originale, poiché i frammenti di entrambi i datagrammi potrebbero essere usati per costruire un segmento TCP corretto.

Questo documento modifica la RFC 791 come segue:

  • L'unicità dell'IPv4 ID si applica solo ai datagrammi non atomici.
  • Ai datagrammi IPv4 non atomici ritrasmessi non è più consentito riutilizzare il valore ID.

6.2. Updates to RFC 1122 (Aggiornamenti alla RFC 1122)​

La RFC 1122 afferma nella Sezione 3.2.1.5 ("Identification: RFC 791 Section 3.2") che:

Quando invia una copia identica di un datagramma precedente, un host PUÒ opzionalmente mantenere lo stesso campo Identification nella copia.

DISCUSSIONE:

Alcuni esperti di protocolli Internet hanno sostenuto che quando un host invia una copia identica di un datagramma precedente, la nuova copia dovrebbe contenere lo stesso valore Identification dell'originale. Ci sono due vantaggi suggeriti: (1) se i datagrammi sono frammentati e alcuni dei frammenti vanno persi, il ricevitore potrebbe essere in grado di ricostruire un datagramma completo dai frammenti dell'originale e delle copie; (2) un gateway congestionato potrebbe usare il campo IP Identification (e Fragment Offset) per scartare i datagrammi duplicati dalla coda.

Questo documento modifica la RFC 1122 come segue:

  • Al campo IPv4 ID non è più consentito essere utilizzato per il rilevamento dei duplicati. Ciò vale sia per i datagrammi atomici che per quelli non atomici.
  • Ai datagrammi IPv4 non atomici ritrasmessi non è più consentito riutilizzare il valore ID.

6.3. Updates to RFC 2003 (Aggiornamenti alla RFC 2003)​

Questo documento aggiorna il modo in cui i tunnel IPv4-in-IPv4 creano i valori IPv4 ID per l'intestazione esterna IPv4 [RFC2003], ma solo allo stesso modo di qualsiasi altra sorgente di datagrammi IPv4. Nello specifico, la RFC 2003 afferma quanto segue, dove [10] si riferisce alla RFC 791:

Identification, Flags, Fragment Offset

Questi tre campi sono impostati come specificato in [10]...

Questo documento modifica la RFC 2003 come segue:

  • Il campo IPv4 ID è impostato come consentito dalla RFC 6864.