Résumé

  • Un Counter32, un Gauge32 et un TimeStamp ne partagent ni la même arithmétique ni la même époque ; les lire comme une série continue peut fabriquer une panne ou une réussite.
  • Les trois rôles Mobile IP produisent des traces complémentaires, mais aucune opération de jointure ne transforme automatiquement leurs traces locales en preuve de livraison.

Le piège le plus banal de la RFC 2006 tient dans une soustraction. Deux lectures d’un même compteur semblent produire un débit ; deux valeurs de durée semblent produire un délai. Or Counter32 peut reboucler, un compteur repart après redémarrage, et TimeStamp se rapporte à sysUpTime. Avant de comparer, il faut donc prouver que les deux valeurs appartiennent à la même époque d’exécution.

La durée restante d’un binding pose un autre problème. C’est un Gauge32 observé au sondage, non la chronologie complète d’une session. Sa baisse attendue renseigne ; sa hausse peut refléter un renouvellement ; son absence peut venir d’une expiration, d’un changement de vue ou d’une perte d’état. La RFC définit des valeurs, pas l’histoire qui permettrait de choisir entre ces explications.

Cette discipline arithmétique éclaire le reste du document. En 1996, la MIP-MIB placée sous mib-2 44 n’a retenu qu’un petit ensemble d’objets utiles au diagnostic et à la configuration. Elle a distribué ces objets entre les trois rôles du protocole, précisément parce qu’aucun rôle ne possédait le journal complet.

Reconstituer sans fusionner les témoins

mipEntities indique les rôles pris en charge et mipEnable permet d’activer ou de désactiver Mobile IP. mipEncapsulationSupported annonce une capacité. Aucun de ces objets ne montre qu’un rôle a traité du trafic, qu’une désactivation a interrompu toute découverte, ou qu’un tunnel a effectivement transporté un datagramme.

Le nœud mobile expose un état — au domicile, enregistré, en attente, isolé ou inconnu — ainsi qu’une table des agents étrangers alimentée par leurs annonces. Les entrées expirent avec les annonces. Les compteurs enregistrent sollicitations, annonces, extensions mal formées et déplacements « décidés » par l’implémentation. Le verbe compte : une décision de mobilité n’est pas une preuve de déplacement physique. Un redémarrage « détecté » par un numéro de séquence modifié n’en établit pas la cause.

La table d’enregistrement relie adresse d’agent, care-of address, drapeaux, Identification, durée demandée et restante, heure d’envoi et résultat accepté. Elle forme une mémoire locale des requêtes, réponses et retransmissions. Elle n’est ni une capture de paquets ni un registre mondial de transactions.

L’agent étranger compte les requêtes reçues, relayées ou refusées, les réponses et diverses erreurs. L’agent d’origine conserve, lui, les bindings de mobilité et des statistiques de service globales ou par nœud. Des totaux égaux ne désignent pas nécessairement les mêmes échanges : perte, retransmission, refus, réinitialisation et instant d’échantillonnage s’intercalent. Une ligne de binding prouve un état conservé au moment de la lecture, pas la remise au care-of address ni l’arrivée à l’application.

La dernière violation n’est pas toute l’histoire

Les types ne sont donc pas une annotation de bas de page. Largeur, époque, intervalle et rôle doivent accompagner toute exportation. Sans eux, une base de séries temporelles conserve des chiffres tout en détruisant leur sens.

La sécurité illustre mieux encore cette frontière. La table des associations est indexée par adresse du pair et SPI ; la clé peut être créée par gestion, mais sa lecture renvoie une valeur de longueur nulle. Ce vide protège le secret, il ne prouve pas son absence. Les objets de violation retiennent le dernier contexte signalé et mipAuthFailure peut annoncer un échec de validation. L’adresse rapportée n’identifie pourtant pas une personne, et l’alerte ne distingue pas automatiquement usurpation, hôte compromis ou contexte périmé.

La bonne lecture de la RFC 2006 ressemble moins à un tableau de bord qu’à un dossier de rapprochement. Chaque chiffre garde son rôle, son époque et son instant ; chaque table garde la raison de sa mise à jour ; chaque alerte garde les limites de l’identité qu’elle rapporte. L’opérateur peut alors joindre ces éléments aux journaux d’accès, aux traces de contrôle et aux mesures du plan de données sans leur demander de certifier ce qu’ils n’ont jamais observé.

Sources