Subject: RE: [mobile-ip] FMIPv6: FBU transmission text

From: Soliman Hesham <[email-masked]>
Date: Thu, 19 Jun 2003 22:02:41 -0400

Rajeev,

 > Sorry.. Which several messages are you referring to ? In order
 > for both the scenarios (in the text I sent) to work together,
 > a message from the MN to the AR is necessary. For the
 > predictive scenario, the message is the only way to announce
 > to the AR to move the proxy ND cache entry to ND cache and
 > start forwarding. For the reactive case, the NAR establishes
 > an entry first; the address verification is trivial: don't over-write
 > an existing entry.

=> Ok perhaps I should explain a bit more, I was relying
on our previous discussions too much maybe. See Greg's 
email as well. Basically, the idea is that since address
collision is extremely unlikely, there is no need to
mandate HI/Hack, and any messages between NAR and MN. 

A simple and effective way of doing the anticipated
handover is for the MN to generate a new CoA on the old
link, send F-BU, move to the new link and send an NA
with O=0. If there is any duplication, OptDAD would
discover that. Note that there is zero changes on the
wire here. 

For the reactive case, the same happens, except that 
the MN generates the nCoA on the new link. 

Note that I'm not saying that you should remove
anything from the draft. I'm simply saying that 
there is no need to mandate the implementation of 
new messages all the time when their sole reason
for existence is something that is not likely to happen
at all. 

Note another 2 facts:
- DAD itself does not guarantee address uniqueness
- On an unreliable link layer (no L2 retransmissions), 
  it is much more likely that the DAD messages will get
  lost than address duplication taking place. 

Hesham

---

From: Greg Daley <[email-masked]>
Date: Fri, 20 Jun 2003 12:53:14 +1000

Hi Hesham,

Soliman Hesham wrote:
[most of email cut]
> - DAD itself does not guarantee address uniqueness

Come on now, you're undermining our world view here :)

>   lost than address duplication taking place. 

I think that if we're talking about optimistic DAD,
there may not be any major harm in extending the
tentative time to incorporate more retransmssions
(obviously, we wouldn't like to hammer the link though).

Maybe you've just described a valid reason for stateful
DAD/address allocation systems?

Greg

---

From: Bryan Hartwell <[email-masked]>
Date: Fri, 20 Jun 2003 11:23:50 -0400

> mandate HI/Hack, and any messages between NAR and MN.

Shouldn't the NAR be able to administratively deny a bi-directional tunnel?
Maybe it doesn't support them (for whatever reason...) eliminating HI/HACK
prevents the NAR from saying it won't detunnel oCOA.
----
I'm also curious as to whether maybe this draft should include a "MIPv4
consideration" section since a FMIPv4 draft is no longer in circulation (or
is there?).

Finally I don't remember anywhere in the draft a reference to BU. I think
the draft should at least say something like:

Once the MN has confirmed NCOA on the new link, it should perform a BU as
described in [#].

Bryan Hartwell
Ryerson University

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Jun 2003 09:19:29 -0700

> consideration" section since a FMIPv4 draft is no longer in circulation
(or

The authors of the FMIPv4 spec and the WG chairs have been in agreement for
over a year that it should go to Experimental, but for some strange and
unknown reason it keeps timing out, then being renewed by the editor, then
timing out... But it never seems to make it into the IESG queue. Granted,
nobody is particularly interested in deploying FMIPv4, but Experimental
specs aren't intended for immediate deployment.

In any event, in no case should there be any MIPv4 considerations in the
FMIPv6 spec, IMHO. It should just concern itself with MIPv6.

            jak

---

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

Hesham,

> discover that. Note that there is zero changes on the

This is simple, but I am afraid we need to look a little
deeper.

a) Since FBack was not received, MN does not know if
    FBU was processed or not. So, it has to send FBU as
   soon as it connects to NAR.
b) If FBU was processed, and NAR is proxying the NCoA,
   then NA with O=0 will not override the proxy entry.
b) MN does not know if NCoA is okay.

The text I sent addresses these. Essentially, it uses
a reformatted FNA (i.e., message 'M') with FBU as
encapsulation.

> the MN generates the nCoA on the new link.

Here, the MN definitely knows FBU was not processed.
It also knows NAR does not have a ND cache entry for
NCoA. So, it sends M with FBU as encapsulation.

> for existence is something that is not likely to happen

There are no new messages.
I am only re-using FNA, and allowing FBU to be
sent encapsulated.

-Rajeev