7. Gestione dei pacchetti IP

Questo documento definisce un meccanismo di tunneling che è concettualmente un collegamento IP. Tuttavia, poiché i collegamenti sono collegati ai router IP, le implementazioni potrebbero dover gestire alcune delle responsabilità dei router IP se non le delegano a un'altra implementazione, come un kernel.

7.1. Operazione di collegamento

I tunnel di inoltro IP descritti in questo documento non sono "interfacce" complete nel senso dell'architettura di indirizzamento IPv6 [IPv6-ADDR]. In particolare, non hanno necessariamente indirizzi link-local IPv6. Inoltre, l'autoconfigurazione stateless IPv6 o i messaggi di annuncio del router non vengono utilizzati in tali interfacce, e nemmeno la scoperta dei vicini.

Quando si utilizza HTTP/2 o HTTP/3, un client PUÒ iniziare ottimisticamente a inviare pacchetti IP tramite proxy prima di ricevere la risposta alla sua richiesta di proxy IP, notando tuttavia che questi potrebbero non essere elaborati dal proxy IP se risponde alla richiesta con un fallimento o se i datagrammi vengono ricevuti dal proxy IP prima della richiesta. Poiché la ricezione di indirizzi e percorsi è necessaria per sapere che un pacchetto può essere inviato attraverso il tunnel, tali pacchetti ottimistici potrebbero essere scartati dal proxy IP se sceglie di fornire informazioni di indirizzamento o instradamento diverse da quelle ipotizzate dal client.

Si noti che è possibile che più pacchetti IP inviati tramite proxy siano incapsulati nello stesso pacchetto esterno, ad esempio, perché un pacchetto QUIC può trasportare più di un frame QUIC DATAGRAM. È anche possibile che un pacchetto IP inviato tramite proxy copra più pacchetti esterni, perché una capsula DATAGRAM può essere divisa su più pacchetti QUIC o TCP.

7.2. Operazione di instradamento

I requisiti in questa sezione sono una ripetizione di requisiti che si applicano ai router IP in generale e potrebbero non applicarsi alle implementazioni di proxy IP che si basano su software esterno per l'instradamento.

Quando un endpoint riceve un Datagramma HTTP contenente un pacchetto IP, analizzerà l'intestazione IP del pacchetto, eseguirà eventuali controlli di politica locale (ad esempio, convalida dell'indirizzo di origine), controllerà la propria tabella di routing per scegliere un'interfaccia in uscita, e quindi invierà il pacchetto IP su quell'interfaccia o lo passerà a un'applicazione locale. L'endpoint può anche scegliere di scartare qualsiasi pacchetto ricevuto invece di inoltrarlo. Se un pacchetto IP ricevuto non supera alcun controllo di correttezza o politica, si tratta di un errore di inoltro, non di una violazione del protocollo, per quanto riguarda il proxy IP; vedere Sezione 7.2.1. Gli endpoint di proxy IP POSSONO implementare politiche di filtraggio aggiuntive sui pacchetti IP che inoltrano.

Nell'altra direzione, quando un endpoint riceve un pacchetto IP, controlla se il pacchetto corrisponde ai percorsi mappati per un tunnel IP ed esegue gli stessi controlli di inoltro di cui sopra prima di trasmettere il pacchetto su Datagrammi HTTP.

Quando gli endpoint di proxy IP inoltrano pacchetti IP tra collegamenti diversi, decrementeranno il conteggio dei salti IP (o TTL) all'incapsulamento ma non alla decapsulazione. In altre parole, il conteggio dei salti viene decrementato subito prima che un pacchetto IP venga trasmesso in un Datagramma HTTP. Ciò impedisce loop infiniti in presenza di loop di routing e corrisponde alle scelte in IPsec [IPSEC]. Ciò non si applica ai pacchetti IP generati dall'endpoint di proxy IP stesso.

Gli implementatori devono assicurarsi di non inoltrare alcun traffico link-local oltre l'interfaccia di proxy IP su cui è stato ricevuto. Gli endpoint di proxy IP devono anche rispondere correttamente ai pacchetti destinati agli indirizzi multicast link-local.

IPv6 richiede che ogni collegamento abbia una MTU di almeno 1280 byte [IPv6]. Poiché il proxy IP in HTTP trasmette pacchetti IP in Datagrammi HTTP e questi possono a loro volta essere inviati in frame QUIC DATAGRAM che non possono essere frammentati [DGRAM], la MTU di un tunnel IP può essere limitata dalla MTU della connessione QUIC su cui opera il proxy IP. Ciò può portare a situazioni in cui viene violata la MTU minima del collegamento IPv6. Gli endpoint di proxy IP che operano come router e supportano IPv6 DEVONO garantire che la MTU del collegamento del tunnel IP sia almeno 1280 byte (cioè, che possano inviare Datagrammi HTTP con payload di almeno 1280 byte). Ciò può essere realizzato utilizzando varie tecniche:

• Se entrambi gli endpoint di proxy IP sanno per certo che non vengono utilizzati intermediari HTTP, gli endpoint possono riempire i pacchetti QUIC INITIAL della connessione QUIC esterna su cui è in esecuzione il proxy IP. (Supponendo che venga utilizzata la versione 1 di QUIC, il sovraccarico è di 1 byte per il tipo, 20 byte per la lunghezza massima dell'ID connessione, 4 byte per la lunghezza massima del numero di pacchetto, 1 byte per il tipo di frame DATAGRAM, 8 byte per l'ID Quarter Stream massimo, 1 byte per l'ID Contesto zero e 16 byte per il tag di autenticazione Authenticated Encryption with Associated Data (AEAD), per un totale di 51 byte di sovraccarico, che corrisponde al riempimento dei pacchetti QUIC INITIAL a 1331 byte o più.)

• Gli endpoint di proxy IP possono anche inviare richieste di eco ICMPv6 con 1232 byte di dati per accertare la MTU del collegamento e abbattere il tunnel se non ricevono una risposta. A meno che gli endpoint non abbiano un mezzo fuori banda per garantire che le tecniche precedenti siano sufficienti, DEVONO utilizzare questo metodo. Se un endpoint non conosce un indirizzo IPv6 del suo peer, può inviare la richiesta di eco ICMPv6 all'indirizzo multicast link-local di tutti i nodi (ff02::1).

Se un endpoint utilizza frame QUIC DATAGRAM per trasmettere pacchetti IPv6 e rileva che la MTU QUIC è troppo bassa per consentire l'invio di 1280 byte, DEVE interrompere il flusso di richiesta del proxy IP.

7.2.1. Segnalazione di errore

Poiché gli endpoint di proxy IP spesso inoltrano pacchetti IP verso altre interfacce di rete, devono gestire gli errori nel processo di inoltro. Ad esempio, l'inoltro può fallire se l'endpoint non ha un percorso per l'indirizzo di destinazione, se è configurato per rifiutare un prefisso di destinazione per politica, o se la MTU del collegamento in uscita è inferiore alla dimensione del pacchetto da inoltrare. In tali scenari, gli endpoint di proxy IP DOVREBBERO utilizzare ICMP [ICMP] [ICMPv6] per segnalare l'errore di inoltro al proprio peer generando pacchetti ICMP e inviandoli utilizzando Datagrammi HTTP.

Gli endpoint sono liberi di selezionare gli errori ICMP più appropriati da inviare. Alcuni esempi rilevanti per il proxy IP includono quanto segue:

• Per indirizzi di origine non validi, inviare Destination Unreachable (Destinazione irraggiungibile) (Sezione 3.1 di ICMPv6) con codice 5, "Source address failed ingress/egress policy" (L'indirizzo di origine non ha superato la politica di ingresso/uscita).

• Per indirizzi di destinazione non instradabili, inviare Destination Unreachable (Destinazione irraggiungibile) (Sezione 3.1 di ICMPv6) con codice 0, "No route to destination" (Nessun percorso verso la destinazione), o codice 1, "Communication with destination administratively prohibited" (Comunicazione con la destinazione proibita amministrativamente).

• Per pacchetti che non possono rientrare nella MTU del collegamento in uscita, inviare Packet Too Big (Pacchetto troppo grande) (Sezione 3.2 di ICMPv6).

Per ricevere questi errori, gli endpoint devono essere preparati a ricevere pacchetti ICMP. Se un endpoint non invia capsule ROUTE_ADVERTISEMENT, come un client che apre un flusso IP attraverso un proxy IP, DOVREBBE elaborare i pacchetti ICMP inviati tramite proxy dal suo peer per ricevere questi errori. Si noti che i messaggi ICMP possono provenire da un indirizzo di origine diverso da quello del peer di proxy IP e anche dall'esterno della destinazione se è in uso l'ambito (vedere Sezione 4.6).