[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dhcwg] DHCPv6: Canonical way to handle an unknown option



On Tue, Jun 02, 2009 at 04:50:42PM +0200, Gabor Retvari wrote:
> What is the best way to handle a DHCPv6 message that contains an unknown 
> DHCPv6 option? Should an implementation drop the message as a whole, once it 
> encounters an unknown option in it, or should it drop only the option and 
> carry on processing the rest of the message that it can make sense of? (It 
> seems to me that wide-dhcp, for instance, implements the latter behavior.)
> 
> Could any one provide me with a pointer on the recommended way to handle 
> unknown options in DHCPv6 implementations?

I don't know if there are any pointers.  ISC DHCP's v4 and v6 client
(they both operate the same way in this regard) will only reject a
packet if it lacks options that are mandatory by the protocol.  It
does not reject a packet with a new option (exception: bugs in the
software, long story).

New options are cached, since it cannot be known what the option's
format is ahead of time, they are stored as an opaque hexadecimal
string.  When configuration is comitted, they are passed to the system
(like all known option codes) as environment variables, so that the
operator or integrator can potentially digest and use them before the
software is updated.

It is reasonable to omit or disregard an unknown option.  Not all
implementations have variable sized lease storage, and quite a few
will not be interested in any options it cannot use directly itself.

Failing to process a packet with an unknown option is probably the
worst possible behaviour.

-- 
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

Attachment: pgpxGdDuETUI3.pgp
Description: PGP signature