Subject: Re: [dhcwg] DHCPv6 message type

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 28 Apr 2008 19:28:11 -0400

Bud accidentally dropped the dhcwg ... Adding it back (after checking
with him) ...

>Well, what's your definition of painful? I guess this is where it could
get 
>unpalatable for anyone not interested in this message type. It just
feels 
>kinda bad to grab a bag full of option codes and reserve them for 
>vendor-specific messages.

The point is that in a vendor specific message, you would have to use
some kind of special encoding to encode IANA-assigned options. Sure, for
those that you knew about, you could just "reserve" those values in the
vendor option space, but that still means that you might conflict with
some future IANA assignment if you mixed the values.

Sure, you could start at 65K and work down, but anyone wanting to hijack
options could do the same in normal messages.

If we were really concerned about option numbers being hijacked, we
should request that IANA randomly pick option numbers from the full
range - as then you'd never know what the next value from IANA would be.
(The issue exists for the messages - someone could use message 255 as it
is unlikely IANA would assign that message number for a long time.)

>And what's considered enough reserved option codes?

Yes, that is a concern. But, if you'll use a lot of options, you'd have
to use an alternative techique (such as encoding them in other options
as sub-options or perhaps even as vendor-options).

---

And, there's one other benefit - packet decoders could still decode some
of the packet for you even for these vendor messages as a portion of the
option space was known! Of course, it would also be possible to have
vendor specific definitions based on the enterprise-id in the message
but then for those cases where the existing are used too, it gets kind
of messy to redefine all of the IANA options?

---

I asked at the DHC WG meeting when I presented the draft if it would
help if I removed the reserved options section, but people still didn't
like the draft even if it had just the vendor-specific message. I don't
think we *need* the reserved options, it just made life a bit easier.

- Bernie

-----Original Message-----
From: Bud Millwood [mailto:[email-masked]] 
Sent: Monday, April 28, 2008 11:07 AM
To: Bernie Volz (volz)
Subject: Re: [dhcwg] DHCPv6 message type

On Monday 28 April 2008, you wrote:
> >As for the draft, it looks interesting, but I have reservations about
> >reserving option codes for this message. My gut feeling is that once
>
> you get
>
> >inside a vendor-specific message, it's your business/problem how you
>
> encode
>
> >data, and the standard DHCP protocol should probably be left out of
it.
>
> The reason for this was that often you want a mix of the IANA assigned
> option codes and private ones. And, having to encode each private (or
> IANA option) as a vendor-option would be painful -- especially if
you're
> trying to bundle up information about multiple clients.

Well, what's your definition of painful? I guess this is where it could
get 
unpalatable for anyone not interested in this message type. It just
feels 
kinda bad to grab a bag full of option codes and reserve them for 
vendor-specific messages.

And what's considered enough reserved option codes?

If you're bundling options for multiple clients, you pretty much have to

include individual option instances per client already, right? So the 
different is between using a VSO to bundle those options and not using a
VSO? 
Like, 6 bytes per bundle? Or is the issue the actual mechanics of 
serializing/deserializing?

And if you're somehow wanting to share individual option instances, the
VSO 
would really only have to be encoded once for the shared data.

> Thus, having a range of option codes you know IANA would never assign
> would allow you to mix private (vendor-specific) options with the
public
> (IANA-assigned) option space. And, given that there are 65K option
codes
> available, I can't see we'd have the issue we did with v4 codes.
>
> I do understand that there might be a temptation for others to use
these
> option codes for client<->server interaction and that's why I wanted
to
> make sure that people understood that if you did that, some servers
(or
> relays) might drop the packets because of the restriction on these
> option codes not being used in normal DHCPv6 messages.

If they're not reserved this problem disappears.

> > I guess it depends on the use case for such a message type.
>
> The use case I discussed when presenting this option was for something
> like DHCPv4 failover. Some kind of communication between multiple
> servers. Given the current state of the DHCPv4 failover draft
(expired)
> and the severe lack of interest from ADs (at least in the past) for
> advancing this protocol, and the questional need for an
interoperatable
> protocol between different vendor's servers, it seems using a DHCPv6
> message to allow for DHCPv6-server to DHCPv6-server communication was
> potentially useful (it also avoids the need for more port number
> allocations or potential conflicts if "private" port numbers were
> selected).

Well, I agree. For our part we'd like to ask other instances of our
server for 
a list of capabilities, service locations, and anything else we can
dream up.

- Bud

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 28 Apr 2008 18:52:52 -0700

> is unlikely IANA would assign that message number for a long time.)

Well, I'm concerned about people hijacking options, but I still don't
think I'd direct IANA to allocate options randomly.  First, more work
for them, second, I can see an implementation case where DHCP software
allocates a fixed array (compiled in probably) for option code
definitions.  Allocating options randomly deselects the ability to
index this array directly by option code (as was done in e.g. ISC DHCP
3.0.x).

We used to do something like this, we might have done something much
more like this (but I decided to go a different route), but we don't
do either method anymore, largely in order to support the Vendor-
Identified spaces as 32-bit option code spaces (where the enterprise-
id is just an option code).

I don't know if such deselection is universal, but I think at least
minimalistic software is likely to benefit from having the "used"
option codes in as compact a binary space as possible, if for no
other reason than to make it possible to index an array of 'dhcp
options' directly by option code.

> think we *need* the reserved options, it just made life a bit easier.

We could check the minutes, but my memory of the WG meeting is that,
after some discussion of many of these talking points, we left the
discussion after an objection was raised that if one were to put this
mechanism in an RFC, then hypothetical people might believe it to be a
good idea, implying this to be an undesirable end result.

I thought this was rather remarkable at the time as, although I am not
terribly experienced in IETF matters, I can think of several RFCs that
were not, are not, and probably never will be good ideas, and many
drafts (such as draft-ietf-wrec-wpad) that would have served the
network much better as an RFC standard despite its marked lack of
visitation by the good idea fairy.

-- 
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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Bud Millwood <[email-masked]>
Date: Tue, 29 Apr 2008 08:36:25 +0200

On Tuesday 29 April 2008, you wrote:
> some kind of special encoding to encode IANA-assigned options.

Like a VSO with enterprise number 0? Unless there's some reason I'm not aware 
of to use EID 0 for IANA, this seems really easy.

> as sub-options or perhaps even as vendor-options).

Same as above.

> of messy to redefine all of the IANA options?

I think the benefit is dubious. We already have VSO, and packet decoders have 
to deal with that.

As for the second part of your paragraph, my first response applies. A VSO 
with EID 0.

> think we *need* the reserved options, it just made life a bit easier.

OK. I don't think we need the reserved options at all, because it doesn't make 
anything easier for us - in fact it seems to needlessly complicate the 
matter.

As for just having the vendor-specific message at all... well, it would help 
us to standardize a behavior that we already "sort of" use.

And as for Shane's comment, my understanding was that he was concerned that 
vendors would end up implementing functionality that could be of benefit to 
the DHCP standard itself. My response to that is that vendors will always 
implement anything they find beneficial regardless of where the standard 
stops. If not in a vendor-specific message, then through some other means. If 
the WG decides to standardize something that's been implemented in a 
vendor-specific message, that's great for everyone.

Bud Millwood
Weird Solutions, Inc.