FR2936387A1

FR2936387A1 - Procede de gestion d'espaces d'adressage lors d'une ouverture d'un tunnel de communication, tete de tunel, produit programme d'ordinateur et moyen de stockage correspondant.

Info

Publication number: FR2936387A1
Application number: FR0856458A
Authority: FR
Inventors: Pascal Viger; Stephane Baron
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2008-09-25
Filing date: 2008-09-25
Publication date: 2010-03-26
Anticipated expiration: 2028-09-25
Also published as: FR2936387B1; US8812633B2; US20100077064A1

Abstract

Il est proposé un procédé permettant de remédier au problème de conflit d'adresses lors d'un établissement de tunnel de communication entre une première tête de tunnel d'un premier sous-réseau de communication et une seconde tête de tunnel d'un second sous-réseau de communication distinct dudit premier sous-réseau, en proposant une méthode efficace de gestion dynamique des espaces d'adressage de chaque sous-réseau, mise en oeuvre par une tête de tunnel lors de la détection d'une requête de mise en relation de deux sous-réseaux par un tunnel.

Description

Procédé de gestion d'espaces d'adressage lors d'une ouverture d'un tunnel de communication, tête de tunnel, produit programme d'ordinateur et moyen de stockage correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication. Plus précisément, l'invention concerne la gestion d'espaces d'adressage, par exemple IP (pour Internet Protocol en anglais ou protocole Internet en français), sur des sous-réseaux locaux domestiques distants (encore appelés réseaux LAN, pour Local Area Network en anglais) lors de l'établissement d'un tunnel de communication, sur un réseau fédérateur, entre ces sous-réseaux. La démocratisation d'Internet haut débit d'une part et l'apparition d'équipements audiovisuels grand public ayant une connectivité réseau d'autre part vont créer de nouveaux comportements des utilisateurs. Parmi ces nouveaux comportements, il fait peu de doute que nous verrons apparaître des individus appartenant à des groupes de personnes ayants des domaines d'intérêts communs (loisirs, famille...) que nous pourrions appeler en liaison permanente . Ceux-ci établiront des connections quasi permanentes avec les autres individus d'un même domaine d'intérêt en établissant des communications audio et/ou vidéo, et partageant des informations de tout type (audio, vidéo, photo, texte ...).

La technologie RPV (pour Réseaux Privés Virtuels en français ou VPN pour Viruual Private Network en anglais) offre une solution intéressante pour répondre à cette attente. En effet, elle permet de communiquer de manière transparente en temps réel, de manière sécurisée entre des individus partageant un même domaine d'intérêt, tout en utilisant l'infrastructure réseau Internet peu sûr mais bon marché.

Pour communiquer de manière transparente et s'affranchir des adresses non routables, les RPV utilisent une encapsulation particulière appelée tunnellisation (ou tunneling en anglais) créant ce que l'on appelle classiquement un tunnel. Cette opération consiste à encapsuler un protocole de niveau A (protocole embarqué ou véhiculé ou passager) dans un protocole de niveau B (protocole de transport ou véhiculant) grâce à un protocole d'encapsulation C. Ainsi, le protocole de transport B traite le protocole embarqué A comme s'il s'agissait de données utiles.

La figure 3, décrite en détail par la suite, présente un exemple d'encapsulation de paquets dans un RPV de niveau 2, c'est-à-dire dans un tunnel de niveau 2 (tunnel de niveau 2 signifie que le protocole embarqué A est un protocole de la couche 2 du modèle OSI, qui décrit les services offerts par chacune de ces couches et leurs interactions).

La tunnellisation peut être utilisée pour transporter un protocole réseau sur un réseau qui ne le supporte pas. Elle peut aussi être utilisée pour fournir différents types de fonctionnalités RPV, comme par exemple l'adressage privé. Les techniques de tunnel sont aujourd'hui de plus en plus utilisées par des fonctionnalités client d'accès à distance, et des interconnexions de réseaux locaux domestiques (ou réseaux LAN). Dans la suite de la description, on considère les tunnels de niveau 2, pour lesquels le niveau du protocole de transport B dans le modèle OSI est égal à celui de la couche de transport (couche de niveau 4 dans le modèle OSI). Il est bien entendu que le cadre de la présente invention n'est nullement limitatif, et que le niveau du protocole de transport B dans le modèle OSI peut être inférieur (par exemple un tunnel avec porteuse Ethernet) ou supérieur (par exemple un tunnel avec porteuse HTTP). Par exemple, EtherlP (décrit par la norme RFC 3378) et L2TP (pour Layer 2 Tunneling Protocol en anglais) ont été standardisés par l'IETF (pour Internet Engineering Task Force en anglais) comme des protocoles L2VPN (pour Layer 2 Virtual Private Networks en anglais ou réseau privé virtuel de couche 2 en français), c'est-à-dire tunnellisant des trames de niveau 2 au dessus du protocole IP. Les RPV (ou VPN) sont fréquemment utilisés pour interconnecter deux réseaux LAN afin de créer un réseau local virtuel composé de l'union des deux réseaux LAN originaux. De manière connue, les RPV sécurisés incluent un algorithme de cryptographie et d'authentification afin de garantir le secret des données transportées. Une configuration typique de RPV basée sur une technique de tunnellisation est illustrée sur la figure 1 (décrite en détail par la suite). Dans cet exemple, les têtes de tunnel (ou TEP pour Tunnel End Point en anglais) ne sont pas intégrées aux passerelles. Le tunnel est établi entre deux têtes de tunnel, et chaque paquet (aussi appelé trame) envoyé à un équipement connecté au réseau LAN distant est encapsulé par la tête de tunnel locale, puis envoyé à la tête de tunnel distante qui va le désencapsuler et l'envoyer sur le réseau LAN distant. Pour les équipements du réseau LAN local et distant, ils sont virtuellement connectés à un même réseau LAN. Une communication entre deux équipements via le tunnel est appelée communication de bout en bout ( end-to-end communication en anglais).

Le standard "Universal Plug and Play" (ci-après désigné par standard UPnP, promulgué par l'UPnP Forum) a pour objectif de permettre de manière simple et efficace à des systèmes et des équipements d'être mis en réseaux et de collaborer, sans configuration préalable. Les équipements compatibles avec le standard UPnP sont notamment des dispositifs audio-vidéo ou des ordinateurs personnels (ou PC pour Personnal Computer en anglais) fabriqués par diverses sociétés. Ces équipements peuvent être intégrés dans un réseau IP local tel un réseau LAN. Le standard UPnP fournit à un équipement compatible des moyens de connexion dynamique à un réseau UPnP (mettant en oeuvre le standard UPnP) lui permettant de découvrir les autres équipements compatibles du réseau et lui permet de communiquer (ou exposer) ses propres capacités. La technologie UPnP est basée sur le protocole réseau TCP/IP (pour Transmission Control Protocol/Internet Protocol en anglais), sur le protocole HTTP (pour HyperText Transfer Protocol en anglais) et sur le protocole XML (pour Extensible Markup Language en anglais).

Le standard UPnP Audio Visual ci-après référencé UPnP AV définit un ensemble d'équipements UPnP (par exemple les télévisions, les magnétoscopes, lecteurs DVD, les lecteurs MP3, les ordinateurs PC, ...) avec leurs services associés, qui sont plus spécifiquement dédiés au monde audio/vidéo numérique. Les trois entités logiques principales d'un réseau UPnP AV (mettant en oeuvre le standard UPnP AV) sont un serveur de media (ou UPnP MediaServer en anglais) ayant accès à des contenus multimédia qu'il peut diffuser sur le réseau local, un lecteur de media (ou UPnP MediaRenderer en anglais) capable de jouer localement ce type de contenus multimédia reçus du réseau, et un poste de contrôle coordonnant les opérations demandées par l'utilisateur (telles que play , stop , pause , ...).

Le serveur de média et le lecteur de média ne mettent pas en oeuvre le protocole UPnP pour échanger directement entre eux des informations. En effet, afin d'échanger des contenus multimédia, ils utilisent des protocoles à part du protocole UPnP (encore appelés protocoles out-of-band ). Ces protocoles out-of-band sont principalement le protocole HTTP (tel que défini dans la norme RFC 2616) au dessus du protocole TCP/IP), et le protocole RTP (pour Real-time Transport Protocol en anglais tel que défini dans la norme RFC 1889) au dessus du protocole UDP (pour User Datagram Protocol en anglais) . La technologie UPnP a été envisagée dans le contexte d'un déploiement sur un réseau local LAN (pour Local Area Network en anglais). Face à l'émergence des réseaux locaux personnels ou domestiques connectés à des réseaux WAN (pour Wide Area Network en anglais ou réseau étendu en français) à haut débit tels que l'Internet, un besoin de connecter ensemble des réseaux domestiques locaux s'est développé. Comme cité précédemment, les réseaux privés virtuels (ou RPV) offrent une solution intéressante pour répondre à cette attente. Les technologies de L2VPN se démocratisent de plus en plus au sein des foyers domestiques grâce à des es outils logiciels de type L2VPN ou des boîtiers réseaux dédiés L2VPN permettant à quiconque de procéder à la mise en relation directe et transparente des équipements de chaque réseau domestique. A la différence des réseaux professionnels, l'interconnexion de réseaux domestiques se fait de façon dynamique et ces réseaux ne sont pas administrés (l'utilisateur n'a pas les connaissances requises). Le protocole DHCP (pour Dynamic Host Configuration Protocol en anglais) est un protocole réseau dont le rôle est d'assurer la configuration automatique des paramètres IP d'une station du réseau, notamment en lui assignant automatiquement une adresse IP et un masque de sous-réseaux lors de son démarrage.

Ce protocole DHCP a été présenté pour la première fois en octobre 1993 et est défini par la norme RFC 1531, modifiée et complétée par les normes RFC 1534, 2131 e t2132. Ce protocole DHCP fonctionne sur le modèle client-serveur. Un serveur, qui détient la politique d'attribution des configurations IP, envoie une configuration donnée pour une durée donnée à un client donné (typiquement, une machine qui vient de démarrer). Le serveur va servir de base pour toutes les requêtes DHCP (il les reçoit et y répond). Pour qu'un serveur DHCP puisse servir allouer des adresses IP, il est nécessaire de lui donner un réservoir d'adresses dans lequel il puisse puiser et plus connu sous le nom d'espace d'adressage (ou Address Space en anglais)de plage d'adresses (ou address range en anglais). Un espace d'adressage est constitué d'un ensemble de plages d'adresses (ou Address Range en anglais), une plage d'adresse étant un ensemble d'adresses A noter qu'il est possible de définir plusieurs plages, disjointes ou contiguës. Quand une machine vient de démarrer, elle n'a pas de configuration réseau (aucune configuration par défaut), et pourtant, elle doit arriver à émettre un message sur le réseau afin de se voir attribuer une vraie configuration sur un ensemble de paramètres permettant à la machine de communiquer sur le réseau. La technique utilisée est le dite de broadcast (ou diffusion). Pour trouver et dialoguer avec un serveur DHCP, la machine va simplement émettre un paquet de diffusion (ou broadcast burst en anglais), sur à destination d'une adresse IP 255.255.255.255 et sur le réseau local. A ce paquet de diffusion correspond à un message DHCPDISCOVER, pour destiné à localiser les serveurs DHCP disponibles et leur demander de fournir des paramètres de une première configuration. Ce paquet particulier de diffusion est reçu par toutes les machines connectées au réseau. Lorsque le serveur DHCP reçoit ce paquet, il répond par un autre paquet de diffusion contenant toutes les informations requises pour la configuration. A ce autre paquet de diffusion correspond à un message DHCPOFFER, contenant des premiers paramètres de la première configuration. Si la machine accepte les paramètres de la configuration, elle renvoie un paquet pour informer le serveur qu'ielle garde les paramètres proposés. Ceci est effectué grâce à un message DHCPREQUEST de requête du client avec conservation des premiers paramètres proposés, ; sinon, il la machine fait une nouvelle demande grâce à un message DHCPREQUEST de requête du client avec nouveaux paramètres. Lors de l'utilisation sur un même segment de plusieurs serveurs DHCP, l'intersection des plages espaces d'adressages des différents serveurs doit être vide, sous peine d'ambiguïté dans les affectations et les renouvellements. En effet, des perturbations imprévisibles et indésirables dans le routage des données réseaux se produiront si plusieurs machines du réseau utilisent une même adresse IP.

Il est remarquable aussi de préciser qu'un serveur DHCP est embarqué dans les équipements passerelles fournis par les fournisseurs d'accès à Internet, et que les espaces d'adressage configurés par défaut sont la plupart du temps les mêmes. En effet, dans la nomenclature Internet, un réseau privé est un réseau utilisant un espace d'adressage définies par la norme RFC 1918 Private IP Address (ou adresse IP privée en français) et n'est pas reliée à l'Internet public. Il en découle que les mêmes adresses IP privées peuvent être utilisées sur des réseaux LAN distincts. L'espace d'adressage d'un serveur DHCP doit consister en un ensemble d'adresses comprises parmi les trois plages d'adresses suivantes : de 10.0.0.0 à 10.255.255.255, de 172.16.0.0 à 172.31.255.255, et de 192.168.0.0 à 192.168.255.255. Pour résoudre ce problème d'intersection des espaces d'adressage de différents serveurs, la plupart des serveurs DHCP implémentent maintenant une fonctionnalité de détection de conflit (ou server conflict detection en anglais) qui permet à chaque serveur DHCP de vérifier si l'adresse qu'il veut attribuer à un des ses équipements clients n'est pas en cours d'utilisation par une autre machine du réseau. Lorsque tous les serveurs DHCP d'un même réseau implémentent cette fonctionnalité, leurs espaces d'adressage peuvent se chevaucher. De plus, il est aussi précisé qu'un poste client puisse vérifier la duplication d'existence d'une adresse IP lors de la réception d'une proposition par le serveur DHCP, auquel cas le client décline la proposition qui lui a été faite. Un document de l'IETF plus connu sous le nom de IPv4 ACD (pour IPv4 Address Conflict Detection en anglais) précise les modalités d'application (nombre de tests à effectuer, délai d'attente de réponse d'un autre poste client éventuel...). Dans l'exemple de la figure 1, les têtes de tunnel de niveau 2 ne sont pas embarquées sur les équipements passerelles proposés par les fournisseurs d'accès à l'Internet. Typiquement, ces têtes de tunnel sont mises en oeuvre sur des postes PC disposant d'outils logiciels L2VPN ou sur des boîtiers dédiés L2VPN connectés sur chaque réseau domestique. Ainsi, l'utilisation de ces outils de mise en relation de réseaux domestiques pose un problème de conflit d'adressage entre des équipements de chaque réseau distinct. En effet, l'aspect dynamique et aléatoire de l'interconnexion de tels réseaux de relations personnelles ne permet pas de prédire à l'avance des espaces d'adressage adaptés pour chaque serveur DHCP car il n'existe pas de configuration statique qui réponde à tous les cas d'interconnexion. Egalement, la fonctionnalité de détection de conflit des serveurs DHCP est efficace dans le cas de nouveaux équipements apparaissant sur un réseau, mais ne répond pas à la problématique d'association des réseaux de niveau 2 possédant des équipements réseaux déjà en activité (et donc possédant déjà une adresse IP potentiellement en conflit avec d'autres équipements du réseau LAN distant). 2. ARRIÈRE-PLAN TECHNOLOGIQUE On connaît, dans l'état de la technique, différentes techniques permettant la communication entre des dispositifs de l'Internet et des équipements d'un réseau local privé. Tout d'abord, le mécanisme NAT (pour Network Address Translators en anglais ou translation d'adresse réseau en français) de la norme RFC 3489, implémenté sur une passerelle Internet, fait correspondre les adresses IP internes non routables d'un réseau LAN local à un ensemble d'adresses IP externes uniques et routables. Ce mécanisme permet notamment de faire correspondre une seule adresse externe publique visible sur Internet à toutes les adresses d'un réseau privé, et pallie ainsi la carence d'adresses IPv4 d'Internet. En principe, quand l'adresse interne émet une trame qui traverse le routeur/passerelle mettant en oeuvre le mécanisme NAT, cette adresse est remplacée dans l'en-tête du paquet TCP/IP par son adresse IP externe. Le remplacement inverse sera fait quand une trame, ayant pour adresse de destination cette adresse externe, est reçue de l'Internet ; l'adresse externe est alors traduite en adresse IP interne par la passerelle Internet. Ce mécanisme est particulièrement désigné dans un contexte client/serveur traditionnel de l'Internet. En effet, un problème majeur se pose lorsqu'un protocole de communication (par exemple, UPnP) transmet l'adresse IP de l'hôte source dans la partie utile ( data payload en anglais) du paquet véhiculé. Cette adresse n'étant pas valide après avoir traversé le routeur NAT, elle ne peut être utilisée par la machine destinatrice. Pour pallier cet inconvénient, les routeurs NAT doivent inspecter le contenu des paquets qui les traversent, et remplacer les adresses IP spécifiées par les adresses traduites.

Cependant, cela implique de connaître le format du protocole, de recalculer la somme de contrôle ( checksum en anglais) et la longueur du paquet.

De plus ce mécanisme est très lourd en charge de calcul, car chaque paquet est analysé et sujet à modification. Outre un accroissement de la consommation de ressources au sein du routeur NAT, on constate un accroissement de la latence de transmission du routeur.

Est apparu ensuite le mécanisme plus évolué dénommé ALG (pour Application-Level Gateway en anglais ou relais applicatif en français) de la norme RFC 2663, similaire à un serveur mandataire (ou proxy en anglais). Par le principe d'inspection de tous les paquets transitant par le dispositif ALG, le service ALG convertit les informations réseau trouvées (adresses IP et ports TCP/UDP) dans la partie utile ( data payload en anglais) de chaque paquet. Il est à noter que cela implique que l'ALG soit particularisée afin de supporter un protocole de communication précis, selon une version précise. Par exemple, le groupe d'étude UPnP Remote Access s'attache à définir une architecture UPnP disposant d'un tel mécanisme ALG, afin de permettre à un équipement terminal déporté de se connecter au premier réseau domestique local et d'interagir avec les autres dispositifs UPnP du premier réseau local comme s'il était attaché physiquement à ce premier réseau local. De plus ce mécanisme est très lourd en charge de calcul, car chaque paquet est analysé et sujet à modification.

Dans le contexte d'une connexion VPN entre deux réseaux distants tels que des réseaux domestiques, les données transférées entre ces deux habitations sont le plus souvent du type audio/vidéo. Aussi, les architectures VPN basées sur les mécanismes précités ne permettent plus d'assurer une correcte QoS ( Quality of Service en anglais ou Qualité de Service en français) pour ces échanges audio/vidéo car l'élément mandataire introduit une latence et une gigue supplémentaires non négligeables dans les communications transitant par le tunnel VPN. Un document de brevet HITACHI (US2007/0127461) Router and communication system propose une solution n'utilisant pas de serveur mandataire entre deux réseaux distincts.

Ce document de brevet se positionne dans le cadre d'un tunnel de niveau 2 (L2VPN) reliant deux réseaux LAN (pour Local Area Network en anglais) distants.

Du fait de la transparence du tunnel vis-à-vis des protocoles de niveau 2 (tous les messages de niveau 2 sont véhiculés directement), ce brevet propose une méthode pour unifier le système d'adressage entre les deux réseaux LAN connectés. Par un mécanisme de distribution d'informations relatives à une affectation d'adresses IP pour un réseau et relatives à un filtrage d'adresses MAC, un routeur maître informe le routeur distant de la configuration devant être mise en place à l'ouverture d'un tunnel. Ces informations font partie du message de requête d'établissement du tunnel. Les informations d'adresses IP servent au routeur distant à distribuer ces adresses aux équipements de son réseau. Les informations d'adresses MAC (pour Medium Access Control en anglais) servent au routeur distant à filtrer les messages de niveau 2 dans le cas d'une configuration multiple-tunnel. Il est à noter que la solution décrite dans le document de brevet HITACHI (US2007/0127461) résout partiellement le problème de conflit d'adresses dans le contexte d'un L2VPN pour les équipements nouvellement démarrés après établissement du tunnel. En effet, dans ce document de brevet HITACHI, le routeur affecte une adresse IP correcte à l'équipement mis en route. Par rapport à la fonctionnalité de détection de conflit (ou server conflict detection ) des serveurs DHCP prévue dans la norme DHCP, cette solution possède uniquement l'avantage de disposer d'une séparation claire des espaces d'adressage de chaque serveur DHCP.

Cependant, ce document de brevet HITACHI se base sur le postulat que toute machine du réseau LAN est éteinte avant l'établissement du tunnel, et sera redémarrée après ouverture du tunnel. Ceci n'est pas réaliste surtout dans un contexte évolutif de connexion VPN entre réseaux domestiques non permanents. Ainsi, ce document de brevet HITACHI ne propose pas de solution permettant de gérer des équipements réseau déjà en fonctionnement lors de l'établissement du tunnel L2VPN. Il est à noter également que ce document de brevet HITACHI suppose que le service DHCP et le routeur L2VPN sont mis en oeuvre par la même machine. Le document de brevet HITACHI n'est donc pas apte à contrôler des serveurs DHCP du commerce. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectifs de pallier cet inconvénient de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif de la présente invention est de fournir une technique permettant de remédier au problème de conflit d'adresses (par exemple IP) entre deux sous-réseaux reliés par un tunnel de communications en proposant une méthode efficace de gestion dynamique des espaces d'adressage de chaque sous-réseau, mise en oeuvre par une tête de tunnel lors de la détection d'une requête de mise en relation de deux sous-réseaux par un tunnel. Un objectif de la présente invention est notamment de fournir une technique permettant d'éviter, lors de l'établissement du tunnel (par exemple L2VPN) entre deux sous-réseaux, des conflits d'adresses (par exemple IP) lorsque des équipements réseau sont déjà en fonctionnement sur ces sous-réseaux. Un autre objectif de l'invention est de fournir une technique permettant d'éviter, lors de l'établissement du tunnel, des conflits d'adresses et ce sans nécessiter de service mandataire ( proxy ) séparant les deux sous-réseaux. Un autre objectif important de l'invention est de permettre une organisation automatique du réseau global de communication, sans nécessiter une quelconque administration par un utilisateur. Un autre objectif de l'invention est de fournir une technique qui soit simple à mettre en oeuvre pour un coût moindre. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion d'espaces d'adressage lors d'un établissement de tunnel de communication entre une première tête de tunnel d'un premier sous-réseau de communication et une seconde tête de tunnel d'un second sous-réseau de communication distinct dudit premier sous-réseau, chaque équipement connecté à un sous-réseau donné parmi lesdits premier et second sous-réseaux possédant une adresse comprise dans un espace d'adressage associé audit sous-réseau donné. Ce procédé est effectué par la première tête de tunnel et est remarquable en ce qu'il comprend des étapes consistant à : - détecter au moins une paire d'équipements possédant une même adresse, chaque paire d'équipements comprenant un premier équipement du premier sous-réseau et un second équipement du second sous-réseau ; - sélectionner au moins un équipement de chaque paire d'équipements ; - allouer une nouvelle adresse à chaque équipement sélectionné ; et - établir le tunnel entre les premier et second sous-réseaux. Ainsi, dans ce mode de réalisation particulier, l'invention repose sur une approche tout à fait nouvelle et inventive de gestion dynamique des espaces d'adressage de chaque sous-réseau, mise en oeuvre par une tête de tunnel lors de la détection d'une requête de mise en relation de deux sous-réseaux par un tunnel. Grâce à ce procédé de gestion, avant l'établissement du tunnel (c'est-à-dire avant d'autoriser toute communication entre des équipements clients des deux sous-réseaux autres que les première et secondes têtes de tunnel), il est possible de détecter à partir d'une connaissance de la configuration de chaque sous-réseau, les doublons d'adresses (c'est-à-dire des adresses identiques affectées à deux équipements de part et d'autre du tunnel) et de supprimer ces doublons en réallouant une nouvelle adresse à au moins un des deux équipements concernés par chaque doublon. Ainsi, la présente invention propose une solution complète au problème de conflit d'adresses et ce même pour des équipements réseau déjà en fonctionnement sur leur réseau propre lors de l'établissement du tunnel. Particulièrement, ce procédé de gestion permet en outre une organisation automatique du réseau global sans nécessiter une quelconque administration par l'utilisateur. De façon avantageuse, l'étape consistant à allouer une nouvelle adresse comprend des étapes consistant à : - obtenir un nombre d'adresses comprises dans les espaces d'adressage associés auxdits premier et second sous-réseaux et qui ne sont pas allouées à un équipement desdits premier et second sous-réseaux ; - comparer ledit nombre d'adresses avec le nombre d'équipements sélectionnés ; - si ledit nombre d'adresses est inférieur au nombre d'équipements sélectionnés, étendre au moins un des espaces d'adressage associés auxdits premier et second sous-réseaux afin de rendre ledit nombre d'adresses supérieur ou égal au nombre d'équipements sélectionnés. Ainsi, par analyse des adresses libres dans chacun des espaces d'adressages des premier et second sous-réseaux, et éventuellement par mise à jour desdits espaces d'adressages pour que la totalité des adresses en doublon puissent trouver une adresse de remplacement, le (ou les) espace(s) d'adressage modifié(s) est(sont) configuré(s) de manière à assurer le bon fonctionnement de la phase d'allocation d'une nouvelle adresse à chaque équipement sélectionné. Avantageusement, l'étape consistant à étendre au moins un des espaces d'adressage comprend au moins une des étapes suivantes, consistant à : - étendre l'espace d'adresses d'au moins un serveur d'adresses actif de l'un desdits premier et second sous-réseaux ; - démarrer un nouveau serveur d'adresses, possédant un espace d'adressage dont les adresses sont distinctes des adresses des espaces d'adressage des serveurs d'adresses déjà actifs desdits premier et second sous-réseaux. Ainsi, on dispose de deux manières pour effectuer l'extension, pouvant être utilisées soit séparément, soit en combinaison. Dans le cas d'une combinaison, par exemple, en cas d'un échec de configuration des serveurs d'adresses des premier et second sous-réseaux, une solution alternative pour l'étape d'extension consiste à démarrer un nouveau serveur sur la première tête de tunnel, ce nouveau serveur d'adresses possédant un espace d'adressage complémentaire des espaces d'adressage des serveurs d'adresses déjà actifs des premier et second sous-réseaux. Ainsi, l'allocation de nouvelles adresses peut s'effectuer en évitant tout problème lié à un conflit d'adresse. Selon une caractéristique avantageuse l'étape consistant à allouer une nouvelle adresse est précédée d'une étape consistant à modifier la configuration de filtrage de la première tête de tunnel pour effectuer un premier filtrage permettant de laisser transiter entre les premier et second sous-réseaux via le tunnel uniquement des messages se rapportant à une allocation d'adresse, et en ce que l'étape consistant à établir le tunnel est précédée d'une étape consistant à modifier la configuration de filtrage de la première tête de tunnel en fonction de la (des) nouvelle(s) adresse(s) allouée(s) au(x) dispositif(s) sélectionné(s). Ainsi, on limite le passage sur le tunnel aux seuls messages protocolaires d'allocation d'adresses, destinés à résoudre les situations de conflit d'adresse, ainsi qu'aux messages de gestion de tunnel échangés entre les première et seconde têtes de tunnel. Ainsi, l'allocation de nouvelles adresses (pour supprimer des conflits d'adresse déjà détectés) peut s'effectuer de manière globale en tenant compte des équipements des deux sous-réseaux.

Selon une autre caractéristique avantageuse, l'étape consistant à allouer une nouvelle adresse comprend une étape consistant à mettre à jour une passerelle d'accès par le premier sous-réseau à un réseau fédérateur, en fonction de la nouvelle adresse de chaque équipement sélectionné. Ainsi, une fois les nouvelles adresses déterminées pour les équipements sélectionnés, cette étape de mise à jour permet d'assurer la conformité de la configuration de la passerelle Internet avec la nouvelle configuration réseau, suite à l'allocation d'une nouvelle adresse aux équipements sélectionnés. Egalement, l'étape consistant à allouer une nouvelle adresse comprend des étapes consistant à : - déterminer, s'il existe, au moins un équipement sélectionné auquel une nouvelle adresse n'a pas pu être allouée, dit équipement toujours en conflit ; - modifier la configuration de filtrage de la première tête de tunnel pour effectuer un deuxième filtrage permettant de ne pas laisser transiter sur le tunnel des messages se rapportant audit équipement toujours en conflit.

Cette seconde étape de filtrage laisse ainsi transiter sur le tunnel toutes les communications du premier sous-réseau et du second sous-réseau pour chaque équipement dont l'adresse n'est pas (ou plus) en conflit d'adresse avec un autre équipement. De façon avantageuse, l'étape consistant à détecter au moins une paire d'équipements possédant une même adresse comprend des étapes consistant à : - obtenir une première table d'allocation d'adresses au sein du premier sous-réseau ; - obtenir une seconde table d'allocation d'adresses au sein du second sous-réseau ; - détecter ladite au moins une paire d'équipements possédant une même adresse, par comparaison desdites première et seconde tables d'allocation d'adresses. Ainsi, grâce à ces deux tables d'allocation d'adresses, il est possible de déterminer facilement chaque paire d'équipements en conflit d'adresses. Avantageusement, l'étape consistant à détecter au moins une paire d'équipements possédant une même adresse comprend des étapes consistant à : - obtenir une première table d'allocation d'adresses au sein du premier sous-réseau ; - transmettre, vers la seconde tête de tunnel, un message de sondage du second sous-réseau pour chaque adresse de ladite première table d'allocation d'adresses ; - détecter ladite au moins une paire d'équipements possédant une même adresse, par analyse d'un message de réponse au message de sondage. Ainsi, si la seconde tête de tunnel n'est pas en mesure de créer sa propre table d'allocation d'adresses, la première tête de tunnel met en oeuvre un mécanisme de sondage d'adresses permettant de détecter d'éventuels conflits d'adresses préalablement à l'établissement d'un tunnel de communication entre ces deux têtes de tunnel. Selon une autre caractéristique avantageuse, l'étape consistant à sélectionner au moins un équipement de chaque paire d'équipements est effectuée en fonction d'au moins une règle appartenant au groupe comprenant : - si une paire d'équipements en comprend un, on sélectionne un équipement qui n'est pas une passerelle d'accès à un réseau fédérateur ; - si une paire d'équipements en comprend un, on sélectionne un équipement qui est de type client ; - si une paire d'équipements en comprend un, on sélectionne un équipement qui n'a pas d'activité de communications sur le réseau ; - si une paire d'équipements en comprend un, on sélectionne un équipement qui n'est pas compris dans une liste prédéterminée d'équipements dont les adresses ne doivent pas être modifiées. Ainsi, selon un mode de réalisation particulier de l'invention, la sélection des équipements sur lesquels appliquer le correctif des adresses en conflits est réalisée de façon à perturber le moins possible le comportement du premier sous-réseau et du second sous-réseau. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur. Ce produit programme d'ordinateur comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage lisible par ordinateur, éventuellement totalement ou partiellement amovible, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation). L'invention concerne également un dispositif de gestion d'espaces d'adressage lors d'un établissement de tunnel de communication entre une première tête de tunnel d'un premier sous-réseau de communication et une seconde tête de tunnel d'un second sous-réseau de communication distinct dudit premier sous-réseau, chaque équipement connecté à un sous-réseau donné parmi lesdits premier et second sous-réseaux possédant une adresse comprise dans un espace d'adressage associé audit sous-réseau donné, caractérisé en ce que la première tête de tunnel comprend : des premiers moyens de détection d'au moins une paire d'équipements possédant une même adresse, chaque paire d'équipements comprenant un premier équipement du premier sous-réseau et un second équipement du second sous-réseau ; - des moyens de sélection d'au moins un équipement de chaque paire d'équipements ; - des moyens d'allocation d'une nouvelle adresse à chaque équipement sélectionné , et - des moyens d'établissement du tunnel entre les premier et second sous-réseaux. Avantageusement, les moyens d'allocation d'une nouvelle adresse comprend : - des premier moyens d'obtention d'un nombre d'adresses comprises dans les espaces d'adressage associés auxdits premier et second sous-réseaux et qui ne sont pas allouées à un équipement desdits premier et second sous-réseaux ; - des moyens de comparaison dudit nombre d'adresses avec le nombre d'équipements sélectionnés ; - si ledit nombre d'adresses est inférieur au nombre d'équipements sélectionnés des moyens d'extension d'au moins un des espaces d'adressage associés auxdits premier et second sous-réseaux afin de rendre ledit nombre d'adresses supérieur ou égal au nombre d'équipements sélectionnés. De manière avantageuse, lesdits moyens d'extension comprennent : - des moyens d'extension de l'espace d'adresses d'au moins un serveur d'adresses actif de l'un desdits premier et second sous-réseaux ; - des moyens de démarrage d'un nouveau serveur d'adresses, possédant un espace d'adressage dont les adresses sont distinctes des adresses des espaces d'adressage des serveurs d'adresses déjà actifs desdits premier et second sous- réseaux. Selon une autre caractéristique avantageuse de l'invention, ce dispositif comprend des premier moyens de modification dela configuration de filtrage de la première tête de tunnel pour effectuer un premier filtrage permettant de laisser transiter entre les premier et second sous-réseaux via le tunnel uniquement des messages se rapportant à une allocation d'adresse, et des second moyens de modification de la configuration de filtrage de la première tête de tunnel en fonction de la (des) nouvelle(s) adresse(s) allouée(s) au(x) dispositif(s) sélectionné(s). En outre, les moyens d'allocation comprennent des moyens de mise à jour d'une passerelle d'accès par le premier sous-réseau à un réseau fédérateur, en fonction de la nouvelle adresse de chaque équipement sélectionné. De manière intéressante, les moyens d'allocation comprennent en outre : - des moyens de détermination, s'il existe, d'au moins un équipement sélectionné auquel une nouvelle adresse n'a pas pu être allouée, dit équipement toujours en conflit ; - des troisième moyens de modification de la configuration de filtrage de la première tête de tunnel pour effectuer un deuxième filtrage (810) permettant de ne pas laisser transiter sur le tunnel des messages se rapportant audit équipement toujours en conflit. Avantageusement, les premiers moyens de détection d'au moins une paire d'équipements possédant une même adresse comprend : - des seconds moyens d'obtention d' une première table d'allocation d'adresses au sein du premier sous-réseau ; - des troisièmes moyens d'obtention d'une seconde table d'allocation d'adresses au sein du second sous-réseau ; - des seconds moyens de détection de ladite au moins une paire d'équipements possédant une même adresse, par comparaison desdites première et seconde tables d'allocation d'adresses. Egalement, les premiers moyens de détection d'au moins une paire d'équipements possédant une même adresse comprend des étapes consistant à : - des seconds moyens d'obtention d'une première table d'allocation d'adresses au sein du premier sous-réseau ; - des moyens de transmission, vers la seconde tête de tunnel, d'un message de sondage du second sous-réseau pour chaque adresse de ladite première table d'allocation d'adresses ; - des quatrièmes moyens de détection de ladite au moins une paire d'équipements possédant une même adresse, par analyse d'un message de réponse au message de sondage. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 illustre schématiquement une configuration typique d'un réseau privé virtuel (VPN) pour la mise en oeuvre de l'invention selon un mode de réalisation particulier ; - la figure 2 illustre schématiquement un exemple de modèle en couche classique d'une tête de tunnel dans laquelle est mis en oeuvre le procédé selon un mode de réalisation particulier ; - la figure 3 illustre schématiquement un exemple de format classique d'une trame Ethernet véhiculant un paquet tunnel de niveau 2 ; - la figure 4 illustre schématiquement les principales étapes d'un mode de réalisation particulier de l'invention en accord avec l'exemple de configuration de la figure 1 ; - la figure 5 illustre schématiquement la structures des données échangées selon un mode de réalisation particulier de l'invention ; - la figure 6 illustre schématiquement un algorithme de détection de conflit d'adresses selon un mode de réalisation particulier de l'invention ; - la figure 7 illustre schématiquement un algorithme de sélection des équipements candidats à une modification d'adresse selon un mode de réalisation particulier de l'invention ; - la figure 8 illustre schématiquement un algorithme de modification de la configuration réseau, appliqué aux équipements sélectionnés ; - la figure 9 illustre schématiquement un dispositif selon un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE La figure 1 illustre schématiquement, selon un mode de réalisation particulier de l'invention, une configuration typique de réseau privé virtuel (VPN) mettant en oeuvre un tunnel 100 de communication entre une première tête de tunnel locale 101 et une seconde tête de tunnel distante 102, à travers un réseau de communication 107 fédérateur ( backbone network en anglais), comme Internet par exemple. Ce tunnel 100 interconnecte un premier sous-réseau de communication 103 et un second sous- réseau de communication 104, encore appelés respectivement LAN A 103 et LAN B 104. Le premier sous-réseau 103 et le second sous-réseau 104 comporte un équipement d'accès Internet haut débit de type passerelle Internet domestique (ou Home Gateway en anglais), pouvant intégrer un pare-feu 105 et 106 (ou Firewall en anglais), des équipements de type PC 109 et 111, des serveurs 110 et 113 permettant le stockage et le partage des media numériques (de type audio, vidéo, photo), ainsi que des équipements de restitutions des médias numériques 108 et 112. Une tête de tunnel peut être intégrée dans un équipement audiovisuel comme un téléviseur numérique. Elle peut aussi être présente dans un équipement de type PC sous la forme d'un programme réalisant les fonctions associées à celle-ci. Une fois le tunnel 100 établi, les équipements 108, 109, et 110, connectés au premier sous-réseau 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au second sous-réseau 104. Par exemple, le client local 108 connecté au premier sous-réseau 103 peut communiquer avec le serveur local 113 connecté au second sous-réseau 104. Sur cette figure 1 est représenté un réseau de communication simple avec un seul tunnel, mais il est bien entendu qu'une même tête de tunnel peut être amenée à gérer plusieurs tunnels (à destination d'autant de têtes de tunnel) pour interconnecter un premier sous-réseau LAN à plusieurs autres sous-réseaux LAN. En outre, dans un souci de simplification, n'ont pas été représentés les équipements d'infrastructure dans le réseau Internet tels que les routeurs Internet.

La première tête de tunnel 101 (ou la seconde tête de tunnel 102) est formée principalement de deux ports de communication avec le premier sous-réseau 103 (ou second sous-réseau 104). Un port d'entrée et un port de sortie. En pratique, ces deux ports ont une même interface physique bidirectionnelle de type Ethernet (ports réseaux 1020 la Figure 9).

Ces deux ports sont connectés au canal de transport du tunnel reliant le premier sous-réseau 103 et le second sous-réseau 104. La première tête de tunnel 101 (ou la seconde tête de tunnel 102) comprend un module de filtrage 101A (respectivement 102A) afin de contrôler la transmission de trames entre les premier 103 et second 104 sous-réseaux. Ce module de filtrage 101A (ou 102A) est contenu dans le module application 200, ci-après décrit en relation avec la figure 2.

Lors de l'arrivée de trames Ethernet du réseau local premier sous-réseau 103, l'agent de filtrage 101A est en charge d'appliquer les mesures de filtrage dont les configurations sont détaillées en relation avec les étapes 601, 604, 806 et 810 des figures 6 et 8 décrites plus amplement par la suite. Si la trame d'entrée ne concerne pas un flux de niveau 2 ou 3 qui, d'après la configuration de filtrage appliquée, doit être bloqué, cette trame Ethernet est fournie au multiplexeur 101A en vue d'être encapsulée et émise dans le tunnel. Si la trame d'entrée concerne un flux TCP sélectionné, l'agent de filtrage détruit cette trame.

De même, l'agent de filtrage est capable de filtrer les trames en provenance du tunnel, afin de limiter éventuellement leur diffusion sur le réseau local. En relation avec la figure 2, on présente maintenant le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110, connectés au premier sous-réseau 103, et entrant dans le tunnel 100. Pour ce faire, on utilise un modèle en couches décrivant les couches de protocoles nécessaires à la mise en oeuvre de ce tunnel 100. Dans ce modèle ne sont pas représentés les éléments de protocole nécessaire aux fonctions autres que la mise en oeuvre du tunnel. Par exemple, ne sont pas représentés les éléments de protocole associés à une architecture UPnP lorsqu'une première tête de tunnel 101 est intégrée dans un équipement UPnP.

La première tête de tunnel 101 comporte une interface physique Ethernet 208 qui remet les trames Ethernet issues des équipements 108, 109, 110 à la couche liaison 207 pour routage : vers la couche réseau 206, pour les trames Ethernet à destination de l'équipement comportant la tête de tunnel, ou vers la couche de pont ( bridge en anglais) 209, pour les autres trames Ethernet. La couche de pont 209 réalise les opérations classiques d'un pont Ethernet telles que le filtrage des trames Ethernet et le relais de ces trames vers le ou les port(s) Ethernet de sortie approprié(s). Sur le pont sont attachées une interface Ethernet 207 et au moins une interface virtuelle 210 simulant un contrôleur Ethernet. Une interface virtuelle 210 est créée pour chaque tunnel instancié par l'application 200 à qui elle remet les trames Ethernet qui doivent transiter sur les tunnels respectivement instanciés. D'une manière générale, le protocole d'encapsulation du tunnel représenté par l'application 200 réalise les opérations nécessaires à la mise en oeuvre de chaque tunnel, parmi lesquelles on trouvera notamment la configuration, le filtrage, l'encapsulation c'est-à-dire, la formation d'un paquet tunnel, et l'extraction d'une trame.

Les trames reçues de l'interface virtuelle 210, après traitement par l'application 200, sont remises sous la forme d'un paquet à travers une interface applicative 201 (ou socket en anglais) à un protocole de transport fiable TCP 203 ou non fiable UDP 205, respectivement sécurisés par les protocoles SSL 202 et DTLS 204. Après traitement par un protocole de transport pour former un paquet tunnel, celui-ci est transmis à la couche réseau 206. Le datagramme IP ainsi formé avec le paquet tunnel peut ensuite être transmis sur le sous-réseau LAN à travers les couches liaison 207 et physique 208. La réception d'une trame en provenance du tunnel 100 suivra dans la tête de tunnel le cheminement inverse à celui présenté ci-dessus.

La figure 3 présente un exemple de format d'encapsulation d'une trame Ethernet 260, transitant par exemple sur le premier sous-réseau 103 de la figure 1 entre la première tête de tunnel 101 et la passerelle domestique 105 (destiné à être émis sur Internet ou reçu d'Internet). Cette trame Ethernet comprend un champ d'en-tête Ethernet 261, un premier datagramme IP véhiculant lui-même un paquet tunnel 250 de niveau 2, et un champ FCS (pour Frame Check Sequence en anglais, ou séquence de contrôle de trame en français). Le paquet tunnel 250 comporte quatre parties : - un champ d'en-tête du protocole de transport 251 (à savoir TCP ou UDP dans cet exemple) ; - un champ d'en-tête du protocole d'encapsulation 252 (à savoir L2TP ou TLS dans cet exemple, qui sont décrits notamment dans les documents suivants : IETF RFC3931, "Layer two tunneling protocol û version 3 (L2TPv3)", J. Lau and ail, March 2005 et IETF RFC2246, "The TLS Protocol Version 1.0" ; - un champ d'en-tête du protocole embarqué 253 (à savoir Ethernet dans cet exemple) ; - un champ de données utilisateurs 254, qui lui-même comporte un second datagramme IP complet si aucune fragmentation n'a été opérée lors de son transit depuis l'équipement source. La figure 4 schématise les différentes étapes mises selon un mode de réalisation particulier de l'invention en relation avec la figure 1. Dans la suite de la description, les algorithmes de l'invention (plus amplement décrits par la suite) sont mis en oeuvre, par exemple, par la première tête de tunnel 101 de la figure 1, chacune des têtes de tunnel de la figure 1 (101 ou 102) étant capables d'exécuter l'invention. Les algorithmes de l'invention sont privilégiement mis en place suite à la détection, dans une étape 400, d'une demande d'ouverture d'une connexion L2VPN entre deux réseaux LAN distants. A titre d'exemple, les algorithmes de l'invention sont mis en place par la tête de tunnel recevant une requête de mise en place du tunnel selon un protocole L2VPN connu. Une demande d'établissement d'un tunnel L2VPN peut indifféremment provenir du réseau local, aussi on considère que la seconde tête de tunnel 102 recevant cette demande locale va exécuter une requête d'établissement d'un tunnel L2VPN envers une première tête de tunnel distante 101 selon le protocole L2VPN. C'est donc la première tête de tunnel 101 qui est en charge de mettre en place les algorithmes de l'invention. Il est à noter que toute tête de tunnel de l'invention est apte à déterminer si la tête de tunnel distante supporte les algorithmes de l'invention, et par défaut si elle est seule à implémenter l'invention, la tête de tunnel de l'invention exécute les algorithmes de la figure 4. Pour la suite, les algorithmes de la figure 4 sont exécutés par la première tête de tunnel 101. L'étape 401 consiste à déterminer une liste d'équipements en conflit d'adresses. Cette étape 401 est décrite par la suite en référence avec la figure 6.

Préférentiellement, une étape optionnelle 402 suivante consiste à choisir, parmi les équipements en conflits, ceux dont il est nécessaire de changer l'adresse IP afin de limiter les impacts d'une réallocation d'adresse sur les communications en cours. Cette étape 402 est décrite ci-après en référence avec la figure 7.

Ensuite, une étape 403 permet de demander aux équipements choisis de changer leur adresse IP, et une fois ces changements réalisés, de mettre à jour la configuration du réseau en accord avec les changements d'adresse réalisés. Cette étape 403 est décrite ci-après en référence avec la figure 8. Si l'ensemble des étapes 401, 402 et 403 est réalisé avec succès, dans une étape 404, l'ouverture d'un tunnel est autorisée pour les communications entre les équipements des deux réseaux LAN associés. Dans un mode de réalisation préférentiel, dans le cas où des conflits d'adresse persistent, l'étape 403 est adaptée à réaliser un blocage des communications sur le tunnel pour les équipements dont les conflits d'adresse n'ont pu être corrigés.

La figure 5 illustre schématiquement, selon un mode de réalisation particulier de l'invention, la structure des données utilisées dans le cadre de l'invention. Pour la suite de la description, il est considéré qu'une tête de tunnel mettant en oeuvre le procédé de la présente invention est adaptée à détecter la présence d'équipements sur son réseau local, et d'enregistrer une entrée (propre à chaque équipement détecté) dans une table des équipements 550 (décrite en relation avec la figure 5). Par exemple, les moyens classiques de découverte d'équipements et de services sur un réseau local sont des protocoles de découverte parmi les suivants : - protocole Bonjour , anciennement appelé protocole Rendezvous , est l'implémentation par Apple de la norme Zeroconf ou Zero Configuration Networking (décrit dans la norme RFC 3927) de l'IETF. Zeroconf est une méthode de découverte de services sur un réseau local. Elle est actuellement utilisée pour trouver les imprimantes et dossiers partagés, mais aussi des serveurs internet et FTP. - protocole SSDP (pour Simple Service Discovery Protocol en anglais) est utilisé dans l'UPnP. Par exemple, quand une machine cherche à connaître les services disponibles sur le réseau local, elle envoie un message de découverte à l'adresse de diffusion 239.255.255.250 sur le port 1900 via le protocole UDP. Ce message contient un entête, similaire à une requête http : M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: ssdp:discover MX: 10 ST: ssdp:all Une fois l'adresse IP d'une machine connue, le protocole de résolution d'adresse (ou ARP pour Address Resolution Protocol en anglais) de la norme RFC 826 traduit cette adresse de protocole de couche réseau (IPv4) en une adresse Ethernet (typiquement une adresse MAC). Une autre solution pour la découverte des équipements du réseau consiste à interroger directement l'équipement passerelle hébergeant le serveur DHCP. En effet, une passerelle Internet conforme aux recommandations TR-64 ( LAN-Side DSL CPE Configuration ) du forum DSL peut être découverte via le protocole SSDP depuis le réseau LAN local, et ainsi proposer une interface UPnP-IGD facilitant sa configuration depuis le réseau LAN local. On rappelle que le forum DSL est une association mondiale de plus de 200 entreprises du secteur des télécommunications. La majorité des équipements de type passerelles domestiques sont compatibles avec les recommandations de cette association. Suite à la diffusion d'un message de découverte SSDP (pour Simple Service Discovery Protocol en anglais) avec un champ "Search Type" de valeur "ST: urn:dslforum-org:device:InternetGatewayDevice:l", seule la passerelle Internet répond. Un exemple de requête de découverte est précisé ci-dessous: M-SEARCH * HTTP/1.1 MX: 10 ST: urn:dslforum-org: device:InternetGatewayDevice:1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" Dès que la passerelle répond, elle indique dans la réponse SSDP l'adresse IP et le port utilisé dans un champ Location pour obtenir une description des services offerts. Un exemple de réponse est précisé ci-dessous: HTTP/1.1 200 0K ST: urn:dslforum-org:device:InternetGatewayDevice:1 EXT: SERVER: pX/2.0 UPnP/1.0 Server/1.0 USN:uuid:739f75f0-a90c-4e42-ac13-2cc42d3c243e::urn:dslforum- org: device:InternetGatewayDevice:1 CACHE-CONTROL: max-age=1209600 LOCATION: http://192.168.0.1:51004/devicedesc.xml Content-Length: 0 Parmi les services supportés par une passerelle Internet conforme à la recommandation TR-064, il existe le service "LANHostConfigManagement". Ce service supporte l'obtention d'information sur les équipements du réseau LAN local, ainsi que la configuration IP du serveur DHCP, via les actions suivantes : - SetAddressRange permettant de définir une plage d'adresses utilisée 20 par le serveur DHCP ; - GetAddressRange permettant d'obtenir la plage d'adresses utilisée par le serveur DHCP ; - SetReservedAddresses permettant de définir une liste d'adresses IP marquées comme réservées (c'est-à-dire non allouables par ce serveur) ; 25 - GetReservedAddresses permettant d'obtenir la liste d'adresses IP marquées comme réservées (c'est-à-dire non allouables par ce serveur). Il est ainsi possible, par combinaison des actions SetAddressRange et SetReservedAddresses de définir l'espace d'adressage d'un serveur DHCP. Il existe également un autre service Hosts . Ce service apporte des 30 informations sur chaque équipement du réseau LAN local, notamment ceux pour qui 10 15 une adresse IP a été allouée par la passerelle via le protocole DHCP, mais aussi pour les équipements avec des adresses IP statiques, via les actions suivantes : - GetHostNumberOfEntries permettant d'obtenir le nombre d'équipements détectés ; - GetGenericHostEntry permettant d'obtenir les informations relevées pour chaque équipement détecté (adresse IP, indication si attribuée par le serveur DHCP, adresse MAC, état d'activité relatif à la présence de l'équipement). A travers les résultats issus de l'une quelconque de ces deux méthodes, il peut être ajouté des entrées à la table 550 de la figure 5 (décrite à titre d'exemple non limitatif). Les champs 551 et 552 représentent respectivement les adresses IP et Ethernet d'un équipement détecté sur le réseau. Les champs 553 et 554 représentent respectivement les types de protocoles ayant permis d'identifier un équipement et la classe d'équipement associée à cet équipement détecté sur le réseau. Une classe d'équipement (ou device class en anglais) désigne une fonctionnalité spécifique supportée par l'équipement. Par exemple, selon les recommandations de l'alliance DLNA (pour Digital Living Network Alliance en anglais), il est possible de lister les classes suivantes : DMP (pour Digital Media Player en anglais), DMS (pour Digital Media Server en anglais), IGD (pour Internet Gateway Device en anglais). Le standard UPnP fournit aussi des moyens d'identifier des équipements tels que des imprimantes, scanners, caméra de sécurité, etc... Les champs 553 et 554 dont la détermination n'a pas pu être obtenue sont notés comme indisponibles ( N/A ) Un champ 555 permet également de renseigner si un équipement est en cours d'activité sur son réseau LAN local. Il existe d'autres techniques pour identifier un équipement sur le réseau LAN local. Par exemple, si un équipement ne répond pas à un protocole de découverte tel que ceux cités ci-dessus, la tête de tunnel peut effectuer des tentatives de communications selon des protocoles bien connus de l'Internet (connexion HTTP sur le port 80, connexion FTP via le port 21, etc...) afin de déterminer si la machine visée héberge une application serveur, ou si elle ne semble qu'être cliente des équipements du réseau LAN local. La figure 5 illustre également un exemple de structure AVP 560 (pour Attribute Value Pair en anglais) selon le protocole L2TP afin d'envoyer une liste d'adresses à une tête de tunnel distante. L'utilisation de cette structure est explicitée plus en détail en relation avec l'étape 607 de la figure 6. La figure 6 schématise, selon un mode de réalisation particulier de l'invention, un algorithme pour la mise en oeuvre de l'étape 401 de la figure 4. Cet algorithme est implémenté sur une première tête de tunnel 101 en vue de la détermination de conflits d'adresses IP entre les deux sous-réseaux (103, 104) connectés via le tunnel L2TP (pour Layer 2 Tunneling Protocol en anglais). Pour rappel, l'étape 400 de la figure 4 (précédant l'étape 401) correspond à la réception d'une demande d'établissement d'un tunnel de niveau 2 depuis une seconde tête de tunnel 102, par exemple compatible avec la norme L2TPv3 (pour Layer 2 Tunneling Protocol en anglais) de la norme RFC 2931. Ce protocole permet de transporter plusieurs connexions de niveau 2 dans un tunnel IP/UDP, le port UDP utilisé de manière standard étant le 1701. Selon ce protocole, l'établissement du tunnel se fait selon l'échange protocolaire suivant entre la première tête de tunnel 101 et la seconde tête de tunnel 102. Un échange (non représenté) en trois messages est d'abord établi pour mettre en route une connexion de contrôle (ou control connection en anglais) du tunnel L2TP, afin d'identifier les systèmes pairs et leurs capacités. Cette connexion de contrôle correspond à une phase de mise en place du tunnel L2TP, qui est suivie ensuite d'une phase de mise en place de session(s) dans ce tunnel chargée(s) alors de véhiculer les données de niveau 2 entre les deux sous-réseaux (103, 104) distants reliés par le tunnel 100 de communication. Un premier message de contrôle, dénommé Start-Control-Connection-Request (SCCRQ) est émis par la tête de tunnel client (par exemple 102) vers la tête de tunnel serveur (par exemple la première tête de tunnel 101) afin de débuter la mise en route du tunnel 100 selon le protocole L2TP. Un second message de contrôle, dénommé Start-Control-Connection-Reply (SCCRP) permet à la tête de tunnel serveur 101 d'indiquer en réponse au premier message SCCRQ, que la requête est acceptée et que l'établissement de la connexion de contrôle peut se poursuivre. Un troisième message de contrôle, dénommé Start-Control-Connection-Connected (SCCCN), termine la phase d'établissement de la connexion de contrôle L2TP entre la première tête de tunnel 101 et la seconde tête de tunnel 102.

Un message de contrôle Stop-Control-Connection-Notification (StopCCN) peut être envoyé par la première tête de tunnel 101 ou la seconde tête de tunnel 102 pour terminer la connexion du tunnel 100 (et éventuellement fermer toutes les sessions actives si besoin). Après l'établissement de la connexion de contrôle, des sessions individuelles peuvent être créées, chaque session correspondant à un flux de transport de niveau 2 entre la première tête de tunnel 101 et la seconde tête de tunnel 102. Ainsi, dans l'exemple proposé, l'étape 404 peut consister à autoriser l'établissement d'au moins une session du tunnel selon le protocole L2TP, c'est-à-dire autoriser la première tête de tunnel 101 à ouvrir une session suite à la demande de la seconde tête de tunnel 102, ou autre exemple, autoriser le module de filtrage de la première tête de tunnel 101 à transmettre des données issues du réseau LAN local sur une session du tunnel déjà établie entre la première tête de tunnel 101 et la seconde tête de tunnel 102. Afin de maximiser l'extensibilité dans le protocole L2TP, une méthode dénommée AVP (pour Attribute Value Pair en anglais) d'encodage uniforme des informations de contrôle et de donnée est proposée par ce protocole. Cette structure AVP consiste en une association entre un type d'attribut et la valeur de cet attribut, qui peut être réutilisable pour la transmission de toute information entre la première tête de tunnel 101 et la seconde tête de tunnel 102.

Ainsi, dans une première étape 600, dite d'obtention d'une première table d'allocation d'adresses, la première tête de tunnel 101 doit obtenir la liste des équipements répertoriés de son réseau local. Pour cela, elle applique un ensemble quelconque de méthodes de découvertes parmi les méthodes précitées en relation avec la figure 5. Le résultat de ce sondage est enregistré dans une table de type 550. De manière préférentielle, la mise à jour de la table 550 est continue et l'étape 600 ne fait qu'obtenir la dernière mise à jour en date de cette table. Ensuite, dans une étape 601, dite quatrième étape de configuration de filtrage, la première tête de tunnel 101 est configurée de sorte qu'elle filtre (ou bloque) toutes les communications susceptibles de transiter sur le tunnel. Ainsi, tous les paquets du premier sous-réseau 103 ne sont pas dans un premier temps acheminés via le tunnel 100 vers le second sous-réseau 104 distant. Le protocole L2TP prévoit l'échange d'informations de version du protocole L2TP, d'identification de la marque de l'équipement distant ou de structure AVP particularisée pour des extensions propriétaires. Ainsi, dans une étape 602, il est aisé pour la première tête de tunnel 101 de savoir si la seconde tête de tunnel 102 distante, avec laquelle elle a échangé les messages SCCRQ et SCCRP, implémente elle aussi les algorithmes de la présente invention. Une étape 603 permet de vérifier si la seconde tête de tunnel distante (dans l'exemple de l'invention) est adaptée à mettre en oeuvre les mécanismes de la présente invention. Dans le cas où la première tête de tunnel 101 est la seule adaptée à exécuter les mécanismes de la présente invention (résultat négatif lors de l'étape 603), la première tête de tunnel 101 doit par elle-même obtenir une liste des équipements en conflit avec ceux qu'elle a répertoriés localement. Pour se faire, elle doit sonder le second sous-réseau 104 distant afin de déterminer les doublons (ou conflits) d'adresse selon les moyens réseaux classiques. Aussi, une session doit être ouverte sur le tunnel 100 de la figure 1 afin d'envoyer ces requêtes de sondage vers le second sous-réseau 104 distant. Dans une étape 604, le module de filtrage 101A de la première tête de tunnel 101 est configuré de façon à réaliser une étape de configuration de filtrage, ci-après nommée troisième étape de configuration de filtrage dans la suite de la description. Cette troisième étape de configuration filtrage permet de ne laisser passer aucun échange entre le premier sous-réseau 103 et le second sous-réseau 104, et une session est ensuite ouverte sur le tunnel 100 selon le protocole L2TP. Ainsi, dans la direction de la première tête de tunnel 101 vers la seconde tête de tunnel 102, seuls les messages en provenance de la première tête de tunnel 101 sont véhiculés sur la session tunnel. Dans la direction opposée, la seconde tête de tunnel distante 102 n'étant pas adaptée à mettre en oeuvre les algorithmes de la présente invention, laisse transiter sur le tunnel 100 toutes les trames de niveau 2. Le module de filtrage 101A de la première tête de tunnel 101 capture les messages embarqués dans le tunnel qui lui sont destinés et détruit tous les autres messages à leur arrivée du tunnel (c'est-à-dire non transmis sur le premier sous-réseau 103). Dans une étape 605, la première tête de tunnel 101, selon un mode de réalisation préféré, met en place une politique de sondage des adresses IP du second sous-réseau 104 distant. Cette étape consiste en l'émission, via la session ouverte du tunnel 100, de requêtes ARP pour chaque adresse IP allouée connue du premier sous-réseau 103 à partir de chaque entrée de la table 550. Selon le protocole ARP, la première tête de tunnel 101 va émettre une trame de diffusion (ou broadcast frame en anglais) de niveau 2 s'adressant à l'ensemble des hôtes du second sous-réseau 104, comportant sa propre adresse physique et l'adresse IP recherchée. Si une machine du second sous-réseau 104 se reconnaît comme possédant l'adresse IP demandée, elle répond par envoi individuel (ou Unicast en anglais) à la première tête de tunnel 101. Toute réponse positive obtenue permet de construire une liste L1 des adresses IP en doublon (en conflit) entre le premier sous-réseau 103 et le second sous-réseau 104.

Dans le cas où cette liste L1 est vide, c'est à dire si aucune adresse du premier sous-réseau 103 et du second sous-réseau 104 n'est en conflit, l'algorithme de résolution des conflits d'adresses se termine dans une étape 606. Sinon, l'étape suivante 402 est exécutée (cette étape est plus amplement décrite par la suite en relation avec la figure 7).

Dans le cas où les deux têtes de tunnel 101 et 102 sont adaptées à exécuter les mécanismes de la présente invention (résultat positif lors de l'étape 603), alors dans une étape 607, la première tête de tunnel 101 et la seconde tête de tunnel 102 s'échangent leur table 550 relative à leur réseau LAN local.

Typiquement, suite à la réception d'une requête SCCRQ , la première tête de tunnel 101 émet une réponse SCCRP à destination de la seconde tête de tunnel 102. Puis la seconde tête de tunnel 102 confirme, par le message SCCCN , l'ouverture de la connexion de contrôle du tunnel en ajoutant une structure AVP particulière 560 listant les adresses IP utilisées sur son second sous-réseau 104 (et extraite de la table 550 relative au second sous-réseau 104). La structure AVP 560 de la figure 5, selon le protocole de tunnellisation L2TP, permet d'envoyer une liste d'adresses à une tête de tunnel distante. La structure AVP 560 est alignée sur 32 bits. L'entête AVP 561 comprend un code d'attribut (noté AT pour Attribute Type en anglais) choisi de manière à ce que la tête de tunnel destinataire reconnaisse le type de structure envoyée. L'entête AVP 561 comprend en outre une indication du nombre (noté NE pour Number of Entries en anglais) d'équipements reconnus sur le réseau, une indication de la longueur (notée L pour Length en anglais) de la structure AVP, un identifiant du fabricant ou vendeur (noté VID pour Vendor Identifier en anglais) de la machine originaire de la structure AVP, un champ réservé (noté R pour Reserved en anglais) permettant de futures extensions de la structure AVP. Conformément aux recommandations de la norme RFC 3931 (L2TPv3), les deux bits de poids fort du premier mot de 32 bits de l'entête AVP 561 sont mis à 0 (bits M et H de l'entête AVP définie par la norme RFC 3931). De plus, la structure AVP 560 comprend en outre une partie données utiles 562 listant les adresses IP de ces équipements. Dans un mode de réalisation préféré, cette liste des adresses IP est formée des champs adresse IP 552 et des champs classe d'équipement 554 transmis sous forme de valeurs séparées par des virgules selon le format informatique ouvert en mode texte CSV (pour Comma-Separated Values en anglais). Bien évidemment, ce format CSV peut être tout à fait remplacé par un format de type XML ou de tout autre format adapté à la description de listes.

Ainsi, dans une étape 608, la première tête de tunnel 101 peut alors mener à bien une vérification des adresses IP en doublon (en conflit) entre le premier sous-réseau 103 et le second sous-réseau 104, en comparant sa liste locale 550 avec la liste de la seconde tête de tunnel 102 distante dont elle a reçu une structure AVP 560. S'il n'y a pas de conflit (test négatif lors de l'étape 608), les algorithmes prennent fin. Sinon, dans une étape 609, chaque adresse en doublon (en conflit) est référencée dans une liste L1 comportant, de manière préférentielle, au minimum des informations renseignant des adresses IP 552 en conflit, la classe d'équipement 554 pour l'équipement du premier sous-réseau 103, la classe d'équipement 554 pour l'équipement du second sous-réseau 104. Cette liste L1 est ensuite utilisée pour la mise en oeuvre de l'algorithme de l'étape 402 de la figure 4 et plus amplement décrit en relation avec la figure 7. La figure 7 décrit en détail l'algorithme de l'étape 402 de la figure 4 selon un mode de réalisation particulier de l'invention. La figure 7 illustre schématiquement un algorithme de la présente invention, implémenté sur la première tête de tunnel 101 en vue de l'application du correctif de gestion des adresses IP. La sélection des équipements sur lesquels appliquer ce correctif est réalisée de façon à perturber le moins possible le comportement du premier sous-réseau 103 et du second sous-réseau 104. Dans une étape 701, pour chaque entrée de la liste L1, il est procédé à la détermination du choix d'un équipement parmi deux équipements en conflit d'adresse, cet équipement étant préférentiellement choisi pour modifier son adresse IP. La liste L2 résultante est utilisée par la suite pour implémenter l'algorithme de l'étape 403 de la figure 4 et plus amplement décrit en relation avec la figure 8. Dans une étape 702 est déterminé si l'un des deux équipements est l'une des passerelles Internet 105 ou 106.

Si c'est le cas, une étape 710 permet de procéder à la sélection de l'équipement qui n'est pas une passerelle. Dans le cas où les deux passerelles sont en conflit d'adresse (étape non représentée), il est choisi préférentiellement la passerelle positionnée dans le réseau où est située la première tête de tunnel 101, c'est-à-dire la passerelle 105. Dans une étape 711, la passerelle sélectionnée est alors ajoutée à une liste L2 d'équipements. Si aucun des deux équipements n'est une des passerelles Internet 105 ou 106 (réponse négative à l'étape 702), il est choisi de préférence, dans une étape 703, un équipement de classe cliente (par exemple, DMP ou N/A). En effet, il est moins perturbant pour le réseau de changer l'adresse IP d'un poste client que de changer l'adresse IP d'un serveur, dont les services peuvent être utilisés par d'autres équipements du réseau. Une étape 704 permet de vérifier si un seul des équipements parmi les deux équipements sélectionnés est un client. Si c'est le cas, celui-ci est sélectionné puis ajouté à la liste L2 d'équipements dans l'étape 711. Si ce n'est pas le cas, une étape 705 permet de choisir de préférence un équipement supportant un protocole de découverte comme par exemple le protocole UPnP, car ce protocole avertira les autres équipements du réseau des modifications d'adressage pour accéder à cet équipement UPnP. Une étape 706 permet de vérifier si un seul des équipements de la paire d'équipements en cours d'analyse supporte le protocole UPnP. Si c'est le cas, celui-ci est sélectionné puis ajouté à la liste L2 d'équipements dans l'étape 711. Si ce n'est pas le cas, une étape 707 permet de vérifier lequel des deux équipements en conflit a des communications établies avec d'autres dispositifs de son réseau LAN local. Dans une étape 708 est vérifié si le test de l'étape 707 a permis ou non de déterminer un équipement privilégié.

Si aucun équipement privilégié n'est déterminé, n'importe lequel des deux équipements est alors sélectionné dans une étape 709 pour ensuite être ajouté à la liste L2 d'équipements dans l'étape 711. Si un équipement privilégié est déterminé, celui-ci est ajouté à la liste L2 d'équipements dans l'étape 711. Il est à noter que cet algorithme de sélection est donné à titre d'exemple. Bien évidemment, tout autre critère de sélection peut être envisagé comme, par exemple, une sélection statique faite par un utilisateur d'un réseau local et listant les équipements serveurs à ne pas modifier.

La figure 8 décrit en détail l'algorithme mis en oeuvre lors de l'étape 403 de la figure 4, et implémenté sur une première tête de tunnel 101 en vue de l'application du correctif de gestion des adresses IP selon la présente invention. Cet algorithme se décompose principalement en trois phases successives : - une phase de préparation des conditions conduisant au succès des réallocations d'adresses et formée de la suite d'étapes 801 à 806 ; - une phase de réallocation d'adresse pour chaque équipement sélectionné et constituée de la suite d'étapes 807 à 808 ; - une phase de mise à jour du réseau avec les nouvelles adresses issues de la phase de réallocation et formée de la suite d'étapes 809 à 810.

Une première étape 801 consiste à vérifier la disponibilité d'adresses libres sur les serveurs DHCP afin de fournir de nouvelles adresses pour les équipements en conflit. Plus précisément, l'étape 801 permet d'obtenir le nombre d'adresses disponibles (non allouées à un équipement) comprises dans les espaces d'adressage associés au premier sous-réseau 103 et au second sous-réseau 104.

En effet, suite à l'étape 401 de la figure 4, la première tête de tunnel 101 connaît le nombre de machines connectées au réseau LAN local grâce à sa table des équipements 550, le nombre de machines connectées au réseau LAN distant grâce à la structure AVP 560, et le besoin de réaffectation d'adresses grâce aux listes L1 et L2. Suite à la recommandation TR-64 précitée, la première tête de tunnel 101 est capable d'interroger le service LANHostConfigManagement grâce à l'action GetAddressRange , ceci afin d'obtenir l'espace d'adressage configuré pour le serveur DHCP de chacune des passerelles Internet 105 et 106. Une étape 802 suivante permet de vérifier s'il est nécessaire de réaliser une extension d'au moins un des espaces d'adressage associés aux premier et second sous- réseaux (103, 104). Cette étape 802 est notamment réalisée par comparaison du nombre d'adresses disponibles obtenu à l'étape 801 avec le nombre d'équipements sélectionnés. Si aucune extension n'est nécessaire, c'est-à-dire si le nombre d'adresses disponibles est supérieur au nombre d'équipements sélectionnés, une étape 806 suivante est réalisée. Cette étape 806 est plus amplement décrite dans la suite de la description.

Si le nombre d'adresses disponibles est inférieur au nombre d'équipements sélectionnés, une étape 803 permet de réaliser une extension d'au moins un des espaces d'adressage associés aux premier et second sous-réseaux (103, 104). Plus précisément, dans l'étape 803, au moins un des serveurs DHCP reçoit une commande d'extension de son espace d'adressage. Cette requête est conforme aux services UPnP IGD LANHostConfigManagement des passerelles Internet et correspondant à l'action SetAddressRange avec une valeur supérieure ou égale au besoin détecté lors de l'étape 801. De manière préférentielle, chaque serveur DHCP est mis à jour afin de supporter un nombre minimal de renouvellement d'adresses correspondant au nombre d'équipements sélectionnés de son réseau LAN local. Par exemple, si la première tête de tunnel 101 a sélectionné trois équipements du premier sous-réseau 103 et quatre équipements du second sous-réseau 104 pour la réallocation d'adresse, la première tête de tunnel 101 cherche à obtenir un ensemble libre d'au moins trois adresses pour le serveur DHCP de la passerelle 105 et au moins quatre adresses pour le serveur DHCP de la passerelle 106.

Une étape 804 permet de vérifier si les serveurs DHCP ont pu être configurés correctement. Si aucun des serveurs n'a pu être configuré correctement, une alternative est proposée dans une étape 805 en démarrant un nouveau serveur DHCP sur la première tête de tunnel 101, ce serveur DHCP possédant un espace d'adressage complémentaire des espaces d'adressage des serveurs DHCP déjà actifs des premier et second sous-réseaux (103, 104), notamment les serveurs DHCP des passerelles Internet. Une étape suivante 806 de configuration, dite première étape de configuration de filtrage, du module de filtrage 101A de la première tête de tunnel 101 en accord avec les résultats de la phase de configuration précédente (étapes 801 à 805). Ainsi configuré, le module de filtrage 101A laisse transiter via le tunnel, outre les messages entre les première et seconde têtes de tunnel relatifs à la gestion du tunnel, uniquement les requêtes réseau utiles pour permettre aux clients DHCP de parvenir à une réallocation d'adresse IP. Cela concerne bien sûr les messages DHCP de clients non présents physiquement sur le même réseau que le serveur DHCP devant lui répondre, mais aussi les messages ICMP et ARP émis pour la validation de nouvelles adresses IP pour ces clients. Dans un premier mode de réalisation, s'il est déterminé lors de l'étape 603 de la figure 6 que la seconde tête de tunnel 102 est adaptée à mettre en oeuvre les algorithmes de la présente invention, la seconde tête de tunnel 102 ne filtre aucune des communications du tunnel établi avec la première tête de tunnel 101. Ainsi, la première tête de tunnel 101 est seule garante de l'autorisation des communications véhiculées dans le tunnel. Dans un second mode de réalisation privilégié, et dans le but d'optimiser la ressource de bande passante utile du tunnel, la première tête de tunnel 101 indique à la seconde tête de tunnel 102 supportant l'invention, une information de filtrage des communications véhiculées sur le tunnel à mettre en place sur le module de filtrage 102A. Par exemple, il peut être utilisé une structure AVP de type 560 de la figure 5 pour véhiculer la liste des équipements (identifiés par leurs adresses MAC) autorisés à communiquer sur le tunnel. Cette structure 560 peut typiquement être véhiculée dans un message de contrôle HELLO du protocole L2TP. Afin de réallouer de nouvelles adresses IP aux équipements sélectionnés, une étape 807 suivante est ensuite réalisée pour inciter le client DHCP à demander cette réallocation.

En fait, le message FORCERENEW du protocole DHCP est utilisé ici selon un usage détourné de la pratique commune prévue par la norme DHCP (ou DHCP reconfigure extension ) de la norme RFC 3203. La procédure prévoit que le serveur DHCP envoie un message DHCP FORCERENEW à un de ses clients pour forcer celui-ci à redemander la validation de sa configuration IP. Une telle demande de validation de configuration IP est effectuée grâce à un message DHCP REQUEST . Le serveur répond alors négativement à cette demande grâce à un message DHCP NAK afin de forcer le client à entrer de nouveau dans une phase complète de demande d'allocation d'adresse.

La première tête de tunnel 101 se substitue alors au serveur DHCP concerné, et envoie un message DHCP FORCERENEW avec comme adresses IP source et MAC source celles du serveur DHCP, et comme adresses IP et MAC destination celles du client DHCP sélectionné. Dans un mode de réalisation optionnel, il peut être ajouté un élément d'authentification utilisé entre le serveur DHCP et les clients qui lui sont associés, conformément à la norme RFC 3118. Le client DHCP sélectionné va alors émettre un message DHCP REQUEST vers le serveur DHCP, qui lui répondra alors les mêmes informations que le dispositif client possédait précédemment. Cependant, la norme DHCP prévoit la vérification par le client de l'unicité de l'adresse IP même en cas de procédure de renouvellement.

Ainsi, si le client découvre, par l'émission de message ARP comprenant cette adresse IP, que cette adresse IP est déjà utilisée (l'autre équipement du réseau distant répond à la requête ARP , le tunnel ayant été configuré dans l'étape 806 afin de laisser passer ces messages requête et réponse ARP), il envoie une réponse DHCP DECLINE au serveur DHCP pour lui indiquer que cette adresse est déjà affectée à un autre équipement. Il reprend ensuite une procédure de réallocation d'adresse complète. Cette seconde procédure conduit alors à l'utilisation de l'une des adresses libres dans l'espace d'adressage préparé lors des étapes 803 ou 805. La première tête de tunnel 101 va ensuite écouter sur le réseau les résultats des réallocations d'adresse. Suite à une réallocation, l'équipement client DHCP vérifie l'unicité de l'adresse IP qui lui est proposée par l'un des serveurs DHCP. Comme indiqué précédemment, une requête ARP est émise en diffusion (ou broadcast ) au niveau Ethernet par ce client. Cette requête est donc transmise sur le premier sous-réseau 103 et le second sous-réseau 104. Ainsi, la première tête de tunnel 101 est capable de recevoir l'indication de la nouvelle adresse IP affectée à l'équipement sélectionné, peu importe que cet équipement soit localisé sur le premier sous-réseau 103 ou le second sous-réseau 104. Une étape 808 suivante consiste ensuite à détecter les requêtes ARP dont l'adresse MAC source est celle de l'équipement DHCP client sélectionné. L'adresse IP de l'équipement DHCP client sélectionné est alors extraite de la requête détectée.

Une fois ces nouvelles adresses IP déterminées pour les équipements sélectionnés, une étape 809 permet de vérifier la conformité de la configuration de la passerelle Internet 105 ou 106. En effet, il est vérifié si l'ancienne adresse IP de chaque équipement sélectionné est référencée par un service actif de la passerelle Internet de son réseau LAN local. Par exemple, selon la spécification UPnP IGD (reprise par la recommandation TR-64 précitée), un service WANIPConnection ou WANPPPConnection est obligatoire et permet de modifier la table de translation des adresses pour les communications de l'Internet vers une machine du réseau LAN local ( NAT PortMapping ). Ce service NAT PortMapping est en charge d'analyser les paquets arrivant sur l'interface WAN (c'est-à-dire connectée à l'Internet) de la passerelle Internet 105 ou 106, et de les rediriger vers l'équipement destinataire du réseau LAN local en effectuant une translation d'adresse IP et de port. Par exemple, un équipement client du réseau LAN local peut mettre en oeuvre un serveur HTTP, et avoir configuré la passerelle Internet pour rediriger les requêtes reçues de l'Internet en direction du serveur HTTP, et rendre ainsi accessible depuis l'Internet le serveur HTTP qui ne dispose que d'une adresse IP non-routable. Ainsi, en interrogeant le service par l'action UPnP GetGenericPortMappingEntry , la première tête de tunnel 101 peut détecter la présence dans la table NAT de l'ancienne adresse IP d'un équipement sélectionné (champ InternalClient ), et peut mettre à jour cette table en utilisant par exemple les commandes UPnP DeletePortMapping et AddPortMapping avec utilisation de l'ancienne et nouvelle adresse IP de l'équipement sélectionné. Dans une étape 810, le module de filtrage 101A de la première tête de tunnel 101 est configuré en accord avec les résultats de la phase de réallocation précédente (étapes 807 et 808). Cette étape 810 de filtrage, dite seconde étape de configuration de filtrage, permet de configurer la première tête de tunnel 101 de manière à laisser transiter sur le tunnel toutes les communications du premier sous-réseau 103 et du second sous-réseau 104 pour chaque équipement n'étant plus en conflit d'adresses. Dans un mode de réalisation privilégié, la première tête de tunnel 101 commande aussi la mise à jour du module de filtrage 102A de la seconde tête de tunnel 102. Dans un mode de réalisation optionnel, s'il persiste des conflits d'adresses (erreur lors de l'essai de reconfiguration des adresses), les communications relatives aux équipements toujours en conflit sont maintenues bloquées par le module de filtrage 101A de la tête de tunnel 101. La figure 9 illustre un dispositif mettant en oeuvre le procédé de la présente invention, selon un mode de réalisation particulier. Un appareil mettant en oeuvre l'invention est par exemple un dispositif de communication générique 1000.

Par exemple, la première tête de tunnel 101 ou la seconde tête de tunnel 102 précitée en relation avec la figure 1 est identique au dispositif générique 1000. Ce dispositif générique 1000 peut notamment être connecté à tout moyen de stockage d'image, de vidéos, ou de sons reliés à une carte graphique et délivrant au dispositif générique 1000 des données multimédia.

Ainsi, le dispositif générique 1000 comporte un bus de communication 1002 auquel sont reliés : - une unité centrale de traitement 1003 (qui est par exemple un microprocesseur référencé CPU) ; - une mémoire morte 1004 référencée ROM, pouvant comporter le ou les logiciel(s) précité(s) et référencé(s) Prog ; - une mémoire vive 1006 (mémoire cache référencée RAM), comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; - une interface de communication 1018 reliée à au moins un réseau de communication 1020, par exemple le premier sous-réseau 103 ou le second sous-réseau 104 et le réseau fédérateur 107 de type Internet, l'interface étant adaptée à transmettre et à recevoir des données avec ces réseaux. Le dispositif générique 1000 comprend également optionnellement : - un écran 1008 permettant de visualiser des données et/ou de servir d'interface graphique avec l'administrateur réseau pour interagir avec les programmes selon l'invention, à l'aide d'un clavier 1010 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 1011 ou un crayon optique ; - un disque dur 1012 pouvant comporter le ou les logiciel(s) "Prog" précités. Le bus de communication 1002 permet la communication et l'interopérabilité entre les différents dispositifs inclus dans le dispositif générique 1000 ou reliés à cet équipement. De manière plus générale, grâce au bus de communication 1002, l'unité centrale 1003 est susceptible de communiquer des instructions à tout dispositif inclus dans le dispositif générique 10200 directement ou par l'intermédiaire d'un autre dispositif du dispositif générique 1000. Le code exécutable de chacun du ou des logiciel(s) précités permettant au dispositif générique 1000 de mettre en oeuvre le procédé selon l'invention de gestion de conflit d'adressage IP entre deux réseaux distincts en cours d'association, peut être stocké, par exemple, dans le disque dur 1012 ou dans la mémoire morte 1004.

L'unité centrale 1003 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des logiciel(s) selon l'invention. Lors de la mise sous tension, le ou les logiciels qui sont stockés dans une mémoire non volatile (par exemple le disque dur 1012 ou la mémoire morte 1004), sont transférés dans la mémoire vive 1006 qui contiendra alors le code exécutable du ou des logiciel(s) selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre du procédé d'accélération temporaire de l'accroissement du débit d'émission d'un serveur TCP selon l'invention. Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé.

Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC). On notera que l'invention ne se limite pas à une implantation purement matérielle mais qu'elle peut aussi être mise en oeuvre sous la forme d'une séquence d'instructions d'un programme informatique ou toute forme mixant une partie matérielle et une partie logicielle. Dans le cas où l'invention est implantée partiellement ou totalement sous forme logicielle, la séquence d'instructions correspondante pourra être stockée dans un moyen de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce moyen de stockage étant lisible partiellement ou totalement par un ordinateur ou un microprocesseur.15

Claims

REVENDICATIONS1. Procédé de gestion d'espaces d'adressage lors d'un établissement de tunnel (100) de communication entre une première tête de tunnel (101) d'un premier sous-réseau (103) de communication et une seconde tête de tunnel (102) d'un second sous-réseau de 5 communication (104) distinct dudit premier sous-réseau, chaque équipement connecté à un sous-réseau donné parmi lesdits premier et second sous-réseaux possédant une adresse comprise dans un espace d'adressage associé audit sous-réseau donné, ledit procédé étant effectué par la première tête de tunnel et caractérisé en ce qu'il comprend des étapes consistant à : - détecter (401) au moins une paire d'équipements possédant une même adresse, chaque paire d'équipements comprenant un premier équipement du premier sous-réseau et un second équipement du second sous-réseau ; - sélectionner (402) au moins un équipement de chaque paire d'équipements ; - allouer (403) une nouvelle adresse à chaque équipement sélectionné ; et - établir le tunnel entre les premier et second sous-réseaux.
2. Procédé selon la revendication 1, caractérisé en ce que l'étape consistant à allouer une nouvelle adresse comprend des étapes consistant à : - obtenir (801) un nombre d'adresses comprises dans les espaces d'adressage associés auxdits premier et second sous-réseaux et qui ne sont pas allouées à un équipement desdits premier et second sous-réseaux ; - comparer (802) ledit nombre d'adresses avec le nombre d'équipements sélectionnés ; - si ledit nombre d'adresses est inférieur au nombre d'équipements sélectionnés, étendre (803, 804, 805) au moins un des espaces d'adressage associés auxdits premier et second sous-réseaux afin de rendre ledit nombre d'adresses supérieur ou égal au nombre d'équipements sélectionnés.
3. Procédé selon la revendication 2, caractérisé en ce que l'étape consistant à étendre au moins un des espaces d'adressage comprend au moins une des étapes suivantes, consistant à : 30 - étendre (803) l'espace d'adresses d'au moins un serveur d'adresses actif de l'un desdits premier et second sous-réseaux ; 10 15 20 25- démarrer (805) un nouveau serveur d'adresses, possédant un espace d'adressage dont les adresses sont distinctes des adresses des espaces d'adressage des serveurs d'adresses déjà actifs desdits premier et second sous-réseaux.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape consistant à allouer une nouvelle adresse est précédée d'une étape consistant à modifier la configuration de filtrage de la première tête de tunnel pour effectuer un premier filtrage (806) permettant de laisser transiter entre les premier et second sous-réseaux via le tunnel uniquement des messages se rapportant à une allocation d'adresse, et en ce que l'étape consistant à établir le tunnel est précédée d'une étape consistant à modifier la configuration de filtrage de la première tête de tunnel en fonction de la (des) nouvelle(s) adresse(s) allouée(s) au(x) dispositif(s) sélectionné(s).
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'étape consistant à allouer une nouvelle adresse comprend une étape consistant à mettre à jour (809) une passerelle d'accès par le premier sous-réseau à un réseau fédérateur (107), en fonction de la nouvelle adresse de chaque équipement sélectionné.
6. Procédé selon l'une quelconque des revendications 4 à 5, caractérisé en ce que l'étape consistant à allouer une nouvelle adresse comprend des étapes consistant à : - déterminer, s'il existe, au moins un équipement sélectionné auquel une nouvelle adresse n'a pas pu être allouée, dit équipement toujours en conflit ; - modifier la configuration de filtrage de la première tête de tunnel pour effectuer un deuxième filtrage (810) permettant de ne pas laisser transiter sur le tunnel des messages se rapportant audit équipement toujours en conflit.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que l'étape consistant à détecter (401) au moins une paire d'équipements possédant une même adresse comprend des étapes consistant à : - obtenir une première table d'allocation d'adresses au sein du premier sous-réseau ; - obtenir (607) une seconde table d'allocation d'adresses au sein du second sous-réseau ;- détecter (608, 609) ladite au moins une paire d'équipements possédant une même adresse, par comparaison desdites première et seconde tables d'allocation d'adresses.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que l'étape consistant à détecter (401) au moins une paire d'équipements possédant une même adresse comprend des étapes consistant à : - obtenir une première table d'allocation d'adresses au sein du premier sous-réseau ; - transmettre (605), vers la seconde tête de tunnel, un message de sondage du second sous-réseau pour chaque adresse de ladite première table d'allocation d'adresses ; - détecter (605) ladite au moins une paire d'équipements possédant une même adresse, par analyse d'un message de réponse au message de sondage.
9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que l'étape consistant à sélectionner (402) au moins un équipement de chaque paire d'équipements est effectuée en fonction d'au moins une règle appartenant au groupe comprenant : - si une paire d'équipements en comprend un, on sélectionne (702, 710) un équipement qui n'est pas une passerelle d'accès à un réseau fédérateur (107) ; - si une paire d'équipements en comprend un, on sélectionne (703, 704) un équipement qui est de type client ; - si une paire d'équipements en comprend un, on sélectionne (707, 708) un équipement qui n'a pas d'activité de communications sur le réseau ; - si une paire d'équipements en comprend un, on sélectionne un équipement qui n'est pas compris dans une liste prédéterminée d'équipements dont les adresses ne doivent pas être modifiées.
10. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme 30 pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 9, lorsque ledit programme est exécuté sur un ordinateur. 25
11. Moyen de stockage lisible par ordinateur, éventuellement totalement ou partiellement amovible, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 9.
12. Dispositif de gestion d'espaces d'adressage lors d'un établissement de tunnel (100) de communication entre une première tête de tunnel (101) d'un premier sous-réseau (103) de communication et une seconde tête de tunnel (102) d'un second sous-réseau de communication (104) distinct dudit premier sous-réseau, chaque équipement connecté à un sous-réseau donné parmi lesdits premier et second sous-réseaux possédant une adresse comprise dans un espace d'adressage associé audit sous-réseau donné, caractérisé en ce que la première tête de tunnel comprend : - des premiers moyens de détection d'au moins une paire d'équipements possédant une même adresse, chaque paire d'équipements comprenant un premier équipement du premier sous-réseau et un second équipement du second sous-réseau ; - des moyens de sélection d'au moins un équipement de chaque paire d'équipements ; - des moyens d'allocation d'une nouvelle adresse à chaque équipement sélectionné ; et - des moyens d'établissement du tunnel entre les premier et second sous-réseaux.
13. Dispositif selon la revendication 12, caractérisé en ce que les moyens d'allocation d'une nouvelle adresse comprend : - des premier moyens d'obtention d'un nombre d'adresses comprises dans les espaces d'adressage associés auxdits premier et second sous-réseaux et qui ne sont pas allouées à un équipement desdits premier et second sous-réseaux ; - des moyens de comparaison dudit nombre d'adresses avec le nombre d'équipements sélectionnés ; - si ledit nombre d'adresses est inférieur au nombre d'équipements sélectionnés des moyens d'extension d'au moins un des espaces d'adressage associés auxdits premier et second sous-réseaux afin de rendre ledit nombre d'adresses supérieur ou égal au nombre d'équipements sélectionnés. 20 25 30
14. Dispositif selon la revendication 13, caractérisé en ce que lesdits moyens d'extension comprennent : - des moyens d'extension de l'espace d'adresses d'au moins un serveur d'adresses actif de l'un desdits premier et second sous-réseaux ; - des moyens de démarrage d'un nouveau serveur d'adresses, possédant un espace d'adressage dont les adresses sont distinctes des adresses des espaces d'adressage des serveurs d'adresses déjà actifs desdits premier et second sous-réseaux.
15. Dispositif selon l'une quelconque des revendications 12 à 14, caractérisé en ce qu'il comprend des premier moyens de modification dela configuration de filtrage de la première tête de tunnel pour effectuer un premier filtrage (806) permettant de laisser transiter entre les premier et second sous-réseaux via le tunnel uniquement des messages se rapportant à une allocation d'adresse, et en ce qu'il comprend des second moyens de modification de la configuration de filtrage de la première tête de tunnel en fonction de la (des) nouvelle(s) adresse(s) allouée(s) au(x) dispositif(s) sélectionné(s).
16. Dispositif selon l'une quelconque des revendications 12 à 15, caractérisé en ce que les moyens d'allocation comprennent des moyens de mise à jour d'une passerelle d'accès par le premier sous-réseau à un réseau fédérateur (107), en fonction de la nouvelle adresse de chaque équipement sélectionné.
17. Dispositif selon l'une quelconque des revendications 15 à 16, et en ce que les moyens d'allocation comprennent en outre : - des moyens de détermination, s'il existe, d'au moins un équipement sélectionné auquel une nouvelle adresse n'a pas pu être allouée, dit équipement toujours en conflit ; - des troisième moyens de modification de la configuration de filtrage de la première tête de tunnel pour effectuer un deuxième filtrage (810) permettant de ne pas laisser transiter sur le tunnel des messages se rapportant audit équipement toujours en conflit. 5 10 15 20
18. Dispositif selon l'une quelconque des revendications 12 à 17, caractérisé en ce que les premiers moyens de détection d'au moins une paire d'équipements possédant une même adresse comprend : - des seconds moyens d'obtention d'une première table d'allocation d'adresses au sein du premier sous-réseau ; - des troisièmes moyens d'obtention d'une seconde table d'allocation d'adresses au sein du second sous-réseau ; - des seconds moyens de détection de ladite au moins une paire d'équipements possédant une même adresse, par comparaison desdites première et seconde tables d'allocation d'adresses.
19. Dispositif selon l'une quelconque des revendications 12 à 18, caractérisé en ce que les premiers moyens de détection d'au moins une paire d'équipements possédant une même adresse comprend des étapes consistant à : - des seconds moyens d'obtention d'une première table d'allocation d'adresses au sein du premier sous-réseau ; - des moyens de transmission, vers la seconde tête de tunnel, d'un message de sondage du second sous-réseau pour chaque adresse de ladite première table d'allocation d'adresses ; - des quatrièmes moyens de détection de ladite au moins une paire d'équipements possédant une même adresse, par analyse d'un message de réponse au message de sondage.