Mon blog

Lorsque des machines parlent IPv6, elles reçoivent fréquemment des messages RA (Router Advertisment), que les routeurs émettent souvent avec trop d'enthousiasme. Le traitement de ces messages RA nécessite des ressources et, sur des petites machines alimentées par une pile et souhaitant économiser les ampèreheures, ces RA fréquents, qui les obligent à se réveiller et à travailler, sont une plaie. Ce court RFC suggère quelques moyens d'économiser l'énergie.

À l'époque où IPv6 avait été conçu, on ne pensait pas vraiment à l'Internet des Objets, à ces millions de petits machins connectés. Des messages RA (RFC 4861, section 3) fréquents ne sont pas un problème pour des serveurs alimentés électriquement en permanence. Mais le monde a changé, et il faut maintenant économiser la batterie (section 1 du RFC).

Regardons quelques cas typiques (section 2 du RFC). Un RA (Router Advertisement) peut être sollicité ou pas (RFC 4861). Un RA sollicité est typiquement dû à l'arrivée d'une machine dans le réseau. Elle émet alors un RS (Router Solicitation) et le ou les routeurs, en le recevant, répondent par un RA. Dans certains cas (par exemple si la machine émettrice n'a pas encore d'adresse IPv6 propre), ce RA est envoyé à une adresse multicast, ce qui fait que toutes les machines le recevront et devront le traiter. Si beaucoup de machines quittent et rejoignent le réseau fréquemment (ce qui arrive dans les réseaux sans-fil, lorsque la liaison est mauvaise), ces RA sollicités peuvent représenter un trafic non négligeable (un maximum d'un RA toutes les trois seconde et par routeur est toutefois imposé par les sections 6.2.6 et 10 du RFC 4861).

Même en l'absence de sollicitations, les routeurs IPv6 émettent des RA périodiques, parfois un toutes les cinq ou dix secondes, de manière à éviter que des machines ratent l'information importante.

Conséquences (section 3 du RFC) ? La batterie se vide plus vite, ce qui est très frustrant puisque la plupart de ces RA étaient « inutiles » pour la machine qui les recevait. Certaines machines traitent le problème en ignorant les RA lorsqu'elles sont dans un mode de basse consommation (par exemple Android, avec des conséquences négatives). C'est compréhensible mais cela fait qu'elles risquent, en se réveillant, d'avoir perdu leur connectivité car le réseau a changé ou, tout simplement, parce qu'elles ont « oublié » la route par défaut. Encore plus violent, certaines machines ignorent tous les paquets lorsqu'elles veulent économiser leur batterie. Ces comportements poussent certains administrateurs réseau à augmenter la fréquence des RA, aggravant ainsi encore le problème.

Une autre conséquence (merci à Gabriel Kerneis pour l'exemple), les NAS du constructeur Synology refusent de passer en hibernation profonde s’ils reçoivent des RA (ou des paquets DHCP d’ailleurs). Le seul moyen de faire fonctionner IPv6 sur ces machines tout en préservant l’hibernation est de configurer l’adresse manuellement.

Quelle serait la bonne fréquence d'envoi de RA (section 4) ? Un ordinateur de type portable ne verra pas grand'chose, même pour des RA envoyés toutes les cinq secondes. Sa batterie en a vu d'autres. Les engins plus petits (tablettes, téléphones, montres connectées et autres objets) ont davantage de contraintes. Aujourd'hui, un engin typique va consommer 5 mA quand il dort. Le traitement d'un RA qu'il n'a pas demandé va lui coûter 200 mA pendant un quart de seconde, ce qui fera en tout presque 14 µAh.

Pour limiter la consommation électrique due aux RA à moins de 2 % de la consommation du mode « économique », il faut rester en dessous de 100 µA, ce qui fait moins de 7 RA par heure. Comme des RA se perdent, le routeur ne peut pas être sûr que toutes les machines ont reçu cette information. Le RFC fait un choix conservateur : avec une moyenne de 8-9 minutes entre deux RA (afin de rester en dessous de 7 par heure), le routeur doit compter que l'information devra durer au moins 5 fois ce temps (ce qui fera 40-45 minutes). Pas question donc de changer de configuration IPv6 trop souvent.

Il est possible que certains environnements (réseaux de capteurs industriels) soient encore plus limités en énergie et doivent donc recevoir encore moins de RA.

Pour synthétiser, les recommandations de notre RFC pour les routeurs sont :

• La possibilité de répondre aux RS par un RA unicast est autorisée par le RFC 4861 mais ce n'est pas obligatoire. Notre RFC demande que cela le devienne et qu'on puisse configurer tous les routeurs pour utiliser cette possibilité. (Si l'adresse source du RS le permet.)
• Les réseaux ayant beaucoup de machines pauvres en énergie ne devraient pas hurler des RA inutiles en permanence. Ces RA devraient être envoyées rarement (voir les chiffres plus haut) quitte à être plus fréquents immédiatement après un changement de la configuration.

Notez que cela ne change pas le protocole IPv6 : ces recommandations sont déjà des comportements légaux.

Et les recommandations pour les machines terminales sont :

• Si elles peuvent traiter des paquets IPv6 pendant le mode « économie d'énergie », elles doivent aussi traiter les RA (autrement, elles risquent de rater des changements importants dans la configuration du réseau), quitte à en limiter le traitement s'ils sont trop fréquents (par exemple un RA par minute maximum).
• Si les machines préfèrent être vraiment silencieuses et inactives pendant cette phase d'économie d'énergie, elles peuvent ignorer les RA mais elles devraient alors se retirer explicitement du réseau lorsqu'elles s'endorment, et refaire la procédure d'arrivée dans un nouveau réseau (par exemple en suivant le RFC 6059) quand elles se réveillent avec du travail à faire (car le réseau aura pu changer pendant leur sommeil).

Enfin, la section 8 du RFC, portant sur la sécurité, rappelle qu'un routeur méchant peut ignorer ces conseils et envoyer beaucoup de RA exprès pour vider les batteries. Il faut donc prendre des mesures contre de tels routeurs (par exemple celle du RFC 6105).

Merci beaucoup à Benjamin Cama pour ses corrections, son analyse détaillée et ses excellentes références (reprises ici).