Résumé
- Hors de son réseau mère, un routeur mobile doit s’enregistrer avant de lancer DHCPv6 Prefix Delegation, alors même qu’il ne connaît pas encore les préfixes qui pourront lui être attribués.
- La RFC 6276 réserve l’ajout d’un préfixe au Binding Cache Entry à un bail DHCPv6 PD valide : l’enregistrement et la réponse DHCPv6 ne deviennent donc pas, à eux seuls, une preuve de transfert ou d’accessibilité.
Dans un journal d’exploitation, « Binding Acknowledgement reçu » ressemble à une conclusion. Le routeur a contacté son agent mère, une association Mobile IPv6 existe, et l’on pourrait être tenté d’annoncer qu’un réseau mobile est déjà joignable. La RFC 6276 impose pourtant une chronologie plus étroite. Le routeur mobile situé hors de son réseau mère doit envoyer un Binding Update avant de commencer l’échange DHCPv6 de délégation de préfixes, car il n’a pas encore nécessairement demandé les préfixes qu’il utilisera.
Cette antériorité sépare la relation d’enregistrement du choix du préfixe. La RFC de juillet 2011, DHCPv6 Prefix Delegation for Network Mobility (NEMO), compte Wassim Haddad parmi ses auteurs. Elle définit comment configurer des préfixes sur les liens situés derrière un routeur mobile ; elle ne transforme pas l’auteur, l’agent mère ou un accusé de réception en preuve d’un réseau réel en fonctionnement.
La première pièce est donc l’enregistrement. Hors du réseau mère, le routeur mobile est le requesting router DHCPv6 et l’agent mère le delegating router. Le routeur joue aussi un relais DHCPv6 co-localisé. Mais avant Solicit, Advertise, Request et Reply, il doit se faire enregistrer par l’agent mère avec un Binding Update implicite. Le RFC donne exactement la raison : le routeur peut ne pas avoir encore demandé de préfixe. Cette étape ne dit ni quel préfixe sera choisi ni combien de temps il sera valable.
La deuxième pièce est la délégation. La RFC 3633 décrit le modèle général : le delegating router sélectionne les préfixes, les renvoie au requesting router, et celui-ci devient responsable des préfixes délégués pendant leur durée de validité. Dans le cas de la RFC 6276, l’agent mère répond à la séquence DHCPv6 avec les préfixes demandés. Une Reply est donc un reçu de délégation avec des conditions de durée. Elle ne montre pas qu’un nœud en aval a configuré une adresse, qu’un tunnel a fait passer un paquet, ou qu’un destinataire a fourni un service.
La troisième pièce est celle que les raccourcis effacent. Une fois la signalisation DHCPv6 achevée, l’agent mère doit ajouter les préfixes délégués à son cache de liaisons. La section de sécurité est encore plus précise : il ne doit ajouter un préfixe au Binding Cache Entry du routeur mobile que si celui-ci détient un bail DHCPv6 Prefix Delegation valide pour ce préfixe. Sans bail valide, il ne doit pas l’ajouter. La RFC indique que cette règle évite que l’agent mère transfère du trafic adressé à des préfixes qui n’ont pas encore été délégués.
Il s’agit d’une autorisation de plan de contrôle attachée à un préfixe, et non d’une livraison. Elle établit que l’agent mère peut inscrire le préfixe dans sa structure de liaisons selon la condition définie. Elle n’établit pas qu’un paquet a été intercepté ou encapsulé, que le routeur est encore accessible, qu’un lien aval contient un hôte, ni qu’une application a terminé une action. Ces affirmations dépendent de capteurs, d’horodatages et de critères propres.
Lire la Reply DHCPv6 comme une preuve de transfert est l’erreur inverse. Le texte place l’entrée de cache après l’achèvement de la signalisation et la lie au bail valide. Une enquête doit conserver les raccords : identités du routeur et de l’agent mère, Binding Update et son accusé, transaction DHCPv6, préfixe, IA_PD si disponible, bail et durée, modification du cache, puis une observation de paquet distincte si le sujet est le trafic.
La RFC 6275 rappelle la limite du décor. Mobile IPv6 ne prétend pas résoudre tous les problèmes liés aux réseaux sans fil ou mobiles, notamment la joignabilité partielle, le contrôle d’accès et la découverte de services. La RFC 6276 ajoute un chemin de délégation défini ; elle ne certifie aucun tunnel, réseau visité, client, trajet ou résultat de production.
Les notes de Heng Lu fournissent ici une discipline de lecture, non une preuve supplémentaire : conserver le fait minimal que chaque mécanisme rend observable. L’enregistrement reste un enregistrement ; la délégation reste une délégation ; le bail valide et le cache décrivent l’autorisation de l’agent mère pour un préfixe. Les paquets et les effets applicatifs ont leurs propres preuves. L’attribution à Haddad est elle aussi limitée : il a coécrit une norme collective, sans devenir l’opérateur d’un réseau NEMO réel.
Sources
- https://www.rfc-editor.org/rfc/rfc6276.html
- https://www.rfc-editor.org/rfc/rfc3633.html
- https://www.rfc-editor.org/rfc/rfc6275.html
- https://www.rfc-editor.org/rfc/rfc3963.html
- https://datatracker.ietf.org/person/Wassim.Haddad%40ericsson.com
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
