Résumé

  • La révision 02 du projet v6ops du 28 octobre demande au traducteur d’utiliser une IPv4 publique disponible comme source d’une erreur ICMPv4 issue d’une erreur ICMPv6 à source intraduisible. Sans adresse publique disponible, il doit utiliser 192.0.0.8. La révision 01 recommandait le marqueur sans cette branche prioritaire explicite.
  • Le traducteur devrait conserver l’IPv6 d’origine dans un objet Node Identification. Pour Packet Too Big, cet objet ne peut être ajouté qu’après conversion en ICMPv4; le projet permet de l’omettre tout en recommandant de transmettre l’erreur. Le registre IANA classe 192.0.0.8/32 comme adresse factice.

Une réponse peut être livrée sans dire qui l’a émise

La difficulté se produit au moment où une erreur IPv6 doit être rendue compréhensible du côté IPv4. Le message ICMPv6 peut annoncer une destination inaccessible, un délai dépassé ou un paquet trop grand. Son adresse source externe est parfois une IPv6 qui ne correspond ni au préfixe de traduction, ni à une entrée statique ou avec état. Le champ source du nouvel en-tête IPv4 ne peut donc pas reprendre cet émetteur. Si le traducteur n’a pas non plus d’IPv4 publique à lui, attendre une adresse parfaite revient à sacrifier le diagnostic.

La section 4.1 du nouveau texte prend une décision plus précise que la version antérieure. Lorsqu’une IPv4 publique ou un petit pool existe, le traducteur devrait s’en servir, conformément à la voie décrite par RFC 6791. Dans les autres cas, il doit prendre 192.0.0.8. La révision 01 disait plus simplement qu’il devrait employer cette adresse factice devant une source intraduisible. La révision 02 reconnaît deux réalités d’exploitation, celle du traducteur doté d’une IPv4 publique et celle du traducteur qui n’en possède pas.

Le registre spécial de l’IANA donne au nombre sa portée exacte. 192.0.0.8/32 y figure comme « IPv4 dummy address », attribuée par RFC 7600. Le registre autorise son rôle de source selon sa colonne correspondante, mais ne la décrit ni comme destination valable ni comme destination globalement joignable. L’adresse peut permettre de fabriquer la réponse. Elle ne nomme pas le routeur IPv6 qui a produit l’erreur. Une sortie de traceroute qui affiche seulement 192.0.0.8 ne dessine donc pas un nouvel équipement reconnaissable à ce numéro.

Pour porter la vraie source, le projet recommande un objet Node Identification contenant une sous-structure d’adresse IP avec l’IPv6 d’origine. Si l’objet est ajouté, cette adresse doit s’y trouver et le contrôle d’intégrité de l’en-tête d’extension doit être recalculé. À l’inverse, lorsque l’IPv6 source se traduit normalement, le texte interdit d’utiliser l’adresse factice ou d’ajouter cette extension. La différence entre les deux branches doit rester visible dans le paquet et dans l’outil de lecture.

Packet Too Big refuse la solution élégante

Le cas le plus instructif est Packet Too Big. On aimerait coller l’identité à l’erreur avant de passer la frontière. Le mécanisme d’extension ICMP ne s’ajoute pourtant pas à un message ICMPv6 Packet Too Big de cette manière. Il faut traduire d’abord, puis ajouter l’objet dans la réponse ICMPv4. Le projet autorise aussi l’implémentation à ne pas ajouter l’objet pour ce cas. Il lui demande néanmoins de transmettre l’erreur avec 192.0.0.8 si la source est intraduisible et aucune IPv4 publique n’est disponible, plutôt que de jeter le message.

Cette concession préserve un signal de taille de paquet utile au correspondant IPv4. Elle peut laisser l’origine moins claire. Ce n’est pas une contradiction : livrer l’erreur et attribuer l’émetteur sont deux fonctions. Le numéro de secours sert à la première. L’extension sert à la seconde quand elle est présente et qu’un logiciel sait l’interpréter.

L’exigence dépasse les en-têtes. Le traducteur doit distinguer une erreur née d’un trafic IPv4 qu’il a traduit d’un trafic IPv6 natif qui n’appelle pas cette intervention. Des adresses IPv6 dédiées à la traduction facilitent ce tri. Si la même IPv6 sert aux deux usages, le projet envisage de l’état supplémentaire ou l’examen du paquet invoquant l’erreur. Une adresse réservée dans un registre ne fait pas ce travail de classification pour l’opérateur.

Le chapitre opérationnel rappelle que les outils, notamment traceroute, doivent afficher l’objet Node Identification pour en tirer le bénéfice. Un paquet peut transporter l’IPv6 d’origine pendant que l’écran ne montre que l’adresse factice. Les articles antérieurs sur Node Identification traitaient de la divulgation générique et de la lecture d’un AFI inconnu. Ici le conflit est celui de l’adresse source choisie par XLAT lorsque l’IPv4 publique manque. Le Datatracker présente une proposition de groupe soumise à l’IESG, encore en évaluation; elle mettrait à jour RFC 6791 et RFC 7915 si elle était approuvée. Aucun relevé de paquets déployés n’est fourni.

Sources