Il me semble également qu'on parle ici de plans sur la comète, essentiellement parce que les infos données ici sont très succintes.
Réflechissons un peu : je vois plusieurs façons d'empêcher le "replay" tel qu'on le fait tous actuellement :
1. utiliser les champs Replay Detection de la RFC 3118 ; typiquement, la valeur actuelle stipule "monotonically increasing value", ce qui implique de fournir le timestamp courant côté client pour que le serveur le compare après réception et rejette la requête si le timestamp est trop loin dans le passé. C'est assez léger à implèmenter côté serveur, et s'il n'y a que ça à faire pour continuer à envoyer bêtement le même trio user/salt/hash, on devrait s'en sortir, même si ça implique de patcher le client DHCP ou d'en trouver un qui implèmente correctement la RDM.
2. stocker côté serveur les données envoyées par les clients (par exemple les salts). C'est beaucoup plus lourd côté Orange, parce qu'il faut un système de stockage accessible à tous les nœuds DHCP, il faut se palucher la purge des données les plus anciennes, les sauvegardes, etc. Bref, ça commence à faire beaucoup de boulot de leur côté pour pas grand chose. Là encore, ça implique de patcher le client DHCP, avec du code plus compliqué (générer un nouveau salt, etc.) mais ça reste faisable.
3. méthode #1 + déterminer les salts acceptables à partir du login PPP et du timestamp courant avec un algorithme propriétaire... ok, là, ça n'implique pas de stockage côté Orange (un simple calcul permettant de définir si le salt fourni est made-in-Livebox ou non) et côté client, il faudrait se coltiner le reverse-engineering du firmware pour déterminer cet algorithme. C'est un peu le pire scénario catastrophe que je vois pour l'obtention d'un bail DHCPv4.
Pour ma part, je vais regarder comment ça se passe côté IPv6 chez Orange... si c'est plus simple d'avoir une connectivité IPv6 Orange, je peux parfaitement me passer de la connectivité IPv4 Orange...
Edit: bon, le DHCP IPv6 envoie les mêmes infos que le DHCP IPv4 a priori...