Re: [dhcwg] DHCPv6 message type

["Bernie Volz (volz)" <volz at cisco.com>]

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:budm at weird-solutions.com] 
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
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg