Résumé

  • La sous-option 10 de RFC 3634 contient une liste d’adresses IPv4, par blocs de quatre octets, rangées par priorité décroissante. Elle ne contient ni domaine Kerberos, ni transport, ni port, ni mesure de disponibilité.
  • Recevoir la configuration, l’installer, choisir une adresse, la joindre, authentifier le KDC, obtenir un ticket et établir le lien SNMPv3 attendu sont des faits différents.
  • Le basculement doit être gouverné comme une décision locale traçable : version de liste, règle de sélection, classe d’échec, budget de reprise, identité du domaine et résultat applicatif.

Une liste courte, une portée plus courte encore

RFC 3634 répond à un besoin précis de CableHome : donner à une passerelle résidentielle l’adresse d’un KDC utilisé au début d’une authentification Kerberos, elle-même préalable à une relation SNMPv3 sécurisée. La sous-option porte le code 10, une longueur et au moins une adresse IPv4. La longueur doit être un multiple de quatre. Plusieurs adresses sont émises de la plus haute à la plus basse priorité.

Ce format ne dit pas que la première répond. Il ne lie pas l’adresse à un domaine, un protocole de transport ou un port. Il ne donne ni poids, ni durée de validité, ni résultat de sonde, ni empreinte cryptographique. Le destinataire reçoit une direction, pas un état du monde.

RFC 3495 rend cette limite particulièrement nette : le domaine Kerberos, les temporisations et reprises AS, les temporisations et reprises AP et d’autres paramètres du dispositif CCC sont des sous-options distinctes. Leur présence autour de l’adresse ne les fusionne pas avec elle.

Priorité ne veut pas dire disponibilité

Le mot priorité est souvent réinterprété par l’exploitation. « Premier » devient « actif », puis « sain ». RFC 3634 n’autorise pas cette chaîne. Il impose l’ordre d’émission, mais ne décrit pas entièrement le comportement du client : durée d’attente, erreurs déclenchant le passage au suivant, mémoire des échecs ou retour vers le premier.

Deux versions logicielles peuvent donc recevoir les mêmes octets et suivre des chemins différents. La preuve utile n’est pas seulement la liste, mais la décision prise par chaque client à partir de cette liste.

La comparaison avec DNS SRV aide à nommer les dimensions absentes. RFC 4120 associe service, transport, domaine, TTL, priorité, poids, port et cible. RFC 2782 définit une sélection parmi les cibles. Mais même ce modèle précise que le poids est statique et non une mesure dynamique de charge. Plus d’attributs ne transforme toujours pas la configuration en télémétrie.

RFC 6784 a ensuite séparé, pour DHCPv6, priorité, poids, transport, port, adresse IPv6 et domaine. Il confirme que ces éléments méritent des champs différents ; il ne modifie pas rétroactivement RFC 3634.

Un échec d’authentification peut rester un incident

RFC 3634 s’appuie sur la sécurité de DHCP et n’en ajoute pas. Une adresse incorrecte peut détourner le trafic ou provoquer un déni de service. Le texte évoque le filtrage CMTS, les certificats, l’authentification Kerberos mutuelle, l’isolement réseau et les pare-feu comme protections ou hypothèses.

Si un faux KDC échoue ensuite à s’authentifier, la frontière cryptographique a fonctionné. Cela n’annule pas le coût : délai, trafic, validation de certificat et charge synchronisée sur une flotte. « Bloqué en sécurité » et « sans impact » ne sont pas synonymes.

L’appartenance à une plage autorisée n’est pas davantage une identité complète. Il faut encore prouver le domaine visé, la clé ou le certificat attendu, l’échange concerné et le résultat qu’on prétend annoncer.

Reconstituer la chaîne

Le premier reçu conserve le serveur DHCP, son authentification éventuelle, la transaction, l’époque de configuration et les octets bruts. Le second établit que le client a accepté et installé la liste. Le troisième explique son choix : version, rang, délai, tentative précédente et règle de basculement.

Viennent ensuite la route et le contact réseau, puis l’identité cryptographique du KDC et le domaine. La réponse AS ou TGS doit être corrélée à sa requête. L’authentification applicative et l’état SNMPv3 arrivent encore après. Chacun de ces étages a un propriétaire et un mode d’échec propres.

Un DHCPACK valide ne prouve donc pas l’obtention d’un ticket. Un ticket ne prouve pas que l’opération de gestion a réussi. Une adresse en tête ne prouve pas qu’elle a même été essayée.

Limite de preuve

Cet Article ne désigne aucun opérateur, KDC, domaine, passerelle, CMTS, abonné, incident ou déploiement. Le statut Standards Track et l’enregistrement IANA du code 10 prouvent une spécification et une allocation, pas une adoption.

RFC 3634 fonde le mécanisme. RFC 3495 fournit le contexte CCC ; RFC 2131 et RFC 3118 séparent transport DHCP et authentification du message. RFC 4120 et RFC 2782 éclairent la découverte DNS. RFC 6784 est une lignée ultérieure ; RFC 5021 et RFC 6251 maintiennent transport et TLS hors de l’adresse.

Les textes de Heng Lu sur le code exécuté, la spécification minimale, l’autorité et les couches de réalité sont des grilles de lecture déclarées. Ils invitent à séparer ordre symbolique, autorité institutionnelle, choix exécuté et résultat observé ; ils ne prouvent aucun fait de déploiement.

La conclusion tient en une phrase : conserver la priorité comme intention, puis mesurer le choix, l’identité et l’effet.

Sources