Les réseaux pour l’IOT et le M2M

24 mars 2016 par Jean-Pierre

Selon Jeremy Rifkin, la 3ème révolution industrielle est en marche et s’appuie sur l’Internet des objets afin que des centaines de milliards d’objets communiquent en temps réel vers des plateformes de données : de la gestion des bâtiments (smart-building), à celle d’une ville entière (smart-city), de l’énergie (smart-grid) à l’agriculture, du véhicule, aux objets du quotidien, … Toutes nos habitudes seront bousculées par l’arrivée massive de ces objets.
Quels sont les secteurs actuellement visés ? Quels sont les revenus attendus ? Quel est le business model pour les nouveaux opérateurs entrants ? Comment les opérateurs vont-ils pouvoir transporter cette masse d’information du capteur ou du smart-meter aux applications ? Comment assurer l’hétérogénéité des solutions existantes ? Comment 3GPP à travers les réseaux 4,5G et 5G répond-il à de tels besoins et à l’émergence de l’Internet Tactile ?

Afin de répondre à ces questions, NEXCOM Systems propose une nouvelle formation Les réseaux pour le M2M et l’IoT faisant un état de l’art des technologies émergentes de l’IoT et en abordant les solutions techniques adoptées dans les réseaux des Telcos pour répondre à de tels défis.

Optimisation des datacenters

10 mars 2015 par Jean-Pierre

Virtualisation des capacités et cloud computing privé conduisent les entreprises à mettre en place leurs propres data centers afin de disposer de la flexibilité indispensable aux évolutions de leur activité, tout en mutualisant les coûts.

Cependant la conception d’un data center se doit d’être réfléchie, notamment dans le contexte économique actuel : quel est l’espace nécessaire, comment optimiser la consommation d’énergie quand les serveurs blades deviennent la norme, quelle architecture réseau, quels types de protection contre les risques d’attaques extérieures… sont autant de questions à se poser pour concevoir une solution répondant aux besoins.

Afin d’accompagner ses clients dans la conception et la mise en oeuvre de data centers performants et rentables, NEXCOM Systems propose de nouvelles formations dans le domaine de l’urbanisation des data centers, ainsi que dans celui des SDN (Software Defined Networks) et de la sécurité, technologies critiques pour apporter la flexibilité et l’efficacité requises.

Virtualisation des réseaux : Accord ETSI / ONF

1 avril 2014 par Yannick

Le 18 mars 2014, l’ETSI (European Telecommunications Standards Institute) et l’ONF (Open Networking Foundation) ont annoncé un accord pour favoriser le développement des normes NFV (Network Functions Virtualization) en s’appuyant sur le SDN (Software-Defined Networking).

L’infrastructure technique définie dans l’architecture NFV s’appuiera sur les travaux réalisés par l’ONF à travers la normalisation de SDN et du protocole OpenFlow (protocole de configuration et de contrôle des switches).

L’ONF a également publié une présentation sur la manière dont les opérateurs vont pouvoir combiner NFV et SDN pour atteindre les objectifs communs des deux technologies (réduction des coûts, flexibilité, évolutivité, …).
Cette présentation est disponible ici.

Pour poursuivre la lecture, vous trouverez également les détails de cette annonce sur les sites de l’ONF (ici) et de l’ETSI (ici).

VoLTE : les solutions envisagées aujourd’hui

20 février 2014 par nexcom

Avec le déploiement de réseaux 4G/LTE et la démocratisation de terminaux compatibles, les solutions de voix sur LTE (Voice over LTE ou VoLTE) se précisent. Réseau de données par excellence, la LTE ne permet pas de passer des appels « voix », à l’exception de l’usage de la voix sur IP (VoIP). Différentes approches ont été envisagées par les opérateurs télécom.

André PEREZ, consultant et formateur LTE et IMS pour NEXCOM Systems aborde ces différentes approches (CS FallBack, SRVCC, …), ainsi que les impacts et interactions avec les infrastructures existantes (IMS) dans un article très détaillé :

Le terme LTE (Long Term Evolution) est utilisé pour désigner les réseaux de mobiles 4G. En fait, il conviendrait de nommer ces réseaux sous le vocable d’EPS (Evolved Packet Service), le terme LTE étant plutôt réservé pour dénommer l’interface radioélectrique entre le réseau 4G et le mobile.
Le service téléphonique est rempli à partir de deux fonctions de base : le transport de la voix et le traitement de la signalisation téléphonique. Le terme Voix sur LTE ou VoLTE (Voice over LTE) est le terme consacré pour désigner le transport de la voix sur IP  assuré par le réseau EPS, dans le cadre de la fourniture du service téléphonique à travers une plate-forme IMS.

Lire la suite de l’article VoLTE… (PDF, 370ko)

 

NEXCOM Systems propose bien évidemment de nombreuses formations sur la LTE, la LTE-Advanced et l’IMS, couvrant les fondamentaux aux concepts plus poussés (interactions avec l’IMS, VoLTE, …). N’hésitez pas à nous contacter pour planifier votre future formation ou obtenir davantage d’informations !

 

VoLTE : nouvel ouvrage technique

20 janvier 2014 par nexcom

Les mécanismes permettant de réaliser de la voix sur LTE (VoLTE ou Voice over LTE) vont devenir une réalité avec le déploiement des réseaux 4G/LTE ainsi que la démocratisation de terminaux compatibles. Réseau de données par excellence, la LTE n’est pas en mesure d’acheminer des communications voix en mode circuit et nécessite dans certains cas de se reposer sur des mécanismes de handover sur réseau 2G/3G. Problématique complexe de ce nouveau réseau mobile, la VoLTE représente un pan entier de cette technologie.

Formateur LTE/IMS pour NEXCOM Systems depuis de nombreuses années, André Pérez publie également régulièrement des ressources sur diverses technologies (IPv6, LTE, …). Le sujet de la voix sur LTE est notamment abordé dans son dernier livre, La voix sur LTE : réseau 4G et architecture IMS. Il y détaille les différents mécanismes utilisés pour réaliser des appels téléphoniques depuis des terminaux LTE (par exemple CS FallBack) et apporte ainsi une vision globale du problème et des solutions disponibles aujourd’hui, tout en prenant en considération les impacts et interactions avec l’infrastructure IMS. Publié aux éditions Hermès, ce livre est disponible au travers de la librairie Lavoisier.

 

NEXCOM Systems propose de nombreuses formations sur la LTE : fondamentaux, concepts avancés, interaction avec l’IMS, VoLTE, … N’hésitez pas à nous contacter pour davantage d’informations !

Formation WebRTC Inter-Entreprises à Paris (28 juin 2013)

28 mai 2013 par nexcom

WebRTC (Web for Real Time Communication) est une technologie qui évolue très rapidement. Après les premiers succès d’interopérabilité entre navigateurs Web, les deux clients majeurs (Google Chrome et Mozilla Firefox) sont sur le point de proposer tous deux le framework dans la version courante (stable) de leur navigateur. Cela marque une étape majeure dans le développement de la technologie : elle est désormais suffisamment stabilisée pour être rendue disponible à un plus large public.

Continue reading “Formation WebRTC Inter-Entreprises à Paris (28 juin 2013)” »

Le Web a 20 ans !

30 avril 2013 par nexcom

Le Web a 20 ans !

Photo par D Sharon Pruitt

Il y a 20 ans, Tim Berners-Lee et le CERN libérait le « World Wide Web ». D’un simple serveur, une toile complète s’est formée à travers le monde et est une des technologies les plus utilisées encore aujourd’hui.

Longue vie au Web et à ses descendants (dont le très récent et très à la mode WebRTC) !

IPv6 : c’est maintenant ou jamais…

par nexcom

IPv4 (Internet Protocol version 4) demeure à ce jour le protocole le plus utilisé dans ce grand réseau mondial qu’est Internet. Son successeur, IPv6, existe depuis bientôt 20 ans (1995 !), mais reste encore aujourd’hui marginal malgré la pénurie toujours plus pressante d’adresse IPv4. Ce constat devient plus alarmant chaque année : il va être temps de faire un choix !

Malgré les nombreuses méthodes mises en place afin de prolonger, plus ou moins artificiellement, la durée de vie d’IPv4 (CIDR, NAT, …), et ainsi permettre de déployer progressivement IPv6, celui-ci demeure encore aujourd’hui largement marginal avec seulement environ 1% du trafic mondial. Ces déploiements se sont légèrement accrus depuis l’annonce, en février 2011 par l’IANA, de l’exhaustion du pool global d’adresses IPv4. Les seules réserves restantes sont aux mains des différentes autorités régionales ou RIR (Regional Internet Registry), mais elles ne dureront pas éternellement.


Statistiques Google IPv6 et état de la pénurie IPv4

Selon l’Internet Society lors de sa dernière réunion le 17 avril 2013 à Denver (Colorado), nous sommes arrivés à un embranchement important, puisqu’au regard des prédictions de pénurie pour chaque RIR (notamment les plus gros consommateurs actuels qui sont le RIPE NCC, l’APNIC et l’ARIN), il est déjà trop tard pour envisager une « simple » transition/cohabitation entre IPv4 et IPv6, la réserve d’adresses IPv4 n’étant plus suffisante pour permettre à IPv6 d’être déployé et utilisé en masse avant leur total exhaustion.

Des approches, que nous avions appelées compressives ou translatives dans la série d’articles relatives à IPv6 et à sa migration, existent, que ce soit via IVI (permettant d’avoir un réseau natif IPv6, sans dual-stack, avec une translation 1 à 1 vers le réseau IPv4) ou au travers de CGN (Carrier-Grade NATs, solution qui semble être privilégiée par un certain nombre d’acteurs à l’heure actuelle). Cette dernière, outre les problèmes techniques qu’elles engendrent, « cassant » certaines applications, pose le même problème que les NAT classiques en leur temps : la durée de vie d’IPv4 est encore rallonger de manière artificielle et peu efficace sur le long terme.

Aujourd’hui toutefois, il n’est plus possible de s’en passer. La Chine, grosse consommatrice d’adresses IP depuis quelques années, a déjà dû recourir à certaines de ces méthodes (IVI notamment). Certains fournisseurs d’accès européens envisagent l’ajout de CGN dans leur réseau afin de retarder l’échéance. Le choix qui sera majoritairement fait à ce niveau de la cohabitation déterminera ce qu’il adviendra d’IPv6 : solution tournée vers l’avenir, elle ne pourra être viable que si tous les acteurs décident de s’y impliquer sérieusement. L’ajout de CGN sur le réseau ne doit être qu’une méthode pour gagner encore un peu de temps, mais ne représente en aucun cas une solution à long terme.

Les CGN et Internet (source:  Geoff Huston de l’APNIC via potaroo.net)

IPv6 est la solution à long terme, la vision d’avenir promise depuis plusieurs décennies. Il est temps de s’y mettre sérieusement : IPv6 n’est plus seulement une perspective à long terme, le protocole doit devenir une priorité, sans quoi l’Internet tel que nous le connaissons aujourd’hui n’existera plus.

Dans cet objectif, NEXCOM Systems propose un certain nombre de ressources et de compétences sur IPv6 afin d’aider à sa compréhension. Des formations IPv6 abordant le protocole dans le détail (disponible sur un ou deux  jours, selon le besoin en connaissances pratiques) ont été conçues afin de comprendre le protocole dans le détail et mieux pouvoir l’appréhender : généralité, adressage, migration v4/v6, etc.

Ces formations sont complétées par des articles, librement disponibles sur notre blog, rappelant les grandes lignes du protocole et des différentes méthodes de migration/translation/cohabitation disponibles. Dans la même idée, nous avons compilé les informations principales du protocole sous une forme concentrée (cheatsheet ou mémo IPv6), également librement disponible sur notre page d’expertise (ou également ici).

Bonne lecture !

Les solutions de chiffrement en réseaux télécoms et Web/WebRTC

25 février 2013 par nexcom

Les notions de sécurité sont souvent mal considérées. Difficiles à comprendre et appréhender, coûteuses à déployer et ayant des résultats parfois variables (mauvaise étude, cas d’usage particulier, …), la sécurité dans les technologies de l’information reste un domaine de niche dans lequel peu s’aventurent. Elle représente en effet un travail considérable… Mais dont l’absence peut mener à des résultats désastreux (vols de données sensibles, indisponibilité prolongée de service, …) ayant des répercutions souvent catastrophiques (coût financier, par exemple, mais pouvant aller jusqu’à la disparition pure et simple d’une entreprise selon les données volées par exemple).

Pourtant, et en se focalisant sur le domaine qui nous intéresse ici directement, il existe aujourd’hui des solutions de chiffrement de trafic IP standardisées et efficaces. Deux méthodes générales peuvent être listées :

  • Symétrique : une unique clé est partagée et sert à la fois à chiffrer et déchiffrer le trafic.
  • Asymétrique : chaque entité dispose de deux clés, l’une servant à chiffrer (clé publique) alors que l’autre permet de déchiffrer le trafic (clé privée).

Chiffrement symétrique

Le premier type est simple d’utilisation et d’implémentation. Il offre de plus d’excellentes performances lorsqu’il s’agit de chiffrer/déchiffrer du trafic, la même clé servant aux deux usages. Il est fréquemment mis en œuvre dans des installations de type SOHO (Simple Office, Home Office) et se retrouve dans des solutions « grand public » (par exemple dans les WiFi sécurisés en WPA-PSK ou Pre-Shared Key).

En pratique toutefois, il montre rapidement ses limites pour plusieurs raisons :

  • La clé doit être échangée à un moment donné. Et cet échange peut être intercepté, rendant le chiffrement inutile…
  • La clé est définie par un des participants, et n’est pas renouvelée automatiquement, la rendant plus vulnérable à des attaques par dictionnaire, par exemple.

Plus la clé symétrique est longue, plus ce second point est atténué. Toutefois, plus la clé est longue, plus le premier point peut devenir contraignant… Ce n’est donc pas une solution viable à long terme.

Chiffrement asymétrique et hybride

Le chiffrement asymétrique, de son côté, est sensiblement plus complexe (quatre clés au lieu d’une seule, chiffrement/déchiffrement bien plus coûteux en ressources, …). Contrairement au chiffrement symétrique, cette approche offre le meilleur niveau de sécurité grand public connu actuellement, proposant une théorique inviolabilité jamais contestée jusqu’à présent (sauf dans le cas de problèmes d’implémentation, liés souvent à une génération prévisible de nombres aléatoires).

Si la clé publique, comme son nom l’indique, peut être distribuée à n’importe qui (elle ne peut servir à rien d’autre qu’au chiffrement et à l’identification), la clé privée, elle, doit impérativement rester secrète sans quoi tout l’intérêt de cette technique disparaît. Toute personne en possession de cette clé peut en effet facilement usurper l’identité du possesseur originel.

A titre d’exemples, RSA (conçu en 1977 et nommée après ses inventeurs, R. Rivest, A. Shamir and L. Adleman) et DH (1976, également du nom de ses inventeurs, W. Diffie et M. Hellman) sont tous deux des algorithmes se reposant sur ce principe d’asymétrie. Les certificats standardisés x.509 représentent la forme la plus courante de distribution de clés publique/privée.

Son coût élevé en ressources pour chiffrer/déchiffrer le trafic ne lui permet malheureusement pas d’être utilisé pour chiffrer de grandes quantités de données. Des méthodes « hybrides » ont été créées afin de palier à ce problème et coupler les avantages du chiffrement symétrique et asymétrique. Le fonctionnement de cette approche est représenté ci-dessous de manière (très) simplifiée DON’T PANIC ! ;-)

  1. Alice demande une connexion sécurisée avec Bob.
  2. Bob transmet, de manière non sécurisée, son certificat, à savoir sa clé publique. Le fait que le médium ne soit pas sécurisé n’est donc pas un problème ici, tout le monde pouvant demander l’accès à cette clé.
  3. Alice récupère la clé publique de Bob et authentifie celui-ci. La connexion est refusée si cette identité ne peut être vérifiée.
  4. Par des procédés cryptographiques dans lesquels nous n’allons pas nous engager ici (à base de très grands nombres premiers aléatoires que les deux entités s’échangent… Je vous passe les détails mais vous conseille cet excellent article publié sur Ars Technica [EN] très récemment), Alice génère une Pre-Master Key.
  5. Cette clé ainsi que la clé publique d’Alice sont transmises à Bob. Le  secret de la Pre-Master Key doit être préservé pour assurer l’efficacité de la méthode. Alice possédant la clé publique de Bob, elle l’utilise pour chiffrer son message.
  6. A la réception du message chiffré, Bob utilise sa clé privée pour déchiffrer le message, chiffré avec sa clé publique par Alice. Il en extrait deux éléments : la clé publique d’Alice et, encore plus important, la Pre-Master Key.
  7. Bob authentifie Alice à l’aide de sa clé publique. Si l’identité est vérifiée correctement, la négociation est terminée. Ce message peut être transmis de manière sécurisée grâce à la clé publique d’Alice. Celle-ci utilise alors sa clé privée pour décoder le message.
  8. Dans le même temps, les deux parties génèrent la même clé maître (Master Key) finale via des procédés cryptographiques. De cette clé, ils peuvent en déduire une clé de session identique (et donc symétrique). Cette clé est régénérée régulièrement afin d’éviter les problèmes inhérents aux clés symétriques.
  9. Cette clé de session symétrique permet de chiffrer efficacement le trafic entre les deux entités, sans la surcharge imprimée par un chiffrement asymétrique.

Cette méthode prend avantage des deux approches : d’un côté, le chiffrement asymétrique permet, au travers d’un médium non sécurisé (Internet, …), de sécurisé les données échangées afin de générer dynamiquement, sans avoir besoin de l’échanger directement, une clé symétrique permettant de chiffrer un trafic important. Cette clé symétrique étant renouvelée régulièrement, elle ne peut être devinée facilement avec les moyens actuels.

 

Ce type de chiffrement, dit mutuel puisque chacun peut être authentifié à l’aide de son certificat, se retrouve généralement dans des applications nécessitant un niveau de sécurisation très pointu. Il est toutefois prévu que WebRTC, cette technologie dont nous avons déjà abordé dans ce blog précédemment (ici,  ou encore dans le cadre de notre formation WebRTC), chiffre le trafic temps-réel à l’aide de cette méthode via DTLS (Datagram Transport Layer Security), soit du TLS sur UDP.

Une version « allégée » de cette méthode est utilisée beaucoup plus couramment lors de l’accès à des sites Web sécurisés (une banque ou un site marchand, par exemple). Seul le serveur dispose dans ce cas d’un certificat, qui permet au client de certifier qu’il se connecte effectivement au bon site. Le client, lui, ne dispose pas de certificat, mais le fonctionnement reste globalement le même : la Pre-Master Key est toujours transmise (point 5) de manière sécurisée, le client disposant ici aussi de la clé publique du serveur, protégeant ainsi un des principaux secrets de la méthode. Une clé symétrique est générée de la même manière pour chiffrer la session entre le client et le serveur sécurisé.

Oui, mais…

Si ce chiffrement semble idéal en bien des points, il est judicieux de s’interroger sur les certificats en eux-mêmes : comment être sûr qu’un certificat appartient bien à une entité donnée ? Diverses méthodes existent, soit en faisant appel à une infrastructure centralisée (PKI ou Public Key Infrastructure), soit en utilisant un système décentralisé basé sur la création de réseaux de confiance, tel que le prône certaines technologies comme PGP (Pretty Good Privacy), mais également WebRTC !

Mais tout ceci est un sujet à part entière que nous aborderons prochainement dans un nouvel article ! So stay tuned !

Mise à jour (2013-03-01) :

Une erreur (récurrente) s’était glissée dans ce post. Le terme « chiffrage », s’il est accepté par l’académie française pour parler de ce sujet, n’est pas le terme français reconnu. « Chiffrement » doit être utilisé en lieu et place. Ces deux termes sont toutefois très proches, mais dans un souci de précision, la correction a été apportée à l’article. A noter que si « chiffrage » et « chiffrement » sont très proches, « cryptage » (et en particulier « décryptage ») a une toute autre signification, puisque ce terme est uniquement utilisé lorsqu’une personne n’ayant pas les bonnes clés tente de déchiffrer un message donné.

La terminologie dans le domaine de la sécurité : toute une histoire ;)

WebRTC : l’interopérabilité en ligne de mire !

12 février 2013 par nexcom

Depuis notre précédent article traitant de WebRTC, le framework a continué son évolution à un rythme régulier, notamment au travers de l’API PeerConnection (renommée RTCPeerConnection pour l’occasion) que nous avions déjà mentionnée précédemment. Cette API se précise de jours en jours et devient désormais parfaitement utilisable par les premières applications WebRTC. Attention toutefois : elle demeure encore dans un état de chantier avancé et est donc susceptible d’évoluer très rapidement !

Son support s’est également étendu : outre Google et son navigateur Chrome, dont même les versions « stables » classiques supportent cette API, Mozilla a rejoint le peloton de tête avec les versions de développement de Firefox, à savoir Aurora et ses nightlies. Le support de l’ensemble est encore très expérimental, mais les résultats actuels sont déjà probants.

Qu’en est-il de l’interopérabilité ? Les navigateurs continuent-ils de proposer des APIs préfixées (respectivement webkit-et moz-) ? Peuvent-ils toutefois fonctionner ensemble sur un même service ? La réponse à ces questions est simple et peut être résumée pratiquement en un mot : oui.

Oui, l’interopérabilité, malgré leurs différences d’implémentation, est possible Et a été prouvée récemment par Google et Mozilla qui sont parvenus à faire communiquer Chrome avec les versions de développement de Firefox. La démonstration utilisée est librement disponible pour quiconque souhaiterait vérifier ces dires !

De quoi rabattre les mauvaises langues qui doutaient que cela puisse être possible. Et une belle preuve de l’avenir de cette technologie, même encore balbutiante !

Qu’en est-il des autres navigateurs ?

  • Opera, fidèle à son habitude, attendra d’avoir une version mieux figée de l’API avant d’envisager l’intégrer à son navigateur phare.
  • Microsoft s’est lancé dans un fork de la technologie, sous des couverts de simplification pour les développeurs des futurs services.
  • Apple reste muet quant à une éventuelle implémentation du framework au sein de son navigateur, Safari.

Dans le cas de ces deux derniers, de nombreuses suppositions peuvent être exposées : tous deux peuvent avoir par exemple des intérêts à ne pas promouvoir trop fortement WebRTC, notamment à cause de leurs services respectifs, Skype et FaceTime. Mais toute conjecture est inutile : seul l’avenir pourra déterminer quel choix était le bon. Chacun des acteurs autour de WebRTC a des raisons d’agir comme il le fait.

Afin de démêler l’ensemble de ces sujets tant contextuels que techniques, NEXCOM Systems propose depuis 2013 une nouvelle formation WebRTC, au contenu pertinent : comprendre le cadre pour lequel WebRTC a été prévu, comprendre les tenants et aboutissants de chacun des acteurs, tout en abordant des aspects plus techniques de la technologie (APIs, transport, …). Cette formation WebRTC est prévue pour permettre à chacun de mieux cerner ce qui fera peut-être partie, demain, de notre environnement technologique quotidien. N’hésitez pas à nous contacter pour avoir plus d’informations !

World IPv6 Day : c’est aujourd’hui !

6 juin 2012 par nexcom

Il y a une année pratiquement jour pour jour, le 8 juin 2011, un événement similaire avait eu lieu, sous la forme d’une expérimentation de lancement d’une durée d’une journée. De grands noms de l’industrie avaient participés : Google, Facebook, Yahoo!, … Les résultats de ces tests ont prouvé qu’une partie non négligeable du réseau global, et en particulier de Websites majeurs, était capable de passer, sans encombre, à IPv6. Continue reading “World IPv6 Day : c’est aujourd’hui !” »

IPv6 arrive : préparons-nous !

5 juin 2012 par nexcom

Afin de succéder à IPv4, il est question de déployer l’Internet Protocol dans sa version 6 depuis de très nombreuses années maintenant. Des moyens importants ont été mis en œuvre afin de préserver autant que possible IPv4 (notamment au travers des NAT). Nous sommes toutefois arrivés à un point de non-retour : le pool d’adresses publiques IPv4 est désormais épuisé au niveau mondial. Continue reading “IPv6 arrive : préparons-nous !” »

IPv6 (9) : Transition vers IPv6 en SIP

par nexcom

La transition entre IPv4 et IPv6 se rapproche toujours un peu plus, et il convient de se préparer à aborder cette transition au mieux. Le cadre le plus intéressant à considérer ici dans le monde de la ToIP (Telephony over IP) se repose sur l’utilisation du protocole SIP (Session Initiation Protocol), majoritairement utilisé à l’heure actuelle et en voie de devenir toujours plus important à l’avenir. Le déploiement de IPv6 se fera progressivement, et il y aura obligatoirement une période plus ou moins longue pendant laquelle IPv4 cohabitera avec IPv6. Si IPv6 n’apporte aucun réel changement par rapport à IPv4 dans le fonctionnement général des réseaux, ces deux protocoles sont néanmoins incompatibles directement, et il est nécessaires de pouvoir effectuer une transition de la manière la plus transparente possible.

Continue reading “IPv6 (9) : Transition vers IPv6 en SIP” »

IPv6 (8) : Déploiements – par le fournisseur d’accès (partie 3)

par nexcom

Après avoir traité des approches hybrides (tunneling) puis compressives (mapping), ce dernier article va discuter du dernier type de options actuellement disponibles, sous la forme de solutions translatives allant faire la traduction entre les deux versions du protocole IP (protocol translation).

Continue reading “IPv6 (8) : Déploiements – par le fournisseur d’accès (partie 3)” »

IPv6 (7) : Déploiements – par le fournisseur d’accès (partie 2)

par nexcom

Au cours de la première partie, nous avions commencé à aborder les différentes options de déploiement IPv6 disponibles pour les opérateurs avec  les méthodes de type hybride/tunneling. Dans le présent article, nous allons poursuivre cette étude en observant une approche quelque peu différente, puisque tentant ici de rationaliser l’usage des  adresses IPv4 afin de limiter l’hémorragie et de pouvoir continuer à fournir un service IPv4 dans les années à venir tout en migrant progressivement vers IPv6.

Certaines de ces solutions, nous allons le voir, essaient de coupler l’aspect préservation avec l’aspect migration, mais il est souvent nécessaire de combiner ces approches avec d’autres protocoles de transition afin d’avoir et une solution de migration vers IPv6, et une solution de préservation d’adresses IPv4

Continue reading “IPv6 (7) : Déploiements – par le fournisseur d’accès (partie 2)” »

IPv6 (6) : Déploiements – par le fournisseur d’accès (partie 1)

par nexcom

Nous l’avons vu dans cet article sur les solutions à disposition des clients afin d’obtenir une connectivité IPv6, mais il s’avère désormais que la gestion des différentes problématiques, relative tant à la pénurie d’adresses IPv4 qu’à la migration vers IPv6, vont incomber en grande partie aux fournisseurs d’accès.

Les opérateurs disposent d’un large choix de solution, leur permettant de sélectionner la meilleure approche possible au regard de leur infrastructure et de l’approche qu’ils envisagent pour aborder ces problématiques. Au regard du nombre d’options possibles, nous allons exposer ces différentes solutions au travers de trois articles successifs, en abordant en premier lieu les solutions hybrides (tunneling) avant de traiter successivement les approches compressives et translatives.

Continue reading “IPv6 (6) : Déploiements – par le fournisseur d’accès (partie 1)” »

IPv6 (5) : Déploiements – par le client

par nexcom

Le risque de pénurie d’adresses IPv4 devient de plus en plus présent avec les mois qui s’écoulent. Des solutions temporaires avaient été apportées avec les NAT, mais il est désormais essentiel de préparer une migration la plus rapide possible vers IPv6 tout en devant gérer cette pénurie, ce qui ne facilite en rien le travail de transition IPv4-IPv6.

De (très) nombreuses solutions ont été imaginées et proposées ces dernières années afin de tenter d’apporter une solution efficace et (relativement) facile à mettre en œuvre afin d’assurer cette transition. Ce choix est une bonne nouvelle puisqu’il va permettre de choisir la méthode la plus appropriée au cas de figure considéré. Ce qui est malheureusement aussi une mauvaise nouvelle puisque cette débauche de solutions engendre un problème de taille : quelles sont les solutions optimales et pour quels cas de figure ?

Ces solutions peuvent être classées en deux écoles différentes : soit la transition est assurée majoritairement au niveau du client, soit cette transition est effectuée par le fournisseur d’accès. Nous commencerons par décrire les approches possibles au niveau des utilisateurs finaux (clients) avant d’aborder, dans un prochain article, les mécanismes offerts aux fournisseurs d’accès.
Continue reading “IPv6 (5) : Déploiements – par le client” »

IPv6 (4) : Adressage – méthodes de configuration

par nexcom

Nous avons précédemment discuté des notions de syntaxe et de classification des adresses IPv6. Il reste toutefois encore un sujet à aborder dans ce domaine, la question de l’adressage en lui-même. Il ne sera pas ici question d’effectuer un plan d’adressage, mais bel et bien des contraintes entourant la distribution et la confection des adresses IPv6 pour chaque entité du réseau.
Continue reading “IPv6 (4) : Adressage – méthodes de configuration” »

IPv6 (3) : Adressage – typage et classification

par nexcom

Depuis les débuts du protocole Internet (Internet Protocol ou IP), la plage complète d’adresses ont toujours été classifiées dans différents rôles et usages. Ces rôles ont évolués au fil du temps, et ont été remis à jour avec l’arrivée d’IPv6.

Continue reading “IPv6 (3) : Adressage – typage et classification” »

IPv6 (2) : Adressage – nomenclature et syntaxe

par nexcom

Les adresses IP majoritairement utilisées actuellement (IPv4) sont particulièrement bien connues et relativement faciles à retenir et utiliser. IPv6 introduit toutefois une certaine complexité dans ces adresses, celles-ci étant sensiblement plus longues, mais aussi devant respecter des règles stricts que nous allons détailler au sein de cet article.
Continue reading “IPv6 (2) : Adressage – nomenclature et syntaxe” »

IPv6 (1) : IPv4, IPv6 et problématiques

par nexcom

Le protocole IP, ou Internet Protocol, permet la création d’un réseau offrant une connectivité entre des entités distantes au sein d’un réseau étendu, voire global (Internet). Ce protocole se repose sur l’utilisation d’adresses afin de localiser les terminaux et entités sur le réseau. Ces adresses s’apparentent, dans leur usage, aux adresses attribuées à chaque lieu de résidence et habitation : sans cette adresse, il devient difficile, voire impossible, de recevoir les services courants (courrier, livraisons …). En théorie, les adresses du protocole IP permettent un usage similaire, définissant une adresse unique pour chaque entité sur le réseau, et permettant ainsi à cette entité de réclamer des services ou de pouvoir être contactée. Continue reading “IPv6 (1) : IPv4, IPv6 et problématiques” »

VoIP & NAT (11) : IPv6 – Good Bye, NAT ?!

par nexcom

Dernier article de notre série relative à la traversée de NAT, nous ne pouvions pas ne pas discuter un peu plus en détail de l’impact qu’aura probablement, à terme, le protocole Internet (Internet Protocol) dans sa version 6.

Continue reading “VoIP & NAT (11) : IPv6 – Good Bye, NAT ?!” »

VoIP & NAT (10) : Une approche pratique à la traversée de NAT

par nexcom

Au sein de notre série d’articles relatifs à la traversée de NAT, nous avons abordé, dans cet autre billet, une approche courante envisagée par les acteurs de l’industrie : les ALG et SBC. Nous en avions conclu que cette approche, si elle n’est pas dénuée de bon sens, est sujette principalement à deux gros problèmes :

  • Les implémentations « grand public » des ALG sont le plus souvent lacunaires, engendrant plus de problèmes qu’elles en résolvent.
  • Les SBC requièrent des compétences et connaissances coûteuses les réservant à certains types d’environnements.

Il était par conséquent nécessaire de combler le vide qui caractérisa la traversée de NAT pendant longtemps, avant que les standards commencent à se développer sérieusement. Des approches ont été envisagées par les différentes implémentation de serveurs SIP au fil du temps, que ce soit de soft switch/IPBX complets (Asterisk, FreeSWITCH) ou de « simples » proxys. Nous allons nous attarder ici particulièrement sur ce dernier cas, et en particulier sur OpenSIPS, un proxy SIP particulièrement performant, modulaire et évolutif.

Continue reading “VoIP & NAT (10) : Une approche pratique à la traversée de NAT” »

VoIP & NAT (9) : ALG/SBC – intérêts et limites

par nexcom

Lors de nos différents articles relatifs aux solutions de traversée de NAT, nous avons détaillés les approches proposées par l’IETF (received/rport, SIP-OUTBOUND, STUN, TURN, ICE) et étant par conséquent normalisées. Ces protocoles, s’ils offrent ensemble une approche complète, efficace et évolutive, sont malheureusement pour la plupart très récents : les acteurs de l’industrie (opérateurs, intégrateurs, …) ont dû trouver des solutions qui leur ouvraient l’utilisation de SIP/RTP dans le cadre de la voix sur IP. Plusieurs solutions existent à ce niveau, mais la plus commune à l’heure actuelle est caractérisée par les ALG (Application Level Gateways) et, de manière plus spécifique, les SBC (Session Border Controllers).

Continue reading “VoIP & NAT (9) : ALG/SBC – intérêts et limites” »

VoIP & NAT (8) : les élection ICE

par nexcom

Dans notre précédent article, nous avons commencé à discuter des mécanismes régissant le protocole ICE, notamment lorsque le processus s’initie : récupération des couples adresse/port par lesquelles une extrémité sera en mesure d’émettre une requête, puis les échanger avec la partie distante jusqu’à ce que l’un comme l’autre disposent de l’ensemble des informations. Cette étape est essentielle, mais, comme dans la réalité, lorsque des candidats sont définis, il faut encore, par la suite, les élire de manière à définir lequel sera choisi au final. Ce second article sur ICE traite de ce sujet en particulier : la sélection d’un candidat au travers de tests de connectivité.

Continue reading “VoIP & NAT (8) : les élection ICE” »

technicolor
broadpeak
sagemcom
t&t
Thales
CGI
sierra_wireless
orange
adventiel
capgemini
athemium
BureauVeritas
nokia-logo
SFR
ESR Groupe H69
Icosnet
akio
intel
actility
AXIANS
CMB ARKEA
XURA 90H
NIJI
SopraSteria
setelia
davidson
ineo
HubOne
image_et_reseau
Monaco Telecom_550x550
alten
VA SOLUTIONS2
neosoft
Sofrecom
Modis
TufigoRapidex
Deltadore
NETENSIA
cirpack
Bouygues E&S
Astellia