Subject: [dhcwg] dhc wg last call on "Virtual Subnet Selection Option"

From: Stig Venaas <[email-masked]>
Date: Thu, 15 Dec 2005 15:10:05 +0100

This message announces a WG last call on "Virtual Subnet Selection
Option" <draft-ietf-dhc-vpn-option-05.txt>.  The last call will
conclude at 1700 ET on 2005-12-29.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

"Virtual Subnet Selection Option" defines a new DHCP option for
passing Virtual Subnet Selection (VSS) information between the DHCP
client and the DHCP server.  It is intended for use primarily by DHCP
proxy clients in situations where VSS information needs to be passed
to the DHCP server for proper address allocation to take place.

This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-05.txt

Prior to initiating this last call we asked for objections.  We did
not get any objections, but there was a mail from Bernie Volz to
dhcwg list on November 28, that we believe should be treated as part
of the last call feed back.

Stig

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2005 12:02:42 -0700

This option requires special-case code in the DHCP server to force it to be 
sent even if the client doesn't request it - that is, it changes the basic 
operation of the DHCP protocol.   As such, I respectfully request that the 
working group not advance the option until that text is replaced with text 
that conforms to the way the protocol currently works - the client MUST 
request the option.

One of the problems that comes up with this option is that a client could send 
it and exhaust the server's address pool.   Since the option is intended for 
use by a DHCP proxy agent, is there any reason not make this a relay agent 
information suboption?   It's okay if the answer is "no" - I'm just curious 
why it wasn't done this way.   In general I'd think it would be preferable to 
have the proxy agent unicast the DHCP packet to the server as a relay agent, 
rather than broadcasting it to the local network as a client.

One interesting thing about this option is that since it's used by a proxy 
device, rather than by an individual client, it's actually a very good 
candidate for shared-secret-based authentication: the proxy device will 
support many clients, and it's under the same administrative domain as the 
DHCP server, so the usual problems with scalability don't apply as severely.   
So this could be the option that actually creates a plausible case for 
deploying RFC3118 - in that sense, I'm quite interested in seeing this option 
go forward.