Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast

[Erik Nordmark <[e-mail]>]

On 7/21/15 12:47 PM, Ole Troan wrote:
>> But in terms of implementation, isn't it simpler to always(*) respond to a RS with a unicast RA?
>> As background, the text in RFC4861 comes from the old concern that all devices might boot at the same time when the power is re-established after a building power failure; that doesn't happen since most devices (laptops, smartphones, IoT devices) have batteries today. In that case it might have made sense to sending fewer RA messages by using multicast.
> in addition to Mark’s points.
>   - what happens when the router reboots, will not all the hosts then try to actively reconnect?
>     that router could server thousands of users.
>   - while this is intended for WIFI networks, in common deployments the WIFI interface is not integrated in the router. for the router’s perspective this just looks like another wired interface. either this has to be made configurable and not the default, or considerations of large flat wired L2 networks must also be considered.
>

Ole,

Even on a flat wired L2 network I don't think it is harmful to default 
to unicast solicited RAs.

If we take a worst case of 10000 hosts on the L2 network all 
rebooting/initializing at the same time, we will see:
  - 10000 DAD probes for link-local address
  - 10000 MLD joins for the solicited node MC for their link-locals
  - 10000 RS messages(*)
  - 1/10000 RA messages
  - 10000 DAD probes for global addresses (N x 10000 if N prefixes on-link)
  - N x 10000 mDNS etc type packets

(*) RFC 4861 suggests receiving an RA before an RS is sent, thus under 
some timing conditions some RS messages might be avoided.

But at best we seem to be talking about saving 20% of the packet during 
the boot of the 10000 hosts.

    Erik