Depuis quelques années et surtout depuis quelques mois/semaines, on parle de la migration IPV6 qui est à effectué d’urgence. Or, il semblerait qu’un aspect important de cette migration a été, très souvent, omise : les applications.
Petit rappel, l’IPv4 est défini par 4 décimaux séparé par des points (ex 192.168.0.2) . La valeur représente un octet (256 valeurs possibles). Afin de répondre à la problématique du nombre croissant de device, mais également pour faire évoluer et répondre à d’autres problématiques, l’IPv6 a été défini. A noter, que cette définition a démarré dans les années 90. Une adresse IPv6 sera représenté par 8 groupes de 2 octets séparés par des deux points (ex : 2001:0db8:0000:85a3:0000:0000:ac1f:800). Côté infrastructure, matériel et OS, cette évolution est intégrée depuis un petit moment ou l’intégration se termine. Ce n’est pas le cas de la plupart des applicatifs.
En sachant la différence sur les tailles des adresses, on se rend compte que les applications sont très souvent développées sur une base d’adresse v4, sauf pour les toutes dernières (et encore !). Prenons un exemple simple, j’ai une application qui tourne sur un serveur PHP avec une base de données en MySQL. Je souhaite enregistrer les IPs des personnes qui se connectent. Le champ utilisé est à 99% un VARCHAR(15) : 4 décimaux de 3 chiffres plus les 3 points. Mon évolution va consister à devoir soit ajouter un champ dédié pour l’IPv6 (en plus de la V4), soit de modifier la taille du champ en VARCHAR(39). Je ne parle pas non plus du code qui sera également à modifier.
En France, d’ici 2013 au plus tard, les FAI ont annoncé la bascule toutes les boxes (et donc tous les abonnés en IPv6). Pareil pour les téléphones mobiles. En résumé, plus le temps passe jusque cette date, plus il deviendra critique et sensible de faire évoluer les applications sans heurt. Je pense également à tous les systèmes de géolocalisation (ex la base Maxmind) qui se base sur les IPv4 et qui vont devoir également gérer la bascule IPv6.
En résumé, si vous n’avez pas encore commencé à étudier cette migration, il est temps de le faire 😉
Pour stocker des IP v4 dans MySQL, le plus efficace est de passer par la conversion vers un entier non signé avec la fonction INET_ATON() (cf. http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_inet-aton).
Tu gagnes 11 octets par IP stockée soit 75% ce qui n’est pas négligeable pour des tables importantes genre des logs.