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

[Mark Smith <[e-mail]>]

Hi Fred,

On 16 July 2015 at 18:23, Fred Baker (fred) <[e-mail]> wrote:
>
>> On Jul 16, 2015, at 10:15 AM, Mark Smith <[e-mail]> wrote:
>>
>> I think this means that unicasting solicited RAs on certain link types
>> would usefully reduce multicasts. It does raise the question as to why
>> solicited RAs were multicast in the first place.
>
> Not sure. RFC 826, which is the obvious predecessor, calls for the response to an ARP request to be unicast.
>

Now you've mentioned an old RFC, it has reminded me of RC1256, "ICMP
Router Discovery Messages", which I came across again fairly recently.
It describes RS/RAs for IPv4, and somewhat surprisingly
implementations of it seem to be fairly available - Cisco and Juniper
call it IRDP, and e.g., my Fedora 22 host has a client for it
installed by default ('rdisc').

It says that RAs can be unicast, multicast or broadcast. It seems to
give a bit of a clue as to why multicast solicited RAs would be
useful:

"A unicast response may be delayed, and a multicast
   response must be delayed, for a small random interval not greater
   than MAX_RESPONSE_DELAY, in order to prevent synchronization with
   other responding routers, and to allow multiple, closely-spaced
   solicitations to be answered with a single multicast advertisement."

In 1991, hosts were pretty much mains powered, fixed location and
wired, so they could all rush to send multicast RSes after a mains
power outage or the 10BASE2 cable broke and was then fixed, and they
wouldn't have come and gone much from the link either. A single
multicast RA in response to the first RS in a flood of them could have
caused a lot of later RSes to be suppressed.

> Thanks for your note.

No worries.

Regards,
Mark.