Subject: Re: NA in optimistic state

From: Jen Linkova <[email-masked]>
Date: Tue, 10 Mar 2020 08:10:26 +1100

...slowly catching up on email backlog...

On Wed, Jan 15, 2020 at 1:56 AM Pascal Thubert (pthubert)
<[email-masked]> wrote:
> I'm a bit confused by text in https://tools.ietf.org/html/draft-linkova-6man-grand-01#section-3.2
>
> "
>    If there is no entry then it would be created/updated with the
>    supplied LLA and its state set to STALE.  In that case as soon as the
>    entry is used for sending traffic to the host, the entry state will
>    be changed to DELAY and the Neighbor Unreachability Detection would
>    be started and the rightful owner LLA will be entered in the cache.
> "
>
> NUD is unicast, and in this case the router would send the NS to the optimistic node and the silent owner would not know.

Pls note that the scenario in that section is:
1) a host X has an address A assigned but has not been using it (no ND
cache entry);
2) a host Y joins the network and is trying to assign the same address
A (using the optimistic DAD) by sending unsolicited NA.
  - a STALE entry created mapping A <> Y_MAC
3) a host X started sending packets
4) Y completes the DAD and detects the duplicated address.
5) return traffic arrives for X.
6) the router sees the STALE entry, uses it for sending the traffic to
Y (not X, who is the "rightful owner"), sends the entry state to DELAY
and then to PROBE and starts NUD by sending the unicast NS
7) Y does not respond to unicast NS as DAD has been completed and
duplication has been detected
8) after unicast NSes have not been answered, the router changes the
cache to INCOMPLETE and sends multicast NSes
9) X receives the multicast NS and responds, the entry changed to REACHABLE.

X would experience the disruption between  #3 (or #2 if it happens
right after #3) and #9.

> The typical optimistic operation is that the router does a lookup not a NUD. That would I guess happen in parallel with the DAD from the optimistic node that is still ongoing.

Basically if the address was assigned to another host but there was no
entry and then another host is trying to use the same address, then
the rightful owner would experience the traffic disruption (in the
worst case scenario) for (time until DAD is completed +
DELAY_FIRST_PROBE_TIME seconds + MAX_UNICAST_SOLICIT *RetransTimer
milliseconds).

> Did I misunderstand the intent in the text?

Well, I guess the text is not clear enough...I'll do smth about it
then - the new version will be submitted in a few hours. Thanks for
your comment!

-- 
SY, Jen Linkova aka Furry

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Mar 2020 11:04:14 +0000

Hello Jen:

Your scenario expects that the DAD has completed, meaning that X has defended its address before the first packet from the outside comes in. At the end of your scenario, X will get some unexpected packets, which may be trouble. But that's a problem with oDAD anyway.

I was worried about race conditions when packets come back faster than Y gets the NA(O) from X. I agree that is low probability with normal hosts on wires. But a duty cycled node might have the problem. And the multicast NS may be delayed at the MAC layer longer than the NA, e.g., if the router is wired and X and Y are wireless, the DAD process could take 20ms for the 2 consecutive multicasts to be scheduled on Wi-Fi. I guess in theory it could be longer than that, after all the DAD time out is one second.

If the DAD did not happen yet when a packet shows up at the router, the router NUDs and Y responds. And the router will send traffic to Y. Which will appear to work fine for a while till X finally wakes up and answers the DAD. At which point Y should yield.
I expect the router to see the NA(O) and fix the NCE. For a period of time X will get traffic that's meant for Y, and Y will be disconnected. Again that's ODAD for you.

This is all remote probability, the least probable being that we ever have a collision in address assignment. 

NB: The scenario also depend on X getting the NS (DAD) at all (remember our experiences at the IETF, that's not a thing you want to depend upon) but that's a problem with ND already.
Your proposal does not seem to change the outcome. Interestingly it seems that if Y uses the address for a short period and X does not realize, things work better than if X defends the address. Food for thoughts.

I'd prefer that we fix the whole thing so DAD works quickly without multicast and addresses cannot be stolen. But that's another story.

All the best

Pascal

> -----Original Message-----
> From: Jen Linkova <[email-masked]>
> Sent: lundi 9 mars 2020 22:10
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: NA in optimistic state
> 
> > I'm a bit confused by text in
> > https://tools.ietf.org/html/draft-linkova-6man-grand-01#section-3.2
> >
> > "
> > NUD is unicast, and in this case the router would send the NS to the
> optimistic node and the silent owner would not know.
> 
> 1) a host X has an address A assigned but has not been using it (no ND cache
> entry);
> 2) a host Y joins the network and is trying to assign the same address A (using
> the optimistic DAD) by sending unsolicited NA.
> 6) the router sees the STALE entry, uses it for sending the traffic to Y (not X,
> who is the "rightful owner"), sends the entry state to DELAY and then to
> PROBE and starts NUD by sending the unicast NS
> 8) after unicast NSes have not been answered, the router changes the cache
> to INCOMPLETE and sends multicast NSes
> X would experience the disruption between  #3 (or #2 if it happens right after
> #3) and #9.
> 
> > The typical optimistic operation is that the router does a lookup not a NUD.
> That would I guess happen in parallel with the DAD from the optimistic node
> that is still ongoing.
> 
> Basically if the address was assigned to another host but there was no entry
> and then another host is trying to use the same address, then the rightful
> owner would experience the traffic disruption (in the worst case scenario)
> for (time until DAD is completed + DELAY_FIRST_PROBE_TIME seconds +
> MAX_UNICAST_SOLICIT *RetransTimer milliseconds).
> 
> Well, I guess the text is not clear enough...I'll do smth about it then - the new
> version will be submitted in a few hours. Thanks for your comment!
> 
> --

---

From: Jen Linkova <[email-masked]>
Date: Mon, 30 Mar 2020 17:51:07 +1100

Hi Pascal,

Thanks for you comments, I think I might need to add more text in the
draft re: various DAD conflict scenarios.

>But that's a problem with oDAD anyway.

Yes, my understanding is that with oDAD it's quite possible for the
rightful owner to receive some "unexpected" traffic, which belongs to
the owner if the Optimistic address. I'm not sure we even consider it
a disruption.

> I was worried about race conditions when packets come back faster than Y gets the NA(O) from X.

It looks to me that until the DAD is completed, X would experience
some disruption *if* X was sending traffic.

So let's say the following happened:
T0: the router has no entry for IP_X
T1: X started sending some traffic, as as X does not support the new
proposed mechanism, X does not send unsolicited NAs, so router still
does not have a cache entry for IP_X
T2: Y sends an unsolicited NA and creates a STALE entry for IP_X <> MAC_Y
T3: The first packets to IP_X arrive (at least some of them belong to
return flows to X; maybe some of them are responses to Y as well, but
it does not matter: if we have addresses collision, it's OK if Y does
not get its traffic back; we only care about the legitimate address
owner);
At this moment is does not really matter if Y has completed DAD or not. Because:
T4: Router forwards traffic to Y , sets the state to DELAY.  Here the
DELAY state is actually important. I'm not sure if modern routers do
use any data plane traffic to confirm reachability? If they do, Y
might respond and move the entry to REACHABLE, which the worst case
scenario. Otherwise the router willl send an unicast NS in
DELAY_FIRST_PROBE_TIME seconds (5 secs by default), and I'd say if DAD
is not completed by that time we have problem anyway.

T5: DAD is completed. Y stopped using IP_X. If the router has a
REACHABLE entry for IP_X <>MAC_Y, then the X would experience an
interruption for quite a bit (until ReachableTime expires and then for
the whole NUD cycle).  If the entry is still in DELAY/PROBE state,
then the additional delay will be MAX_UNICAST_SOLICIT * RETRANS_TIMER
(3 secs by default).

However there is another thing: when X receives an NS, it would
respond with NA. If that NA reaches the router before Y sends its
unsolicited NA, the router would create a correct cache entry for IP_X
<> MAC_X.
(I assume that router *is* implementing the proposed change and
creates a STALE entry. If it does not then we are not introducing any
new outage scenario at all)

So...Maybe it makes sense to explicitly request a host to send the DAD
NS first and only then send an unsolicited NA...In that case the
section 4.1.2 of the draft would say:
' if Optimistic DAD [RFC4429] is used: a new Optimistic GUA is
assigned to the host interface. The host SHOULD send the unsolicited
NA after the first DAD NS for that address'.

>I agree that is low probability with normal hosts on wires. But a duty cycled node might have the problem. And the multicast NS may be delayed at the MAC layer longer than the NA,

That unsolicited NAs are also multicast. So I guess they might be
delayed as well?

>e.g., if the router is wired and X and Y are wireless, the DAD process could take 20ms for the 2 consecutive multicasts to be scheduled on Wi-Fi. I guess in theory it could be longer than that, after all the DAD time out is one second.
>
> If the DAD did not happen yet when a packet shows up at the router, the router NUDs and Y responds. And the router will send traffic to Y. Which will appear to work fine for a while

As I described above, it would cause some interruption for X *if* the
first packet to X arrives after Y joined the network but before DAD
discovers the duplicate.

> till X finally wakes up and answers the DAD. At which point Y should yield.

Yes, exactly. The whole ND machinery relies heavily on DAD packets not
being lost. If they do then it's another, much bigger problem space.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 30 Mar 2020 07:11:21 +0000

I think we agree, Jen.

All in all, the proposal does not seem to be worse than the existing.

Yes, the problem of multicast being unreliable for wireless and sleeping devices is a much bigger problem space.
In the IOT space we did not have the option to look elsewhere so we made the DAD process unicast.

Keep safe!

Pascal

> Sent: lundi 30 mars 2020 08:51
> Thanks for you comments, I think I might need to add more text in the draft
> re: various DAD conflict scenarios.
> 
> > Your scenario expects that the DAD has completed, meaning that X has
> defended its address before the first packet from the outside comes in. At the
> end of your scenario, X will get some unexpected packets, which may be
> trouble.
> >But that's a problem with oDAD anyway.
> 
> Yes, my understanding is that with oDAD it's quite possible for the rightful
> owner to receive some "unexpected" traffic, which belongs to the owner if the
> Optimistic address. I'm not sure we even consider it a disruption.
> 
> It looks to me that until the DAD is completed, X would experience some
> disruption *if* X was sending traffic.
> 
> T1: X started sending some traffic, as as X does not support the new proposed
> mechanism, X does not send unsolicited NAs, so router still does not have a
> cache entry for IP_X
> T3: The first packets to IP_X arrive (at least some of them belong to return
> flows to X; maybe some of them are responses to Y as well, but it does not
> matter: if we have addresses collision, it's OK if Y does not get its traffic back;
> we only care about the legitimate address owner); At this moment is does not
> really matter if Y has completed DAD or not. Because:
> T4: Router forwards traffic to Y , sets the state to DELAY.  Here the DELAY
> state is actually important. I'm not sure if modern routers do use any data
> plane traffic to confirm reachability? If they do, Y might respond and move the
> entry to REACHABLE, which the worst case scenario. Otherwise the router willl
> send an unicast NS in DELAY_FIRST_PROBE_TIME seconds (5 secs by default),
> and I'd say if DAD is not completed by that time we have problem anyway.
> 
> T5: DAD is completed. Y stopped using IP_X. If the router has a REACHABLE
> entry for IP_X <>MAC_Y, then the X would experience an interruption for
> quite a bit (until ReachableTime expires and then for the whole NUD cycle).  If
> the entry is still in DELAY/PROBE state, then the additional delay will be
> MAX_UNICAST_SOLICIT * RETRANS_TIMER
> (3 secs by default).
> 
> However there is another thing: when X receives an NS, it would respond with
> NA. If that NA reaches the router before Y sends its unsolicited NA, the router
> would create a correct cache entry for IP_X <> MAC_X.
> (I assume that router *is* implementing the proposed change and creates a
> STALE entry. If it does not then we are not introducing any new outage
> scenario at all)
> 
> So...Maybe it makes sense to explicitly request a host to send the DAD NS first
> and only then send an unsolicited NA...In that case the section 4.1.2 of the
> draft would say:
> ' if Optimistic DAD [RFC4429] is used: a new Optimistic GUA is assigned to the
> host interface. The host SHOULD send the unsolicited NA after the first DAD
> NS for that address'.
> 
> >I agree that is low probability with normal hosts on wires. But a duty
> >cycled node might have the problem. And the multicast NS may be delayed
> >at the MAC layer longer than the NA,
> 
> That unsolicited NAs are also multicast. So I guess they might be delayed as
> well?
> 
> >e.g., if the router is wired and X and Y are wireless, the DAD process could
> take 20ms for the 2 consecutive multicasts to be scheduled on Wi-Fi. I guess in
> theory it could be longer than that, after all the DAD time out is one second.
> >
> > If the DAD did not happen yet when a packet shows up at the router,
> > the router NUDs and Y responds. And the router will send traffic to Y.
> > Which will appear to work fine for a while
> 
> As I described above, it would cause some interruption for X *if* the first
> packet to X arrives after Y joined the network but before DAD discovers the
> duplicate.
> 
> > I expect the router to see the NA(O) and fix the NCE. For a period of time X
> will get traffic that's meant for Y, and Y will be disconnected. Again that's
> ODAD for you.
> >
> > NB: The scenario also depend on X getting the NS (DAD) at all (remember
> our experiences at the IETF, that's not a thing you want to depend upon) but
> that's a problem with ND already.
> 
> Yes, exactly. The whole ND machinery relies heavily on DAD packets not being
> lost. If they do then it's another, much bigger problem space.
> 
> > Your proposal does not seem to change the outcome. Interestingly it seems
> that if Y uses the address for a short period and X does not realize, things work
> better than if X defends the address. Food for thoughts.
> > I'd prefer that we fix the whole thing so DAD works quickly without multicast
> and addresses cannot be stolen. But that's another story.
> >
> >
> > > 1) a host X has an address A assigned but has not been using it (no
> > > ND cache entry);
> > > 2) a host Y joins the network and is trying to assign the same
> > > address A (using the optimistic DAD) by sending unsolicited NA.
> > > 6) the router sees the STALE entry, uses it for sending the traffic
> > > to Y (not X, who is the "rightful owner"), sends the entry state to
> > > DELAY and then to PROBE and starts NUD by sending the unicast NS
> > > right after
> > > That would I guess happen in parallel with the DAD from the
> > > optimistic node that is still ongoing.
> > >
> > > Basically if the address was assigned to another host but there was
> > > no entry and then another host is trying to use the same address,
> > > then the rightful owner would experience the traffic disruption (in
> > > the worst case scenario) for (time until DAD is completed +
> > > DELAY_FIRST_PROBE_TIME seconds + MAX_UNICAST_SOLICIT
> *RetransTimer milliseconds).
> > >
> > > then - the new version will be submitted in a few hours. Thanks for your
> comment!
> > >
> > > --