Mettre du PCP dans les boxes ne suffit pas, il faut aussi mettre un
relais Upnp-PCP :-)
http://www.bortzmeyer.org/6970.html
Auteur(s) du RFC: M. Boucadair (France Telecom), R. Penno, D. Wing (Cisco)
Chemin des normes
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 client 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).
---
Liste de diffusion du FRnOG
http://www.frnog.org/
