Subject: RE: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 13 Nov 2002 23:30:47 +0100

> > => Hmm. It seems that this is not a functional distinction
  > > but one that is based on "likely" use cases. I was
  > > concerned with the functional difference and to me
  > > there is none.
  > >
  > 
  > I guess you've lost me there. The function of an AR is to 
  > provide last hop
  > routing service for a wireless link and associated mobile 
  > nodes that are using
  > the link. If an HA can optionally not have any wireless 
  > access points and thus
  > not perform last hop routing service for a wireless link, 
  > then how can there not
  > be a functional distinction?

=> The functions you are talking aout have nothing
to do with mobility. _when_ mobility is invoked, the 
AR will need a "HA function" to be able to handle it.
Of course the AR has more functions than mobility, like
access control ...etc, but that is a different comparison.
You are comparing boxes, I'm saying that within that box
the mobility functions are identical to that of a HA.

  > 
  > >   > They are not designed to change routing unless the address
  > >   > actually does change.
  > >   > What is happening is that the link suddenly goes away and
  > >   > the host appears on
  > >   > another one.
  > >
  > > => Well, the address should change in this case.
  > >
  > 
  > It can't change until RO is complete. And the time required 
  > for that depends on
  > many factors. The FMIP protocol can't assume it will.

=> RO is not relevant here because you can have a tunnel
from the AR (HA? :) ) to the new CoA while the MN
does RR and sends BUs ...etc what's the problem?
The only reason for keeping the old CoA is to avoid
problems of address duplication. IMO this is not needed.

  > > => It shouldn't be used, why? Because of all
  > > the complexity involved in the current FMIPv6
  > > draft. All this complexity is done to avoid address
  > > duplication. To me, this is an overkill, but I'm not
  > > going to try to remove it from the draft, I just
  > > think HI/HACK should be optional (for the case
  > > where the tunnel is generated based on L2 triggers
  > > only).
  > >
  > 
  > The tunnel is there because it takes a finite amount of 
  > time for the RO to
  > complete and until that happens, the new CoA won't work. 
  > The packets routed by
  > the CN to the old AR will get dropped.

=> See above.

  > But why add extra complexity when the design can leverage 
  > off an existing
  > security mechanism (with key distribution planned)? Reuse 
  > seems like a big win,
  > especially when it comes to security protocols.

=> You're not suggesting reuse though, I am (e.g. IKE, RR, 
CGAs ....). You're suggesting we eliminate the BU. I don't
see what gain you are showing with the new alternative. You
still need an SA between a MN and a random AR,call the message
whatever you want to call it. The SA will _require_ proof
of address ownership. 

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Nov 2002 14:49:10 -0800

> the mobility functions are identical to that of a HA.

The functions are not identical. There are one set of functions that deal with
changes in link connectivity and another that deal with mobility.

Up until now, the change in link connectivity functions have been implemented
using ICMP Redirect, but this case is one in which I believe some changes in
signaling are needed because it is the host (in 802.11), and not the router,
that is detecting the change. ICMP Redirect is primarily designed for routers.

The functions that deal with mobility involve changing the node identifier to
routing identifier binding, regardless of whether link connectivity has changed.
For example, a MIPv6 MN could decide to change its CoA to implement address
privacy while still on the same link.

The AR deals with changes in link connectivity, the HA with mobility.

We seem to have a pretty fundamental architectural disagreement here, and I
frankly don't see much evidence that we'll converge on a common understanding.

> whatever you want to call it. The SA will _require_ proof

I'm suggesting that we define the case of the MN detecting a link failure and
requesting a tunnel to the PCoA as a new case in the link failure functions,
that the signaling be a reuse of ND  by extending it, and that we reuse security
as defined in RFC 2461 and with whatever key distribution SEND comes up with.

The benefit is that we maintain a clean architectural distinction between link
failure/fixup and rebinding of the routing identifier to node identifier.

            jak