Résumé

  • RFC 3338 plaça un traducteur entre l’API socket et les piles IPv4/IPv6. Pour un pair n’ayant qu’un AAAA, il pouvait fabriquer une réponse A depuis un pool local et relier cette valeur à l’adresse IPv6 sans traduire les en-têtes IP.
  • La valeur IPv4 appartenait à l’état du traducteur. Épuisement, réemploi, différences d’API et décalage entre AAAA de l’hôte et version du service limitaient l’illusion. Génération du mapping, appel traduit, transport et application exigeaient leurs propres reçus.

Le résolveur fabriquait la forme attendue

Une application IPv4 ancienne attendait des structures à quatre octets. Lorsque son code source n’était pas disponible, la porter n’était pas possible immédiatement. BIA visait un hôte déjà dual stack dont certains programmes n’avaient pas encore appris IPv6.

Le résolveur interceptait l’appel, demandait A et AAAA, puis, si seul AAAA existait, obtenait du mappeur une valeur du pool IPv4 interne. Il enregistrait la paire et renvoyait une réponse A synthétique au programme.

Lors de l’appel socket, le function mapper récupérait l’IPv6 associé et invoquait l’API IPv6. Les paquets utilisaient la pile native ; contrairement à BIS, BIA ne convertissait pas les en-têtes IP.

La valeur désignait une ligne de table

Une adresse ordinaire semble identifier durablement une interface. La valeur BIA avait un sens plus étroit : dans telle table, à telle génération, elle désignait telle adresse IPv6.

Le RFC proposait comme exemple des valeurs non attribuées telles que 0.0.0.1 à 0.0.0.255. Elles ne devaient pas sortir de l’hôte. Leur unicité pouvait être par nœud, utilisateur ou processus.

Un journal qui ne garde que les quatre octets est ambigu. Il faut périmètre, génération, processus, réponse DNS et référent IPv6. Cette « adresse » ressemblait davantage à un descripteur de fichier qu’à une identité routée.

Le réemploi changeait le référent sans changer les bits

Le pool était fini. Face à de nombreux pairs, le mappeur pouvait libérer l’entrée la plus ancienne et réutiliser sa valeur. La capacité revenait, mais la poignée désignait désormais un autre pair.

Une copie conservée dans un cache, un callback ou un log pouvait sembler valide et mener ailleurs. Le conflit naissait du temps local, pas du routage mondial.

Les preuves doivent enregistrer allocation, dernier usage, éviction, réemploi et génération. Deux appels montrant la même valeur avant et après réemploi ne parlent pas de la même identité opérationnelle.

Convertir un appel ne rendait pas les API identiques

Le mapper cherchait des fonctions sémantiquement correspondantes, mais IPv4 et IPv6 n’étaient pas entièrement compatibles. IPv6 apportait des fonctions nouvelles ; raw sockets, données auxiliaires, ICMP et adresses présentes dans les protocoles applicatifs dépendaient du système.

Un appel traduit avec succès prouvait l’invocation, non la conservation de chaque option et erreur. L’application pouvait dépendre d’un détail impossible à reproduire.

Le reçu conserve fonction et arguments originaux, fonction produite, options, implémentation OS, retour et interprétation. Ne pas traduire l’en-tête simplifiait une couche ; la traduction sémantique demeurait.

Le AAAA de l’hôte ne garantissait pas le service sur ce port

Une machine dual stack pouvait publier AAAA parce que certains services parlaient IPv6, alors qu’une application serveur restait IPv4-only. Le client BIA atteignait l’hôte IPv6 mais échouait au port choisi.

Pour TCP, le traducteur pouvait parfois observer l’échec de connect et essayer les autres adresses. Pour UDP, savoir quelle adresse avait fonctionné était difficile voire impossible sans participation de l’application.

DNS prouve des enregistrements, la joignabilité prouve un chemin, l’écoute prouve un port, et l’application prouve l’opération. Aucun reçu ne remplace le suivant.

Une passerelle temporaire pouvait retarder la migration

RFC 3338 était Experimental. Il visait les premiers utilisateurs possédant IPv6 mais un programme sans source. Il déconseillait l’usage général et refusait que BIA excuse un report du portage quand le code existait.

Cette limite anticipait le verrouillage. Une couche de compatibilité acquiert des exceptions, des dépendances et des outils jusqu’à rendre sa suppression plus chère que le portage initial.

Le déploiement devait donc avoir des critères de sortie : applications admissibles, propriétaire du portage, appels non supportés, date de révision et preuve autorisant l’arrêt.

Les solutions ultérieures ne doivent pas être projetées en arrière

RFC 2767 plaçait BIS plus bas et s’appuyait sur SIIT de RFC 2765. RFC 2893 décrivait le contexte dual stack. RFC 3493 documenta ensuite l’API IPv6, et RFC 4038 les choix applicatifs.

RFC 6555 puis RFC 8305 conçurent Happy Eyeballs, qui essaie ou ordonne plusieurs familles. Ce n’est pas l’alias IPv4 local de BIA. Leur logique ne doit pas être attribuée à RFC 3338.

RFC 4291 définit les adresses IPv6, sans donner une portée mondiale au pool synthétique. Aucun de ces textes ne prouve un déploiement.

Toute poignée de compatibilité a besoin d’une génération

BIA conserva l’interface de l’application en modifiant l’exécution en dessous. Le coût était un état caché : l’adresse devint référence de table et l’appel ordinaire devint interception.

Une réponse A synthétique doit porter le reçu de mapping. L’appel doit garder avant et après. La connexion doit nommer l’IPv6 réel et le résultat du service.

Sinon, l’enquêteur voit une valeur IPv4 et lui attribue une identité globale imaginaire. Les bits n’étaient pas l’identité ; le mapping vivant l’était.

Sources