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

[Erik Nordmark <[e-mail]>]

On 7/17/15 9:34 AM, Fred Baker (fred) wrote:
>> So the next logical thing to do would be to have the router default to
>> unicast Router Advertisements, measure the rate of received Router
>> Solicitations, and switch to multicast RA mode past a certain
>> threshold to cover this sort of situation. Once the number of RSes
>> falls, it switches back to unicast RA mode.
>>
>> That would get rid of the configuration knob proposed in this ID, and
>> is behaviour that I think could be universal for all link types,
>> rather than just for the case of wireless ones with mobile devices.
> If it were me implementing it, I think I would go about this in a little different way, hopefully simpler. I would want to send at most one (e.g., either zero or one) RA per some interval (a second?). In the normal case, that is sent unicast. However, having sent a unicast RA at time t, if I now receive another RS before t+1, I send the next one (at time t+1) as a multicast.

First of all I support this document as a WG document.

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.

(*) the only case in RFC 4861 when I think a multicast response might be 
considered is when the source IPv6 address in the RS is the unspecified 
address. Further, an implementation which rate limits received RS 
packets (e.g., CoPP in a router) might also want to detect when the rate 
limit might have dropped RS packets and multicast an RA in that case.


I do wonder why implementations haven't already changed to send unicast 
solicited RA, and whether it would make a difference if we have an 
informational document asking them to do this. Alternatively we could 
have a proposed standard which updates section 6.2.6 to change the "MAY 
unicast" to a "SHOULD unicast".

FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6.

Thanks,
    Erik

>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops