Résumé

  • Les services ONC RPC pouvaient choisir leurs ports de transport à l’exécution ; le portmapper de la RFC 1057 offrait au client un point fixe où retrouver ce choix.
  • L’enregistrement associait programme, version et transport à un port sur une machine donnée. C’était une réponse d’annuaire, pas une preuve d’identité ni de disponibilité.

Une adresse connue, un port qui pouvait changer

Imaginons qu’un administrateur relance le service de fichiers d’une machine. Le processus serveur peut demander un port disponible au lieu de dépendre d’un numéro réservé à l’avance pour tout le réseau. Mais le client qui connaît l’adresse de l’hôte et le programme RPC recherché doit encore savoir où envoyer son appel. Si chaque service devait posséder son port fixe mondialement coordonné, un espace de ports réduit deviendrait un registre encombré pour des programmes nombreux et évolutifs.

La RFC 1057, publiée par Sun Microsystems en juin 1988, décrit une autre organisation. Le numéro de programme et la version indiquent ce que veut le client ; TCP ou UDP désigne le transport. Un portmapper local, joignable au port bien connu 111, relie ces identifiants au port choisi par le serveur. Le client consulte d’abord le mapper, puis contacte le service. L’appel RPC et sa résolution de liaison sont deux étapes différentes.

La procédure PMAPPROC_SET enregistre le service. Le serveur transmet au mapper de la même machine son numéro de programme, sa version, le protocole de transport et le port d’écoute. Le mapper refuse un doublon pour le même triplet programme-version-protocole. Quand le service cesse, PMAPPROC_UNSET retire l’inscription. Le client appelle PMAPPROC_GETPORT ; zéro signifie qu’aucune correspondance n’est enregistrée pour ce triplet.

La répartition des rôles est simple : le service choisit où écouter ; le mapper rend ce choix consultable à un point prévisible ; le client utilise le port renvoyé. Le point de résolution est conventionnel, tandis que le point de service peut varier.

Ce que la réponse ne disait pas

La réponse du mapper était limitée à l’état de son registre local. La RFC 1057 ne transforme pas GETPORT en vérification de bout en bout, en preuve qu’une route réseau fonctionne ni en déclaration cryptographique sur le programme qui occupe ce port. Le client doit encore établir la connexion, appeler la procédure et interpréter le résultat. Un service arrêté peut laisser une inscription périmée : la découverte aboutit alors que l’appel échoue. À l’inverse, l’absence de correspondance signale un problème de liaison.

« Trouvé » peut sembler plus fort que « inscrit ». Un numéro de port indique où le service a été enregistré comme écoute ; il ne garantit ni l’arrivée des paquets, ni l’acceptation du client, ni l’exécution de la procédure. La RFC traite séparément l’authentification et les propriétés du transport : le portmapper ne les remplace pas.

Cette table n’était pas un registre mondial de tous les programmes RPC. Elle vivait sur la machine qui hébergeait le service. Le client devait connaître l’adresse de cette machine par une autre source, puis demander à son mapper le port de transport. La découverte était ainsi distribuée entre plusieurs couches : le nom ou la configuration fournissait l’hôte, le numéro de programme et la version désignaient l’interface, et le mapper indiquait le point de transport.

La RFC décrivait aussi PMAPPROC_DUMP, qui énumérait les inscriptions, et PMAPPROC_CALLIT, conçu pour les appels diffusés. Le client envoyait sa requête au port fixe du mapper, à l’adresse de diffusion ; chaque mapper qui la recevait pouvait appeler le service enregistré localement. Le mapper ne répondait que si l’exécution réussissait ; sinon, il restait silencieux. Cela rendait possible une diffusion vers des ports différents selon les machines, sans garantir la livraison ni dresser l’inventaire complet des répondants.

Les plages de numéros de programme ajoutaient une règle de coordination. La RFC 1057 séparait les blocs définis par Sun, définis par les utilisateurs, transitoires et réservés. Le nom logique du programme restait donc distinct du port de transport variable : l’un identifiait le service RPC, l’autre l’endroit où son instance écoutait.

De la table TCP/UDP aux adresses universelles

La première version de portmapper décrite était liée aux ports TCP et UDP. En 1995, la RFC 1833 documenta la version 2 de Port Mapper ainsi que les versions 3 et 4 de RPCBIND. Elle expose la même difficulté : le port ou sélecteur de transport peut varier, alors que le client a besoin d’un point de consultation fixe à l’adresse du serveur. RPCBIND représentait les adresses de transport sous forme de chaînes dites universelles et ajoutait un identifiant réseau ; la liaison ne se limitait donc plus aux seuls ports TCP/UDP.

Ce texte ultérieur éclaire la portée du choix de 1988. La RFC 1057 ne rendait pas le programme RPC indissociable d’un port donné. Elle définissait un rendez-vous capable d’associer programme et version à un écouteur propre au transport. RFC 5531, plus tardive, explicite à son tour l’indépendance entre le protocole des messages RPC et les mécanismes de liaison et de rendez-vous.

Le bénéfice était circonscrit : si client et serveur partageaient une convention de consultation, le client n’avait pas besoin de connaître à l’avance le port du service. Cela économisait des ports fixes et laissait les instances choisir localement. En contrepartie, l’appel dépendait d’une conversation préalable et d’un état qui devait suivre le démarrage, l’inscription, l’arrêt et le retrait du service.

Ces RFC décrivent des mécanismes, pas la fréquence des déploiements historiques ni leur fiabilité mesurée. Elles ne permettent pas de quantifier les inscriptions périmées ou la rapidité de leur correction. La conclusion sûre est architecturale : le portmapper rendait un point RPC découvrable par un rendez-vous local stable ; la joignabilité, l’authentification et l’exécution restaient à établir ensuite.

Documents primaires : RFC 1057 — RPC version 2 ; RFC 1833 — Protocoles de liaison ONC RPC ; RFC 5531 — ONC RPC version 2.