Résumé

  • Le RFC 1542 demande au relais de conserver la même destination, ou le même groupe de destinations, pour toutes les requêtes BOOTREQUEST d’un client.
  • Il décrit un relais qui répartit les paquets à tour de rôle entre plusieurs serveurs ; des requêtes d’un même client peuvent alors aboutir à des serveurs différents.
  • Une répartition stable selon l’identité du client, par exemple au moyen d’une empreinte de son adresse de liaison, conserve l’équilibre entre clients sans disperser un même échange.

Le relais devient une partie de l’échange

BOOTP répondait au problème d’une machine qui démarre sans connaître son adresse IP ou le serveur capable de fournir ses informations d’amorçage. Le RFC 951, publié en 1985, décrit une première phase d’attribution d’adresse et de choix du fichier de démarrage. Un client peut diffuser sa requête sur son réseau local. Si le serveur se trouve ailleurs, un routeur ordinaire ne transporte pas simplement cette diffusion comme une requête unicast.

Le RFC 951 rend donc possible un démarrage à travers des passerelles coopérantes. Cette fonction de relais reste facultative. La passerelle, ou un autre agent présent sur le réseau du client, reçoit BOOTREQUEST, renseigne au besoin giaddr et incrémente hops. Le champ giaddr indique au serveur le chemin de retour vers le réseau du client. L’idée était claire, mais le comportement du relais n’était pas encore défini avec précision.

En octobre 1993, le RFC 1532 tente de clarifier BOOTP. Le RFC 1542 paraît le même mois : il met à jour le RFC 951, remplace le RFC 1532 et explique que des erreurs éditoriales ont été introduites dans ce dernier. Son résumé souligne que le comportement des agents relais faisait partie des points à renforcer. Le relais cesse ainsi d’être un simple détail de transmission : il devient un participant dont le comportement peut déterminer si une suite de messages reste cohérente.

Une destination stable pour chaque client

Le RFC 1542 laisse une marge de décision à l’administrateur du réseau. Un mécanisme doit permettre d’activer ou de désactiver le relais, qui doit être désactivé par défaut. Le relais écarte les requêtes dont hops dépasse 16 ; un seuil inférieur doit pouvoir être configuré. Si giaddr est nul, l’agent le renseigne avec une adresse de l’interface qui a reçu la requête, incrémente hops et conserve les autres champs BOOTP. La destination ou le groupe de destinations reste également configurable.

La règle moins visible porte sur la répétition : toutes les requêtes BOOTREQUEST qu’un relais reçoit d’un même client doivent aller à la même destination ou au même groupe. Le texte explique le problème par un exemple. Au moins une implémentation connue répartissait les requêtes à tour de rôle entre plusieurs serveurs. Chaque nouvelle requête partait vers le serveur suivant ; deux requêtes consécutives d’un même client pouvaient donc arriver à des serveurs distincts.

Le défaut ne vient pas du partage de charge en soi, mais du moment où la décision est prise. Si le relais choisit un serveur pour chaque paquet, il peut séparer une conversation faite de plusieurs requêtes et réponses. Le RFC estime que cette méthode réagit mal avec DHCP et d’autres variantes de BOOTP qui reposent sur plusieurs échanges. L’un des serveurs peut voir une étape, tandis qu’un autre reçoit la suivante. Le texte décrit un risque de protocole ; il ne rapporte ni panne nommée ni fréquence de cette pratique.

Pour conserver une répartition, le RFC propose de calculer une empreinte à partir de l’adresse de liaison du client, ou d’une autre information fiable qui l’identifie, puis d’utiliser ce résultat pour choisir sa destination. Les clients peuvent ainsi être distribués entre plusieurs serveurs tout en gardant chacun un chemin stable. L’option la plus simple consiste à envoyer toutes les requêtes au même groupe de destinations. Dans les deux cas, l’unité de répartition est le client, pas le paquet.

Ce que la règle garantit — et ce qu’elle ne garantit pas

Le RFC 1542 ne promet ni disponibilité des serveurs, ni partage d’état entre eux, ni réussite du démarrage. Il limite le choix du relais : pour un client donné, la destination ne change pas au fil des requêtes. Il n’impose pas non plus un serveur unique pour tous les clients ; un groupe de destinations peut recevoir les messages, et une sélection stable peut répartir les clients.

Le RFC 1534, également daté d’octobre 1993, précise les conditions d’interopérabilité entre BOOTP et DHCP, dont les messages reprennent le format BOOTP. En 1997, le RFC 2131 formalise davantage la séquence DHCP : découverte de serveurs, offres, choix d’un serveur et requêtes ultérieures. Ces textes éclairent le contexte des échanges multiples, sans prouver qu’un déploiement particulier a subi une panne à cause du tourniquet.

Le registre du RFC Editor signale un erratum vérifié pour le RFC 1542. Il corrige dans le §3.1.1 une référence à BOOTREPLY qui devait être BOOTREQUEST, dans un passage sur le fanion de diffusion. Cette correction est distincte de la règle du §4.1.1 examinée ici ; elle ne la modifie pas.

L’histoire tient donc à une distinction opérationnelle précise. On peut équilibrer la charge en répartissant des clients, mais pas en envoyant à tour de rôle les paquets d’un même client vers des serveurs différents lorsque l’échange peut avoir plusieurs étapes. Le RFC 1542 fixe cette limite et laisse le choix de la stratégie au gestionnaire du réseau.

Sources