Re: [MEXT] IPv4 home address option in DSMIP

Shi Xiaoyan <shi_xyan@huawei.com> Tue, 20 January 2009 10:06 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: monami6-archive@megatron.ietf.org
Delivered-To: ietfarch-monami6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87BD3A6A36; Tue, 20 Jan 2009 02:06:19 -0800 (PST)
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 0B0E83A6A11 for <mext@core3.amsl.com>; Tue, 20 Jan 2009 02:06:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.355
X-Spam-Level:
X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=1.245, 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 6wj9XYCdi7eV for <mext@core3.amsl.com>; Tue, 20 Jan 2009 02:06:16 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6E7243A67A7 for <mext@ietf.org>; Tue, 20 Jan 2009 02:06:16 -0800 (PST)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDR00DLKLDY8E@szxga01-in.huawei.com> for mext@ietf.org; Tue, 20 Jan 2009 18:05:58 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDR00KYVLDYC4@szxga01-in.huawei.com> for mext@ietf.org; Tue, 20 Jan 2009 18:05:58 +0800 (CST)
Received: from s68128b ([10.111.148.189]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDR006TXLDW6H@szxml04-in.huawei.com> for mext@ietf.org; Tue, 20 Jan 2009 18:05:58 +0800 (CST)
Date: Tue, 20 Jan 2009 18:05:56 +0800
From: Shi Xiaoyan <shi_xyan@huawei.com>
In-reply-to: <C59AB74C.B237%hesham@elevatemobile.com>
To: 'Hesham Soliman' <hesham@elevatemobile.com>
Message-id: <010801c97ae6$b0affc80$bd946f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Thread-index: Acl4e/1gnce/8wg+TyC7IjHZuRMuKQANY/OkAEesPfAAF25TZwArr7WQ
Cc: mext@ietf.org
Subject: Re: [MEXT] IPv4 home address option in DSMIP
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org


> -----Original Message-----
> From: Hesham Soliman [mailto:hesham@elevatemobile.com] 
> Sent: Monday, January 19, 2009 8:04 PM
> To: Shi Xiaoyan
> Cc: mext@ietf.org
> Subject: Re: IPv4 home address option in DSMIP

> > 1. BU without IPv4 home address option works well for extending 
> > lifetime. I can't understand what you said "how a BU 
> works". Is there 
> > any Specification to require that BU for exending lifetime  must be 
> > consistent with BU for first register? Is there any special 
> effect? In 
> > fact, with more and more extension for BU in future, the 
> requirement 
> > that BU for exending lifetime must be consistent with BU 
> for first register will cause unnecessary load.
> 
> => Yes I know that will use more bandwidth but I don't 
> understand what you're objecting to. Implementations copy the 
> contents of the new BU into the BC to replace the old entry, 
> as specified in 3775. So a new BU overwrites the old one 
> unless you desgin a new option per extension that tells the 
> receiver to only refresh.
> 

In my opinion, re-registration BU should not include the IPv4 HAO. Because
re-registration BU with IPv4 HAO
1. Need more bandwidth.
2. Cause extra load on HA. Because HA must verify if  the address in IPv4
HAO match that in BCE in order to avoid MN use a unauthorized IPv4 address. 

In fact, since "the home agent MUST be able to find the IPv4 home address of
a mobile node when given the IPv6 home address", section 5.5, why IPv4 HAO
must be include in re-registration BU? I can't find any benefit. 

I didn't find the description in 3775 for "a new BU overwrites the old one".
It should be implementation issue.
It also could be done as that attributes in BCE also include in
re-registration BU should be overwriten and other attribute not included in
re-registration BU should remain valid.  

De-registration for IPv4 HoA can be done by adding a bit in IPv4 HAO option
for indicating de-registration, or any other ways. It is all ok. 
I just think it is unnecessary that re-registration BU include the IPv4 HAO.
:-)



> > 
> > 2. We can find many other ways to delete the IPv4 binding if it is 
> > consensus that re-registration BU does not have to include the IPv4 
> > HAO. It could not be a resason for re-registration BU must 
> including IPv4 HAO.
> 
> => Well, that's the reason now, if you have better ideas, 
> other than designing a new option per extension please send 
> them to the list. This is already a bit late given that I'm 
> making the last update for IESG comments.
> 
> Hesham
> 
> > 
> >> 
> >> Hesham
> >> 
> >>>  
> >>> 
> >>> Regards,
> >>> Xiaoyan
> >> 
> > 
> > Regards,
> > Xiaoyan
> > 
> 
> 

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext