Résumé

  • L’option 137 de DHCPv4 et l’option 51 de DHCPv6 encodent chacune un seul FQDN. Une chaîne bien formée atteste un décodage, non la légitimité de celui qui l’a fournie.
  • Ce FQDN alimente ensuite U-NAPTR et le DNS. La sélection de service, l’adresse, le transport protégé, l’identité du serveur et la réponse LoST sont autant de décisions séparées.
  • Le bon tableau de bord ne demande pas seulement « découverte réussie ? ». Il conserve qui a donné le nom, dans quel contexte réseau, avec quelles protections, et quel résultat a suivi.

Le reçu était syntaxique

Imaginons une séquence d’audit construite, sans prétendre décrire un incident réel. À 08:14:00, un terminal rejoint un réseau d’accès. Une seconde plus tard, un DHCPACK transporte l’option 137. Les octets se décodent en lost.access.example; le nom se termine par l’unique label racine requis. À 08:14:02, la supervision affiche « service LoST découvert ».

À cet instant, personne n’a encore observé de réponse U-NAPTR, de cible de service, d’adresse DNS, d’état de validation, de certificat, d’identité de service, de message XML LoST, de cartographie, d’URI de contact ou d’appel. Le système a reçu une indication de départ et l’a racontée comme une arrivée.

RFC 5223 évite précisément cette confusion. Le réseau d’accès peut exploiter un serveur LoST ou connaître le service d’un tiers. Il remet alors au client un domaine qui servira d’entrée à la procédure DNS décrite pour LoST. Le texte ne fait pas du DHCP l’autorité de cartographie. Il lui attribue une fonction de configuration locale.

Cette modestie n’est pas un manque. Elle empêche qu’un protocole d’amorçage se voie confier, par glissement, la vérité sur la localisation, la compétence d’un service d’urgence et l’issue d’une communication.

Un FQDN exactement, pas une politique cachée

Pour IPv4, OPTION_V4_LOST porte le code 137. Pour IPv6, OPTION_V6_LOST porte le code 51. Les deux utilisent l’encodage DNS par labels et contiennent un seul nom pleinement qualifié. Le client peut les demander dans le mécanisme de requête d’options correspondant.

Il faut prendre au sérieux ce que le champ ne contient pas. Il ne livre pas directement une adresse IP. Il ne livre pas une URI LoST finale. Il n’ordonne pas plusieurs serveurs de secours. Il ne définit pas la durée pendant laquelle une application peut conserver le résultat après un changement de réseau. Son objet est minimal : donner un nom comme point d’entrée.

Un enregistrement d’audit devrait garder le code d’option, les octets bruts, le résultat de décodage, le FQDN exact et la raison d’acceptation ou de rejet. Remplacer ces éléments par une valeur booléenne supprime la possibilité de distinguer une option absente, malformée, modifiée ou simplement non exploitée.

Même l’inscription auprès de l’IANA reste une coordination sémantique. Elle évite que deux implémentations donnent des sens différents au code 137 ou 51. Elle ne certifie pas l’origine de chaque message observé sur un réseau.

Le contexte DHCP a sa propre durée de vie

RFC 2131 décrit l’échange DHCPv4, le choix du serveur, l’accusé de réception et les paramètres associés au bail. RFC 8415 fournit le cadre DHCPv6 actuel. Ce sont des preuves de configuration liées à un échange et à un contexte d’attachement.

Le serveur DHCP identifié dans ce dialogue n’est pas, par ce seul fait, l’opérateur du service LoST nommé. Il peut connaître un tiers. Il peut aussi être correctement autorisé pour le réseau d’accès tout en étant mal configuré. L’autorité pour fournir une configuration locale ne devient pas une compétence universelle sur toutes les juridictions de secours.

RFC 3046 permet au relais DHCP d’ajouter des informations utiles sur le chemin d’accès. Ces données peuvent aider à comprendre par quel segment la demande est arrivée. Elles ne sont ni un certificat de service LoST ni une preuve que la cible finale détient une cartographie à jour.

La mobilité rend la séparation visible. Un appareil peut changer d’interface, de point d’accès, de réseau administratif ou d’adresse alors qu’une application conserve encore le FQDN. Le reçu utile associe le nom au serveur DHCP, au relais éventuel, à l’interface, à l’heure, au bail et à l’événement de renouvellement ou d’invalidation. Sans ces liens, « fourni par le réseau » ne désigne plus un réseau déterminé.

Le serveur pirate figure dans le modèle de menace

RFC 5223 dit explicitement qu’un adversaire capable de modifier ou d’insérer une réponse DHCP peut diriger le client vers un serveur LoST pirate ou vers une adresse invalide. RFC 5069 replace cette possibilité dans les menaces qui touchent le marquage et la cartographie des appels d’urgence.

RFC 3118 spécifie des mécanismes d’authentification et de protection contre le rejeu pour les messages DHCP. On peut en tirer une règle d’audit, pas une statistique de déploiement : il existe une couche de preuve portant sur l’origine et l’intégrité du message. Il faut constater son résultat quand elle est utilisée, et enregistrer son absence quand la politique l’exige. Le simple fait qu’un RFC existe n’autorise pas à écrire « DHCP authentifié » dans un rapport d’exploitation.

Une authentification réussie reste bornée. Elle peut lier le message à un acteur et protéger son contenu. Elle ne rend pas vrai un paramètre périmé, ne confère pas au fournisseur DHCP l’autorité de cartographie, et ne garantit pas que le service désigné répondra.

La discipline de Heng Lu sur le code en fonctionnement conduit à une question simple : quel composant a réellement pris quelle décision vérifiable ? Le client DHCP peut montrer le paramètre accepté. Il ne peut pas témoigner à la place du résolveur, du pair TLS, du serveur LoST ou du centre qui répondra à l’appel.

Après le nom vient la résolution

Le FQDN est une entrée de la procédure U-NAPTR et DNS décrite autour de RFC 5222. Il faut encore interroger, choisir un enregistrement de service, résoudre une cible, obtenir une adresse, établir une connexion et vérifier l’identité attendue.

Chaque jointure possède son propre échec possible. Le domaine peut n’avoir aucun enregistrement pertinent. Le DNS peut répondre trop tard. Une adresse peut être inaccessible. Le pair peut présenter une identité incompatible avec le service demandé. RFC 8446 protège le transport TLS; RFC 9525 précise la vérification de l’identité de service. Un canal chiffré vers la mauvaise cible reste un canal vers la mauvaise cible.

Il faut donc conserver la question U-NAPTR, la réponse choisie, la durée de vie DNS, l’ensemble des adresses, l’état de validation quand il existe, l’adresse effectivement contactée et le résultat de l’identité TLS. Réécrire l’événement DHCP avec l’adresse obtenue plus tard fabriquerait une provenance qui n’a jamais existé.

RFC 8917 attribue au service de validation LoST une étiquette S-NAPTR propre. Cette spécialisation confirme que la découverte sait nommer des rôles différents. Elle ne transforme pas une étiquette en preuve de bonne exécution du rôle.

La cartographie commence après la découverte

Une connexion au pair attendu permet seulement d’envoyer une demande LoST. La réponse peut être une erreur, un avertissement, une redirection ou une cartographie dont la source, la fraîcheur, la frontière et l’adéquation doivent encore être examinées.

L’article RFC 5222 déjà publié traite ce domaine suivant : une cartographie n’est pas un reçu d’appel abouti. Le présent article s’arrête avant lui. L’option DHCP ne peut pas garantir à l’avance le contenu d’une réponse que le client n’a pas encore reçue.

RFC 6739 protège la synchronisation et la provenance des cartographies entre serveurs. Cette assurance de fond ne prouve pas qu’un terminal a reçu une réponse DHCP authentique, vu le bon DNS ou sélectionné le pair voulu. Les deux chaînes ne se rejoignent qu’avec des identifiants et des horodatages conservés.

RFC 6881 situe la découverte dans un parcours d’appel d’urgence plus large. La localisation, la configuration, la découverte, la cartographie, la signalisation et la prise en charge sont interdépendantes. Elles ne partagent pas un même verdict.

Une chaîne de preuve exploitable

L’organisation devrait pouvoir produire, dans l’ordre : le contexte d’attachement; la transaction DHCP; l’identité du serveur et du relais; les protections vérifiées; l’option brute et son FQDN; la durée de validité; le choix U-NAPTR; les réponses DNS; l’identité TLS; le message LoST; la pertinence de la cartographie; la tentative de session; puis l’acceptation du service.

Si un maillon manque, le système peut le dire sans effacer les maillons précédents. « Option reçue, U-NAPTR en échec » est une information opérationnelle. « Découverte verte, appel impossible » est une couleur sans diagnostic.

Sources

  1. RFC 5223
  2. RFC 5223 sur l’IETF Datatracker
  3. Statut de RFC 5223
  4. Historique de RFC 5223
  5. Errata de RFC 5223
  6. RFC 2131
  7. RFC 2132
  8. RFC 8415
  9. RFC 3118
  10. RFC 3046
  11. RFC 5222
  12. RFC 5069
  13. RFC 6881
  14. RFC 8917
  15. RFC 6739
  16. RFC 8446
  17. RFC 9525
  18. Heng Lu — primauté du code en fonctionnement
  19. Heng Lu — spécification initiale minimale et adoption volontaire