Résumé

  • En 2003, RFC 3315 a permis au client DHCPv6 de demander un échange Solicit–Reply à la place de Solicit–Advertise–Request–Reply ; le serveur restait libre de ne pas l’accepter.
  • Avec Rapid Commit, le serveur réservait l’adresse avant d’envoyer sa réponse. Plusieurs réponses pouvaient donc engager des baux dont le client n’utiliserait qu’un, et une réponse perdue laissait un écart entre l’état du serveur et ce que le client avait reçu.

Le délai entre les quatre messages habituels n’était pas un simple détour. Après Solicit, un client pouvait comparer les Advertise de plusieurs serveurs, choisir, puis demander à l’un d’eux de confirmer l’attribution. Dans la version initiale de DHCPv6, RFC 3315, cette sélection visible précédait l’engagement définitif. Mais le texte prévoyait aussi une voie plus courte pour les réseaux où l’attente supplémentaire n’était pas souhaitée.

Le client pouvait inclure l’option Rapid Commit, de longueur nulle, dans son Solicit. Il signalait ainsi qu’il acceptait de recevoir immédiatement Reply. Ce signal ne forçait pas les serveurs à s’exécuter : chacun appliquait sa politique et sa configuration. Un serveur qui n’était pas configuré pour attribuer les ressources immédiatement pouvait ignorer l’option et envoyer Advertise. Le client retombait alors sur l’échange habituel. S’il acceptait le chemin rapide, le serveur créait le bail avant d’émettre Reply.

L’ordre des opérations changeait donc. Le serveur engageait l’adresse d’abord ; la réponse suivait. Une réponse valide portant Rapid Commit permettait au client d’utiliser l’adresse sans envoyer Request. Mais le serveur ne recevait pas ensuite de confirmation que le client avait bien reçu Reply. RFC 3315 souligne la conséquence : si plusieurs serveurs répondent au même Solicit, chacun engage des adresses alors que le client n’utilise que les baux de l’un d’eux. Les autres peuvent rester engagés et inutilisés. Si Reply se perd, le serveur peut également conserver un état que le client ne peut pas exploiter.

Ce compromis apparaît mieux en comparant les deux chemins. Advertise puis Request donnent au client une étape pour choisir avant que le serveur retenu finalise l’allocation. Solicit puis Reply accélère la configuration en supprimant cette sélection explicite ; l’incertitude n’a pas disparu, elle a changé de place. Les serveurs peuvent engager des ressources avant de savoir quelle réponse le client a reçue ou utilisée. Ce mécanisme ne prouve pas qu’une collision d’adresses s’est produite et ne rend pas chaque bail inutilisé dangereux. Il déplace un risque vers la gestion du pool et la coordination entre répondants.

RFC 3315 indique que les services utilisant Solicit–Reply sont généralement conçus pour qu’un seul serveur réponde. Le document cite aussi des durées de bail initiales plus courtes pour limiter les allocations inutilisées. Ce sont des choix d’architecture, pas une garantie que le serveur unique restera seul ou que les états sont partagés. Rapid Commit est plus prévisible lorsque la sélection des répondants est intentionnelle.

En 2005, RFC 4039 a introduit Rapid Commit dans DHCPv4, en reprenant l’idée DHCPv6 pour des environnements où le point de raccordement change souvent. Le texte rappelle que le chemin normal à quatre messages apporte une redondance : les offres restent provisoires pendant que le client choisit. Cette filiation montre comment le compromis s’est étendu, pas qu’il ait été déployé partout. RFC 8415 a ensuite regroupé DHCPv6 en 2018 ; RFC 9915, qui remplace désormais RFC 8415, conserve le choix du client, la décision du serveur et l’avertissement sur les baux engagés mais non utilisés.

Le gain de vitesse ne se résume donc pas à compter les paquets. Il faut demander quand l’adresse est engagée, combien de serveurs peuvent répondre et quelle preuve indique que le client a réellement reçu et utilisé la ressource. Enlever un échange enlève aussi une étape de confirmation et de choix.

Sources : RFC 3315, RFC 4039, RFC 8415 et RFC 9915.