Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-13.txt

Alexandru Petrescu <alexandru.petrescu@gmail.com> Sun, 20 March 2011 15:25 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 AF37728C0D8 for <mext@core3.amsl.com>; Sun, 20 Mar 2011 08:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.529
X-Spam-Level:
X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24]
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 oZXxIXbpc6gc for <mext@core3.amsl.com>; Sun, 20 Mar 2011 08:25:44 -0700 (PDT)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0A728C0CF for <mext@ietf.org>; Sun, 20 Mar 2011 08:25:42 -0700 (PDT)
Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id DF6409400F2 for <mext@ietf.org>; Sun, 20 Mar 2011 16:27:09 +0100 (CET)
Message-ID: <4D861CCC.5010600@gmail.com>
Date: Sun, 20 Mar 2011 16:27:08 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: mext@ietf.org
References: <20110312000001.8564.99335.idtracker@localhost> <AANLkTinC6qZbQdSX45j1FY5K-boWCMk2EmxM496tcOE8@mail.gmail.com> <4D7AC1CE.9040105@earthlink.net>
In-Reply-To: <4D7AC1CE.9040105@earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 110320-0, 20/03/2011), Outbound message
X-Antivirus-Status: Clean
Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-13.txt
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: Sun, 20 Mar 2011 15:25:45 -0000

Le 12/03/2011 01:43, Charles E. Perkins a écrit :
> Hello Julien,
>
> You're welcome. It's been more than a dozen years since the start of
> RFC 3775, and quite an experience. I remember when we were pretty
> sure that IPv6 would be widely available by year 2000 or so, and
> we'd all have quite heterogeneous access to converged mobile/fixed
> voice/data networks. I guess something went wrong along the way.

Hello Charles,

I am interested understanding what may have gone wrong, to improve
future action.

Overall, I think Mobile IPv6 is relevant and needed but only in some
particular settings satisfying some conditions.

Generally, lack of truth in advertisement is a factor hampering Mobile
IPv6 adoption.  Not only once the handover story was advertised
on sold products without being actually implemented.  Advertising the
handover feature is encouraging in the short term - it is a beautiful
story which sells, but lacking the real feature prevents wider adoption.

I _think_ one of the reasons may relate to the adoption by some SDO.  On
one hand, SDO adoption is very encouraging, assuming it materializes.
  It is that materialization in deployment which seems to
be an issue, IMHO.  I think too much importance may have been given to
the SDO need.  Were it to be developped for more pragmatic small issues
at hand I guess it may have been better.

It is good to have a single IETF protocol to do IPv6 mobility.  But
there is a misunderstanding about this.  SDO is tempted to pick that one
protocol as universal solution for mobility.  Or, Internet is not for
one particular SDO.  Mobile IPv6 is designed to work _across_ networks
using protocols of different SDOs.  Within one single technology SDO
Mobile IPv6 is an unnecessary burden.

Another SDO aspect: one particular SDO success went very fast and far in
the recent years.  Surprisingly in a sense - that happens without Mobile
IPv6.  Worse, it seems to be trying to to avoid the use of Mobile IPv6.
  For example, in a public transportation vehicle, the tendency is to let
passengers use that pervasive SDO network, instead of recommending a
WiFi network deployed _within_ the vehicle.  The net effect is that it
avoids handovers and the changes in the IP address while moving.

Another issue may lie in the discrepancy between the (mis)advertised
features and the problems it actually solves.  It advertises too much. 
Mobile IPv6 is often presented as _the_ protocol to run on a mobile 
device.  But in practice there are several other IPv6 protocols run on a 
mobile device which help it deal with that mobility.

There may be issues as well about the MIP6 recommendation of particular
types of tunnels, and IPR, preventing adoption.

The problems Mobile IPv6 actually solves, and which no other protocols
solves are only two and, strangely enough, only when they're both
needed: reachability at a unique HoA _and_ continuous real-time
sessions.  Taken separately, each problem is solved by other protocols
e.g. RTP, VPN.  The context of those two solved problems is also
particular: it is the worldwide Internet, where tunnels are necessary
and route updates impossible.  A context of only one SDO network is not
relevant for Mobile IPv6, because within it route updates are possible
and MIP tunnels are a burden to the existing tunnels.

Naming: if it were called "dynamic tunnel setup for real-time
sessions combined with reachability at unique address, across
heterogeneous links, for wide scale Internet" instead of "Mobile IPv6"
it could have been better.  It may have gotten less visibility, but
adoption may have been wider.

My optimistic note is that Mobile IPv6 protocol _is_ needed in these
particular settings where some particular conditions are met.  It may be
that these settings are not as numerous as initially expected.

Alex

>
> Regards, Charlie P.
>
>
>
> On 3/11/2011 4:34 PM, Julien Laganier wrote:
>> Folks,
>>
>> This will be the last revision of the rfc3775bis. It resolves the
>> last discuss held by Tim Polk, and thus it will move towards the
>> RFC Editor for publication. Thanks again to Charlie for
>> volunteering to serve as an editor of our most important document!
>>
>> --julien
>>
>> On Fri, Mar 11, 2011 at 4:00 PM,<Internet-Drafts@ietf.org> wrote:
>>> A New Internet-Draft is available from the on-line
>>> Internet-Drafts directories. This draft is a work item of the
>>> Mobility EXTensions for IPv6 Working Group of the IETF.
>>>
>>>
>>> Title : Mobility Support in IPv6 Author(s) : C. Perkins, et al.
>>> Filename : draft-ietf-mext-rfc3775bis-13.txt Pages : 177 Date :
>>> 2011-03-11
>>>
>>> This document specifies Mobile IPv6, a protocol which allows
>>> nodes to remain reachable while moving around in the IPv6
>>> Internet. Each mobile node is always identified by its home
>>> address, regardless of its current point of attachment to the
>>> Internet. While situated away from its home, a mobile node is
>>> also associated with a care-of address, which provides
>>> information about the mobile node's current location. IPv6
>>> packets addressed to a mobile node's home address are
>>> transparently routed to its care-of address. The protocol enables
>>> IPv6 nodes to cache the binding of a mobile node's home address
>>> with its care-of address, and to then send any packets destined
>>> for the mobile node directly to it at this care-of address. To
>>> support this operation, Mobile IPv6 defines a new IPv6 protocol
>>> and a new destination option. All IPv6 nodes, whether mobile or
>>> stationary, can communicate with mobile nodes. This document
>>> obsoletes RFC 3775.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-13.txt
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>>  implementation to automatically retrieve the ASCII version of
>>> the Internet-Draft.
>>>
>>>
>>> _______________________________________________ MEXT mailing list
>>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
>>>
>>>
>>
>
> _______________________________________________ MEXT mailing list
> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
>