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

[Mark Smith <[e-mail]>]

Hi,

On 9 July 2015 at 15:38, Fred Baker (fred) <[e-mail]> wrote:
>
>> On Jul 8, 2015, at 10:08 PM, Mark Smith <[e-mail]> wrote:
>>
>> One thought I have though is that I wonder if just changing solicited
>> RAs from multlicast to unicasts would result in an increase in the
>> number of multicast RSes?
>
> Sounds like you have a tool that you could use to simulate that and find out?

So thought about this a bit more, and realised that my thinking wasn't
quite right.

Hosts don't issue periodic multicast RSes, such that receiving a
solicited multicast RA a short period before a periodic multicast RS
would have been sent would suppress the multicast RS. Periodic
unsolicited multicast RAs keep hosts' knowledge of default routers
fresh, so hosts would only issue a multicast RS when they need to
discover routers "now" i.e., when an interface comes up.

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. The only other
benefit I can see of mulicasting solicited RAs is that it would keep
all of the receiving hosts' default router knowledge more accurate and
the aging of the default router information more synchronised across
all nodes over the periodic unsolicited multicast RAs. I'm not sure if
it would matter if the loss of this increased default router accuracy
and aging synchronisation would matter if solicited RAs were unicast
instead of being multicast.

Out of interest, I also captured RSes and RAs on my home Wifi LAN (all
hosts were variants of Linux), and also looked up some Windows boot
packet captures I have. Here's what I found and some thoughts.


o  RSes with a :: source address

Windows XP sends some early RSes with a source address of the
unspecified address. These RSes didn't have the Source Link-Layer
Address Option (because :: shouldn't be added to the neighbor cache).
This is permitted by RFC4861. It later sends RSes using a link-local
source address, now containing the Source Link-Layer Address Option.
Later versions of Windows didn't issue RSes with :: source addresses
i.e., they waited until they had a link-local address to use (and
included the Source Link-Layer Address Option).

It isn't possible to use the :: address as a destination address for
the solicited RA per RFC4291, so it seems the only choice for the IPv6
destination address is FF02::1. However, if the link-layer header
source address of the RS is available to the RA process, then it could
link-layer unicast the multicast RA, as per RFC6085, "Address Mapping
of IPv6 Multicast Packets on Ethernet".

I think it is necessary to describe how to handle these :: source
address RSes in this draft, as they're valid and could appear on a
"solicited unicast RA only" link.


o  RSes with a link-local source addresses, but no Source Link-Layer
Address Option

Some of my Linux hosts issued RSes with a link-local source address,
but without the Source Link-Layer Address Option. This also seems
permitted by RFC4861. These hosts were Fedora 22 hosts, using the user
space Network manager package to perform/handle RS/RA processing in
user space, verses other hosts (Android, Chrome OS) which are probably
using the Linux kernel's RS/RA facilities. I dug into the Network
manager code and found that it was using the libndp.org NDP library,
and was using a single call that builds a generic RS without the SLLA
option.

RFC4861 is pretty clear about what to do when there is an SLLA option
in an RS - create or update a neighbor cache entry for the RS source
address with the SLLA option value, and set it to STALE. However, I
don't find the text about when there is no SLLA option that clear:

"If there is no existing Neighbor Cache
   entry and no Source Link-Layer Address option was present in the
   solicitation, the router may respond with either a multicast or a
   unicast router advertisement.  Whether or not a Source Link-Layer
   Address option is provided, if a Neighbor Cache entry for the
   solicitation's sender exists (or is created) the entry's IsRouter
   flag MUST be set to FALSE."

It seems to be strongly implying that a neighbor cache entry could be
created even if there is no SLLA option, because it says it is
possible to respond with a unicast RA. However, to be able to use the
RS's source IPv6 address to unicast the RA, I think a NS/NA
transaction would need to occur first for the RS's source address,
before the unicast RA is sent.

The implementation could use the link-layer source address from the
frame the RS arrived in to send a link-layer unicast solicited unicast
RA (i.e., don't use the neighbor cache to resolve the link-layer
destination address, use the RS frame's source address). In that case,
I think the frame's link-layer source address should only be used for
this unicast solicited RA. An entry in the neighbor cache would be
created for the RS's source address, and then an NS/NA transaction to
verify its reachability independent of sending the RA.

Alternatively, the method of link-layer unicasting a multicast
solicited RA could be used, although there is probably more broader
value in the triggering an NS/NA transaction method.


o  At least one common IPv6 RA implementation isn't rate limiting
sending solicited RAs

This is for the current version of OpenWRT, sending way more than one
RA per 3 seconds if I solicit them quickly. So it may be worth
observing in the ID that RA rate limits may not have been implemented,
and unicasting RAs in that case will have the benefit of avoiding
sending these RAs to nodes that didn't solicit them.

17:14:47.312209 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router
solicitation, length 8
17:14:47.313398 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router
solicitation, length 8
17:14:47.314363 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router
solicitation, length 8
17:14:47.315563 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router
solicitation, length 8
17:14:47.316739 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router
solicitation, length 8
17:14:47.529880 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router
advertisement, length 192
17:14:47.533531 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router
advertisement, length 192
17:14:47.536100 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router
advertisement, length 192
17:14:47.538672 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router
advertisement, length 192
17:14:47.541194 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router
advertisement, length 192


Regards,
Mark.