Archives par mois : juin 2012

World IPv6 Day : c’est aujourd’hui !

6 juin 2012

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

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

5 juin 2012

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)

5 juin 2012

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)

5 juin 2012

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)

5 juin 2012

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

5 juin 2012

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

5 juin 2012

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

5 juin 2012

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

5 juin 2012

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

5 juin 2012

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 ?!

5 juin 2012

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

5 juin 2012

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

5 juin 2012

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

5 juin 2012

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” »

VoIP & NAT (7) : les candidats ICE

5 juin 2012

ICE, ou Interactive Connectivity Establishment, apporte un niveau d’abstraction aux protocoles STUN et TURN décrits dans les articles précédents (respectivement ici et ). Alors que beaucoup de solutions, et STUN et TURN en font partie lorsqu’ils sont utilisés indépendamment, plaçaient l’intelligence au niveau des serveurs (ceux-ci détenant le maximum d’informations), ICE fait le pari inverse : intégrer cette intelligence au niveau du client. En effet, comme le discutera cet article ainsi que le suivant, les serveurs ne servent désormais que d’outils permettant au client d’apprendre et de connaître son environnement.

Continue reading “VoIP & NAT (7) : les candidats ICE” »

VoIP & NAT (6) : TURN – STUN++ ?

5 juin 2012

Lors de notre précédent article, nous avions discuté de STUN, dont les fonctionnalités offrent déjà une gamme de services intéressantes. Il avait cependant été question que cette traversée de NAT, si elle est efficace, n’est pas exhaustive, puisque seuls les NAT dont les associations sont créées indépendamment de la destination sont supportés. Malheureusement, beaucoup de NAT à l’heure actuelle ne fonctionnent pas de cette manière, étant bien souvent des NAT symétriques ou, plus manière plus générique, dépendants de la destination. TURN (Traversal Using Relays around NAT) a été étudié comme un extension à STUN venant particulièrement combler ce problème en proposant une approche se basant sur un serveur relai servant de pont entre les deux parties.

Continue reading “VoIP & NAT (6) : TURN – STUN++ ?” »

VoIP & NAT (5) : STUN – la base

5 juin 2012

Dans cet article, nous discutions des méthodes permettant la traversée de NAT des messages SIP, tant pour les réponses que les requêtes. Nous avons mentionné une méthode permettant de maintenir les différentes associations au niveau du NAT valides en utilisant le protocole STUN. Toutefois, qu’est-ce que STUN et comment fonctionne-t-il ?

Continue reading “VoIP & NAT (5) : STUN – la base” »

VoIP & NAT (4) : SIP requests et NAT

5 juin 2012

Lors de notre dernière incursion dans les méandres des NAT en VoIP, nous avions discuté de la méthode envisagée pour permettre aux réponses SIP (200 OK par exemple) d’atteindre leur cible. Il avait toutefois été noté qu’il était, en théorie, impossible de réutiliser ces informations dans le but d’acheminer des requêtes SIP (INVITE par exemple). L’IETF a de ce fait imaginé une méthode spécifique permettant aux requêtes distantes de contacter un client situé derrière un NAT : SIP-OUTBOUND. Alors que les attributs received et rport modifient les entêtes Via, cette méthode s’occupe d’altérer les informations contenues dans le Contact afin de pouvoir acheminer la requête correctement. Mais si elle se limitait à ceci, elle n’aurait que peu d’intérêts.

Continue reading “VoIP & NAT (4) : SIP requests et NAT” »

VoIP & NAT (3) : SIP replies et NAT

5 juin 2012

Dans la continuité des articles relatifs au NAT en ToIP publiés précédemment (introduction sur les NAT et terminologie des NAT), examinons tout d’abord le problème du point de vue de SIP, ainsi que les méthodes de résolution pouvant s’appliquer.

Lorsque SIP (Session Initiation Protocol) a été initialement spécifié aux alentours des années 2000 (mars 1999 pour être exact), il est intéressant de noter que, si les NAT existaient déjà et étaient déployés de manière conséquente, il n’a jamais été question de leur traversée par le protocole. De l’aveu même de ses auteurs, le protocole n’est pas pensé pour géré le NAT :

« A host behind a network address translator (NAT) or firewall may not be able to insert a network address into the Via header that can be reached by the next hop beyond the NAT. Use of the received attribute allows SIP requests to traverse NAT’s which only modify the source IP address. NAT’s which modify port numbers, called Network Address Port Translator’s (NAPT) will not properly pass SIP when transported on UDP, in which case an application layer gateway is required. When run over TCP, SIP stands a better chance of traversing NAT’s, since its behavior is similar to HTTP in this case (but of course on different ports). »

Pire encore, la seule fonctionnalité qui lui permettrait de gérer ce problème partiellement s’avère lacunaire, puisqu’elle ne prend en considération que l’adresse et non le port. Mais pourquoi SIP a-t-il autant de problèmes à traverser les NAT ? Tout simplement car SIP, en tant que protocole applicatif, transport ses propres adresses et ports au sein de ses messages de manière à établir des sessions entre deux entités. Toutefois voici ce qui se passe réellement lorsqu’une requête SIP traverse un NAT :

 

Lorsque le client émet une requête à destination de son proxy SIP (1), il forme son message SIP en utilisant les adresses et ports dont il a connaissance, c’est-à-dire des adresses privées, en règle générale. Ces informations correspondent pour le moment aux entêtes TCP/IP permettant le routage des paquets vers leur destination. Toutefois, lorsque le message va avoir traversé le NAT (2), ce dernier va modifier les entêtes TCP/IP des paquets afin que les réponses puissent aboutir et pointer vers l’adresse, non plus du client (privée et inaccessible depuis l’extérieure), mais publique. Malheureusement, le NAT ne fonctionnant qu’au niveau du réseau (TCP/IP), il n’est pas en mesure de modifier le contenu du message SIP en tant que tel. De ce fait, aucune réponse SIP ne pourra aboutir correctement.

Dès lors, comment procéder à la résolution de ce problème au niveau SIP ? Les auteurs de la spécification originelle avaient envisagé une gestion lacunaire des réponses SIP (par l’entête Via) au travers d’un attribut received. Lorsqu’un serveur reçoit une requête, il définit cet attribut en y associant l’adresse par laquelle la requête a été émise. Puisqu’il réceptionne la requête modifiée du NAT, il est en mesure de connaître l’adresse à laquelle il doit envoyer les réponses à la requête. Toutefois, comme le suggère notre précédent post, il manque une composante importante afin que les réponses soient acheminées correctement : le port !

Ce manque a été comblé en 2003 avec l’introduction d’un nouveau paramètre au champ Via : puisque l’adresse est récupérée dans un attribut received, pourquoi ne pas stocker le port de manière similaire. Cette extension au protocole SIP rajoute par conséquent un attribut rport (pour received port) qui permet de stocker, en plus de l’adresse, le port par lequel la requête a été émise du NAT. L’ajout de cette fonctionnalité permet l’introduction du concept de réponse symétrique (symmetric response) qui réutilise systématiquement le même couple adresse/port pour émettre et recevoir.

Client SIP :

INVITE sip:ua2@nexcom.fr SIP/2.0

Via: SIP/2.0/UDP 10.0.0.1:4540;rport;branch=Kkjshdyff

 

Proxy SIP :

INVITE sip:ua2@nexcom.fr SIP/2.0

Via: SIP/2.0/UDP proxy.nexcom.fr;branch=Kkjsh77

Via: SIP/2.0/UDP 10.0.0.1:4540;received=123.4.56.78;rport=9988

;branch=Kkjshdyff

 

Malheureusement, ces paramètres ne s’appliquent qu’aux réponses (par exemple 180 Ringing), mais ne permettent pas, par leur conception, d’être utilisés en dehors de ce cadre, notamment pour acheminer des requêtes venant d’un utilisateur distant souhaitant contacter le client. Comme nous en discuterons, certaines implémentations ont contourné ce problème en stockant par exemple ces valeurs de manière persistante afin de les réutiliser dans d’autres cas de figures (ce qui est en soi relativement malin). Toutefois, ce genre de solution ne respectent pas le cadre classique des standards, qui définissent une méthode spécifique pour ce cas précis, et qui sera détaillée prochainement dans un nouvel article : la spécification SIP-OUTBOUND !

Stay tuned !

neosoft
CMB ARKEA
adventiel
athemium
VA SOLUTIONS2
XURA 90H
Thales
sagemcom
engie-ineo
Lomaco
AIRBUS
SFR
technicolor
akio
setelia
la poste
Modis
ESR Groupe H69
CGI
HubOne
BureauVeritas
AXIANS
alten
cirpack
image_et_reseau
NIJI
Motorola
intel
SII
Monaco Telecom_550x550
econocom
t&t
Icosnet
Bouygues E&S
capgemini
DCNS
Viibe
axione
Sofrecom
nokia-logo
orange
Groupama-logo
Deltadore
ADP
GFI
SopraSteria
sierra_wireless
DGAC
Keolis
assystem-logo
broadpeak
Extia
Italtel
Astellia
NETENSIA
iagility
actility
SNCF_2011
davidson
Savelec
TuffigoRapidex