Résumé

  • Un PvD est une frontière de cohérence entre adresse source, DNS, routeur et autres paramètres. Son FQDN, ses indicateurs et son numéro de séquence identifient et actualisent cette frontière ; ils ne constituent pas un classement des chemins.
  • La preuve se construit par étapes : récupération des informations supplémentaires dans le même PvD, authentification du nom, contrôle de l’identifiant, de l’expiration et des préfixes, puis décision locale et observation de l’adresse source, du résolveur et du prochain saut réellement utilisés.

Un domaine valide, mais inadapté à cette connexion

Un poste reçoit deux PvD explicites sur le même lien. Le premier porte le nom d’un opérateur connu. Son indicateur H annonce des informations supplémentaires et son numéro de séquence vient de changer. Une console le met en évidence et conclut qu’il a été choisi.

Le document JSON obtenu par HTTPS raconte autre chose : noInternet: true. Ce domaine dessert correctement un environnement local restreint. Le second PvD est le seul qui convienne à une session vers l’Internet public, et la politique de l’hôte le retient pour le navigateur.

Il n’y a aucune contradiction protocolaire. Le premier PvD est identifié, frais et exploitable. Il n’est simplement pas éligible pour cet usage. La console a confondu identité, actualité, aptitude et décision exécutée.

Cette confusion est précisément celle que l’architecture des PvD cherche à éviter. Sur un hôte multiréseau, une adresse apprise dans un contexte peut être associée au DNS ou au routeur d’un autre. Chaque élément semble valable, mais leur assemblage ne l’est pas. Le problème ne se résout pas en élisant une interface préférée ; il faut conserver la provenance de la configuration.

Une frontière de configuration, pas une interface

La RFC 7556 définit un Provisioning Domain comme un ensemble cohérent d’informations de configuration réseau. Il peut contenir des préfixes d’adresses sources, des serveurs DNS, des suffixes de recherche, un mandataire et des passerelles par défaut.

Plusieurs PvD peuvent être présents sur un même lien, tandis qu’un PvD peut couvrir plusieurs liens. L’assimiler à une carte réseau efface donc sa propriété essentielle. La frontière est logique et administrative : elle indique quelles informations peuvent être utilisées ensemble sans créer un chemin incohérent.

L’architecture distingue les PvD implicites, déduits de la source de configuration, et les PvD explicites, dotés d’une identité. Dans les deux cas, un hôte conscient des PvD garde l’association entre chaque paramètre et son domaine. Lors d’une connexion, le système, l’utilisateur ou l’application sélectionne un domaine selon ses règles, puis utilise des paramètres compatibles à l’intérieur de ce domaine.

La norme ne fournit volontairement aucun classement universel. La sécurité, le coût, la portée du service, la joignabilité et la préférence de l’utilisateur peuvent conduire à des décisions différentes. Une application métier peut utiliser un PvD restreint pendant qu’un navigateur emprunte, sur la même machine, un PvD d’accès général.

L’annonceur peut nommer le contexte

La RFC 8801 définit l’option PvD de type 21 dans les Router Advertisements IPv6. Elle transporte un identifiant PvD sous forme de FQDN, les indicateurs H, L et R, un numéro de séquence sur 16 bits, une valeur de délai et, le cas échéant, des options RA internes.

L’opérateur qui publie le FQDN doit le posséder et le gérer. Un même identifiant ne devrait couvrir que des services finalement identiques. Réutiliser un nom familier pour deux prestations différentes simplifie l’inventaire de l’opérateur, mais détruit la stabilité sémantique attendue par l’hôte.

Cette capacité de nommage reste limitée. Un attaquant présent sur le lien peut écrire un FQDN connu dans une fausse annonce. L’identité ne devient contraignante qu’après les vérifications du service HTTPS et des préfixes.

H indique qu’un objet d’information supplémentaire peut être récupéré par HTTPS. L associe des informations DHCPv4 héritées. R signale la présence d’un en-tête RA et d’options internes destinés aux hôtes compatibles. H ne prouve ni la récupération ni l’acceptation de l’objet. R n’exprime aucune préférence. Le numéro de séquence marque une génération propre à un PvD ; sa valeur n’est pas comparable à celle d’un autre domaine.

La récupération ne doit pas sortir du domaine examiné

Lorsque H est présent, l’hôte peut interroger https://<PvD-ID>/.well-known/pvd. Sans H, il ne doit pas lancer cette récupération. La réponse porte le type application/pvd+json.

La contrainte décisive concerne le chemin de cette requête. La résolution DNS du PvD ID, les vérifications de certificat, la connexion HTTPS, le choix de l’adresse source et celui du prochain saut doivent utiliser uniquement la configuration rattachée au PvD considéré. Résoudre le nom par un deuxième réseau et envoyer la requête par un troisième romprait le lien que l’on prétend vérifier.

Ce principe évite aussi des fuites. Un DNS à horizon partagé peut répondre différemment selon le contexte. Le préfixe source influe sur le premier routeur approprié. Interroger un autre réseau à propos d’un nom PvD propre à une entreprise révèle que l’appareil a rencontré ce réseau. Une trace limitée à l’URL finale ne suffit donc pas.

Le certificat TLS doit présenter un DNS-ID égal au PvD ID. En cas d’échec, l’hôte ferme la connexion et considère que le PvD ne possède aucune information supplémentaire. Cette vérification établit l’autorisation donnée par le détenteur du FQDN au service d’information. Elle n’authentifie pas, à elle seule, l’annonce locale ni tous les préfixes revendiqués.

Le JSON ferme la boucle des préfixes

Un objet recevable comporte identifier, expires et prefixes. L’identifiant doit correspondre au FQDN annoncé, l’expiration doit se situer dans le futur et les préfixes du JSON doivent couvrir toutes les Prefix Information Options de l’annonce associée. Un champ obligatoire absent ou un préfixe non couvert rend l’objet inutilisable.

Deux déclarations indépendantes sont ainsi rapprochées. Le routeur local affirme qu’une configuration appartient à un nom. Le service authentifié affirme que ce nom reconnaît un ensemble de préfixes. Contrôler une seule surface ne suffit plus à produire toute la preuve.

Les clés facultatives ont elles aussi une portée précise. dnsZones décrit des zones accessibles dans le PvD. noInternet: true indique un domaine restreint, non une panne. Un réseau industriel ou hospitalier peut être utile précisément parce qu’il n’offre pas l’Internet général.

Les clés inconnues sont ignorées afin de permettre l’évolution. L’IANA tient le registre commun ; les extensions privées se placent dans un sous-dictionnaire organisationnel ou vendor-*. L’inscription normalise la syntaxe, mais ne garantit ni l’exactitude d’une valeur annoncée ni son déploiement.

L’actualisation comprend des limites d’arrêt

Une modification du numéro de séquence ou l’arrivée à expiration déprécie l’objet précédemment obtenu. Le champ Delay et l’aléa de renouvellement empêchent une foule d’hôtes d’interroger simultanément le serveur. Ils gèrent la charge ; ils ne donnent aucun rang au PvD.

L’heure absolue n’est pas une racine de confiance : une horloge locale peut être fausse. La RFC interdit donc de fonder une décision sensible de sécurité sur l’expiration seule. Après un échec de certificat, de HTTP ou de JSON, l’hôte cesse d’interroger cet identifiant pendant l’attachement courant. Après dix échecs ou davantage sur le réseau, il arrête toutes les récupérations PvD pour cet attachement.

Ces règles bornent une attaque où de fausses annonces déclencheraient des connexions DNS, TLS et HTTP vers de nombreux serveurs. L’opérateur assume aussi une obligation lorsqu’il positionne H : même derrière un portail captif, les échanges nécessaires doivent être autorisés avant l’authentification.

Enfin, la récupération est observable. L’hôte devrait employer une adresse IPv6 temporaire disponible dans le PvD et éviter cookies ou en-têtes identifiants. Une métadonnée facultative ne doit pas devenir le premier identifiant persistant de la session réseau.

La décision n’existe qu’au niveau de l’hôte

Une fois plusieurs ensembles validés, une politique choisit celui qui répond à la connexion demandée. L’opérateur fournit un contexte cohérent. Le propriétaire du FQDN autorise le service d’information. L’objet décrit des caractéristiques. L’hôte décide si elles conviennent à l’application.

La preuve finale se trouve dans l’exécution : adresse source, résolveur, prochain saut, destination et résultat. Running-Code Primacy ne retire rien à la norme ; il exige de vérifier que le logiciel a effectivement préservé les associations minimales que la norme rend communes.

Sources