Re: [Seamoby] DoCoMo Implementation Issues with CTP

"Raghu" <dendukuri@docomolabs-usa.com> Fri, 20 February 2004 03:21 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13969 for <seamoby-archive@odin.ietf.org>; Thu, 19 Feb 2004 22:21:12 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au1DZ-0002oE-Gz for seamoby-archive@odin.ietf.org; Thu, 19 Feb 2004 22:20:45 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K3Khou010780 for seamoby-archive@odin.ietf.org; Thu, 19 Feb 2004 22:20:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au1DT-0002nn-AI for seamoby-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 22:20:39 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13938 for <seamoby-web-archive@ietf.org>; Thu, 19 Feb 2004 22:20:35 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au1DP-0002uY-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 22:20:36 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au1CU-0002qv-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 22:19:39 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au1Br-0002o2-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 22:18:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au1Bt-0002hL-8T; Thu, 19 Feb 2004 22:19:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au1Bc-0002g8-Bo for seamoby@optimus.ietf.org; Thu, 19 Feb 2004 22:18:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13903 for <seamoby@ietf.org>; Thu, 19 Feb 2004 22:18:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au1BZ-0002mu-00 for seamoby@ietf.org; Thu, 19 Feb 2004 22:18:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au1Aj-0002jq-00 for seamoby@ietf.org; Thu, 19 Feb 2004 22:17:50 -0500
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Au19o-0002gD-00 for seamoby@ietf.org; Thu, 19 Feb 2004 22:16:52 -0500
Message-ID: <028001c3f75f$cf0aa140$1c6015ac@dcldendukuri>
From: Raghu <dendukuri@docomolabs-usa.com>
To: seamoby@ietf.org
References: <F4410B91C6CC314F9582B1A8E91DC9281BE721@ftmail2000>
Subject: Re: [Seamoby] DoCoMo Implementation Issues with CTP
Date: Thu, 19 Feb 2004 19:15:36 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Soliman Hesham" <H.Soliman@flarion.com>
To: "Raghu" <dendukuri@docomolabs-usa.com>; <seamoby@ietf.org>
Sent: Thursday, February 19, 2004 7:04 PM
Subject: RE: [Seamoby] DoCoMo Implementation Issues with CTP


> 
>  > > Well, CTAR includes MN's IP(v4,v6) addresses. So does
>  > > PCTD. So, nAR can still match the contexts. Since the token
>  > > does not include PAR's address, verification can still be
>  > > done.
>  > > 
>  > I think I didnot make my point clear.
>  > MN is claiming that it came from one pAR IP Address(IPV6),
>  > but the nAR has a PCTD that says pAR IP is different(IPv4),
>  > How can nAR verify the Token without matching the pAR IP ?
> 
> => Just out of curiosity, why do you expect the protocol
> to function in this scenario? If I understand you correctly
> the MN is moving from a v6 AR to a v4 only one. Even if 
> CT worked in this scenario, many other things will break.
> Is there a requirement for CT to work here ?
> 
MN is moving from pAR(v6 & v4) to nAR(v6 & v4).
According to Rajeev's previous mail, only one IP should be used,
either v6 or v4, for AR. In this case I was asking how the
funtionality should be with the above question.

I am expecting nothing to break in CTP when MN
moves from v6 to v4 only AR. 
Can you please provide some examples that break.


regards,
Raghu


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby