FR2873254A1 - Encapsulation pour paquets a adresses etendues compatibles avec des pare-feux existants - Google Patents

Abstract

L'invention concerne un dispositif d'émission de paquets dans un réseau, comprenant un module de traitement de paquets, apte à préparer l'émission d'un paquet comportant un en-tête de type IP, en particulier de type IPv4, comprenant au moins un champ source (SA) et un champ destination (DA), ce paquet ayant vocation à recevoir des données établies selon un protocole de niveau supérieur. Le module de traitement de paquets est apte à préparer l'émission de paquets dans lesquels au moins une partie (DA6) de l'adresse destination est située en dehors dudit en-tête, dans une zone choisie pour préserver le fonctionnement de filtrages de pare-feu fondés sur l'en-tête du dit protocole de niveau supérieur.

Description

L Despresl2.frd.

ENCAPSULATION POUR PAQUETS A ADRESSES E1ENDUES COMPATIBLE AVEC DES PAREFEUX EXISTANTS L'invention concerne le traitement des paquets de données sur un réseau, selon un protocole tel que le protocole Internet (IP).

On sait qu'il existe aussi des protocoles de niveau supérieur à celui du protocole Internet. 10 On les appelle ici "protocoles de niveau 4 (ou plus)".

Pour étendre le nombre des adresses utilisables sur le réseau Internet par rapport à ce qui est possible avec le format de paquets IPv4, aux adresses de 32 bits, divers formats de paquets à adresses plus étendues ont été définis, notamment le format de paquet IPv6 à adresses de 128 bits.

De plus, pour que des paquets à adresses étendues puissent traverser des parties du réseau restées en IPv4, divers formats de paquets, dits formats d'encapsulation, ont été définis. Ils sont tels que des champs contenant tout ou partie des adresses étendues sont 2 0 situés en dehors des en-têtes IPv4 et tels que des routeurs IPv4 peuvent les acheminer d'un équipement qui connaisse le format à adresses étendues à un autre. C'est le cas notamment avec l'encapsulation dite "6to4" du RFC 3056 ou encore avec l'encapsulation décrite dans la demande de brevet français N 04 05 288, déposée le 14 mai 2004 au nom du Demandeur.

Ces formats d'encapsulation connus ont toutefois comme limite qu'ils mettent en échec les fonctions de filtrage des pare-feux IPv4, y compris les fonctions de ces pare-feux qui font intervenir sans mémoire d'état les seuls en-têtes des protocoles de niveau supérieur à IP (niveau 4), alors que ceux-ci sont d'une grande utilité pratique.

La présente invention a notamment pour premier objectif de permettre à des paquets comprenant des adresses étendues de traverser des parties de réseaux où opèrent certains pare-feux IPv4 tout en permettant à ceux-ci d'effectuer leurs filtrages fondés sur les en-têtes des protocoles de niveau 4. r

Un deuxième objectif est que des équipements qui reçoivent aussi bien des paquets au format IPv4 sans encapsulation que des paquets IPv4 avec encapsulation, disposent d'un test sur les paquets reçus pour faire la distinction entre les deux formats.

Il est proposé un dispositif d'émission de paquets dans un réseau, comprenant un module de traitement de paquets, apte à préparer l'émission d'un paquet comportant un en-tête de type IP, en particulier de type IPv4, comprenant au moins un champ source et un champ destination, ce paquet ayant vocation à recevoir des données établies selon un protocole de niveau supérieur.

Selon un premier aspect de l'invention, le module de traitement de paquets est apte à préparer l'émission de paquets dans lesquels au moins une partie de l'adresse destination est située en dehors dudit en-tête, dans une zone choisie pour préserver le fonctionnement de filtrages de pare-feu fondés sur l'en-tête du dit protocole de niveau supérieur.

Selon un second aspect de l'invention, le paquet comprend au moins une indication permettant de distinguer entre un paquet où l'adresse de destination est totalement contenue dans ledit champ destination, et un paquet où au moins une partie de l'adresse 2 0 destination est située en dehors dudit en-tête.

Selon un autre aspect de l'invention, ladite indication comprend la présence d'une marque de Fragment à suivre et au moins une valeur particulière du champ Décalage de fragment, décalage au moyen duquel les données de chaque paquet d'un datagramme fragmenté sont situées dans l'ensemble du datagramme.

Selon encore un autre aspect de l'invention, venant en variante ou en complément du précédent, là où le protocole de niveau supérieur à IP est un protocole à datagrammes, tel qu'UDP, ladite indication comprend un ensemble de valeurs particulières du champ de 3 0 l'en-tête UDP qui indique la longueur totale du datagramme.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels: - la figure 1 est un schéma illustrant le format d'un paquet au protocole Internet version 4 (IPv4), - la figure 2 est un schéma illustrant le format d'un paquet au protocole Internet version 6 (IPv6), la figure 3 est un schéma illustrant le format d'un paquet ici proposé (dit "6sur4" ou "6on4"), - la figure 4 est un organigramme de reconnaissance du format "6sur4" de la figure 3 à la réception d'un paquet IPv4, - la figure 5 est un organigramme de conversion du format IPv6 de la figure 2 en format "6sur4" de la figure 3, et - la figure 6 est un organigramme de conversion inverse du format "6sur4" de la figure 3 en format IPv6 de la figure 2.

Les dessins contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront 15 donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant.

La présente description peut faire intervenir des éléments susceptibles de protection par le droit d'auteur et/ou le copyright. Le titulaire des droits n'a pas d'objection à la reproduction à l'identique par quiconque du présent document de brevet ou de sa partie descriptive, telle qu'elle apparaît dans les dossiers officiels. Pour le reste, il réserve intégralement ses droits.

Bien qu'elle soit éventuellement d'application plus générale, l'invention sera décrite ci- après dans le contexte d'un exemple particulier, qui est le protocole Internet ou IP.

La présente demande de brevet propose différents moyens qui peuvent être utilisés ensemble, séparément, ou encore en différentes combinaisons ou sous-combinaisons.

Ces moyens pourront être exprimés sous forme de choix particuliers, bien entendu généralisables, qui seront décrits dans la suite pour atteindre les objectifs précités, au moins partiellement. Ces choix particuliers tirent parti de propriétés suivantes des protocoles existants et des logiciels qui les mettent en oeuvre: É Le protocole IPv4 prévoit que les stations émettrices puissent décomposer un datagramme, c'est à dire une unité traitée par le protocole de niveau supérieur, en plusieurs paquets, chacun contenant un fragment du datagramme. Les paquets IPv4 contiennent pour cela un champ "Décalage du fragment" dont la valeur indique la position du fragment dans le datagramme. Celui-ci est à 0 dans les paquets d'un "premier fragment" (premier fragment d'un datagramme fragmenté ou intégralité d'un datagramme non fragmenté), et non nul dans les paquets d'un autre fragment (dit "fragment suivant"). Il est exprimé sur 13 bits en nombre de blocs de 8 octets. Les paquets IPv4 contiennent aussi un indicateur "Fragments à suivre". Celui-ci est à 0 pour le dernier (ou unique) fragment d'un datagramme, et à 1 pour tous les précédents.

É Les routeurs IPv4 peuvent eux aussi fragmenter les paquets qu'ils reçoivent, s'ils ont à les faire suivre dans une partie de réseau où la longueur maximale admise pour les paquets le nécessite. Cette faculté n'est toutefois mise en oeuvre que si l'indicateur "Ne pas fragmenter" de l'en-tête IPv4 soit à O. S'il est à 1, les paquets trop grands sont éliminés.

É Après que des difficultés diverses liées au ré-assemblage des fragments dans les 2 0 stations destinataires aient été rencontrées, la fragmentation par les routeurs est tombée en désuétude, les sources positionnant systématiquement l'indicateur "Ne pas fragmenter" à 1. De plus, le protocole de niveau 4 TCP est systématiquement utilisé sans fragmentation par les sources, donc sans aucune fragmentation.

É Si le protocole de niveau 4 est UDP, la plupart des applications limitent la longueur 2 5 des données transmises dans un datagramme à 512 octets. La raison en est que les stations destinataires sont autorisées à limiter la longueur des datagrammes qu'elles réassemblent à n'importe quelle valeur d'au moins 596 octets. Dans sa station destinataire, un datagramme trop long pour être réassemblé est soit délivré partiellement à l'application, les octets au-delà de la limite du tampon de 3 0 réassemblage étant perdus, soit éliminé.

É Malgré ce seuil de 596 octets, l'application NFS, importante pour certains partages de fichiers sous UNIX, transmet des blocs de 8.192 octets en un seul datagramme. En conséquence, la plupart des systèmes d'exploitation situent la longueur maximale des datagrammes légèrement audelà de cette valeur.

É Les datagrammes UDP comprennent dans leur en-tête UDP un champ "Longueur de datagramme UDP", en nombre d'octets sur 16 bits.

É Lorsqu'un pare-feu qui opère sans mémoire d'état sur les seuls en-têtes de niveau 4 reçoit un paquet contenant un fragment suivant (ce qu'il reconnaît par la valeur non nulle de son champ "Décalage de fragment"), il doit le fait suivre systématiquement. Il ignore en effet si le premier paquet du datagramme, dans lequel se situent les informations de niveau 4 exploitées par le pare-feu, est déjà passé, ou doit passer ultérieurement suite à un changement de l'ordre des paquets au cours du trajet amont, ou encore ne passera jamais ici, étant passé par un autre chemin doté d'un autre pare-feu.

Selon un premier mode de réalisation particulier, on opère comme suit dans les paquets à adresse étendue: - mettre systématiquement le champ "Ne pas fragmenter" à 1 et le champ "Fragments à suivre" à 1, - mettre le champ "Décalage de fragment" à 0 dans le paquet d'un premier fragment - mettre le champ "Décalage de fragment" à une valeur différente de 0 pour les paquets 2 0 des fragments suivants, - maintenir dans le champ protocole IPv4 la marque du protocole de niveau 4 utilisé, au moins si ce protocole est un de ceux sur lesquels on souhaite une intervention des pare-feux, maintenir immédiatement après l'en-tête IPv4 les octets de l'en-tête de niveau 4 pour lesquels on souhaite une intervention des pare-feux, au moins dans les paquets 2 5 contenant un premier fragment.

On peut ainsi atteindre le premier objectif, à savoir la compatibilité avec les filtrages des pare-feux opérant au niveau 4 sans mémoire d'état.

Selon un second mode de réalisation particulier, compatible avec le premier, on opère comme suit:

JUS

(1) dans un paquet formant le premier fragment d'un datagramme UDP avec encapsulation, éviter tout champ IPv4 optionnel (le champ "Longueur d'entête" d'IPv4 vaut 5, ce qui indique une longueur de 20 octets); (2) le champ "Longueur de datagramme UDP" est mis à une valeur supérieure à la plus grande de l'usage normal, par exemple en forçant à 1 son bit de fort poids; (3) dans les paquets des fragments suivants le champ "Décalage de fragment" est mis à une valeur inférieure à la plus petite d'un usage normal, par exemple en lui donnant la 10 valeur 1.

Ceci peut fournir un test pertinent pour distinguer les paquets IPv4 sans encapsulation de ceux avec encapsulation. Le test peut être réalisé de la manière suivante: un paquet est alors traité comme un paquet avec encapsulation si: (1) le champ "Longueur d'en-tête" d'IPv4 vaut 5; (2) ses champs "Ne pas fragmenter" et "Fragments à suivre" sont à 1; 2 0 (3) le champ "Décalage de fragment" vaut 0 ou 1; (4) si le champ protocole contient la marque UDP et le champ "Décalage de fragment" est à 0, alors le bit de fort poids du champ "Longueur de datagramme UDP" est à 1.

On décrira maintenant de manière plus détaillée un mode de réalisation particulier, dit "6sur4" (ou "6on4") . Cette réalisation particulière repose sur l'encapsulation d'un paquet fonctionnellement équivalent à un paquet IPv6 mais formaté différemment.

Les champs d'un paquet IPv4 (figure 1) sont les suivants: 3 0 É V Version d'IP (= 4 pour IPv4) É L Longueur d'en-tête (en mots de 32 bits) É ToS Type de service (exploité par les routeurs) É TL Longueur totale du paquet (en octets) É ID Identificateur (utile lorsqu'il y a fragmentation) É DF Ne pas fragmenter É MF Fragments à suivre É FO Décalage de fragment É TTL Durée de vie (en pratique nombre maximum de routeurs à traverser en aval) É P Protocole de niveau 4 É HC Totalisation de contrôle de l'en-tête (calcul en complément à 1 sur 16 bits) É SA Adresse source É DA Adresse destination É D Données (un nombre quelconque d'octets, dans la limite de la taille de paquet supportée localement) É LUDP Longueur du datagramme UDP (champ qui n'existe que si P = "UDP" et FO = 0, en octets) Des champs optionnels peuvent de plus être insérés entre DA et D Les champs d'un paquet IPv6 (figure 2) sont les suivants: 2 0 É V Version d'IP (= 6 pour IPv6) É TC Classe de trafic (même signification que le ToS d'IPv4) É FL Etiquette de flux (utilisation non normalisée) É DL Longueur des données (y compris les éventuels champs d'extension IPv6 qui suivent l'en-tête IPv6, en octets) 2 5 É NH En-tête suivant (désigne le protocole de niveau 4 ou une extension IPv6 particulière) É HL Limite du nombre de sauts (même signification que le TTL d'IPv4) É SA Adresse source (comme en IPv4 mais de 128 bits au lieu de 32) É DA Adresse destination (idem) 3 0 É D Données (comme en IPv4) Des en-têtes d'extensions IPv6 optionnelles peuvent de plus être insérés entre DA et D. ee Les champs d'un paquet 6on4 où est encapsulé, en format modifié, un paquet IPv6 sont tout d'abord ceux de l'en-tête IPv4, définis comme suit (figure 3) : É V=4 É L=5 É ToS = TC.

É TL = Longueur du paquet IPv6 + 20 (l'en-tête IPv4 contribue pour 20 octets).

É ID = par exemple 0 (champ inutilisé).

É DF=MF=1.

É FO = 0 si le paquet IPv6 n'a pas l'extension IPv6 de Fragmentation ou si le Décalage 10 de fragment de celle-ci est à 0, FO = 1 autrement.

É TTL = HL quand le paquet IPv6 est converti en 6on4 (puis réduit de 1 à chaque traversée de routeur, avec élimination du paquet s'il atteint 0) É P = le protocole de niveau 4 (le NH de l'en-tête IPv6 s'il n'y a aucune extension IPv6 dans le paquet, sinon, le champ NH de l'en-tête de la dernière extension IPv6 du 15 paquet) É HC = la valeur calculée à partir de celle des autres champs de l'en- tête.

É SA = l'adresse IPv4 qui est déduite de l'adresse SA du paquet IPv6, éventuellement d'une façon qui dépend d'où se trouve l'équipement où le paquet IPv6 a été converti en paquet 6on4 2 0 É DA = l'adresse IPv4 qui est déduite de l'adresse DA du paquet IPv6, éventuellement d'une façon qui dépend d'où se trouve l'équipement où le paquet IPv6 a été converti en paquet 6on4.

La façon d'obtenir une adresse IPv4 à partir d'une adresse IPv6 ne fait pas partie de l'invention. Plusieurs sont connues, notamment dans le RFC 3056 concernant l'encapsulation dite 6to4 , et dans la demande de brevet français N 04 05 288, déposée le 14 mai 2004 au nom du Demandeur où l'adresse obtenue à partir d'une adresse IPv6 donnée dépend d'où cette adresse IPv4 est obtenue.

3 0 Le champ de données D qui suit l'en-tête IPv4 du paquet 6on4 est celui du paquet IPv6, à l'exception près de ce que: É Si P = "UDP" et FO = 0, alors LUDP = 1 Le champ de bourrage B a une longueur telle que la longueur du paquet soit multiple de 8 octets, comme l'impose IPv4 pour les paquets d'un datagramme fragmenté autres que le dernier. (Cette contrainte est liée au fait que les décalages de fragment sont exprimés en unités de 8 octets.) L'en-tête IPv4 ayant 20 octets, et les champs qui suivent le bourrage, décrits dans la suite ayant chacun une longueur multiple de 8 octets, la longueur de B est égale à (DL6 + 20) arrondi par excès à un multiple de 8, moins (DL6 + 20).

Après le champ B est placé l'ensemble E6 des éventuels en-têtes d'extension IPv6 du paquet IPv6. E6 est vide si le champ NH de l'en-tête IPv6 n'a aucune des valeurs qui désignent une extension IPv6, à savoir à ce jour 0, 43, 44, 50, 51 ou 60, donc en particulier s'il a l'une des valeurs 17 ou 6 qui désignent respectivement UDP et TCP. Si E6 n'est pas vide, il est constitué d'une suite d'en-têtes d'extension IPv6 commençant chacun par deux octets dont le premier est l'octet NH (next header), dont la valeur désigne une extension IPv6 suivante ou le protocole de niveau supérieur à IP, et dont le second est un champ de longueur dudit en-tête. Le dernier en-tête d'extension IPv6 de E6 est repéré par le fait que son champ NH n'a aucune des valeurs qui désignent une extension IPv6.

Si l'une des extensions IPv6 est celle de Fragmentation (NH précédent = 44), et si le champ "Décalage de fragment" de son en-tête n'est pas nul, c'est-à-dire si le paquet contient un fragment suivant, et si champ NH de la dernière extension IPv6 désigne UDP (valeur 7), alors le bit de fort poids de LUDP est mis à 1.

Enfin, une copie de l'en-tête IPv6 d'origine est placée après les éventuels en-têtes d'extension IPv6. Pour la clarté, les noms des champs du paquet IPv6 sont à cette occasion renommés en faisant suivre d'un "6" leur nom d'origine.

Dans cette copie, le champ DL6, au lieu d'être une simple copie de DL, a la valeur (DL - 3 0 <longueur des extensions IPv6>). Grâce à cela il est possible, en examinant le paquet 6on4, de déterminer la longueur du champ D (égale à DL6) et la longueur du champ B (égale à (DL6 + 20) arrondi par excès à un multiple de 8 bits, moins (DL6 + 20).

Un organigramme de reconnaissance du format 6on4 à la réception d'un paquet IPv4 est présenté sur la figure 4. Après l'initialisation 400, on détermine (402) si le paquet présente des options IPv4, faute de quoi ce n'est pas un paquet "6on4" (412). Autrement - si on n'a pas à la fois DF = 1 et MF = 1, ce n'est pas non plus un paquet "6on4" (412) ; - si FO n'est ni 0, ni 1 (404, 406), ce n'est toujours pas un paquet "6on4" (412) ; - si FO = 1 (404, 406), c'est un paquet "6on4" (414) ; - enfin, si FO = 0: * si on a P = UDP et LUDP(0) = 1, c'est un paquet "6on4" (414) ; * sinon, ce n'en est pas un (412).

Un organigramme de conversion du format IPv6 en format 6on4 est présenté sur la figure 5. Après l'initialisation 500, on procède (502) au remplissage du champ de bourrage B jusqu'au multiple supérieur de 8 octets, ceci pour respecter la règle d'IPv4 selon laquelle les paquets qui ont le champ MF à 1 doivent avoir une longueur multiple de 8 octets, et sachant que les en-têtes qui vont suivre, IPv6 et extensions IPv6, ont par nature chacun une longueur multiple de 8 octets.

Ensuite, à l'opération 504, on parcourt les en-têtes des éventuelles extensions IPv6, pour calculer leur longueur totale "LE". Si l'option de fragmentation est présente, on y trouve la valeur de "FO6", le Décalage de Fragment du fragment de datagramme que contient ce paquet. Enfin, on trouve le protocole de niveau 4 "P4" dans le champ NH du premier en-tête d'extension IPv6 où ce champ n'a pas une valeur désignant une extension IPv6 suivante.

À l'opération 506, on place les en-têtes IPv6 après les données, et l'on soustrait la longueur des en-tête d'extensions IPv6 de la longueur des données.

À l'opération 508, on place l'en-tête IPv4 avant les données; ensuite, on fixe les valeurs 3 0 suivantes dans le paquet: ToS = TC; TTL = HL; TL = <longueur du paquet IPv6> + 20; ID = 0; P = P4. De plus: Si FO6 existe et est différent de 0, alors [ FO = 1 et (si P = UDP alors LUDP(0) = 1) ], sinon FO = 0) ).

À l'opération 510, SA et DA de l'en-tête IPv4 sont les adresses IPv4 obtenues localement à partir des adresses SA et DA de l'en-tête IPv6 d'origine, en appliquant la règle adéquate pour la situation (par exemple celle du RFC 3056 concernant l'encapsulation 6to4, ou celle de la demande de brevet français N 04 05 288, déposée le 14 mai 2004 au nom du Demandeur).

Si l'encapsulation 6on4 est utilisée avec un adressage à la façon de 6to4, l'adresse IPv4 se trouve après le 2 premiers octets de l'adresse IPv6, ceux-ci ayant la valeur 0x2002 caractéristique de 6to4. La conversion ne dépend pas dans ce cas de l'endroit où se trouve l'équipement qui convertit le format IPv6 en format 6on4. Elle en dépend en revanche si l'encapsulation 6on4 est utilisée dans le cadre d'une application de la demande de brevet précitée, où l'adresse locale IPv4 correspondant à une adresse IPv6 dépend d'un paramètre "Préfixe de sous-réseau de l'interface d'émission".

Enfin, l'opération 512 consiste à mettre à jour le HC de l'en tête IPv4 (complément à 1 des mots de 16 bits constituant l'en-tête IPv4 tel qu'il vient d'être constitué, avec HC initialement à 0).

Un organigramme de conversion du format 6on4 en format IPv6 est présenté sur la figure 6. Après l'entrée 600, l'opération 602 vérifie que les adresses SA et DA sont compatibles avec les adresses SA6 et DA6, c'est-àdire qu'elles son égales respectivement aux adresses IPv4 que l'on obtient si on applique aux adresses SA6 et DA6 respectivement la règle en vigueur pour obtenir une adresse IPv4 à partir d'une adresse IPv6. En cas d'incompatibilité pour l'une ou l'autre (604), le paquet est éliminé (606) .

Ensuite, l'opération 608 détermine la longueur totale "LE" des en-têtes d'extension IPV6 en soustrayant le décalage du début des l'en-têtes d'extensions IPv6, par rapport au début 3 0 du paquet, de celui du début de l'en-tête IPv6 recopié: LE = [<longueur du paquet IPv6> - 40] [ (DL6 + 20) arrondi par excès à un multiple de 8] À l'opération 610, on sauvegarde l'en-tête IPV4, puis, avant les données D, on place la copie de l'en-tête IPv6, suivi de la copie des éventuels en-têtes d'extensions IPv6.

À l'opération 612, on va: * Augmenter DL de la longueur des en-têtes d'extension IPV6 * faire HL = TTL Enfin, à l'opération 612, Si on a NH = "UDP", on force LUDP(0) = 0.

Ce qui précède constitue l'ensemble des moyens requis dans la réalisation particulière décrite. La description qui précède montre comment l'on peut placer des extensions d'adresse dans un "en-queue"d'un paquet, c'est-àdire après les données qu'il contient, maintenant en cela dans la mesure du possible le fonctionnement des pare-feux existants opérant selon le protocole IPV4.

Bien que la description détaillée place les extensions d'adresse dans un "en-queue", ces extensions peuvent être également placées à d'autres endroits du paquet, en maintenant au moins en partie les mêmes avantages.

2 0 En particulier, le demandeur a proposé dans sa demande de brevet précitée un système d'adresse étendue pour IPV4, dans lequel les extensions, placées ailleurs que dans l'en-tête, sont rendues suffisamment compactes, et convenablement localisées, pour respecter les contraintes relatives à l'établissement et la retransmission éventuelle de messages d'erreur ICMPv4 dans lesquels sont recopiés seulement les 8 premiers octets qui suivent l'en-tête IPv4 des paquets fautifs.

Dans la même demande de brevet antérieure, on recherche également une compatibilité avec les routeurs IPV4, même si ceux-ci sont amenés à réaliser des fragmentations de paquet.

L'usage des enseignements de la présente description est compatible avec la proposition faite dans la demande de brevet précitée sur la base des remarques et/ou évolutions suivantes: - On admet que des messages d'erreur puissent être perdus systématiquement, comme ils le sont avec l'encapsulation 6to4, et comme ils peuvent l'être, occasionnellement mais sans probabilité définie, en IPv4 sans encapsulation.

- Il s'est avéré que le traitement de la fragmentation par les routeurs est la plupart du temps superflu, du fait que les routeurs IPV4 reliés entre eux par des liaisons modernes supportent des longueurs de paquets compatibles avec celles des réseaux locaux Ethernet (1.500 octets maximum) , raison pour laquelle IPv6 ne prévoit plus aucune fragmentation pour des paquets s'ils ne dépassent pas 1.280 octets de données ce qui autorise un ensemble de champs de service, y compris d'encapsulations diverses, dont la longueur totale peut atteindre 1.500 1280 = 220 octets, ce qui est plus que suffisant dans la pratique.

Si l'on souhaite néanmoins éviter la perte des messages d'erreur et/ou autoriser la fragmentation par les routeurs, il est possible de recourir à certaines au moins des 2 0 mesures suivantes: - placer une partie au moins du complément d'adresse source en un ou plusieurs endroits bien choisis de l'en-tête IPv4, en particulier dans le champ d'identification de datagramme, - utiliser les 8 premiers octets suivant l'en-tête IP pour placer la partie de l'en-tête de niveau supérieur à IP sur laquelle on souhaite que puissent intervenir les pare-feux, par exemple les champs de Numéros de port de source et de destination qui sont particulièrement utiles, et le cas échéant le reste du complément d'adresse source.

3 0 Dans ce qui précède, on a décrit différentes combinaisons des éléments de l'invention.

Cela n'est pas limitatif, et d'autres combinaisons sont envisageables, en fonction: de la possibilité d'enlever certains éléments dans les situations où ils ne servent pas; des possibilités d'évolution du protocole de base (ici IP) et des possibilités d'évolution du protocole de niveau supérieur.

C'est notamment en fonction de ces facteurs que l'on pourra agencer les moyens décrits ensemble, séparément, ou encore en différentes combinaisons ou sous-combinaisons, comme déjà indiqué.

Claims (4)

Revendications

1. Dispositif d'émission de paquets dans un réseau, comprenant un module de traitement de paquets, apte à préparer l'émission d'un paquet comportant un en-tête de type IP, en particulier de type IPv4, comprenant au moins un champ source et un champ destination, ce paquet ayant vocation à recevoir des données établies selon un protocole de niveau supérieur, caractérisé en ce que le module de traitement de paquets est apte à préparer l'émission de paquets dans lesquels au moins une partie de l'adresse destination est située en dehors dudit en-tête, dans une zone choisie pour préserver le fonctionnement de filtrages de pare-feu fondés sur l'en-tête du dit protocole de niveau supérieur.

2. Dispositif selon la revendication 1, caractérisé en ce que le paquet comprend au moins une indication permettant de distinguer entre un paquet où l'adresse de destination est totalement contenue dans ledit champ destination, et un paquet où au moins une partie de l'adresse destination est située en dehors dudit en-tête.

3. Dispositif selon la revendication 2, caractérisé en ce que ladite indication comprend la présence de la marque de Fragment à suivre et au moins une valeur particulière du champ Décalage de fragment, décalage au moyen duquel les données de chaque paquet d'un datagramme fragmenté sont situées dans l'ensemble du datagramme.

4. Dispositif selon l'une des revendications 2 et 3, caractérisé en ce que, là où le protocole de niveau supérieur à IP est UDP, ladite indication comprend un ensemble de 2 5 valeurs particulières du champ de l'en-tête UDP qui indique la longueur totale du datagramme.

Jq \-av-,

CABINET NETTER