Subject: Re: RFC 7527 Optimistic Duplicate Address Detection (DAD) for IPv6 and Address Resolution

From: prabhakar lakhera <[email-masked]>
Date: Sun, 3 May 2020 00:38:28 -0700

I have to correct myself here.

RFC 4861 does mandate sending SLLAO for multicast NS (which would be the
case for address resolution here) and that does make sense.
While it is definitely desired, I am not sure how can we resolve the stated
issue below without relaxing that requirement.

One could modify the requirement that multicast NS with source that is
preferred MUST send SLLAO.
And RFC 7527 could relax the requirement and allow for sending multicast NS
for address resolution with optimistic address which MUST not include SLLAO.

It does imply that for the scenario below, responding to such multicast NS
with an unicast NA would in turn trigger another address resolution but
that is not very different from when unicast NS may miss SLLAO and the
target doesn't have NS's source entry in its neighbor cache.

It would still result in establishing the data path faster than waiting for
DAD to complete.

I am not sure, how else it could be solved other than a more complicated
work around of requiring such APs to advertise RA with SLLAOs even when
they are not providing any IPv6 kind of routing.

On Tue, Apr 28, 2020 at 6:26 PM prabhakar lakhera <
[email-masked]> wrote:

> Hi,
>>
>> Wanted to check if this behavior outlined in RFC 7527 is too restrictive.
>>
>> https://www.rfc-editor.org/rfc/rfc4429.html#section-3.2
>>
>> Specifically:
>>
>> * (modifies section 7.2.2 <https://www.rfc-editor.org/rfc/rfc4429.html#section-7.2.2>)  A node MUST NOT use an Optimistic Address
>> as the source address of a Neighbor Solicitation.
>>
>>
>> The reasoning is detailed here:
>>
>> https://www.rfc-editor.org/rfc/rfc4429.html#section-2.2
>>
>> " In order to avoid interference, it is important that an Optimistic Node
>> does not send any messages from an Optimistic Address
>>   that will override its neighbors' Neighbor Cache (NC) entries for the
>> address it is trying to configure: doing so would disrupt the
>>   rightful owner of the address in the case of a collision."
>>
>>
>> It then goes on to list the following:
>>
>>
>>    * Never sending Neighbor Solicitations from an Optimistic Address.
>>      NSes include a Source Link-Layer Address Option (SLLAO), which
>>      may cause Neighbor Cache disruption.  NSes sent as part of DAD
>>      are sent from the unspecified address, without a SLLAO.
>>
>>
>> That seems somewhat limiting.
>>
>>
>> Take the scenario of a client device connecting to another device that acts as an Access point without
>>
>> really providing routing (say a thermal camera device, android auto/car play head unit or some other smart device).
>>
>>
>> Right now, this would be the sequence:
>>
>>
>> 1. Interface comes up
>>
>> 2. Client attached to device acting as WiFi access point.
>>
>> 3. Both sides configure LLA pretty quickly.
>>
>> 4. Client uses multicast service discovery to get the LLA endpoint of the device.
>>
>> 5. Client attempts connect to the device's endpoint. Optimistic DAD implies, the address can be used.
>>
>> 6. Outgoing TCP SYN from client will trigger address resolution, and it will be queued pending address resolution completion.
>>
>> 7. Even though client LLA is optimistic, because it is the only address available and the device isn't sending RA with SLLAO or NS,
>>
>>     the neighbor cache entry at Client for Device would stay in INCOMPLETE state and no NS will be sent out from client, till address
>>
>>     moves from optimistic to preferred.
>>
>> 8. 7 Implies a wait time of DAD attempts * DAD interval
>>
>>
>> That runs in seconds and that delay is visible to user.
>>
>>
>> Given that source link layer information is optional in NS, wouldn't just mandating that SLLAO doesn't get sent in NS from client,
>>
>> be enough to not cause any disruptions rather than not allowing NS to be sent at all?
>>
>>
>> Or may be I am missing something here. Looking forward to hear some feedback on this.
>>
>>
>> Thanks!
>>
>>
>> Prabhakar
>>
>>
>>

---

From: prabhakar lakhera <[email-masked]>
Date: Fri, 8 May 2020 00:45:27 -0700

Fixed the typo in the RFC number below.
Any thoughts? Some quick changes from my side shows connection setup times
for client to accessory acting as WiFi AP over v6 LLA that gets triggered
right after joining it, from ~2 seconds to a tens of milliseconds.

On Sun, May 3, 2020 at 12:38 AM prabhakar lakhera <
[email-masked]> wrote:

> While it is definitely desired, I am not sure how can we resolve the
> stated issue below without relaxing that requirement.
>
> And RFC 7527 4429 could relax the requirement and allow for sending
> multicast NS for address resolution with optimistic address which MUST not
> include SLLAO.
>
> It would still result in establishing the data path faster than waiting
> for DAD to complete.
>