Summary

  • RFC 5223 attribue les options DHCPv4 137 et DHCPv6 51 à un unique FQDN de serveur LoST. Le client utilise ce nom comme entrée d’une résolution DNS/U-NAPTR ; il ne reçoit pas directement une adresse de serveur, une autorité authentifiée ou une réponse d’urgence.
  • Le contrôle exige un reçu de chaîne : provenance DHCP, décodage du nom, vue DNS, résultat U-NAPTR, URI et adresse sélectionnées, identité LoST, cartographie puis résultat aval.

Un nom correctement encodé ne dit pas qui l’a mandaté

Le terminal rejoint un réseau et demande l’option LoST. La réponse contient un nom bien formé. Chaque étiquette respecte sa longueur, l’ensemble ne dépasse pas la limite et un seul label racine termine le champ. Pour l’agent DHCP, le traitement est terminé.

Pour l’application d’urgence, il vient seulement de commencer. La réussite du décodage ne prouve pas que l’émetteur avait le mandat de choisir le domaine de découverte. Elle ne dit pas quelle vue DNS répondra, quel enregistrement U-NAPTR sera retenu, quel service se présentera, ni si ce service possède une cartographie actuelle.

RFC 5223 maintient volontairement cette limite. L’option 137 en DHCPv4 et l’option 51 en DHCPv6 transportent un FQDN unique. Ce FQDN devient l’entrée du mécanisme de résolution décrit par LoST et RFC 4848. Le protocole livre un point de départ, pas une conclusion de bout en bout.

La découverte est une suite de transformations

Le champ DHCP possède une sémantique étroite. L’encodage d’étiquettes vient de RFC 1035, la longueur totale reste au plus égale à 255 octets et l’option ne doit contenir qu’un domaine avec une seule racine. Ces contraintes répondent à la question : « pouvons-nous interpréter ces octets comme un nom ? »

La question suivante porte sur la provenance : quel échange DHCP et quel domaine administratif ont fourni le nom ? Puis le client interroge un résolveur. La réponse dépend du temps, du cache, de la vue du résolveur et de la délégation DNS. U-NAPTR transforme encore le nom en URI de service. La connexion qui suit doit établir l’identité du service LoST et appliquer les protections propres au protocole.

La cartographie décrite par RFC 5222 arrive après cette découverte. Elle possède ses propres preuves : emplacement présenté, source, date, expiration, frontière et destination retournée. Même une destination valide ne prouve pas qu’un répondant a traité l’appel. Une sortie de couche devient une entrée pour la suivante, jamais son attestation.

Le réseau d’accès effectue une délégation

Le texte permet au réseau d’accès d’indiquer le domaine d’un serveur qu’il exploite, ou celui d’un tiers qu’il connaît. Ce choix peut rapprocher le service du terminal et simplifier la configuration. Il crée aussi une décision de délégation que l’organisation doit rendre visible.

L’opérateur DHCP, le titulaire du domaine, l’administrateur DNS, l’opérateur LoST et le service d’urgence peuvent être cinq acteurs distincts. Le premier peut configurer un nom sans pouvoir corriger les enregistrements du second. Le service résolu peut changer sans modification de l’option. L’autorité sur la cartographie peut encore appartenir à un autre mandant.

Le dossier doit donc nommer les acteurs : qui a approuvé le domaine, qui possède la zone, qui publie U-NAPTR, quelle identité de serveur est attendue, qui révoque une délégation et qui explique une différence entre deux réseaux d’accès. « Découvert localement » décrit un chemin ; ce n’est pas une attribution de responsabilité.

Le détournement commence avant la requête LoST

La section sécurité de RFC 5223 est directe. Un adversaire capable de modifier une réponse DHCP ou d’en insérer une peut conduire le client vers un serveur LoST malveillant ou lui fournir une adresse inutilisable. Le premier choix dangereux précède la résolution et la requête de cartographie.

Une résolution DNS parfaitement conforme ne répare pas un domaine malveillant. Inversement, une réponse DHCP authentique ne garantit pas tous les enregistrements et services ultérieurs. Chaque frontière réclame son contrôle : origine DHCP, cohérence DNS, interprétation U-NAPTR, authentification du serveur, sécurité LoST, fraîcheur de la cartographie et joignabilité aval.

L’exploitation doit préserver des diagnostics distincts. Absence d’option, option mal formée, domaine sans résultat U-NAPTR, service non authentifié, absence de cartographie et destination injoignable ne sont pas un seul échec de « découverte ». Les fusionner empêche de désigner le propriétaire de la correction.

La proximité annoncée reste une hypothèse à mesurer

RFC 5223 explique qu’un serveur placé près de l’hôte est souhaitable et peut améliorer la résilience lors d’une connectivité intermittente en situation de catastrophe. C’est une justification de conception, pas une mesure de disponibilité, de latence ou de résultat opérationnel dans un réseau nommé.

Un service topologiquement proche n’est pas nécessairement administré par le fournisseur d’accès, autoritaire pour toutes les positions, synchronisé ou accessible pendant chaque panne. La résilience dépend aussi du renouvellement DHCP, du résolveur, des TTL, de l’identité du service, de la réponse de cartographie et de la communication en aval.

Un tableau de bord ne doit donc pas transformer « domaine local reçu » en score de résilience. Il doit montrer les dépendances et les scénarios de rupture effectivement testés.

Limites de la preuve

Les sources ne recensent aucun déploiement actuel des options 137 ou 51. Elles ne prouvent ni compromission DHCP, ni serveur LoST frauduleux, ni appel d’urgence perdu, ni défaut de fournisseur. RFC 3315 est la référence DHCPv6 historique de RFC 5223 et a depuis été remplacé par RFC 8415 ; ce changement de statut ne démontre pas l’usage présent de l’option.

Cette analyse s’arrête avant le sujet déjà attribué à RFC 5222. Elle ne reprend pas la différence entre une cartographie valide et un service d’urgence livré. Son affirmation est antérieure : le FQDN DHCP est une entrée de découverte, et toute autorité au-delà doit être établie séparément.

Conserver un reçu de la chaîne de découverte

Pour chaque événement, enregistrer le réseau, la version DHCP, l’identité observable du serveur, le code d’option, le hash des octets, le résultat d’analyse, le FQDN, la racine, l’heure ou le bail, la vue du résolveur, les enregistrements U-NAPTR, les TTL, l’URI, l’adresse, le contrôle d’identité LoST, les identifiants de requête et de réponse, l’âge de la cartographie et le résultat aval.

Les faits négatifs doivent rester : options absentes, réponses concurrentes, étiquettes invalides, changements inattendus de domaine, erreurs NAPTR, vues DNS divergentes, données expirées, échec d’authentification, repli manuel et service injoignable.

La doctrine de Lu Heng sur la réalité en fonctionnement et le mandant attribuable empêche d’emprunter les preuves. Le réseau d’accès répond de sa configuration DHCP, le gestionnaire de zone de la délégation DNS, l’opérateur LoST de son service et l’application de l’issue. La direction doit exiger leur raccordement.

Sources

Dossier complémentaire

  1. RFC 5223 en texte brut
  2. Fiche RFC 5223
  3. RFC 5223 dans Datatracker
  4. Errata de RFC 5223