Re: [Mipshop] FMIPv6 Reactive Handover - HI/HAck

[Rajeev Koodli <[e-mail]>]

Hello folks,


Narayanan Vidya-CVN065 wrote:

> Hi Rajeev, Junghoon,
> 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 

They are not a MUST for use. Anyway, I will have an issue tracker for it.


> 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?

Requiring NAR to know that FBack is successful is not such a good
idea. FBack is never sent to NAR (an ASCII picture may not be able
to best illustrate the point, so please read the text).


> 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?

No, to set up AH?!
In any case, I don't see why FBU and FBAck should need to be touched.

-Rajeev



>  
> Vidya
> 
>     -----Original Message-----
>     From: Junghoon Jee [mailto:[e-mail]]
>     Sent: Monday, August 22, 2005 9:15 PM
>     To: Narayanan Vidya-CVN065; [e-mail]
>     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:[e-mail]]
>>  Sent: Tuesday, July 19, 2005 8:46 AM
>>  To: Junghoon Jee
>>  Cc: 'Syam Madanapalli'; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>
>>  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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mipshop


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