FR2855697A1 - SYSTEME DE CONVERSION DE DONNEES BASEE SUR IPv4 EN DONNEES BASEES SUR IPv6 A TRANSMETTRE A TRAVERS UN RESEAU COMMUTE IP - Google Patents

SYSTEME DE CONVERSION DE DONNEES BASEE SUR IPv4 EN DONNEES BASEES SUR IPv6 A TRANSMETTRE A TRAVERS UN RESEAU COMMUTE IP Download PDF

Info

Publication number
FR2855697A1
FR2855697A1 FR0306308A FR0306308A FR2855697A1 FR 2855697 A1 FR2855697 A1 FR 2855697A1 FR 0306308 A FR0306308 A FR 0306308A FR 0306308 A FR0306308 A FR 0306308A FR 2855697 A1 FR2855697 A1 FR 2855697A1
Authority
FR
France
Prior art keywords
packet
network
ipv6
protocol
ipv4
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0306308A
Other languages
English (en)
Other versions
FR2855697B1 (fr
Inventor
Jean-Francois Le Pennec
Aurelien Bruno
Claude Galand
Didier Giroir
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
AT&T Corp
Original Assignee
AT&T Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by AT&T Corp filed Critical AT&T Corp
Priority to FR0306308A priority Critical patent/FR2855697B1/fr
Priority to JP2004153034A priority patent/JP2004357292A/ja
Priority to EP04012230A priority patent/EP1482678B1/fr
Priority to DE602004029419T priority patent/DE602004029419D1/de
Priority to KR1020040037368A priority patent/KR20040101933A/ko
Priority to US10/852,945 priority patent/US7369560B2/en
Priority to CA002468480A priority patent/CA2468480C/fr
Publication of FR2855697A1 publication Critical patent/FR2855697A1/fr
Application granted granted Critical
Publication of FR2855697B1 publication Critical patent/FR2855697B1/fr
Priority to US12/101,313 priority patent/US7920589B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272Virtual private networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/50Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/251Translation of Internet protocol [IP] addresses between different IP versions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/2557Translation policies or rules
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/604Address structures or formats
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101Access control lists [ACL]

Abstract

Système de conversion de paquets de données basés sur le protocole IPv4 en paquets de données basés sur le protocole IPv6 à transmettre à travers une infrastructure de réseaux privés virtuels (VPN) dans un système de transmission de données comprenant un réseau commuté IP (25) auquel sont connectées une première station de travail (20) par un premier dispositif de bord (PE 24) et une seconde station de travail (26) par un second dispositif de bord (PE 30), les stations de travail fonctionnant selon le protocole IPv4 alors que le réseau commuté IP fonctionne selon le protocole IPv6. Le système comprend un premier constructeur de paquet (22) entre la première station de travail et le réseau commuté IP pour convertir chaque paquet de données basé sur le protocole IPv4 reçu à partir de la première station de travail dans le protocole IPv6 et réciproquement, et un second constructeur de paquet (28) entre le réseau commuté IP et la seconde station de travail pour convertir chaque paquet de données basé sur le protocole IPv6 reçu à partir du réseau dans le protocole IPv4 et réciproquement.

Description

Domaine technique
L'invention concerne de façon générale la transmission de paquets de données dans un réseau commuté IP tel qu'un réseau par commutation d'étiquettes multiprotocole (MPLS) et concerne en particulier un système de conversion de données basées sur IPv4 en données basées sur IPv6 à transmettre à travers un tel réseau.
Etat de la technique Il y a de plus en plus de réseaux privés virtuels (VPN) qui sont mis en oeuvre pour permettre des communications entre des dispositifs, même si certaines de ces communications sont 15 transmises à travers un réseau public. La plupart des VPN sont construits pour supporter les règles du protocole IP pour la couche 3 et principalement la version IPv4 du protocole IP.
Il existe aujourd'hui un problème avec le protocole IPv4 qui est dû à la limitation bien connue de l'espace adresse dans IPv4, 20 mais aussi un problème soulevé par les règles de transmission IPv4 o les actions de routage sont basées sur l'adresse de destination sans influence due à l'adresse source. Puisque un réseau IPv4 peut être situé n'importe o dans le monde, les routeurs doivent maintenir un enregistrement pour tous les 25 réseaux actifs. Ceci n'est pas seulement vrai pour le réseau Internet, mais aussi pour les réseaux VPN, Intranet et Extranet.
La solution réelle à long terme de ces problèmes est un espace adresse beaucoup plus grand, permettant une structure d'adressage plus importante, des politiques d'allocation moins 30 rigoureuses et un routage plus efficace. Ceci est offert par la version IPv6 qui la rend plus attractive pour l'utilisation de l'infrastructure de réseau. Le support d'un plus grand nombre d'utilisateurs IP et la facilité de gestion sont quelques uns des objectifs de IPv6. Mais comme tous les dispositifs ne sont pas v6, il existe un besoin de mécanismes qui trouvent avantage à l'utilisation de v6. En outre, les utilisations proposées d'en5 têtes IPv6 ne sont pas réellement associées avec la commutation d'étiquettes et la possibilité de supporter des VPN avec des protocoles comme la commutation d'étiquettes multiprotocole (MPLS).
L'utilisation standard de IPv6 basée seulement sur les 10 champs d'adresses IPv6 est même plus complexe que IPv4 si le filtrage de route est utilisé pour fournir les connexions et construire les VPN du fait de la longueur du champ d'adresse sur lequel une recherche doit être effectuée. Un tel filtrage de route peut être mis en oeuvre pour contrôler la propagation de 15 telle façon que certains réseaux obtiennent des routes pour d'autres réseaux à l'intérieur de leur propre communauté d'intérêt (c'est à dire VPN).
Le filtrage de route est basé sur la proposition qu'un sousréseau d'un réseau IP sous-jacent supportant le VPN (tel que le 20 réseau Internet) forme réellement le VPN. Les routes associées à ce sous-réseau sont filtrées de telle sorte qu'elles ne sont pas fournies à d'autres réseaux connectés au sous-réseau formant le VPN. Inversement, aucune autre route non VPN n'est fournie au sous-réseau. Le filtrage de route sur IPv4 implique que les VPN 25 utilisent des espaces d'adresses différents. IPv6 simplifie ce filtrage puisque les VPN sont identifiés dans le champ d'adresse IP mais ouvrent un trou de sécurité.
Pour l'isolation des services sur une couche réseau, le filtrage de route VPN est mis en oeuvre en restreignant la 30 possibilité à un hôte VPN de fournir une réponse aux paquets qui contiennent des adresses source provenant de l'extérieur du VPN.
De telles restrictions sont basées sur des listes de contrôle d'accès (ACL), qui sont des tables informant un dispositif de quels droits d'accès dispose chaque utilisateur. C'est à dire qu'un ACL est une liste d'entrées qui accordent ou refusent des droits d'accès spécifiques à des individus ou des groupes.
Les VPN a filtrage de route présentent cependant un certain nombre de difficultés. Par exemple, un tel arrangement peut être incorrectement configuré de telle sorte qu'il accepte des paquets alors qu'il ne devrait pas, et/ou rejette des paquets qui devraient être acceptés. Un autre problème du filtrage de route 10 est que, lorsqu'il est implémenté après une passerelle ou un pare-feu, le réseau d'abonnés peut définir un routeur extérieur à la passerelle ou au pare-feu comme routeur par défaut, de sorte que les utilisateurs du VPN au-delà de la passerelle ou du parefeu peuvent atteindre des réseaux extérieurs tant qu'ils 15 connaissent l'adresse du routeur par défaut (même s'il n'y a pas d'information). Des imperfections supplémentaires de cette technique comprennent les fautes administratives, une nature statique du modèle et des limitations de la sécurité. En outre, la complexité pour définir et maintenir toutes les règles est 20 très grande de sorte que la technique ne s'ajuste pas très bien ou pas très facilement.
Différentes solutions ont été apportées pour réaliser différents niveaux d'isolation de réseaux lors de la construction de VPN à travers une infrastructure de réseau IP. Beaucoup de ces 25 solutions nécessitent des capacités de transmission séparées pour chaque VPN, et utilisent des tunnels basés sur IP ou MPLS à travers le réseau. De tels tunnels ajoutent de la surcharge et une complexité de gestion, surtout dans les dispositifs d'extrémité du tunnel. Aussi, dans un domaine VPN, un moyen de 30 routage est utilisé pour distribuer les informations d'accessibilité VPN parmi les routeurs. N'importe quel protocole de routage peut être utilisé et aucune modification ou extension non reliée au VPN n'est nécessaire pour le protocole de routage dans le but de réaliser l'accessibilité VPN.
Quelle que soit celle des techniques ci-dessus (ou d'autres techniques) qui est utilisée pour former un VPN, on doit 5 comprendre que la sécurité réseau est un problème. En fait, la sécurité réseau est un problème dans de nombreux contextes en dehors des VPN et, en général, l'utilisation accrue de l'accès éloigné dans les réseaux publics et l'accès Internet pour des communications commerciales constituent les contraintes 10 principales derrière l'évolution de la technologie sécuritaire.
Plusieurs techniques pour la sécurité réseau tournent autour de l'utilisation d'un pare-feu qui est connu généralement comme étant une combinaison de matériel et de logiciel utilisée pour mettre en ouvre une politique de sécurité s'imposant au trafic 15 réseau entre deux ou plusieurs réseaux, quelques uns étant sous contrôle administratif (par exemple les réseaux organisés) et d'autres n'étant pas sous contrôle administratif (par exemple Internet).
Quelle que soit la technique de routage utilisé, le 20 mécanisme de routage n'est habituellement pas utilisé pour mettre en oeuvre la politique de sécurité, c'est à dire qu'un mécanisme de routage est souvent considéré trop dynamique et non fiable pour effectuer des fonctions de sécurité. Les fonctions de routage et les structures de base sont principalement conçues 25 pour router les paquets de façon efficace et fiable, mais pas de façon sécurisée. Par conséquent, les techniques de filtrage qui peuvent être implémentées en liaison avec les fonctionnements d'un pare-feu (et/ou routeur) dans des buts de sécurité existent et des exemples (voir ci-dessus) sont le filtrage de paquet, les 30 proxys d'application et le filtrage dynamique (à contrôle d'état). Les champs sur lesquels le filtrage est appliqué doivent être les champs fiables, ce qui n'est pas facilement le cas avec les en-têtes IPv4. L'un de ces champs nécessaires est du type ID VPN.
Bien qu'il y a beaucoup de techniques pour implémenter et sécuriser des VPN individuels, comme discuté ci-dessus, il existe 5 un besoin additionnel pour des VPN qui peuvent communiquer entre eux sans sacrifier le service rendu aux utilisateurs, par exemple sans réduire la sécurité des transmissions entre les deux (ou plus) VPN ou à l'intérieur d'un VPN particulier.
Exposé de l'invention En conséquence, le but principal de l'invention est de fournir un système pour convertir les données basées sur IPv4 en données basées sur IPv6 et transmettre les données converties dans un réseau commuté IP, un tel système évitant les problèmes 15 mentionnés précédemment tels que le filtrage de route et améliorant la sécurité réseau lors de l'élaboration des VPN dans une infrastructure réseau IP partagée.
L'invention a donc pour objet un système de conversion de paquets de données basés sur le protocole IPv4 en paquets de 20 données basés sur le protocole IPv6 à transmettre à travers une infrastructure de réseaux privés virtuels (VPN) dans un système de transmission de données comprenant un réseau commuté IP auquel sont connectées une première station de travail par un premier dispositif de bord de fournisseur (PE) et une seconde station de 25 travail par un second dispositif de bord de fournisseur (PE), les stations de travail fonctionnant selon le protocole IPv4 alors que le réseau commuté IP fonctionne selon le protocole IPv6. Le système comprend un premier constructeur de paquet entre la première station de travail et le réseau commuté IP pour 30 convertir chaque paquet de données basé sur le protocole IPv4 reçu à partir de la première station de travail et transmis au réseau commuté IP dans le protocole IPv6 et réciproquement, et un second constructeur de paquet entre le réseau commuté IP et la seconde station de travail pour convertir chaque paquet de données basé sur le protocole IPv6 reçu à partir du réseau et transmis à la seconde station de travail dans le protocole IPv4 et réciproquement.
Description brève des dessins
Les buts, objets et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description qui 10 suit faite en référence aux dessins dans lesquels: * la figure 1 représente un premier mode de réalisation d'un système de transmission de données mettant en euvre l'invention, * les figures 2A et 2B représentent respectivement l'adresse 15 unicast globale IPv6 et ses modifications pour la mise en oeuvre de l'invention, * la figure 3 est un bloc-diagramme représentant les constructeurs de paquet selon l'invention connectés aux serveurs de données par l'intermédiaire d'un réseau virtuel, 20 * la figure 4 représente un second mode de réalisation dans lequel la fonction de constructeur de paquet est intégrée dans le dispositif PE, et * les figures 5A et 5B représentent respectivement la modification de la structure de paquet de données entre la 25 source et la destination dans les premier et second modes s de réalisation de l'invention.
Description détaillée de l'invention
Un système selon l'invention est illustré sur la figure 1. 30 Dans un tel système, deux stations de travail 20 et 26 échangent des données à travers un réseau commuté IP 25. Un tel réseau est, dans le mode de réalisation préféré, basé sur le protocole MPLS (commutation d'étiquettes multiprotocole) qui est une technologie IP définissant des dispositifs PE (bords du fournisseur de service) qui définissent un chemin physique à travers le réseau 5 pour chaque liaison client, un tel chemin étant défini comme un ensemble d'étiquettes qui sont commutées le long du chemin d'un PE d'entrée tel que PE1 24 à un EP de sortie tel que PE2 30.
Dans le réseau commuté IP 25, qui est de préférence un réseau MPLS comme mentionné précédemment, plusieurs VPN sont 10 implémentés entre les dispositifs de bord 24 et 30.
L'environnement de l'invention est relatif à la question de savoir comment un VPN spécifique peut être établi et identifié de façon sécurisée en utilisant les mécanismes de couche 3 tels que celui proposé ici dans le protocole IPv6.
On suppose que les paquets de données envoyés par chaque station de travail 20 et 26 sont basés sur IPv4. Par conséquent, chaque station de travail est connectée à un réseau IPv4, respectivement le réseau 21 pour la station 20 et le réseau 27 pour la station 26. Le flot de données IPv4 transmis à partir de 20 la station de travail 20 est alors converti, comme décrit cidessous, par un constructeur de paquet PB1 22 en un flot de données IPv6. Les paquets sont transmis au PE1 d'entrée 24 à travers le réseau IPv6 23, et ensuite transmis à travers le réseau 25 en utilisant la commutation d'étiquettes si ce réseau 25 est un réseau MPLS.
A la sortie du réseau 25, les paquets de données en IPv6 sont reçus par PE2 30 et transférés à un constructeur de paquet PB2 28 à travers un réseau IPv6 29. Les paquets qui ont été convertis, comme décrit cidessous, de IPv6 à IPv4 sont transmis 30 à la station de travail ST2 28 à travers le réseau IPv4 27. Ce flot de données est naturellement inversé pour les paquets transmis de la station 26 à la station 20.
Le principe de l'invention est d'utiliser un en-tête IP qui est dérivé de l'en-tête IP proposé par IETF (Force de travail d'inginiérie) dans les RFC 2373 et 2374 qui est illustré sur la figure 2A. Le format de cette adresse unicast globale est conçu 5 pour supporter le regroupement d'adresses utilisé par le fournisseur habituel et un nouveau type de regroupement utilisé pour les échanges. La combinaison permet un regroupement de routage pour les deux sites qui se connectent directement aux fournisseurs de service. Les sites ont le choix de se connecter à 10 l'un ou des points de regroupement.
Globalement, dans le format d'adresse illustré sur la figure 2A, les premiers 48 bits sont relatifs à la technologie de réseau public, les 16 bits suivants sont relatifs à la topologie du site et les 64 bits restants sont relatifs à l'identifiant 15 d'interface. Les champs sont les suivants: - Préfixe Format (3 bits), pour les adresses unicast globales, ID TLA, Identifiant d'agrégation du niveau supérieur, - RES, Réservé pour utilisation future, - ID NLA, Identifiant d'agrégation de niveau inférieur, - ID SLA, Identifia d'agrégation de niveau site, - ID INTERFACE, Identifiant d'interface.
Cette structure basique est ré-utilisée pour fournir un usage transparent des mécanismes IPv6 tels que la recherche 25 d'adresse (correspondance par le préfixe le plus long).
Malheureusement, le mécanisme utilisé pour construire le format IPv6 à partir du format IPv4 est statique et établi manuellement dans les dispositifs de bord.
C'est pourquoi l'invention concerne un nouveau format IPv6 30 illustré sur la figure 2B, dans lequel les champs sont les suivants: * l'identifiant ID du fournisseur ID FO (par exemple ATT), * le champ PE incluant le numéro sur le dispositif PE connecté au réseau commuté IP (par exemple 24 ou 30). La façon dont le champ PE est défini fait aussi partie de la 5 proposition et comprend plusieurs méthodes: topologie active connue fournie par les outils de gestion du réseau, récupération du champ au niveau IP: outil de type "Traceroute" + base de données PE avec des techniques dynamiques ou de mises à jour régulières, 10 données par les outils MPLS, forcés ou prédéfinis, * l'identifiant ID VPN qui peut être subdivisé en zones pour fournir une structure VPN hiérarchique, * l'identifiant d'emplacement ID EMP est la situation géographique du site, * l'identifiant hôte ID HOTE qui se réfère à un dispositif qui utilise l'adresse IPv4 correspondante. L'hôte peut être un serveur, un client, un routeur, un pare-feu.
Différentes règles peuvent être appliquées. Dans le mode de réalisation préféré, c'est l'adresse MAC si cette 20 adresse peut être récupérée et vérifiée. Elle fournit une identification unique qui donne une information privative supplémentaire. ID HOTE dans le champ d'adresse IPv6 peut soit contenir l'adresse MAC correspondant à l'adresse IPv4 ou juste un équivalent ID et la correspondance entre 25 eux est conservée localement, * l'adresse ADR IPv4 (source ou destination) qui est présente dans le paquet entrant.
L'avantage majeur de l'invention est de simplifier la commutation d'étiquettes et la gestion de VPN (VPN MPLS) puisque 30 la destination PE est incluse dans le champ d'adresse de destination du nouvel en-tête IPv6. Une étiquette VPN par connexion peut être utilisée à la place du regroupement de connexions partageant la même étiquette dans la mesure o il n'existe plus de besoin pour une implémentation d'étiquettes duales comme ceci est réalisé dans le VPN MPLS. En utilisant 5 cette méthode, un paquet entrant dans le réseau MPLS 25, par exemple à PEl, fournit directement dans son en-tête IPv6 le PE de destination tel que PE2. Il n'est pas nécessaire qu'il y ait une identification de chemin spéciale si PEl sait comment atteindre PE2.
Finalement, pour le routage dans le réseau commuté IP, seuls les octets MSB du champ d'adresse sont utilisés alors que sur l'accès, seulement les octets LSB sont utilisés. Ceci simplifie le mécanisme de recherche d'adresse même au niveau PE, ce qui a été un des inconvénients de IPv6 puisque, normalement, une 15 recherche d'adresse à 128 bits est nécessaire. Les PE usuels supportant IPv6 comme protocole d'entrée peuvent être utilisés mais peuvent aussi être améliorés en identifiant les sous-champs de la partie MSB du champ d'adresse IPv6 de façon à utiliser directement l'adresse pour router les paquets.
Le réseau MPLS n'a pas besoin de mettre en oeuvre une caractéristique VPN additionnelle telle que VPN MPLS puisque l'isolation est assurée par l'entête IPv6 qui contient l'identifiant VPN. Comme ce champ n'est pas établi par l'utilisateur mais par le constructeur de paquet PBl ou PB2, il 25 n'y a aucun risque d'avoir une usurpation par les flots IPv6 défins par l'utilisateur. Ceci est un perfectionnement de la sécurité qui mérite d'être utilisé même pour les flots entrants IPv6 standard. Tous les champs de sécurité doivent être validés, ajoutés ou remplacés au neud d'entrée du réseau. Ces champs 30 comprennent le champ de fournisseur, le champ PE, le champ ID VPN, le champ d'emplacement ID EMP, et le champ d'hôte ID HOTE même s'il est utilisé aussi pour le filtrage. Lorsqu'un paquet il IPv6 est reçu, il peut être analysé pour vérifier que sa structure d'en-tête correspond aux règles locales, ce qui empêche une usurpation IPv6. S'il n'y a pas correspondance dépendant des champs et des règles, il peut être modifié ou éliminé. S'il est 5 modifié, une table de remplacement est construite pour retrouver le champ d'adresse d'origine des paquets entrants à partir du réseau comme un mécanisme à contrôle d'état. Elle fonctionne, dans ce cas, comme une table de traduction d'adresse NAT IPv6 pour convertir les flots IPv6 qui ne correspondent pas aux règles 10 proposées. Une telle conversion est effectuée dans les dispositifs PB.
L'invention rend le routage adaptable à un plus grand nombre d'utilisateurs. La gestion de réseau d'une telle implémentation est plus simple puisque l'en-tête IP contient tous les champs 15 nécessaires pour gérer un flot, ce qui n'est pas le cas aujourd'hui avec IPv4 d'un côté et MPLS de l'autre. Elle fournit aussi une sécurité accrue.
En ce qui concerne MPLS, les organisations standards et les vendeurs travaillent sur un mécanisme IPv6 à travers MPLS appelé 20 6PE, qui réutilise les mécanisme VPN MPLS en v4. L'invention consiste à remplacer les mécanismes MPLS et BGP basés sur v4 par des mécanisme v6 standards, ceci étant encore compatible avec la solution 6PE comme implémentation intermédiaire. L'avantage d'introduire la connaissance VPN MPLS dans l'entête IPv6 est de 25 converger vers un seul élément de transmission qui possède toute l'information nécessaire en tout point du réseau.
L'intercommunication entre deux MPLS sera aussi plus facile à mettre en oeuvre et à gérer d'une manière plus sécurisée dans la mesure o l'entête IPv6 contiendra l'information nécessaire et 30 il ne sera pas nécessaire d'établir un pont au niveau étiquette.
Pour implémenter l'invention, il est nécessaire d'utiliser des serveurs qui donnent la valeur de chaque champ pour les adresses source et destination de manière sécurisée. Ces serveurs comprennent des dispositifs DNS, Whois, Réflecteurs de route et également des Autorités de Certification puisque l'adresse IPv6 doit être fournie de façon sécurisée. La figure 3 représente les 5 connexions logiques des constructeurs de paquet 22 ou 28 vers de tels serveurs 31 à 37 au moyen d'un réseau virtuel 39 qui peut être un réseau IPv4 21 ou 27, un réseau IPv6 23 ou 29, le réseau MPLS 25 ou 27, un réseau IPv6 23 ou 29, le réseau MPLS 25 ou tout autre réseau connecté à un de ces réseaux ou directement connecté 10 au constructeur de paquet.
La reconstitution de l'adresse IPv6 source ou destination est une méthode pour construire les paquets IPv6 en utilisant les paquets IPv4.
* La recherche DNS 31 et la recherche Whois sur le serveur 15 WH 32 sont utilisées pour identifier l'emplacement du dispositif de destination et le propriétaire (ISP/client). Les deux sont utilisés pour établir le champ ID EMP et le champ ID VPN.
* La requête de certificat sur le serveur d'Autorité de 20 certification (CA) 33 est utilisée pour valider les adresses IPv4 source et destination et ID HOTE pour des buts de sécurité. Elle peut être utilisée en plus ou en remplacement des serveurs DNS et Whois.
* Un serveur répertoire REP 34 contient les sous-réseaux 25 permis et les ID HOTE autorisés mais en tant que méthode alternative à l'utilisation de certificat. Ce serveur ou le CA peut aussi fournir ID VPN si plus d'un VPN est présent sur une interface. Autrement, ID VPN peut être défini juste par l'interface en utilisant une table 30 statique de correspondance comme il est pratiqué aujourd'hui à l'aide d'une correspondance physique ou logique à un seul VPN (généralement un circuit virtuel).
* Un Réflecteur de route RR 35 fournit la valeur du champ PE pour l'adresse de destination. L'adresse source est 5 remplie avec le champ d'identification PE de connexion locale. RR résout le routage dans l'infrastructure de commutation en utilisant n'importe quelle sorte de techniques de routage permettant de fournir le routage pour les groupes VPN ou les types de flot.
* Un outil de gestion réseau NM 36 fournit les règles de filtrage qui peuvent être appliquées dynamiquement si nécessaire. PB est l'endroit adéquat pour mettre des règles de filtrage au point d'entrée du réseau de façon à éviter l'usurpation par exemple. NM peut aisément 15 identifier les attaques sur le réseau destinataire et trouver à partir de quel point d'entrée ces paquets sont envoyés et prendre des mesures appropriées.
* Un proxy AP 37 fournit l'adresse MAC du dispositif transmetteur si cette fonction est utilisée pour une 20 sécurité améliorée et l'identification du dispositif.
Dans certains cas, le proxy peut être seulement le routeur d'accès par défaut lorsqu'il n'existe pas d'autres routeurs sur le chemin. Dans ce cas, un tel routeur devrait être autorisé à répondre aux requêtes AP. 25 L'adresse MAC peut également être mémorisée préalablement dans le DNS ou le serveur répertoire ou dans le certificat. L'avantage du proxy ou la requête AP au routeur par défaut est que l'adresse MAC est validée dynamiquement par rapport à l'adresse IP source du flot. 30 Ainsi, par exemple, une adresse MAC connue peut être délivrée même s'il n'est pas connecté au réseau LAN régulier. Une adresse MAC inconnue pour tous les serveurs peut être interdite pour certain réseaux dans un autre cas.
Les champs IPv6 à remplir de cette façon comprennent 5 l'adresse source et l'adresse destination. La figure 3 montre une implémentation o les deux dispositif PB ont accès à tous les serveurs de manière à obtenir les informations pour les deux champs d'adresse source et destination. Une implémentation alternative est que le Réflecteur de route fournisse l'adresse IP 10 du constructeur de paquet de destination (comme PB2) lorsque PE2 est destinataire de manière à ce que PBl obtienne les informations de destination directement de PB2 et non à partir des serveurs. L'avantage d'une telle implémentation est la performance puisque chaque constructeur de paquet maintient une 15 liste de tous les dispositifs accessibles localement avec les paramètres associés. Ainsi, en un seul appel au PB éloigné, toutes informations peuvent être obtenues. Si le PB éloigné n'a pas ce dispositif dans sa mémoire cache, il contacte les serveurs pour les obtenir. Cette analyse est seulement faite une fois par 20 flot (sur le premier paquet) et le niveau d'analyse effectuée peut dépendre du réseau sur lequel le paquet doit être transmis.
En fait, c'est moins d'une fois par flot dans la mesure o seule la partie source (ou la partie destination s'il est nouveau) est traitée et les informations sont conservées dans une mémoire 25 cache, ce qui minimise l'impact sur la performance d'une telle implémentation.
Selon un autre mode de réalisation, le constructeur de paquet est intégré dans le dispositif PE comme représenté sur la figure 4. Dans un tel cas, il n'y a bien sûr pas de réseau IPv6 30 comme dans le mode de réalisation général illustré sur la figure 1. Dans ce cas, le constructeur de paquet et le dispositif PE forment un simple bloc, c'est à dire que le bloc PE1 41 remplace PB1 22 et PE1 24 et le bloc PE2 remplace PB2 28 et PE2 30.
Cette implémentation est également utilisée pour effectuer la fonction sur le PE lui-même, ce qui est plus efficace puisque 5 le champ PE de l'adresse peut être directement utilisé par le PE pour transmettre sur le réseau MPLS sans récupération du chemin supplémentaire et un niveau supplémentaire d'étiquette comme sur VPN MPLS. En fait, une étiquette peut être utilisée comme en-tête compressée au lieu de transmettre l'en- tête IPv6 complet. La 10 transmission des deux (étiquette suivie d'un en- tête IPv6 complet) serait redondant mais possible. Plusieurs implémentations compatibles peuvent être utilisées dans l'infrastructure réseau pour la transmission de paquets utilisant des étiquettes de commutation. Le besoin est de récupérer au PE 15 ou PB de sortie l'en- tête IPv6 d'origine de chaque paquet.
Le changement du paquet de données lorsqu'il est transmis de la station de travail transmettrice à la station de travail réceptrice est illustré sur la figure 5A. Dans la station de travail 20, le paquet de données est un paquet au format standard 20 IPv4 avec un en-tête IPv4 et une partie de données. Le paquet est transmis au dispositif PB1 à l'étape 61. Le constructeur de paquet valide les champs de l'en-tête IPv4 et trouve, grâce aux serveurs défins sur la figure 3, la valeur des champs utilisés pour construire l'en-tête IPv6 correspondant. Celui-ci comprend 25 principalement l'adresse de destination IPv6 et l'adresse source IPv6. PB1 peut effectuer un filtrage additionnel si nécessaire.
Le nouveau paquet est transmis vers PE1 à l'étape 62. PE1 identifie le PE de destination et envoie le paquet à PE2 à l'étape 63. PE1 peut ajouter une étiquette telle qu'une étiquette 30 MPLS Pour améliorer la commutation des paquets dans le réseau.
PE2 reçoit le paquet et retire l'étiquette si elle est présente.
Puis, il transmet le paquet à PB2 à l'étape 64 qui peut de nouveau effectuer le filtrage, et retire ensuite l'en-tête IPv6 et reconstruit aisément le paquet IPv4 dans la mesure o l'entête IPv6 contient tous les champs nécessaires. Ce paquet IPv4 est ensuite transmis à la station de travail de destination 26 à l'étape 65.
On doit noter que ce procédé semble complexe mais nécessite, en fait, d'être effectué entièrement seulement une fois, spécialement dans PBl et PB2. Les autres paquets du même flot ne nécessitent qu'un remplacement deschamps de l'en-tête en 10 utilisant les mêmes valeurs de champ. Par conséquent, une table de remplacement peut être mise en oeuvre dans les constructeurs de paquet pour accélérer le traitement des en-têtes.
La construction ou l'addition de champs de vérification de paquet et la construction d'autres champs d'en-tête IPv4 ne sont 15 pas détaillés ici dans la mesure o d'autres fonctions peuvent être effectuées en utilisant les règles standard et des mécanismes de traduction tels que RFC 2766 ou d'autres RFC IETF.
Si le second mode de réalisation dans lequel la fonction du constructeur de paquet est intégrée dans le dispositif PE est 20 utilisée, le flot de paquet de données (et le changement de structure) illustré sur la figure 5B est simplifié mais reste très similaire au flot de données du mode de réalisation général.

Claims (12)

REVENDICATIONS
1. Système de conversion de paquets de données basés sur le 5 protocole IPv4 en paquets de données basés sur le protocole IPv6 à transmettre à travers une infrastructure de réseaux privés virtuels (VPN) dans un système de transmission de données comprenant un réseau commuté IP (25) auquel sont connectées une première station de travail (20) par un 10 premier dispositif de bord de fournisseur (PE 24) et une seconde station de travail (26) par un second dispositif de bord de fournisseur (PE 30), lesdites stations de travail fonctionnant selon le protocole IPv4 alors que ledit réseau commuté IP fonctionne selon le protocole IPv6; ledit système étant caractérisé en ce qu'il comprend un premier constructeur de paquet (22) entre ladite première station de travail et ledit réseau commuté IP pour convertir chaque paquet de données basé sur le protocole IPv4 reçu à partir de ladite première station de travail et 20 transmis audit réseau commuté IP dans le protocole IPv6 et réciproquement, et un second constructeur de paquet (28) entre ledit réseau commuté IP et ladite seconde station de travail pour convertir chaque paquet de données basé sur le protocole IPv6 reçu à partir dudit réseau et transmis à 25 ladite seconde station de travail dans le protocole IPv4 et réciproquement.
2. Système selon la revendication 1, comprenant en outre au moins un serveur (31 à 37) accédé par chacun desdits 30 premier et second constructeurs de paquet (22, 28) pour leur fournir les informations nécessaires pour convertir un paquet de données basé sur le protocole IPv4 en un paquet de données basé sur le protocole IPv6.
3. Système selon la revendication 2, dans lequel chaque paquet qui a été converti dans le protocole IPv6 par un des constructeurs de paquet (21, 28) comprend un en-tête de paquet contenant un champ PE correspondant au PE (24 ou 30) à utiliser, soit comme PE source, soit comme PE de destination et un champ d'identification VPN en plus de l'adresse IPv4 qui était dans l'en- tête de paquet avant la conversion.
4. Système selon la revendication 3, dans lequel chaque paquet de données qui a été converti dans le protocole IPv6 par un desdits constructeurs de paquet (22, 28) comprend en outre un champ d'identification EMP se référant à l'emplacement géographique du site et un champ d'identification HOTE se 15 référant à la station de travail (20, 26) qui a transmis ledit paquet de données.
5. Système selon la revendication 2, dans lequel l'accès aux serveurs (31 à 37) fournissant les informations nécessaires 20 pour convertir un paquet de données basé sur le protocole IPv4 en un paquet de données basé sur le protocole IPv6 peut être effectué par chacun desdits premier et second constructeurs de paquet à travers un réseau virtuel (39).
6. Système selon la revendication 5, dans lequel chacun desdits serveurs peut être l'un parmi un serveur de nom de domaine (31), un serveur Whois (32), un serveur d'autorité de certification (33), un serveur répertoire (34), un réflecteur de route (35), un outil de gestion de réseau 30 (36) et un proxy (37).
7. Système selon l'une des revendications 1 à 6, dans lequel ledit constructeur de paquet (22 ou 28) est connecté audit dispositif PE (24 ou 30) par un réseau basé sur le protocole IPv6 (23 ou 29).
8. Système selon l'une quelconques des revendications 1 à 6, 5 dans lequel le constructeur de paquet (22 ou 28) est intégré dans ledit dispositif PE (24 ou 30).
9. Méthode de conversion de paquets de données basés sur le protocole IPv4 en paquets de données basés sur le protocole 10 IPv6 à transmettre à travers une infrastructure de réseaux privés virtuels (VPN) dans un système de transmission de données comprenant un réseau commuté IP (25) auquel sont connectées une première station de travail (20) par un premier dispositif de bord de fournisseur (PE 24) et une 15 seconde station de travail (26) par un second dispositif de bord de fournisseur (PE 30), lesdites stations de travail fonctionnant selon le protocole IPv4 alors que ledit réseau commuté IP fonctionne selon le protocole IPv6, ladite méthode étant caractérisée par les étapes 20 consistant à : * convertir chaque paquet de données basé sur le protocole IPv4 en un paquet de données basé sur le protocole IPv6 avant de le transmettre audit réseau commuté IP en utilisant des informations fournies 25 par un serveur exterieur, et * convertir chaque paquet de données basé sur le protocole IPv6 fourni par ledit réseau commuté IP en un paquet de données basé sur le protocole IPv4 avant de le transmettre à ladite première ou seconde 30 station de travail.
10. Méthode selon la revendication 9, dans laquelle chaque paquet qui a été converti dans le protocole IPv6 par un des constructeurs de paquet (21, 28) comprend un en-tête de paquet contenant un champ PE correspondant au PE (24 ou 30) à utiliser soit comme PE source, soit comme PE de destination et un champ d'identification VPN en plus de l'adresse IPv4 qui était dans l'en-tête de paquet avant la conversion.
11. Méthode selon la revendication 10, dans laquelle chaque paquet de données qui a été converti dans le protocole IPv6 par un desdits constructeurs de paquet (22, 28) comprend en 10 outre un champ d'identification EMP se référant à l'emplacement géographique du site et un champ d'identification HOTE se référant à la station de travail (20, 26) qui a transmis ledit paquet de données.
12. Méthode selon la revendication 11, dans laquelle chacun desdits serveurs peut être l'un parmi un serveur de nom de domaine (31), un serveur Whois (32), un serveur d'autorité de certification (33), un serveur répertoire (34), un réflecteur de route (35), un outil de gestion de réseau 20 (36) et un proxy (37)
FR0306308A 2003-05-26 2003-05-26 SYSTEME DE CONVERSION DE DONNEES BASEE SUR IPv4 EN DONNEES BASEES SUR IPv6 A TRANSMETTRE A TRAVERS UN RESEAU COMMUTE IP Expired - Fee Related FR2855697B1 (fr)

Priority Applications (8)

Application Number Priority Date Filing Date Title
FR0306308A FR2855697B1 (fr) 2003-05-26 2003-05-26 SYSTEME DE CONVERSION DE DONNEES BASEE SUR IPv4 EN DONNEES BASEES SUR IPv6 A TRANSMETTRE A TRAVERS UN RESEAU COMMUTE IP
EP04012230A EP1482678B1 (fr) 2003-05-26 2004-05-24 Système pour la conversion de paquets des données selon IPv4 dans des paquets de données selon IPv6
DE602004029419T DE602004029419D1 (de) 2003-05-26 2004-05-24 System zur Konvertierung von IPv4-Datenpaketen in IPv6-Datenpakete
JP2004153034A JP2004357292A (ja) 2003-05-26 2004-05-24 IP交換網上で伝達されるデータをIPv4ベースからIPv6ベースに変換するシステム
KR1020040037368A KR20040101933A (ko) 2003-05-26 2004-05-25 데이터 변환 시스템
US10/852,945 US7369560B2 (en) 2003-05-26 2004-05-25 System for converting data based upon IPv4 into data based upon IPv6 to be transmitted over an IP switched network
CA002468480A CA2468480C (fr) 2003-05-26 2004-05-26 Systeme pour convertir des donnees ipv4 en donnees ipv6 a transmettre sur un reseau commute ip
US12/101,313 US7920589B2 (en) 2003-05-26 2008-04-11 System for converting data based upon IPv4 into data based upon IPv6 to be transmitted over an IP switched network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0306308A FR2855697B1 (fr) 2003-05-26 2003-05-26 SYSTEME DE CONVERSION DE DONNEES BASEE SUR IPv4 EN DONNEES BASEES SUR IPv6 A TRANSMETTRE A TRAVERS UN RESEAU COMMUTE IP

Publications (2)

Publication Number Publication Date
FR2855697A1 true FR2855697A1 (fr) 2004-12-03
FR2855697B1 FR2855697B1 (fr) 2005-09-23

Family

ID=33104469

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0306308A Expired - Fee Related FR2855697B1 (fr) 2003-05-26 2003-05-26 SYSTEME DE CONVERSION DE DONNEES BASEE SUR IPv4 EN DONNEES BASEES SUR IPv6 A TRANSMETTRE A TRAVERS UN RESEAU COMMUTE IP

Country Status (7)

Country Link
US (2) US7369560B2 (fr)
EP (1) EP1482678B1 (fr)
JP (1) JP2004357292A (fr)
KR (1) KR20040101933A (fr)
CA (1) CA2468480C (fr)
DE (1) DE602004029419D1 (fr)
FR (1) FR2855697B1 (fr)

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7006526B1 (en) * 2001-07-31 2006-02-28 Cisco Technology, Inc. Mechanisms for avoiding problems associated with network address protocol translation
CN100407683C (zh) * 2004-12-01 2008-07-30 华为技术有限公司 基于异种介质的IPv6网络互通的实现方法
CN100387019C (zh) * 2005-04-04 2008-05-07 华为技术有限公司 跨混合网络的多协议标签交换虚拟专用网的实现方法
US20060277267A1 (en) * 2005-05-16 2006-12-07 Simon Lok Unified memory IP packet processing platform
CN100433691C (zh) * 2005-11-02 2008-11-12 华为技术有限公司 一种虚拟专用网络的路由方法
CN100414919C (zh) * 2005-11-14 2008-08-27 华为技术有限公司 一种跨多自治系统混合网络虚拟专用网的实现方法
JP4706542B2 (ja) * 2006-04-10 2011-06-22 株式会社日立製作所 通信装置
US7668954B1 (en) * 2006-06-27 2010-02-23 Stephen Waller Melvin Unique identifier validation
US8301753B1 (en) 2006-06-27 2012-10-30 Nosadia Pass Nv, Limited Liability Company Endpoint activity logging
US8181227B2 (en) * 2006-08-29 2012-05-15 Akamai Technologies, Inc. System and method for client-side authenticaton for secure internet communications
US8112803B1 (en) * 2006-12-22 2012-02-07 Symantec Corporation IPv6 malicious code blocking system and method
US8373698B2 (en) 2007-05-10 2013-02-12 International Business Machines Corporation Holographic enterprise network
US20080288220A1 (en) * 2007-05-17 2008-11-20 Dillenberger Donna N Use of a three-dimensional (3d) data center to share service operations
KR101366254B1 (ko) * 2007-08-03 2014-02-20 삼성전자주식회사 방송망을 통하여 전송되는 ip 패킷의 압축 및 복원 방법
JP4827868B2 (ja) * 2008-03-11 2011-11-30 日本電信電話株式会社 ネットワーク接続制御システム、ネットワーク接続制御プログラムおよびネットワーク接続制御方法
US8429739B2 (en) * 2008-03-31 2013-04-23 Amazon Technologies, Inc. Authorizing communications between computing nodes
US8046480B2 (en) * 2008-03-31 2011-10-25 Amazon Technologies, Inc. Embedding overlay virtual network addresses in underlying substrate network addresses
EP3002684A1 (fr) * 2008-03-31 2016-04-06 Amazon Technologies, Inc. Configuration de communications entre des machines virtuelles
US7995504B2 (en) * 2008-05-12 2011-08-09 Microsoft Corporation Locality-based routing table generation
KR100948693B1 (ko) * 2008-10-08 2010-03-18 한국전자통신연구원 가상 플랫폼을 이용한 이종 망간 프로토콜 연동 지원을 위한 인터넷 프로토콜 변환장치 및 방법
US8004968B2 (en) * 2008-12-24 2011-08-23 Cisco Technology, Inc. Provider edge-controlled redundancy using pseudo link aggregation control protocol
JP5328472B2 (ja) * 2009-05-13 2013-10-30 キヤノン株式会社 ネットワーク通信装置及び方法とプログラム
US8234377B2 (en) * 2009-07-22 2012-07-31 Amazon Technologies, Inc. Dynamically migrating computer networks
JP5241665B2 (ja) * 2009-09-28 2013-07-17 三菱電機株式会社 通信装置、通信システムおよび通信方法
WO2011135405A1 (fr) * 2010-04-26 2011-11-03 Nokia Corporation Procédé et appareil de détection d'adresse synthétisée
US8683023B1 (en) * 2010-06-30 2014-03-25 Amazon Technologies, Inc. Managing communications involving external nodes of provided computer networks
US8923133B2 (en) * 2010-12-27 2014-12-30 Symbol Technologies, Inc. Detection of unauthorized changes to an address resolution protocol cache in a communication network
CN102904814B (zh) * 2012-10-19 2015-09-16 福建星网锐捷网络有限公司 数据传输方法、源pe、目的pe和数据传输系统
US8937955B2 (en) * 2012-12-05 2015-01-20 Cisco Technology, Inc. System and method for scaling IPv6 addresses in a network environment
US10767156B2 (en) 2013-10-24 2020-09-08 Yeda Research And Development Co., Ltd. Polynucleotides encoding BREX system polypeptides and methods of using same
US10326710B1 (en) 2015-09-02 2019-06-18 Amazon Technologies, Inc. Propagating access rules on virtual networks in provider network environments
US10666536B1 (en) * 2015-12-11 2020-05-26 Expanse, Inc. Network asset discovery
US10257280B2 (en) 2015-12-28 2019-04-09 Carbonite, Inc. Systems and methods for remote management of appliances
US20180375762A1 (en) * 2017-06-21 2018-12-27 Microsoft Technology Licensing, Llc System and method for limiting access to cloud-based resources including transmission between l3 and l7 layers using ipv6 packet with embedded ipv4 addresses and metadata
CN112261054B (zh) * 2020-10-23 2022-07-15 重庆邮电大学 基于应用业务服务质量的Ethernet/IP与IPv6协议转换系统及方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020136237A1 (en) * 1996-11-01 2002-09-26 Hitachi, Ltd. Communicating method between IPv4 terminal and IPv6 terminal and IPv4 converting apparatus
EP1298853A1 (fr) * 2000-06-16 2003-04-02 Fujitsu Limited Dispositif de communication comprenant une fonction d'amenagement vpn

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6580717B1 (en) * 1996-07-04 2003-06-17 Hitachi, Ltd. Packet communication method and apparatus and a recording medium storing a packet communication program
US7369556B1 (en) * 1997-12-23 2008-05-06 Cisco Technology, Inc. Router for virtual private network employing tag switching
US6339595B1 (en) * 1997-12-23 2002-01-15 Cisco Technology, Inc. Peer-model support for virtual private networks with potentially overlapping addresses
WO2001099457A1 (fr) * 2000-06-20 2001-12-27 Nokia Networks Oy Procede d'execution d'une mise a jour des routes d'un terminal mobile utilisateur, dans un reseau de telecommunications mis en oeuvre selon le protocole internet
US6907470B2 (en) * 2000-06-29 2005-06-14 Hitachi, Ltd. Communication apparatus for routing or discarding a packet sent from a user terminal
JP2002033764A (ja) * 2000-07-14 2002-01-31 Fujitsu Ltd 通信サービス提供システム、並びに通信サービス提供システムにおいて使用される移動端末装置、アドレスサーバ装置、およびルータ装置
JP4183379B2 (ja) * 2000-11-27 2008-11-19 富士通株式会社 ネットワーク及びエッジルータ
US7136374B1 (en) * 2001-03-19 2006-11-14 Juniper Networks, Inc. Transport networks supporting virtual private networks, and configuring such networks
JP4236398B2 (ja) * 2001-08-15 2009-03-11 富士通株式会社 通信方法、通信システム及び通信接続プログラム
US20030172177A1 (en) * 2001-12-06 2003-09-11 Kersley Ian P. System and method for verifying a device
JP4349789B2 (ja) * 2002-11-06 2009-10-21 富士通株式会社 安全性判断装置及び安全性判断方法
EP1692595A2 (fr) * 2003-11-04 2006-08-23 Nexthop Technologies, Inc. Communications standards securises par reseau longue portee

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020136237A1 (en) * 1996-11-01 2002-09-26 Hitachi, Ltd. Communicating method between IPv4 terminal and IPv6 terminal and IPv4 converting apparatus
EP1298853A1 (fr) * 2000-06-16 2003-04-02 Fujitsu Limited Dispositif de communication comprenant une fonction d'amenagement vpn

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DE CLERQ; GASTAUD; CARUGI; LE FAUCHEUR: "BGP-MPLS VPN extension for IPv6 VPN", INTERNET DRAFT, 30 November 2002 (2002-11-30), pages 1 - 13, XP002270869, Retrieved from the Internet <URL:http://pddocserv/specdocs/data/standards/telecom/ietf/drafts/draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt> [retrieved on 20040219] *

Also Published As

Publication number Publication date
CA2468480C (fr) 2010-01-19
DE602004029419D1 (de) 2010-11-18
US20050025157A1 (en) 2005-02-03
CA2468480A1 (fr) 2004-11-26
EP1482678B1 (fr) 2010-10-06
EP1482678A1 (fr) 2004-12-01
US20080192771A1 (en) 2008-08-14
JP2004357292A (ja) 2004-12-16
US7920589B2 (en) 2011-04-05
KR20040101933A (ko) 2004-12-03
US7369560B2 (en) 2008-05-06
FR2855697B1 (fr) 2005-09-23

Similar Documents

Publication Publication Date Title
FR2855697A1 (fr) SYSTEME DE CONVERSION DE DONNEES BASEE SUR IPv4 EN DONNEES BASEES SUR IPv6 A TRANSMETTRE A TRAVERS UN RESEAU COMMUTE IP
US8295285B2 (en) Method and apparatus for communication of data packets between local networks
US7873993B2 (en) Propagating black hole shunts to remote routers with split tunnel and IPSec direct encapsulation
US7855955B2 (en) Method for managing frames in a global-area communications network, corresponding computer-readable storage medium and tunnel endpoint
JP4130962B2 (ja) ネットワーク上のデスティネーションへ送信されたデータの経路決めをするドメイン名を使用するためのシステムおよび方法
US7903671B2 (en) Service for NAT traversal using IPSEC
US8805977B2 (en) Method and system for address conflict resolution
US8554946B2 (en) NAT traversal method and apparatus
FR2801754A1 (fr) Methode pour assigner une double adresse ip a un poste de travail relie a un reseau de transmission de donnees ip
TW201201554A (en) Network topology concealment using address permutation
EP2294798B1 (fr) Procede de routage d&#39;un paquet de donnees dans un reseau et dispositif associe
EP1672849B1 (fr) Procédé d&#39;exploitation d&#39;un réseau informatique local relié à un réseau distant privé par un tunnel IPsec
US20220337547A1 (en) Domain routing for private networks
US20090106449A1 (en) Method and apparatus for providing dynamic route advertisement
WO2010072953A1 (fr) SYSTEME D&#39;ACHEMINEMENT D&#39;UN PAQUET DE DONNEES IPv4
FR3023098A1 (fr) Procede et systeme de traitement d&#39;une demande de resolution d&#39;un nom d&#39;un serveur, emise par une application cliente sur un reseau de communication.
WO2020020911A1 (fr) Procede de traitement d&#39;un paquet de donnees, dispositif, equipement de commutation et programme d&#39;ordinateur associes
FR3118561A1 (fr) Procede de configuration d&#39;une interface securisee entre un reseau de transport et un reseau elementaire d&#39;une pluralite de reseaux elementaires federes a travers le reseau de transport ; interface associee
Kramshøj Designing Internetworks with IPv6
Henrici et al. Site Multihoming and Provider-Independent Addressing Using IPv6
Ryynänen Päästä-päähän reitittävä Ethernet–Tekninen kokeilu
Venaas et al. of Deliverable: Updated IPv4 to IPv6 transition cookbook for end site

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20130131