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

Subba Reddy <subbareddy@samsung.com> Tue, 23 August 2005 03:52 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7PqG-0001wA-TF; Mon, 22 Aug 2005 23:52:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7PqF-0001w4-CO for mipshop@megatron.ietf.org; Mon, 22 Aug 2005 23:52:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27805 for <mipshop@ietf.org>; Mon, 22 Aug 2005 23:52:47 -0400 (EDT)
Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7PqG-0005pR-FE for mipshop@ietf.org; Mon, 22 Aug 2005 23:52:53 -0400
Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ILN00FD8PFNYF@mailout1.samsung.com> for mipshop@ietf.org; Tue, 23 Aug 2005 12:52:35 +0900 (KST)
Received: from subbareddy ([107.108.71.57]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0ILN004EFPFA1P@mmp2.samsung.com> for mipshop@ietf.org; Tue, 23 Aug 2005 12:52:35 +0900 (KST)
Date: Tue, 23 Aug 2005 09:17:40 +0530
From: Subba Reddy <subbareddy@samsung.com>
Subject: Re: [Mipshop] FMIPv6 Reactive Handover - HI/HAck
To: Narayanan Vidya-CVN065 <vidya@motorola.com>, 'Junghoon Jee' <jhjee@etri.re.kr>, mipshop@ietf.org
Message-id: <00bf01c5a795$6b0ae910$39476c6b@sisodomain.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-Priority: 3
X-MSMail-priority: Normal
References: <1B631E11D496D711BB2800065BFCB6A11B7A7324@il02exm13>
X-Spam-Score: 1.1 (+)
X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472
Cc:
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mipshop.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1867212860=="
Sender: mipshop-bounces@ietf.org
Errors-To: mipshop-bounces@ietf.org

MessageHi Vidya,

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. 

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:jhjee@etri.re.kr] 
    Sent: Monday, August 22, 2005 9:15 PM
    To: Narayanan Vidya-CVN065; mipshop@ietf.org
    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:rajeev@iprg.nokia.com] 
    > Sent: Tuesday, July 19, 2005 8:46 AM
    > To: Junghoon Jee
    > Cc: 'Syam Madanapalli'; dna@eng.monash.edu.au; smadanapalli@gmail.com
    > 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
  Mipshop@ietf.org
  https://www1.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop