[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: RFC 7527 Optimistic Duplicate Address Detection (DAD) for IPv6 and Address Resolution
From: prabhakar lakhera <prabhakar.lakhera () gmail ! com>
Date: 2020-04-29 1:26:12
Message-ID: CALg+rhU8pyaASpo17V73ziOD3CCL7ZPfGtkw0CCiwUnFHxq2xQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
>
> 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
>
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><div><font \
face="arial, sans-serif">Hi,</font></div><div><font face="arial, \
sans-serif"><br></font></div><div><font face="arial, sans-serif">Wanted to check if \
this behavior outlined in RFC 7527 is too restrictive..</font></div><div><font \
face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><a \
href="https://www.rfc-editor.org/rfc/rfc4429.html#section-3.2" \
target="_blank">https://www.rfc-editor.org/rfc/rfc4429.html#section-3.2</a><br></font></div><div><font \
face="arial, sans-serif"><br></font></div><div><font face="arial, \
sans-serif">Specifically:</font></div><div><font face="arial, \
sans-serif"><br></font></div><div><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">* (modifies <a \
href="https://www.rfc-editor.org/rfc/rfc4429.html#section-7.2.2" \
target="_blank">section 7.2.2</a>) A node MUST NOT use an Optimistic Address as the \
source address of a Neighbor Solicitation. </font></pre><font face="arial, \
sans-serif"><br></font></div><div><font face="arial, sans-serif">The reasoning is \
detailed here:</font></div><div><font face="arial, \
sans-serif"><br></font></div><div><font face="arial, sans-serif"><a \
href="https://www.rfc-editor.org/rfc/rfc4429.html#section-2.2" \
target="_blank">https://www.rfc-editor.org/rfc/rfc4429.html#section-2.2</a><br></font></div><div><font \
face="arial, sans-serif"><br></font></div><div><font face="arial, \
sans-serif">"<span style="font-size:13.3333px"> In order to avoid interference, \
it is important that an Optimistic </span><span style="font-size:13.3333px">Node \
does not send any messages from an Optimistic Address</span></font></div><div><font \
face="arial, sans-serif"><span style="font-size:13.3333px"> that will </span><span \
style="font-size:13.3333px">override its neighbors' Neighbor Cache (NC) entries \
for the address </span><span style="font-size:13.3333px">it is trying to configure: \
doing so would disrupt the</span></font></div><div><font face="arial, \
sans-serif"><span style="font-size:13.3333px"> rightful owner</span><span \
style="font-size:13.3333px"> of the address in the case of a \
collision."</span></font></div><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif"><br></font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">It then goes on to list the following:</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif"><br></font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"> * \
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.</pre><pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><br></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">That seems somewhat limiting.</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif"><br></font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">Take the scenario of a client device connecting to another \
device that acts as an Access point without</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">really providing routing (say a thermal camera device, \
android auto/car play head unit or some other smart device).</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif"><br></font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">Right now, this would be the sequence:</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif"><br></font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">1. Interface comes up</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">2. Client attached to device acting as WiFi access \
point.</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">3. Both sides configure LLA pretty quickly.</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">4. Client uses multicast service discovery to get the LLA \
endpoint of the device.</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">5. Client attempts connect to the device's endpoint. \
Optimistic DAD implies, the address can be used.</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">6. Outgoing TCP SYN from client will trigger address \
resolution, and it will be queued pending address resolution \
completion.</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">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,</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif"> the neighbor cache entry at Client for Device would stay \
in INCOMPLETE state and no NS will be sent out from client, till \
address</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif"> moves from optimistic to preferred.</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">8. 7 Implies a wait time of DAD attempts * DAD \
interval</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif"><br></font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">That runs in seconds and that delay is visible to \
user.</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><br></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">Given that source link layer information is optional in NS, \
wouldn't just mandating that SLLAO doesn't get sent in NS from \
client,</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">be enough to not cause any disruptions rather than not \
allowing NS to be sent at all?</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><br></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">Or may be I am missing something here. Looking forward to \
hear some feedback on this.</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif"><br></font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">Thanks!</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif"><br></font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"><font \
face="arial, sans-serif">Prabhakar</font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"></pre></pre><font \
face="arial, sans-serif"><br></font></pre></pre></div> </blockquote></div></div>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic