Résumé

  • La RFC 3074 permettait à plusieurs serveurs DHCP de prendre localement la même décision à partir d’un identifiant client et d’une carte de 256 compartiments configurée à l’avance.
  • Le hachage répartissait le droit de répondre, pas le travail mesuré : un compartiment sans serveur pouvait produire le silence, et un délai ne prouvait pas qu’un bail avait finalement été remis.

Une répartition des réponses, pas un compteur de charge

Une diffusion DHCP peut parvenir simultanément à plusieurs serveurs. En 2001, la RFC 3074 proposait de limiter ces réponses en double sans modifier les clients : chaque serveur calculait le même hachage pour la transaction et ne répondait que si le résultat appartenait à son Hash Bucket Assignment (HBA).

Le serveur utilisait d’abord l’option Client Identifier. En son absence, il hachait les champs de longueur et d’adresse matérielle du client, sur seize octets au plus. Le hachage de Pearson produisait l’une de 256 valeurs. Une carte de 32 octets indiquait celles qu’un serveur pouvait traiter. Un relais BOOTP pouvait, lui, associer des compartiments à des identifiants de serveur et acheminer les paquets en conséquence.

La décision était prise dans la configuration initiale, sans négociation entre serveurs à chaque requête. L’idée provenait d’une optimisation du projet de protocole DHCP Failover, avant d’être étendue aux serveurs coopérants et aux relais. Le gain recherché était circonscrit : moins d’échanges entre serveurs et aucun changement requis côté client.

La part indiquée par une configuration n’était pourtant pas une mesure des processeurs, des pools d’adresses, du temps de réponse ou des allocations réussies. La RFC précise que la proportion peut s’écarter de la cible à court terme et s’en rapprocher lorsque le nombre de transactions augmente. Elle parle de répartition des demandes dans le temps, pas de coût identique par demande ni d’effort égal entre serveurs.

Le compartiment sans propriétaire était un choix

La limite la plus révélatrice se trouve dans la carte HBA. Une demande associée à une valeur non attribuée peut être entièrement ignorée ; la RFC note que ce résultat peut être souhaitable dans certains cas. Le silence pouvait donc être prévu par la configuration, et pas seulement provenir d’une perte de paquets.

Le paramètre facultatif Delayed Service permettait à un autre serveur de répondre après une attente. C’est une échappatoire temporisée, pas un quorum en temps réel ni la preuve que le serveur désigné est en panne. La RFC laisse aussi aux implémentations le soin de traiter l’indisponibilité du serveur sélectionné ou l’absence d’adresse disponible.

Le relais rend les étapes plus visibles : il peut envoyer un compartiment à un serveur ou à une paire primaire-secourue qui utilise séparément DHCP Failover. Sélection, acheminement, état des baux et usage final de l’adresse sont des faits différents. La RFC spécifie une règle de sélection, pas un état de bail partagé ni un reçu de bout en bout.

Le Datatracker classe toujours la RFC 3074 comme Proposed Standard de l’IETF ; ce statut décrit le document, non son adoption actuelle. La RFC 8156, publiée en 2017, définit le failover DHCPv6 et la reprise des baux après panne ou partition réseau. C’est un contraste utile, mais pas la preuve que la RFC 3074 a été remplacée ou déployée.

La note ultérieure de Heng Lu sur les « couches de réalité » sert ici de grille éditoriale, non de preuve sur DHCP : distinguer la règle écrite, la configuration opérateur, le comportement observé du serveur et le résultat côté client. La contribution historique de la RFC 3074 est ainsi plus étroite, mais plus précise : rendre calculable l’éligibilité à répondre, sans rendre le résultat du service auto-vérifiable.

Sources