Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6

From: [email-masked]
Date: Fri, 8 Jun 2001 11:56:19 -0700

comments below.

Barani

Vijay Devarapalli <[email-masked]> on 06/08/2001 11:17:02 AM

Please respond to [email-masked]

Sent by:  Vijay Devarapalli <[email-masked]>

To:   [email-masked]
cc:    (Barani Subbiah/HQ/3Com)
Subject:  Re: [mobile-ip] questions on fast handoffs for MIPv6

[email-masked] wrote:
>
> I agree. It is also not clear on "mobile has not arrived". Has the mobile been

the newAR has not received any NA or a F_NA (as defined
in the fast handoff draft, which i assume you havent read
yet). if a link level trigger exists, the newAR hasnt
received this trigger yet. this means the mobile has
not arrived yet.

>>> There is both logical and physical way of looking whether a mobile has
arrived. Old AR can inform the new AR that a mobile has logically handed over
("arrived") so that the new AR can accept the packets before any physical
identification of the  mobile with new AR.
Do not assume too much. I see that your proposing a solution with out looking at
other possibilities or issues.

authentication is after that. you dont do authentication before
establishing a link level connection and sending a NA.

>> I was asking about how the new AR is authorised to receive the packets for
the new mobile node before mobile is physically attached. One way is that old AR
informs new AR and new AR can get an authentication for mobile from network
before it arrives. This would allow the new AR to receive the packets with out
any security problems. We are talking about buffering packets not just receive
and discard.

and the fast handoff draft is not trying to solve authentication
between the MN and the access router.

>> yes, however it should not create any holes either.

vijay

> authenticated by the new AR? If not, how the new AR can receive packets for
> un-authenticated mobile. We need to check security issues here.
>
> Barani.
>
> James Kempf <[email-masked]> on 06/07/2001 09:41:22 AM
>
> Please respond to [email-masked]
>
> Sent by:  James Kempf <[email-masked]>
>
> To:   [email-masked]
> cc:    (Barani Subbiah/HQ/3Com)
> Subject:  Re: [mobile-ip] questions on fast handoffs for MIPv6
>
> >Can you add the following text to the draft then?
> >
> >    When the newAR is receiving packets forwarded by the
> >    oldAR for the MN, and the MN hasnt shown up yet, the
> >    newAR SHOULD buffer packets. If the newAR does not
> >    buffer packets, it would the packets meant for the MN.
> >
>
> I don't think this text should be added.
>
> It is entirely unclear at this point whether buffering will work without
causing
> user-perceivable artifacts in real time streams. In fact, I know of
> at least one experiment with buffering (in IPv4) that showed it cannot be
done.
> This experiment was not definitive, of course, but I think it is
> not wise to write buffering into the standard until more is known
> about whether it will work or not.
>
> There are other alternatives to handoff smoothing, for example bicasting,
> that could handle some portion of the handoff smoothing task without
> introducing artifacts. We need to leave the standard open on this
> until there is more evidence.
>
>           jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Jun 2001 16:05:41 -0700

[email-masked] wrote:

> ("arrived") 

this is already there. this is the HI message

> so that the new AR can accept the packets before any physical

the whole discussion was about whether you should buffer such packets
which come before the MN physically attaches to the newAR. what
are you trying to say? this is what we have been discussing.

> other possibilities or issues.

?????

> any security problems. We are talking about buffering packets not just receive

here the text i sent in another mail. it should answer your question.

in the mobile controlled handoff case, its the MN which says 
i want to move to this particular AR. so here there is no 
question of authorization of the newAR to receive MN's 
packets. in the network controlled handover, its again some 
network entity which decides that this particular MN should 
be handed over to this AR. there is no question of 
authorization of the newAR in this case either.

the newAR also receives a HI from the oldAR protected by
an authentication header. the oldAR receives a HAck from
the newAR protected by an authentication header.

vijay