Subject: Re: [mobile-ip] Text proposal for Mobile IPv6 issue 154 ND Constants(Removing RS/DAD optimizations).

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jan 2003 00:06:03 +0100 (CET)

[Some late comments and a clarifying question at the end]

> Except that we still are debating the delay before initiating DAD.
> Following the RFCs to the letter, I think Vijay is technically
> right: if we are not initializing or re-initializing then we don't
> have to delay... just that noone has defined initialization in any
> exact sense. Clearly, if you turn off and on your interface then
> thats reinitialization. What if you WLAN card starts to hear another
> base station, is that reinitialization?

I think it is fair to say that the authors of RFC 2461 didn't think
to deeply about the exact definitions in the light of wireless links, but
I do think that we considered it ok to send an RS when the IP stack gets
an indication that a the link has come up after having been down - something
which might happen when there is a handover.
And if that is ok, then even without an explicit indication from L2
it should be ok to do the RS.

From a definition perspective observe that "interface" in RFC 2460
is subtly different than "interface" in an implementation - at least
the way I read things. A link is basically defined by the set of nodes
that attach to it. Thus if the set of neigbors the node sees is different 
for the old AP and the new AP, then it is a different
interface. Of course, in the implementation it is the same "wlan0" interface
independently of the set of neighbors.

So just a new AP doesn't mean that you are on a new link - you might have
multiple APs on the same link but only hear some of them.

> On the other hand, I also think Greg and others are right in the
> sense that there is a possibility of simultaneous movements which
> could cause a storm of DAD requests. I talked to some radio experts
> about this and they didn't have any papers that would tell us how
> bad the problem is. They did say, however, that ten years ago there
> was a concern that fast trains etc would cause a similar problem
> for cellular systems but that in practise this hasn't happened. And
> yes, James, there's probably some safety features in lower layers
> to deal with these things. WLANs have exponential back-off for
> collisions, for instance, and I suspect many wireless techniques
> have some inherently random delays before they can switch to
> another base station.

The RFC 2461 randomization concern was due to the power failure case
when lots of nodes with identical software and handware might
boot in lock step. I can see that similar things might happen
during "bulk" handover in theory unless there is something in
the process of detecting the movement at L2, doing the L2 handover, or
detecting the movement at L3, that randomize things.
I guess we don't have data on whether there are technologies where
there is in practise no randomizations.
Clearly (?) when movement detection is driven by a multicast RA, there
can be a high risk of multiple nodes detecting the movement from the same RA.
But it is too early to say whether this is problematic. Thus being conservative
while allowing hosts to have a local mechanism for the L2 (driver)  to
indicate that the L2 has random delays in its handover timing would make 
sense to me.

> There's also the question of how does the IP stack *know* that it
> has re-initialized an interface? Remember that many current
> drivers in Linux etc do not tell the IP stack that there's been a
> switch to a new base station. So, the IP stack learns that
> there's a new router and prefix, and it probably also sees that
> the flow of packets from the previous router has stopped...
> is this interface re-initialization or did someone turn off
> the router and installed a new one? And the initialization delay
> comes then at a time when we have received at least one RA and
> sent perhaps many NUD-related messages.

I think the synchronization risk comes from either an L2 handover
that happens more or less at the same time for a set of nodes and
an L2 "link up" notification to the IP stack, or no L2 notification but
a multicast RA that has the same effect.
In those cases it makes sense to ensure that there is some randomization
somewhere before the node sends its first IP packet (could be a DAD probe
and/or a RS).
Of course, experimenting with L2s e.g. by putting N PDAs with WLAN interfaces
in a box and moving them around will give an indication of to what extent
the L2 handovers happen at the same time.

> How about this (Section 11.5.2, paragraphs 5 & 6) for choice 3 above:
> 
>    RFC 2462 [ref] specifies that in normal processing for Duplicate
>    Address Detection, the node SHOULD delay sending the
>    initial Neighbor Solicitation message by a random delay between
>    0 and MAX_RTR_SOLICITATION_DELAY.  Since delaying
>    DAD can result in significant delays in configuring a new care
>    of address when the Mobile Node moves to a new link, the
>    Mobile Node preferably SHOULD NOT delay DAD when
>    configuring a new care of address. The Mobile Node SHOULD
>    delay according to the mechanisms specified in RFC 2462
>    if the Mobile IP stack cannot distinguish between the normal
>    process of moving to a new link and reinitializing the interface, or
>    if the link layer does not include adequate local collision and
>    congestion control mechanisms.

I don't see what the "distinguish" above is distinguishing between.
Is it "moving to a new link" and "reinitializing the interface"?
That doesn't make sense.
It is the potential synchronizing events we care about (at least until
we have more experimental data for real L2 behavior).

Thus it makes more sense to me to say
     The Mobile Node SHOULD
     delay according to the mechanisms specified in RFC 2462
     unless the implementation has a behavior that desynchronizes the steps
     that happen before the DAD in the case that multiple nodes experience
     handover at the same time. Such desynchronizing behaviors might be due
     to random delays in the L2 protocols or device drivers, or due to the    
     movement detection mechanism that is used.

   Erik