Subject: [dhcwg] DHCPv6 message type

From: Bud Millwood <[email-masked]>
Date: Thu, 17 Apr 2008 22:53:26 +0200

A few months back I was thinking about how to locate other DHCP servers on the 
network for the purpose of exchanging information. It occurred to me that the 
simple solution would be to have a DHCP message type that was strictly for 
carrying vendor-specific data.

On the one hand it seems like hijacking the protocol, but on the other it's 
simple to deal with if you're not the vendor in question - simply drop the 
packet.

Has anyone else considered this idea?

-- 
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: Thu, 17 Apr 2008 15:20:03 -0700

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 24 Apr 2008 17:38:37 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf
Of David W. Hankins
Sent: Thursday, April 17, 2008 6:20 PM
To: [email-masked]
Subject: Re: [dhcwg] DHCPv6 message type

---

From: Shane Kerr <[email-masked]>
Date: Fri, 25 Apr 2008 08:41:12 +0200

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.

--
Shane

---

From: Bud Millwood <[email-masked]>
Date: Mon, 28 Apr 2008 09:45:28 +0200

> 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

---

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

>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: [email-masked] [mailto:[email-masked]] On Behalf
Of Bud Millwood
Sent: Monday, April 28, 2008 3:45 AM
To: [email-masked]
Subject: Re: [dhcwg] DHCPv6 message type

> 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

---

From: Damien Neil <[email-masked]>
Date: Mon, 28 Apr 2008 16:39:07 -0700

> the server as well as what basic capabilities (aka other services)  

It seems to me that an Information-Request message would work well for  
this purpose.

                    - Damien

---

From: Bud Millwood <[email-masked]>
Date: Wed, 30 Apr 2008 14:29:26 +0200

> It seems to me that an Information-Request message would work well for

   A server MUST discard any Solicit, Confirm, Rebind or
   Information-request messages it receives with a unicast destination
   address.

That sentence could be a show stopper. Also, it seems like we'd be overloading 
the semantics of info-req, if not the syntax. And I think, in the past with 
DHCP, most of the times we've overloaded the semantics of something it all 
just went to h*ll (v4 siaddr comes to mind). :)

- Bud