RE: [Seamoby] DoCoMo Implementation Issues with CTP

"Soliman Hesham" <H.Soliman@flarion.com> Fri, 20 February 2004 03:09 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 WAA13540 for <seamoby-archive@odin.ietf.org>; Thu, 19 Feb 2004 22:09:08 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au11t-0002MM-M3 for seamoby-archive@odin.ietf.org; Thu, 19 Feb 2004 22:08:41 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K38fU2009064 for seamoby-archive@odin.ietf.org; Thu, 19 Feb 2004 22:08:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au11t-0002M7-GX for seamoby-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 22:08:41 -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 WAA13509 for <seamoby-web-archive@ietf.org>; Thu, 19 Feb 2004 22:08:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au11q-00029y-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 22:08:38 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au10v-00025J-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 22:07:41 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au10E-00021s-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 22:06:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au10H-0001r8-5p; Thu, 19 Feb 2004 22:07:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0zt-0001qZ-RF for seamoby@optimus.ietf.org; Thu, 19 Feb 2004 22:06:37 -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 WAA13445 for <seamoby@ietf.org>; Thu, 19 Feb 2004 22:06:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au0zq-00020S-00 for seamoby@ietf.org; Thu, 19 Feb 2004 22:06:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au0ys-0001xc-00 for seamoby@ietf.org; Thu, 19 Feb 2004 22:05:35 -0500
Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Au0xz-0001sb-00 for seamoby@ietf.org; Thu, 19 Feb 2004 22:04:39 -0500
content-class: urn:content-classes:message
Subject: RE: [Seamoby] DoCoMo Implementation Issues with CTP
Date: Thu, 19 Feb 2004 22:04:09 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <F4410B91C6CC314F9582B1A8E91DC9281BE721@ftmail2000>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Thread-Topic: [Seamoby] DoCoMo Implementation Issues with CTP
Thread-Index: AcP3XY7EKJeQk8NGSJeSkeJOIQx35QAAJfOg
From: Soliman Hesham <H.Soliman@flarion.com>
To: Raghu <dendukuri@docomolabs-usa.com>, seamoby@ietf.org
Content-Transfer-Encoding: quoted-printable
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=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

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

Hesham

 > 
 > > >
 > > > > Is the confusion in whether `V' bits also refer to
 > > > > PAR and NAR addresses ? If so, we should clarify that they
 > > > > refer to MN's IP addresses only, and that the router address
 > > > > must be either IPv4 or IPv6 but not both.
 > > > >
 > > > This description in the draft may clarify things, but how to
 > > > identify the IP version AR in CT messages.
 > > > I guess another V flag for AR might simply things.
 > > >
 > > 
 > > Perhaps this is not necessary. (See above)
 > >
 > I mean,
 > In CTAR Message there is pAR IP,
 > how can nAR know that there is IPv4 or IPv6 address of pAR,
 > if the V flag is only for MN IP version.
 > 
 > 
 > regards,
 > Raghu 
 > 
 > _______________________________________________
 > Seamoby mailing list
 > Seamoby@ietf.org
 > https://www1.ietf.org/mailman/listinfo/seamoby
 > 

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