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

[Mark Smith <[e-mail]>]

Hi Erik,

On 23 July 2015 at 08:21, Erik Nordmark <[e-mail]> wrote:
> On 7/21/15 1:25 PM, Mark Smith wrote:
>>
>>
>> I thought that could be an option, however I encountered RSes without
>> the Source Link Layer Option, which means if RFC6085 is to be used,
>> the link-layer header has to be available to get the source link-layer
>> address from.
>>
>> After I wondered about the efficiency benefit of using multicasts for
>> solicited RAs, Fred asked me to do some testing/investigation. I wrote
>> up what I found here, the few unusual RS cases I saw the following,
>> which I put down some thoughts about handling via e.g., RFC6085.
>>
>> o  RSes with a :: source address
>>
>> o  RSes with a link-local source addresses, but no Source Link-Layer
>> Address Option
>
>
> Yes, both of those are important (I had forgotten about the second one).
>
> As you say, an implementation might be able to use the link-layer header and
> unicast back a packet. If the source was :: then that approach would rely on
> sending to the multicast ff02::1 while the link-layer destination is
> unicast.
>
> If not, then the implementation needs to multicast the RA.
>

I was wondering if instead the implementation could trigger an ND/NS
transaction for the RS source address at that point, and then unicast
the RA when that completes.

RFC4861 seems to be a bit vague about being able to do that. It says
that if the SLLO is not present, the router still can unicast the RA.
As RFC4861 is pre RFC6085, then performing a ND/NS first would be the
only way to do that. The last sentence also seems to be permitting NC
entries to be created when there is no SLLO ("or not a Source
Link-Layer is provided" ... "Neighbor Cache entry" ... "(or is
created)").

"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."

Performing an NS/ND to resolve the source address of the RS without a
SLLO would seem consistent with the corresponding RS SLLO handling -
to load the Neighbor Cache with entries for nodes that have sent RSes.


Regards,
Mark.

>    Erik
>
>>
>> https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html
>>
>>
>>
>>
>> https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html
>>
>>> But I would not say it's sufficient, if only from an "explicit
>>> clarity" standpoint.  I think explicit mention of RAs and the other
>>> discussion is helpful for implementors not inclined to dig to great
>>> depths or just seeking explicit confirmation.
>>>
>>
>>
>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>