Résumé

  • Le RFC 5192 autorise un serveur configuré à envoyer l’option PAA même lorsque le client ne l’a pas explicitement demandée. La présence dans la réponse ne constitue donc ni un choix du client ni un accord sur la politique de sécurité.
  • La liste est ordonnée et le PaC doit essayer les adresses dans cet ordre. Ce pouvoir de séquencement ne certifie ni la santé des PAA, ni leur identité, ni le succès d’une future session PANA.

Une trace réseau contient souvent deux vérités qui deviennent une fausse histoire quand on les fusionne. Le client peut ne pas avoir placé l’option PAA dans sa Parameter Request List ou son Option Request Option. Le serveur, s’il est configuré avec une liste de PAA, devrait néanmoins la fournir. Le RFC 5192 prévoit précisément cette combinaison.

La réponse est alors conforme. La phrase « le client a demandé PANA » ne l’est pas. Elle attribue à la réception une volonté que seul le message de requête aurait pu établir.

Cette nuance est le début d’une chaîne plus large. Demander une option, la recevoir, la décoder, conserver son ordre, tenter une adresse et terminer PANA sont six événements. Une base qui les réduit à « PAA trouvé » ne dispose plus d’un état ; elle dispose d’un récit impossible à vérifier.

Deux paquets, deux autorités

La requête DHCP décrit ce que le client sollicite. La réponse décrit ce que le serveur fournit. Le RFC 5192 recommande au PaC de demander l’option, mais recommande également au serveur configuré de l’envoyer même sans demande explicite.

Il faut donc conserver les deux messages avec leur identifiant de transaction, leur famille d’adresses, l’interface, l’identité de serveur disponible, le chemin de relais et l’horodatage. Une seule ligne agrégée ne permet pas de savoir si l’option était sollicitée, spontanée, répétée ou apparue lors d’un échange ultérieur.

Cette séparation évite aussi une erreur de gouvernance. Une configuration de serveur peut exprimer une décision d’exploitation : annoncer certains candidats dans un certain ordre. Elle ne peut pas fabriquer rétroactivement le consentement du client ni modifier la politique de sécurité que celui-ci doit appliquer.

L’ordre doit survivre au stockage

L’option DHCPv4 136 transporte des adresses de 32 bits et exige une longueur multiple de quatre. L’option DHCPv6 40 transporte des adresses de 128 bits et exige une longueur multiple de seize. Dans les deux cas, les PAA sont placés par ordre de préférence et le client doit essayer les enregistrements dans l’ordre reçu.

Une interface d’administration qui trie les adresses pour les rendre plus lisibles change donc le comportement. Une table relationnelle qui déduplique sans garder les positions peut faire la même chose. Même une normalisation apparemment innocente—IPv4 puis IPv6, ou ordre numérique—peut substituer la préférence de l’outil à celle du serveur.

Le reçu doit contenir les octets bruts, la longueur déclarée, le résultat de validation, la liste décodée avec son indice et un hash de version. Chaque tentative référence ensuite cette version et cet indice.

L’ordre ne prédit pas la disponibilité. Il prescrit seulement le premier essai. Un PAA préféré peut ne pas répondre ; le deuxième peut établir PANA. Le journal doit alors garder l’échec du premier au lieu de ne retenir que le vainqueur.

Une option n’est pas une négociation

Le texte normatif est catégorique : ces options servent uniquement à découvrir des PAA. Elles ne doivent pas négocier l’emploi de PANA. Leur présence ne signifie pas que le réseau impose PANA ; leur absence ne signifie pas qu’il autorise à s’en passer.

La raison est une attaque de baisse de sécurité. Si la suppression d’une option suffisait à désactiver PANA, un acteur capable d’altérer la réponse DHCP pourrait faire choisir un mécanisme moins robuste, voire aucun mécanisme.

Le système doit donc représenter absent, présent valide et présent invalide comme des observations. La règle « PANA requis » provient d’une autre source de politique. Si une méthode locale de secours existe, elle doit être nommée et versionnée ; elle n’est pas cachée dans le silence de DHCP.

Cette discipline permet d’expliquer un incident sans réécrire la norme. Une option manquante peut déclencher une autre découverte. Elle ne vote pas contre PANA.

Les longueurs sont des contrôles de structure

Les multiples de quatre et de seize ne sont pas des détails de présentation. Ils rendent possible une partition exacte du payload en adresses. Un reste d’octets signifie que la structure annoncée ne correspond pas au format.

Le RFC 5192 ne fournit pas un algorithme complet pour réparer un tel message. Une implémentation ne devrait pas transformer silencieusement le reste en zéros, tronquer puis publier une adresse plausible, ou annoncer « liste vide » comme si aucun candidat n’avait été envoyé.

Conserver l’échec de validation protège l’enquête. Option absente désigne un choix ou une omission du message. Option reçue, longueur invalide désigne des données présentes mais non interprétables. Les deux états peuvent empêcher la découverte, mais ils n’ont ni la même cause ni le même niveau de risque.

La préférence vieillit avec son échange

La liste a été apprise sur une interface et dans un échange DHCP déterminé. DHCPv4 et DHCPv6 possèdent des transactions, des serveurs, des relais, des baux, des renouvellements et des rebinding distincts. Ces repères donnent un contexte temporel et topologique à l’option.

Si une réponse ultérieure fournit une autre liste ou un autre ordre, il faut créer une nouvelle version. Une tentative commencée depuis l’ancienne version ne doit pas être rattachée artificiellement à la nouvelle. Sinon l’audit conclura que le client a violé un ordre qu’il n’avait pas encore reçu.

Le RFC 5192 ne décide pas comment faire courir IPv4 contre IPv6, combien de temps attendre, ni quand mettre en cache un échec. Ces choix appartiennent à l’implémentation. Les rendre explicites est plus honnête que d’inventer une règle normative.

La protection est une propriété du paquet observé

Le RFC constate que, dans la plupart des réseaux, l’échange DHCP antérieur à l’authentification d’accès n’est ni protégé en intégrité ni authentifié à l’origine. Une réponse modifiée ou injectée peut conduire le PaC vers un PAA hostile, capable d’intercepter des demandes d’authentification ou de refuser l’accès.

Il existe des mécanismes d’authentification DHCP dans les normes environnantes. Leur existence ne prouve pas leur emploi. Le reçu doit indiquer le mécanisme effectivement vérifié, son résultat et l’identité couverte. À défaut, l’état reste inconnu ou non protégé.

Même une option authentifiée ne mesure pas la santé du candidat. Elle prouve, dans sa portée, l’origine et l’intégrité de la préférence reçue. Le contact et PANA restent des étapes ultérieures.

Un registre d’essais, pas une case « découvert »

Le modèle opérationnel commence par la requête et la réponse. Il enregistre ensuite la validation et la liste immuable. Pour chaque adresse : rang, famille, heure de début, observation réseau, message PANA éventuel et raison terminale.

Le candidat sélectionné est un lien vers une session PANA, pas une mutation qui efface les autres. Si aucun ne réussit, tous les échecs restent visibles. Si l’option n’était pas demandée, cette vérité reste visible elle aussi.

La doctrine des couches de réalité de Heng Lu interdit ici une commodité très tentante : faire parler le dernier enregistrement au nom de tous les précédents. Une réponse peut livrer une liste sans prouver une demande. Une liste peut guider un essai sans prouver un service. La clarté consiste à laisser chaque reçu garder sa propre voix.

Sources

  1. RFC 5192 HTML
  2. RFC 5192 texte
  3. Notice RFC 5192
  4. Datatracker RFC 5192
  5. Historique RFC 5192
  6. Références RFC 5192
  7. Errata RFC 5192
  8. RFC 2131
  9. Notice RFC 2131
  10. RFC 2132
  11. RFC 8415
  12. Notice RFC 8415
  13. RFC 3315
  14. RFC 5191
  15. RFC 3748
  16. RFC 3118
  17. Paramètres BOOTP/DHCP de l’IANA
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy