Résumé

  • RFC 3493 permettait à un socket AF_INET6 de dialoguer avec un pair IPv4 représenté par une adresse IPv4 mappée en IPv6. L’option IPV6_V6ONLY séparait les familles, mais le RFC la déclarait désactivée par défaut.
  • Le nom de famille du socket ne prouvait donc ni la famille réelle du pair ni l’occupation du port. Valeur effective de l’option, adresse générique, ordre des bind et résultat de chaque appel étaient des preuves distinctes.

Imaginons un déploiement avec deux processus : l’un annoncé comme serveur IPv6, l’autre comme serveur IPv4. Le plan semble sans ambiguïté. Pourtant, si le premier ouvre un socket AF_INET6 générique avec le comportement double pile, il peut déjà couvrir les connexions IPv4. Le second processus arrive devant un port que le noyau considère occupé.

RFC 3493 explique le mécanisme par les adresses IPv4 mappées en IPv6. Les 32 bits d’une adresse IPv4 sont placés dans une structure de 128 bits sous le préfixe fixe ::ffff:. Un programme peut alors utiliser l’interface IPv6 pour joindre un nœud IPv4. À la réception, le noyau peut rendre le pair dans un sockaddr_in6; le test IN6_IS_ADDR_V4MAPPED() permet à l’application de reconnaître cette représentation.

Il ne faut pas confondre représentation et trajet. La structure ne prouve pas que la machine distante parle IPv6, que le réseau intermédiaire est natif IPv6 ou que les mêmes contrôles de sécurité ont été appliqués. Elle prouve seulement comment le noyau et le programme se transmettent une adresse.

La section 5.3 ajoute IPV6_V6ONLY. Activée, cette option booléenne limite un socket AF_INET6 aux communications IPv6. RFC 3493 la fixe à désactivée par défaut. En 2003, l’objectif était de faciliter les applications double pile sans les forcer à ouvrir deux interfaces entièrement séparées.

L’exemple du RFC porte précisément sur l’occupation du port : activer l’option permet à deux versions du même serveur de fonctionner sur le même port, l’une en IPv6, l’autre en IPv4. L’option gouverne donc une frontière de ressources. Elle détermine si un bind générique revendique une seule famille ou les deux, et si un deuxième processus peut obtenir son écouteur.

Une supervision limitée aux processus peut manquer l’échec. Les deux binaires existent, mais l’un n’a jamais acquis son port. Une supervision limitée au socket peut manquer l’autre sens du problème : un seul descripteur reçoit deux catégories de pairs alors que la politique pensait les séparer. Le reçu utile doit contenir la valeur effective de IPV6_V6ONLY, l’adresse liée, le code retour du bind et les catégories réellement acceptées.

Une réserve du RFC empêche une lecture mécanique. L’option n’affecte pas les adresses mappées qui entrent déjà comme trafic IPv6 valide par SIIT. RFC 6052 et RFC 6145 décrivent des préfixes intégrés et la traduction de paquets, mécanismes différents de la présentation locale d’un pair IPv4 à un socket double pile. La forme observée ne suffit donc pas à déterminer où la transformation a eu lieu.

La résolution de noms ne ferme pas davantage la preuve. getaddrinfo() produit des candidats selon une famille et des indicateurs. RFC 6724 organise la sélection; RFC 8305 traite les candidats IPv6 et IPv4 comme des chemins à essayer. Une adresse retournée ne garantit ni bind en face, ni accessibilité, ni résultat applicatif.

Enfin, le défaut « désactivé » appartient au document historique. RFC 3493 est Informational, remplace RFC 2553 et renvoie à une norme externe pour l’autorité formelle de l’API. Les systèmes contemporains peuvent avoir d’autres valeurs ou d’autres conflits de bind. L’article ne transforme pas la règle de 2003 en conseil universel.

La conclusion tient dans une chaîne : famille déclarée, option effective, bind réussi, pair accepté, autorisation puis service. Chaque étape demande son propre reçu. Sans cette chaîne, « serveur IPv6 » reste une étiquette commode, pas la description démontrée d’une frontière réseau.

Sources