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.
