Résumé
- La RFC 5149 ajoute une option de sélection de service à la Binding Update Mobile IPv6.
- L’option identifie le service demandé ; elle n’accorde pas elle-même le droit d’y accéder.
- Une seule option peut apparaître et elle précède les options d’autorisation ou d’authentification.
- Le type 20 transporte un identifiant UTF-8 NFKC de 1 à 255 octets.
- L’unicité n’est exigée qu’entre les home agents où ce nœud peut s’inscrire, pas mondialement.
- Le home agent authentifie le nœud puis vérifie séparément l’autorisation pour le service nommé.
- Un refus utilise le statut 151,
SERVICE_AUTHORIZATION_FAILED. - Un changement de service entraîne une nouvelle autorisation et peut supprimer l’ancien binding.
- La sélection peut influer sur préfixe, routage, pare-feu, sécurité, politique et QoS.
- Un correspondent node sans catalogue partagé doit ignorer silencieusement l’option.
- ESP peut cacher la sélection sur le réseau sans prouver le droit ni le résultat.
- Inscription, application des politiques, accessibilité interdomaines et service utilisateur sont des preuves distinctes.
Un identifiant ne traverse pas les politiques
L’identité du terminal ne suffit pas toujours à choisir entre plusieurs services d’un même abonnement de mobilité. La RFC 5149 fournit donc un identifiant dans l’inscription. Le home agent peut s’en servir pour choisir une politique d’adresse ou de préfixe, un routage, un pare-feu, un traitement de sécurité ou une classe de qualité de service.
Ce champ formule une demande. Il ne transporte ni le profil d’abonnement ni la décision d’autorisation. Son ordre dans la Binding Update permet aux mécanismes suivants de protéger la sélection, mais une option correctement protégée peut toujours demander un service interdit.
L’identifiant est une chaîne UTF-8 normalisée NFKC. Sa portée d’unicité est locale aux home agents où le nœud est autorisé. Une forme ressemblant à un nom de domaine ne devient ni une délégation DNS ni une identité universelle.
Le succès local peut restreindre un autre domaine
La RFC cite l’accès simultané à des domaines séparés comme cas d’usage, puis prévient que certains déploiements produisent l’effet inverse. Les services peuvent vivre dans des domaines administratifs différents ou derrière un réseau client qui filtre fortement le trafic entrant et sortant.
Le home agent peut donc accepter l’inscription alors que le domaine de service bloque le retour, que l’accès public disparaît, ou qu’une politique externe n’a jamais été synchronisée. Une Binding Acknowledgement positive décrit le résultat d’inscription du home agent, pas toute la chaîne de livraison.
Lorsque l’option est absente, le home agent traite la requête comme un accès Internet ordinaire. La RFC recommande fortement ce défaut pour éviter une configuration opérateur spécifique, mais ne l’impose pas à tous les abonnés. Même le défaut est une demande définie, non une garantie d’accès.
Changer de service peut supprimer l’état précédent
Le home agent authentifie et autorise d’abord le nœud, puis vérifie que son profil permet le service sélectionné. Le statut 151 refuse la requête en cas d’échec.
Un changement exige une nouvelle autorisation. Deux services peuvent nécessiter des Home Addresses ou Home Network Prefixes différents. Si l’autorisation échoue, le home agent supprime tout binding portant l’adresse ou le préfixe existant ; le terminal qui reçoit le statut 151 doit faire de même.
Le passage n’est donc pas une modification anodine de métadonnée. Une tentative peut détruire un chemin fonctionnel avant qu’un remplacement existe. Le reçu d’exploitation doit conserver état précédent, requête, version d’abonnement, décision, suppression, nouvelle allocation et résultat de retour arrière.
Le catalogue du correspondant n’est pas présumé
Le terminal ne devrait normalement pas envoyer l’option à un correspondent node. Sans connaissance commune des services, celui-ci doit l’ignorer. Dans un même domaine administratif, un catalogue partagé peut permettre un traitement spécifique, mais le même nom ne prouve pas la même version de catalogue ni la même politique effective.
Cette limite sépare nomenclature et exécution. Il faut vérifier le compilateur de politique, le point d’application, la route et le flux réel. L’attribution d’un préfixe reste un résultat de contrôle, pas une preuve de chemin.
Chiffrer la sélection ne valide pas sa vérité
Si le nom du service est sensible, la RFC recommande ESP en mode transport avec chiffrement non nul pour les Binding Updates et Acknowledgements. Cela protège la confidentialité. Cela ne corrige pas un abonnement erroné, n’installe pas un pare-feu et ne prouve pas la disponibilité.
Les valeurs IANA 20 et 151 prouvent une coordination durable des codes. Elles ne recensent ni support actuel, ni déploiement, ni conformité d’un produit. La preuve opérationnelle doit continuer jusqu’au flux utilisateur.
Sources
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