| Subject: | ACK to DHCREQUEST gives different configuration parameter values than ACK to DHCPINFORM |
As reported to us by Bluecat and confirmed by Thomas.
Bluecat said:
~~~
A customer has observed that defining option 6 (domain name servers) in the subnet and the range will result in an inconsistent ACK response when DHCP is sending an ACK for a DHCPREQUEST versus an ACK for a DHCPINFORM.
The ACK response to the DHCPREQUEST comes with the value that was defined at the range level (which is expected) while the ACK to the DHCPINFORM comes with the value that was defined at the subnet level, which seems to be incorrect.
We haven't validated with other options, but this probably affects not only option 6.
~~~
Thomas used the configuration that they provided and replicated the problem, as well as found in the code where what they want isn't happening with DHCPINFORM.
In the code, there are even comments that the code doesn't bother to match beyond subnet because 'clients are unlikely to send these options' (or words to that effect).
Thomas and I concur that a fix for this (he thinks he has one) should not hold up 4.3.5 or 4.1-ESV-R14 production, but should go into 4.3.6 and 4.1-ESV-R15 as well as 4.4.0
There is the possibility that someone might be depending on DHCPINFORM and DHCPREQUEST getting different answers back - but this seems way off the bottom of the 'likely' scale to us - it's just *wrong* what we're doing now.
I will check back with Bluecat to find out if just having a patch will suffice.