Re: [nemo] NEMOv4 vs DS-MIPv6

Henrik Levkowetz <henrik@levkowetz.com> Thu, 11 May 2006 09:46 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe7kM-00043y-VT; Thu, 11 May 2006 05:46:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe7kL-00043t-G6 for nemo@ietf.org; Thu, 11 May 2006 05:46:13 -0400
Received: from av11-1-sn2.hy.skanova.net ([81.228.8.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe7kK-00082Y-V0 for nemo@ietf.org; Thu, 11 May 2006 05:46:13 -0400
Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 4A33537FDD; Thu, 11 May 2006 11:46:12 +0200 (CEST)
Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 26CFB37F54; Thu, 11 May 2006 11:46:12 +0200 (CEST)
Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id BE83437E50; Thu, 11 May 2006 11:46:07 +0200 (CEST)
Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from <henrik@levkowetz.com>) id 1Fe7kE-0005aX-81; Thu, 11 May 2006 11:46:06 +0200
Message-ID: <446307DD.4090707@levkowetz.com>
Date: Thu, 11 May 2006 11:46:05 +0200
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308)
MIME-Version: 1.0
To: "Narayanan, Vidya" <vidyan@qualcomm.com>
Subject: Re: [nemo] NEMOv4 vs DS-MIPv6
References: <2EBB8025B6D1BA41B567DB32C1D8DB8480F815@NAEX06.na.qualcomm.com>
In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8480F815@NAEX06.na.qualcomm.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Cc: nemo@ietf.org, Thierry Ernst <thierry.ernst@inria.fr>
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Errors-To: nemo-bounces@ietf.org

Hi Vidya,

on 2006-05-11 04:35 Narayanan, Vidya said the following:
> Hi Henrik,
>  
>> In *that* case you've got me, but I have to say that I have a 
>> hard time understanding how it might be possible to put in a 
>> new component with new NEMOv4 MR capability, but not a NEMOv6 
>> MR.  The v6 MR doesn't require any surrounding IPv6 
>> infrastructure, either, so ... I have a hard time seeing how 
>> that restriction would come into place.  Mind you, it might, 
>> but it's not obvious.
>> 
> 
> The problem sometimes is just the lack of an IPv6 stack in the
> host/mobile router. Putting new NEMOv4 functionality only relies on an
> existing IPv4 stack, while putting NEMOv6 brings in the need for an IPv6
> stack. I am not saying that putting an IPv6 stack on such devices is the
> end of the world, but deployments aren't always that straightforward. In
> addition to adding NEMO functionality and dealing with the rollout,
> testing, etc. of that, such things are now broader with the introduction
> of IPv6 - which means more cycles, time, etc. - this is often a problem
> in the present world (unfortunately). 

Heh.  I understand.  I see a market opening here for an implementation
of MIPv6 which doesn't require an IPv6 stack as long as you're not
sending IPv6 traffic.  Entirely possible, I think.  ;-)


	Henrik



> Vidya
> 
> 
>> > George
>> > P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does 
>> support IPv4 
>> > prefixes
>> 
>> Yes.
>> 
>> 
>> 	Henrik
>> 
>> 
>> >> -----Original Message-----
>> >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
>> >> Sent: Wednesday, May 10, 2006 4:55 PM
>> >> To: Tsirtsis, George
>> >> Cc: nemo@ietf.org; Thierry Ernst
>> >> Subject: Re: [nemo] NEMOv4 vs DS-MIPv6
>> >> 
>> >> Hi George,
>> >> 
>> >> on 2006-05-10 17:51 Tsirtsis, George said the following:
>> >> ...
>> >> >> I'm not sure what your scenario is, and in which 
>> situation NEMOv4 
>> >> >> support would be necessary. If someone argue that NEMOv4 is
>> > necessary
>> >> >> because there are existing vehicles - for instance - with IPv4 
>> >> >> capabilities and the customer doesn't want to upgrade 
>> the vehicles
>> > to
>> >> >> IPv6, then I guess the customer could be adviced to deployed
>> > DS-MIPv6
>> >> > on
>> >> >> the MR.
>> >> >>
>> >> >
>> >> > First of all I am not sure that DS-MIPv6 currently supports IPv4
>> > network
>> >> > prefixes allocation (maybe it should). But even if it does, what 
>> >> > you
>> > are
>> >> > suggesting is that the network operator providing 
>> services to that
>> > car
>> >> > is IPv6 capable. Is it not clear to everyone that in most of the
>> > world
>> >> > this is still not the case?
>> >> 
>> >> Mmm??  I believe that is incorrect.  I don't see why the network
>> > operator
>> >> has to be IPv6 capable.  The only part in the network that 
>> has to be
>> >> IPv6 is the home link, which can be virtual.  So you'll 
>> need a MIPv6 
>> >> HA, but the box it sits in doesn't even need a single physical
>> > interface
>> >> which has an IPv6 address.
>> >> 
>> >> >> It would be interesting to list down in which situation a
>> > transition
>> >> >> mechanims (DM-MIPv6 or another one) could apply or not 
>> so that we
>> >> > could
>> >> >> clarify how many important scenarios would require a plain IPv4
>> >> > solution.
>> >> >>
>> >> >
>> >> > NEMOv4 would be useful for network operators that support mobile 
>> >> > equipment (cars, trains, home routers or whatever) and that, for 
>> >> > whatever reason, do not support IPv6 but still want to support
>> > network
>> >> > mobility.
>> >> 
>> >> (As indicated above) I believe this doesn't hold.
>> >> 
>> >> > I really do not like the fact that lately, to do any IPv4 work in
>> > the
>> >> > IETF, we are getting pressured to release customer 
>> information and 
>> >> > deployment details. I will say the following which I hope will
>> > satisfy
>> >> > you:
>> >> > We have a number of customers (network operators) in 
>> various parts
>> > of
>> >> > the world that have deployed our FLASH-OFDM system. This is
>> > basically a
>> >> > MobileIPv4 based cellular data system (search for Flarion press
>> > releases
>> >> > if you want specifics...and sorry for the commercial).
>> >> >
>> >> > Our customers would like to support network mobility. Some 
>> >> > customers would also like to move to IPv6 some day, 
>> which is why we 
>> >> > proposed
>> >> > DS-MIPv4 and DS-MIPv6 solutions. The two decisions, however, are 
>> >> > not related and should not have to be coupled.
>> >> 
>> >> Fine.  But nevertheless, NEMOv6 with DSMIPv6 will let you support 
>> >> network mobility without the operator having to support IPv6.
>> >> 
>> >> 
>> >> 	Henrik
>> > 
>> > 
>> 
>> 
>