Mon blog

Le RFC 6887 normalise le protocole PCP (Port Control Protocol) qui permet de contrôler un routeur NAT ou un pare-feu depuis une machine cliente, par exemple pour ouvrir un port en entrée lorsqu'on utilise un logiciel de transfert de fichiers pair-à-pair ou bien un logiciel de téléphonie sur IP. PCP fonctionne également dans le cas des CGN. Mais cela ne sert à rien d'avoir des routeurs PCP si la quasi-totalité des applications sur les postes clients n'utilise toujours que le vieux protocole UPnP, certes très limité mais qui est largement déployé. Ce nouveau RFC décrit donc une solution de transition : une passerelle entre UPnP et PCP, permettant de satisfaire les clients UPnP et les serveurs PCP.

Cette passerelle sera typiquement installée dans le routeur CPE (la box). Ainsi, lorsque, par exemple, l'application qui parle UPnP fera un AddPortMapping, la passerelle le traduira en une requête MAP PCP (avec l'option PREFER_FAILURE puisque cette requête, contrairement à AddAnyPortMapping, réclame un numéro de port spécifique et échoue s'il n'est pas disponible ; cf. section 5.6). Si vous aimez les sigles, vous serez ravis car le nom complet de la passerelle est UPnP IGD-PCP IWF pour UPnP Internet Gateway Device PCP Interworking Function.

La section 4 donne les correspondances complètes entre les méthodes UPnP et les méthodes PCP, ainsi qu'entre leurs codes d'erreur. Ainsi, toute passerelle UPnP<->PCP sait qu'elle doit traduire une erreur 8 de PCP (NO_RESOURCES) en une erreur 501 ActionFailed chez UPnP v1 et 728 NoPortMapsAvailable chez UPnP v2 (qui a des codes d'erreur bien plus détaillés). De la même façon, une erreur 2 de PCP (NOT_AUTHORIZED) devient 718 ConflictInMappingEntry en UPnP v1 et 606 Action not authorized en UPnP v2.

La passerelle UPnP<->PCP n'est pas un simple relais, transférant des requêtes dans un sens et les réponses dans l'autre. Elle doit garder un état, la mémoire de toutes les correspondances demandées (section 5.3). Cela permet, par exemple de faire face au fait que UPnP permet de créer une correspondance {adresse interne, port interne, adresse externe, port externe} de durée illimitée, ce que ne sait pas faire PCP (RFC 6887, section 7.1). Dans ce cas, la passerelle enregistre la correspondance et la renouvelle dans le serveur PCP à chaque fois qu'elle approche de l'expiration (section 5.9). D'autre part, des requêtes UPnP d'information comme GetListOfPortMappings ne sont pas relayés au serveur PCP mais traitées en examinant l'état local (section 5.7).

Autre point important de ce RFC : la passerelle peut être sur un routeur NAT ou pas (par exemple, dans certains cas de CGN, le routeur CPE ne fait pas de NAT). Si elle doit faire du NAT, la réception d'une requête UPnP va se traduire par une mise à jour de la table NAT locale et l'émission d'une requête au serveur PCP.

Ah, et pour trouver le serveur PCP à utiliser, comment fait la passerelle ? Comme un client PCP normal (via DHCP, par exemple).