Résumé

  • DRAP a remplacé un pair DLSw par poste par de nombreux clients légers, un serveur et une seule relation DLSw vers le site central.
  • Le serveur attribuait ou mémorisait les adresses MAC, répondait aux tests d’accessibilité, négociait les capacités, créait les identifiants de session et pouvait conserver les circuits pendant une suspension TCP.
  • Ces signaux ne prouvaient ni identité humaine, ni autorisation, ni provenance authentique, ni livraison de bout en bout ; RFC 2106 ne décrivait aucune authentification et n’était pas une norme Internet.

Réduire les connexions en déplaçant l’état

Le point de départ de RFC 2106 était un problème d’échelle. Faire fonctionner DLSw sur chaque poste distant faisait croître le nombre de sessions TCP vers le site central avec le nombre de postes. Un protocole conçu pour relier des commutateurs arrivait jusqu’à l’extrémité utilisateur.

DRAP a changé la hiérarchie. Les postes sont devenus clients d’un serveur proche ; le serveur seul a gardé la relation de pair DLSw avec le routeur central. Plusieurs rattachements locaux pouvaient ainsi partager un seul lien logique vers le réseau central. La complexité n’a pas disparu : elle s’est déplacée vers une passerelle chargée de se souvenir et de parler pour les clients.

C’est une frontière éditoriale précise. RFC 1434 portait sur deux liaisons LLC locales et un transport commun ; RFC 2024 rendait visibles, dans une MIB, les états d’annuaire, de cache, de transport et de circuit de DLSw ; RFC 2043 séparait deux admissions SNA sur PPP ; RFC 2097 traitait l’admission des noms NetBIOS. RFC 2106 porte sur l’agrégation et le pouvoir opérationnel confié au serveur.

Une MAC virtuelle n’était pas une pièce d’identité

Un poste raccordé par PPP pouvait disposer d’une adresse IP sans adresse MAC de réseau local. Le serveur DRAP pouvait lui attribuer une MAC virtuelle. Si le client proposait une adresse non nulle, le serveur en vérifiait l’unicité et la conservait. Le client pouvait aussi préenregistrer MAC et IP afin de permettre une session initiée par le serveur.

Cette adresse rendait le routage possible dans le modèle DRAP. Elle ne disait pas quelle personne commandait le poste, si cette personne avait le droit d’atteindre l’application, ni si l’enregistrement provenait d’une source authentique. Le cache du serveur conservait une assertion exploitable, pas une identité vérifiée.

La sélection du serveur appelle la même prudence. Avec plusieurs adresses configurées, le client pouvait interroger plusieurs serveurs et retenir le premier répondant. Le premier retour établissait une disponibilité et une latence à cet instant ; il ne désignait pas une autorité administrative légitime.

Chaque message attestait une transition limitée

CAN_U_REACH interrogeait le serveur ; I_CAN_REACH rendait son appréciation de l’accessibilité. START_DL demandait une station de liaison et DL_STARTED signalait sa création. Des identifiants d’origine et de réception distinguaient les circuits. L’échange de capacités fixait notamment la MAC, la prise en charge de NetBIOS, les SAP et l’aptitude du client à écouter une nouvelle connexion TCP.

Une réponse positive prouvait que le serveur se déclarait capable d’atteindre la cible. Elle ne prouvait pas une livraison applicative. Une liaison démarrée attestait une transition locale, non l’autorisation de l’usage. Un identifiant nommait un état interne, sans fournir à lui seul sa provenance.

RFC 2106 utilisait une connexion TCP bidirectionnelle par couple client-serveur, sur le port 1973. Il permettait aussi de suspendre TCP tout en maintenant les circuits de liaison. À l’arrivée de nouvelles données, le client se reconnectait sans recommencer l’échange de capacités. Les keepalive facultatifs mesuraient la réponse du pair ; après trois échecs, la recommandation était de fermer TCP et les circuits.

Ainsi, « connecté » n’était pas un fait unique. Une socket pouvait disparaître alors qu’un circuit logique demeurait. Un keepalive pouvait prouver une réponse, pas l’aboutissement d’une transaction. Le protocole distinguait ces couches ; l’exploitation doit conserver cette distinction.

Un instantané Informational

Publié en février 1997, RFC 2106 avait le statut Informational et précisait qu’il ne définissait pas une norme Internet. Il ne décrivait aucun mécanisme d’authentification et ne comportait pas de section Security Considerations. Historiquement, il faut lire cette absence sans lui faire dire davantage : le texte spécifiait une adaptation d’accès distant, non une architecture d’identité.

RFC 2114 l’a rendu obsolète le même mois, sous le nom de DCAP, en ajoutant des options de découverte tout en conservant le cœur client-serveur. Un numéro de RFC, un port enregistré ou une mise en œuvre interopérable peuvent rendre un dispositif exploitable. Aucun ne suffit, seul, à démontrer un consensus normatif durable.

Sources