Suport technique et veille technologique

Lorsqu'on est situé derrière un routeur NAT64, parce qu'on n'a pas d'adresse IPv4 et qu'on dépend de ce routeur pour la communication avec les vieux systèmes qui sont encore uniquement en IPv4, on peut, la plupart du temps, ignorer ce que fait ledit routeur et, notamment, le préfixe qu'il utilise pour synthétiser des adresses IPv6 à partir des adresses IPv4 des systèmes archaïques. C'est la cuisine interne du routeur. Mais, parfois, ce n'est pas possible et on aurait besoin de connaître ce préfixe pour faire la synthèse d'adresses IPv6 soi-même. Ce nouveau RFC décrit une option du protocole PCP permettant d'apprendre le préfixe de synthèse.

Un petit rappel sur NAT64, normalisé dans le RFC 6146. Lorsqu'on a un réseau purement IPv6, mais qu'on veut pouvoir communiquer avec les machines purement IPv4, une des techniques possibles est d'installer un routeur NAT64 qui va faire de la traduction d'adresses d'IPv6 vers IPv4 et retour. Les machines du réseau étant purement IPv6, il faut qu'elles trouvent une adresse IPv6 lorsqu'elles demandent, même si la machine avec qui elles veulent communiquer n'en a pas. NAT64 est donc inséparable de DNS64 (RFC 6147) qui synthétise ces adresses IPv6 en les préfixant avec un préfixe spécial, que le routeur NAT64 reconnaîtra (RFC 6052). Le choix de ce préfixe est une décision locale et les machines du réseau local purement IPv6 ne connaissent pas ce préfixe. La plupart du temps, cela ne les gêne pas. Elles croiront parler en IPv6 avec leur partenaire. Mais, parfois, cela pourrait être utile. Par exemple, dans certains protocoles (par exemple SIP), il y a des références : Alice écrit à Bob en IPv6, le routeur NAT64 transmet à Bob en IPv4 et Bob, voyant une session en IPv4, répond à Alice « envoies les paquets à l'adresse 192.0.34.19 ». Le routeur NAT64 n'analyse pas les paquets SIP et ne peut donc pas traduire cette référence. C'est donc Alice qui doit le faire, ce qui implique de connaître le préfixe à utiliser, pour que le routeur NAT64 sache quoi faire de ces paquets. Le RFC 7051 faisait le tour des possibilités existantes pour découvrir ce préfixe et le RFC 7050 proposait une solution. Notre RFC 7225 en suggère une autre.

PCP (RFC 6887) est un protocole (assez récent et encore très peu déployé) de communication entre une machine sur un réseau local et la box qui relie ce réseau à l'Internet. Son utilité principale est pour l'ouverture de trous dans le NAT, pour permettre, par exemple, les connexions entrantes. Il permet la définition d'options qui ajoutent des possibilités comme celle décrite dans ce RFC, PREFIX64.

La section 3 de notre RFC décrit le cahier des charges. On veut :

• distinguer les adresses IPv6 natives de celles qui ont été synthétisées par NAT64.
• pouvoir synthétiser des adresses IPv6 pour NAT64, à partir d'adresses IPv4, même quand DNS64 n'est pas disponible ou utilisable.
• permettre l'utilisation de DNSSEC.
• gérer des cas compliqués comme la découverte du préfixe lorsque le préfixe dépend de la destination.
• fonctionner même s'il y a plusieurs routeurs NAT64 sur le réseau local (avec des préfixes différents, sinon, cela ne serait pas drôle).

La section 4 du RFC 7051 contient des études de cas plus détaillées. Par exemple, on peut souhaiter avoir son propre résolveur DNS, sur sa machine, et donc on doit faire la synthèse des adresses IPv6 soi-même. Cela nécessite de connaître le préfixe utilisé sur ce réseau local. Il existe de nombreuses raisons pour avoir un résolveur local sur sa machine mais le RFC en cite surtout une : pouvoir faire du DNSSEC proprement, c'est-à-dire avec validation locale. Autre cas où un mécanisme pour apprendre le préfixe est nécessaire, celui cité plus haut où une application transmet des références, sous forme d'une adresse IP. Cela ne concerne pas que SIP, cité plus haut (RFC 3261 et RFC 4566) mais aussi WebRTC, BitTorrent (lorsque le tracker indique les adresses des leechers et seeders), etc.

La section 4 du RFC décrit le format de la nouvelle option, PREFIX64, de numéro 129 (cf. le registre IANA). Le point important est que, pour chaque préfixe IPv6 listé dans le champ Prefix64, il y a une liste (pouvant être de taille nulle) de préfixes IPv4 pour lesquels ce préfixe s'applique.

Que doit faire le serveur PCP avec cette option ? Lorsque le client le demande (en mettant l'option PREFIX64 dans sa requête), le serveur lui répond poliment, avec le préfixe que lui, serveur, utilisera pour les synthèses d'adresses IPv6. Le serveur a le droit d'envoyer cette option PREFIX64 même si on ne lui a rien demandé. Il peut y avoir plusieurs occurrences de l'option si le serveur PCP (le routeur NAT64) utilise plusieurs préfixes.

Et le client ? Il peut demander explicitement le préfixe, en utilisant l'option PREFIX64 avec une valeur spéciale pour le préfixe (::/96). Attention à ne pas paniquer si la réponse contient plusieurs préfixes IPv6, c'est normal. Le client ne doit pas garder en vrac les préfixes mais les laisser associés à un serveur PCP particulier (au cas où il y en ait plusieurs sur le réseau, ce qui est rare, mais permis).

Des exemples d'usage figurent dans la section 5, avec un exemple détaillé pour le (compliqué) cas de SIP : le client SIP (le softphone, qui n'a que IPv6) va envoyer une requête PCP de type MAP avec les options PORT_SET et PREFIX64. Il récupère les ports à utiliser et le préfixe, mettons 2001:db8:122::/48. Avec les informations sur son adresse IPv4 externe, il va construire une offre SDP, qui ne contiendra que de l'IPv4. Ensuite, le logiciel fait une requête SIP INVITE, en IPv6, en utilisant une adresse de destination formée à partir du préfixe et de l'adresse IPv4 du serveur SIP. Le routeur NAT64, voyant ce préfixe, va ensuite faire son travail (conversion en v4, transmission). Pareil pour le message de routeur (l'acceptation de l'appel). Notez que l'« intelligence » était presque entièrement dans le client : le routeur NAT64 n'a pas d'ALG.

À ma connaissance, il n'existe encore aucun client ou serveur PCP avec cette option.