Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

[Simon Perreault <[e-mail]>]

Le 2013-11-27 06:10, Qi Sun a écrit :
>> If not, why exclude requesting the 4o6 server option? Obviously, it’s
>> pointless allowing the Enable option, but sending the 4o6 server
>> option within the BOOTREPLYV6 to allow a dedicated DHCP4o6 server to
>> tell the client to use unicast seems like it could be a good idea.
>> What’s the reason for specifically excluding it?
>
> [Qi] Allowing the client to request the 4o6 server address option would
> violate the Bullet 4 in section 8: the client only receives the 4o6
> Server Address option but no DHCPv4 over DHCPv6 Enable option, then the
> client is required to ignore the 4o6 Server Address option.

You don't want to have a server sending an option that was not requested 
by the client. Stay with the usual ORO model. Here's a proposal:

- The client MUST always include both OPTION_DHCP4_O_DHCP6_ENABLE and 
OPTION_DHCP4_O_DHCP6_SERVER in the ORO.

- The server responds with zero (if DHCPv4-over-DHCPv6 is not available) 
or one of two options. Never both.
     - OPTION_DHCP4_O_DHCP6_ENABLE means "multicast".
     - OPTION_DHCP4_O_DHCP6_SERVER means "unicast".

If this makes sense, then I would rename the options: 
s/ENABLE/MULTICAST/ and s/SERVER/UNICAST/. And maybe go further and kill 
OPTION_DHCP4_O_DHCP6_ENABLE, and just put the multicast address in the 
payload of OPTION_DHCP4_O_DHCP6_SERVER.

By the way, a suggestion for the document: replace all instances of "4o6 
Server Address option" with the full option name, 
"OPTION_DHCP4_O_DHCP6_SERVER". Always using the same terminology makes 
it much easier to grep the document.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca