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

[Lorenzo Colitti <[e-mail]>]

On Thu, Jul 9, 2015 at 7:08 AM, Mark Smith <[e-mail]> wrote:

> It was my understanding that the idea behind multicasting solicited
> RAs was to also update hosts who were soon going to be issuing
> multicast RSes, which would then reduce the volume of multicast RSes.
> If those hosts are now not going to receive the multicast solicited
> RAs, then they I think they would now be issuing multicast RSes more
> often where as in the past they wouldn't.
>

Yes. In the (rare) case where a large number of nodes joins the network at
the same time, sending a single multicast RA would likely be more
efficient. That would need to be weighed against the power implications on
the nodes that are already connected, so it probably only makes sense if
the router is seeing large enough numbers of RS packets that it believes
that it cannot handle them efficiently.

We could put something in the draft saying that "routers configured in this
mode MAY send solicited RAs multicast in conditions where it is likely that
doing so will be more efficient (e.g., if a large number of clients is
sending RS packets at the same time and the packets are being dropped due
to control plane limiting).

As a side note, the radvd RA daemon already supports a UnicastOnly option:
>
> --
> UnicastOnly on|off
> Indicates that the interface link type only supports unicast. This
> will prevent unsolicited advertisements from being sent, and will
> cause solicited advertisements to be unicast to the soliciting node.
> This option is necessary for non-broadcast, multiple-access links,
> such as ISATAP.
>

That doesn't help because it doesn't do unsolicited advertisements.