Subject: RE: [Mipshop] FMIPv6 Reactive Handover - HI/HAck

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Mon, 22 Aug 2005 23:18:43 -0500

Hi Subba Reddy,
 
Actually, that is where I was going with this. It seems like HI/HAck is not really a MUST for reactive handover. The FBU from the MN will be authenticated by the PAR. As long as the NAR knows that the FBAck was successful, isn't that all that is needed for tunnel state creation/enablement? 
 
--> As per my understanding, FBack is sent to MN's NCoA (sec 6.3.2). But in the figure, it is showing to NAR.  
 
------> It does seem that the FBAck is sent to the NCoA (as per the IP destination value in 6.3.2, although this doesn't make much sense if it is sent on the old link itself, as in the predictive handoff case). Nevertheless, we could take advantage of the fact that it is going through the NAR for sure in the case of reactive handovers. 
 
Vidya

Thanks & Regards,
Subba Reddy

Again, CT is a different story - so, I'm not referring to that. 
 
I think the text can be made clearer in the protocol description to alleviate ambiguity. But, regardless, why is there a need to mandate these messages for reactive mode? 
 
I can see the need for a message exchange with the AH between the ARs - but, seems to me like the FBU/FBAck can be extended to carry that - no? 
 
Vidya

-----Original Message-----
From: Junghoon Jee [mailto:[email-masked]] 
Sent: Monday, August 22, 2005 9:15 PM
To: Narayanan Vidya-CVN065; [email-masked]
Subject: RE: [Mipshop] FMIPv6 Reactive Handover - HI/HAck 

Hi Vidya,
I made the same question through DNA WG recently regarding FMIP-DNA I-D.
 
You can find the previous discussion through the attached message.
 
I am still questioning why HI/HAck for the access control is required after MN has already attached to NAR in the reactive case.
 
Junghoon
 
> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]] 
> Sent: Tuesday, July 19, 2005 8:46 AM
> To: Junghoon Jee
> Cc: 'Syam Madanapalli'; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
> Subject: Re: [DNA] draft-koodli-dna-fmip-00.txt
> 
> 
> 
> 
> Junghoon Jee wrote:
> 
> > Rajeev,
> >  
> > 
> >>For both predictive and reactive modes, HI/HAck can be useful for 
> >>access control. NAR can forward packets for the MN without forcing 
> >>access control, through HI/HAck.
> > 
> 
> One could use HI/HAck for CT, but I am not referring to that.
> 
> When FBU processing is successful, PAR's message (HI) to NAR 
> can allow NAR to "validate" the ND cache entry for NCoA.
> No Context Transfer is involved. The fields in HI (PCoA, NCoA,
> LLA) are sufficient for the purpose.
> 
> -Rajeev
> 
> 
> 
> 
> 
> > 
> > Are you saying about context transfer by HI/HAck ?
> > 
> > Regards,
> > Junghoon
> > 
> > 
> >>(If it is not clear, FMIP-DNA is applicable when DNA+oDAD is 
> >>available,
> >>  and no neighborhood information is available for FMIP)
> >>
> >>-Rajeev
> >>
> >>
> >>
> >>Syam Madanapalli wrote:
> >>
> >>
> >>>Hello Junghoon,
> >>>
> >>>Thanks for reviewing the draft.
> >>>
> >>>
> >>>>Hi Syam,
> >>>>It's an interesting work.
> >>>>After reviewing this I-D, I've come up with a following question.
> >>>>
> >>>>About the role of HI/HACK in this reactive FMIPv6-DNA :
> >>>>I thought that these messages are required to confirm the MN's 
> >>>>prospective NCoA in predictive mode.
> >>>>In the FMIPv6-DNA, MN configures the NCoA by optimistic 
> DAD in the 
> >>>>reactive mode, so why do those messages needed to be
> >>
> >>transferred and
> >>
> >>>>what's their roles ?
> >>>>Just to prepare for future optional behavior the same as
> >>
> >>specified in
> >>
> >>>>the draft-ietf-mipshop-fast-mipv6-03 ?
> >>>>I guess that my question may also apply to the reactive mode of 
> >>>>draft-ietf-mipshop-fast-mipv6-03.
> >>>
> >>>
> >>>As you mentioned, currently there is no new use of HI/HACK
> >>
> >>other than
> >>
> >>>what is mentioned in FMIPv6 RFC.  That is, NAR can make use of the 
> >>>knowledge that its trusted peer (i.e., PAR) has a trust
> >>
> >>relationship
> >>
> >>>with the
> >>>MN.
> >>>
> >>>
> >>>
> >>>>Regards,
> >>>>Junghoon
> >>>>
> >>>
> > 
> 

  _____  

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Subba Reddy <[email-masked]>
Date: Tue, 23 Aug 2005 10:21:26 +0530

MessageHi Vidya,

    ------> It does seem that the FBAck is sent to the NCoA (as per the IP destination value in 6.3.2, although this doesn't make much sense if it is sent on the old link itself, as in the predictive handoff case). 

    --> In the predictive case, I feel sending FBack to old link may be better. 

    As per the spec sending FBack to old link is optional. 
    But, if MN does not receive FBack after retries, it must assume that fast handover is not available.
    I think, this is bit ambiguous.
    Sec 4 (page 13, last but one para)

    "...
    The PAR MAY send the
       FBack to the previous link to facilitate faster reception in the
       event that the MN is still present.  The result of the FBU and FBack
       processing is that PAR begins tunneling the MN's packets to NCoA.  If
       the MN does not receive an FBack message even after retransmitting
       the FBU for FBU_RETRIES, it must assume that fast handover support is
       not available and stop the protocol operation."

    Nevertheless, we could take advantage of the fact that it is going through the NAR for sure in the case of reactive handovers. 

    --> I think, if FBack is secured, NAR may not be able to process FBack.

    Thanks & Regards,
    Subba Reddy

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Aug 2005 09:15:37 -0700

MessageVidya,

If it is routed through the NAR rather than sent to it, the NAR can't insert any inter-router authentication. The FBU is strictly between the MN and PAR, modulo any Routing Headers or such that are added.

I think you are right that HI/HAck are not needed on reactive handover. The MN will have done oDAD on the new link (and DHCP if stateful) prior to the tunneled packets showing up on NAR, and so the MN will be in a position to answer the NAR's NS with a definitive NA (if the oDAD completed successfully) having an SLLAO. Thus, no need for HI/HAck to confirm the address.

It could be used for other reasons, like CT for example, but that's independent of its function in FMIP.

            jak

----- Original Message ----- 
  From: Narayanan Vidya-CVN065 
  To: 'Subba Reddy' ; 'Junghoon Jee' ; [email-masked] 
  Sent: Monday, August 22, 2005 9:18 PM
  Subject: RE: [Mipshop] FMIPv6 Reactive Handover - HI/HAck

    Hi Subba Reddy,

    Vidya

    Thanks & Regards,
    Subba Reddy

      Vidya
        -----Original Message-----
        From: Junghoon Jee [mailto:[email-masked]] 
        Sent: Monday, August 22, 2005 9:15 PM
        To: Narayanan Vidya-CVN065; [email-masked]
        Subject: RE: [Mipshop] FMIPv6 Reactive Handover - HI/HAck 

        Hi Vidya,

        Junghoon

        > Cc: 'Syam Madanapalli'; [email-masked]; [email-masked]

--------------------------------------------------------------------------

------------------------------------------------------------------------------

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Aug 2005 10:41:14 -0700

>     But in the figure, it is showing to NAR.  

Actually, the Figure only shows FBack being sent _towards_ NAR. The 
point being it is forwarded, just as any other packet, once NAR
detects MN's attachment. NAR does not know, and it must not be required 
to, which packet contains FBack.

>     ------> It does seem that the FBAck is sent to the NCoA (as per the
>     IP destination value in 6.3.2, although this doesn't make much sense
>     if it is sent on the old link itself, as in the predictive handoff

You have to go back to archives for this sort of thing :-)
(Briefly, the MN is not required to stay on the old link after
sending FBU. Hence FBack is always sent to NCoA. But if it happens
to be hanging around on the previous link, it can still receive one
if PAR sends it on the previous link)

-Rajeev

>     case). Nevertheless, we could take advantage of the fact that it is
>     going through the NAR for sure in the case of reactive handovers.
>      
>     Vidya
>      
>      
>     Thanks & Regards,
>     Subba Reddy
> 
>          
>         I think the text can be made clearer in the protocol description
>         to alleviate ambiguity. But, regardless, why is there a need to
>         mandate these messages for reactive mode?
>          
>         I can see the need for a message exchange with the AH between
>         the ARs - but, seems to me like the FBU/FBAck can be extended to
>         carry that - no?
>          
>         Vidya
> 
>             I am still questioning why HI/HAck for the access control is
>             required after MN has already attached to NAR in the
>             reactive case.
>              
>             Junghoon
>              
>>  Cc: 'Syam Madanapalli'; [email-masked]
>             <mailto:[email-masked]>; [email-masked]
>             <mailto:[email-masked]>
>         ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
>