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

From: Gabor Retvari <[email-masked]>
Date: Tue, 2 Jun 2009 16:50:42 +0200

Dear all,

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?

Best regards,
Gabor

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 4 Jun 2009 12:34:00 -0700

> 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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Jun 2009 12:52:41 -0700

This raises an interesting question - in several places RFC3115 talks  
about a "valid Reply message," but the term is never defined.   We  
aren't told what makes a Reply message "valid" or "invalid."   So I  
understand the writer's confusion, and this ought to be clarified.   I  
would assume that "valid" means "well-formed," which is to say "parses  
without encountering anything the RFC hasn't told you how to parse."    
You've been told how to parse options, so I would say that an unknown  
option is valid in this context, but the RFC provides no guidance.

Anyway, the bottom line is that logically it doesn't make sense to  
drop packets with unknown options - it's entirely possible that these  
options represent a valid protocol extension that was added after you  
implemented your client, and it would be a mistake for your client to  
fail because of this.   Rather, it should ignore what it doesn't  
understand, as long as it's well-formed.   Otherwise, some protocol  
enhancement down the road could suddenly result in your client failing  
dependably, and you really don't want those phone calls.

---

From: Bud Millwood <[email-masked]>
Date: Fri, 5 Jun 2009 09:08:36 +0200

On Tuesday 02 June 2009, Gabor Retvari wrote:
> 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.)
>

The de-facto standard for adding new options to DHCPv4 has always been that if 
a sender transmits an option, and the reply does not contain the option (or 
does not contain any explicit reply to that option), the server does not 
understand the option. The sender can then alter its behavior accordingly.

This long-time standard behavior implies that it is the norm for a server to 
drop unknown options (from the sender's perspective; what you do with them 
internally is your business). I highly doubt that this group would recommend 
any other behavior for DHCPv6.

- Bud

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 5 Jun 2009 14:55:32 -0700

On Thu, Jun 04, 2009 at 12:52:41PM -0700, Ted Lemon wrote:
> This raises an interesting question - in several places RFC3115 talks about 
> a "valid Reply message," but the term is never defined.   We aren't told 
> what makes a Reply message "valid" or "invalid."   So I understand the 
> writer's confusion, and this ought to be clarified.   I would assume that 
> "valid" means "well-formed," which is to say "parses without encountering 
> anything the RFC hasn't told you how to parse."   You've been told how to 
> parse options, so I would say that an unknown option is valid in this 
> context, but the RFC provides no guidance.

There are message validation sections in 3315 that describe how to
validate the various kinds of messages (must contain this and that,
must not contain those other things...).  I've always assumed that
valid, in the context of 3315's own lexicon, means that the message
has passed those tests.

I'm becoming increasingly aware of a different but related open issue
in both DHCPv4 and DHCPv6 - the client's selection criteria when
presented with multiple offers (or advertises).

DHCPv4 describes a selection period, but doesn't hint at selection
mechanisms.  3315 hints, which I've tried to implement to the best
of my ability, but is self-inconsistent in its hints, and
inconsistency in client implementations here could lead to
interoperability issues.

In particular, in either protocol, if a client de-selects a server's
offer due to some failing criteria ("i require options x,y,z to
operate, you did not supply z"), the server (and operator) has no
feedback to understand the nature of the deselection.  The client is
simply silent in this case, which is identical behaviour to UDP packet
loss.

At some point I'll set forward to do something about that ("write a
draft"), but at least for me that time is not today.  If someone else
has the energy, I think it would be good for there to be an optional
to implement selection algorithm, that also introduces a new option
for a client to advertise the results of selection, and a new message
so that option can be used when selection resulted in zero leases
(without declining the lease).

That's also an opportunity to reinforce simple ideas like, if you
see a new option you don't understand, ignore it.