L’IPv4 en tant que service fait de la traduction un contrat d’exploitation

Résumé

• L’IPv4 en tant que service ne supprime pas la dépendance à IPv4 : elle la déplace vers DNS64, la découverte du préfixe, le CLAT, l’état du PLAT et le partage des ports.
• IPv6 peut rester disponible tandis que seuls les noms IPv4, les adresses littérales ou les sessions traduites de longue durée échouent.
• Une exploitation crédible exige un reçu daté reliant résolveur, Pref64, chemin CLAT, état du PLAT, bascule, attribution et limites de l’IPv4 entrant.

Un abonné remplace le résolveur de sa passerelle. Les services natifs IPv6 continuent de répondre. En revanche, un site qui ne publie qu’un enregistrement A n’obtient plus d’adresse AAAA synthétique et devient inaccessible. Chez un autre abonné, la même destination fonctionne encore : le CLAT accepte le paquet IPv4 et découvre autrement le préfixe de traduction. Dans les deux cas, le voyant de la box reste vert.

Cette panne sélective explique l’enjeu de l’IPv4-as-a-Service. L’opérateur peut retirer IPv4 de l’accès ou du cœur tout en donnant accès à l’Internet IPv4 restant. Mais la continuité n’est plus attachée à une adresse remise de bout en bout. Elle dépend d’une suite de décisions prises par le résolveur, l’hôte, la passerelle, le routage et le traducteur de l’opérateur.

L’adresse synthétique doit rejoindre le bon traducteur

La RFC 6147 définit DNS64. Lorsqu’un client demande un enregistrement AAAA pour un service qui n’a qu’un enregistrement A, DNS64 peut insérer l’adresse IPv4 dans un préfixe IPv6 de traduction, Pref64::/n. Le client envoie alors un paquet IPv6 vers cette adresse synthétique.

Ce résultat DNS n’est pas une preuve de connectivité. Le préfixe utilisé pour la synthèse doit correspondre à celui que le NAT64 sait décoder et que le réseau achemine vers lui. Le résolveur et le traducteur ne renégocient pas cet accord à chaque requête. Un AAAA synthétique confirme une construction d’adresse, pas la disponibilité du PLAT, sa capacité ou la continuité de son état.

DNSSEC rend cette articulation visible : la synthèse modifie une réponse alors que DNSSEC cherche précisément à détecter les modifications non autorisées. La validation reste possible lorsque les rôles de validation et de synthèse sont placés consciemment. Le reçu doit donc conserver le résolveur, les réponses A et AAAA, le résultat DNSSEC et le préfixe employé.

Le CLAT préserve certaines hypothèses anciennes, pas toutes

La RFC 6877 décrit 464XLAT. Le CLAT, traducteur sans état placé dans le terminal ou la passerelle client, transforme un paquet IPv4 en IPv6. Le PLAT, côté opérateur, effectue la traduction avec état vers IPv4. Une application qui utilise un nom peut bénéficier de DNS64 et d’une seule traduction avec état. Une application qui appelle une adresse IPv4 littérale ou une API ancienne utilise le CLAT comme première étape.

C’est pourquoi un résolveur étranger ne produit pas toujours la même panne. La RFC 8683 montre qu’un accès doté de NAT64 mais dépourvu de CLAT peut perdre les destinations IPv4 lorsque le résolveur choisi ne fait pas DNS64. Avec 464XLAT, le trafic peut survivre sans DNS64, à condition que le CLAT découvre le bon Pref64. Un préfixe propre au réseau et un résolveur qui en synthétise un autre peuvent encore séparer l’adresse de son traducteur.

464XLAT n’est pas un double accès IPv4 intégral. La RFC 6877 vise les communications client-serveur vers des serveurs IPv4 publiquement adressés. Elle ne fournit pas, à elle seule, une connexion IPv4 entrante générale ni toutes les formes de pair à pair. Ces exclusions doivent figurer dans le produit et non être découvertes dans un ticket d’incident.

Pref64 possède une durée de vie

La RFC 8781 ajoute une option PREF64 aux annonces de routeur IPv6. Elle transporte la longueur du préfixe et une durée de validité ; une valeur nulle indique que le préfixe ne doit plus être utilisé. L’hôte doit le traiter comme propre à l’interface et, s’il comprend les domaines de provisionnement, au PvD concerné. Les routeurs sont invités à détecter et journaliser les annonces incohérentes sur un même lien.

L’exploitation doit donc enregistrer le mécanisme de découverte, le préfixe, sa durée restante, l’interface ou le PvD et la cohérence des annonces. Un ancien préfixe peut continuer à désigner un traducteur retiré ; une durée trop courte peut expirer avant l’annonce suivante. Une simple ligne de configuration ne raconte pas ce cycle.

Une bascule de boîtier n’est pas forcément une reprise de session

La RFC 6146 définit le NAT64 avec état. Le PLAT maintient les associations et les sessions qui permettent au paquet de retour de retrouver le client IPv6. La RFC impose aussi de borner les ressources accordées aux fragments pour résister à l’épuisement. Elle ne garantit pas qu’un second traducteur possède les sessions du premier.

Après une bascule, les nouvelles connexions peuvent réussir tandis qu’un téléchargement, un jeu ou un tunnel existant se réinitialise. Un contrôle qui ouvre seulement une nouvelle connexion donnera un faux sentiment de reprise. Il faut tester une session avant et après la bascule et joindre au résultat le site PLAT actif, la marge d’état, l’événement de bascule et le comportement prévu des associations existantes.

La RFC 9099 rappelle les frontières de sécurité : pression sur l’état, interaction DNSSEC et difficulté avec la plupart des usages IPsec sans encapsulation UDP. 464XLAT peut fonctionner sans DNS64 et éviter le problème particulier de la synthèse DNS, sans faire disparaître les autres risques de traduction.

L’économie d’adresses déplace la comptabilité

La RFC 9313 compare cinq techniques IPv4aaS. Avec 464XLAT, l’état par flux et l’allocation dynamique de ports résident dans le NAT64 de l’opérateur. Le partage d’une adresse IPv4 peut être efficace, mais il concentre capacité, continuité et journalisation.

Attribuer une adresse et un port observés à un abonné exige alors une preuve liée au temps. Journaliser chaque session est précis mais coûteux ; attribuer un bloc de ports pour une durée réduit les journaux et utilise moins finement l’espace de ports. La décision dépend aussi du droit applicable. La RFC ne fixe pas une durée universelle de conservation.

Enfin, l’état côté opérateur ne donne pas automatiquement un port entrant au client. PCP ou une correspondance explicite peut être nécessaire. Une limite architecturale doit être annoncée comme telle.

Les sources ne donnent ni part mondiale d’adoption en 2026, ni gain universel, ni taux habituel de panne. Elles établissent une chaîne de contrôle suffisamment précise pour être testée.

Sources

1. RFC 6146 — NAT64 avec état
2. RFC 6147 — DNS64
3. RFC 6877 — 464XLAT
4. RFC 8683 — déploiement de NAT64 et 464XLAT
5. RFC 8781 — découverte de PREF64
6. RFC 9099 — sécurité opérationnelle d’IPv6
7. RFC 9313 — comparaison des techniques IPv4aaS