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

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 6 Jun 2001 12:58:03 -0500

Hi all,

I guess I continue my trend of asking silly question :)
I have the following questions on the MIPv6 fast handover draft.
I appreciate if I could get answers on the following questions.

Regards,
Madjid

Q1-Neighbor advertisement and L2 connectivity
It says in the draft (page 5) that the newAR will deliver packets to the mobile
when it receive indication from access network or NA from Mobile.
In page 1 it says MN sends NA or F-NA to newAR as soon as it receives L2 connectivity
trigger. Could there be a race condition where newAR can start delivering packets
 (based on L2 indication) before receiving an NA from MN? if not why is the text 
written that way?

Q2-It seems that the oldAR forwards MN's data to newAR as soon as oldAR 
receives a BU from MN or an F-BU + HACk.
 The newAR delivers the packets to the MN as soon as it receives an NA or
 F-NA from the MN (apart from Q1 above). 
This means that during this time the MN's packets must be buffered at 
newAR (whether it helps real time traffic or not, is another issue).
There was also a discussion about buffering at oldAR or at newAR, but
I think what I missed on the discussion was that
" is buffering at newAR supported or is it left to implementers,
  (Should/ MUST/ May question?)"

3- This question was asked on the list, I am not sure if I saw a convincing
answer other than comparing F-BU with BU.
The MN cannot use its newCoA as source address until it has received
F-Back from oldAR. Then how does it use newCoA as source address in F-BU?
Isn't this a chicken and egg problem? What am I missing?
Also what about ingress filtering issue at oldAR?

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 06 Jun 2001 12:13:13 -0700

answer for question 3.

it will work if the following happens.

when the MN sends a F-BU when at the oldAR, the source address
of the packet is oldCoA. the newCoA is included in the alt-CoA 
sub-option. 

answer for question 2.

Yes, buffering should be supported at the newAR. otherwise you
would be dropping packets.

vijay

---

From: Jean-Michel COMBES <[email-masked]>
Date: Fri, 08 Jun 2001 12:42:45 +0200

Hi Vijay and Alper,

> it will work if the following happens.

JMC :
I don't think so.

> of the packet is oldCoA. the newCoA is included in the alt-CoA

JMC :
What happens if  ESP is used ? Alt-CoA will be encrypted and you couldn't do filtering ...

> > Also what about ingress filtering issue at oldAR?

JMC.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Jun 2001 10:12:56 -0700

hi,

> I don't think so.

it will work.

> What happens if  ESP is used ? Alt-CoA will be encrypted and you couldn't do filtering ...

what filtering? the source address of the F-BU is the oldCoA 
and it is still attached to oldAR. so ingress filtering is fine.

the altCoA is needed only when you start processing the BU option. 
when you start processing the BU, you would have already decrypted 
the packet.

Vijay