Subject: [Mip4] Pre-Registration Request routing issue in Low Latency Handoffs in Mobile IPv4 Draft --

From: "Chugtu Manish-a22653" <[email-masked]>
Date: Tue, 6 Mar 2007 22:12:09 +0800

Hi Karim, 
 
This is regarding the method of handling Pre-Registration request by oFA
in the Low Latency Handoffs in Mobile IPv4
<http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-hand
offs-v4-11.txt>  Internet Draft. According to me, the way it is handled
by the draft might have a problem as follows: 
 
Pre-Registration according to draft should be treated as normal IP
packet which has to be routed to the nFA by oFA. But since the MN is
already registered to oFA and lets say we have Reverse Tunneling enabled
on oFA, any packet with the source address as Home Address of MN would
be tunneled to HA including the Pre-registration packet, which is not
what we want. 
 
Also, in this case if somehow we route the Pre-Reg packet to the nFa
by-passing reverse tunneling (by defining some routing policies or may
be by coding it in such way) , it still may not be a good idea, since
one of the main reason for reverse tunneling is to avoid packet drops
for topologically in-correct source address.
 
So we would have to define a specific way to handle Pre-Reg packets in
reverse tunneling case eg: Might need to tunnel it to the nFA. Please
let me know your inputs and also in case I am missing something here. In
case you agree to the problem, do you think we might need a revision to
the draft which states and addresses the above mentioned problem
 
Best Regards
Manish Chugtu 
-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Chugtu Manish-a22653" <[email-masked]>
Date: Mon, 12 Mar 2007 15:25:59 +0800

Hi Karim, 

That's exactly what I am referring to. We do need something like a
secure interface between oFa-nFa for the Registration Request destined
to nFA. This will reduce the delay, that exists due to it going to the
HA twice (in case of Reverse Tunneling), which could be crucial in a
faster handoff process.

Will be looking forward to the list of issues that you are taking up.

Thanks and Best Regards
Manish Chugtu

-----Original Message-----
From: Karim El Malki [mailto:[email-masked]] 
Sent: Sunday, March 11, 2007 10:36 PM
To: Chugtu Manish-a22653
Cc: [email-masked]
Subject: Re: Pre-Registration Request routing issue in Low Latency
Handoffs in Mobile IPv4 Draft --

Hi Manish,
If I understand the problem correctly, you're saying that it would take
longer for the Registration Req to reach nFA in the case of reverse
tunnelling since it would have to traverse the HA twice. This may or may
not delay the actual handoff depending on the anticipation time and the
FA-HA delay. Typically the wireless leg and handoff time tend to
compensate for additional fixed delays so there would not be a problem.
However there may be a case where the overall handoff time is impacted
(do you have any practical case?) thus we could introduce shorter path
routing for the reverse tunnelling case. The oFA has knowledge of its
nFA neighbour addresses and could further filter incoming packets (RR?)
destined to the nFA routing them through the secure oFA-nFA interface.
That would be compatible with reverse tunnelling and the packets
wouldn't be dropped by source address filters.
There's a couple of issues, possibily including this one, that I'd like
to take up in a revision of the draft following RFC publication (in RFC
Ed queue). I'll put forward a list.
Regards,
Karim

Chugtu Manish-a22653 wrote:
> Hi Karim,
>  
> This is regarding the method of handling Pre-Registration request by 
> oFA in the /Low Latency Handoffs in Mobile IPv4 / 
> <http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-ha
> ndoffs-v4-11.txt>/ Internet Draft./ According to me, the way it is 
> handled by the draft might have a problem as follows:
>  
> Pre-Registration according to draft should be treated as *normal IP 
> packet which has to be routed **to the nFA by oFA*. But since the MN 
> is already registered to oFA and lets say we have Reverse Tunneling 
> enabled on oFA, any packet with the source address as Home Address of 
> MN would be tunneled to HA including the Pre-registration packet, 
> which is not what we want.
>  

> let me know your inputs and also in case I am missing something here. 
> In case you agree to the problem, do you think we might need a 
> revision to the draft which states and addresses the above mentioned 
> problem
>  
> Best Regards
> Manish Chugtu

---

From: Karim El Malki <[email-masked]>
Date: Sun, 11 Mar 2007 18:06:19 +0100

Hi Manish,
If I understand the problem correctly, you're saying that
it would take longer for the Registration Req to reach nFA
in the case of reverse tunnelling since it would have to
traverse the HA twice. This may or may not delay the
actual handoff depending on the anticipation time and the FA-HA
delay. Typically the wireless leg and handoff time tend to
compensate for additional fixed delays so there would not be
a problem. However there may be a case where the overall handoff
time is impacted (do you have any practical case?) thus we
could introduce shorter path routing for the reverse
tunnelling case. The oFA has knowledge of its nFA neighbour
addresses and could further filter incoming packets (RR?)
destined to the nFA routing them through the secure oFA-nFA
interface. That would be compatible with reverse tunnelling
and the packets wouldn't be dropped by source address filters.
There's a couple of issues, possibily including this one, that
I'd like to take up in a revision of the draft following RFC
publication (in RFC Ed queue). I'll put forward a list.
Regards,
Karim

Chugtu Manish-a22653 wrote:
> in the /Low Latency Handoffs in Mobile IPv4 /
> <http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt>/ Internet
> Draft./ According to me, the way it is handled by the draft might have a
> problem as follows:
>  
> packet which has to be routed **to the nFA by oFA*. But since the MN is