Re: [MEXT] Rethink on Mobile IPv6

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 05 March 2010 15:14 UTC

Return-Path: <alexandru.petrescu@gmail.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 245F83A8FB9; Fri, 5 Mar 2010 07:14:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 tuW4-HJXrv3Z; Fri, 5 Mar 2010 07:14:08 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 264983A8AB4; Fri, 5 Mar 2010 07:14:07 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o25FDtGV016244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Mar 2010 16:13:55 +0100
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o25FDsVg029979; Fri, 5 Mar 2010 16:13:55 +0100 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o25FDswd027219; Fri, 5 Mar 2010 16:13:54 +0100
Message-ID: <4B911FB2.4050301@gmail.com>
Date: Fri, 05 Mar 2010 16:13:54 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: Basavaraj.Patil@nokia.com
References: <C7B3E2AE.5767%basavaraj.patil@nokia.com>
In-Reply-To: <C7B3E2AE.5767%basavaraj.patil@nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: jari.arkko@piuha.net, rdroms@cisco.com, int-area@ietf.org, mext@ietf.org
Subject: Re: [MEXT] Rethink on Mobile IPv6
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: Fri, 05 Mar 2010 15:14:10 -0000

With respect to the deployment of Mobile IPv6.

I just wanted to add to this thread the fact that a "Mobile IPv6
(EXPERIMENTAL)" button exists since some time now in the main linux
kernel.  This is a great achievement for the Mobile IPv6 community, I think.

Alex

Le 03/03/2010 16:55, Basavaraj.Patil@nokia.com a écrit :
>
> Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack
> Mobile IPv6 (RFC5555) since 2009. Implementations of the protocol
> has been lacklustre to say the least. Several SDOs have considered
> MIP6 and DSMIP6 as a solution for interworking and mobility between
> different access technologies and only 3GPP has adopted it in a very
> limited manner for Rel 8 (for use on the S2c interface) with the
> likelihood of it being actually deployed quite low (IMO).
>
> While there are many reasons that can be attributed to the lack of
> implementations and use, one that I would like to raise is the the
> concern with the overly complex security model that MIP6/DSMIP6
> relies on today. MIP6/DSMIP6 requires IPsec and IKE/IKEv2
> (RFC3776/4877) to secure the signaling between the MN and HA. The
> fundamental purpose of MIP6/DSMIP6 is to provide mobility to hosts.
> At a very high level the MIP6/DSMIP6 protocol boils down to the
> ability to setup a tunnel between the MN and HA and update the MN
> tunnel end-point whenever there is a change in the associated IP
> address (CoA). The signaling to establish the tunnel needs to be
> secure. But using a protocol like IKEv2 and IPsec to achieve this
> security is just an overkill. It increases the complexity of the
> implementation as a result of many factors that have been captured in
> I-D: draft-patil-mext-mip6issueswithipsec and discussed in the MEXT
> WG meetings.
>
> Given the objective of the protocol is to enable IP mobility for
> hosts, it should focus on doing that well in a manner that makes it
> easy to implement/adopt/deploy/scale. My opinion as a result of
> implementation experience is that MIP6/DSMIP6 can be significantly
> simplified, especially the security architecture. The protocol as
> specified currently in RFC3775/RFC5555 is a kitchensink of features.
>  Getting back to basics of simply establishing a tunnel between the
> MN and HA and managing that tunnel is all that is needed and would
> potentially see the light of day in the real world.
>
> You may want to call it as Mobile IPv6-lite if you wish. But I do
> believe that a simplification of the protocol is needed without
> which I fear it will remain an academic exercise with many years
> spent in developing a spec. I hope the working group and people who
> are involved in mobility related work would consider undertaking such
> an effort in the IETF.
>
> -Basavaraj
>
> _______________________________________________ MEXT mailing list
> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
>