Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals
arno@natisbad.org (Arnaud Ebalard) Thu, 21 May 2009 22:02 UTC
Return-Path: <arno@natisbad.org>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A563A7013 for <mext@core3.amsl.com>; Thu, 21 May 2009 15:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.59
X-Spam-Level:
X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEFLFIrdZWml for <mext@core3.amsl.com>; Thu, 21 May 2009 15:02:29 -0700 (PDT)
Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 359EE3A6C1B for <mext@ietf.org>; Thu, 21 May 2009 15:00:44 -0700 (PDT)
Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <arno@natisbad.org>) id 1M7GKr-0002Ly-Hu; Fri, 22 May 2009 00:01:57 +0200
From: arno@natisbad.org
To: Vijay Devarapalli <vijay@wichorus.com>
References: <C6305549.7554%vijay@wichorus.com> <87eiusx1s6.fsf@small.ssi.corp> <2D50B653-C7B4-4FDF-93A0-D7F0AE2BEEDC@gmail.com> <87ws8cnhrg.fsf@small.ssi.corp> <4A147DD0.1030109@wichorus.com> <87octmpzs0.fsf@small.ssi.corp> <4A15BE1F.9040305@wichorus.com>
X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc
X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026
X-Hashcash: 1:20:090521:thierry.ernst@inria.fr::4HXmH+/sTp7H/CIp:0000000000000000000000000000000000000001tMB
X-Hashcash: 1:20:090521:tsirtsis@googlemail.com::EHrb82mcYD1nuFtB:000000000000000000000000000000000000000J0Q
X-Hashcash: 1:20:090521:marcelo@it.uc3m.es::Yx6Cm/aOElXwvmKo:00000000000000000000000000000000000000000000o4r
X-Hashcash: 1:20:090521:ryuji.wakikawa@gmail.com::nq15SNr3ti10BpGs:00000000000000000000000000000000000000icj
X-Hashcash: 1:20:090521:vijay@wichorus.com::VCnblBADIq7y2VTx:00000000000000000000000000000000000000000003M5w
X-Hashcash: 1:20:090521:mext@ietf.org::Av0D0yuhsJznoLWJ:00001ziy
X-Hashcash: 1:20:090521:hesham@elevatemobile.com::FUwtVSiy8BX+JK5T:00000000000000000000000000000000000009aSj
Date: Fri, 22 May 2009 00:02:32 +0200
In-Reply-To: <4A15BE1F.9040305@wichorus.com> (Vijay Devarapalli's message of "Thu, 21 May 2009 13:48:31 -0700")
Message-ID: <87vdnunmh3.fsf@small.ssi.corp>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: IETF MEXT WG ML <mext@ietf.org>
Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2009 22:02:31 -0000
Hi, Vijay Devarapalli <vijay@wichorus.com> writes: > Arnaud Ebalard wrote: > >>> Even in RFC 3775, a mobile node can clear the 'K' bit in a BU sent for >>> a binding refresh when there is no change in CoA. When the CoA >>> changes, the MN can set the 'K' bit in the BU sent to update the CoA. >> >> Rereading Section 10.3.1 of RFC 3775, the binding refresh case when >> there is no change of CoA does not exist. > > No. The mobile node would send a BU to refresh an existing binding if > the lifetime is about to expire, even if there is no change in > CoA. Maybe this is not explicitly pointed out in section > 10.3.1. Section 11.7.1 says > > Also, if the mobile node wants the services of the home agent beyond > the current registration period, the mobile node should send a new > Binding Update to it well before the expiration of this period, even > if it is not changing its primary care-of address. Sorry, I meant "the specific 'K' bit processing you describe for a refresh w/o CoA change" does not exist. The processing (including K bit one) is described for all kinds of BU, no matter if they create or refresh a binding. I obviously did not mean binding refresh is not defined. >> As usual, the content of a new >> BU basically replace the content of the previous one in the BCE. In >> section 10.3.1, the processing performed by the HA is done *only* based >> on the value of the K bit it sets *in its BA* (section 10.3.1). When the >> K bit is 0, the action is to "discard the key management connections, if >> any, to the old care-of address" (the one in the BCE). >> >> What I say is that an implementation which *strictly* follows what is in >> section 10.3.1 will just discard the key management connections to the >> old CoA. >> >> Nonetheless, I think what you describe is valid and it makes sense to >> consider that *in all cases* implementations specifically handle the >> binding refresh with no change of CoA (and not even look at K bit value >> in that specific case). > > So I am going to conclude that there is no need for any change in the > MCoA document on this issue. Right. Cheers, a+
- [MEXT] Review of draft-ietf-monami6-multiplecoa-1… Arnaud Ebalard
- Re: [MEXT] Review of draft-ietf-monami6-multiplec… Ryuji Wakikawa
- Re: [MEXT] Review of draft-ietf-monami6-multiplec… Arnaud Ebalard
- Re: [MEXT] Review of draft-ietf-monami6-multiplec… Julien Laganier
- Re: [MEXT] Review of draft-ietf-monami6-multiplec… Arnaud Ebalard
- Re: [MEXT] Review of draft-ietf-monami6-multiplec… Vijay Devarapalli
- Re: [MEXT] Review of draft-ietf-monami6-multiplec… Arnaud Ebalard
- Re: [MEXT] Review of draft-ietf-monami6-multiplec… Vijay Devarapalli
- Re: [MEXT] Review of draft-ietf-monami6-multiplec… Arnaud Ebalard