1. Introduzione

L'IETF ha specificato il trasporto datagramma utilizzando UDP, Stream Control Transmission Protocol (SCTP) e Datagram Congestion Control Protocol (DCCP), nonché protocolli stratificati sopra questi trasporti (ad esempio, SCTP/UDP, DCCP/UDP, QUIC/UDP) e trasporto datagramma diretto sul livello di rete IP. Questo documento descrive un metodo robusto per la scoperta del MTU di percorso (Path MTU Discovery, PMTUD) che può essere utilizzato con questi protocolli di trasporto (o le applicazioni che utilizzano il loro servizio di trasporto) per scoprire una dimensione appropriata di pacchetto da utilizzare su un percorso Internet.

1.1. Scoperta classica del MTU di percorso (Classical Path MTU Discovery)

La scoperta classica dell'unità di trasmissione massima di percorso (Classical Path Maximum Transmission Unit Discovery, PMTUD) può essere utilizzata con qualsiasi trasporto in grado di elaborare messaggi ICMP Packet Too Big (PTB) (ad esempio, [RFC1191] e [RFC8201]). In questo documento, il termine messaggio PTB si applica sia ai messaggi ICMP Unreachable IPv4 (Tipo 3) che trasportano l'errore Fragmentation Needed (Tipo 3, Codice 4) [RFC0792] sia ai messaggi ICMPv6 Packet Too Big (Tipo 2) [RFC4443]. Quando un mittente riceve un messaggio PTB, riduce l'MTU effettivo al valore segnalato come MTU di collegamento nel messaggio PTB. Il PMTUD classico specifica un metodo di aumento periodico della dimensione del pacchetto nel tentativo di scoprire un aumento del PMTU supportato. I pacchetti inviati con una dimensione maggiore dell'attuale PMTU effettivo sono noti come pacchetti di sondaggio.

I pacchetti non destinati a essere pacchetti di sondaggio sono frammentati all'attuale PMTU effettivo, oppure il tentativo di invio fallisce con un codice di errore. Le applicazioni possono ricevere una primitiva che consente loro di leggere la dimensione massima del pacchetto (Maximum Packet Size, MPS), che è derivata dall'attuale PMTU effettivo.

Il PMTUD classico è soggetto a guasti del protocollo. Un guasto si verifica quando il traffico che utilizza una dimensione del pacchetto maggiore del PMTU effettivo viene messo in black hole (tutti i datagrammi più grandi del PMTU effettivo vengono scartati). Questo può verificarsi quando i messaggi PTB non vengono rinviati al mittente per qualche ragione (ad esempio, vedere [RFC2923]).

Gli esempi di casi in cui i messaggi PTB non vengono consegnati includono i seguenti:

• La generazione di messaggi ICMP è solitamente limitata in velocità. Questo potrebbe risultare in nessun messaggio PTB generato per il mittente (vedere [RFC4443] Sezione 2.4).

• I messaggi ICMP possono essere filtrati da middlebox, inclusi firewall [RFC4890]. Un firewall potrebbe essere configurato con una policy per bloccare i messaggi ICMP in ingresso, che impedirebbe la ricezione di messaggi PTB da parte di un endpoint mittente dietro questo firewall.

• Quando il router che emette il messaggio ICMP scarta un pacchetto tunnelizzato, il messaggio ICMP risultante viene diretto all'ingresso del tunnel. Questo endpoint del tunnel è responsabile dell'inoltro del messaggio ICMP, dell'elaborazione del pacchetto citato nel campo del payload per rimuovere l'effetto del tunnel e della restituzione di un messaggio ICMP formattato correttamente al mittente [TUNNELS]. Il mancato adempimento di ciò impedisce al messaggio PTB di raggiungere il mittente originale.

• L'asimmetria nell'inoltro può risultare nell'assenza di un percorso di ritorno al mittente originale, che impedirebbe la consegna di un messaggio ICMP al mittente. Questo problema può verificarsi anche quando viene utilizzato il routing basato su policy o il routing multipath a costo uguale (Equal-Cost Multipath, ECMP), o quando un middlebox funge da bilanciatore di carico dell'applicazione. Un esempio è un router ECMP che sceglie un percorso verso il server in base ai byte nel payload IP. In questo caso, se un pacchetto inviato dal server incontra un problema dopo il router ECMP, allora il router ECMP deve dirigere qualsiasi messaggio ICMP risultante verso il mittente originale.

• Ci sono casi aggiuntivi in cui la destinazione del prossimo hop non riesce a ricevere un pacchetto a causa della sua dimensione. Questo potrebbe essere dovuto a una configurazione errata del percorso di livello 2 tra i nodi, ad esempio l'MTU configurato in uno switch di livello 2, o una configurazione errata dell'unità di ricezione massima (Maximum Receive Unit, MRU). Se un pacchetto viene scartato dal collegamento, ciò non causerà l'invio di un messaggio PTB al mittente originale.

Un altro guasto potrebbe verificarsi se un nodo che non è sul percorso di rete invia un messaggio PTB che tenta di forzare un mittente a modificare il PMTU effettivo [RFC8201]. Un mittente può proteggersi dalla reazione a tali messaggi utilizzando il pacchetto citato all'interno di un payload di messaggio PTB per validare che il messaggio PTB ricevuto è stato generato in risposta a un pacchetto che aveva effettivamente avuto origine dal mittente. Tuttavia, ci sono situazioni in cui un mittente non sarebbe in grado di fornire questa validazione.

Gli esempi in cui la validazione del messaggio PTB non è possibile includono i seguenti:

• Quando un router che emette il messaggio ICMP implementa RFC 792 [RFC0792], è tenuto solo a includere i primi 64 bit del payload IP del pacchetto nel payload citato. Potrebbero non rimanere byte sufficienti per consentire al mittente di interpretare le informazioni di trasporto citate.

  Nota: La raccomandazione in RFC 1812 [RFC1812] è che i router IPv4 restituiscano un pacchetto citato con quanto più del datagramma originale possibile senza che la lunghezza del datagramma ICMP superi i 576 byte. I router IPv6 includono quanto più del pacchetto invocante possibile senza che il pacchetto ICMPv6 superi i 1280 byte [RFC4443].

• L'uso di tunnel e/o crittografia può ridurre la dimensione del pacchetto citato restituito all'indirizzo sorgente originale, aumentando il rischio che non rimangano byte sufficienti per consentire al mittente di interpretare le informazioni di trasporto citate.

• Anche quando il messaggio PTB include byte sufficienti del pacchetto citato, il livello di rete potrebbe mancare di contesto sufficiente per validare il messaggio perché la validazione dipende dalle informazioni sui flussi di trasporto attivi presso un nodo endpoint (ad esempio, le coppie socket/indirizzo utilizzate e altre informazioni di intestazione del protocollo).

• Quando un pacchetto è incapsulato/tunnelizzato su un trasporto crittografato, l'ingresso del tunnel/incapsulamento potrebbe non avere contesto sufficiente o potenza di calcolo per ricostruire l'intestazione di trasporto che sarebbe necessaria per eseguire la validazione.

• Quando un messaggio ICMP viene generato da un router in un segmento di rete che ha inserito un'intestazione in un pacchetto, il pacchetto citato potrebbe contenere informazioni di intestazione del protocollo aggiuntive che non erano incluse nel pacchetto inviato originale e che il mittente PL non elabora o potrebbe non sapere come elaborare. Ciò potrebbe disturbare la capacità del mittente di validare questo messaggio PTB.

• Un dispositivo di traduzione degli indirizzi di rete (Network Address Translation, NAT) che traduce un'intestazione di pacchetto dovrebbe anche tradurre i messaggi ICMP e aggiornare il pacchetto citato ICMP [RFC5508] in quel messaggio. Se questo non viene tradotto correttamente, il mittente non sarebbe in grado di associare il messaggio con il PL che ha originato il pacchetto, e quindi questo messaggio ICMP non può essere validato.

1.2. Scoperta del MTU di percorso del livello di pacchettizzazione (Packetization Layer Path MTU Discovery)

Il termine livello di pacchettizzazione (Packetization Layer, PL) è stato introdotto per descrivere il livello responsabile del posizionamento di blocchi di dati nel payload di pacchetti IP e della selezione di un MPS appropriato. Questa funzione è spesso eseguita da un protocollo di trasporto (ad esempio, DCCP, RTP, SCTP, QUIC) ma può anche essere eseguita da altri metodi di incapsulamento che operano sopra il livello di trasporto.

A differenza del PMTUD, la scoperta del MTU di percorso del livello di pacchettizzazione (Packetization Layer Path MTU Discovery, PLPMTUD) [RFC4821] introduce un metodo che non si basa sulla ricezione e validazione dei messaggi PTB. È quindi più robusto del PMTUD classico. Questo è diventato l'approccio raccomandato per implementare la scoperta del PMTU [BCP145].

Questo documento aggiorna [RFC4821] per specificare il metodo PLPMTUD per i PL di datagramma e aggiorna anche [BCP145] per fare riferimento al metodo specificato in questo documento per l'uso con datagrammi UDP invece del metodo in [RFC4821].

Utilizza una strategia generale in cui il PL invia pacchetti di sondaggio per cercare la dimensione più grande di datagramma non frammentato che può essere inviato su un percorso di rete. I pacchetti di sondaggio vengono inviati per esplorare utilizzando una dimensione di pacchetto maggiore. Se un pacchetto di sondaggio viene consegnato con successo (come determinato dal PL), allora il PLPMTU viene aumentato alla dimensione del sondaggio riuscito. Se viene rilevato un black hole (ad esempio, dove pacchetti di dimensione PLPMTU non vengono ricevuti in modo coerente), il metodo riduce il PLPMTU.

Il PLPMTUD di datagramma introduce flessibilità nell'implementazione. A un estremo, può essere configurato per eseguire solo il rilevamento e il recupero del black hole con maggiore robustezza rispetto al PMTUD classico. All'altro estremo, tutta l'elaborazione PTB può essere disabilitata e PLPMTUD sostituisce il PMTUD classico.

PLPMTUD può anche includere controlli di coerenza aggiuntivi senza aumentare il rischio che i dati vengano persi durante il sondaggio per scoprire il MTU di percorso. Ad esempio, le informazioni disponibili al PL, o ai livelli superiori, consentono di validare i messaggi PTB ricevuti prima di essere utilizzati.

1.3. Scoperta del MTU di percorso per servizi di datagramma (Path MTU Discovery for Datagram Services)

La Sezione 5 di questo documento presenta un insieme di algoritmi per i protocolli di datagramma per scoprire la dimensione più grande di datagramma non frammentato che può essere inviato su un percorso di rete. Il metodo si basa sulle caratteristiche del PL descritte nella Sezione 3 e si applica ai protocolli di trasporto che operano su IPv4 e IPv6. Non richiede la cooperazione dai livelli inferiori, sebbene possa utilizzare i messaggi PTB quando questi messaggi ricevuti vengono resi disponibili al PL.

Le linee guida sulla dimensione del messaggio nella Sezione 3.2 delle linee guida sull'uso di UDP [BCP145] affermano che «un'applicazione DOVREBBE utilizzare le informazioni sul MTU di percorso fornite dal livello IP o implementare la scoperta del MTU di percorso (PMTUD)» ma non forniscono un meccanismo per scoprire la dimensione più grande di datagramma non frammentato che può essere utilizzato su un percorso di rete. Il presente documento aggiorna RFC 8085 per specificare questo metodo al posto di PLPMTUD [RFC4821] e fornisce un meccanismo per condividere la dimensione più grande scoperta come MPS (vedere Sezione 4.4).

La Sezione 10.2 di [RFC4821] raccomandava un metodo di sondaggio PLPMTUD per il protocollo di controllo di trasmissione in flusso (Stream Control Transport Protocol, SCTP). SCTP utilizza pacchetti di sondaggio composti da un chunk HEARTBEAT di dimensioni minime raggruppato con un chunk PAD come definito in [RFC4820]. Tuttavia, RFC 4821 non forniva una specifica completa. Il presente documento sostituisce quella descrizione fornendo una specifica completa.

Il protocollo di controllo della congestione del datagramma (Datagram Congestion Control Protocol, DCCP) [RFC4340] richiede che le implementazioni supportino il PMTUD classico e afferma che un mittente DCCP «DEVE mantenere l'MPS consentito per ogni sessione DCCP attiva». Definisce anche l'MPS di controllo della congestione corrente (Current Congestion Control MPS, CCMPS) supportato da un percorso di rete. Questo raccomanda l'uso di PMTUD e suggerisce l'uso di pacchetti di controllo (DCCP-Sync) come pacchetti di sondaggio del percorso perché non rischiano la perdita di dati dell'applicazione. Il metodo definito in questa specifica può essere utilizzato con DCCP.

La Sezione 4 e la Sezione 5 definiscono i meccanismi del protocollo e la specifica per la scoperta del MTU di percorso del livello di pacchettizzazione di datagramma (Datagram Packetization Layer Path MTU Discovery, DPLPMTUD).

La Sezione 6 specifica il metodo per i trasporti di datagramma e fornisce informazioni per consentire l'implementazione di PLPMTUD con altri trasporti di datagramma e applicazioni che utilizzano trasporti di datagramma.

La Sezione 6 fornisce anche raccomandazioni per gli endpoint SCTP, aggiornando [RFC4960], [RFC6951] e [RFC8261] per utilizzare il metodo specificato in questo documento invece del metodo in [RFC4821].