[Int-area] Rethink on Mobile IPv6

<Basavaraj.Patil@nokia.com> Wed, 03 March 2010 15:56 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91F93A8AB7; Wed, 3 Mar 2010 07:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Rtw00kbptsLP; Wed, 3 Mar 2010 07:56:24 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B7E053A8A86; Wed, 3 Mar 2010 07:56:23 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o23FuIEI031379; Wed, 3 Mar 2010 17:56:19 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 17:56:02 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 17:56:02 +0200
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 3 Mar 2010 16:56:02 +0100
From: Basavaraj.Patil@nokia.com
To: mext@ietf.org
Date: Wed, 03 Mar 2010 16:55:58 +0100
Thread-Topic: Rethink on Mobile IPv6
Thread-Index: Acq66gOoUWTseQTmoUO8Px+IuYFs9g==
Message-ID: <C7B3E2AE.5767%basavaraj.patil@nokia.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Mar 2010 15:56:02.0669 (UTC) FILETIME=[067169D0:01CABAEA]
X-Nokia-AV: Clean
Cc: int-area@ietf.org, rdroms@cisco.com
Subject: [Int-area] Rethink on Mobile IPv6
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2010 15:56:25 -0000

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