Auteur Sujet: Pourquoi supporter des options DHCPv4 anciennes dans Freebox Server ? (Lu 221 fois)

basilix · « **le:** **Aujourd'hui** à 06:13:17 »

Je parcours les options DHCPv4 présentes dans le RFC2132. La spécification remonte dans le passé avec le support BOOTP.
Mon objectif est de comprendre quelles options sont encore actuelles. J'ai l'impression que beaucoup d'options ne le sont plus.

Ce qui est surprenant c'est que Free revendique leur prise en charge (mise à jour de janvier 2026).

Citer

La liste complète des options est la suivante, classé par catégorie :

## Options Générales et Configuration Réseau
– Time offset (2) : Indique la différence de temps en secondes par rapport à l’heure UTC.
– Time server (4) : Fournit une liste d’adresses IP de serveurs de temps (RFC 868).
– NTP server (42) : Fournit une liste d’adresses IP de serveurs NTP (Network Time Protocol) pour la synchronisation de l’heure.
...

Hyperlien : https://blog.genma.fr/Tuto-Freebox-TFTP-et-Options-DHCP.html

J'ai l'impression que c'est un ajout à rebours.

Selon l'IA, les options 2, 20, 21 sont formellement obsolètes ou déconseillées. Toujours selon l'IA, beaucoup d'options sont anciennes bien que certaines « puissent encore
avoir une utilité dans du démarrage réseau, des équipements embarqués ou des environnements très anciens » : 4, 5, 7-11, 13, 14, 16, 18, 24-39. Je vois beaucoup d'options
désuètes dans la liste intégrée au Freebox Server. Cela ressemble plus à une mauvaise blague ou à une forme de nostalgie.

basilix · « **Réponse #1 le:** **Aujourd'hui** à 06:54:42 »

Time Offset [2] --> NTP Servers [42]
Time Server [4] --> NTP Servers [42], PCode [100], TCode [101]
Log Server [7] --> Méthode désuète.
Cookie Server [8] --> Méthode obsolète.
LPR Server [9] --> Méthode désuète.
Impress Server [10] --> Méthode obsolète.
Resource Location Server [11] --> Méthode obsolète.
...

basilix · « **Réponse #2 le:** **Aujourd'hui** à 09:30:15 »

Idem pour systemd avec l'option Broadcast Address. Une relique qui date de Mathusalem.

https://github.com/systemd/systemd/issues/31252

https://networkengineering.stackexchange.com/questions/64604/redundant-option-in-dhcp

Optix · « **Réponse #3 le:** **Aujourd'hui** à 09:40:51 »

Doucement avec le multi-post, tu peux éditer le premier pour apporter des éléments hein

Sinon, qui es-tu pour juger de l'obscolescence des méthodes ?

Par exemple, le "Log server" (opt 7), c'est très utile pour moi, FAI, afin que les boxs centralisent leurs logs sur un serveur commun.

basilix · « **Réponse #4 le:** **Aujourd'hui** à 16:13:59 »

@Optix :

Beaucoup d'options sont inutiles car elles sont dépassées, substituables par d'autres ou rarement utilisées. La plupart n'ont
pas été déprécié par l'IANA. Le bon sens indique toutefois que cela relève de reliques du passé. J'ai d'ailleurs donné un
exemple significatif avec l'explication qui l'accompagne, celui du support de l'option DHCPv4 28 : Broadcast Address.

Citer

Because in days long forgotten, one could use the all-zeros address or the all-ones address for broadcast, so you had to tell systems which way each network leans.
Today (and for about 30 years), everything uses the all-ones address.

citation de Ricky, sur le site networkengineering.stackexchange.com

Elle fait d'ailleurs partie de la liste des paramètres requis envoyés par une Livebox. L'IA m'assiste dans cette tâche et il est
vraisemblable que ces options ne soient jamais dépréciées.

thenico · « **Réponse #5 le:** **Aujourd'hui** à 17:12:12 »

Parce que cela ne coute virtuellement rien de les laisser dans le produit?
La liste est probablement autogeneré depuis la définition des options dans le code du serveur DHCP.