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.

IP version 4

Depuis les origines des réseaux IP, la version 4 du protocole (IPv4) est majoritairement utilisée. Datant de septembre 1981 (30 ans en septembre 2011 !), il se repose sur une base d’adresses codée sur 32 bits (ou BInary digiTS), lui permettant de fournir environ 4.3 milliards d’adresses uniques différentes (232). Formatée pour l’esprit humain sous la forme de quatre blocs décimaux compris entre 0 et 255 (p.ex. 192.0.255.76), elles sont distribuées par les fournisseurs d’accès à chaque entité souhaitant se connecter au réseau.

Les technologies d’accès ont évolué régulièrement depuis les débuts d’Internet. En France notamment, le réseau d’accès est majoritairement constitué de lignes de cuivre issues du réseau téléphonique commuté (RTC), que ce soit au travers de modem (MOdulator/DEModulator) 56k puis par les technologies DSL (Digital Subscriber Line, notamment l’Asymmetric DSL ou ADSL dans le cadre des particuliers). Ces réseaux d’accès ont évolués jusqu’à proposer à l’heure actuelle des accès par fibre optique (FTTx, ou Fiber To The Home/Building/Network/…), mais aussi les réseaux d’accès mobiles via l’usage des réseaux 3G, 3G+ et à l’avenir 4G.

Ces réseaux d’accès ne sont pas spécifiques à IPv4, mais leur démocratisation et leur déploiement à grande échelle a engendré une consommation effrénée de la plage d’adresse disponible. Entre les accès « fixes » (ADSL), les accès mobiles (smartphones, …), chaque point d’accès occupant une adresse IP, le stock d’adresse a rapidement été menacé de la pénurie. Cette problématique a nécessité l’usage de solutions permettant de résoudre ces problèmes : l’usage de NAT (Network Address Translation) a été préconisé à court et moyen terme de manière à limiter autant que possible la consommation d’adresse (pour plus de détails), avec comme objectif à long terme le déploiement d’une version révisée du protocole Internet : IP version 6 ou IPv6.

IP version 6

Le protocole Internet dans sa version 6, ou IPv6, adresse le principal problème touchant IPv4 : la pénurie d’adresses. En effet, avec des adresses codées non plus sur 32 bits mais sur 128, IPv6 offre une quantité d’adresses infiniment plus conséquente que son prédécesseur, proposant du même fait une solution durable au problème touchant IPv4. Avec ses 2128 ou 3.4×1038 adresses, il devient pratiquement impossible de quantifier au niveau humain la quantité d’adresses disponibles : avec plus de 667 000 milliards d’adresses IP par millimètres carrés de superficie terrestre, la probabilité d’épuiser ce stock semble bien lointain ! Cette quantité d’adresses permet néanmoins de considérer à nouveau des terminaux globalement accessibles, n’étant plus situés derrières des NAT.

S’il résout cette problématique, IPv6 n’est toutefois pas exempt de désavantages, notamment liés à la surcharge (overhead) imprimé par ses adresses sur les paquets IP classiques. En effet, chaque paquet contenant l’adresse IP de la source et de la destination, et celles-ci occupant quatre fois plus de place (en binaire) que les adresses IPv4, la surcharge s’avère rapidement non négligeables. Cet impact a été pris en considération lors de la spécification de cette version du protocole. Avec l’expérience acquise sur son prédécesseur, il a été possible de supprimer certains entêtes de manière à alléger autant que possible le nouveau protocole. De manière à observer cet impact, comparons les blocs d’entêtes pour chaque version du protocole :

Avant d’aborder les entêtes IPv6, observons tout d’abord les informations gérées par IPv4. D’une taille minimale fixe de 20 octets (bytes), ces entêtes contiennent toutes les informations nécessaires pour faire transiter les paquets au travers du réseau. Toutefois, IPv4 ne dispose pas d’une structure optimisée, et certains entêtes sont soit rarement utilisés, menant à leur abandon pur et simple, soit redondant et pouvant être améliorés.

On s’aperçoit immédiatement d’une différence fondamentale entre ces deux entêtes, représentée par ces deux blocs d’adresse, occupant chacun 16 octets. Ne serait-ce que par le stockage des adresses source et destination, la taille de l’ensemble des entêtes dépasse déjà de 12 octets la taille minimale des entêtes IPv4, puisque à elles seules, ces adresses occupent 32 octets ! La taille fixe des entêtes IPv6 étant de 40 octets, le reste des informations tiens désormais sur 8 octets seulement, contre 12 précédemment. L’usage de l’espace disponible a été optimisé en ne maintenant qu’un nombre limité et essentiel d’entêtes :

  • Version, dont la valeur passe ici de 0100 (4 en notation binaire) à 0110 (6).
  • Type of Service, ici connu sous le nom de Traffic Class, utilisé pour DiffServ (Quality of Service ou QoS) et Explicit Congestion Notification (ECN).
  • Time to Live (TTL), sous la forme de l’entête Hop Limit ayant sensiblement le même rôle, celui d’éviter des boucles de routage infinies. Toutefois, alors que IPv4 utilise un décompte lié au temps, IPv6 se repose sur le nombre de sauts effectués (passages de routeurs). Par extension, cette méthode n’est plus sujette aux questions de latence, et se focalise exclusivement sur sa fonction première.
  • Protocol, qui devient ici Next Header, représentant le type de contenu du paquet (p.ex. IPSec utilise les identifiants 50 et 51 pour ESP et AH respectivement).
  • Source Address, passant de 32 à 128 bits.
  • Destination Address, passant ici aussi de 32 à 128 bits.

Il est intéressant de noter qu’IPv6, au contraire de son prédécesseur, a éliminé certains entêtes en modifiant sensiblement son comportement. Alors qu’IPv4 intègre les options au sein des entêtes, entraînant une taille aléatoire stockée dans l’entête IHL, IPv6 définit une taille fixe (correspondant à la taille minimale de l’entête) et considère que tout le reste fait partie du contenu (payload), options comprises. Cette approche permet à IPv6 de bénéficier de certains éléments intéressants :

  • Il peut s’affranchir de l’entête IHL et ne garder qu’une taille de contenu (payload length).
  • Cette approche réduit les calculs à effectuer : avec IPv4, pour connaître la taille du contenu, il était nécessaire de soustraire l’IHL de la taille totale du paquet.
  • Les options étant gérées en dehors de l’entête rend le protocole facilement adaptable à de nouvelles situations via des extensions (évolutivité modulaire).

Par sa conception même, un paquet IPv6 n’est plus censé être fragmenté. De ce fait, l’entête d’identification devient inutile. Par extension, les flags D (Don’t Fragment) et M (More Fragment) peuvent être abandonnés pour les mêmes raisons, ainsi que le fragment offset. En supprimant ces entêtes d’IPv6, il est possible de gagner des quatre octets dont il a été question précédemment. Dans le cas où une fragmentation demeure nécessaire, la spécification définit une extension dédiée à cette problématique.

Un dernier entête disparait avec IPv6 : header checksum. Il permet, au sein d’IPv4, de déterminer si une erreur s’est produite lors de la transmission s’est produite, altérant les informations IP. Toutefois, par la conception même du protocole IP, cette tâche devrait échoir à d’autres protocoles, notamment de couche supérieure (TCP/UDP). De plus, si la protection de l’entête IP doit persister, le protocole AH (tiré d’IPSec) permet de s’en assurer, rendant l’usage du header checksum obsolète.

La dernière différence d’importance entre IPv6 et IPv4 repose dans leur gestion respective de la qualité de service (QoS). Avec son nouvel entête Flow Label, et couplé aux fonctions de QoS de Traffic Class, IPv6 est en mesure de fournir une QoS réellement efficace, et non plus basée sur une notion de best effort sur laquelle IPv4 fonctionne intégralement. Le Flow Label permet de plus d’offrir, au travers d’usages particuliers, des fonctionnalités supplémentaires, par exemple liées à la protection contre certains types d’attaques.

Malgré ces modifications dans le comportement du protocole, l’usage d’IPv6 n’apporte en soi aucune différence d’utilisation par les terminaux par rapport à son prédécesseur. Toutefois, du point de vue de l’infrastructure, les ajouts et avantages d’IPv6 sont clairement non négligeables. Il est intéressant de noter que l’usage d’IPv6 peut s’avérer particulièrement probant dans le cadre de certaines applications, notamment en voix sur IP.

VoIPv6 : la voix sur IPv6

Les apports pratiques d’IPv6 dans le cadre d’échanges classiques sont minimes. En effet, si l’on considère une utilisation client-serveur standard (entre un navigateur Web et un serveur Web par exemple), IPv4 offre une expérience d’utilisation tout à fait satisfaisante. Il existe toutefois des cas dans lesquels l’infrastructure IPv4 actuelle pose problème : les applications nécessitant des échanges en temps réel directement entre deux entités, telles que la voix sur IP dans le cas qui nous intéresse ici.

De telles applications, dites peer to peer (P2P) puisque tentant de connecter deux terminaux directement, vont rencontrer un problème en IPv4 sous la forme des NAT (Network Address Translators) qui ne permettent pas aux terminaux d’être globalement accessibles. IPv6 résout ce problème en supprimant l’usage des NAT et en offrant à nouveau cette connectivité globale : chaque terminal pouvant disposer de sa propre adresse unique, il devient possible de les faire communiquer entre eux directement, sans intermédiaire, dans une relation peer to peer authentique.

De ce simple fait, la VoIP ne pourra que bénéficier du passage à IPv6. En y ajoutant les avantages liés à la gestion exhaustive de la qualité de service (QoS) ainsi que les éventuelles extensions pouvant venir compléter et affiner le comportement d’IPv6, les avantages, dans ce cadre précis mais par extension à toutes les applications P2P, apportent une réelle plus-value qu’il serait dommageable de négliger. Toutefois, il est nécessaire de prendre en considération la surcharge engendrée par IPv6 : le couple IPv4 et UDP utilisé jusqu’à maintenant demandait 28 octets d’entêtes (20 pour IPv4, 8 pour UDP). IPv6 double pratiquement cette valeur (48 octets) pour, au final, un résultat globalement similaire à ce qui existe aujourd’hui.

De ces observations ressortent plusieurs problématiques :

  • La surcharge engendrée par IPv6 est-elle supportable pour les infrastructures actuelles ? Va-t-elle engendrer une diminution perceptible de qualité ?
  • Le manque d’interopérabilité entre IPv4 et IPv6 implique, le déploiement progressif d’IPv6 progressant, de devoir faire cohabiter IPv4 et IPv6 au sein d’une même infrastructure. Comment cette transition est-elle gérée en VoIP ?

Ces sujets, et bien d’autres, seront traités ultérieurement au sein d’articles spécifiques !