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.

Cette transition a été abordée en détails par les organismes de standardisation, IETF en tête, afin d’apporter une réponse valable à cette problématique dans le cadre de SIP. La spécification RFC 6157 décrit les mécanismes nécessaires au bon déroulement de cette transition en abordant les divers cas de figure à considérer : entre les équipements, on parlera par la suite de User Agents ou UA dans le cadre de SIP, dits dual-stack supportant les deux versions simultanément (la situation idéale) et les équipements strictement IPv4 ou IPv6, les combinaisons sont nombreuses. Il y a plusieurs points à noter à l’heure actuelle

  •  De nombreux UA SIP ne supportent actuellement que IPv4, particulière parmi les applications clientes.
  • Certains UA SIP ne supportent, ou ne supporteront, que IPv6, soit parce qu’il ont été développé avec cette approche en tête, soit pour cause de pénurie d’adresses IPv4 lui imposant de fonctionner en IPv6.
  • Les UA dual-stack doivent avoir la capaciter, dans le cadre d’applications clientes, quel protocole utilisé (v4 ou v6). Ce sont aussi les seuls, dans le cadre de serveurs SIP (proxy ou IPBX) a pouvoir effectuer cette transition dynamiquement entre UA IPv4 et UA IPv6.

Par définition, des UA ne fonctionnant qu’en IPv4 ou IPv6 ne pourront pas communiquer directement avec des UA utilisant l’autre version du protocole, leur imposant de transiter par des entités dual-stack. Afin de gérer cette problématique, il est possible de considérer deux situations différentes, la première liées à la gestion de la signalisation (le transport des informations de session d’un terminal à l’autre) et au transport des flux multimédias audio et/ou vidéo servant à la communication.

La signalisation

Afin de gérer la signalisation entre deux entités incompatibles (la figue ci-dessus suggère des terminaux, mais des serveurs peuvent parfaitement se retrouver dans la même situation), il est nécessaire de disposer des éléments suivants :

  • Un système d’exploitation dual-stack supportant simultanément IPv4 et IPv6, soit la majorité des systèmes d’exploitation relativement récent.
  • Une machine disposant d’une connectivité IPv4 et IPv6, que ce soit sur deux interfaces différentes ou non (il est parfaitement possible d’envisager un réseau dual-stack sur lequel repose des entités single-stack).
  • Un service SIP (proxy, IPBX) dual-stack, pouvant être configuré de manière à gérer efficacement les requêtes. Il devra par conséquent être en mesure de traiter à la fois les requêtes en provenance de clients IPv4, et en provenance de clients IPv6, tout en effectuant la transition entre les deux.

Dans le cadre d’une infrastructure similaire à celle exposée ci-dessus, voici ce qu’il est censé se passer lors d’échanges entre des UA incompatibles :

  • L’UA IPv4, qui peut être un terminal ou un autre proxy SIP ne supportant que l’IPv4, émet une requête pour une destination ne supportant que l’IPv6 (terminal ou serveur SIP). Afin que cette destination soit en mesure de comprendre les informations qu’elle reçoit, la requête doit au préalable passer par une entité dual-stack, ici le proxy dual-stack, qui va se charger de transformer la requête en adéquation avec le réseau de destination. Ce proxy ne pourra pas se retirer du chemin de signalisation puisqu’il prend à sa charge la modification des requêtes.
  • Le proxy dual-stack a modifié la requête en conséquence et nous pouvons remarquer que, afin que les requêtes suivantes soient routées de manière correct, ce proxy doit ajouter deux entêtes Record-Route qui permettront d’acheminer par la suite les autres requêtes. La première information entrée correspond au réseau d’origine, et le second au réseau de destination.
  • Ces informations permettent à l’UA IPv6 de router ses requêtes correctement, en utilisant les informations de routage dans l’ordre : tout d’abord la route IPv6, puis la route IPv4 lorsque la requête aura traversé le proxy dual-stack.
  • L’UA d’origine se crée de la même manière une route vers sa destination en prenant ces mêmes informations en sens inverse : l’adresse IPv4 d’abord, puis l’adresse IPv6 par la suite, lorsque la requête aura transité au travers du proxy dual-stack .

Il est intéressant de noter qu’une telle manipulation n’est nécessaire que si des adresses IP sont utilisées pour acheminer les requêtes. Dans le cadre d’une utilisation judicieuse d’un DNS correctement configuré, il est possible pour l’UA IPv4 de récupérer, à partir du nom de domaine, l’adresse IPv4 (enregistrement A). Le même phénomène se produira pour l’UA IPv6, qui lui récupèrera une adresse IPv6 (enregistrement AAAA). Dans ce cas de figure, un unique entête Record-Route est nécessaire, chaque entité ne pouvant récupérer que les adresses dont ils peuvent avoir connaissance (IPv4 et IPv6).

Dès lors, il existe essentiellement deux points ayant une importance particulière ici :

  • Une entité dual-stack doit impérativement exister sur le trajet de la requête, de manière à fournir les bonnes informations aux deux UA incompatibles.
  • Cette entité doit impérativement rester sur le chemin de la signalisation, sans quoi les deux UA ne pourront plus continuer à envoyer avec succès leurs requêtes subséquentes (comme par exemple les requêtes de terminaison, de type BYE ou CANCEL).

Les flux médias

La gestion des flux multimédias dans ce genre d’environnement peut poser de sérieux problèmes. En effet, SIP utilise une méthode de type offer/answer afin d’établir une session entre les deux terminaux. Il permet en effet d’échanger les informations de connectivité (protocole, adresse, port, codecs, …) afin de pouvoir établir la communication. Malheureusement, dans un environnement dans lequel cohabitent IPv4 et IPv6, ces informations de session ne sont plus pertinentes, les terminaux n’étant pas en mesure de les comprendre (sauf implémentations dual-stack, bien entendu, ce dernier étant en mesure de passer d’une version à l’autre dynamiquement en fonction des données reçues).

Il est par conséquent nécessaire de prévoir une méthode permettant de continuer à faire transiter les informations entre ces entités de manière la plus transparente possible. La résolution de ce problème va passer par l’utilisation de mécanismes déjà connu au sein d’une autre problématique : la traversée de NAT par l’usage de serveurs relais TURN (Traversal Using Relays around NAT). En effet, en appliquant ce protocole, défini principalement au sein des spécifications RFC 5389 (STUN, ou Session Traversal Utilies for NAT, protocole dont TURN est l’extension) et RFC 5766, il va être possible de faire communiquer de telles entités indirectement au travers du serveur relai.

Le protocole TURN, devenu un standard dans le cadre de la traversée de NAT, a de grandes chances d’être largement déployé au sein des infrastructures futures. De ce fait, et au lieu de les maintenir dans leur rôle premier de traversée de NAT, il est intéressant d’étendre leurs attributions en les paramétrant de telle sorte qu’ils soient en mesure d’effectuer tout type de translation d’adresse. De manière simplifiée, un serveur TURN va en effet agir de manière similaire à un NAT muni d’une ALG (Application Level Gateway) puisqu’il effectuer une translation d’adresse, à l’origine de IPv4 en IPv4, en fournissant de nouvelles données (adresses et ports).

Cet usage peut toutefois être étendu, en ajoutant des mécanismes liés à IPv6, en une translation similaire, mais incluant cette fois la possibilité d’effectuer des transferts entre versions du protocole IP : de IPv4 vers IPv6, de IPv6 vers IPv4 et de IPv6 vers IPv6 (même si ce dernier cas n’est normalement pas utile, les deux entités IPv6 n’ayant probablement plus besoin de passer par un relai pour communiquer). La spécification RFC 6156 (TURN-IPV6), dont les mécanismes sont décrits au sein de la RFC 6145, prévoit une extension à TURN prenant en considération ces différents cas de figure.

Il est intéressant de noter que l’usage de ICE (Interactive Connectivity Establishment, RFC 5245, voir à ce sujet nos articles sur ICE dans le cadre de la problématique de la traversée de NAT) permet d’automatiser la sélection de la meilleure connexion entre deux entités, en automatisant notamment l’usage du protocole STUN/TURN. Dans le cadre d’une communication entre des entités IPv4 et IPv6 pures, ICE détectera, par l’usage de tests de connectivité, qu’il est impossible de contacter l’UA distant à l’aide d’autres mécanismes qu’un serveur relai (TURN) et imposera l’usage de celui-ci afin d’établir la communication. On sort ici du cadre original de ICE (la traversée de NAT) en étendant sa portée à une autre problématique, globalement similaire puisqu’impliquant une translation d’adresse.

En considérant le fonctionnement classique d’ICE, il est possible de représenter ce qu’il se produit lors de son utilisation dans le cadre qui nous intéresse ici. La représentation qui en est faite ici est volontairement simplifiée, le fonctionnement d’ICE est sensiblement plus complexe.

  • Les candidats ICE, soit les couples adresse/port pouvant être utilisés ultérieurement lors de la communication, sont récupérés, ce qui implique de demander par la même occasion des candidats publics via STUN (dans le cadre d’IPv4, l’adresse de son NAT), ainsi que les candidats relayés au travers du serveur TURN.
  • Le serveur STUN/TURN répond avec les informations demandées (adresse publique et relayée).
  • Les candidats de l’UA sont envoyé, via la signalisation SIP, à son destinataire.
  • L’UA de destination va appliquer le même procédé qui est décrit en 1, à la différence que la requête sera ici effectuée en IPv6.
  • Les réponses sont envoyées de la même manière. Il est à noter que l’adresse publique d’un hôte IPv6 sera potentiellement identique à son candidat local (privé).
  • L’UA IPv6 transmet ses propres candidats à l’UA IPv4 via la signalisation SIP.
  • Disposant de l’ensemble des informations, l’émetteur de la requête peut effectuer les tests de connectivité sur chaque couple de candidats de manière à définir lequel utiliser ultérieurement lors de la communication. Certains candidats proposés par l’UA IPv6 disposent cependant d’une adresse IPv6 que l’UA IPv4 n’est pas en mesure de comprendre, entraînant l’échec de ces candidats.
  • L’adresse public du destinataire, étant IPv6, échouera aussi.
  • Seul le passage par le candidat relayé permettra de contacter avec succès le destinataire.
  • Avec cette réponse positive, l’émetteur de la requête dispose d’un lien de connexion fonctionnel lui permettant d’initier la communication, et de faire transiter les flux RTP au travers du relai.

ICE permet donc de s’affranchir de la réflexion déterminant quel service utiliser afin d’atteindre sa destination. De ce fait, il apporte un niveau d’abstraction appréciable permettant un fonctionnement le plus transparent possible.

En conclusion

La gestion de la signalisation SIP relève d’un raisonnement logique, tiré directement de la spécification SIP : si la requête n’entre et ne sort pas par la même adresse, de multiples entêtes Record-Route doivent être introduit de manière à acheminer les messages correctement. Seul l’usage du nom de domaine permet ici de s’affranchir de cette usage, à la seule condition que les serveurs DNS soient configurés de manière à fournir les informations nécessaires tant en IPv4 (enregistrement A) qu’en IPv6 (enregistrement AAAA).

L’approche proposée par cette spécification au niveau de la gestion des médias est tout à fait intéressante. Elle se repose en effet sur une observation simple : le transition entre IPv4 et IPv6 peut s’apparenter au traitement classique devant être appliqué à la traversée de NAT. De ce fait, les outils classiques peuvent être réutilisés, au travers d’adaptations relativement mineures de leur fonctionnement habituel, notamment ici par l’usage de serveurs relais, les seuls en mesure de traduire des adresses d’une version à une autre (4-to-6, 6-to-4, …). Mieux encore, il est parfaitement possible de refaire usage de ICE, celui-ci permettant d’automatiquement sélectionner le meilleur lien possible entre deux UA, soit ici obligatoirement via le serveur relai.

Les différents tests d’implémentation effectués par nos soins démontrent qu’il est relativement aisé, à l’aide des solutions disponibles actuellement, d’offrir un niveau de service similaire à ce que cette RFC 6157 propose, permettant d’offrir simplement et facilement une transition IPv4-IPv6. L’usage des standards permet toutefois de garantir l’évolutivité de la solution, ce qui n’est pas obligatoirement le cas d’une approche pratique à l’heure actuelle.