Résumé

  • RFC 5213 transfère la signalisation de mobilité du terminal vers le réseau. Le MAG détecte l'attachement et envoie un PBU pour le compte du mobile ; le PBA positif atteste que le LMA a accepté une déclaration authentifiée et autorisée.
  • Cet accusé ne mesure ni la fraîcheur de l'attachement, ni l'exécution au MAG, ni la réception de l'annonce de routeur, ni la configuration d'adresse, ni la survie de la session applicative. Chacun de ces résultats a son propre producteur de preuve.

Une mobilité sans message du mobile

Proxy Mobile IPv6 part d'une contrainte de déploiement : ne pas imposer une fonction de mobilité particulière à chaque terminal. Dans un domaine administré, le réseau reconnaît l'appareil et maintient son préfixe pendant qu'il change de point d'accès. Le terminal continue d'utiliser les mécanismes IPv6 ordinaires.

Deux rôles portent l'opération. Le Local Mobility Anchor, ou LMA, ancre le préfixe du mobile et conserve le binding cache. Le Mobile Access Gateway, ou MAG, observe l'arrivée au bord du réseau, obtient l'identifiant et le profil du terminal, puis envoie un Proxy Binding Update. Si la demande est recevable, le LMA crée ou renouvelle le binding, associe le préfixe au MAG, prépare son extrémité de tunnel et répond par un Proxy Binding Acknowledgement.

Le succès a une valeur précise. Il signifie que le LMA a traité un message protégé provenant d'un pair habilité à agir pour le terminal nommé. Il signifie aussi que l'ancre a réalisé les opérations que la spécification lui attribue. Ce n'est donc pas un signal faible.

Mais le terminal n'a pas signé ce constat de mobilité. La technologie d'accès a fourni une observation, le système d'identité lui a donné un sujet, la politique a accordé un mandat, puis le MAG a parlé. La réussite du LMA est la réussite d'une représentation déléguée, pas un témoignage de l'appareil.

Le mandat et le fait observé ne sont pas la même chose

RFC 5213 exige une relation de confiance entre MAG et LMA. Les messages de binding doivent être protégés ; la prise en charge d'IPsec est obligatoire. Le LMA doit en outre vérifier que ce MAG est autorisé à mettre à jour ce mobile précis. L'authentification établit l'émetteur, l'intégrité protège la déclaration et l'autorisation en limite le périmètre.

Aucun de ces contrôles ne constitue un second capteur sur le lien d'accès.

La détection d'attachement dépend de la technologie : association radio, événement de port, authentification d'accès ou autre mécanisme. RFC 5213 ne la normalise pas. Le MAG transforme ce résultat extérieur en PBU. Si l'événement est ancien, erroné ou associé au mauvais identifiant, la protection cryptographique transmet fidèlement une prémisse défectueuse.

Le texte de sécurité reconnaît lui-même ce risque. Un MAG compromis peut prétendre qu'un mobile est attaché alors qu'il ne l'est pas. Une entité de confiance pourrait confirmer l'attachement réel avant l'acceptation par le LMA, mais le mécanisme reste hors du périmètre de la RFC. La confirmation de la scène et l'authentification du porte-parole sont donc deux preuves distinctes.

Cette limite éclaire une idée plus générale des notes de Heng Lu : la visibilité ne crée pas un mandat universel, et le mandat ne réalise pas l'exécution. Le MAG dispose d'un pouvoir réel, mais circonscrit. Sa signature ne devient ni un capteur physique ni la voix de l'application.

Un PBA positif ouvre la seconde moitié

L'ordre protocolaire interdit de traiter l'accusé du LMA comme un résultat final. Le LMA accepte le PBU, met à jour son cache, sélectionne le préfixe, établit son extrémité du tunnel et renvoie le PBA. Ensuite seulement, le MAG authentifie cette réponse, met à jour son état local, établit l'autre extrémité, installe le transfert et émet des Router Advertisements sur le lien du mobile.

Le tableau de bord qui s'arrête au statut zéro connaît l'état de l'ancre. Il ignore encore si la périphérie a reçu la réponse et exécuté ses tâches.

Le terminal doit à son tour traiter l'annonce selon Neighbor Discovery. La configuration d'adresse et Duplicate Address Detection obéissent à RFC 4862. PMIPv6 cherche à rendre le déplacement transparent grâce au même préfixe de réseau d'origine. Cette intention n'atteste pas la réception de l'annonce, la validité de l'adresse, la sélection du routeur par défaut ou la circulation des paquets dans les deux sens.

Les extensions ultérieures peuvent identifier plus finement les tunnels avec une clé GRE, attribuer dynamiquement une ancre ou transporter des paramètres de qualité de service. Elles enrichissent le contrôle. Elles ne transforment toujours pas l'objet tunnel en preuve de session applicative.

Le cache dirige les paquets, il ne voit pas la radio

Le binding cache du LMA a une autorité opérationnelle : il détermine vers quel MAG envoyer le trafic. Sa durée de vie, son numéro de séquence et sa génération comptent. Lors d'un transfert, l'ancien MAG peut signaler un détachement tandis que le nouveau annonce un attachement. Les messages peuvent se croiser ou disparaître.

Une entrée non expirée indique que la déclaration acceptée reste valide selon les règles du protocole. Elle n'indique pas que le LMA observe en continu l'appareil. La valeur actuelle est une décision de routage fondée sur un historique de déclarations, et non une mesure permanente de position.

Lors d'un incident, la bonne enquête suit la chaîne. Qui a produit l'événement d'accès et à quelle heure ? Comment l'identifiant a-t-il été obtenu ? L'authentification d'accès et l'autorisation du MAG visaient-elles le même sujet ? Le nouveau MAG a-t-il reçu le PBA ? Le transfert, le tunnel et l'annonce ont-ils été réalisés ? Quand l'ancien chemin a-t-il été retiré ? Quel premier point a perdu le trafic bidirectionnel ?

Un unique indicateur « handover complete » ne répond à aucune de ces questions. Il supprime au contraire les horloges et les responsabilités nécessaires pour y répondre.

Un reçu de transfert par procuration

Un reçu défendable relierait : la technologie, l'observateur, l'heure et la confiance de l'attachement ; la provenance de l'identifiant ; l'authentification d'accès ; l'identité et l'autorité du MAG ; la séquence et la durée de vie du PBU ; une éventuelle confirmation indépendante ; la génération du binding, le préfixe, la route et le tunnel au LMA ; le PBA et sa réception authentifiée au MAG ; le tunnel et le transfert côté MAG ; l'émission et la réception de l'annonce ; l'adresse et DAD au terminal ; les sondes bidirectionnelles ; l'effet applicatif ; le retrait de l'ancien état.

Ce reçu relève de l'analyse éditoriale de BTW, pas d'une nouvelle obligation de RFC 5213. Il sert à conserver les séparations que le protocole contient déjà lorsque les événements alimentent l'automatisation et les rapports de direction.

La primauté du code en fonctionnement n'invalide pas le registre. Elle lui assigne une portée. Le cache du LMA peut légitimement orienter le trafic. Il ne peut pas rendre rétrospectivement vraie une observation d'accès. Le MAG peut représenter le mobile dans le protocole. Il ne peut pas représenter la réception de l'annonce ou l'expérience d'une application qu'il n'observe pas.

Une architecture de mobilité mature ne demande pas à un seul accusé de tout prouver. Elle sait montrer où finit la déclaration du mandataire et où commence le résultat du système.

Sources

  1. RFC 5213 en HTML
  2. IETF Datatracker : RFC 5213
  3. Fiche RFC 5213
  4. Historique du document RFC 5213
  5. RFC 6543 — MAG et interfaces multiples
  6. RFC 7864 — mise à jour de la base PMIPv6
  7. RFC 3775 — mobilité IPv6
  8. RFC 4283 — option Mobile Node Identifier
  9. RFC 4832 — terminologie de mobilité
  10. RFC 4861 — découverte des voisins IPv6
  11. RFC 4862 — autoconfiguration IPv6
  12. RFC 4301 — architecture de sécurité IP
  13. RFC 4303 — Encapsulating Security Payload
  14. RFC 4306 — Internet Key Exchange
  15. RFC 2473 — tunnel IPv6 générique
  16. RFC 5845 — clé GRE pour PMIPv6
  17. RFC 6463 — attribution dynamique du LMA
  18. RFC 8127 — options de qualité de service PMIPv6
  19. Heng Lu — primauté du code en fonctionnement