Subject: RE: [mobile-ip] FMIPv6 Address confusion

From: Soliman Hesham <[email-masked]>
Date: Thu, 26 Jun 2003 21:38:05 -0400

=> Your assumptions about sending ICMP unreachables
are wrong because they don't follow 2461. If you
disagree please point me to a reference that says
when the NAR sends ICMP unreachables.

 > 
 > 
 > >
 > >  >
 > >  > - I do not see how a router can create an ND cache entry,
 > >  > when there isn't one, using a 2461 unsolicited NA.
 > >
 > > => If an entry is in INCOMPLETE, because there is
 > > incoming traffic then it will create an entry based
 > > on unsolicited NAs. If there is no INCOMPLETE entry
 > >
 > 
 > From 7.2.5 again, for unsolicited NA, an existing
 > entry in INCOMPLETE state is set to STALE. This implies
 > the router would invoke NUD for reachability confirmation.

=> Ok so you agree that an entry is created, great. 
Your assumption about NUD is incorrect AFAIK.
Please read section 7.3.3. The router should continue
forwarding packet to a STALE entry. If no confirmation
appears, it will do NUD in parallel. So the traffic 
is not delayed by NUD.

 > 
 > In general, I have not seen 2461 recommending creating ND cache
 > entries in REACHABLE state for unsolicited NAs. I reckon this is
 > because reachability confirmation burden is always on the sender of
 > the packet. More knowledgeable folks please correct.

=> Yes but STALE does not mean you don't send traffic till
NUD is done. The router will continue to send traffic
to a STALE entry.

 > > then there is no traffic, so who cares.
 > >
 > 
 > Well, after the MN attaches, creating an entry at NAR saves
 > a round-trip when packets arrive.

=> Now you want to optimise ND not handovers...

 > 
 > >
 > >  > If you are using standard ND, why would traffic wait at
 > >  > NAR ? If no one answers NS, NAR sends Dest Unreachable
 > >  > isn't it ?
 > >
 > > => After several attempts. The default is something like
 > > 3 secs if memory serves me right. Check the defaults
 > > in 2461.
 > >
 > 
 > But, the packets still keep arriving. Standard 2461 recommends
 > keeping the ND buffer small.

=> Again, it's an implemnentation issue...It's
pretty easy to change this stuff! 

 > 
 > This is not just an implementation issue. Many "standard" existing
 > implementations keep the buffer to 1-2 packets.

=> The draft suggests updating the AR with
a zillion things, but it can't suggest increasing
the queue size? Changing the queue size breaks everything
doesn't it? 

 > >  >
 > >  > Second, you don't require ND queue to be larger. Only the
 > >  > FMIP buffer needs to be bigger.
 > >
 > > => In this scenario there is no FMIP buffer, only
 > > the normal ND queue.
 > >
 > 
 > It's my turn to failure (to explain). Let's say that packets
 > come to some address A for which NAR does NS. This is
 > _standard_ ND and hence has a small queue. 

=> Please stop using this small queue reason. I'm
sorry but it's rediculous that we can't suggest a 
larger queue in the router....Let's talk about
real problems.

 > >  >
 > >  > Third, NAR proxies NCoA in case some node tries
 > >  > to capture it.
 > >
 > > => OptDAD.
 > >
 > 
 > How does optDAD help if a normal node tries to grab the
 > exact address the off-link MN is trying to prospectively
 > use ?

=> Of course it doesn't but the whole assumption
is that address collision is extremely unlikely, 
but when detected, Opt DAD recovers gracefully.

Hesham

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 27 Jun 2003 10:41:20 -0700

Soliman Hesham wrote:

>  > umm.. Two things above. NAR to not do ND, and sending
>  > Dest Unreachable. The former happens when packets arrive
>  > (which we agree) and the latter happens depending on relative
>  > timing (which we may have slightly different perspectives).
>  > But, what is not correct here ?
>

Which assumption ? Did I say there won't be any
re-transmissions of NS before NAR sends unreachable ? If so,
that is incorrect.

Anyway, NAR probes NCoA for MAX_MULTICAST_SOLICIT
before giving up. Let's move on..

> => Ok so you agree that an entry is created, great.

Just to be clear: if there is an existing entry in INCOMPLETE
state, the router moves it to STALE. If there is no entry, for
instance because PAR has not processed FBU, unsolicited NA
does not create an entry.

> appears, it will do NUD in parallel. So the traffic

This is a good point.
However, you would still have another round-trip
because of NUD, although that does not stop traffic.

> NUD is done. The router will continue to send traffic

Agreed.

> => Now you want to optimise ND not handovers...

FMIP goal is to enable a MN to send packets as soon as
new link is available and to enable it to receive packets
as soon as NAR detects its presence. So, creating an entry
asap is important.

> the queue size? Changing the queue size breaks everything

FMIP does suggest to buffer packets, but Not by
expanding the ND queue.

> larger queue in the router....Let's talk about

Why is this not a real problem ? You didn't answer
my question. Why should a generic ND queue be made
larger for _all_ incoming packets because there are
handovers ? Do you disagree that ND queues at routers
are small ? If not, how would you selectively increase the
ND queue for handovers ?  FMIP does not
require generic ND queue to be made larger, and I don't
see why that should change.

-Rajeev

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Mon, 30 Jun 2003 10:41:13 +1000

On 2003-06-27, Youn-Hee Han wrote:
> Hesham wrote:
> No. the current optiDAD cannot recovers the address collision.

Please explain the details of the situation which isn't recovered
correctly -- there are some exceedingly rare situations I've already
identified in the draft, but I'm always happy to document any 
further shortcomings.

Okay, here's something for you to consider:

Unmodifed DAD may also fail, as NSes and NAs may be lost in
transit, causing a collision to go undetected.

The probability of such packet loss is much higher than the
probability of the kind of problematic Optimisitic DAD 
behaviour you are talking about.

> As I mentioned in previous mail, I don't like to tell...
>   "FMIPv6 should only be used where the probability of collision is
>    exceedingly low."

Why not?  RNG isn't rocket science any more ...

-----Nick

---

From: "Youn-Hee Han" <[email-masked]>
Date: Mon, 30 Jun 2003 11:38:26 +0900

Hello Nick!

Please see inline comments.

> identified in the draft, but I'm always happy to document any 

I already explained the situation in a previous mail, 
and some people' opinion seem to be in accord with mine.
I also agree that there are some exceedingly rare address 
collisons. But, that is only possible with additional assumption.
(e.g. "*all* of hosts involved in a protocol SHOULD use 
a strong RNG")

> behaviour you are talking about.

I agree with you. However, without aforementioned additional
assumption, we also should concern the collision case, even in 
the environment where the probability of such packet loss is 
extremely low.

> Why not?  RNG isn't rocket science any more ...

Although strong RNG is not difficult technology, how can we have 
a firm belief that *all* of hosts involved in a protocol (e.g., FMIPv6)
will use a strong RNG?

Regards,
Youn-Hee

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Mon, 30 Jun 2003 13:00:46 +1000

> (e.g. "*all* of hosts involved in a protocol SHOULD use 

No.  Imagine that, for some bizarre reason, 1000 nodes
are on the network each of which has a broken PRNG which 
has led them to grab addresses ::1, ::2, ::3 .. ::3E8.

There is still a 1000/2^62 chance that our strongly random
generate address will have a collision with one of these
nodes.  Just as there is if they had all chosen strongly
random addresses.

draft-soto-mobileip-random-iids-00.txt, now expired
but available from
<http://www.watersprings.org/pub/id/draft-soto-mobileip-random-iids-00.txt>
includes the following illuminating example:

| [ P(2^62,5000)=< 5.4 e-12 ]
|
| For instance, according to Table 1.1 of [6], the probability of being
| killed by a lightning (per day) is about 1.1 e-10.  Then, a mobile
| phone user should be more worried about being killed by a
| lightning than to have an interface identifier repeated.

But, even assuming we're worrying about collisions:

An undetected collision due to DAD packet loss will cause
an ongoing problem which will continue until one of the
colliding nodes relinquish their addresses ... collision
detection has failed and they will both answer NSes,
causing a lot of confusion to ND.  

The kind of temporary clash which may be caused by misplaced
optimism may cause a TCP RESET, but at least the collision
will be detected and higher-layer protocols can retry.
In fact, use of Optimistic DAD can potentially make DAD 
_safer_, as an address can remain Tentative longer, and
send more detection NSes, as a result of the reduced 
penalty for Tentativeness.

Frankly, Optimistic DAD errs on the side of caution.

-----Nick