Re: [Mip6] draft-dupont-mip6-dhaadharmful-00.txt

Vijay Devarapalli <vijayd@iprg.nokia.com> Tue, 25 October 2005 23:03 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUXpP-0002sm-2A; Tue, 25 Oct 2005 19:03:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUXpI-0002g4-4M for mip6@megatron.ietf.org; Tue, 25 Oct 2005 19:03:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24270 for <mip6@ietf.org>; Tue, 25 Oct 2005 19:03:12 -0400 (EDT)
Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUY21-0006V0-Tj for mip6@ietf.org; Tue, 25 Oct 2005 19:16:49 -0400
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j9PMTno05159; Tue, 25 Oct 2005 15:29:49 -0700
X-mProtect: <200510252229> Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14184.americas.nokia.com (172.18.141.84, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdEGoKbs; Tue, 25 Oct 2005 15:29:47 PDT
Message-ID: <435EB98D.3010401@iprg.nokia.com>
Date: Tue, 25 Oct 2005 16:02:37 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gerardo Giaretta <Gerardo.Giaretta@TILAB.COM>
Subject: Re: [Mip6] draft-dupont-mip6-dhaadharmful-00.txt
References: <DA62A6E0CDD1B34A84557FF1AC850C57016E9CDC@EXC01B.cselt.it>
In-Reply-To: <DA62A6E0CDD1B34A84557FF1AC850C57016E9CDC@EXC01B.cselt.it>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: mip6@ietf.org, Kilian Weniger <Kilian.Weniger@eu.panasonic.com>, James Kempf <Kempf@docomolabs-usa.com>, Francis Dupont <Francis.Dupont@enst-bretagne.fr>, Petrescu Alexandru-AAP021 <alexandru.petrescu@motorola.com>, COMBES Jean-Michel RD-MAPS-ISS <jeanmichel.combes@francetelecom.com>
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org

Gerardo Giaretta wrote:

>>What does prevent the MN to contact the HA he wants? Nothing 
>>as far as I
>>can see.
>>
> 
> 
> I agree. This is true also for DHAAD. 
> Besides the motivation why a MN will prevent another HA that is
> theoretically more loaded, the operator may let the HA refuse the IPsec
> SA setup during IKEv2 through its AAA infrastructure. But I agree this
> is not a clean approach.
> 
> 
>>> Otherwise, in integrated scenario, 
>>>DHCP can be used. As mentioned before, if you need a very 
>>>strict control on the HA assignment by the operator, IMHO the 
>>>best way is to perform it during network access 
>>>authentication, but unfortunately this is not a general solution.
>>
>>Agree. But I think a operator must have the possibility to 
>>assign the HA
>>in any cases.
>>
> 
> 
> DHCP-based solution seems to achieve this. Do you see any issue on that?

yes. DHCP based solution would require the Operator to
first update the access network too. what many operators
would like to do (initially atleast) is to just plug in
a HA and introduce new mobile devices that can use the
new features. no upgrades anywhere else.

Vijay


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6