Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals

Vijay Devarapalli <vijay@wichorus.com> Thu, 21 May 2009 20:47 UTC

Return-Path: <vijay@wichorus.com>
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 C8FB93A6ABF for <mext@core3.amsl.com>; Thu, 21 May 2009 13:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.676
X-Spam-Level:
X-Spam-Status: No, score=0.676 tagged_above=-999 required=5 tests=[AWL=3.275, BAYES_00=-2.599]
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 1AEjWVdM1aTs for <mext@core3.amsl.com>; Thu, 21 May 2009 13:47:28 -0700 (PDT)
Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id CCA7B3A6A72 for <mext@ietf.org>; Thu, 21 May 2009 13:47:27 -0700 (PDT)
Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA06.westchester.pa.mail.comcast.net with comcast id uCFl1b00Z0EZKEL56Lp6A2; Thu, 21 May 2009 20:49:06 +0000
Received: from [10.166.254.150] ([38.96.10.141]) by OMTA01.westchester.pa.mail.comcast.net with comcast id uLoM1b00V32awWW3MLoWlG; Thu, 21 May 2009 20:48:49 +0000
Message-ID: <4A15BE1F.9040305@wichorus.com>
Date: Thu, 21 May 2009 13:48:31 -0700
From: Vijay Devarapalli <vijay@wichorus.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Arnaud Ebalard <arno@natisbad.org>
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>
In-Reply-To: <87octmpzs0.fsf@small.ssi.corp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 20:47:28 -0000

Hi Arnaud,

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.

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

> Thanks for your thoughts,

No problem. Your detailed reviews are always welcome.

Vijay