dhc wg last call on "Virtual Subnet Selection Option"
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.
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.
Re: dhc wg last call on "Virtual Subnet Selection Option"
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