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

[Marcin Siodelski <[e-mail]>]

On Wed, Nov 27, 2013 at 4:18 PM, Simon Perreault
<[e-mail]> wrote:
> Le 2013-11-27 10:10, [e-mail] a écrit :
>
>>> 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.
>>
>>
>> [ian] IIRC, putting the multicast address into the option was discussed in
>> the authoring process, but was rejected as being too error prone.
>
>
> How is a multicast address more error prone than a unicast address? Any
> network admin would immediately notice the error when "it doesn't work". And
> once it's in place, you don't play with it every day. IMHO the reduced
> complexity is definitely worth it.
>
> Does anyone have a convincing argument for this?
>
>

The OPTION_DHCP4_O_DHCP6_SERVERS is by its definition a collection of
the IP addresses. So the server configuration will probably allow
multiple occurrences of All_DHCP_Relay_Agents_and_Servers in the
OPTION_DHCP4_O_DHCP6_SERVER option. In some cases, the server
configuration may even allow to specify the mixture of multicast and
unicast addresses. That already implies, that either configuration
mechanism or/and the client not only does have to validate that there
is one and only one occurrence of each address in the option, but also
it has to validate that if there are unicast addresses the multicast
shouldn't be present (or vice-versa). Which one the client would
choose if there were both multicast and unicast. Is it really making
it simpler?

In the case proposed in the draft: if I want to use the multicast, I
send minimal amount of information to the client (boolean option). If
I want to use unicast I send two options, if client receives both
options it uses unicast. I am not certain if this is any more
complicated that parsing the option, eliminate the duplicates and the
problem of presence of both multicast and unicast etc. At least, what
you propose causes additional burden on the client's side to prevent
amplification attack when using multicast - something that we only had
for unicast so far.

Marcin