Le protocole PCP, normalisé dans le RFC 6887, permet à une machine de signaler à la
box, au
routeur CPE, au
pare-feu, ses désirs en terme d'ouverture
de ports,
d'obtention d'information sur l'adresse IP externe, etc. Mais
comment l'ordinateur de M. Michu trouve t-il l'adresse du serveur
PCP ? Une des solutions est celle introduite par ce
RFC : une adresse
anycast « bien connue »,
192.0.0.9 en IPv4 et
2001:1::1 en IPv6.
Souvent, l'adresse IP du serveur PCP est évidente : c'est
l'adresse du routeur par défaut. Mais il y a des cas plus
compliqués, par exemple en cas de
CGN (section 1 du RFC). Avant notre RFC 7723, les
seules autres solutions étaient la configuration manuelle, ou une
option DHCP (RFC 7291).
Ce nouveau RFC ajoute une possibilité : le client PCP écrit
tout simplement à l'adresse bien connue, 192.0.0.9 ou
2001:1::1, et le serveur PCP
approprié
répondra. L'anycast
s'occupera de router le message du client au bon serveur. Une
simple diffusion n'aurait
pas suffi : le serveur PCP n'est pas forcément sur le réseau local
(notamment en cas de CGN). Avec
l'anycast, il n'y a pas besoin d'installer quoi
que ce soit de particulier dans le réseau local ou les équipements
CPE. Et l'adresse bien connue étant
immuable, on peut la mettre en dur dans les applications PCP, sans
avoir besoin de l'obtenir du système
d'exploitation. (Personnellement, je trouve cela un peu
optimiste : comme cette option anycast est
nouvelle, et qu'elle ne sera pas forcément déployée partout,
l'application aura toujours besoin d'un « plan B » en demandant au
système d'exploitation « une idée de l'adresse IP du serveur PCP ? »)
Le comportement du client et du serveur PCP est décrit dans la section 2 du
RFC. La liste des serveurs PCP possibles pour le client (section 8.1, étape 2 du
RFC 6887) s'enrichit des adresses
anycast bien connues. Le traitement de cette
liste continue à suivre la norme PCP du RFC 7488. Le serveur, lui, a juste à écouter sur les
adresses anycast bien connues, en plus de ses
adresses habituelles. Le RFC ne le mentionne apparemment pas, mais
l'administrateur réseaux doit aussi évidemment configurer le
routage pour que la route vers le serveur PCP soit annoncée
partout, et appliquée.
L'anycast peut être déroutant au début pour
les administrateurs réseaux et la section 3 du RFC rappelle donc
quelques règles de déploiement (en plus des documents existants
sur l'anycast, RFC 4786
et RFC 7094). Par exemple, si le réseau a
deux connexions vers l'extérieur, chacune avec son propre serveur
PCP, l'anycast ne va pas forcément aider car le message
PCP du client ne sera reçu que par un seul des deux serveurs (même
si tous les serveurs ont été configurés pour écouter sur l'adresse
anycast).
Si le routage est toujours symétrique, ce n'est pas un
problème, car le serveur PCP qui recevra le message envoyé à
l'adresse anycast est également celui qui verra
passer tout le trafic, et pourra donc faire ce qui lui a été
demandé par le client PCP. Même si le routage change, et qu'on
passe subitement par un autre lien, avec un autre serveur PCP, ce
n'est pas grave (c'est l'équivalent du redémarrage d'un serveur
PCP, cas qui est géré par les clients PCP).
Mais, si le routage est asymétrique... Eh bien, dans ce cas,
c'est fichu, c'est une limite de PCP plus que de ces adresses
anycast. La seule solution est de développer un
mécanisme (qui n'existe pas encore) pour synchroniser deux
serveurs PCP.
La section 4 de notre RFC rappelle les enregistrements des deux
adresses à l'IANA, dans les registres
d'adresses spéciales IPv4
et IPv6.
(Les fanas de sécurité peuvent lire la section 5 mais il n'y a
pas grand'chose à dire d'original : les messages PCP,
anycast ou pas, peuvent être attaqués comme
tous les autres paquets IP, ni plus, ni moins.)
Pour l'instant (PCP est, de toute façon, très peu déployé), je
ne crois pas que quiconque utilise déjà ces adresses anycast.
