5. Impact of Proposed Changes (Impatto delle modifiche proposte)

Questa sezione discute l'impatto delle modifiche proposte sui dispositivi legacy, sulla generazione dei datagrammi nei dispositivi aggiornati, sui middlebox e sulla compressione delle intestazioni.

5.1. Impact on Legacy Internet Devices (Impatto sui dispositivi Internet legacy)

Gli usi legacy del campo IPv4 ID consistono nella generazione di frammenti, nel riassemblaggio dei frammenti, nel rilevamento dei datagrammi duplicati e in usi "altri".

I dispositivi attuali generano già valori ID che vengono riutilizzati all'interno della tupla indirizzo di origine/indirizzo di destinazione/protocollo in meno della MDL Internet attualmente stimata di due minuti. Essi presuppongono che la MDL sul loro percorso end-to-end sia molto inferiore.

È noto che dispositivi esistenti generino ID non variabili per i datagrammi atomici da quasi un decennio, in particolare alcuni telefoni cellulari. Tali valori ID costanti sono la ragione del loro supporto come ottimizzazione della ROHC [RFC5225]. Questo aspetto è discusso ulteriormente nella Sezione 5.4. La generazione di datagrammi IPv4 con ID costanti (zero) è anche descritta nell'ambito dello standard di traduzione IP/ICMP [RFC6145].

Molti dispositivi attuali supportano la frammentazione che ignora il bit Don't Fragment (DF) di IPv4. Tali dispositivi già transitano traffico proveniente da sorgenti che riutilizzano l'ID. Se frammenti di datagrammi diversi che riutilizzano lo stesso ID (all'interno della tupla indirizzo di origine/indirizzo di destinazione/protocollo) arrivano alla destinazione interlacciati, la frammentazione fallirebbe e il traffico verrebbe scartato. O tale interlacciamento è poco comune, oppure il traffico proveniente da tali dispositivi non attraversa ampiamente questi dispositivi che ignorano il DF, poiché non è stata segnalata una significativa occorrenza di errori di riassemblaggio. I dispositivi che ignorano il DF non sono conformi agli standard esistenti, e non è fattibile aggiornare gli standard per consentirli come conformi.

Il campo ID è stato ipotizzato per l'uso nel rilevamento dei duplicati, come discusso nella Sezione 4.1. Sebbene questo documento ora consenta il riutilizzo dell'IPv4 ID per i datagrammi atomici, tale riutilizzo è già comune (come osservato sopra). È noto che gli acceleratori di protocollo implementino il rilevamento dei duplicati IPv4, ma è anche noto che tali dispositivi violino altri standard Internet per ottenere prestazioni end-to-end più elevate. Questi dispositivi mostrerebbero già scarti errati per questo traffico attuale, e ciò non è stato segnalato.

Esistono altri usi potenziali del campo ID, ad esempio per scopi diagnostici. Tali usi devono già gestire datagrammi atomici con campi ID riutilizzati. Non vi sono segnalazioni di problemi in tali usi con i datagrammi attuali che riutilizzano gli ID.

Pertanto, in conseguenza dei requisiti precedenti, questo documento raccomanda che i meccanismi di rilevamento dei duplicati e diagnostici IPv4 applichino metodi compatibili con IPv6, cioè metodi che non si basano sul campo ID (ad esempio, come suggerito in [RFC6621]). Ciò è una conseguenza dell'uso del campo ID solo per il riassemblaggio, nonché del noto pericolo rappresentato da dispositivi esistenti che già riutilizzano il campo ID.

5.2. Impact on Datagram Generation (Impatto sulla generazione dei datagrammi)

Quella che segue è una sintesi delle raccomandazioni che derivano dalle precedenti modifiche alla specifica del campo IPv4 ID.

Poiché i datagrammi atomici possono utilizzare valori IPv4 ID arbitrari, il campo ID non impone più un impatto sulle prestazioni in quei casi. Tuttavia, l'impatto sulle prestazioni rimane per i datagrammi non atomici. Di conseguenza:

Le sorgenti di datagrammi IPv4 non atomici DEVONO limitare la velocità del proprio output per conformarsi ai requisiti di unicità dell'ID. Tali sorgenti includono, in particolare, il DNS su UDP [RFC2671].

Poiché non esiste una definizione rigorosa della MDL, i pericoli di riassemblaggio esistono indipendentemente dall'intervallo di riutilizzo dell'IPv4 ID o dal timeout di riassemblaggio. Di conseguenza:

I protocolli di livello superiore DOVREBBERO verificare l'integrità dei datagrammi IPv4, ad esempio utilizzando un checksum o un hash in grado di rilevare errori di riassemblaggio (i checksum UDP e TCP sono deboli a questo riguardo, ma meglio di niente).

È possibile impiegare controlli di integrità aggiuntivi utilizzando tunnel, come supportato dal Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320], da IPsec [RFC4301] o dallo Stream Control Transmission Protocol (SCTP) [RFC4960]. Tali controlli possono evitare i pericoli di riassemblaggio che possono verificarsi quando si utilizzano i checksum UDP e TCP [RFC4963] o quando si utilizzano checksum parziali come in UDP-Lite [RFC3828]. Poiché tali controlli di integrità possono evitare l'impatto degli errori di riassemblaggio:

Le sorgenti di datagrammi IPv4 non atomici che utilizzano controlli di integrità forti POSSONO riutilizzare l'ID entro intervalli inferiori ai valori MDL tipici.

Si noti, tuttavia, che un riutilizzo così frequente può comunque comportare un riassemblaggio corrotto e un throughput scarso, sebbene non propaghi errori di riassemblaggio ai protocolli di livello superiore.

5.3. Impact on Middleboxes (Impatto sui middlebox)

I middlebox includono dispositivi di riscrittura come i network address translator (NAT), i network address/port translator (NAPT) e altri meccanismi di condivisione degli indirizzi (ASM). Includono anche dispositivi che ispezionano e filtrano i datagrammi ma che non sono router, come gli acceleratori e i firewall.

Le modifiche proposte in questo documento potrebbero non essere implementate dai middlebox; tuttavia, è più probabile che tali modifiche rendano conforme il comportamento attuale dei middlebox piuttosto che incidere sul servizio fornito da quei dispositivi.

5.3.1. Rewriting Middleboxes (Middlebox di riscrittura)

I NAT e i NAPT riscrivono i campi IP, e gli ingressi dei tunnel (che utilizzano l'incapsulamento IPv4) copiano e modificano alcuni campi IPv4; tutti sono quindi considerati sorgenti di datagrammi, così come qualsiasi dispositivo che riscriva una qualsiasi porzione della tupla indirizzo di origine/indirizzo di destinazione/protocollo/ID per qualsiasi datagramma [RFC3022]. Ciò vale anche per altri ASM, tra cui l'IPv4 Residual Deployment (4rd) [De11], IVI [RFC6219] e altri della famiglia "A+P" (address plus port) [Bo11]. Vale ugualmente per qualsiasi altro meccanismo di riscrittura dei datagrammi. Di conseguenza, sono soggetti a tutti i requisiti di qualsiasi sorgente di datagrammi, come è stato osservato.

I NAT/ASM/riscrittori presentano una situazione particolarmente problematica per la frammentazione. Poiché sovrascrivono porzioni della tupla di riassemblaggio in entrambe le direzioni, possono distruggere l'unicità della tupla e dare luogo a un pericolo di riassemblaggio. Ogni volta che vengono modificati i campi indirizzo di origine, indirizzo di destinazione o protocollo di IPv4, un NAT/ASM/riscrittore deve assicurarsi che il campo ID sia generato in modo appropriato, anziché essere semplicemente copiato dal datagramma in ingresso.

Nello specifico:

I dispositivi di condivisione degli indirizzi o di riscrittura DEVONO garantire che il campo IPv4 ID dei datagrammi i cui indirizzi o protocolli sono tradotti sia conforme a questi requisiti come se il datagramma fosse originato da quel dispositivo.

Tale conformità significa che il campo IPv4 ID dei datagrammi non atomici tradotti presso un NAT/ASM/riscrittore deve rispettare i requisiti di unicità di qualsiasi sorgente di datagrammi IPv4. Sfortunatamente, i frammenti tradotti violano già tale requisito, poiché ripetono un IPv4 ID entro la MDL per una data tupla indirizzo di origine/indirizzo di destinazione/protocollo.

Tali problemi con la trasmissione di frammenti attraverso NAT/ASM/riscrittori sono già noti; la traduzione è tipicamente basata sul numero di porta di trasporto, che comunque è presente solo nel primo frammento [RFC3022]. Questo documento sottolinea il punto che non solo il riassemblaggio (e possibilmente la successiva frammentazione) è necessario per la traduzione, ma può essere utilizzato per evitare problemi con l'unicità dell'IPv4 ID.

Si noti che i NAT/ASM devono già prestare particolare attenzione quando emettono datagrammi sul loro lato pubblico, perché la fusione di datagrammi provenienti da molte sorgenti su un unico indirizzo di origine in uscita può causare collisioni di IPv4 ID. Questa situazione precede questo documento e non è da esso influenzata. È esacerbata nei NAT su larga scala, cosiddetti "carrier grade" [Pe11].

Gli ingressi dei tunnel agiscono come sorgenti per l'intestazione più esterna, ma i tunnel agiscono come router per le intestazioni interne (cioè, il datagramma come arriva all'ingresso del tunnel). Gli ingressi possono sempre frammentare in quanto sorgenti di origine dell'intestazione esterna, perché controllano l'unicità di quel campo IPv4 ID e il valore di DF sull'intestazione esterna indipendentemente da quei valori sull'intestazione interna (del datagramma in arrivo).

5.3.2. Filtering Middleboxes (Middlebox di filtraggio)

I middlebox includono anche dispositivi che filtrano i datagrammi, come gli acceleratori di rete e i firewall. Alcuni di tali dispositivi, secondo quanto riportato, presentano una deduplicazione dei datagrammi che si basa sull'unicità dell'IP ID per identificare i duplicati, come discusso nella Sezione 5.1.

5.4. Impact on Header Compression (Impatto sulla compressione delle intestazioni)

Gli algoritmi di compressione delle intestazioni già gestiscono vari modi in cui l'IPv4 ID cambia tra datagrammi sequenziali [RFC1144] [RFC2508] [RFC3545] [RFC5225]. Tali algoritmi attualmente presuppongono che l'IPv4 ID sia preservato end-to-end. Alcuni algoritmi consentono già di presupporre che l'ID non cambi (ad esempio, ROHC [RFC5225]), mentre altri includono ID non variabili tramite delta zero (ad esempio, Enhanced Compressed RTP (ECRTP) [RFC3545]).

Quando la compressione presuppone un ID variabile come impostazione predefinita, avere un ID non variabile può rendere la compressione meno efficiente. Tali ID non variabili sono stati descritti in varie RFC (ad esempio, la nota 21 di [RFC1144] e cRTP [RFC2508]). Quando la compressione può presupporre un IPv4 ID non variabile -- come con ROHC ed ECRTP -- l'efficienza può aumentare.

5.5. Impact of Network Reordering and Loss (Impatto del riordino e della perdita di rete)

La tolleranza al riordino e alla perdita di rete è una caratteristica fondamentale dell'architettura Internet. Sebbene la maggior parte delle attuali reti IP eviti tali eventi gratuiti, sia il riordino che la perdita possono e continuano a verificarsi. I datagrammi sono già destinati a essere riordinati o persi, e il recupero da tali errori (ove supportato) avviene già a livello di trasporto o a livelli di protocollo superiori.

Il riordino è tipicamente associato a transitori di routing o a flussi suddivisi su più percorsi. La perdita è tipicamente associata a congestione del percorso o a guasto del collegamento (parziale o completo). L'impatto di tali eventi è diverso per i datagrammi atomici e non atomici ed è discusso di seguito. In sintesi, le raccomandazioni di questo documento rendono Internet più robusta al riordino e alla perdita, enfatizzando i requisiti di unicità dell'ID per i datagrammi non atomici e indicando più chiaramente l'impatto di questi requisiti sia sugli endpoint che sui dispositivi di transito dei datagrammi.

5.5.1. Atomic Datagrams Experiencing Reordering or Loss (Datagrammi atomici soggetti a riordino o perdita)

Il riutilizzo dei valori ID non influisce sui datagrammi atomici quando il bit DF è correttamente rispettato, perché il ripristino dell'ordine non dipende dall'intestazione del datagramma. TCP utilizza un numero di sequenza nell'intestazione di trasporto; in alcuni altri protocolli, la sequenza è indicata e ripristinata a livello applicativo.

Quando DF=1 viene ignorato, il riordino o la perdita possono far sì che frammenti di datagrammi diversi vengano interlacciati e quindi riassemblati in modo errato e scartati. Il riutilizzo dei valori ID nei datagrammi atomici, come consentito da questo documento, può comportare una maggiore perdita di datagrammi in tali casi. Situazioni come questa possono già esistere perché esistono dispositivi noti che utilizzano un ID costante per i datagrammi atomici (alcuni telefoni cellulari) ed esistono dispositivi noti che ignorano DF=1, ma non sono stati segnalati livelli elevati di perdita corrispondente. La mancanza di tali segnalazioni indica o una mancanza di riordino o perdita in tali casi, oppure una tolleranza alle perdite risultanti. Se tali problemi venissero segnalati, sarebbe più produttivo affrontare i dispositivi non conformi (che ignorano DF=1), perché non è pratico definire specifiche Internet per tollerare dispositivi che ignorano tali specifiche. È per questo che questo documento sottolinea la necessità di rispettare DF=1, così come la necessità che i dispositivi di transito dei datagrammi mantengano il bit DF come ricevuto (cioè, anziché azzerarlo).

5.5.2. Non-atomic Datagrams Experiencing Reordering or Loss (Datagrammi non atomici soggetti a riordino o perdita)

I datagrammi non atomici si basano sull'unicità del valore ID per tollerare il riordino dei frammenti, in particolare quando frammenti di datagrammi diversi vengono interlacciati a seguito di tale riordino. La perdita di frammenti può comportare il riassemblaggio di frammenti provenienti da datagrammi di origine diversi, motivo per cui il riutilizzo dell'ID nei datagrammi non atomici si basa sulla durata massima del datagramma (frammento), non solo sull'interlacciamento previsto dovuto al riordino.

Questo documento non modifica i requisiti di unicità degli ID nei datagrammi non atomici e quindi non incide sulla loro tolleranza a tale riordino o perdita. Questo documento sottolinea la necessità dell'unicità dell'ID per tutte le sorgenti di datagrammi, inclusi i middlebox che riscrivono; la necessità di limitare la velocità delle sorgenti per garantire l'unicità dell'ID; la necessità di non riutilizzare l'ID per i datagrammi ritrasmessi; e la necessità di utilizzare controlli di integrità di livello superiore per prevenire errori di riassemblaggio -- tutti fattori che determinano una maggiore tolleranza agli eventi di riordino o perdita.