Résumé

  • RFC 1157 définissait agent-addr comme l’adresse réseau de l’objet générant un trap ; RFC 1298 imposait pourtant 0.0.0.0 dans ce champ pour SNMP sur IPX.
  • La source devait être déduite des informations livrées par la couche de transport : réseau IPX, nœud et socket formaient le contexte d’attribution extérieur au PDU.
  • SNMP utilisait le Packet Type 4, le socket 36879 pour les requêtes et le socket 36880 pour les traps ; ces valeurs indiquaient un rôle d’acheminement, pas l’identité durable d’un appareil.
  • La recommandation de 546 octets, l’adresse composée de douze octets et le choix d’IPX rendaient le mapping opérable, sans prouver réception applicative, événement réel, sécurité ou interopérabilité universelle.

La case vide était une consigne, pas un aveu d’ignorance

Dans la définition initiale de SNMP, RFC 1157 attribuait à agent-addr un sens précis au sein du Trap-PDU : l’adresse réseau de l’objet qui générait le trap. Un lecteur pouvait donc s’attendre à trouver dans le message lui-même une indication sur sa source.

RFC 1298 changeait ce geste pour le transport IPX. Le champ devait contenir 0.0.0.0. Il ne fallait ni y encoder une adresse IPX de fortune, ni interpréter les zéros comme la preuve que personne ne connaissait l’origine. Le mapping demandait au gestionnaire SNMP de la déduire à partir des informations fournies par la couche de transport.

Le message et son enveloppe devenaient ainsi deux pièces complémentaires. Le PDU conservait sa structure SNMP, mais l’indice d’origine appartenait au paquet qui l’avait porté jusqu’au gestionnaire. Archiver seulement les octets du PDU revenait à garder une lettre après avoir jeté l’enveloppe que la spécification avait choisie pour l’adressage.

Ce choix ne donnait pas à l’enveloppe un pouvoir illimité. Elle indiquait d’où provenait l’échange selon le transport observé. Elle ne certifiait ni l’identité durable de l’équipement, ni l’organisation qui le contrôlait, ni la personne qui l’exploitait. L’attribution technique et l’authentification restaient deux questions distinctes.

Un datagramme sans promesse de réponse

Publié en mars 1992, RFC 1298 était un mapping Informational de SNMP sur Internet Packet Exchange, non une norme Internet. IPX y était décrit comme un service de datagrammes sans connexion et sans acquittement. Il pouvait porter un message sans établir de connexion et sans produire, par lui-même, la preuve que l’application destinataire l’avait reçu ou traité.

Les messages SNMP circulaient avec le Packet Type 4 d’IPX, appelé Packet Exchange Packet. Cette valeur identifiait la nature attendue du paquet dans le service. Elle ne disait pas quel appareil durable se trouvait derrière la source et ne garantissait pas que le contenu ASN.1 serait compris.

La différence entre émission, transport, réception et action est essentielle pour un trap. Un agent peut fabriquer un PDU ; une pile peut remettre un paquet au réseau ; une interface peut l’observer ; un gestionnaire peut le parser ; une application peut ensuite ouvrir une alerte. Aucun de ces verbes ne contient automatiquement les suivants.

Le trap lui-même rapporte une condition de gestion. Même reçu et décodé, il reste une déclaration. Pour conclure qu’une interface est tombée, qu’une alimentation a cessé ou qu’un service a été affecté, il faut une observation indépendante du phénomène. RFC 1298 définissait le portage, pas la vérité matérielle de l’alerte.

Deux sockets distribuaient les rôles

Le mapping séparait les destinations. GetRequest, GetNextRequest et SetRequest étaient envoyés au socket IPX 36879, soit 0x900F. Les messages Trap étaient envoyés au socket 36880, soit 0x9010. Un chiffre distinguait donc le point d’écoute des échanges sollicités de celui des notifications.

Cette séparation ne créait pas deux identités. Le socket 36880 signifiait « destination réservée aux traps » dans ce mapping, non « appareil qui a subi l’événement ». Le socket 36879 n’authentifiait pas davantage un gestionnaire autorisé à lire ou modifier. Ce sont des rôles d’acheminement, réutilisables par de nombreux participants.

La réponse suivait une règle symétrique mais contextuelle. Un agent adressait GetResponse à l’adresse IPX et au socket depuis lesquels la requête correspondante était arrivée. Le trajet de retour dépendait donc du tuple source observé sur l’enveloppe de la demande. Sans identifiant de requête, message reçu et tuple d’origine, une réponse envoyée à une adresse ne prouvait pas qu’elle répondait à la bonne opération. Et sans observation du retour, la destination calculée ne prouvait aucune livraison.

Ces règles montrent pourquoi un endpoint de transport doit conserver son verbe. Il peut être la destination d’une requête, l’origine observée de cette requête, la destination calculée d’une réponse ou l’origine d’un trap. Employer le même mot « agent » pour ces quatre positions ferait disparaître la direction et la fonction de chaque enregistrement.

Douze octets composaient un endpoint, pas une personne

RFC 1298 définissait IpxTransportAddress sur douze octets. Les quatre premiers portaient le numéro de réseau, les six suivants l’adresse physique du nœud et les deux derniers le socket. La valeur rassemblait donc trois coordonnées de nature différente dans une seule chaîne d’octets.

Cette composition répondait au modèle d’adressage IPX. Elle n’était pas un identifiant universel. Un nœud peut changer de contexte, une adresse peut être réutilisée et un socket décrit un service plutôt qu’un propriétaire. Pour relier le tuple à une fiche d’inventaire, il faut une résolution datée : quelle observation, quelle table, quelle période de validité et quel degré de confiance ont permis d’associer cet endpoint à un appareil ?

La chaîne de preuve doit conserver cette résolution à part. Les douze octets appartiennent au paquet. Le nom durable appartient à un répertoire ou à un inventaire. La preuve d’identité appartient à un mécanisme de sécurité. Les fondre en une seule colonne rend impossible de savoir si une attribution vient du réseau, d’une convention ou d’une authentification réelle.

Le cas agent-addr=0.0.0.0 rend cette discipline particulièrement visible. Les zéros sont une valeur prescrite dans le PDU ; le tuple IPX est l’observation du transport ; le nom humainement lisible est une conclusion ultérieure. Aucun des trois ne remplace les autres.

546 octets ne mesuraient pas tous les chemins

RFC 1298 recommandait que les implémentations acceptent des messages SNMP allant jusqu’à 546 octets. Cette taille devait pouvoir franchir des routeurs qui ne fragmentaient pas. Des messages plus grands n’étaient raisonnables que si la taille maximale le long du chemin était connue, y compris pour les routeurs et les liaisons de données sous-jacentes.

Le nombre était donc une règle prudente d’interopérabilité, pas le résultat d’une mesure universelle. Un paquet de 547 octets n’était pas condamné par définition ; il exigeait davantage de connaissance sur son trajet. À l’inverse, la conformité à 546 octets ne prouvait pas qu’un paquet particulier avait atteint son gestionnaire. Les limites, pannes et politiques du chemin restaient observables séparément.

Le choix du transport déplaçait aussi les fonctions de fragmentation et la population joignable. RFC 1270 expliquait que les services réseau et transport offraient des tailles maximales et comportements différents. Un transport natif pouvait avoir un intérêt dans un environnement non-Internet, mais il pouvait aussi réduire le nombre de gestionnaires et d’agents capables de communiquer.

La commodité locale avait un prix d’interopérabilité

RFC 1270 présentait UDP comme l’unique transport SNMP alors normalisé et nécessaire à la conformité complète. Il associait UDP/IP à la portée et à l’acceptation les plus larges, sans nier qu’un transport natif puisse être pertinent ailleurs. La note de l’éditeur de RFC 1298 recommandait fortement UDP/IP plutôt qu’IPX pour favoriser l’interopérabilité.

Cette préférence ne rendait pas le mapping IPX incohérent. RFC 1298 faisait précisément le travail nécessaire pour qu’un protocole de gestion existe sur un service de datagrammes natif : type de paquet, sockets, règle de réponse, taille, forme d’adresse et traitement spécial du trap. Mais chaque adaptation éloignait l’échange du socle partagé par la communauté SNMP la plus vaste.

Le dilemme n’opposait pas un transport vrai à un transport faux. Il opposait la commodité dans un environnement donné à la capacité de parler avec davantage d’implémentations. L’ubiquité venait de la convention commune ; l’ajustement local venait de l’intégration native.

Enfin, ni RFC 1298 ni RFC 1270 ne discutaient les questions de sécurité. Le tuple source ne devient pas une preuve d’authentification parce qu’il est nécessaire à l’attribution. Il ne démontre ni autorisation, ni intégrité, ni confidentialité, ni résistance à l’usurpation. Un message bien adressé peut toujours porter une affirmation fausse ou provenir d’un acteur non établi par ces documents.

Sources et limites de preuve

Cet article s’appuie sur RFC 1157 — A Simple Network Management Protocol (SNMP), RFC 1270 — SNMP Communications Services et RFC 1298 — SNMP over IPX. Ces textes établissent le sens initial de agent-addr, le débat sur le transport et les règles du mapping IPX. Ils n’établissent aucun appareil réel, aucune identité authentifiée, aucun trap reçu, aucun événement opérationnel, aucune réponse, aucune remédiation ni aucun déploiement actuel.