3. The IPv4 ID Field (Il campo IPv4 ID)

IP supporta la frammentazione dei datagrammi, in cui i datagrammi di grandi dimensioni vengono suddivisi in componenti più piccoli per attraversare collegamenti con unità massime di trasmissione (Maximum Transmission Unit, MTU) limitate. I frammenti sono indicati in modi diversi in IPv4 e IPv6:

• In IPv4, i frammenti sono indicati utilizzando quattro campi dell'intestazione di base: Identification (ID), Fragment Offset, il flag "Don't Fragment" (DF) e il flag "More Fragments" (MF) [RFC791].
• In IPv6, i frammenti sono indicati in un'intestazione di estensione che include un ID, Fragment Offset e un flag M (more fragments) simili alle loro controparti in IPv4 [RFC2460].

La frammentazione IPv6 differisce dalla frammentazione IPv4 per alcuni aspetti importanti. La frammentazione IPv6 avviene solo presso la sorgente, quindi non è necessario un bit DF per impedire ai dispositivi a valle di avviare la frammentazione (cioè, IPv6 si comporta sempre come se DF=1). L'intestazione di frammentazione IPv6 è presente solo quando un datagramma è stato frammentato, oppure quando la sorgente ha ricevuto un messaggio di errore ICMPv6 "packet too big" che indica che il percorso non può supportare la MTU IPv6 minima richiesta di 1280 byte ed è quindi soggetto a traduzione [RFC2460] [RFC4443]. Quest'ultimo caso è rilevante solo per i datagrammi IPv6 inviati a destinazioni IPv4 per supportare la frammentazione successiva dopo la traduzione verso IPv4.

Fatta eccezione per questi due casi, il campo ID non è presente per i datagrammi non frammentati; pertanto, ha significato solo per i datagrammi già frammentati o per i datagrammi destinati a essere frammentati nell'ambito della traduzione verso IPv4. Infine, il campo ID IPv6 è di 32 bit ed è richiesto univoco per coppia indirizzo di origine/destinazione per IPv6, mentre per IPv4 è solo di 16 bit ed è richiesto univoco per tupla indirizzo di origine/indirizzo di destinazione/protocollo.

Questo documento si concentra sui problemi del campo IPv4 ID, perché in IPv6 il campo è più grande ed è presente solo nei frammenti.

3.1. Uses of the IPv4 ID Field (Usi del campo IPv4 ID)

Il campo IPv4 ID era originariamente destinato alla frammentazione e al riassemblaggio [RFC791]. All'interno di una data combinazione di indirizzo di origine, indirizzo di destinazione e protocollo, i frammenti di un datagramma originale vengono abbinati in base al loro IPv4 ID. Ciò richiede che gli ID siano univoci all'interno della tupla indirizzo di origine/indirizzo di destinazione/protocollo quando la frammentazione è possibile (ad esempio, DF=0) o quando è già avvenuta (ad esempio, frag_offset>0 o MF=1).

Per il campo IPv4 ID sono stati ipotizzati altri usi. Il campo è stato proposto come mezzo per rilevare e rimuovere i datagrammi duplicati, ad esempio presso router congestionati (come osservato nella Sezione 3.2.1.5 di [RFC1122]) o negli acceleratori di rete. È stato analogamente proposto l'uso presso gli end host per ridurre l'impatto della duplicazione sui protocolli di livello superiore (ad esempio, elaborazione aggiuntiva in TCP o la necessità di soppressione dei duplicati a livello applicativo in UDP). Questo aspetto è discusso ulteriormente nella Sezione 5.1.

Il campo IPv4 ID è utilizzato in alcuni strumenti diagnostici per correlare i datagrammi misurati in varie posizioni lungo un percorso di rete. Ciò è già insufficiente in IPv6 perché i datagrammi non frammentati sono privi di ID, quindi questi strumenti vengono già aggiornati per evitare tale dipendenza dal campo ID. Anche questo aspetto è discusso ulteriormente nella Sezione 5.1.

L'ID deve chiaramente essere univoco (entro la MDL, entro la tupla indirizzo di origine/indirizzo di destinazione/protocollo) per supportare la frammentazione e il riassemblaggio, ma non tutti i datagrammi sono frammentati o consentono la frammentazione. Questo documento depreca gli usi diversi dalla frammentazione, consentendo la ripetizione dell'ID (entro la MDL, entro la tupla indirizzo di origine/indirizzo di destinazione/protocollo) in tali casi.

3.2. Background on IPv4 ID Reassembly Issues (Contesto sui problemi di riassemblaggio dell'IPv4 ID)

Quella che segue è una sintesi dei problemi relativi al riassemblaggio dei frammenti IPv4 in ambienti ad alta velocità, sollevati in precedenza [RFC4963]. Si invita il lettore a consultare la RFC 4963 per una discussione più dettagliata di questi problemi.

Con la dimensione massima del datagramma IPv4 di 64 KB, un campo ID di 16 bit che non si ripete entro 120 secondi significa che l'aggregato di tutte le connessioni TCP di un dato protocollo tra due endpoint IP è limitato a circa 286 Mbps; a una MTU più tipica di 1500 byte, questa velocità scende a 6,4 Mbps [RFC791] [RFC1122] [RFC4963]. Attualmente questo limite si applica a tutti i datagrammi IPv4 all'interno di un singolo protocollo (cioè, il campo protocol di IPv4) tra due indirizzi IP, indipendentemente dal fatto che la frammentazione sia abilitata o inibita e che un datagramma sia frammentato o meno.

IPv6, anche a MTU tipiche, è in grado di raggiungere 18,7 Tbps con la frammentazione tra due endpoint IP come aggregato su tutti i protocolli, grazie al campo ID più grande di 32 bit (e al fatto che il campo next-header di IPv6, equivalente al campo protocol di IPv4, non viene considerato nel differenziare i frammenti). Quando la frammentazione non viene utilizzata, il campo è assente e, in tal caso, le velocità di IPv6 non sono limitate dall'unicità del campo ID.

Si noti inoltre che 120 secondi è solo una stima della MDL. Essa è correlata al timeout di riassemblaggio come limite inferiore e al TCP Maximum Segment Lifetime come limite superiore (entrambi come osservato in [RFC1122]). I ritardi di rete si verificano in altri modi, ad esempio nei collegamenti satellitari, che possono aggiungere secondi di ritardo anche se il Time to Live (TTL) non viene decrementato di una quantità corrispondente. Non esiste quindi alcun meccanismo di applicazione che garantisca lo scarto dei datagrammi più vecchi di 120 secondi.

I dispositivi Internet wireless sono spesso connessi a velocità superiori a 54 Mbps, e i collegamenti cablati da 1 Gbps sono lo standard predefinito da diversi anni. Sebbene molti percorsi di trasporto end-to-end siano limitati dalla congestione, questi dispositivi raggiungono facilmente un throughput a livello applicativo di oltre 100 Mbps sulle LAN (ad esempio, velocità di trasferimento file da disco a disco), e numerose dimostrazioni di throughput con sistemi Commercial-Off-The-Shelf (COTS) su percorsi geograficamente estesi hanno mostrato queste velocità per oltre un decennio. Ciò suggerisce fortemente che l'unicità dell'IPv4 ID sia priva di significato pratico da molto tempo.