Résumé

  • RFC 3011 permettait de demander une adresse sur un sous-réseau différent de celui par lequel le serveur DHCP observait la requête ; l’origine devenait un fait distinct de la cible d’allocation.
  • La copie identique de l’option 118 dans la réponse attestait un traitement précis, sans authentifier le demandeur ni prouver son droit sur le pool, la routabilité de l’adresse ou le service final.

Le cas fondateur n’était pas celui d’un ordinateur installé sur son propre réseau local. C’était celui d’un équipement d’accès placé entre deux mondes. Son interface interne pouvait joindre le serveur DHCP. Ses clients, eux, devaient recevoir des adresses appartenant à des réseaux externes que le serveur ne pouvait pas atteindre directement. Si le serveur suivait seulement le trajet visible de la demande, il puisait dans le mauvais pool.

Le DHCP de RFC 2131 disposait d’une règle pragmatique. Avec un relais, le champ giaddr indiquait le réseau d’origine du client. Sans cette indication, l’interface ayant reçu le paquet servait de repère. La topologie observée répondait donc à la question d’allocation.

RFC 3011, publié en novembre 2000, a rendu l’exception explicite. L’option de sélection de sous-réseau transporte une adresse IPv4 de quatre octets représentant le sous-réseau demandé : on prend une adresse de ce sous-réseau et l’on met à zéro les bits d’hôte avec le masque. Le registre IANA BOOTP/DHCP conserve aujourd’hui le code 118 et la longueur quatre.

Ce n’était pas une annotation décorative. Si le serveur était configuré pour la traiter, l’option l’emportait sur la déduction normale fondée sur giaddr ou sur l’interface de réception. Le serveur devait choisir une adresse dans le sous-réseau indiqué, ou dans un autre sous-réseau du même segment. Il ne devait pas faire une offre hors de cette limite.

Le changement historique tient à la nature de la preuve. Le serveur voyait toujours le paquet arriver sur le réseau interne. Cette observation restait vraie. Mais elle cessait d’être l’unique autorité pour choisir le pool. Une instruction portée par le message introduisait une seconde réalité : le lieu demandé pour l’allocation.

Une troisième réalité devait rester indépendante. Le serveur avait besoin d’une adresse utilisable pour renvoyer DHCPOFFER ou DHCPACK à l’équipement. RFC 3011 exigeait donc que tout message contenant l’option 118 renseigne giaddr avec une adresse sur laquelle le demandeur accepterait les réponses. Même lors d’un renouvellement, l’adresse externe attribuée pouvait ne pas être routable depuis le serveur. Le sous-réseau d’allocation ne remplaçait pas le chemin de retour.

La spécification ajoutait un contrôle de compatibilité. Un serveur activé pour cette option devait renvoyer une copie identique de l’option, même si elle ne figurait pas dans la liste ordinaire des paramètres demandés. Le client utilisant ce mécanisme devait rejeter toute offre ou tout acquittement qui ne la contenait pas.

Ce rejet évitait une acceptation trompeuse. Un ancien serveur pouvait ignorer le code inconnu et attribuer une adresse selon sa méthode habituelle. Un serveur moderne mais administrativement configuré pour ignorer l’option pouvait faire de même. Dans les deux cas, une réponse DHCP valide sur la forme n’exécutait pas le contrat de sélection demandé. L’absence de l’écho rendait cette différence observable.

L’écho restait pourtant un reçu borné. Il ne disait pas qui contrôlait réellement l’équipement d’accès. Il ne démontrait pas que ce demandeur avait mandat pour consommer le pool externe. Il ne prouvait ni route, ni absence de conflit, ni livraison au client final. Il confirmait que le serveur avait reconnu une option et traité l’échange sous la règle associée.

La section de sécurité expose le coût de cette liberté. Le DHCP de l’époque ne fournissait pas, à lui seul, de mécanisme d’authentification. Une machine limitée auparavant au pool déduit de son réseau local pouvait désormais désigner d’autres pools. L’épuisement d’adresses devenait plus large que la topologie d’arrivée.

La fonction devait donc être désactivée par défaut. Son activation était un acte administratif. RFC 3011 recommandait de la restreindre, par exemple à certains identifiants clients, à certaines origines ou à une liste de sous-réseaux cibles. Le standard définissait comment exprimer la demande ; il n’accordait pas à tout émetteur le droit de la faire exécuter.

RFC 2132 avait fourni la grammaire code-longueur-valeur. RFC 3011 a donné un sens public au code 118. La capacité de parser une option et l’autorité de modifier une allocation demeuraient deux choses différentes.

Les travaux suivants ont déplacé une assertion voisine vers le relais. RFC 3046 a défini l’information d’agent relais, avec des identifiants de circuit et de terminal produits dans un périmètre d’exploitation. RFC 3527 a ajouté une sous-option de sélection de lien pour les cas où le lien d’allocation devait différer de l’adresse utilisée pour communiquer avec le relais.

La distinction est révélatrice. Dans RFC 3527, giaddr reste l’adresse de retour vers le relais ; la sous-option désigne le lien d’allocation. Si le message contient à la fois l’option client de RFC 3011 et la sous-option relais, la valeur du relais prévaut. La hiérarchie ne vient pas de la longueur du champ, mais de la place de l’acteur dans le modèle de confiance de l’opérateur.

Même ce mécanisme ne transforme pas une copie en preuve universelle. RFC 3527 avertit qu’un relais ne doit pas tirer de conclusion différente selon que la sous-option réapparaît ou non, car le conteneur d’information peut être recopié. La configuration commune du relais et du serveur reste déterminante. RFC 3118 a défini une authentification DHCP, mais sa publication ne prouve pas son emploi dans un réseau donné.

RFC 7969 a ensuite dressé la carte des personnalisations topologiques : sélection de sous-réseau, sélection de lien et sélection de sous-réseau virtuel. Cette accumulation ne signifie pas que la topologie a perdu sa valeur. Elle montre qu’un seul indice ne pouvait plus représenter à la fois l’origine, l’intermédiaire, le pool, le VPN et la destination de réponse.

L’architecture probante qui en résulte est plus exigeante qu’un journal de baux. Il faut conserver l’interface d’entrée, la source observée, giaddr, l’identité client revendiquée, l’option 118, la règle locale appliquée, le pool choisi, l’adresse offerte, la copie retournée et la destination de la réponse. Puis viennent d’autres reçus : état du bail, route, voisinage, session de l’abonné et résultat applicatif.

La lecture par la primauté du code exécutable de Lu Heng conduit à une conclusion sobre. RFC 3011 n’a pas créé une institution globale de l’allocation. Il a normalisé un mécanisme minimal qui modifiait un seul choix du serveur. La décision de l’activer et d’en limiter le champ restait locale, visible dans la configuration et dans les effets du serveur.

Le paquet venait bien du réseau interne. L’adresse appartenait bien au réseau externe. La réponse devait encore revenir par une adresse joignable. La contribution de RFC 3011 fut de refuser que ces trois phrases soient comprimées en une seule preuve topologique.

Sources