7. Gestion des paquets IP

Ce document définit un mécanisme de tunnelisation qui est conceptuellement une liaison IP. Cependant, parce que les liaisons sont attachées aux routeurs IP, les implémentations peuvent devoir gérer certaines des responsabilités des routeurs IP si elles ne les délèguent pas à une autre implémentation, telle qu'un noyau.

7.1. Opération de liaison

Les tunnels de transfert IP décrits dans ce document ne sont pas des "interfaces" complètes au sens de l'architecture d'adressage IPv6 [IPv6-ADDR]. En particulier, ils n'ont pas nécessairement d'adresses lien-local IPv6. De plus, l'autoconfiguration sans état IPv6 ou les messages d'annonce de routeur ne sont pas utilisés dans de telles interfaces, tout comme la découverte de voisins.

Lors de l'utilisation de HTTP/2 ou HTTP/3, un client PEUT commencer de manière optimiste à envoyer des paquets IP relayés avant de recevoir la réponse à sa requête de relais IP, notant cependant que ceux-ci peuvent ne pas être traités par le proxy IP s'il répond à la requête par un échec ou si les datagrammes sont reçus par le proxy IP avant la requête. Puisque la réception d'adresses et de routes est requise pour savoir qu'un paquet peut être envoyé via le tunnel, de tels paquets optimistes pourraient être rejetés par le proxy IP s'il choisit de fournir des informations d'adressage ou de routage différentes de celles supposées par le client.

Notez qu'il est possible que plusieurs paquets IP relayés soient encapsulés dans le même paquet externe, par exemple, parce qu'un paquet QUIC peut transporter plus d'une trame QUIC DATAGRAM. Il est également possible qu'un paquet IP relayé s'étende sur plusieurs paquets externes, car une capsule DATAGRAM peut être divisée sur plusieurs paquets QUIC ou TCP.

7.2. Opération de routage

Les exigences de cette section sont une répétition des exigences qui s'appliquent aux routeurs IP en général et pourraient ne pas s'appliquer aux implémentations de relais IP qui s'appuient sur un logiciel externe pour le routage.

Lorsqu'un point de terminaison reçoit un datagramme HTTP contenant un paquet IP, il analysera l'en-tête IP du paquet, effectuera toutes les vérifications de politique locale (par exemple, validation de l'adresse source), vérifiera sa table de routage pour choisir une interface sortante, puis enverra le paquet IP sur cette interface ou le passera à une application locale. Le point de terminaison peut également choisir de rejeter tous les paquets reçus au lieu de les transférer. Si un paquet IP reçu échoue à une vérification d'exactitude ou de politique, c'est une erreur de transfert, pas une violation de protocole, en ce qui concerne le relais IP ; voir Section 7.2.1. Les points de terminaison de relais IP PEUVENT implémenter des politiques de filtrage supplémentaires sur les paquets IP qu'ils transfèrent.

Dans l'autre sens, lorsqu'un point de terminaison reçoit un paquet IP, il vérifie si le paquet correspond aux routes mappées pour un tunnel IP et effectue les mêmes vérifications de transfert que ci-dessus avant de transmettre le paquet via des datagrammes HTTP.

Lorsque les points de terminaison de relais IP transfèrent des paquets IP entre différentes liaisons, ils décrémentent le nombre de sauts IP (ou TTL) lors de l'encapsulation mais pas lors de la désencapsulation. En d'autres termes, le nombre de sauts est décrémenté juste avant qu'un paquet IP ne soit transmis dans un datagramme HTTP. Cela empêche les boucles infinies en présence de boucles de routage et correspond aux choix dans IPsec [IPSEC]. Cela ne s'applique pas aux paquets IP générés par le point de terminaison de relais IP lui-même.

Les implémenteurs doivent s'assurer qu'ils ne transfèrent aucun trafic lien-local au-delà de l'interface de relais IP sur laquelle il a été reçu. Les points de terminaison de relais IP doivent également répondre correctement aux paquets destinés aux adresses de multidiffusion lien-local.

IPv6 exige que chaque liaison ait une MTU d'au moins 1280 octets [IPv6]. Puisque le relais IP dans HTTP transmet des paquets IP dans des datagrammes HTTP et que ceux-ci peuvent à leur tour être envoyés dans des trames QUIC DATAGRAM qui ne peuvent pas être fragmentées [DGRAM], la MTU d'un tunnel IP peut être limitée par la MTU de la connexion QUIC sur laquelle le relais IP fonctionne. Cela peut conduire à des situations où la MTU de liaison minimale IPv6 est violée. Les points de terminaison de relais IP qui fonctionnent comme des routeurs et prennent en charge IPv6 DOIVENT s'assurer que la MTU de la liaison du tunnel IP est d'au moins 1280 octets (c'est-à-dire qu'ils peuvent envoyer des datagrammes HTTP avec des charges utiles d'au moins 1280 octets). Cela peut être accompli en utilisant diverses techniques :

• Si les deux points de terminaison de relais IP savent avec certitude que les intermédiaires HTTP ne sont pas utilisés, les points de terminaison peuvent remplir les paquets QUIC INITIAL de la connexion QUIC externe sur laquelle le relais IP s'exécute. (En supposant que la version 1 de QUIC est utilisée, la surcharge est de 1 octet pour le type, 20 octets pour la longueur maximale de l'ID de connexion, 4 octets pour la longueur maximale du numéro de paquet, 1 octet pour le type de trame DATAGRAM, 8 octets pour l'ID de flux trimestriel maximal, 1 octet pour l'ID de contexte zéro, et 16 octets pour la balise d'authentification AEAD (Authenticated Encryption with Associated Data), pour un total de 51 octets de surcharge, ce qui correspond au remplissage des paquets QUIC INITIAL à 1331 octets ou plus.)

• Les points de terminaison de relais IP peuvent également envoyer des demandes d'écho ICMPv6 avec 1232 octets de données pour vérifier la MTU de la liaison et démonter le tunnel s'ils ne reçoivent pas de réponse. À moins que les points de terminaison n'aient un moyen hors bande de garantir que les techniques précédentes sont suffisantes, ils DOIVENT utiliser cette méthode. Si un point de terminaison ne connaît pas une adresse IPv6 de son pair, il peut envoyer la demande d'écho ICMPv6 à l'adresse de multidiffusion de tous les nœuds lien-local (ff02::1).

Si un point de terminaison utilise des trames QUIC DATAGRAM pour transmettre des paquets IPv6 et qu'il détecte que la MTU QUIC est trop basse pour permettre l'envoi de 1280 octets, il DOIT abandonner le flux de requête de relais IP.

7.2.1. Signalisation d'erreur

Puisque les points de terminaison de relais IP transfèrent souvent des paquets IP vers d'autres interfaces réseau, ils doivent gérer les erreurs dans le processus de transfert. Par exemple, le transfert peut échouer si le point de terminaison n'a pas de route pour l'adresse de destination, s'il est configuré pour rejeter un préfixe de destination par politique, ou si la MTU de la liaison sortante est inférieure à la taille du paquet à transférer. Dans de tels scénarios, les points de terminaison de relais IP DEVRAIENT utiliser ICMP [ICMP] [ICMPv6] pour signaler l'erreur de transfert à son pair en générant des paquets ICMP et en les envoyant à l'aide de datagrammes HTTP.

Les points de terminaison sont libres de sélectionner les erreurs ICMP les plus appropriées à envoyer. Quelques exemples pertinents pour le relais IP incluent les suivants :

• Pour les adresses source invalides, envoyer Destination Unreachable (Destination inaccessible) (Section 3.1 de ICMPv6) avec le code 5, "Source address failed ingress/egress policy" (L'adresse source a échoué à la politique d'entrée/sortie).

• Pour les adresses de destination non routables, envoyer Destination Unreachable (Destination inaccessible) (Section 3.1 de ICMPv6) avec le code 0, "No route to destination" (Pas de route vers la destination), ou le code 1, "Communication with destination administratively prohibited" (Communication avec la destination administrativement interdite).

• Pour les paquets qui ne peuvent pas tenir dans la MTU de la liaison sortante, envoyer Packet Too Big (Paquet trop grand) (Section 3.2 de ICMPv6).

Afin de recevoir ces erreurs, les points de terminaison doivent être préparés à recevoir des paquets ICMP. Si un point de terminaison n'envoie pas de capsules ROUTE_ADVERTISEMENT, comme un client ouvrant un flux IP via un proxy IP, il DEVRAIT traiter les paquets ICMP relayés de son pair afin de recevoir ces erreurs. Notez que les messages ICMP peuvent provenir d'une adresse source différente de celle du pair de relais IP et également de l'extérieur de la cible si la limitation de portée est utilisée (voir Section 4.6).