FR2938144A1

FR2938144A1 - Procede de gestion d'espaces d'adressage a la fermeture d'un tunnel de communication entre une premiere et une seconde tete de tunnel, produit programme d'ordinateur, moyen de stockage et dispositif correspondants.

Info

Publication number: FR2938144A1
Application number: FR0857424A
Authority: FR
Inventors: Stephane Baron; Pascal Viger
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2008-10-31
Filing date: 2008-10-31
Publication date: 2010-05-07
Anticipated expiration: 2028-10-31
Also published as: FR2938144B1

Abstract

Il est proposé un procédé de gestion d'espaces d'adressage à la fermeture d'un tunnel de communication entre une première tête de tunnel d'un premier sous-réseau et une seconde tête de tunnel d'un second sous-réseau. Plus précisément, la première tête de tunnel (101) effectue des étapes consistant à : - déterminer un ensemble de noeuds du premier sous-réseau : * dont les adresses ont été allouées par un serveur d'adresses du second sous-réseau, ou * dont les adresses ont été, préalablement à l'ouverture du tunnel, allouées par un serveur d'adresses du premier sous-réseau et libérées par un serveur d'adresses du second sous-réseau ; - activer (552) au moins un serveur d'adresses du premier sous-réseau, un espace d'adressage étant associé audit au moins un serveur ; - mettre à jour (553-558) ledit espace d'adressage en fonction des adresses des noeuds dudit ensemble de noeuds obtenu.

Description

Procédé de gestion d'espaces d'adressage à la fermeture d'un tunnel de communication entre une première et une seconde tête de tunnel, produit programme d'ordinateur, moyen de stockage et dispositif 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 une technique de gestion d'espaces d'adressage d'un réseau de communication de l'ouverture à la fermeture d'un tunnel de communication entre une première tête de tunnel d'un premier réseau et une seconde tête de tunnel d'un second réseau.

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 de voir 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 etlou 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 Virtual 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 (encore appelés ci-après réseaux LAN, pour Local Area Network en anglais). Dans la suite de la description est considéré uniquement les tunnels de niveau 2 ou inférieur. Par exemple, EtherlP (norme RFC 3378) et L2TP (pour Layer 2 Tunneling Protocol en anglais ou protocole de tunellisation de niveau 2 en français) ont été standardisés par l'IETF (pour Internet Engineering Task Force en anglais ou détachement d'ingénierie d'Internet en français) 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 réseaux privés virtuels 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. Les réseaux privés virtuels sécurisés incluent un algorithme de cryptographie et d'authentification pour garantir le secret des données transportées. Une configuration typique de RPV basé 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 la désencapsuler et l'envoyer sur le réseau LAN distant. Du point de vue des équipements, ils sont virtuellement connectés à un même réseau LAN.

Le protocole DHCP (pour Dynamic Host Configuration Protocol en anglais ou protocole de configuration automatique de clients en français) est un protocole réseau dont le rôle est d'assurer la configuration automatique des paramètres IP d'un équipement du réseau, notamment en lui assignant automatiquement une adresse IP et un masque de sous-réseau lors de son démarrage. Ce protocole DHCP est défini par la norme RFC 1531, modifiée et complétée par les normes RFC 1534, RFC 2131 et RFC 2132. 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 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). 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 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 un ensemble de paramètres permettant à la machine de communiquer sur le réseau. La technique utilisée est dite de broadcast (ou diffusion). Pour trouver et dialoguer avec un serveur DHCP, la machine va simplement émettre un paquet de diffusion (ou broadcast en anglais), à destination d'une adresse IP 255.255.255.255. Ce paquet de diffusion va être reçu par toutes les machines connectées au réseau (particularité du broadcast ). Lorsque le serveur DHCP reçoit ce paquet, il répond par un autre paquet de broadcast contenant toutes les informations requises pour la configuration. Si le client accepte la configuration, il renvoie un paquet pour informer le serveur qu'il garde les paramètres, sinon, il fait une nouvelle demande. Lors de l'utilisation sur un même segment de plusieurs serveurs DHCP, l'intersection des espaces d'adressage des différents serveurs DHCP 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. Pour résoudre ce problème d'intersection des espaces d'adressage, 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 est adapté à 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 (peur IPv4 Address Conflict Detection en anglais ou détection des conflits d'adresses IP version 4 en français) précise les modalités d'application (nombre de tests à effectuer, délai d'attente de réponse d'un autre poste client éventuel...). 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). Dans le cas par exemple où un groupe d'utilisateur désire faire de la visioconférence, du partage de fichier, du jeu en réseau, ou bien toute autre application réseau à plusieurs, l'utilisation de tunnel permet de créer à partir des différents réseaux LAN, un seul réseau virtuel privé dans lequel les utilisateurs peuvent faire facilement communiquer leurs applications. Il est à préciser également 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 les espaces 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. Il existe des préconisations, pour la mise en oeuvre de ces passerelles, émises par le DSL Forum. La recommandation TR124 ( Functional Requirements for Broadband Residential Gateway Devices , December 2006, DSLHome-Technical Working Group, et plus particulièrement la section LAN.DHCPS) concerne la gestion d'un serveur DHCP embarqué dans une passerelle. Cette recommandation stipule que le serveur DHCP embarqué doit se désactiver s'il détecte la présence d'un autre serveur DHCP sur le réseau local. Cette préconisation a été mise en place pour éviter les effets indésirables dus à la présence de deux serveurs DHCP fonctionnant simultanément sur un même réseau local (conflits d'espaces d'adressage, imprédictibilité de la configuration réseau, etc.). Lors de l'établissement d'un tunnel entre deux têtes de tunnel de deux réseaux LAN distints, le serveur DHCP d'une passerelle va détecter le serveur DHCP de l'autre passerelle (de son point de vue, il s'agit d'un serveur DHCP sur le réseau LAN local car le tunnel rend transparent le réseau WAN), et va donc se désactiver. Par la suite, tout nouvel équipement connecté à l'un ou l'autre des deux réseaux LAN constituant le VPN va se voir affecter une adresse IP par le seul serveur DHCP encore actif. Tout cela fonctionne très bien tant que le tunnel est ouvert.

Mais, dans un environnement domestique, les réseaux privés virtuels créés sont dynamiques, et éphémères (contrairement au monde professionnel). Lors de la fermeture du tunnel constituant le réseau privé, il existe un problème d'incohérence potentielle de l'espace d'adressage IP du réseau local. D'une part, les équipements ayant reçu une configuration IP de la part d'un serveur DHCP disparu ont potentiellement une configuration réseau devenue incorrecte, pouvant ainsi leur interdire d'avoir accès à certains services réseaux (DNS, accès à l'Internet, etc.). D'autre part, la configuration du serveur DHCP local ne reflète plus la réalité des équipements qu'il est censé servir (dans certains cas, le serveur DHCP est d'ailleurs devenu inactif...). En particulier, il ne connaît pas certains équipements, ou bien encore, certaines adresses IP sont bloquées (le serveur est persuadé que ces adresses sont affectées à des équipements du réseau LAN, alors que ceux-ci ont disparu). 2. ARRIÈRE-PLAN TECHNOLOGIOUE On connaît, dans l'état de la technique, différents types de mécanismes pour éviter les conflits de serveurs d'adresse, comme c'est le cas par exemple dans la norme RFC 2131 (pour Request For Comment en anglais ou demande de commentaires en français) décrivant le comportement du protocole DHCP face à la présence de plusieurs serveurs sur le réseau. De même, la recommandation du DSL forum TR124( Functional Requirements for Broadband Residential Gateway Devices , December 2006, DSLHome-Technical Working Group) précise comment éviter que deux serveurs d'adresses ne rentrent en conflit, tout simplement en désactivant un des deux serveurs d'adresse. Ces mécanismes se mettent en oeuvre lors de l'ouverture d'un tunnel, mais peu de choses sont prévues pour gérer la cohérence de l'espace d'adressage à la fermeture d'un tunnel. En effet, la raison vient du fait que la plupart des publications sur le sujet traitent de réseaux privés professionnels qui sont établis entre deux succursales par exemple. Dans ces conditions, les problèmes d'espace d'adressage apparaissent lors de la mise en place du réseau privé virtuel, et la question de sa fermeture ne se pose pas du fait qu'elle n'est tout simplement pas prévue. D'un autre côté, les problèmes cités précédemment (équipement avec une configuration réseau erronée ou bien encore une adresse bloquée sur un serveur d'adresses) se résolvent seuls, par le simple fait que toute affectation d'adresse IP à un équipement possède une durée de validité limitée (typiquement 24 heures). Ainsi, en attendant suffisamment longtemps, les différents problèmes rentreront dans l'ordre sans intervention particulière.

Toutefois, le problème apparaît clairement lorsque l'on a affaire à des réseaux privés virtuels dynamiques et éphémères, qui se connectent et se déconnectent rapidement à différents points comme c'est le cas dans un environnement utilisateur individuel. Parmi les solutions proposées pour rétablir un espace d'adressage à la fermeture d'un tunnel, un document de brevet W00175626 ( EICON TECHNOLOGY CORP, BRIDGE CONFIGURATION OVER IP/WEB ) propose une technique permettant de gérer le problème de la perte de serveur DHCP lors de la fermeture accidentelle d'un tunnel. Lors de la détection de la fermeture d'un tunnel, ce document de brevet propose d'espionner le trafic sur le réseau LAN à la recherche de requêtes d'affectation d'adresse non traitées. Il en est alors déduit que le système d'affectation d'adresse du réseau LAN résultant de la fermeture du tunnel ne fonctionne plus, car il ne possède plus de serveur d'adresses actif. Un serveur d'adresses est alors mis en place afin de répondre aux requêtes d'affectation d'adresse non traitées. Ce serveur détermine l'adresse à affecter en recherchant une adresse non affectée sur le réseau. Puis, il configure la passerelle du réseau LAN afin que celle-ci permettent l'accès à Internet pour l'équipement. La solution technique proposée dans ce document de brevet EICON TECHNOLOGY repose sur la fin du bail du serveur DHCP. C'est-à-dire que les équipements réseau ne fonctionnent potentiellement plus jusqu'à l'expiration du bail, qui rappelons le est par défaut de 24h dans les passerelles du commerce (mais peut être infini...). De plus, une telle solution technique repose sur une analyse de l'ensemble des trames circulant sur le réseau, ce qui est très coûteux en ressource CPU (pour Central Processing Unit en anglais ou unité centrale de traitement en français ). Enfin, cette solution technique modifie les paramètres réseaux de la passerelle afin de permettre l'accès d'un équipement dont ils ont affecté l'adresse. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation particulier, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, dans au moins un mode de réalisation particulier de l'invention, un objectif est de fournir une solution technique permettant de gérer la cohérence d'espaces d'adressages de serveurs d'adresses suite à la fermeture d'un tunnel. Un autre objectif de l'invention est de fournir une technique peu coûteuse en ressource CPU.

Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique simple à mettre en oeuvre et pour un moindre coût. 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 à la fermeture d'un tunnel de communication entre une première tête de tunnel d'un premier sous-réseau et une seconde tête de tunnel d'un second sous-réseau. La première tête de tunnel effectue des étapes consistant à : - déterminer un ensemble de noeuds du premier sous-réseau : * dont les adresses ont été allouées par un serveur d'adresses du second sous-réseau, ou * dont les adresses ont été, préalablement à l'ouverture du tunnel, allouées par un serveur d'adresses du premier sous-réseau et libérées par un serveur d'adresses du second sous-réseau ; - activer au moins un serveur d'adresses du premier sous-réseau, un espace d'adressage étant associé audit au moins un serveur ; - mettre à jour ledit espace d'adressage en fonction des adresses des noeuds dudit ensemble de noeuds obtenu. Ainsi, dans ce mode de réalisation particulier, l'invention repose sur une approche tout à fait nouvelle et inventive consistant, à la fermeture d'un tunnel de communication reliant les premier et second serveurs d'adresses, à déterminer au moins un serveur d'adresses actif du premier sous-réseau et à mettre à jour l'espace d'adressage de ce au moins un serveur d'adresses actif, afin de garantir la cohérence de ce premier sous-réseau (après la fermeture du tunnel entre les premier et second sous-réseaux). L'espace d'adressage dudit au moins serveur actif reflète alors la réalité des équipements déconnectés du réseau.

Il est à noter que dans le cadre de l'invention, un sous-réseau est à interpréter comme étant un ensemble d'un ou plusieurs réseaux LAN, du fait qu'un sous-réseau peut comprendre une ou plusieurs têtes de tunnel. De manière générale, ce procédé permet d'éviter le problème d'incohérence de l'espace d'adressage d'un réseau LAN local lors de la fermeture d'un tunnel de communication reliant ce réseau LAN local à un autre réseau LAN distant. Ce procédé permet en outre d'éviter les problèmes de conflit de serveur d'adresses. De façon avantageuse, l'étape consistant à mettre à jour l'espace d'adressage comprend des étapes consistant à, pour au moins une adresse donnée dudit ensemble de noeuds obtenus : - vérifier que ladite adresse donnée est comprise dans ledit espace d'adressage ; - en cas de vérification positive, allouer l'adresse donnée auprès dudit au moins un serveur d'adresses activé. Ainsi, après mise à jour, l'espace d'adressage reflète la réalité des adresses allouées (par un serveur d'adresses du second sous-réseau) durant la période pendant laquelle le tunnel était ouvert. Avantageusement, l'étape consistant à mettre à jour l'espace d'adressage comprend en outre une étape consistant à, en cas de vérification négative, forcer le noeud auquel l'adresse donnée est allouée à obtenir une nouvelle adresse auprès dudit au moins un serveur d'adresses activé Ainsi, si la configuration réseau d'un équipement est erronée, ce dernier est forcé à redemander une nouvelle configuration réseau audit au moins serveur d'adresses activé suite à la fermeture du tunnel. Ceci permet d'éviter qu'un équipement possède une adresse allouée incompatible avec l'espace d'adressage du (des) serveur(s) activé(s).

Ceci permet de garantir le bon fonctionnement de cet équipement immédiatement après la rupture du tunnel. Le gain de temps est alors optimisé par rapport à l'état de l'art nécessitant d'attendre l'expiration du bail d'adresse (typiquement 24h...). Selon une caractéristique avantageuse, l'étape consistant à activer au moins un serveur d'adresses du premier sous-réseau comprend des étapes consistant à : - détecter s'il reste au moins un tunnel ouvert sur la première tête de tunnel; - s'il reste au moins un tunnel ouvert entre la première tête de tunnel et une troisième tête de tunnel du premier sous-réseau, collaborer avec la troisième tête de tunnel afin d'activer au moins un serveur d'adresses du premier sous-réseau ; - s'il ne reste aucun tunnel ouvert sur la première tête de tunnel, réactiver un ou des serveur(s) d'adresses présent(s) sur le premier sous-réseau et qui a (ont) été désactivé(s) préalablement à l'ouverture du tunnel entre la première tête de tunnel et la seconde tête de tunnel. Si le choix du ou des serveur(s) activé(s) du premier sous-réseau résulte d'une collaboration avec la troisième tête de tunnel, alors le(s) serveur(s) activé(s) est avantageusement interne à l'une des première et troisième têtes de tunnel. Ainsi, il est aisé d'effectuer des échanges de mises à jour entre les première et troisième têtes de tunnel, entre l'ouverture et la fermeture du tunnel entre celles-ci. Si le choix du ou des serveur(s) activé(s) du premier sous-réseau résulte d'une réactivation, le(s) serveur(s) réactivé(s) est avantageusement externe à la première tête de tunnel. Ainsi, un retrait ultérieur de la première tête de tunnel n'aura pas d'impact sur la gestion de l'espace d'adressage du premier sous-réseau. Selon une caractéristique avantageuse, la première tête de tunnel effectue, préalablement à l'ouverture du tunnel, une étape consistant à désactiver le ou les serveurs d'adresses présents sur le premier sous-réseau.

Ainsi, on évite ainsi les conflits de gestion d'adressage entre les premier et second sous-réseaux, entre l'ouverture et la fermeture du tunnel entre les première et seconde têtes de tunnel. Avantageusement, la première tête de tunnel effectue, préalablement à l'ouverture du tunnel, une étape consistant à collaborer avec la seconde tête de tunnel afin d'activer au moins un serveur d'adresses du second sous-réseau pour l'ensemble constitué des premier et second sous-réseaux. Ainsi, on évite ainsi les conflits de gestion d'adressage entre les premier et second sous-réseaux, entre l'ouverture et la fermeture du tunnel entre les première et seconde têtes de tunnel.

Préférentiellement, la première tête de tunnel effectue en outre, préalablement à l'ouverture du tunnel, des étapes consistant à : - obtenir des informations correspondant à un espace d'adressage courant, l'espace d'adressage courant étant associé audit ou auxdits serveur(s) d'adresses présent(s) sur le premier sous-réseau et désactivé(s) ; - utiliser ces informations pour mettre à jour ledit au moins un serveur d'adresses du second sous-réseau. Ainsi, on évite de réaliser des affectations d'adresses redondantes, entre l'ouverture et la fermeture du tunnel entre les première et seconde têtes de tunnel. De façon avantageuse, entre l'ouverture et la fermeture du tunnel, la première tête de tunnel reçoit en provenance de la seconde tête de tunnel des mises à jour effectuées sur l'espace d'adressage associé audit serveur d'adresses du second sous-réseau activé. En outre, ladite étape consistant à déterminer, à la fermeture du tunnel, un ensemble de noeuds du premier sous-réseau est effectuée en prenant en compte les mises à jour reçues entre l'ouverture et la fermeture du tunnel. Ceci permet un gain en termes de cycles CPU en évitant l'écoute ( snoop en anglais) de toutes les trames transmises sur le réseau (ce qui est extrêmement consommateur en termes de cycle CPU). Il est toutefois à noter que dans une variante de réalisation, l'étape consistant à déterminer, à la fermeture du tunnel, un ensemble de noeuds du premier sous-réseau est effectuée grâce à la technique précitée d'écoute.

Avantageusement, les mises à jour sur l'espace d'adressage associé audit au moins un serveur d'adresses activé sont effectuées suite à au moins une requête d'allocation ou de libération d'adresse en provenance d'un équipement appartenant à l'ensemble constitué du premier sous-réseau et du second sous-réseau. Ainsi, le déclenchement des mises à jour est automatique et ne nécessite aucune données de signalisation particulière. 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 à la fermeture d'un tunnel de communication entre une première tête de tunnel d'un premier sous-réseau et une seconde tête de tunnel d'un second sous-réseau. La première tête de tunnel comprend: - des moyens de détermination d'un ensemble de noeuds du premier sous-réseau : * dont les adresses ont été allouées par un serveur d'adresses du second sous-réseau, ou * dont les adresses ont été, préalablement à l'ouverture du tunnel, allouées par un serveur d'adresses du premier sous-réseau et libérées par un serveur d'adresses du second sous-réseau ; - des moyens d'activation d'au moins un serveur d'adresses du premier sous-réseau, un espace d'adressage étant associé audit au moins un serveur ; - des moyens de mise à jour dudit espace d'adressage en fonction des adresses des noeuds dudit ensemble de noeuds obtenu. Avantageusement, les moyens de mise à jour dudit espace d'adressage comprennent, pour au moins une adresse donnée dudit ensemble de noeuds obtenus : - des moyens de vérification que ladite adresse donnée est comprise dans ledit espace d'adressage ; - en cas de vérification positive, des moyens d'allocation de ladite adresse donnée 25 auprès dudit au moins un serveur d'adresses activé. De manière avantageuse, les moyens de mise à jour dudit espace d'adressage comprennent en outre, en cas de vérification négative, des moyens de forcer le noeud auquel l'adresse donnée est allouée à obtenir une nouvelle adresse auprès dudit au moins un serveur d'adresses activé. 30 En outre, les moyens d'activation d'au moins un serveur d'adresses du premier sous-réseau comprennent : 20 - des moyens de détection s'il reste au moins un tunnel ouvert sur la première tête de tunnel (101) ; - des moyens, activés s'il reste au moins un tunnel ouvert entre la première tête de tunnel et une troisième tête de tunnel du premier sous-réseau, de collaboration avec la troisième tête de tunnel afin d'activer au moins un serveur d'adresses du premier sous-réseau ; - des moyens, activés s'il ne reste aucun tunnel ouvert sur la première tête de tunnel, de réactivation d'un ou des serveur(s) d'adresses présent(s) sur le premier sous-réseau et qui a (ont) été désactivé(s) préalablement à l'ouverture du tunnel entre la première tête de tunnel et la seconde tête de tunnel. De manière intéressante, la première tête de tunnel comprend des moyens de désactivation du ou des serveurs d'adresses présents sur le premier sous-réseau, préalablement à l'ouverture du tunnel, Egalement, la première tête de tunnel comprend des moyens de collaboration avec la seconde tête de tunnel afin d'activer au moins un serveur d'adresses du second sous-réseau pour l'ensemble constitué des premier et second sous-réseaux, préalablement à l'ouverture du tunnel. Avantageusement, la première tête de tunnel comprend : des moyens d'obtention des informations correspondant à un espace d'adressage courant, préalablement à l'ouverture du tunnel, l'espace d'adressage courant étant associé audit ou auxdits serveur(s) d'adresses présent sur le premier sous-réseau et désactivé(s) ; des moyens d'utilisation de ces informations pour mettre à jour ledit au moins un serveur d'adresses du second sous-réseau.

Selon une caractéristique particulière, la première tête de tunnel comprend des moyens de réception entre l'ouverture et la fermeture du tunnel, en provenance de la seconde tête de tunnel, de mises à jour effectuées sur l'espace d'adressage associé audit serveur d'adresses du second sous-réseau activé. En outre, les moyens de détermination, à la fermeture du tunnel, d'un ensemble de noeuds du premier sous-réseau prennent en compte les mises à jour reçues entre l'ouverture et la fermeture du tunnel.

Selon une autre caractéristique particulière, ledit serveur d'adresses du second sous-réseau activé comprend des moyens de réception d'au moins une requête d'allocation ou de libération d'adresse en provenance d'un équipement appartenant à l'ensemble constitué du premier sous-réseau et du second sous-réseau. 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) mettant en oeuvre un tunnel selon un mode de réalisation particulier de l'invention ; - 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 de l'invention ; - 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 un traitement des requêtes (d'allocation ou de libération) d'adresse sur un serveur d'adresses d'une tête de tunnel, selon un mode de réalisation particulier de l'invention ; la figure 5 illustre schématiquement les différentes étapes effectuées lors de l'ouverture d'un tunnel, selon un mode de réalisation particulier de l'invention ; - la figure 6 illustre schématiquement les étapes de traitement des requêtes (d'allocation ou de libération) d'adresse entre serveurs, selon un mode de réalisation particulier de l'invention ; la figure 7 illustre schématiquement les différentes étapes effectuées lors de la fermeture d'un tunnel, selon un mode de réalisation particulier de l'invention ; la figure 8 illustre schématiquement les différentes étapes pour la restauration de la cohérence d'un espace d'adressage, selon un mode de réalisation particulier de l'invention ; la figure 9 illustre schématiquement les différents types de données utilisées selon un mode de réalisation particulier de l'invention ; la figure 10 illustre schématiquement une tête de tunnel mettant en oeuvre l'invention selon un mode de réalisation particulier. 6. DESCRIPTION DÉTAILLÉE La figure 1 illustre, selon un mode de réalisation particulier de l'invention , une configuration classique d'un réseau privé virtuel (VPN) mettant en oeuvre un tunnel 100 entre une tête de tunnel locale 101 d'un réseau LAN 103 et une tête de tunnel 102 d'un réseau LAN 104, à travers un réseau fédérateur 107 (Internet par exemple). Chacun des réseaux LAN 103 et 104 comprend 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. Il est à noter qu'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 réseau LAN 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au réseau LAN 104. Par exemple, le client local 108 connecté au réseau LAN 103 peut communiquer avec le serveur local 113 connecté au réseau LAN 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 réseau LAN à plusieurs autres réseaux LAN distincts. 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. Pour la mise en oeuvre de l'invention, chacune des deux têtes de tunnel 101 et 102 contient un serveur d'adresses réseau respectivement 114 et 115 implémentant chacun l'invention.

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 réseau LAN 103, et entrant dans le tunnel 100. Pour ce faire, on utilise un modèle en couche 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écessaires 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 (pour Universal Plug and Play en englais) lorsqu'une tête de tunnel 101 est intégrée dans un équipement UPnP. La 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 (ou socket en anglais) 201 à un protocole de transport fiable TCP 203 (pour Transmission Control Protocol en anglais ou protocole de contrôle de transmissions en français) ou non fiable UDP 205 (pour User Datagram Protocol en anglais ou protocole de datagramme utilisateur en français), respectivement sécurisés par les protocoles SSL 202 (pour Secure Sockets Layers en anglais ou couche d'interface applicative sécurisée en français) et DTLS 204 (pour Datagram Transport Layer Security en anglais ou sécurisation des échanges en mode datagramme en français). Après traitement par un protocole de transport pour former le paquet tunnel 250, on passe celui-ci à la couche réseau 206. Le datagramme IP ainsi formé avec le paquet tunnel peut maintenant être transmis sur le 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 classique d'une trame Ethernet (référencée 260), transitant par exemple sur le réseau LAN 103 de la figure 1 entre la 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 de niveau 2 (référencé 250), et un champ FCS ( Frame Check Sequence , ou séquence de contrôle de trame ). 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), et enfin 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 suite de la description se place dans le cas de l'établissement d'un tunnel 100 de communication, sur un réseau fédérateur 107 (figure 1), entre une première tête de tunnel 101 d'un premier réseau 103 (encore appelé premier sous-réseau 103) et une seconde tête de tunnel 102 d'un second sous-réseau 104 (encore appelé second sous- réseau 104). En outre, la première tête de tunnel 101 et la seconde tête de tunnel 102 comprennent respectivement un premier serveur d'adresses 114 et un second serveur d'adresses 115. La figure 4 illustre schématiquement, selon un mode de réalisation particulier de l'invention, l'algorithme appliqué lors de la réception par le premier serveur d'adresses 114 ou le second serveur d'adresses 115 (implémentant tous les deux l'invention) d'une requête relative à la gestion des adresses du réseau. Les requêtes reçues par les premier et second serveurs d'adresses 114 ou 115, sont les requêtes standard de gestion d'adresses envoyées par un client standard .

Par exemple, dans le cas de gestion d'adresses grâce au protocole DHCP, le serveur est adapté à recevoir des requêtes DHCP telles que décrites dans les documents IETF RFC2131 (DHCP) et RFC3203 ( DHCP reconfigure extension ). Selon un mode de réalisation particulier de l'invention, un serveur d'adresses (114 ou 115) implémentant l'invention, comporte un état supplémentaire en comparaison aux serveurs d'adresses décrits dans les normes RFC précitées. En effet, ces serveurs d'adresses implémentent en plus des deux états de l'état de l'art classiques (actif et inactif), un nouvel état, dit de veille dans lequel le premier serveur d'adresses 114 ou le second serveur d'adresses 115 retransmet vers un autre serveur d'adresses, qui est dans l'état actif et compris dans une autre tête de tunnel, chaque requête de gestion d'adresse reçue. Dans le cas d'un protocole DHCP, les requêtes du protocole d'adresse DHCP normales qu'il reçoit sont ainsi ignorées. Dans cet état de veille, le premier serveur d'adresses 114 ou le second serveur d'adresses 115 est capable de recevoir des messages d'informations 61 plus amplement décrits par la suite en relation avec la figure 9, ces messages d'informations 61 étant transmis par un autre serveur implémentant l'invention afin de lui permettre de mettre à jour ses tables internes de gestion des adresses allouées sur le réseau. Il est à noter que l'état actif de l'invention diffère de l'état actif classique de l'état de l'art en ce qu'en plus de répondre de manière classique à chaque requête de gestion d'adresse reçue, l'état actif selon un mode de réalisation particulier de l'invention permet de transmettre vers au moins un autre serveur d'adresses, qui est dans l'état de veille précité et compris dans une autre tête de tunnel, au moins un message d'informations 61 pour chaque requête de gestion d'adresses reçue. Dans une première étape 21, l'état courant d'un serveur d'adresses, par exemple le premier serveur d'adresses 114, est déterminé suite à la réception d'une requête relative à la gestion des adresses du réseau. Si le premier serveur d'adresses 114 est en mode actif (selon l'invention), ce dernier traite de manière classique la requête et y répond tel un serveur d'adresses de l'état de l'art (étapes 22 et 23). Une étape 24 est ensuite exécutée (plus amplement décrite par la suite).

Si le premier serveur d'adresses 114 est dans l'état de veille, la requête de gestion d'adresses est ignorée et est simplement transmise lors d'une étape 25 au serveur actif présent sur le réseau. Cette transmission est réalisée par examen d'une table 60 de la figure 9 (plus amplement décrite par la suite) afin de déterminer sur quel tunnel envoyer la requête de gestion d'adresses.

Lors de l'étape 22, le traitement de la requête est identique à celui exécuté par les serveurs d'adresses de l'état de l'art (tel que décrit dans la RFC2131 par exemple) afin de déterminer le contenu de la trame à générer à destination du client à l'origine de la requête. Ensuite, dans une étape 23, le premier serveur d'adresses 114 envoie au client la trame générée lors de l'étape 22. Puis une étape 24 est exécutée. Lors de cette étape 24, les informations d'affectations ou de libérations d'adresses vont être diffusées aux serveurs d'adresses dans l'état de veille (ou mode veille). Selon un mode de réalisation particulier de l'invention, lors de cette étape 24 est généré un message 61 de type information avec comme message la trame générée à l'étape 22 dans le cas d'une allocation, et la requête originale dans le cas d'une libération. Ce message d'informations 61 contient notamment toutes les informations nécessaires à un serveur d'adresses dans l'état de veille afin de mettre à jour une table 62 d'adresses 62 (figure 9) renseignant des adresses affectées ou libérées sur le réseau.

La figure 5 illustre schématiquement, selon un mode de réalisation particulier de l'invention, les étapes nécessaires à la mise en oeuvre de l'invention lors de l'ouverture d'un tunnel par une première tête de tunnel 101. L'invention propose de faire en sorte qu'il n'y ait qu'un unique serveur d'adresses actif sur le réseau (constitué de l'interconnexion des différents réseaux LAN reliés par les tunnels). Cet unique serveur d'adresses actif est de préférence le serveur d'adresses embarqué dans la tête de tunnel, et implémentant l'invention. Le fait de s'assurer qu'un seul serveur d'adresses reste actif garantit notamment le bon fonctionnement du système d'affectation dynamique d'adresses, en évitant les conflits d'adresses dont les résultats sont imprévisibles et généralement néfastes au bon fonctionnement du réseau. Pour garantir l'unicité du serveur d'adresses actif, la tête de tunnel à l'origine de la requête d'établissement du tunnel (rôle de client), par exemple la première tête de tunnel 101, va piloter le processus de sélection de l'unique serveur d'adresses actif.

Dans l'état de la technique, lors d'une ouverture d'un tunnel de communications, le protocole classique d'ouverture d'un tunnel commence par une demande de connexion du client. Puis une phase de négociation s'engage entre les deux têtes de tunnel afin de déterminer le protocole, et le degré de sécurité par exemple. Lors de cette phase de négociation, pour la mise en oeuvre de l'invention, est ajoutée une information de l'état du serveur d'adresses intégré à chaque tête de tunnel. Cette information échangée entre les têtes de tunnel va permettre notamment de sélectionner efficacement un serveur unique d'adresses actif. L'algorithme de détermination de l'unique serveur d'adresses actif commence par une étape 40 consistant à déterminer l'état du premier serveur d'adresses 114 intégré à la première tête de tunnel 101 (encore appelée tête de tunnel locale), pour un tunnel établi entre la première tête de tunnel 101 du premier réseau de communication 103 et la seconde tête de tunnel 102 du second réseau de communication 104. Si l'étape 40 détermine que le premier serveur d'adresses 114 est inactif, cela signifie qu'aucun tunnel n'est encore ouvert, et il va falloir configurer les éventuels 30 serveurs présents sur le premier réseau 103 avant d'autoriser les trames de niveau 2 à traverser le tunnel. En effet, ces trames peuvent véhiculer des trames du protocole de gestion dynamique des adresses réseau. Une étape 42 suivante permet de déterminer la liste des serveurs d'adresses actifs sur le premier réseau 103. Cette étape peut aisément être réalisée en envoyant un message de découverte des serveurs d'adresses du premier réseau 103. Dans le cas du protocole DHCP, cela consiste à envoyer une trame de type DHCP_DISCOVER puis à enregistrer toutes les réponses suite à une requête de type DHCP_OFFER . Une fois la liste des serveurs actifs établie, une étape 43b permet de désactiver ces serveurs d'adresses actifs grâce aux propriétés des équipements intégrant des serveurs d'adresses dynamiques. En particulier, les équipements comme les passerelles (105 par exemple) intègrent non seulement des pare-feux, mais aussi un routeur, et un serveur d'adresses dynamique. Ces passerelles personnelles doivent se conformer aux recommandations du DSL forum, et en particulier la recommandation TR124 ( Functional Requirements for Broadband Residential Gateway Devices , December 2006, DSLHome-Technical Working Group, et plus particulièrement la section LAN.DHCPS) qui stipule que les serveurs d'adresses embarqués dans ces équipements doivent supporter des demandes de désactivation (par le biais de la commande SetDHCPServerEnable ). Notamment, ces équipements embarquent une passerelle Internet (ou IGD pour Internet Gateway Device en anglais) qui supporte un protocole d'interface public normalisé utilisable pour en piloter le fonctionnement, et en particulier pour activer ou désactiver son serveur d'adresses interne. L'étape 43b permet donc d'envoyer une requête de désactivation du serveur d'adresses de chaque serveur d'adresses actif trouvé lors de l'exécution de l'étape 42. Préalablement à cette étape 43b, une étape 43a, permet, en utilisant des mécanismes décrits dans la recommandation du DSL forum TR064 ( LAN-Side DSL CPE Configuration , May 2004, DSLHome-Technical Working Group, et plus particulièrement la section 6.6 LAN Device ), de déterminer les plages d'adresses gérées par les différents serveurs à désactiver. En effet, la recommandation TR064 définit une interface permettant d'interroger le serveur DHCP afin d'obtenir ses plages d'adresses, ainsi que les adresses marquées comme déjà réservées (en utilisant respectivement les actions GetAddressRange et GetReservedAddresses").

L'utilisation des ces commandes sur l'ensemble des serveurs déterminés à l'étape 42 permet ainsi de déterminer les plages d'adresses que le serveur DHCP local doit gérer, ainsi que les adresses déjà allouées (pour éviter une double allocation nuisible). Après avoir désactivé l'ensemble des serveurs d'adresses actifs du premier réseau 103, une étape 44 suivante permet de déterminer l'état du second serveur d'adresses 115 (encore appelé serveur distant 115) de la seconde tête de tunnel 102 (information reçue lors de la phase de négociation de l'ouverture du tunnel). Si le second serveur d'adresses 115 est inactif, la seconde tête de tunnel 102 n'a aucun tunnel actuellement ouvert. Dans ce cas, une mode de réalisation particulier de l'invention propose de choisir arbitrairement (étape 46) le premier serveur d'adresses 114 comme serveur actif. Une étape 47 suivante permet de modifier l'état du second serveur d'adresses 115 afin de faire passer celui-ci à l'état dit de veille grâce à une requête 61 de passage en veille, cette requête 61 étant générée par la première tête de tunnel 101 puis envoyée à la seconde tête de tunnel 102. Si l'étape 44 a déterminé que le second serveur d'adresses 115 est en état actif ou en état de veille, une étape 45 est exécutée afin de modifier l'état du premier serveur d'adresses 114 pour le passer en mode veille. Si l'étape 40 a déterminé que l'état du premier serveur d'adresses 114 est actif, le premier serveur d'adresses 114 va tenter de rester actif. Pour cela, une étape 41 évalue l'état du second serveur d'adresses 115. Si le second serveur d'adresses 115 est inactif, une étape 48 est exécutée afin de faire passer l'état du second serveur d'adresses 115 à l'état de veille grâce à la génération, par la première tête de tunnel 101, d'une requête 61 de passage en veille envoyée à la seconde tête de tunnel 102. Si par contre l'étape 41 a déterminé que le second serveur d'adresses 115 est dans l'état de veille, ou encore actif, cela signifie que la seconde tête de tunnel 102 à déjà établi un tunnel avec une ou plusieurs autres tête de tunnel. En conséquence, pour des raisons de simplicité, la première tête de tunnel 101 passe son premier serveur d'adresses 114 à l'état de veille (étape 45) car il existe déjà un serveur actif quelque part sur le second réseau 104.

Si l'étape 40 a déterminé que l'état du premier serveur d'adresses 114 est à l'état de veille, cela signifie que la première tête de tunnel 101 a déjà établi un tunnel vers une autre tête de tunnel, sur lequel se trouve connecté le serveur actif. Dans ces conditions, la première tête de tunnel 101 va demander à la tête de tunnel avec laquelle elle tente d'établir un nouveau tunnel de désactiver le serveur d'adresses actif de son réseau (s'il existe) ainsi que de passer à l'état de veille. Pour cela, l'étape 48 est de nouveau exécutée. A la réception de la requête 61 de passage en veille générée lors de l'étape 48, le second serveur d'adresses 115 va passer en veille, et suivant son état va éventuellement demander la désactivation du serveur actif situé quelque part sur son second réseau 104 (étapes 32 à 36 de la figure 6). Enfin, suite aux étapes 45, 47 ou 48, une étape 49 permet de mettre à jour la table des tunnels actifs 60 (figure 9) en ajoutant une ligne pour le nouveau tunnel ouvert, et en indiquant, si le serveur d'adresses actif se trouve connecté à l'autre bout du tunnel (champ 603 de la table 60).

La figure 6 illustre schématiquement, selon un mode de réalisation particulier de l'invention, les étapes réalisées par un serveur d'adresses (implémentant l'invention) lors de la réception d'un message 61 d'informations ou de passage veille généré par un autre serveur d'adresses (implémentant l'invention également). Une première étape 31 permet de déterminer, par examen du champ 611 de la trame du message 61, s'il s'agit d'une trame d'informations ou pas. Si c'est le cas, une étape 37 examine le contenu de la trame d'informations reçue puis met à jour la table des adresses 62 de la figure 9. Si le champ 613 de la trame 61 reçue contient une affectation d'adresse, l'étape 37 ajoute une ligne à la table des adresses 62, en insérant la trame reçue dans le champ 624. Si au contraire, il s'agit d'une libération d'adresse, la ligne correspondante de la table 62 est effacée si elle existe (cas de libération d'une adresse affectée durant la vie du tunnel). Si l'adresse n'existait pas, cela signifie qu'il s'agit d'une libération d'adresse qui avait été affectée avant l'ouverture du tunnel. Dans ce cas, l'étape 37 ajoute une ligne à la table des adresses 62, en insérant la trame reçue dans le champ 624.

Après analyse de la trame du message 61 d'informations, dans une étape 38, celui-ci est transféré sans aucune modification à l'ensemble des têtes de tunnel mis à part celle d'où provient le message. Cette étape 38 détermine, par examen du champ 602 de la table 60, la liste des têtes tunnel à qui retransmettre le message 61 d'informations (c'est-à-dire l'ensemble des éléments de la liste excepté la tête de tunnel à l'origine du message). S'il ne s'agit pas d'une trame d'informations dans l'étape 31, il s'agit donc d'une trame de demande de passage en état de veille du serveur d'adresses courant (par exemple le second serveur d'adresses 115).

Une étape 32 suivante permet d'évaluer l'état du serveur d'adresses courant (le second serveur d'adresses 115 dans l'exemple de l'invention). Suivant l'état du serveur d'adresses courant (inactif, actif, ou veille), le traitement diffère. Ainsi, si le serveur d'adresses courant est dans l'état actif, ce dernier passe directement à l'état veille dans une étape 35 consistant à modifier la variable d'état interne du serveur d'adresses courant. Si le serveur d'adresses courant est dans l'état inactif, la tête de tunnel courante (ou encore la seconde tête de tunnel 102 dans notre exemple) n'a aucun tunnel d'établi, et il faut, préalablement à l'ouverture du tunnel, désactiver l'ensemble des serveurs d'adresses du réseau LAN local de la tête de tunnel courante (c'est-à-dire le second réseau 104 dans notre exemple) dans une étape 34b plus amplement décrite par la suite. Préalablement à cette étape 34b de désactivation, une étape 33 permet de déterminer la liste des serveurs d'adresses actifs sur le réseau LAN local de la tête de tunnel courante. Cette étape peut aisément être réalisée en envoyant un message de découverte des serveurs situés sur le réseau LAN local de la tête de tunnel courante.Dans le cas du protocole DHCP, cette trame équivaut à envoyer une trame de type DHCP_DISCOVER puis à enregistrer toutes les réponses suite à une requête de type DHCP_OFFER . Puis, une étape 34a, permet, en utilisant des mécanismes décrits dans la recommandation du DSL forum TR064 ( LAN-Side DSL CPE Configuration , May 2004, DSLHome-Technical Working Group, et plus particulièrement la section 6.6 LAN Device ), de déterminer les plages d'adresses gérées par les différents serveurs à désactiver. Cette étape est identique à celle décrite à l'étape 43a. Une fois la liste des serveurs d'adresses actifs établie, l'étape 34b va désactiver ces serveurs d'adresses actifs. Pour cela, elle envoie une requête de désactivation aux serveurs d'adresses actifs trouvés lors de l'exécution de l'étape 33. Cette étape 34b est identique à celle décrite à l'étape 43b. Puis le serveur d'adresses courant local passe à l'état veille par exécution de l'étape 35 précédemment décrite. Enfin, si l'étape 32 détermine que le serveur d'adresses courant local est dans un état de veille, cela signifie qu'au moins un autre tunnel est déjà établi, et que l'un des tunnels établis mène à un réseau LAN possédant un serveur actif. Dans ce cas, dans une étape 36, la requête de passage en veille est envoyée au réseau LAN possédant le serveur actif afin de le faire passer en mode veille. Cette étape 36 détermine, grâce au champ 603 de la table des tunnels 60, vers quelle tête de tunnel retransmettre la requête 61 de passage en veille. La requête est ainsi retransmise de proche en proche jusqu'à la tête de tunnel possédant un serveur d'adresses actif. A réception de la requête, le serveur d'adresses actif détecté passe à l'état de veille. La figure 7 illustre schématiquement les différentes étapes réalisées par un serveur d'adresses (par exemple les premier et second serveurs d'adresses 114 ou 115) mettant en oeuvre l'invention lors de la fermeture d'un tunnel (par exemple le tunnel 100 de la figure 1). A la fermeture d'un tunnel, le but est de garantir la cohérence de l'espace d'adressage du réseau résultant de la déconnection d'un des réseaux LAN le constituant. En particulier, il faut garantir la présence d'un serveur actif sur le réseau, ainsi que de garantir que l'espace d'adressage dont il dispose reflète la réalité des équipements connectés au réseau. De même, il faut que les équipements, dont la configuration réseau est devenue fausse suite au changement de topologie engendrée par la fermeture du tunnel, puisse récupérer une nouvelle configuration réseau. Une première étape 51 permet de déterminer l'ensemble des équipements nécessaires de supprimer de la table des adresses 62 suite à la fermeture du tunnel, puis en informe les autres têtes de tunnel. Pour cela, l'étape 51 analyse la table 62 des adresses, et détermine l'ensemble des adresses dont l'identifiant de tunnel (champ 623 de la table 62) correspond à l'identifiant de tunnel du tunnel qui vient de se fermer. Puis pour chacune des adresses, l'étape 51 génère un message 61 d'informations à destination des serveurs d'adresses distants pour leur indiquer la libération de l'adresse (dans le cas de l'utilisation de DHCP, le message 613 de la trame 61 correspond à une trame de type DHCP_RELEASE ). Cette trame indiquera au serveur quel que soit son état (veille ou actif) qu'il doit supprimer l'adresse indiquée dans la trame de sa base 62 des adresses. Une fois ces messages envoyés à l'ensemble des têtes de tunnel distantes (qui se chargeront éventuellement de propager l'information à leurs propres têtes de tunnel distantes tel que décrit dans l'étape 38 de la figure 6), une étape 52 met à jour la table 62 des adresses en supprimant les adresses dont l'identifiant de tunnel correspond au tunnel qui vient de se fermer. Puis une étape 53 permet de mettre à jour la table 60 des tunnels actifs, en supprimant la ligne correspondant au tunnel fermé. Après la gestion de la disparition d'équipements réseau suite à la fermeture d'un tunnel, une étape 54 permet de déterminer s'il reste encore des tunnels actifs sur la tête de tunnel courante. Cette étape consiste à examiner la table des tunnels 60. S'il ne reste pas de tunnels actifs sur la tête de tunnel courante (étape 54 négative), tous les tunnels sont à présent fermés, et la tête de tunnel courante va devoir remettre le réseau dans un état cohérent et proche de l'état initial (avant l'ouverture du premier tunnel). Pour cela, une étape 55 décrite en détail dans la figure 8 est exécutée. Puis, dans une étape 56, le serveur d'adresses intégré à la tête de tunnel courante retourne à l'état inactif. S'il reste des tunnels actifs sur la tête de tunnel courante (étape 54 positive), une étape 57 permet de vérifier, en fonction l'état du serveur d'adresses courant (c'est-à-dire soit actif soit en veille) de la tête de tunnel courante, qu'il reste bien un serveur d'adresses actif (en effet, le serveur actif était peut être sur une partie du réseau accessible via le tunnel en cours de fermeture). Si l'état du serveur d'adresses courant est à l'état actif, l'algorithme se termine.

Si l'état du serveur d'adresses courant est à l'état de veille, une étape 58 permet de vérifier si l'un des tunnels encore ouvert possède un serveur d'adresses actif. Pour cela, l'étape 58 examine le champ 603 de la table 60 à la recherche d'un tunnel dont le serveur d'adresses est actif. Si c'est la cas (étape 58 positive), cela signifie qu'il existe un serveur d'adresses actif sur le réseau résultant de la fermeture du tunnel, et l'algorithme s'arête.

Si ce n'est pas le cas (étape 58 négative), le serveur d'adresses courant doit passer à l'état actif. Une étape 59 réalise cette opération en modifiant la variable d'état interne au serveur de la tête de tunnel courante. La figure 8 décrit en détail l'étape 55 de gestion d'un espace d'adressage d'un réseau (ou sous-réseau) de la figure 7.

Lors de la fermeture du dernier tunnel ouvert par une tête de tunnel, par exemple la première tête de tunnel 101, la présente invention permet avantageusement de remettre son réseau local dans un état permettant son fonctionnement normal immédiat. Une première étape 551 permet de déterminer la liste des serveurs d'adresses qui ont été arrêtés lors de l'ouverture du tunnel (étapes 42, 43a et 43b de la figure 5), par exemple le tunnel 100 de la figure 1. Si la liste déterminée à l'étape 551 n'est pas vide, une étape 552 utilise des mécanismes similaires à ceux employés lors de l'étape 43b pour activer les serveurs d'adresses de la dite liste (par exemple en employant le protocole IGD de la passerelle). Si ce n'est pas le cas, une étape 553 est directement exécutée.

Après réactivation des serveurs, ceux-ci doivent être configurés de façon à ce que l'espace d'adressage associé reflète la réalité des adresses affectées ou libérées durant la période ou un tunnel était ouvert. L'étape 553 sélectionne une à une chaque adresse de la table 62. Pour chaque adresse sélectionnée, une étape 554 suivante de libération ou 25 d'allocation d'adresse est exécutée. L'étape 554 détermine par examen du champ 624 de la trame 62 stockée, s'il s'agit d'une adresse allouée ou libérée durant la vie du tunnel. L'analyse des trames est notamment rendu possible car il s'agit de tunnels de niveau 2 où l'ensemble des trames Ethernet sont propagées sur l'ensemble du réseau. 30 Dans le cas où il s'agit d'une adresse allouée, celle ci doit être ajoutée à un et un seul des serveurs d'adresses activé à l'étape 552. Pour cela, une étape 5591 sélectionne un serveur actif de la liste déterminée à l'étape 551 (par défaut, le premier de la liste, puis les suivants un à un jusqu'au dernier), ledit serveur sera par la suite désigné comme serveur actif courant. L'étape 5592 détermine si le serveur actif courant est valide (c'est à dire si l'étape 5591 a sélectionné un serveur actif ou non (c'est le cas lorsque la liste est vide, ou lorsque l'étape 555 a été appliquée à tous les serveurs actifs de la liste)). Dans le cas où l'étape 5592 est positive, une étape 555 permet d'ajouter l'adresse (à allouer) au serveur d'adresses actif courant. Lors de cette étape 555, la première tête de tunnel 114 génère une trame indiquant au serveur d'adresses actif courant qu'un équipement possède une adresse. Dans le cas du protocole DHCP, ceci peut être réalisé par l'utilisation d'une trame DHCP_INFORM . En réponse à cette requête, le serveur d'adresses actif courant va envoyer un acquittement contenant une configuration réseau correcte ( DHCP_ACK par exemple), ou un non acquittement ( DHCP_NACK par exemple ) dans le cas où l'adresse donnée par l'équipement est incompatible avec l'espace d'adressage connu du serveur actif courant.

Ensuite, une étape 556 permet la mise en attente de la réponse du serveur actif courant afin de déterminer si l'adresse est acceptée ou non par ce serveur, c'est-à-dire si la configuration réseau retournée par le serveur actif courant est compatible avec celle stockée dans le champ 624 de la table 62 pour l'adresse courante. Si ce n'est pas le cas, c'est-à-dire si l'adresse n'est pas acceptée par le serveur actif courant, ou bien si la configuration réseau est incompatible, alors l'étape 5592 est à nouveau effectuée pour sélectionner un nouveau serveur actif courant correspondant à l'élément suivant de la liste déterminée à l'étape 551. Si l'étape 5592 est négative, cela signifie que l'on n'a pas trouvé de serveur actif acceptant l'adresse courante, et une étape 557 est exécutée Lors de l'étape 557, l'équipement dont la configuration réseau est erronée est forcé à redemander une nouvelle configuration réseau aux serveurs activés à l'étape 552 Dans le cas de l'utilisation du protocole DHCP, cette opération peut être réalisée par l'envoie d'une requête DHCP_FORCERENEW . A réception de cette trame, l'équipement va retourner dans un mode de renouvellement d'adresse, qui va déboucher sur l'affectation d'une nouvelle configuration réseau complète par l'un des serveurs d'adresses du réseau LAN local. Après envoi de cette trame forçant le renouvellement de l'adresse, une adresse suivante sélectionnée lors de l'étape 553 est à son tour analysée. Si c'est le cas lors de l'étape 556, une adresse suivante sélectionnée lors de l'étape 553 est à son tour analysée.

Dans le cas où il s'agit d'une adresse libérée durant la vie du tunnel (étape 554), une étape 558 est exécutée. Lors de cette étape 558, la première tête de tunnel 101 indique aux serveurs d'adresses activés à l'étape 552 qu'un équipement libère une adresse. Pour cela, la première tête de tunnel 101 émet à destination du serveur d'adresses activé à l'étape 552 la trame d'origine 624 stockée dans la table 62, en modifiant simplement l'adresse destination de cette trame (la destination est maintenant le serveur d'adresses activé à l'étape 552). Lorsque toutes les adresses ont été traitées lors de l'étape 554, l'algorithme s'arrête. La figure 9 décrit les structures de données nécessaires à la mise en oeuvre de 15 l'invention (tables 60 et 62), ainsi que la structure de la trame du message 61 d'informations échangé entre les serveurs d'adresses. La table 60 contient la liste des tunnels actifs (en cours d'ouverture, ouverts ou en cours de fermeture). Un champ 601 contient un identifiant unique affecté lors de la demande de connexion. Un champ 602 contient l'adresse MAC de la tête de tunnel 20 distante. Un champ 603 contient un booléen indiquant s'il existe un serveur d'adresses actif sur la partie du réseau à l'autre bout du tunnel (sur la tête de tunnel elle-même, ou sur des têtes connectées via des tunnels à la tête de tunnel distante). La table 62 contient la liste des adresses affectées à un équipement connecté au réseau constitué de l'interconnexion des différents réseaux LAN via les tunnels. Un 25 champ 621 contient l'adresse IP affecté à un équipement. Un champ 622 contient l'adresse MAC de l'équipement. Un champ 623 contient l'identifiant (ID) unique (correspondant au champ 601 de la table 60) du tunnel permettant d'accéder à l'équipement auquel a été affecté l'adresse IP. Un dernier champ 624 contient la trame émise par un serveur en réponse à la requête d'un client à l'origine de l'affectation de 30 l'adresse IP. Dans le cas de l'utilisation du protocole DHCP, il s'agit d'une requête de type DHCP_ACK (réponse du serveur contenant toutes les informations réseau y compris l'adresse IP, mais aussi, le masque de réseau, l'adresse de la passerelle par défaut, l'adresse du serveur DNS, etc.). La table 61 décrit une structure de la trame du message utilisé par les serveurs d'adresses implémentant l'invention pour communiquer avec les autres serveurs 5 implémentant l'invention. Un champ 611 est un octet indiquant le type de trame (trame d'informations Info ou trame de veille Veille ). Les trames du message 61 d'informations contiennent des informations permettant de propager l'information de l'affectation ou de libération d'une adresse 10 réseau. Un champ 612 contient l'adresse MAC du serveur à l'origine de la requête (ce champ n'est pas modifié en cas de retransmission de la trame vers d'autres têtes de tunnels). Un champ 613 contient la requête originale. Par exemple, dans le cas du 15 protocole DHCP, ce champ contient la trame DHCP_ACK, ou DHCP_RELEASE à l'origine de l'affectation ou de la libération de l'adresse courante. La figure 10 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 20 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 25 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) ; 30 - 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 réseau LAN 103 ou le second réseau LAN 104 et le réseau fédérateur 107 de type l'Internet, l'interface étant adaptée à transmettre et à recevoir des données avec ces réseaux. Le dispositif générique 1000 comprend optionnellement : - un écran 1008 permettant de visualiser des données et/ou de servir d'interface 10 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é 15 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 20 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é de gestion d'espace d'adressage de l'ouverture à la fermeture d'un tunnel, peut être stocké, par exemple, dans le disque dur 1012 ou dans la mémoire morte 1004. 25 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 30 registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre du procédé de restauration d'un espace d'adressage IP cohérent à la fermeture d'un RPV de niveau 2 du 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 à la fermeture d'un tunnel (100) de communication entre une première tête de tunnel (101) d'un premier sous-réseau (103) et une seconde tête de tunnel (102) d'un second sous-réseau (104), caractérisé en ce que la première tête de tunnel (101) effectue des étapes consistant à : - déterminer un ensemble de noeuds du premier sous-réseau : * dont les adresses ont été allouées par un serveur d'adresses du second sous-réseau, ou * dont les adresses ont été, préalablement à l'ouverture du tunnel, allouées par un serveur d'adresses du premier sous-réseau et libérées par un serveur d'adresses du second sous-réseau ; - activer (552) au moins un serveur d'adresses du premier sous-réseau, un espace d'adressage étant associé audit au moins un serveur ; - mettre à jour (553-558) ledit espace d'adressage en fonction des adresses des noeuds dudit ensemble de noeuds obtenu.
2. Procédé de gestion d'espaces d'adressage selon la revendication 1, caractérisé en ce que l'étape consistant à mettre à jour l'espace d'adressage comprend des étapes consistant à, pour au moins une adresse donnée dudit ensemble de noeuds obtenus : - vérifier que ladite adresse donnée est comprise dans ledit espace d'adressage ; - en cas de vérification positive, allouer l'adresse donnée auprès dudit au moins un serveur d'adresses activé.
3. Procédé de gestion d'espaces d'adressage selon la revendication 2, caractérisé en ce que, l'étape consistant à mettre à jour l'espace d'adressage comprend en outre une étape consistant à, en cas de vérification négative, forcer le noeud auquel l'adresse donnée est allouée à obtenir une nouvelle adresse auprès dudit au moins un serveur d'adresses activé.
4. Procédé de gestion d'espaces d'adressage selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape consistant à activer (552) au moins un 30 serveur d'adresses du premier sous-réseau comprend des étapes consistant à :- détecter s'il reste au moins un tunnel ouvert (53-54) sur la première tête de tunnel (101) ; - s'il reste au moins un tunnel ouvert (53-54) entre la première tête de tunnel (101) et une troisième tête de tunnel du premier sous-réseau (103), collaborer avec la troisième tête de tunnel afin d'activer au moins un serveur d'adresses du premier sous-réseau ; - s'il ne reste aucun tunnel ouvert sur la première tête de tunnel (101), réactiver (55, 56) un ou des serveur(s) d'adresses présent(s) sur le premier sous-réseau et qui a (ont) été désactivé(s) préalablement à l'ouverture du tunnel entre la première tête de tunnel (101) et la seconde tête de tunnel (102).
5. Procédé de gestion d'espaces d'adressage selon l'une quelconque des revendications 1 à 4, caractérisé en ce que la première tête de tunnel (101) effectue, préalablement à l'ouverture du tunnel, une étape consistant à désactiver (34b, 43b) le ou les serveurs d'adresses présents sur le premier sous-réseau. 15
6. Procédé de gestion d'espaces d'adressage selon la revendication 5, caractérisé en ce que la première tête de tunnel (101) effectue, préalablement à l'ouverture du tunnel, une étape consistant à collaborer avec la seconde tête de tunnel afin d'activer au moins un serveur d'adresses du second sous-réseau pour l'ensemble constitué des premier et second sous-réseaux. 20
7. Procédé de gestion d'espaces d'adressage selon la revendication 6 caractérisé en ce que la première tête de tunnel (101) effectue en outre, préalablement à l'ouverture du tunnel, des étapes consistant à : - obtenir (34a, 43a) des informations correspondant à un espace d'adressage courant, l'espace d'adressage courant étant associé audit ou auxdits serveur(s) d'adresses 25 présent(s) sur le premier sous-réseau et désactivé(s) ; - utiliser ces informations pour mettre à jour ledit au moins un serveur d'adresses du second sous-réseau.
8. Procédé de gestion d'espaces d'adressage selon l'une quelconque des revendications 6 et 7, caractérisé en ce que, entre l'ouverture et la fermeture du tunnel, 30 la première tête de tunnel reçoit en provenance de la seconde tête de tunnel des mises à 10jour effectuées sur l'espace d'adressage associé audit serveur d'adresses du second sous-réseau activé, et en ce que ladite étape consistant à déterminer, à la fermeture du tunnel, un ensemble de noeuds du premier sous-réseau est effectuée en prenant en compte les mises à jour 5 reçues entre l'ouverture et la fermeture du tunnel.
9. Procédé de gestion d'espaces d'adressage selon la revendication 8, caractérisé en ce que les mises à jour sur l'espace d'adressage associé audit serveur d'adresses activé sont effectuées suite à au moins une requête d'allocation ou de libération d'adresse en provenance d'un équipement appartenant à l'ensemble constitué du 10 premier sous-réseau et du second sous-réseau.
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 pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 9, lorsque 15 ledit programme est exécuté sur un ordinateur.
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é de gestion de plans d'adressage selon au moins une des revendications 1 à 9. 20
12. Dispositif de gestion d'espaces d'adressage à la fermeture d'un tunnel (100) de communication entre une première tête de tunnel (101) d'un premier sous-réseau (103) et une seconde tête de tunnel (102) d'un second sous-réseau (104), caractérisé en ce que la première tête de tunnel (101) comprend: - des moyens de détermination d'un ensemble de noeuds du premier sous-réseau : 25 * dont les adresses ont été allouées par un serveur d'adresses du second sous-réseau, ou * dont les adresses ont été, préalablement à l'ouverture du tunnel, allouées par un serveur d'adresses du premier sous-réseau et libérées par un serveur d'adresses du second sous-réseau ; 30 - des moyens d'activation d'au moins un serveur d'adresses du premier sous-réseau, un espace d'adressage étant associé audit au moins un serveur ;- des moyens de mise à jour dudit espace d'adressage en fonction des adresses des noeuds dudit ensemble de noeuds obtenu.
13. Dispositif de gestion d'espaces d'adressage selon la revendication 12, caractérisé en ce que les moyens de mise à jour dudit espace d'adressage comprennent, pour au moins une adresse donnée dudit ensemble de noeuds obtenus : - des moyens de vérification que ladite adresse donnée est comprise dans ledit espace d'adressage; - en cas de vérification positive, des moyens d'allocation de ladite adresse donnée auprès dudit au moins un serveur d'adresses activé.
14. Dispositif de gestion d'espaces d'adressage selon la revendication 13, caractérisé en ce que les moyens de mise à jour dudit espace d'adressage comprennent en outre, en cas de vérification négative, des moyens de forcer le noeud auquel l'adresse donnée est allouée à obtenir une nouvelle adresse auprès dudit au moins un serveur d'adresses activé.
15. Dispositif de gestion d'espaces d'adressage selon l'une quelconque des revendications 12 à 14, caractérisé en ce que les moyens d'activation d'au moins un serveur d'adresses du premier sous-réseau comprennent : - des moyens de détection s'il reste au moins un tunnel ouvert sur la première tête de tunnel (101) ; - des moyens, activés s'il reste au moins un tunnel ouvert entre la première tête de tunnel (101) et une troisième tête de tunnel du premier sous-réseau (103), de collaboration avec la troisième tête de tunnel afin d'activer au moins un serveur d'adresses du premier sous-réseau ; - des moyens, activés s'il ne reste aucun tunnel ouvert sur la première tête de tunnel (101), de réactivation d'un ou des serveur(s) d'adresses présent(s) sur le premier sous-réseau et qui a (ont) été désactivé(s) préalablement à l'ouverture du tunnel entre la première tête de tunnel (101) et la seconde tête de tunnel (102).
16. Dispositf de gestion d'espaces d'adressage selon l'une quelconque des revendications 12 à 15, caractérisé en ce que la première tête de tunnel (101) comprenddes moyens de désactivation du ou des serveurs d'adresses présents sur le premier sous-réseau, préalablement à l'ouverture du tunnel,
17. Dispositif de gestion d'espaces d'adressage selon la revendication 16, caractérisé en ce que la première tête de tunnel (101) comprend des moyens de collaboration avec la seconde tête de tunnel afin d'activer au moins un serveur d'adresses du second sous-réseau pour l'ensemble constitué des premier et second sous-réseaux, préalablement à l'ouverture du tunnel.
18. Dispositif de gestion d'espaces d'adressage selon la revendication 17 caractérisé en ce que la première tête de tunnel (101) comprend : des moyens d'obtention des informations correspondant à un espace d'adressage courant, préalablement à l'ouverture du tunnel, l'espace d'adressage courant étant associé audit ou auxdits serveur(s) d'adresses présent sur le premier sous-réseau et désactivé(s) ; des moyens d'utilisation de ces informations pour mettre à jour ledit au moins 15 un serveur d'adresses du second sous-réseau.
19. Dispositif de gestion d'espaces d'adressage selon l'une quelconque des revendications 17 et 18, caractérisé en ce que la première tête de tunnel comprend des moyens de réception entre l'ouverture et la fermeture du tunnel, en provenance de la seconde tête de tunnel, de mises à jour effectuées sur l'espace d'adressage associé audit 20 serveur d'adresses du second sous-réseau activé, et en ce que les moyens de détermination, à la fermeture du tunnel, d'un ensemble de noeuds du premier sous-réseau prennent en compte les mises à jour reçues entre l'ouverture et la fermeture du tunnel.
20. Dispositif de gestion d'espaces d'adressage selon la revendication 19, 25 caractérisé en ce que ledit serveur d'adresses du second sous-réseau activé comprend des moyens de réception d'au moins une requête d'allocation ou de libération d'adresse en provenance d'un équipement appartenant à l'ensemble constitué du premier sous-réseau et du second sous-réseau.