Subject: RE: [mobile-ip] FMIPv6 protocol changes

From: Soliman Hesham <[email-masked]>
Date: Mon, 16 Jun 2003 22:53:32 -0400

> - clarify FBU transmission from the new link.
 > Specifically, it would be useful to have FBU
 > sent with NCoA as source IP address so that
 > issues surrounding ingress filtering etc could
 > be avoided to begin with. And, packet
 > forwarding could ensue for topologically
 > consistent address for packets tunneled from
 > the previous router.

=> Agreed. Optimistic DAD is our friend!

 > 
 > - role of Three Party Handover. It would be
 > better to keep the scope of the draft to simple
 > scenarios and fall back to base Mobile IP during
 > error cases. I am proposing that Section 4.6, which
 > specifies TPH using L2 signaling, be deprecated.
 > This text might be useful in a separate document
 > that _could_ specify further optimizations to
 > FMIPv6, if such thing is seen as useful in the future.

=> Agreed.

 > 
 > - role of L2-optimized handover, i.e., Section 4.5.
 > It has always been an issue to address L2-L3 interaction
 > to improve performance. What if we focus (back!) merely on
 > IP protocol specification and leave the "vertical integration"
 > out, perhaps to some other time and place ? I think this
 > would impart substantial simplification to the protocol
 > behavior. At the same time, some illustrative text on
 > L2 triggers causing protocol invocation would be needed.
 > Any takers ?

=> No cycles here, but I'm supportive ;)

 > 
 > - text specifying securing FBU. Multiple mechanisms
 > could be used to establish security association between
 > the MN and its AR. I heard Anonymous DH (from Erik)
 > during last IETF. Perhaps we should specify that, along
 > with its short-comings, for the case when nothing else is
 > available ? Please note I am not suggesting we solicit
 > proposals to solve this issue; we have concluded that
 > discussion.

=> What was the conclusion? I don't recall any. I only
recall suggestions. 

Hesham

 > Comments ?
 > -Rajeev

---

From: Alper Yegin <[email-masked]>
Date: Mon, 16 Jun 2003 20:22:37 -0700

> => Agreed. Optimistic DAD is our friend!

Rajeev, do you mean optDAD here, or simply (blindly) transmitting the BU
with a newCoA?

>> FMIPv6, if such thing is seen as useful in the future.

Ditto.

> => No cycles here, but I'm supportive ;)

I presume this does not mean that we'll remove L2 triggers from the spec
completely. 

>> available ? 

One can define an EAP-DH method (if not done already) and carry it over PANA
to create the SA between MN and AR. This SA can be used when the MN moves
off-link.

>> Please note I am not suggesting we solicit

Alper

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 17 Jun 2003 15:21:34 +0900

> => Agreed. Optimistic DAD is our friend!

Current FMIPv6 description devotes most parts to the NCoA confirmation.
AFAIK, the confirmation includes normal DAD process. If optiDAD were
a friend of FMIPv6, MN itself could create and use its address without the 
complex confirmation protocol, whenever it attaches new link, cann't it?

- Youn-Hee

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 17 Jun 2003 11:57:11 -0700

> => What was the conclusion? I don't recall any. I only

During SF IETF meeting, we had a discussion. The
conclusion of that was to move the draft assuming
some mechanism is available, instead of having to
devise our own. In the same context, Anonymous
DH was mentioned as well as a possible candidate.

So, I am proposing we specify text on how FMIPv6
could use the mechanism(s), and/or specify ADH
as a default.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 17 Jun 2003 12:02:43 -0700

> Rajeev, do you mean optDAD here, or simply (blindly) transmitting the BU

I am not implying optDAD nor am I implying
simply transmitting FBU. I will provide some
text.

> I presume this does not mean that we'll remove L2 triggers from the spec

No, we will only have some illustrative text.

> to create the SA between MN and AR. This SA can be used when the MN moves

PANA is a candidate. There could be others. For FMIPv6,
we need to reference them but focus on how the SA could
be used to secure FBU. Admittedly, there will be protocol
nits that determine their respective suitability.

-Rajeev

---

From: "Bryan Hartwell" <[email-masked]>
Date: Wed, 18 Jun 2003 15:59:27 -0400

> No, we will only have some illustrative text.

Correct me if I'm wrong, but because of 802.11 the MN will receive RAs from
only one AR...so a proactive handoff (from MN) in this environment can only
be instigated by L2 triggers.
Naturally  FMIP should support network initiated handoffs, but if that's the
only focus then this is a draft about MN/traffic management and not smooth
handoffs. And a reactive "fast handover" is not smooth... it's just damage
control.

At the minium, I think section 4.5 should stay in the draft untouched. i
know there isn't any existing support for this on the L2 side but, as your
draft says, if it's not L2 sourced then it's just policy-based. Then the
draft no longer covers the physical movement between coverage areas - the
whole point of MIP in the first place. That's just my 2 cents worth.

Cheers,
Bryan