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 >
- [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-13.t… Internet-Drafts
- Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-… Julien Laganier
- Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-… Charles E. Perkins
- Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-… Alexandru Petrescu