Résumé

  • Les fonctions centrales prenaient déjà un pointeur d’adresse opaque et une longueur ; leur syntaxe pouvait rester stable, tandis que PF_INET6, sockaddr_in6 et de nouvelles fonctions de conversion devenaient nécessaires.
  • La survie des anciens programmes PF_INET face aux pairs IPv4 et l’accès d’un nouveau programme PF_INET6 à un pair IPv4 par adresse mappée sont deux promesses distinctes, sans garantie de service IPv6 effectif.

Un programme transmet un socket ouvert à un autre processus. Le destinataire sait appeler getpeername(), mais ignore parfois si les octets retournés décrivent sockaddr_in ou sockaddr_in6. C’est une scène plus éclairante qu’une simple liste de fonctions inchangées. Le RFC 2133, publié en avril 1997 comme document informatif puis rendu obsolète par le RFC 2553, traitait précisément cette frontière.

Le saut de 32 à 128 bits pour l’adresse IP imposait un nouveau contenant. Les fonctions de base passaient une adresse par pointeur opaque, avec sa longueur : bind(), connect(), sendto() ou accept() pouvaient donc conserver leurs signatures. Mais les quelques octets libres de sockaddr_in ne suffisaient pas à loger adresse IPv6, port et famille. Le document introduisait AF_INET6, PF_INET6 et sockaddr_in6, ainsi que des outils de résolution de noms et de conversion des adresses. Les variantes BSD 4.3 et 4.4 n’avaient même pas la même disposition initiale des champs longueur et famille. Un appel identique n’effaçait ni un tampon trop court ni une conversion de pointeur mal fondée.

La première promesse de compatibilité protégeait l’existant : les systèmes offrant l’extension devaient continuer à exécuter les sources et binaires de l’ancienne interface. PF_INET et sockaddr_in devaient toujours permettre de parler à des nœuds IPv4. Rien n’indiquait qu’un ancien binaire devenait capable d’IPv6. La seconde promesse concernait une nouvelle application PF_INET6. Celle-ci pouvait représenter l’adresse d’un nœud IPv4 sous la forme ::FFFF:<adresse IPv4> dans sockaddr_in6. La notation est une représentation API du pair IPv4 ; elle ne prouve ni un pair IPv6 ni un transport IPv6 sur le réseau.

Le document distinguait aussi l’adresse IPv6 non spécifiée, employée pour laisser au système le choix local, et l’adresse de bouclage, limitée à la machine. Ni l’une ni l’autre ne constitue un test de joignabilité publique. Savoir que le système accepte un argument ne dit pas quelle famille un service déployé recevra effectivement.

Le transfert d’un descripteur rendait la différence dangereuse. Si le processus récepteur décode une structure de la mauvaise famille, l’interface reste familière mais la valeur lue devient trompeuse. RFC 2133 proposait l’option historique IPV6_ADDRFORM pour changer la vue PF_INET ou PF_INET6 d’un socket déjà ouvert. La rétrogradation vers PF_INET n’était permise que si toutes les adresses non génériques déjà associées étaient des adresses IPv4 mappées. Le noyau et l’état existant posaient donc une condition réelle au changement de vue. Cette proposition obsolète n’est pas une recette portable pour les systèmes actuels.

Même les numéros d’interface appartiennent à un autre niveau de preuve. if_nametoindex relie un nom à un indice attribué localement par le noyau ; les options de multidiffusion peuvent choisir une interface de sortie ou inscrire un groupe local. Ces opérations ne démontrent pas qu’un paquet est arrivé au destinataire ou qu’une application l’a consommé. Une réponse de getaddrinfo() fournit, elle aussi, un candidat pour communiquer, pas le compte rendu d’une communication réussie.

L’intérêt historique du RFC tient à cette séparation. La continuité d’un programme IPv4, la représentation d’un pair IPv4 par une application nouvelle, la configuration locale et le résultat de l’application exigent chacun leur preuve. La réflexion de Lu Heng sur le code en fonctionnement sert ici d’angle éditorial pour ne pas confondre texte et observation ; elle ne constitue pas la source des faits techniques.

Sources : RFC 2133, fiche RFC Editor et RFC 2553.