Résumé

  • La RFC 3074 transformait l’identifiant client ou l’adresse matérielle en une valeur parmi 256, puis consultait une carte de compartiments afin que les serveurs DHCP sachent lequel devait répondre.
  • Elle prévoyait pourtant le serveur désigné indisponible ou sans adresse, les compartiments non attribués, un temps client peu fiable et la falsification de la carte. Le résultat du hachage attestait une consigne, pas une capacité en direct.

Une requête DHCPDISCOVER est diffusée. Plusieurs serveurs peuvent donc la recevoir et répondre, tandis qu’un relais BOOTP peut reproduire cette dispersion vers tous ses serveurs configurés. Publiée en février 2001 par B. Volz, S. Gonczi, T. Lemon et R. Stevens, la RFC 3074 proposait une économie de coordination : après une configuration initiale commune, chaque participant pouvait prendre seul la même décision « servir / ne pas servir ».

Le calcul partait d’un Service Transaction ID. La présence de l’option Client Identifier l’imposait comme entrée ; à défaut, le serveur employait hlen et chaddr, dans la limite des seize premiers octets. La fonction de Pearson prescrite produisait une valeur de 0 à 255. Une Hash Bucket Assignment, carte de 32 octets pour un serveur, liait ces valeurs aux participants. Un bit activé obligeait son destinataire à traiter les requêtes tombant dans le compartiment correspondant.

L’accord ainsi obtenu était réel. Même entrée, même table de mélange et mêmes HBA donnaient le même responsable sans conversation supplémentaire. Un relais pouvait appliquer des couples Server-ID/compartiment pour choisir une ou plusieurs destinations. L’algorithme partageait une population de demandes tout en laissant les anciens clients DHCP inchangés.

Mais il ne mesurait pas l’état du serveur. La fonction ne vérifiait ni processus actif, ni chemin réseau, ni cohérence de la base de baux, ni stock d’adresses adéquates. Le STID décrivait la transaction du client ; la HBA déclarait une responsabilité administrative. Aucun des deux ne transportait la capacité instantanée.

La RFC distingue elle-même les plans. Elle envisage le cas où le serveur censé répondre est indisponible ou n’a plus d’adresse appropriée. Le paramètre facultatif Delayed Service autorise alors un serveur que le hachage aurait exclu à répondre après S secondes depuis la première tentative. Ce mécanisme n’annule pas le choix initial : il ouvre une seconde possibilité lorsque le délai réservé au premier responsable est écoulé.

La mesure de ce délai reste conditionnelle. Le serveur devrait lire secs si le client fournit une valeur non nulle, mais le texte reconnaît que certains clients renseignent mal ce champ. Il peut donc mémoriser une requête refusée et mesurer localement le temps jusqu’à une répétition portant le même identifiant de transaction. L’une des méthodes reçoit une durée déclarée ; l’autre joint deux observations. Aucune n’explique à elle seule pourquoi le premier serveur est resté silencieux.

Sans Delayed Service, la carte impose strictement « servir / ne pas servir ». Des compartiments non attribués font ignorer entièrement certaines transactions, situation que le document juge parfois souhaitable. La couverture de la carte devient donc une preuve autonome. Un programme parfaitement conforme peut calculer correctement une valeur que personne n’est chargé de servir.

Les pourcentages sont eux aussi bornés. La RFC qualifie l’approche de probabiliste à l’échelle de la population : sur une courte période, la part réelle d’un serveur peut s’écarter du partage prévu ; avec davantage de requêtes, elle devrait s’en rapprocher. Le hachage ne pondère ni CPU, ni file d’attente, ni adresses libres, ni délai de réponse. Il répartit des identifiants, sous réserve qu’ils présentent assez de variété.

La configuration appartient ainsi au chemin d’exécution. Une HBA peut venir d’un fichier, du registre Windows NT, d’une EEPROM ou d’un algorithme convenu, et voyager dans un autre protocole. La RFC ne fournit aucune sécurité par elle-même. Toute transmission de la carte doit être protégée contre l’altération, car une modification peut priver de service certains clients ou tous. Un code identique ne corrige pas deux cartes divergentes ou une carte commune falsifiée.

Le socle DHCP confirme cette séparation. La RFC 2131 prépare le client à plusieurs réponses et place le mécanisme sous la politique de l’administrateur local. Après DISCOVER viennent encore OFFER, choix du client, REQUEST, ACK et l’usage réel de la configuration. La RFC 3074 optimise l’autorisation de répondre ; elle ne transforme pas ces événements ultérieurs en propriétés du compartiment. La RFC 1542 décrit le relais BOOTP, sans prouver qu’un relais donné ait adopté correctement cet algorithme.

La RFC 7031, beaucoup plus tardive, décrit les configurations incohérentes entre partenaires comme un problème fréquent et laisse l’équilibrage hors du cœur du failover DHCPv6. Ce n’est pas un rapport rétrospectif sur les déploiements de 3074. C’est un rappel utile : répartir les entrées, synchroniser l’état et survivre à une panne sont des fonctions liées, mais distinctes.

Running-Code Primacy invite à réunir les reçus dans l’ordre : source du STID, résultat du hachage, couverture HBA, identité du serveur, joignabilité, adresse disponible, éventuel délai de secours, OFFER, choix, ACK, puis configuration utilisable. Reality Layers aide à ne pas confondre la certitude symbolique d’un responsable calculé avec l’autorité opérationnelle d’un service accompli. Ces cadres sont postérieurs et ne doivent pas être attribués aux auteurs ou à l’IETF.

La RFC 3074 a réduit les réponses en double avec un calcul léger et sans modification des clients. C’était une réussite précise. Sa limite l’était aussi : le compartiment disait qui devait tenter en premier. La présence, la capacité, l’intégrité de la configuration et le résultat chez le client demandaient chacun leur propre preuve.

Sources