Résumé

  • Spiro Stathakis a lancé la plateforme de commandes d’isp6 sur EKS avec des pods IPv6, tout en réservant d’abord de petits sous-réseaux IPv4 /28.
  • Les interfaces principales des nœuds et celles des points de terminaison double pile ont épuisé cette réserve. L’équipe est passée à /27 côté public et /26 côté privé.

La promesse tenait dans un paramètre : ipFamily: ipv6. Pour isp6, fournisseur de services autour d’IPv6, l’utiliser sur sa propre plateforme de commandes avait du sens. Spiro Stathakis raconte l’essai sur RIPE Labs : les pods recevaient des adresses IPv6 tirées de l’allocation de l’entreprise, tandis que les sous-réseaux IPv4 étaient réduits à /28 pour les besoins hérités. Le plus petit format qu’AWS autorise s’est révélé trop petit pour l’infrastructure qui entourait ces pods.

Un /28 compte 16 adresses. La documentation AWS en retire cinq, les quatre premières et la dernière, avant toute attribution à une ressource. Il en reste 11. Stathakis impute l’épuisement aux interfaces IPv4 principales des nœuds et aux interfaces des points de terminaison double pile. Son équipe a porté les sous-réseaux publics à /27 et les privés à /26. Ce témoignage décrit son installation ; il ne donne ni inventaire détaillé des interfaces ni taux d’occupation actuel.

Le piège est dans le périmètre du mot « IPv6 ». AWS attribue bien IPv6 aux pods et aux services EKS. Mais, pour joindre une destination uniquement IPv4, un pod dispose aussi d’une adresse IPv4 locale à l’hôte, que le composant réseau traduit vers l’IPv4 principale du nœud. L’application continue de fonctionner. Elle peut aussi continuer de dépendre de l’ancien chemin sans bruit particulier. Quant au choix de famille d’adresses du cluster, AWS précise qu’il se fixe lors de sa création.

Stathakis a gardé une passerelle NAT pour les destinations IPv4 encore nécessaires. Il décrit également une règle de sécurité qui n’autorise que l’IPv6 sur le port 443 de certains points de terminaison double pile : si un client choisit une adresse A, la tentative échoue au lieu de glisser discrètement vers IPv4. Les journaux de flux NAT leur ont montré les dépendances qui empruntaient encore ce détour. Une exportation datée des sous-réseaux, des interfaces et de ces flux permettrait de mesurer le reste à migrer aujourd’hui.

La scène est moins spectaculaire qu’une panne, mais plus instructive. Une plateforme peut adopter IPv6 pour ses charges de travail et continuer de payer en espace IPv4 pour le squelette qui les porte. Le /28 représentait une ambition ; le plan d’adressage réel a été écrit par les interfaces.