Change in handling of multiple names for the same option number in dhcpd 3.0.x vs 3.1.x and later

[David W. Hankins]

On Tue, Nov 11, 2008 at 05:31:01PM -0500, Peter Norton wrote:
> Any insight, pointers, etc. would be appreciated. I haven't found a lot
> directly related to my question or the change in the parser in the
> documentation so far, and nothing about requiring a 1-to-1 mapping of
> user-defined option names to option numbers.

We never knew people were using it that way, and I can't find any
evidence that the original author had n-to-1 mappings in mind when he
wrote the software.

N-to-1 is formally supported through the use of multiple site-option
spaces, so that the specific interpretation of the code tag can be
selected explicitly.

When we did the original "prepwork" for DHCPv6, one of the things we
had to do was abandon the days of 256-element arrays of option format
definition structures.  65536-element arrays of DHCPv6 structures, and
2^32-element arrays of Vendor-Identified structures just don't scale.
This prepwork made it into 3.1.0 along with the initial
vendor-identified option support.

It was during that work I discovered this "bug" that old option
definitions wouldn't get cleaned up, and "fixed" it.

Now we're finding out people relied on that very option reference leak
bug.


We've got a bugs ticket queued to at least make the issue more visible
to operators relying on the old behaviour.  We weren't able to get
that fix reviewed in time for the last release cycle.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins