Les réseaux IoT vont-ils favoriser l'adoption d'IPv6 ?
Les entreprises s'éloignent peu à peu de l'IPv4 pour progressivement se rapprocher de l'IPv6, mais parce que ce dernier présente beaucoup d'avantages pour les réseaux IoT, le processus pourrait s'accélérer.
L'IPv6 comble les lacunes de l'IPv4 et apporte des caractéristiques intéressantes pour les déploiements IoT. Par exemple, la capacité de prendre en charge de vastes réseaux IoT, de préserver la durée de vie des batteries des appareils IoT et de soulager les tâches d'administration et de maintenance. Alors, l'IoT va-t-il favoriser l'adoption de l'IPv6 dans les réseaux d'entreprise ?
Un nombre colossal d'adresses IP
Un problème flagrant de l'IPv4, c'est qu'il ne peut prendre en charge que 4,2 milliards d'adresses quand, selon certaines estimations, le nombre d'appareils connectés à Internet devrait atteindre les 28,5 milliards en 2022. C'est un handicap énorme parce que, au moment du déploiement des réseaux IoT, la plupart des dispositifs ne pourront pas être connectés à Internet sans une couche technologique intermédiaire dite de traduction d'adresse réseau (NAT). Cette adresse permet à une ou plusieurs adresses IP publiques de servir de nombreuses adresses IP privées ou jouant un rôle local important. Comparativement, l'IPv6 peut prendre en charge environ 340 sextillions d'adresses IP (340 suivi de 36 zéros), ce qui est suffisant pour fournir des adresses IP universellement uniques à chaque périphérique IoT. Et ce serait possible sans qu'il soit nécessaire d'investir dans des routeurs NAT.
Une meilleure gestion des batteries IoT
L'IPv4 n'est également pas à la hauteur pour préserver l'autonomie de la batterie des périphériques IoT. La plupart des appareils connectés sont alimentés par batterie et les réseaux IoT, comme les systèmes de capteurs des usines, peuvent comprendre des centaines ou des milliers d'appareils, si bien que la préservation de la durée de vie des batteries est très importante. Il suffit d'imaginer le temps, les efforts, et le coût que représente le remplacement des piles dans des milliers de dispositifs IoT par ailleurs très dispersés. Sous IPv4, la diffusion inutile de messages de routine consomme de l'énergie. Ces messages sont notamment utilisés pour des processus de résolution d'adresse (ARP), qui servent à lier les adresses MAC aux adresses IPv4. Ce mode de fonctionnement implique l'envoi d'un message ARP à chaque appareil du réseau qui doit chacun à son tour traiter le paquet, et donc utiliser une partie de l'énergie de la batterie, peu importe si l'appareil doit ou non participer à l'échange.
Ce manque d'efficacité peut également perturber le réseau dans son ensemble. Les problèmes liés aux tempêtes de radiodiffusion provoquées par des émissions fréquentes dans un court laps de temps sont bien connus, et ce type d'événement serait préjudiciable à un réseau IoT. L'IPv6 n'impose pas de fonction de diffusion. Le protocole s'appuie sur des communications multicast efficaces pour gérer les communications de « un-vers-plusieurs » périphériques. Au lieu de faire de la diffusion, le protocole IPv6 Neighbor Discovery Protocol (NDP) utilise une multidiffusion efficace avec des adresses dites de « multicast sollicité » pour construire et maintenir un cache de voisinage. Le paquet Neighbor Solicitation (NS) n'est envoyé qu'à un sous-ensemble situé à une minute du subset /64 du réseau LAN et le paquet Neighbor Advertisement est renvoyé en unicast. L'adresse de groupe de multidiffusion en lien local All-Nodes IPv6 (FF02::1) est aussi proche que possible d'une diffusion IPv6, et les périphériques IoT font en sorte d'utiliser des messages en unicast chaque fois que possible pour économiser la batterie.
Une sollicitation mesurée des batteries
L'IPv6 offre plusieurs solutions pour assigner dynamiquement des adresses aux périphériques IoT. Les noeuds IPv6 ont plusieurs adresses, contrairement aux noeuds IPv4 qui n'ont qu'une seule adresse unicast. Les noeuds IPv6 ont une adresse locale de lien (FE80::/10) et une ou plusieurs adresses IPv6 unicast par interface. L'adresse locale du lien est utilisée comme « amorce ou boostrap » pour acquérir les adresses unicast qui serviront d'adresse source pour le message de sollicitation de routeur (RS) et identifier le routeur local. Le routeur du premier saut renvoie le paquet RA (Router Advertisement) au groupe multicast all-nodes (FF02::1) indiquant le préfixe IPv6 /64 local et la méthode pour obtenir son adresse unicast. En fonction de certains indicateurs et d'autres options du message RA, un noeud est invité à utiliser l'auto-configuration automatique des adresses sans état (Stateless Address AutoConfiguration - SLAAC) (RFC 4862), le DHCPv6 Stateful (RFC 8415) ou le serveur DNS récursif (Recursive DNS Server - RDNSS) (RFC 8106). Savoir quelle solution utiliser est une question fréquente dans les réseaux d'entreprise.
Dans le cas des capteurs qui n'offrent pas la puissance de calcul et la robustesse nécessaire pour exécuter le DHCPv6 et ont besoin de fonctionner uniquement sur un réseau plat, le choix du SLAAC s'impose de manière évidente. Pour les postes de travail et les serveurs d'entreprise, le DHCPv6 est recommandé, mais la question se pose désormais. Alors que de plus en plus d'OS supportent de RDNSS, Android compris, le choix du RDNSS se généralise. Le plus souvent, les paquets RA sont transmis par le routeur local toutes les 200 secondes pour tenir tous les noeuds informés d'un changement quel qu'il soit. Les nouveaux noeuds qui rejoignent le réseau étant très impatients, ils envoient sans délai un paquet RS au groupe de multidiffusion de lien local All-nodes (FF02::2) pour savoir sur quel réseau ils se trouvent. Le routeur local répond immédiatement au RS en envoyant un paquet Router Advertisement (RA) à tous les noeuds. Comme on peut l'imaginer, ce transfert d'information peut consommer une certaine quantité d'énergie mesurable par une application IoT et, par conséquent, des options pour contrôler les paquets RA ont été créées.
Des protocoles IoT innovants
Une option consiste à utiliser des intervalles de RA plus longs pour les réseaux IoT. Certains dispositifs IoT n'ont pas besoin de recevoir plus d'un seul message RA par jour, voire moins. Cependant, chaque fois qu'un nouveau périphérique IoT rejoint le réseau, il envoie un paquet Router Advertisement (RA), déclenchant une multidiffusion de RA All-nodes par le routeur local. Pour restreindre l'envoi des paquets multicast à tous les noeuds, il est possible de transformer le paquet Router Advertisement en paquet unicast au niveau du noeud individuel qui envoie le message de sollicitation de routeur (RS). Cela permet d'empêcher tout autre noeud établi de recevoir le RA multicast. Cette fonction « Unicast-RA » supprime les paquets RA envoyés au groupe multidiffusion All-nodes. L'option a été ajoutée aux versions du système IOS 15.4(2)T, 15.4(2)T, 15.4(2)S, 15.2(1)SY1 de Cisco et ultérieures. Elle est configurée en utilisant la commande d'interface Layer 3 « ipv6 nd ra solicited unicast ».
L'IPv6 facilite l'innovation et beaucoup de protocoles IoT compatibles IPv6 ont été développés. Voici quelques exemples d'utilisation de l'IPv6 par les réseaux IoT.
- L'IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) permet de compresser, d'encapsuler et de diviser les paquets IPv6 en plusieurs trames plus petites pour les envoyer sur des réseaux sans fil IEEE 802.15.4 (RFC 4944 et RFC 6282). Par conséquent, 6LoWPAN nécessite une passerelle (un routeur edge) pour connecter le réseau IPv6 natif au réseau de périphériques IoT. L'objectif est de limiter l'utilisation de la multidiffusion IPv6 pour maximiser l'autonomie de la batterie (RFC 6775). Ces méthodes sont utilisées par la suite de protocoles Zigbee.
- L'Internet Engineering Task Force (IETF) travaille sur des IPv6 over Low Power WAN comme LoRaWAN et Light-Weight Implementation Guidance (lwig) pour les petits appareils intégrés utilisant l'IPv6. L'IETF a également créé des protocoles de routage compatibles avec ces réseaux à faible puissance et à faible perte (Routing Over Low power and Lossy networks - roll). L'IETF a créé le « RPL : IPv6 Routing Protocol for Low-Power and Lossy Networks » (RFC 6550) et le « Multicast Protocol for Low-Power and Lossy Networks » (MPL) (RFC 7731). Le RPL s'appuie sur l'IPv6 pour la découverte de tous les noeuds RPL en utilisant le groupe de multidiffusion IPv6 FF02::1A. L'IETF a élaboré des normes sur la manière dont les dispositifs IoT communiquent sous IPv6 en utilisant des interfaces Web et RESTful (CoRE).
- Le Constrained Application Protocol (CoAP) (RFC 7252) définit la méthode d'utilisation des services Web communs par ces dispositifs IoT. Le CoAP utilise le groupe de multidiffusion IPv6 FF0X::FD (All CoAP Nodes). Le protocole IPv6 mobile (MIPv6) (RFC 6275) est utilisé depuis de nombreuses années pour permettre aux appareils sans contrainte de maintenir leurs communications pendant la transition entre les réseaux Layer 3. L'IPv6 est même utilisé dans l'IoT industrielle et les réseaux robotiques. Le protocole PTP (Precision Time Protocol) (IEEE 1588-2008) utilise la multidiffusion IPv6 pour synchroniser les horloges à une précision inférieure à la microseconde pour le réglage très précis de mouvements à grande vitesse. Le PTP utilise les groupes de multidiffusion IPv6 FF02::6B et FF0X::181.
- À mesure que les entreprises déploient leurs diverses applications IoT, elles devraient chercher à faire fonctionner leur système sous IPv6. Les ingénieurs des réseaux d'entreprise devraient travailler activement au déploiement de l'infrastructure IPv6 avant que le réseau IoT ne soit opérationnel. Ils pourront mettre en oeuvre un meilleur réseau IPv6 que s'ils sont bousculés par la mise en route d'un projet IoT qui doit permettre à l'entreprise d'économiser de l'argent ou lui apporter une fonction utile. En premier lieu, les entreprises doivent obtenir leurs ressources d'adresses IPv6 auprès du Registre Internet Régional (RIR), puis suivre les directives bien documentées du déploiement IPv6.
