[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] DHCPv6 message type
>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.
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.
> 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).
- Bernie
-----Original Message-----
From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
Of Bud Millwood
Sent: Monday, April 28, 2008 3:45 AM
To: dhcwg at ietf.org
Subject: Re: [dhcwg] DHCPv6 message type
On Friday 25 April 2008, Shane Kerr wrote:
> Bernie,
>
> I guess it depends on the use case for such a message type.
>
> Bud, maybe you can give us some examples of the kind of thing you want
> to do?
>
> My thinking is, there are probably uses for a vendor message type, but
> we should also look to see if there is missing functionality that
> would be independently invented by different vendors.
We have a command-line client that can log into our server and make
changes to
the running system. Today this client sends a non-standard message to
the
DHCP server port to query the server for information about how to
connect to
the server as well as what basic capabilities (aka other services) can
be
accessed.
Although the query is available from the DHCP frontend, the actual
services
are typically not.
Another possibility could be to query load status. In our case we have
quite a
bit of load information that would not make much sense to other servers.
Granted, all of this can be done outside the DHCP protocol, but the one
convenience is that with a vendor-specific message code we always know
where
to start - the dhcp server port.
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.
- Bud
> Shane
>
> On Apr 24, 2008, at 23:38 +0200, Bernie Volz (volz) wrote:
> > Yes, I did write such a draft (just over a year ago), see
> > http://tools.ietf.org/html/draft-volz-dhc-dhcpv6-vendor-message-00.
> >
> > I did not receive a warm reception for this idea, hence I stopped
work
> > on it. If there is interest, it can always be updated and
resubmitted.
> >
> > - Bernie
> >
> > -----Original Message-----
> > From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On
Behalf
> > Of David W. Hankins
> > Sent: Thursday, April 17, 2008 6:20 PM
> > To: dhcwg at ietf.org
> > Subject: Re: [dhcwg] DHCPv6 message type
> >
> > On Thu, Apr 17, 2008 at 10:53:26PM +0200, Bud Millwood wrote:
> >> Has anyone else considered this idea?
> >
> > I think Bernie wrote a draft essentially defining a number of
'vendor
> > identified message codes' for much the same reason. They looked a
lot
> > like the vendor-identified options; using an enterprise-id to
> > disambiguate.
> >
> > He presented (I thought it was in the most recent Vancouver?) the
> > draft, but it doesn't seem to have progressed.
> >
> > I think it's possible that based upon the discussion, Bernie may
have
> > determined further pursuit would not be a fruitful expendiature of
> > time.
> >
> > --
> > 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
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg at ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
--
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
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg