Mon blog

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.