Résumé

  • L’option 121 de RFC 3442 a permis à DHCPv4 de transmettre des routes avec une longueur de préfixe explicite, là où l’ancienne option statique supposait des classes d’adresses.
  • Un client compatible devait installer ces routes et les préférer aux valeurs des options Router et 33 reçues avec elles ; le RFC avertissait qu’un prochain saut erroné pouvait détourner le trafic.

Un bail d’adresse ressemble à une attribution : le réseau indique à un hôte quelle adresse utiliser et pendant combien de temps. Mais l’hôte doit aussi savoir où envoyer les paquets destinés à l’extérieur du lien local. RFC 3442 a intégré cette seconde décision à la configuration DHCP. Son option de routes statiques sans classes pouvait transmettre un préfixe de destination et l’adresse du routeur à utiliser pour le joindre.

Le changement répondait à un décalage. L’option 33 de DHCP, définie par RFC 2132, décrivait des routes sans masque distinct pour chaque destination. Cette hypothèse convenait lorsque la frontière réseau se déduisait de la classe d’adresse. Le routage sans classes avait remplacé cette logique : 10.0.0.0/8 et 10.0.0.0/24 désignent des destinations différentes, même si leurs premiers octets se ressemblent. Le client doit connaître la longueur du préfixe pour savoir quels bits définissent la route.

L’option 121 encodait cette portée de manière compacte. Le descripteur de destination commençait par la longueur du préfixe et ne contenait que les octets significatifs ; l’adresse du routeur, sur quatre octets, suivait. Le client reconstruisait la destination et mettait à zéro les bits hors masque avant d’installer la route. RFC 3442 ne transformait pas DHCP en protocole de routage et ne distribuait pas une table Internet. Il permettait à un administrateur d’utiliser un serveur déjà chargé de configurer les hôtes pour installer certaines routes statiques sur les clients.

Ce mécanisme déplaçait un choix important entre deux surfaces administratives. La table de routage demeurait sur l’hôte, qui appliquait toujours ses propres règles. Pourtant, une route pouvait désormais provenir de la configuration du serveur DHCP plutôt que d’une intervention locale sur l’appareil. Pour un client compatible, le RFC exigeait l’installation des routes, sous réserve d’une exception concernant les sous-réseaux locaux. Si l’option 121 arrivait avec l’option Router ou l’option 33, le client devait ignorer ces valeurs plus anciennes.

L’ordre de demande des options comptait également : 121 devait précéder Router et l’option 33 dans la liste des paramètres demandés.

La compatibilité faisait partie de la conception. Un client qui ne prenait pas en charge l’option 121 devait l’ignorer. RFC 3442 recommandait donc aux administrateurs d’envoyer également Router, avec les informations de routeur par défaut en double pour les anciens clients. Il s’agissait d’une stratégie de transition, pas d’une preuve du nombre d’appareils compatibles ni de la vitesse d’adoption. Une norme peut fixer une règle de priorité ; elle ne peut contraindre chaque client à l’implémenter.

La limite avait aussi une conséquence de sécurité. RFC 3442 avertissait explicitement qu’une adresse de routeur erronée pouvait provoquer un déni de service ou faire transiter le trafic par un observateur. Le risque ne provenait pas uniquement de l’option 121 : Router et l’ancienne option de routes pouvaient eux aussi indiquer un mauvais prochain saut. L’option ne prouvait pas que la route proposée était autorisée, exacte ou sûre. L’authentification des messages, lorsqu’elle était utilisée, relevait d’un mécanisme DHCP distinct et ne suffisait pas à établir que le choix de route était judicieux.

La taille des paquets influençait également cette transmission. Une longue liste de routes pouvait dépasser la taille traditionnelle d’un message DHCP ; RFC 3442 abordait donc la négociation de messages plus grands et exigeait la concaténation des options longues. Sur un lien partagé par plusieurs sous-réseaux IP, le RFC définissait aussi l’emploi particulier du prochain saut 0.0.0.0 pour signaler un sous-réseau local directement joignable. Les clients dépourvus du comportement nécessaire devaient ignorer cette entrée.

Le déplacement historique de RFC 3442 est limité mais significatif : dès lors que le routage devenait sans classes, la configuration d’adresses devait pouvoir exprimer la portée des routes. Le bail pouvait devenir le véhicule d’une politique locale de transmission. Le client restait le lieu d’installation, l’administrateur DHCP devenait un acteur du choix de route, et le prochain saut avait des conséquences dépassant l’attribution d’une adresse.

Sources