6. Specifica dei metodi specifici del protocollo
DPLPMTUD richiede che i dettagli specifici del protocollo siano specificati per ogni PL che lo utilizza.
La prima sottosezione fornisce indicazioni su come implementare il metodo DPLPMTUD come parte di un'applicazione che utilizza UDP o UDP-Lite. Questa guida è anche applicabile ad altri servizi di datagramma che non includono un protocollo di trasporto specifico (come l'incapsulamento del tunnel). Le sottosezioni seguenti descrivono come implementare DPLPMTUD come parte di un servizio di trasporto, consentendo alle applicazioni che utilizzano questo servizio di beneficiare della scoperta del PLPMTU senza dover implementare questo metodo da sole quando si utilizzano SCTP e QUIC.
6.1. Supporto applicativo per DPLPMTUD con UDP o UDP-Lite
Le specifiche attuali di UDP [RFC0768] e UDP-Lite [RFC3828] non definiscono un metodo nella serie RFC che supporta PLPMTUD. In particolare, il trasporto UDP non fornisce le funzionalità di trasporto richieste per implementare il datagramma PLPMTUD.
Il metodo DPLPMTUD può essere implementato come parte di un'applicazione costruita direttamente o indirettamente su UDP o UDP-Lite, ma si basa sulle funzionalità del protocollo di livello superiore per implementare il metodo [BCP145].
Alcune primitive utilizzate da DPLPMTUD potrebbero non essere disponibili tramite l'API del datagramma (ad esempio, la capacità di accedere al PLPMTU dalla cache del livello IP o la capacità di interpretare i messaggi PTB ricevuti).
Inoltre, è RACCOMANDATO che la scoperta PMTU non venga eseguita da più livelli di protocollo. Quando il sistema di trasporto sottostante fornisce questa funzione, un'applicazione DOVREBBE evitare di utilizzare DPLPMTUD. Ci sono vantaggi in un metodo generico per gestire il PLPMTU, sia nella condivisione dello stato tra i processi sia nel coordinamento del sondaggio per diverse istanze PL.
6.1.1. Richiesta dell'applicazione
Un'applicazione necessita di un meccanismo di protocollo a livello di applicazione (come un metodo di conferma del messaggio) per richiedere una risposta dall'endpoint di destinazione. Il metodo DOVREBBE consentire al mittente di controllare i valori restituiti nella risposta per fornire una protezione aggiuntiva contro l'iniezione di dati fuori dal percorso [BCP145]. I metodi appropriati includono parametri noti solo ai due endpoint, come un ID di sessione o un numero di sequenza inizializzato.
6.1.2. Risposta dell'applicazione
Un'applicazione necessita di un meccanismo di protocollo a livello di applicazione per comunicare una risposta dall'endpoint di destinazione. Questa risposta può indicare che un sondaggio ha attraversato con successo il percorso, ma può anche indicare che alcuni (o tutti) i pacchetti non hanno raggiunto la destinazione.
6.1.3. Invio di pacchetti di sondaggio dell'applicazione
I pacchetti di sondaggio possono trasportare un blocco di dati dell'applicazione, ma c'è il rischio che la trasmissione riuscita di questi dati sia a rischio quando utilizzata per il sondaggio. Alcune applicazioni potrebbero preferire utilizzare pacchetti di sondaggio che non trasportano un blocco di dati dell'applicazione per evitare interruzioni nella trasmissione dei dati.
6.1.4. Connettività iniziale
Un'applicazione che non ha altre informazioni di livello superiore che confermano la connettività con il peer remoto DOVREBBE implementare un meccanismo per la connessione utilizzando pacchetti di sondaggio confermati prima di entrare nello stato BASE.
6.1.5. Validazione del percorso
Un'applicazione che non ha altre informazioni di livello superiore che confermano che i datagrammi sono consegnati correttamente DOVREBBE implementare il CONFIRMATION_TIMER per inviare periodicamente pacchetti di sondaggio quando si trova nello stato SEARCH_COMPLETE.
6.1.6. Gestione dei messaggi PTB
Le applicazioni che sono in grado e desiderano ricevere messaggi PTB DEVONO eseguire la validazione ICMP specificata nella Sezione 5.2 di [BCP145]. Ciò richiede che l'applicazione controlli ogni messaggio PTB ricevuto per validare che è stato ricevuto in risposta al traffico trasmesso e che il PL_PTB_SIZE segnalato è inferiore alla dimensione attualmente sondata (vedere Sezione 4.6.2). Un messaggio PTB validato PUÒ essere utilizzato come input per l'algoritmo DPLPMTUD ma NON DEVE essere utilizzato direttamente per impostare il PLPMTU.
6.2. DPLPMTUD per SCTP
La Sezione 10.2 di [RFC4821] specifica un metodo di sondaggio PLPMTUD raccomandato per SCTP, e la Sezione 7.3 di [RFC4960] raccomanda che un endpoint applichi le tecniche di RFC 4821 su base per indirizzo di destinazione. La specifica DPLPMTUD continua la pratica del PL che scopre il PMTU ma aggiorna RFC4960 per RACCOMANDARE l'uso del metodo specificato in questo documento: Il metodo RACCOMANDATO per generare sondaggi consiste nell'aggiungere un chunk costituito solo da riempimento a un messaggio SCTP. Il chunk PAD definito in [RFC4820] DOVREBBE essere allegato a un chunk HEARTBEAT (HB) di lunghezza minima per costruire un pacchetto di sondaggio. Ciò rende il sondaggio indipendente dal trasferimento dei messaggi utente e indipendente dal controllo della congestione o del flusso. Questo è preferibile all'uso di chunk DATA (raggruppati, se necessario, con altri chunk di controllo) come sondaggi di percorso.
La Sezione 6.9 di [RFC4960] descrive il mittente PL che segmenta i messaggi utente in chunk DATA quando si utilizza SCTP. Questo nota che una volta inviato un messaggio SCTP, non può essere risegmentato. [RFC4960] descrive un metodo di ritrasmissione dei chunk DATA quando l'MPS è ridotto, e la Sezione 6.9 di [RFC4960] descrive l'uso della frammentazione IP in questo caso. Questo documento non apporta modifiche a questo.
6.2.1. SCTP/IPv4 e SCTP/IPv6
6.2.1.1. Connettività iniziale
Il protocollo base è specificato in [RFC4960]. Questo fornisce un PL confermato. Pertanto, un mittente può entrare nello stato BASE una volta che l'associazione è stata confermata.
6.2.1.2. Invio di pacchetti di sondaggio SCTP
Il pacchetto di sondaggio è composto da un'intestazione comune SCTP, un chunk HEARTBEAT e un chunk PAD. Il chunk PAD viene utilizzato per controllare la lunghezza del pacchetto di sondaggio. Il chunk HEARTBEAT viene utilizzato per attivare l'invio di un chunk HEARTBEAT ACK. La ricezione di un chunk HEARTBEAT ACK conferma la ricezione di un sondaggio riuscito. I sondaggi riusciti aggiornano i contatori dell'associazione e del percorso, ma i sondaggi non riusciti vengono ignorati (presumibilmente il risultato della scelta di un PLPMTU troppo grande).
Il mittente SCTP deve essere in grado di determinare la dimensione totale di un pacchetto di sondaggio. Il chunk HEARTBEAT può trasportare un parametro di informazioni sul battito cardiaco che, oltre alle informazioni suggerite in [RFC4960], include anche la dimensione del sondaggio per aiutare le implementazioni ad associare un HEARTBEAT ACK con la dimensione del sondaggio inviato. Altri metodi sono possibili, come l'invio di un numero casuale e la verifica che le informazioni restituite contengano anche il numero casuale corrispondente.
La lunghezza del chunk PAD viene calcolata riducendo la dimensione dell'intestazione comune SCTP e del chunk HEARTBEAT. Il payload del chunk PAD contiene dati arbitrari. Quando trasmesso su IP, la dimensione PMTU include anche l'intestazione IPv4 o IPv6.
Il sondaggio può iniziare direttamente dopo l'handshake PL; questo può essere fatto prima dell'invio dei dati. Assumendo questo comportamento (cioè, PMTU è minore o uguale all'interfaccia MTU), questo processo richiederà diversi periodi di tempo di andata e ritorno, a seconda del numero di sondaggi DPLPMTUD inviati. Il timer del battito cardiaco può essere utilizzato per implementare il PROBE_TIMER.
6.2.1.3. Validazione del percorso con SCTP
Poiché SCTP fornisce un PL confermato, un mittente NON DEVE implementare il CONFIRMATION_TIMER quando si trova nello stato SEARCH_COMPLETE.
6.2.1.4. Gestione dei messaggi PTB da parte di SCTP
La validazione ICMP normale DEVE essere eseguita come specificato nell'Appendice C di [RFC4960]. Ciò richiede che i primi 8 byte dell'intestazione comune SCTP siano citati nel payload del messaggio PTB, che può essere il caso per ICMPv4 e di solito è il caso per ICMPv6.
Quando un messaggio PTB è stato validato, il PL_PTB_SIZE calcolato dal PTB_SIZE segnalato nel messaggio PTB DOVREBBE essere utilizzato con l'algoritmo DPLPMTUD, a condizione che il PL_PTB_SIZE segnalato sia inferiore alla dimensione del sondaggio corrente (vedere Sezione 4.6).
6.2.2. DPLPMTUD per SCTP/UDP
L'incapsulamento UDP di SCTP è specificato in [RFC6951].
Questa specifica aggiorna il riferimento a RFC 4821 nella Sezione 5.6 di RFC 6951 per fare riferimento a questo documento (RFC 8899). RFC 6951 viene aggiornato aggiungendo la seguente frase alla fine della Sezione 5.6 di RFC 6951:
Il metodo RACCOMANDATO per determinare il MTU del percorso è specificato in RFC 8899.
6.2.2.1. Connettività iniziale
Un mittente può entrare nello stato BASE una volta che l'associazione SCTP è stata confermata.
6.2.2.2. Invio di pacchetti di sondaggio SCTP/UDP
Il sondaggio del datagramma può essere eseguito come specificato nella Sezione 6.2.1.2. La dimensione dei pacchetti di sondaggio include l'intestazione UDP di 8 byte. Questo deve essere preso in considerazione quando si riempie un pacchetto di sondaggio utilizzando un chunk PAD.
6.2.2.3. Validazione del percorso con SCTP/UDP
SCTP fornisce un PL confermato; pertanto, un mittente non implementa il CONFIRMATION_TIMER quando si trova nello stato SEARCH_COMPLETE.
6.2.2.4. Gestione dei messaggi PTB da parte di SCTP/UDP
La validazione ICMP dei messaggi PTB DEVE essere eseguita come specificato nell'Appendice C di [RFC4960]. Ciò richiede che i primi 8 byte dell'intestazione comune SCTP siano presenti nel messaggio PTB, che potrebbe essere il caso per ICMPv4 (ma si noti che l'intestazione UDP consuma una parte dell'intestazione del pacchetto citato) e di solito è il caso per ICMPv6. Quando la validazione è completata, il PL_PTB_SIZE calcolato dal PTB_SIZE nel messaggio PTB DOVREBBE essere utilizzato con DPLPMTUD, a condizione che il PL_PTB_SIZE segnalato sia inferiore alla dimensione del sondaggio corrente.
6.2.3. DPLPMTUD per SCTP/DTLS
L'incapsulamento Datagram Transport Layer Security (DTLS) di SCTP è specificato in [RFC8261]. Questo viene utilizzato nei canali dati per le implementazioni WebRTC. Questa specifica aggiorna il riferimento a RFC 4821 nella Sezione 5 di RFC 8261 per fare riferimento a questo documento (RFC 8899).
6.2.3.1. Connettività iniziale
Un mittente può entrare nello stato BASE una volta che l'associazione SCTP è stata confermata.
6.2.3.2. Invio di pacchetti di sondaggio SCTP/DTLS
Il sondaggio del datagramma può essere eseguito come specificato nella Sezione 6.2.1.2. Il payload massimo è ridotto dalla dimensione delle intestazioni DTLS, che deve essere preso in considerazione quando si riempie utilizzando un chunk PAD. La dimensione dei pacchetti di sondaggio include l'intestazione PL DTLS. Questo deve essere preso in considerazione quando si riempie un pacchetto di sondaggio utilizzando un chunk PAD.
6.2.3.3. Validazione del percorso con SCTP/DTLS
Poiché SCTP fornisce un PL confermato, un mittente NON DEVE implementare il CONFIRMATION_TIMER quando si trova nello stato SEARCH_COMPLETE.
6.2.3.4. Gestione dei messaggi PTB da parte di SCTP/DTLS
[RFC4960] non specifica un metodo per la validazione dei payload dei messaggi ICMP SCTP/DTLS, e nemmeno questo documento lo fa. Questo impedisce l'elaborazione dei messaggi PTB al livello PL.
6.3. DPLPMTUD per QUIC
QUIC [QUIC] è un PL basato su UDP che fornisce feedback di ricezione. Il payload UDP include un'intestazione del pacchetto QUIC, un payload protetto e tutti i campi di autenticazione. Supporta il riempimento e la coalescenza dei pacchetti che possono essere utilizzati per costruire pacchetti di sondaggio. Dal punto di vista di DPLPMTUD, QUIC può funzionare come un PL confermato. [QUIC] descrive un metodo per utilizzare DPLPMTUD con pacchetti QUIC.
Considerazioni sull'implementazione
Quando si implementa DPLPMTUD per un protocollo specifico:
- Scegliere il metodo di sondaggio appropriato - Selezionare il tipo di pacchetto di sondaggio più efficiente in base alle caratteristiche del protocollo
- Utilizzare i meccanismi esistenti - Utilizzare i meccanismi di conferma e battito cardiaco integrati ove possibile
- Considerare l'overhead di incapsulamento - Calcolare correttamente la dimensione delle intestazioni a ciascun livello
- Coordinare la gestione dello stato - Assicurarsi che lo stato PLPMTU si sincronizzi con lo stato della connessione del protocollo
- Gestire le limitazioni specifiche del protocollo - Considerare i vincoli e i requisiti unici di ciascun protocollo
Queste linee guida di implementazione specifiche del protocollo garantiscono che DPLPMTUD possa integrarsi efficacemente con vari protocolli di trasporto.