4. Updates to the IPv4 ID Specification (Aggiornamenti alla specifica IPv4 ID)
Questo documento aggiorna la specifica del campo IPv4 ID in tre modi distinti, come discusso nelle sottosezioni successive:
- Utilizzo del campo IPv4 ID solo per la frammentazione
- Incoraggiamento di un funzionamento sicuro quando il campo IPv4 ID viene utilizzato
- Evitare un impatto sulle prestazioni quando il campo IPv4 ID viene utilizzato
Esistono due tipi di datagrammi, definiti di seguito e utilizzati nella discussione che segue:
- I datagrammi atomici sono datagrammi non ancora frammentati e per i quali è stata inibita un'ulteriore frammentazione.
- I datagrammi non atomici sono datagrammi che sono già stati frammentati oppure per i quali la frammentazione rimane possibile.
Questa stessa definizione può essere espressa in pseudo codice, utilizzando i comuni operatori logici (uguale è ==, 'and' logico è &&, 'or' logico è ||, maggiore di è >, e la funzione parentesi è usata tipicamente) come segue:
- Datagrammi atomici: (DF==1)&&(MF==0)&&(frag_offset==0)
- Datagrammi non atomici: (DF==0)||(MF==1)||(frag_offset>0)
Il test per i datagrammi non atomici è la negazione logica del test per i datagrammi atomici; pertanto, tutte le possibilità sono considerate.
4.1. IPv4 ID Used Only for Fragmentation (IPv4 ID usato solo per la frammentazione)
Sebbene la RFC 1122 suggerisca che il campo IPv4 ID abbia altri usi, inclusa la deduplicazione dei datagrammi, tali usi non sono già interoperabili con implementazioni note di sorgenti che non variano il proprio ID. Questo documento definisce quindi il valore di questo campo solo per la frammentazione e il riassemblaggio:
Il campo IPv4 ID NON DEVE essere utilizzato per scopi diversi dalla frammentazione e dal riassemblaggio.
La deduplicazione dei datagrammi può comunque essere realizzata utilizzando il rilevamento dei duplicati basato su hash nei casi in cui il campo ID è assente (datagrammi IPv6 non frammentati), approccio che può essere applicato anche ai datagrammi atomici IPv4 senza utilizzare il campo ID [RFC6621].
Nei datagrammi atomici, il campo IPv4 ID non ha significato; pertanto, può essere impostato a un valore arbitrario, cioè il requisito di ID non ripetuti all'interno della tupla indirizzo di origine/indirizzo di destinazione/protocollo non è più richiesto per i datagrammi atomici:
Le sorgenti di origine POSSONO impostare il campo IPv4 ID dei datagrammi atomici a qualsiasi valore.
In secondo luogo, tutti i nodi di rete, siano essi router intermedi, host di destinazione o altri dispositivi (ad esempio, NAT e altri meccanismi di condivisione degli indirizzi, firewall, ingressi dei tunnel), non possono fare affidamento sul campo dei datagrammi atomici:
Tutti i dispositivi che esaminano le intestazioni IPv4 DEVONO ignorare il campo IPv4 ID dei datagrammi atomici.
Il campo IPv4 ID è quindi significativo solo per i datagrammi non atomici -- vale a dire quei datagrammi che sono già stati frammentati o quelli per i quali la frammentazione rimane consentita. I datagrammi atomici vengono rilevati tramite i loro campi DF, MF e fragmentation offset come spiegato nella Sezione 4, perché tale test è completamente retrocompatibile; pertanto, questo documento non riserva alcun valore IPv4 ID, incluso 0, come distinto.
Deprecare l'uso del campo IPv4 ID per usi diversi dal riassemblaggio dovrebbe avere un impatto minimo -- se non nullo. Gli IPv4 ID sono già frequentemente ripetuti, ad esempio su connessioni anche solo moderatamente veloci e da alcune sorgenti che non variano affatto l'ID, e non è stato osservato alcun impatto negativo. La soppressione dei duplicati è stata suggerita [RFC1122] ed è stata implementata in alcuni acceleratori di protocollo, ma a oggi non sono stati rilevati impatti derivanti dal riutilizzo dell'IPv4 ID. I router non sono tenuti a emettere ICMP su una particolare scala temporale, quindi la ripetizione dell'IPv4 ID non avrebbe dovuto essere usata a fini di validazione; questo scenario non è stato osservato. Inoltre, la ripetizione avviene già e sarebbe stata notata [RFC1812]. L'inoltro ICMP presso gli ingressi dei tunnel è specificato per utilizzare soft state anziché una cache dei datagrammi; per ragioni simili, se quest'ultima fosse utilizzata, ciò sarebbe stato notato [RFC2003]. Questi e altri problemi legacy sono discussi ulteriormente nella Sezione 5.1.
4.2. Encouraging Safe IPv4 ID Use (Incoraggiare un uso sicuro dell'IPv4 ID)
Questo documento modifica inoltre la specifica del campo IPv4 ID per incoraggiarne un uso sicuro.
Come discusso nella RFC 1122, se TCP ritrasmette un segmento, può essere possibile riutilizzare l'IPv4 ID (vedere la Sezione 6.2). Ciò può rendere difficile per una sorgente evitare la ripetizione dell'IPv4 ID per i frammenti ricevuti. La RFC 1122 conclude che questo comportamento "non è utile"; questo documento formalizza tale conclusione come segue:
L'IPv4 ID dei datagrammi non atomici NON DEVE essere riutilizzato quando si invia una copia di un datagramma non atomico precedente.
La RFC 1122 suggerisce inoltre che i frammenti possono sovrapporsi. Tale sovrapposizione può verificarsi se ritrasmissioni successive vengono frammentate in modi diversi ma con lo stesso IPv4 ID di riassemblaggio. Questa sovrapposizione è indicata come il risultato del riutilizzo degli IPv4 ID durante la ritrasmissione dei datagrammi, cosa che questo documento depreca. Tuttavia, è anche il risultato della duplicazione dei datagrammi all'interno della rete, che può ancora verificarsi. Di conseguenza, questo documento non modifica la necessità che i ricevitori supportino i frammenti sovrapposti.
4.3. IPv4 ID Requirements That Persist (Requisiti IPv4 ID che persistono)
Questo documento non allenta i requisiti di unicità del campo IPv4 ID di [RFC791] per i datagrammi non atomici, vale a dire:
Le sorgenti che emettono datagrammi non atomici NON DEVONO ripetere i valori IPv4 ID entro una MDL per una data tupla indirizzo di origine/indirizzo di destinazione/protocollo.
Tali sorgenti includono host di origine, ingressi di tunnel e NAT (inclusi altri meccanismi di condivisione degli indirizzi) (vedere la Sezione 5.3).
Questo documento non allenta il requisito che tutti i dispositivi di rete rispettino il bit DF, vale a dire:
I datagrammi IPv4 con DF=1 NON DEVONO essere frammentati.
I dispositivi di transito dei datagrammi IPv4 NON DEVONO azzerare il bit DF.
Nello specifico, DF=1 impedisce la frammentazione dei datagrammi atomici. DF=1 impedisce inoltre l'ulteriore frammentazione dei frammenti ricevuti. La frammentazione all'interno della rete è consentita solo quando DF=0; questo documento non modifica tale requisito.