5.2. Storing PMTU Information (Memorizzazione delle informazioni PMTU)

Idealmente, un valore PMTU dovrebbe essere associato a un percorso specifico attraversato dai pacchetti scambiati tra i nodi sorgente e destinazione. Tuttavia, nella maggior parte dei casi un nodo non avrà informazioni sufficienti per identificare completamente e accuratamente tale percorso. Piuttosto, un nodo deve associare un valore PMTU con una rappresentazione locale di un percorso. È lasciato all'implementazione la selezione della rappresentazione locale di un percorso. Per i nodi con più interfacce, le informazioni sulla Path MTU dovrebbero essere mantenute per ciascun link IPv6.

Nel caso di un indirizzo di destinazione multicast, le copie di un pacchetto possono attraversare molti percorsi diversi per raggiungere molti nodi diversi. La rappresentazione locale del "percorso" verso una destinazione multicast deve rappresentare un insieme potenzialmente grande di percorsi.

In modo minimale, un'implementazione potrebbe mantenere un singolo valore PMTU da utilizzare per tutti i pacchetti originati dal nodo. Questo valore PMTU sarebbe la PMTU minima appresa nell'insieme di tutti i percorsi in uso dal nodo. Questo approccio probabilmente comporterà l'uso di pacchetti più piccoli del necessario per molti percorsi. Nel caso del routing multipath (ad esempio, Equal-Cost Multipath Routing (ECMP)), un insieme di percorsi può esistere anche per una singola coppia sorgente e destinazione.

Un'implementazione potrebbe utilizzare l'indirizzo di destinazione come rappresentazione locale di un percorso. Il valore PMTU associato a una destinazione sarebbe la PMTU minima appresa nell'insieme di tutti i percorsi in uso verso quella destinazione. Questo approccio comporterà l'uso di pacchetti di dimensioni ottimali su base per-destinazione. Questo approccio si integra bene con il modello concettuale di un host come descritto in [ND]: un valore PMTU potrebbe essere memorizzato con la voce corrispondente nella cache delle destinazioni.

Se i flussi [RFC8200] sono in uso, un'implementazione potrebbe utilizzare il flow id come rappresentazione locale di un percorso. I pacchetti inviati a una particolare destinazione ma appartenenti a flussi diversi possono utilizzare percorsi diversi, come con ECMP, in cui la scelta del percorso potrebbe dipendere dal flow id. Questo approccio potrebbe risultare nell'uso di pacchetti di dimensioni ottimali su base per-flusso, fornendo una granularità più fine rispetto ai valori PMTU mantenuti su base per-destinazione.

Per i pacchetti con routing dalla sorgente (cioè pacchetti contenenti un'intestazione Routing IPv6 [RFC8200]), il percorso dalla sorgente può qualificare ulteriormente la rappresentazione locale di un percorso.

Inizialmente, il valore PMTU per un percorso è assunto essere la MTU (nota) del link del primo hop.

Quando viene ricevuto un messaggio Packet Too Big, il nodo determina a quale percorso si applica il messaggio in base al contenuto del messaggio Packet Too Big. Ad esempio, se l'indirizzo di destinazione viene utilizzato come rappresentazione locale di un percorso, l'indirizzo di destinazione dal pacchetto originale verrebbe utilizzato per determinare a quale percorso si applica il messaggio.

Nota: se il pacchetto originale conteneva un'intestazione Routing, l'intestazione Routing dovrebbe essere utilizzata per determinare la posizione dell'indirizzo di destinazione all'interno del pacchetto originale. Se Segments Left è uguale a zero, l'indirizzo di destinazione è nel campo Destination Address nell'intestazione IPv6. Se Segments Left è maggiore di zero, l'indirizzo di destinazione è l'ultimo indirizzo (Address[n]) nell'intestazione Routing.

Il nodo quindi utilizza il valore nel campo MTU nel messaggio Packet Too Big come valore PMTU tentativo o la MTU minima del link IPv6 se questa è maggiore, e confronta la PMTU tentativa con la PMTU esistente. Se la PMTU tentativa è inferiore alla stima PMTU esistente, la PMTU tentativa sostituisce la PMTU esistente come valore PMTU per il percorso.

I livelli di pacchettizzazione devono essere notificati delle diminuzioni della PMTU. Qualsiasi istanza del livello di pacchettizzazione (ad esempio, una connessione TCP) che sta utilizzando attivamente il percorso deve essere notificata se la stima PMTU viene diminuita.

Nota: anche se il messaggio Packet Too Big contiene un'intestazione del pacchetto originale che fa riferimento a un pacchetto UDP, il livello TCP deve essere notificato se una qualsiasi delle sue connessioni utilizza il percorso dato.

Inoltre, l'istanza che ha inviato il pacchetto che ha suscitato il messaggio Packet Too Big dovrebbe essere notificata che il suo pacchetto è stato scartato, anche se la stima PMTU non è cambiata, in modo che possa ritrasmettere i dati scartati.

Nota: Un'implementazione può evitare l'uso di un meccanismo di notifica asincrono per le diminuzioni PMTU posticipando la notifica fino al successivo tentativo di inviare un pacchetto più grande della stima PMTU. In questo approccio, quando viene fatto un tentativo di INVIARE un pacchetto più grande della stima PMTU, la funzione SEND dovrebbe fallire e restituire un'indicazione di errore adeguata. Questo approccio può essere più adatto a un livello di pacchettizzazione senza connessione (come uno che utilizza UDP), che (in alcune implementazioni) può essere difficile da "notificare" dal livello ICMPv6. In questo caso, i normali meccanismi di ritrasmissione basati su timeout verrebbero utilizzati per recuperare dai pacchetti scartati.

È importante capire che la notifica delle istanze del livello di pacchettizzazione che utilizzano il percorso riguardo al cambiamento nella PMTU è distinta dalla notifica di un'istanza specifica che un pacchetto è stato scartato. Quest'ultima dovrebbe essere effettuata il prima possibile (cioè in modo asincrono dal punto di vista dell'istanza del livello di pacchettizzazione), mentre la prima può essere ritardata fino a quando un'istanza del livello di pacchettizzazione desidera creare un pacchetto.