RE: RFC4 4861 and unicast router solicitations

[Dmitry Anipko <Dmitry.Anipko at microsoft.com>]

Thanks Hesham, Hemant and Suresh for your responses.

It seems from them that the implied intent was that unicast-destined RSes should be allowed to be both sent and received and should be handled equally with multicast-destined ones. If that is the case, shall the RFC text be amended to reflect that more clearly?

To answer Suresh's question:

>> An unicast destination address is valid but not very useful. That is why
the multicast address is "typically" used. I am curious though, and I
would appreciate it if you can give a little bit of background on why
you would like to send an RS with a unicast destination address. If you
are doing it for checking reachability, an NS would be a better bet.

While as it was pointed out in your responses, unicast RSes may be useful/reasonable for any type of link, I faced this in the case of ISATAP links.

ISATAP clients are provisioned with potential routers by out of band mechanism.  In general the clients could send multicast RSes to the provisioned routers, however ISATAP doesn't natively support multicast, and hence it seemed that it would also be reasonable for the clients to send unicast RSes to the provisioned routers directly. However it was not clear whether such behavior would be compliant with RFC 4861.

Please let me know if you think there are additional considerations for this behavior in case of the non-multicast capable links.

Thanks,
Dmitry