4. Meccanismi DPLPMTUD

Questa sezione elenca i meccanismi di protocollo utilizzati in questa specifica.

4.1. Pacchetti di sondaggio PLPMTU

Il metodo DPLPMTUD si basa sulla capacità del mittente PL di generare pacchetti di sondaggio con una dimensione specifica. TCP è in grado di generare questi pacchetti di sondaggio scegliendo un segmento appropriato di dati inviati [RFC4821]. Al contrario, un PL di datagramma che costruisce un pacchetto di sondaggio deve richiedere all'applicazione di inviare un blocco di dati più grande di quello generato dall'applicazione oppure utilizzare funzioni di riempimento per estendere un datagramma oltre la dimensione del blocco di dati dell'applicazione. I protocolli che consentono lo scambio di messaggi di controllo (senza un blocco di dati dell'applicazione) possono generare un pacchetto di sondaggio estendendo un messaggio di controllo con dati di riempimento. La dimensione totale di un pacchetto di sondaggio include tutte le intestazioni e il riempimento aggiunti ai dati di payload inviati (ad esempio, inclusi campi di opzione del protocollo, campi relativi alla sicurezza come un tag AEAD e riempimento del livello record TLS).

RICHIESTO: Il ricevitore deve essere in grado di distinguere tra blocchi di dati in banda e qualsiasi riempimento aggiunto. Questo è necessario per garantire che qualsiasi riempimento aggiunto non venga passato all'applicazione ricevente.

Tre metodi per creare pacchetti di sondaggio

1. Sondaggio utilizzando dati di riempimento

Un pacchetto di sondaggio che contiene solo informazioni di controllo insieme a qualsiasi riempimento necessario per gonfiare la lunghezza del datagramma alla dimensione del pacchetto di sondaggio. Poiché questi pacchetti di sondaggio non trasportano un blocco di dati fornito dall'applicazione, non richiedono tipicamente ritrasmissione, sebbene consumino comunque capacità di rete e comportino elaborazione dell'endpoint.

2. Sondaggio utilizzando dati dell'applicazione e dati di riempimento

Un pacchetto di sondaggio che contiene un blocco di dati fornito da un'applicazione che è combinato con riempimento per gonfiare la lunghezza del datagramma alla dimensione del pacchetto di sondaggio.

3. Sondaggio utilizzando dati dell'applicazione

Un pacchetto di sondaggio che contiene un blocco di dati fornito da un'applicazione che corrisponde alla dimensione di un pacchetto di sondaggio. Questo metodo richiede all'applicazione di emettere un blocco di dati della dimensione di sondaggio desiderata.

Protezione dei pacchetti di sondaggio

I PL che utilizzano pacchetti di sondaggio che trasportano dati dell'applicazione che devono essere resilienti alla perdita di questo pacchetto di sondaggio possono eseguire ritrasmissione/riparazione del livello di trasporto del blocco di dati (ad esempio, tramite ritrasmissione dopo il rilevamento della perdita o duplicando il blocco di dati in un datagramma senza i dati di riempimento). Questo blocco di dati ritrasmesso potrebbe dover essere inviato utilizzando un PLPMTU più piccolo, il che potrebbe forzare il PL a utilizzare una dimensione di pacchetto più piccola per attraversare il percorso end-to-end (Questo potrebbe utilizzare la frammentazione del livello di rete dell'endpoint o potrebbe segmentare il blocco di dati in più datagrammi tramite un PL).

DPLPMTUD PUÒ scegliere di utilizzare solo uno di questi metodi per semplificare l'implementazione.

Identificazione dei pacchetti di sondaggio

I messaggi di sondaggio inviati dal PL DEVONO contenere informazioni sufficienti per identificare in modo univoco il sondaggio entro la durata massima del segmento (ad esempio, incluso un identificatore univoco dal PL o dall'implementazione DPLPMTUD) ed essere robusti al riordino e alla riproduzione delle risposte di sondaggio e dei messaggi PTB.

4.2. Conferma della dimensione del pacchetto sondato

Il PL necessita di un metodo per determinare (confermare) quando un pacchetto di sondaggio è stato ricevuto con successo end-to-end attraverso un percorso di rete.

I protocolli di trasporto possono includere metodi end-to-end che rilevano e segnalano la ricezione di datagrammi specifici che inviano (ad esempio, DCCP, SCTP e QUIC forniscono funzioni di keep-alive/heartbeat). Quando supportato, questo meccanismo PUÒ anche essere utilizzato da DPLPMTUD per confermare la ricezione di un pacchetto di sondaggio.

I PL che non confermano la ricezione dei dati (ad esempio, UDP e UDP-Lite) non sono in grado da soli di rilevare quando un pacchetto che inviano è stato scartato perché la sua dimensione è maggiore del PMTU effettivo. Questi PL devono fare affidamento su un protocollo dell'applicazione per rilevare questa perdita.

Sezione 6 specifica questa funzione per un insieme di protocolli specificati dall'IETF.

4.3. Rilevamento del buco nero e riduzione del PLPMTU

La descrizione seguente utilizza l'insieme di costanti definite nella Sezione 5.1.2 e le variabili definite nella Sezione 5.1.3.

Il rilevamento del buco nero è attivato da un'indicazione che il percorso di rete potrebbe essere incapace di supportare la dimensione PLPMTU corrente.

Tre indicatori di rilevamento del buco nero

1. Indicazione del messaggio PTB

Un messaggio PTB validato può essere ricevuto che indica un PL_PTB_SIZE inferiore al PLPMTU corrente. Il metodo DPLPMTUD NON DEVE fare affidamento esclusivamente su questo metodo.

2. Sondaggio periodico

Il PL può utilizzare il meccanismo di sondaggio DPLPMTUD per generare periodicamente pacchetti di sondaggio della dimensione PLPMTU corrente (ad esempio, utilizzando il CONFIRMATION_TIMER, Sezione 5.1.1). Un timer tiene traccia del fatto che vengano ricevuti riconoscimenti. La perdita successiva di sondaggi è un'indicazione che il percorso corrente non sostiene più il PLPMTU (ad esempio, quando il numero di pacchetti di sondaggio inviati senza ricevere un riconoscimento, PROBE_COUNT, diventa maggiore di MAX_PROBES).

3. Indicazione di evento PL

Il PL può utilizzare un evento che indica che il percorso di rete non sta più sostenendo la dimensione PLPMTU del mittente. Questo può essere rilevato utilizzando meccanismi implementati all'interno del PL per rilevare una perdita eccessiva di dati inviati con una dimensione di pacchetto specifica, e quindi dedurre che questa perdita eccessiva potrebbe essere il risultato di un PLPMTU non valido (come per PLPMTUD per TCP [RFC4821]).

Differenze nel modello di sondaggio

Questi tre metodi possono risultare in modelli di trasmissione diversi per i pacchetti utilizzati come sondaggi e ci si aspetta che risultino in una reattività diversa dopo un effettivo cambiamento di PMTU.

Soppressione del sondaggio

PUÒ: Il PL sopprimere l'invio di pacchetti di sondaggio quando un'applicazione non ha inviato dati dall'ultimo pacchetto di sondaggio.

Un PL che riprende l'invio di dati utente PUÒ continuare a utilizzare la scoperta PLPMTU per ogni percorso. Ciò consente di utilizzare il PLPMTU più recente. Tuttavia, ciò potrebbe comportare l'invio di pacchetti aggiuntivi.

Riduzione del PLPMTU

Quando il metodo rileva che il PLPMTU corrente non è supportato, DPLPMTUD imposta un PLPMTU inferiore e un MPS inferiore. Il PL quindi conferma che il nuovo PLPMTU può essere utilizzato con successo per il percorso. I pacchetti di sondaggio potrebbero dover essere più piccoli della dimensione dei blocchi di dati generati dall'applicazione.

4.4. La dimensione massima del pacchetto (MPS)

Il risultato del sondaggio determina il PLPMTU disponibile, che viene utilizzato per impostare l'MPS utilizzato dall'applicazione. L'MPS è più piccolo del PLPMTU perché è ridotto dalla dimensione delle intestazioni PL (incluso l'overhead per i campi relativi alla sicurezza come i tag AEAD e il riempimento del livello record TLS).

Relazione tra MPS e PLPMTU

|<----- PLPMTU ----->|
|<-- MPS -->|  Intestazioni PL  |  Intestazioni IP  |
| Dati app  | Trasporto | Sicurezza | Rete |

Il PL non può inviare un pacchetto (diverso da un pacchetto di sondaggio) con una dimensione al livello di rete maggiore del PLPMTU corrente. Per evitare ciò, un PL PUÒ essere progettato per segmentare blocchi di dati più grandi dell'MPS in più datagrammi.

DPLPMTUD cerca di evitare la frammentazione IP. Se il PL non è in grado di segmentare i dati, un tentativo di inviare un blocco di dati più grande dell'MPS fallirà. Per determinare il blocco di dati più grande che può essere inviato, un PL DOVREBBE fornire una primitiva all'applicazione che restituisce l'MPS derivato dal PLPMTU corrente.

Gestione del cambiamento MPS

Se DPLPMTUD risulta in un cambiamento dell'MPS, le applicazioni devono adattarsi al nuovo MPS. Un caso particolare può verificarsi quando i pacchetti vengono inviati con una dimensione inferiore all'MPS e il PLPMTU viene successivamente ridotto. Se questi pacchetti vengono persi, il PL PUÒ segmentare i dati utilizzando il nuovo MPS.

Se il PL non è in grado di risegmentare un datagramma precedentemente inviato (ad esempio, [RFC4960]), il mittente scarta il datagramma oppure può eseguire la ritrasmissione utilizzando la frammentazione del livello di rete per formare più pacchetti IP non più grandi del PLPMTU. Per IPv4, il mittente utilizza la frammentazione dell'endpoint in preferenza alla cancellazione del bit DF nell'intestazione IPv4. L'esperienza operativa mostra che la frammentazione IP può ridurre l'affidabilità della comunicazione Internet [RFC8900], il che potrebbe ridurre la probabilità di ritrasmissione riuscita.

4.5. Disabilitazione dell'effetto del PMTUD

Un PL che implementa questa specifica DEVE sospendere l'applicazione del PMTU [RFC1191] [RFC8201] per l'elaborazione del livello di rete dei pacchetti in uscita per ogni flusso che utilizza DPLPMTUD e utilizzare invece DPLPMTUD per controllare la dimensione dei pacchetti che il flusso invia. Ciò elimina la necessità per il livello di rete di scartare o frammentare i pacchetti inviati con una dimensione maggiore del PMTU.

4.6. Risposta ai messaggi PTB

Questo metodo richiede che il mittente DPLPMTUD validi qualsiasi messaggio PTB ricevuto prima di utilizzare le informazioni PTB. La risposta a un messaggio PTB dipende dal PL_PTB_SIZE calcolato dal PTB_SIZE nel messaggio PTB, dallo stato della macchina a stati PLPMTUD e dal protocollo IP in uso.

Sezione 4.6.1 descrive la validazione sia dei messaggi ICMP Unreachable IPv4 (Tipo 3) sia dei messaggi ICMPv6 Packet Too Big, entrambi denominati messaggi PTB in questo documento.

4.6.1. Validazione dei messaggi PTB

Questa sezione specifica l'utilizzo e la validazione dei messaggi PTB.

Opzioni di implementazione

• Implementazione semplice: PUÒ ignorare i messaggi PTB ricevuti, nel qual caso il PLPMTU non viene aggiornato quando viene ricevuto un messaggio PTB.

• PL che supporta PTB: DEVE validare questi messaggi prima dell'ulteriore elaborazione.

Processo di validazione

Un PL che riceve un messaggio PTB da un router o da una middlebox esegue la validazione ICMP (vedere Sezione 4 di [RFC8201] e Sezione 5.2 di [BCP145]). Poiché DPLPMTUD opera al livello PL, il PL deve controllare ogni messaggio PTB ricevuto per determinare se è stato ricevuto in risposta a un pacchetto originato dall'endpoint PL che esegue DPLPMTUD.

Il PL DEVE controllare le informazioni del protocollo nel pacchetto citato trasportato in un payload del messaggio ICMP PTB per validare che il messaggio ha avuto origine dal nodo mittente. Questa validazione include la determinazione che la combinazione di indirizzi IP, protocollo, porta sorgente e porta di destinazione corrisponda alla combinazione restituita nel pacchetto citato -- questo è anche necessario affinché il messaggio PTB venga passato al PL corrispondente.

La validazione DOVREBBE utilizzare informazioni che non sono facilmente disponibili per un attaccante fuori percorso [BCP145]. Ad esempio, può controllare il valore dei campi dell'intestazione del protocollo noti solo ai due endpoint PL. Le applicazioni di datagramma che utilizzano porte sorgente e di destinazione ben note dovrebbero anche fare affidamento su altre informazioni per completare questa validazione.

Questi controlli hanno lo scopo di fornire protezione dai pacchetti che hanno origine da un nodo che non è sul percorso di rete. I messaggi PTB che non hanno completato la validazione NON DEVONO essere ulteriormente utilizzati dal metodo DPLPMTUD, come discusso nella sezione Considerazioni sulla sicurezza (Sezione 8).

Sezione 4.6.2 descrive l'elaborazione dei messaggi PTB.

4.6.2. Utilizzo dei messaggi PTB

Un messaggio PTB validato PUÒ essere utilizzato dall'algoritmo DPLPMTUD ma NON DEVE essere utilizzato direttamente per impostare il PLPMTU.

Prima di utilizzare la dimensione riportata nel messaggio PTB, deve prima essere convertita in un PL_PTB_SIZE. Il PL_PTB_SIZE è più piccolo del PTB_SIZE perché è ridotto dalle intestazioni sotto il PL, incluse eventuali opzioni o estensioni IP aggiunte al pacchetto PL.

I metodi che utilizzano questi messaggi PTB possono migliorare la velocità con cui l'algoritmo rileva un PLPMTU appropriato attivando un sondaggio immediato per un PL_PTB_SIZE (risultando in una dimensione del pacchetto del livello di rete di PTB_SIZE), rispetto ai metodi che si basano esclusivamente su un algoritmo di ricerca basato su timer.

Un insieme di controlli ha lo scopo di fornire protezione da un router che segnala un PTB_SIZE inaspettato. Il PL deve anche controllare che il PL_PTB_SIZE indicato sia inferiore alla dimensione utilizzata da un pacchetto di sondaggio e almeno alla dimensione minima accettata.

Riepilogo dell'elaborazione dei messaggi PTB

Questa sezione fornisce un riepilogo di come vengono utilizzati i messaggi PTB, utilizzando l'insieme di costanti definite nella Sezione 5.1.2. Questa elaborazione dipende dal PL_PTB_SIZE e dai valori correnti di un insieme di variabili:

PL_PTB_SIZE < MIN_PLPMTU

• PL_PTB_SIZE non valido, vedere Sezione 4.6.1
• Il messaggio PTB dovrebbe essere scartato senza ulteriore elaborazione (cioè, il PLPMTU non viene modificato)
• Queste informazioni potrebbero essere utilizzate come input per attivare l'abilitazione di una modalità di resilienza (vedere Sezione 5.3.3)

MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU

• Un PL robusto PUÒ entrare nello stato di errore (vedere Sezione 5.2) per un percorso IPv4 quando il PL_PTB_SIZE riportato nel messaggio PTB è maggiore o uguale a 68 byte [RFC0791] e inferiore a BASE_PLPMTU
• Un PL robusto PUÒ entrare nello stato di errore (vedere Sezione 5.2) per un percorso IPv6 quando il PL_PTB_SIZE riportato nel messaggio PTB è maggiore o uguale a 1280 byte [RFC8200] e inferiore a BASE_PLPMTU

BASE_PLPMTU <= PL_PTB_SIZE < PLPMTU

• Questo potrebbe essere un'indicazione di un buco nero. Il PLPMTU DOVREBBE essere impostato su BASE_PLPMTU (il PLPMTU viene ridotto a BASE_PLPMTU per evitare perdite di pacchetti non necessarie quando si incontra un buco nero)
• Il PL dovrebbe avviare una ricerca per scoprire rapidamente il nuovo PLPMTU. Il PL_PTB_SIZE riportato nel messaggio PTB può essere utilizzato per inizializzare l'algoritmo di ricerca

PLPMTU < PL_PTB_SIZE < PROBED_SIZE

• Il PLPMTU continua ad essere valido, ma la dimensione utilizzata per una ricerca (PROBED_SIZE) è maggiore del PMTU effettivo
• Il PLPMTU non viene aggiornato
• Quando riprende l'algoritmo di ricerca, il PL può utilizzare il PL_PTB_SIZE riportato nel messaggio PTB come prossimo punto di ricerca

PL_PTB_SIZE >= PROBED_SIZE

• Segnale di rete incoerente
• Il messaggio PTB dovrebbe essere scartato senza ulteriore elaborazione (cioè, il PLPMTU non viene modificato)
• Queste informazioni potrebbero essere utilizzate come input che attiva l'abilitazione di una modalità di resilienza

Questi meccanismi insieme garantiscono che DPLPMTUD possa scoprire e mantenere in modo affidabile un MTU di percorso appropriato.