Aller au contenu principal

4. Tunnelisation IP sur HTTP

Pour permettre la négociation d'un tunnel pour IP sur HTTP, ce document définit le jeton de mise à niveau HTTP "connect-ip". Les tunnels IP résultants utilisent le protocole Capsule (voir Section 3.2 de HTTP-DGRAM) avec des datagrammes HTTP au format défini dans la Section 6.

Pour initier un tunnel IP associé à un seul flux HTTP, un client émet une requête contenant le jeton de mise à niveau "connect-ip".

Lors de l'envoi de sa requête de relais IP, le client DOIT effectuer une expansion de modèle d'URI pour déterminer le chemin et la requête de sa demande ; voir Section 3.

En vertu de la définition du protocole Capsule (voir Section 3.2 de HTTP-DGRAM), les requêtes de relais IP ne transportent aucun contenu de message. De même, les réponses de relais IP réussies ne transportent également aucun contenu de message.

Le relais IP sur HTTP DOIT être exploité sur un chiffrement TLS ou QUIC, ou un autre protocole de chiffrement équivalent, pour fournir confidentialité, intégrité et authentification.

4.1. Gestion du proxy IP​

À la réception d'une requête de relais IP :

  • Si le destinataire est configuré pour utiliser un autre serveur HTTP, il agira comme intermédiaire en transférant la requête à l'autre serveur HTTP. Notez que de tels intermédiaires peuvent avoir besoin de ré-encoder la requête s'ils la transfèrent en utilisant une version de HTTP différente de celle utilisée pour la recevoir, car l'encodage de la requête diffère selon la version (voir ci-dessous).

  • Sinon, le destinataire agira comme un proxy IP. Le proxy IP peut choisir de rejeter la requête de relais IP. Sinon, il extrait les variables facultatives "target" et "ipproto" de l'URI qu'il a reconstruit à partir des en-têtes de requête, décode leur encodage en pourcentage et établit un tunnel IP.

Les proxys IP DOIVENT valider si les variables "target" et "ipproto" décodées répondent aux exigences de la Section 4.6. Si elles ne le font pas, le proxy IP DOIT traiter la requête comme malformée ; voir Section 8.1.1 de HTTP/2 et Section 4.1.2 de HTTP/3. Si la variable "target" est un nom DNS, le proxy IP DOIT effectuer une résolution DNS (pour obtenir les adresses IPv4 et/ou IPv6 correspondantes via des enregistrements A et/ou AAAA) avant de répondre à la requête HTTP. Si des erreurs se produisent au cours de ce processus, le proxy IP DOIT rejeter la requête et DEVRAIT envoyer des détails en utilisant un champ d'en-tête Proxy-Status approprié [PROXY-STATUS]. Par exemple, si la résolution DNS renvoie une erreur, le proxy peut utiliser le type d'erreur de proxy dns_error de la Section 2.3.2 de PROXY-STATUS.

La durée de vie du tunnel de transfert IP est liée au flux de requête de relais IP. Le proxy IP DOIT maintenir toutes les assignations d'adresses IP et de routes associées au tunnel de transfert IP tant que le flux de requête est ouvert. Les proxys IP PEUVENT choisir de démonter le tunnel en raison d'une période d'inactivité, mais ils DOIVENT fermer le flux de requête lorsqu'ils le font.

Une réponse de relais IP réussie (telle que définie dans les Sections 4.3 et 4.5) indique que le proxy IP a établi un tunnel IP et est prêt à relayer des charges utiles IP. Toute réponse autre qu'une réponse de relais IP réussie indique que la requête a échoué ; par conséquent, le client DOIT abandonner la requête.

Parallèlement à une réponse de relais IP réussie, le proxy IP peut envoyer des capsules pour assigner des adresses et annoncer des routes au client (Section 4.7). Le client peut également assigner des adresses et annoncer des routes au proxy IP pour le routage réseau à réseau.

4.2. Requête HTTP/1.1​

Lors de l'utilisation de HTTP/1.1 [HTTP/1.1], une requête de relais IP répondra aux exigences suivantes :

  • La méthode DOIT être "GET".

  • La requête DOIT inclure un seul champ d'en-tête Host contenant l'hôte et le port facultatif du proxy IP.

  • La requête DOIT inclure un champ d'en-tête Connection avec la valeur "Upgrade" (notez que cette exigence est insensible à la casse, conformément à la Section 7.6.1 de HTTP).

  • La requête DOIT inclure un champ d'en-tête Upgrade avec la valeur "connect-ip".

Une requête de relais IP qui ne se conforme pas à ces restrictions est malformée. Le destinataire d'une telle requête malformée DOIT répondre par une erreur et DEVRAIT utiliser le code d'état 400 (Bad Request).

Par exemple, si le client est configuré avec le modèle d'URI "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" et souhaite ouvrir un tunnel de transfert IP sans limitations de cible ou de protocole, il pourrait envoyer la requête suivante :

GET https://example.org/.well-known/masque/ip/*/*/ HTTP/1.1
Host: example.org
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

Figure 2 : Exemple de requête HTTP/1.1

4.3. Réponse HTTP/1.1​

Le serveur indique une réponse de relais IP réussie en répondant avec les exigences suivantes :

  • Le code d'état HTTP sur la réponse DOIT être 101 (Switching Protocols).

  • La réponse DOIT inclure un champ d'en-tête Connection avec la valeur "Upgrade" (notez que cette exigence est insensible à la casse, conformément à la Section 7.6.1 de HTTP).

  • La réponse DOIT inclure un seul champ d'en-tête Upgrade avec la valeur "connect-ip".

  • La réponse DOIT répondre aux exigences des réponses HTTP qui démarrent le protocole Capsule ; voir Section 3.2 de HTTP-DGRAM.

Si l'une de ces exigences n'est pas satisfaite, le client DOIT traiter cette tentative de relais comme un échec et fermer la connexion.

Par exemple, le serveur pourrait répondre avec :

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

Figure 3 : Exemple de réponse HTTP/1.1

4.4. Requêtes HTTP/2 et HTTP/3​

Lors de l'utilisation de HTTP/2 [HTTP/2] ou HTTP/3 [HTTP/3], les requêtes de relais IP utilisent HTTP Extended CONNECT. Cela nécessite que les serveurs envoient un paramètre HTTP (HTTP Setting), tel que spécifié dans [EXT-CONNECT2] et [EXT-CONNECT3], et que les requêtes utilisent des champs de pseudo-en-tête HTTP avec les exigences suivantes :

  • Le champ de pseudo-en-tête :method DOIT être "CONNECT".

  • Le champ de pseudo-en-tête :protocol DOIT être "connect-ip".

  • Le champ de pseudo-en-tête :authority DOIT contenir l'autorité du proxy IP.

  • Les champs de pseudo-en-tête :path et :scheme NE DOIVENT PAS être vides. Leurs valeurs DOIVENT contenir le schéma et le chemin du modèle d'URI une fois le processus d'expansion du modèle d'URI terminé ; voir Section 3. Les variables dans le modèle d'URI peuvent déterminer la portée de la requête, comme la demande de transfert de paquets IP en tunnel complet, ou un flux relayé spécifique ; voir Section 4.6.

Une requête de relais IP qui ne se conforme pas à ces restrictions est malformée ; voir Section 8.1.1 de HTTP/2 et Section 4.1.2 de HTTP/3.

Par exemple, si le client est configuré avec le modèle d'URI "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" et souhaite ouvrir un tunnel de transfert IP sans limitations de cible ou de protocole, il pourrait envoyer la requête suivante :

HEADERS
:method = CONNECT
:protocol = connect-ip
:scheme = https
:path = /.well-known/masque/ip/*/*/
:authority = example.org
capsule-protocol = ?1

Figure 4 : Exemple de requête HTTP/2 ou HTTP/3

4.5. Réponses HTTP/2 et HTTP/3​

Le serveur indique une réponse de relais IP réussie en répondant avec les exigences suivantes :

  • Le code d'état HTTP sur la réponse DOIT être dans la plage 2xx (Succès).

  • La réponse DOIT répondre aux exigences des réponses HTTP qui démarrent le protocole Capsule ; voir Section 3.2 de HTTP-DGRAM.

Si l'une de ces exigences n'est pas satisfaite, le client DOIT traiter cette tentative de relais comme un échec et abandonner la requête. À titre d'exemple, tout code d'état dans la plage 3xx sera traité comme un échec et amènera le client à abandonner la requête.

Par exemple, le serveur pourrait répondre avec :

HEADERS
:status = 200
capsule-protocol = ?1

Figure 5 : Exemple de réponse HTTP/2 ou HTTP/3

4.6. Limitation de la portée de la requête​

Contrairement aux requêtes de relais UDP, qui nécessitent de spécifier un hôte cible, les requêtes de relais IP peuvent permettre aux points de terminaison d'envoyer des paquets IP arbitraires à n'importe quel hôte. Le client peut choisir de restreindre une requête donnée à un préfixe IP ou un protocole IP spécifique en ajoutant des paramètres à sa requête. Lorsque le proxy IP sait qu'une requête est limitée à un préfixe ou un protocole cible, il peut exploiter cette information pour optimiser son allocation de ressources ; par exemple, le proxy IP peut assigner la même adresse IP publique à deux requêtes de relais IP qui sont limitées à des préfixes différents et/ou des protocoles différents.

La portée de la requête est indiquée par le client au proxy IP via les variables "target" et "ipproto" du modèle d'URI ; voir Section 3. Les variables "target" et "ipproto" sont toutes deux facultatives ; si elles ne sont pas incluses, elles sont considérées comme portant la valeur générique "*".

target : La variable "target" contient un nom d'hôte ou un préfixe IP d'un hôte spécifique vers lequel le client souhaite relayer les paquets. Si la variable "target" n'est pas spécifiée ou si sa valeur est "*", le client demande à communiquer avec tout hôte autorisé. "target" prend en charge l'utilisation de noms DNS, de préfixes IPv6 et de préfixes IPv4. Notez que les identifiants de zone d'adressage de portée IPv6 [IPv6-ZONE-ID] ne sont pas pris en charge. Si la cible est un préfixe IP (adresse IP éventuellement suivie d'une barre oblique encodée en pourcentage suivie de la longueur du préfixe en bits), la requête ne prendra en charge qu'une seule version IP. Si la cible est un nom d'hôte, le proxy IP est censé effectuer une résolution DNS pour déterminer quelle(s) route(s) annoncer au client. Le proxy IP DEVRAIT envoyer une capsule ROUTE_ADVERTISEMENT qui inclut des routes pour toutes les adresses qui ont été résolues pour le nom d'hôte demandé, qui sont accessibles au proxy IP et appartiennent à une famille d'adresses pour laquelle le proxy IP envoie également une adresse assignée.

ipproto : La variable "ipproto" contient un numéro de protocole Internet ; voir la liste définie dans le registre IANA "Assigned Internet Protocol Numbers" [IANA-PN]. Si elle est présente, elle spécifie qu'un client souhaite uniquement relayer un protocole IP spécifique pour cette requête. Si la valeur est "*", ou si la variable n'est pas incluse, le client demande à utiliser n'importe quel protocole IP. Le protocole IP indiqué dans la variable "ipproto" représente une valeur d'en-tête suivant autorisée transportée dans les en-têtes IP qui sont directement envoyés dans les datagrammes HTTP (les en-têtes IP les plus externes). Le trafic ICMP est toujours autorisé, quelle que soit la valeur de ce champ.

En utilisant les termes IPv6address, IPv4address et reg-name de [URI], les variables "target" et "ipproto" DOIVENT respecter le format de la Figure 6, en utilisant la notation de [ABNF]. De plus :

  • Si "target" contient un littéral ou un préfixe IPv6, les deux-points (":") DOIVENT être encodés en pourcentage. Par exemple, si l'hôte cible est "2001:db8::42", il sera encodé dans l'URI comme "2001%3Adb8%3A%3A42".

  • Si elle est présente, la longueur du préfixe IP dans "target" DOIT être précédée d'une barre oblique encodée en pourcentage ("/") : "%2F". La longueur du préfixe IP DOIT représenter un entier décimal compris entre 0 et la longueur de l'adresse IP en bits, inclus.

  • Si "target" contient un préfixe IP et que la longueur du préfixe est strictement inférieure à la longueur de l'adresse IP en bits, les bits inférieurs de l'adresse IP qui ne sont pas couverts par la longueur du préfixe DOIVENT tous être mis à 0.

  • "ipproto" DOIT représenter un entier décimal compris entre 0 et 255 inclus ou la valeur générique "*".

target = IPv6prefix / IPv4prefix / reg-name / "*"
IPv6prefix = IPv6address ["%2F" 1*3DIGIT]
IPv4prefix = IPv4address ["%2F" 1*2DIGIT]
ipproto = 1*3DIGIT / "*"

Figure 6 : Format de variable de modèle d'URI

Les proxys IP PEUVENT effectuer un contrôle d'accès en utilisant les informations de portée fournies par le client, c'est-à-dire que si le client n'est pas autorisé à accéder à l'une des destinations incluses dans la portée, alors le proxy IP peut immédiatement rejeter la requête.

4.7. Capsules​

Ce document définit plusieurs nouveaux types de capsules qui permettent aux points de terminaison d'échanger des informations de configuration IP. Les deux points de terminaison PEUVENT envoyer un nombre quelconque de ces nouvelles capsules.

4.7.1. Capsule ADDRESS_ASSIGN​

La capsule ADDRESS_ASSIGN (type de capsule 0x01) permet à un point de terminaison d'assigner à son pair une liste d'adresses ou de préfixes IP. Chaque capsule contient la liste complète des préfixes IP actuellement assignés au destinataire. N'importe laquelle de ces adresses peut être utilisée comme adresse source sur les paquets IP émis par le destinataire de cette capsule.

ADDRESS_ASSIGN Capsule {
  Type (i) = 0x01,
  Length (i),
  Assigned Address (..) ...,
}

Figure 7 : Format de capsule ADDRESS_ASSIGN

La capsule ADDRESS_ASSIGN contient une séquence de zéro ou plusieurs adresses assignées.

Assigned Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

Figure 8 : Format d'adresse assignée

Chaque adresse assignée contient les champs suivants :

Request ID (ID de requête) : Identifiant de requête, encodé comme un entier de longueur variable. Si cette assignation d'adresse est en réponse à une requête d'adresse (voir Section 4.7.2), alors ce champ DOIT contenir la valeur du champ correspondant dans la requête. Sinon, ce champ DOIT être zéro.

IP Version (Version IP) : Version IP de cette assignation d'adresse, encodée comme un entier non signé de 8 bits. Elle DOIT être soit 4 soit 6.

IP Address (Adresse IP) : Adresse IP assignée. Si le champ IP Version a la valeur 4, le champ IP Address DOIT avoir une longueur de 32 bits. Si le champ IP Version a la valeur 6, le champ IP Address DOIT avoir une longueur de 128 bits.

IP Prefix Length (Longueur de préfixe IP) : Le nombre de bits dans l'adresse IP qui sont utilisés pour définir le préfixe qui est assigné, encodé comme un entier non signé de 8 bits. Cela DOIT être inférieur ou égal à la longueur du champ IP Address en bits. Si la longueur du préfixe est égale à la longueur de l'adresse IP, le destinataire de cette capsule est autorisé à envoyer des paquets à partir d'une seule adresse source. Si la longueur du préfixe est inférieure à la longueur de l'adresse IP, le destinataire de cette capsule est autorisé à envoyer des paquets à partir de n'importe quelle adresse source qui tombe dans le préfixe. Si la longueur du préfixe est strictement inférieure à la longueur de l'adresse IP en bits, les bits inférieurs du champ IP Address qui ne sont pas couverts par la longueur du préfixe DOIVENT tous être mis à 0.

Si l'un des champs de la capsule est malformé lors de la réception, le destinataire de la capsule DOIT suivre la procédure de gestion des erreurs définie dans la Section 3.3 de HTTP-DGRAM.

Si une capsule ADDRESS_ASSIGN ne contient pas une adresse qui a été précédemment transmise dans une autre capsule ADDRESS_ASSIGN, cela indique que l'adresse a été supprimée. Une capsule ADDRESS_ASSIGN peut également être vide, indiquant que toutes les adresses ont été supprimées.

Dans certains déploiements de relais IP dans HTTP, un point de terminaison doit se voir assigner une adresse par son pair avant de savoir quelle adresse source définir sur ses propres paquets. Par exemple, dans le cas du VPN d'accès à distance (Section 8.1), le client ne peut pas envoyer de paquets IP tant qu'il ne sait pas quelle adresse utiliser. Dans ces déploiements, le point de terminaison qui attend une assignation d'adresse DOIT envoyer une capsule ADDRESS_REQUEST. Ce n'est pas nécessaire si le point de terminaison n'a besoin d'aucune assignation d'adresse, par exemple, lorsqu'il est configuré hors bande avec des adresses statiques.

Bien que les capsules ADDRESS_ASSIGN soient couramment envoyées en réponse aux capsules ADDRESS_REQUEST, les points de terminaison PEUVENT envoyer des capsules ADDRESS_ASSIGN spontanément.

4.7.2. Capsule ADDRESS_REQUEST​

La capsule ADDRESS_REQUEST (type de capsule 0x02) permet à un point de terminaison de demander l'assignation d'adresses IP à son pair. La capsule permet au point de terminaison d'indiquer facultativement une préférence pour l'adresse qui lui serait assignée.

ADDRESS_REQUEST Capsule {
  Type (i) = 0x02,
  Length (i),
  Requested Address (..) ...,
}

Figure 9 : Format de capsule ADDRESS_REQUEST

La capsule ADDRESS_REQUEST contient une séquence d'une ou plusieurs adresses demandées.

Requested Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

Figure 10 : Format d'adresse demandée

Chaque adresse demandée contient les champs suivants :

Request ID (ID de requête) : Identifiant de requête, encodé comme un entier de longueur variable. C'est l'identifiant de cette demande d'adresse spécifique. Chaque demande d'un point de terminaison donné porte un identifiant différent. Les ID de requête NE DOIVENT PAS être réutilisés par un point de terminaison et NE DOIVENT PAS être zéro.

IP Version (Version IP) : Version IP de cette demande d'adresse, encodée comme un entier non signé de 8 bits. Elle DOIT être soit 4 soit 6.

IP Address (Adresse IP) : Adresse IP demandée. Si le champ IP Version a la valeur 4, le champ IP Address DOIT avoir une longueur de 32 bits. Si le champ IP Version a la valeur 6, le champ IP Address DOIT avoir une longueur de 128 bits.

IP Prefix Length (Longueur de préfixe IP) : Longueur du préfixe IP demandé en bits, encodée comme un entier non signé de 8 bits. Elle DOIT être inférieure ou égale à la longueur du champ IP Address en bits. Si la longueur du préfixe est strictement inférieure à la longueur de l'adresse IP en bits, les bits inférieurs du champ IP Address qui ne sont pas couverts par la longueur du préfixe DOIVENT tous être mis à 0.

Si l'adresse IP est entièrement à zéro (0.0.0.0 ou ::), cela indique que l'expéditeur demande une adresse de cette famille d'adresses mais n'a pas de préférence pour une adresse spécifique. Dans ce scénario, la longueur du préfixe indique toujours la préférence de l'expéditeur pour la longueur du préfixe qu'il demande.

Si l'un des champs de la capsule est malformé lors de la réception, le destinataire de la capsule DOIT suivre la procédure de gestion des erreurs définie dans la Section 3.3 de HTTP-DGRAM.

À la réception de la capsule ADDRESS_REQUEST, un point de terminaison DEVRAIT assigner une ou plusieurs adresses IP à son pair, puis répondre avec une capsule ADDRESS_ASSIGN pour informer le pair de l'assignation. Pour chaque adresse demandée, le destinataire de la capsule ADDRESS_REQUEST DOIT répondre avec une adresse assignée avec un ID de requête correspondant. Si l'adresse demandée a été assignée, les champs IP Address et IP Prefix Length dans la réponse d'adresse assignée DOIVENT être définis sur les valeurs assignées. Si l'adresse demandée n'a pas été assignée, l'adresse IP DOIT être entièrement à zéro, et la longueur du préfixe IP DOIT être la longueur maximale (0.0.0.0/32 ou ::/128) pour indiquer qu'aucune adresse n'a été assignée. Ces rejets d'adresse NE DEVRAIENT PAS être inclus dans les capsules ADDRESS_ASSIGN ultérieures. Notez que d'autres entrées d'adresse assignée qui ne correspondent à aucun ID de requête peuvent également être contenues dans la même réponse ADDRESS_ASSIGN.

Si un point de terminaison reçoit une capsule ADDRESS_REQUEST qui contient zéro adresse demandée, il DOIT abandonner le flux de requête de relais IP.

Notez que l'ordre des adresses demandées ne porte aucune sémantique. De même, l'ID de requête n'est conçu que comme un identifiant unique ; il ne transmet aucune priorité ou importance.

4.7.3. Capsule ROUTE_ADVERTISEMENT​

La capsule ROUTE_ADVERTISEMENT (type de capsule 0x03) permet à un point de terminaison de communiquer à son pair qu'il est prêt à router le trafic vers un ensemble de plages d'adresses IP. Cela indique que l'expéditeur a une route existante vers chaque plage d'adresses et notifie son pair que, si le destinataire de la capsule ROUTE_ADVERTISEMENT envoie des paquets IP pour l'une de ces plages dans des datagrammes HTTP, l'expéditeur de la capsule les transférera le long de sa route préexistante. Toute adresse qui se trouve dans l'une des plages d'adresses peut être utilisée comme adresse de destination sur les paquets IP émis par le destinataire de cette capsule.

ROUTE_ADVERTISEMENT Capsule {
  Type (i) = 0x03,
  Length (i),
  IP Address Range (..) ...,
}

Figure 11 : Format de capsule ROUTE_ADVERTISEMENT

La capsule ROUTE_ADVERTISEMENT contient une séquence de zéro ou plusieurs plages d'adresses IP.

IP Address Range {
  IP Version (8),
  Start IP Address (32..128),
  End IP Address (32..128),
  IP Protocol (8),
}

Figure 12 : Format de plage d'adresses IP

Chaque plage d'adresses IP contient les champs suivants :

IP Version (Version IP) : Version IP de cette plage, encodée comme un entier non signé de 8 bits. Elle DOIT être soit 4 soit 6.

Start IP Address et End IP Address (Adresse IP de début et Adresse IP de fin) : Adresse IP de début et de fin inclusive de la plage annoncée. Si le champ IP Version a la valeur 4, ces champs DOIVENT avoir une longueur de 32 bits. Si le champ IP Version a la valeur 6, ces champs DOIVENT avoir une longueur de 128 bits. L'adresse IP de début DOIT être inférieure ou égale à l'adresse IP de fin.

IP Protocol (Protocole IP) : Le numéro de protocole Internet pour le trafic qui peut être envoyé vers cette plage, encodé comme un entier non signé de 8 bits. Si la valeur est 0, tous les protocoles sont autorisés. Si la valeur n'est pas 0, elle représente une valeur d'en-tête suivant autorisée transportée dans les en-têtes IP qui sont envoyés directement dans les datagrammes HTTP (les en-têtes IP les plus externes). Le trafic ICMP est toujours autorisé, quelle que soit la valeur de ce champ.

Si l'un des champs de la capsule est malformé lors de la réception, le destinataire de la capsule DOIT suivre la procédure de gestion des erreurs définie dans la Section 3.3 de HTTP-DGRAM.

À la réception de la capsule ROUTE_ADVERTISEMENT, un point de terminaison PEUT mettre à jour son état local concernant ce que son pair est prêt à router (sous réserve de la politique locale), par exemple en installant des entrées dans une table de routage.

Chaque ROUTE_ADVERTISEMENT contient la liste complète des plages d'adresses. Si plusieurs capsules ROUTE_ADVERTISEMENT sont envoyées dans une direction, chaque capsule ROUTE_ADVERTISEMENT remplace les précédentes. En d'autres termes, si une plage d'adresses donnée était présente dans une capsule précédente mais que la capsule ROUTE_ADVERTISEMENT la plus récemment reçue ne la contient pas, le destinataire considérera que cette plage est retirée.

Si plusieurs plages utilisant le même protocole IP devaient se chevaucher, certaines implémentations de table de routage pourraient les rejeter. Pour éviter le chevauchement, les plages sont ordonnées ; cela place la charge sur l'expéditeur et rend la vérification par le destinataire beaucoup plus simple. Si une plage d'adresses IP A précède une plage d'adresses IP B dans la même capsule ROUTE_ADVERTISEMENT, elles DOIVENT suivre ces exigences :

  • La version IP de A DOIT être inférieure ou égale à la version IP de B.

  • Si la version IP de A et B sont égales, le protocole IP de A DOIT être inférieur ou égal au protocole IP de B.

  • Si la version IP et le protocole IP de A et B sont tous deux égaux, l'adresse IP de fin de A DOIT être strictement inférieure à l'adresse IP de début de B.

Si un point de terminaison reçoit une capsule ROUTE_ADVERTISEMENT qui ne répond pas à ces exigences, il DOIT abandonner le flux de requête de relais IP.

Puisque le réglage du protocole IP à zéro indique que tous les protocoles sont autorisés, les exigences ci-dessus permettent à deux routes de se chevaucher lorsque l'une a son protocole IP défini à zéro et l'autre l'a défini à une valeur non nulle. Les points de terminaison NE DOIVENT PAS envoyer une capsule ROUTE_ADVERTISEMENT avec des routes qui se chevauchent de telle manière. La validation de cette exigence est FACULTATIVE, mais si un point de terminaison détecte la violation, il DOIT abandonner le flux de requête de relais IP.

4.8. En-têtes d'extension IPv6​

La limitation de la portée de la requête (voir Section 4.6) et la capsule ROUTE_ADVERTISEMENT (voir Section 4.7.3) utilisent toutes deux des numéros de protocole Internet. Ces numéros représentent à la fois les couches supérieures (telles que définies dans la Section 2 de IPv6, avec des exemples incluant TCP et UDP) et les en-têtes d'extension IPv6 (tels que définis dans la Section 4 de IPv6, avec des exemples incluant les en-têtes de fragment et d'options). Les proxys IP PEUVENT rejeter les demandes de limitation de portée aux numéros de protocole qui sont utilisés pour les en-têtes d'extension. À la réception de paquets, les implémentations qui prennent en charge la limitation de portée ou le routage par numéro de protocole Internet DOIVENT parcourir la chaîne d'extensions pour trouver le numéro de protocole Internet non-extension le plus externe pour correspondre à la règle de limitation de portée. Notez que la capsule ROUTE_ADVERTISEMENT utilise le numéro de protocole Internet 0 pour indiquer que tous les protocoles sont autorisés ; cela ne restreint pas la route à l'en-tête d'options pas à pas IPv6 (Section 4.3 de IPv6).

Dernière mise à jour le