Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-v4v6-mipv4-01.txt

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 20 Apr 2006 15:28:51 -0700

Raj,

The purpose of DS-MIPv4 is slightly different than what you present
below. Keep in mind that Mobile IPv4 (unlike Mobile IPv6) is deployed
today in multiple networks, corporate and operator owned.

What we are trying to do is to allow these operators to provide IPv6 to
their customers with an incremental approach that fits their deployment
scenario (mobility) and without having to replace their entire
infrastructure.

Think of it this way:

- DS-MIPv4 extensions will ease transition to IPv6 for networks that are
currently Mobile IPv4 based.

- DS-MIPv6 will allow green field IPv6 deployments to happen while
providing access to the IPv4 Internet.

George 

> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]]
> Sent: Thursday, April 20, 2006 6:18 PM
> To: Tsirtsis, George; [email-masked]
> Subject: Re: [Mip4] FW: I-D ACTION:draft-tsirtsis-v4v6-mipv4-01.txt
> 
> 
> 
> George,
> 
> So we have many transition mechanisms for supporting IPv6 when a host
> is attached to an IPv4 access today. Obviously none of them are able
> to deal with mobility (i.e the host moving to different v4
> subnets). Your I-D basically is provding yet another transition
> mechanism for IPv6 with the added benefit of mobility. We are talking
> about dual-stack mobile hosts here, right... And you would agree that
> most IPv4 hosts do not have Mobile IPv4 client capability today. Given
> that the host is a dual-stack node, it should support MIP6 as part of
> its IPv6 stack. Hence it would be better to handle mobility using MIP6
> and also provide IPv4 connectivity using such an approach.
> In your I-D you state:
> 
> "
>    On the other hand, and more importantly, it allows dual stack
mobile
>    nodes and networks to utilize a single protocol for the movement of
>    both IPv4 and IPv6 stacks in the network topology.
> "
> The design team in MIP6/NEMO WG is essentially working on addressing
> the same issue for DS nodes. Why not use IPv6 mobility as the baseline
> mobility protocol?
> 
> The other point that I had was if connectivity to IPv6 islands is the
> need of the hour with mobility, could you not address this by using a
> Mobike solution that also provides transition GW capability on the GW
> side?
> 
> -Raj
> >>> -----Original Message-----
> >>> From: Henrik Levkowetz [mailto:[email-masked]]
> >>> Sent: Monday, April 17, 2006 10:44 AM
> >>> To: Tsirtsis, George
> >>> Cc: Pete McCann; [email-masked]
> >>> Subject: Re: [Mip4] FW: I-D
ACTION:draft-tsirtsis-v4v6-mipv4-01.txt
> >>>
> >>> Hi George,
> >>>
> >>> on 2006-04-17 16:34 Tsirtsis, George said the following:
> >>>> Pete/Henrik,
> >>>>
> >>>> This draft was just updated and it is now available on the I-D
> >>>> directory.
> >>>
> >>> Good, good.
> >>>
> >>>> Based on the discussion during the WG meeting we are requesting
> > for
> >> this
> >>>> proposal to be adopted as a working group draft.
> >>>
> >>> Right.  Well, we didn't have time for any proper discussion during
> >>> the meeting, and there were voices which called for that,
> > explicitly,
> >>> so let's start by hearing what people have to say about this
> > proposal.
> >>>
> >>> Speak up, people!
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Henrik
> >>>
> >>>
> >>>> Comments and suggestions are always welcome.
> >>>>
> >>>> Regards
> >>>> George
> >>>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]]
> >>>> Sent: Friday, April 14, 2006 6:50 PM
> >>>> To: [email-masked]
> >>>> Subject: I-D ACTION:draft-tsirtsis-v4v6-mipv4-01.txt
> >>>>
> >>>> A New Internet-Draft is available from the on-line
Internet-Drafts
> >>>> directories.
> >>>>
> >>>>
> >>>> Title  : Dual Stack Mobile IPv4
> >>>> Author(s) : G. Tsirtsis, et al.
> >>>> Filename : draft-tsirtsis-v4v6-mipv4-01.txt
> >>>> Pages  : 17
> >>>> Date  : 2006-4-14
> >>>>
> >>>> This specification provides IPv6 extensions to the Mobile IPv4
> >>>> [MIPv4] protocol. The extensions allow a dual stack node to use
> > IPv4
> >>>> and IPv6 home addresses as well as move between IPv4 and dual
> > stack
> >>>> network infrastructures.
> >>>>
> >>>> A URL for this Internet-Draft is:
> >>>>
> > http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt
> >>>>
> >>>> To remove yourself from the I-D Announcement list, send a message
> > to
> >>>> [email-masked] with the word unsubscribe in the
> > body
> >> of
> >>>> the message.
> >>>> You can also visit
> >> https://www1.ietf.org/mailman/listinfo/I-D-announce
> >>>> to change your subscription settings.
> >>>>
> >>>>
> >>>> Internet-Drafts are also available by anonymous FTP. Login with
> > the
> >>>> username
> >>>> "anonymous" and a password of your e-mail address. After logging
> > in,
> >>>> type "cd internet-drafts" and then
> >>>> "get draft-tsirtsis-v4v6-mipv4-01.txt".
> >>>>
> >>>> A list of Internet-Drafts directories can be found in
> >>>> http://www.ietf.org/shadow.html
> >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>>
> >>>>
> >>>> Internet-Drafts can also be obtained by e-mail.
> >>>>
> >>>> Send a message to:
> >>>> [email-masked].
> >>>> In the body type:
> >>>> "FILE /internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt".
> >>>>
> >>>> NOTE: The mail server at ietf.org can return the document in
> >>>> MIME-encoded form by using the "mpack" utility.  To use this
> >>>> feature, insert the command "ENCODING mime" before the "FILE"
> >>>> command.  To decode the response(s), you will need "munpack" or
> >>>> a MIME-compliant mail reader.  Different MIME-compliant mail
> >>>> readers
> >>>> exhibit different behavior, especially when dealing with
> >>>> "multipart" MIME messages (i.e. documents which have been split
> >>>> up into multiple messages), so check your local documentation on
> >>>> how to manipulate these messages.
> >>>>
> >>>>
> >>>> Below is the data which will enable a MIME compliant mail reader
> >>>> implementation to automatically retrieve the ASCII version of the
> >>>> Internet-Draft.
> >>>>
> >>>
> >>> --
> >>> Mip4 mailing list: [email-masked]
> >>>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
> >>>      Charter page:
> > http://www.ietf.org/html.charters/mip4-charter.html
> >>> Supplemental site: http://www.mip4.org/
> >>
> >>
> >>
> >> "This email message and any attachments are confidential
information
> > of
> >> Starent Networks, Corp. The information transmitted may not be used
to
> >> create or change any contractual obligations of Starent Networks,
> > Corp.
> >> Any review, retransmission, dissemination or other use of, or
taking
> > of
> >> any action in reliance upon this e-mail and its attachments by
persons
> > or
> >> entities other than the intended recipient is prohibited. If you
are
> > not
> >> the intended recipient, please notify the sender immediately -- by
> >> replying to this message or by sending an email to
> >> [email-masked] -- and destroy all copies of this
> > message
> >> and any attachments without reading or disclosing their contents.
> > Thank
> >> you."
> >
> > --
> > Mip4 mailing list: [email-masked]
> >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
> >      Charter page:
http://www.ietf.org/html.charters/mip4-charter.html
> > Supplemental site: http://www.mip4.org/

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Apr 2006 15:59:33 -0700

Hi George,

> scenario (mobility) and without having to replace their entire

I already disputed this argument. whats incremental
about deploying IPv6? compared to deploying IPv6
services, upgrading your home agent and mobile node
from MIPv4 to MIPv6 would be trivial. I don't buy
this argument.

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 21 Apr 2006 01:29:09 +0200

Hi Vijay,

> from MIPv4 to MIPv6 would be trivial. I don't buy

So I guess I'll have to repeat my refutation too.  Whether you
buy it or not, being able to deploy a MIPv6 agent on your client
platform is vitally dependent on the commercial availability of
fine client software for that platform.  Whether you as an
individual find it trivial to perform an upgrade is neither here
nor there in this context.

And furthermore, upgrading the client in thousands or millions of
deployed low-end devices can hardly be considered 'trivial', even
if the software is available and will fit in the flash memory of
the device, which is not at all guaranteed.

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Apr 2006 16:38:39 -0700

Henrik Levkowetz wrote:
> fine client software for that platform.  

they are available. I don't see this as an issue.

> Whether you as an

I am not talking about "myself". I am talking
about an enterprise upgrading their clients from
MIPv4 to MIPv6 while upgrading them to use IPv6
services.

> the device, which is not at all guaranteed.

the clients are being upgraded for IPv6 services
anyway. whats special about upgrading the clients
from MIPv4 to MIPv6?

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 21 Apr 2006 01:58:34 +0200

on 2006-04-21 01:38 Vijay Devarapalli said the following:
...
> they are available. I don't see this as an issue.

I understand that you don't see it as an issue.  However, as you
aren't the one who will have to upgrade your infrastructure, and
some people who are deploying MIP4 are asking for this, I don't
see that we can ignore them because this is not an issue for you...

> MIPv4 to MIPv6 while upgrading them to use IPv6

You're assuming that the device which is running IPv6 apps
is the same as the one with the MIPv4 client.  This is not
necessarily true.

> anyway. whats special about upgrading the clients

Nope.  Think a phone model which may have just enough flash for
MIPv4, but not enough flash for the additional IPsec and MIPv6
functionality.

Things aren't necessarily as simple as you suggest for those
who have MIPv4 deployed in small devices today, I believe.

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Apr 2006 17:14:07 -0700

> see that we can ignore them because this is not an issue for you...

ok. I generally don't oppose any work in any
working group if it is right thing to do or there
are people who really want the solution. IMHO,
these are the two most important things to
consider when some new work is proposed in the
IETF. in this case, I haven't seen either so far.

> is the same as the one with the MIPv4 client.  This is not

hmmm... then how does the spec which describes
running IPv6 over MIPv4 help these clients? some
of the clients run IPv6 while others run MIPv4.
I am missing something here.

> MIPv4, but not enough flash for the additional IPsec and MIPv6

is this small device being upgraded to IPv6?
IPsec is a MUST for IPv6.

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 21 Apr 2006 03:35:30 +0200

> IETF. in this case, I haven't seen either so far.

Ok.  I guess perceptions can differ.

> I am missing something here.

As one example, let us take a MIPv4 enabled cell-phone which
provides connectivity for a IPv6 enabled laptop.  Why would
you deny the MIPv4 conduit the capability of transporting
IPv6 packets?

> IPsec is a MUST for IPv6.

See example above.

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Apr 2006 18:47:41 -0700

> you deny the MIPv4 conduit the capability of transporting

got it. the MIPv4 client is not being upgraded to
IPv6, but the device connecting through it is being
upgraded. this is a valid case where it might not
be trivial to upgrade the MIPv4 client to MIPv6
client. but is this the common case in an
Enterprise? I expect laptops connecting directly to
the Enterprise network instead of through cell
phones. when the user is outside the Enterprise
network, then the laptop might be connected to the
Enterprise through a cell phone (through a cellular
operator). but in this case MIPv4 might not be used.
the MIP tunnel might be inside an IPsec tunnel.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 20 Apr 2006 22:52:08 -0500

Hi George,

Inline:

> today in multiple networks, corporate and operator owned.

No argument about the fact that MIP4 has some deployment today and MIP6 has
none. MIP6 is in a catch22 situation. You need IPv6 deployments to enable
MIP6.... So let me not speculate when, how, where this will/may happen.

> scenario (mobility) and without having to replace their entire

So the assumption here is that there are operators that want to provide IPv6
service and this can be enabled by having IPv6 carried over mobility enabled
tunnels that are setup by MIP4. Well, if the operator wants to provide IPv6
service there will be hosts that are DS...So now the question is how to
access the IPv6 island given the fact that it is only v4 that is ubiquitous,
and provide mobility at the same time.
Yes, you could do this using MIP4 as you explain in your well-written I-D.
Or you could setup IPsec tunnels to a VPN GW that supports Mobike and run
IPv6 over it 
Or you run Mobile IPv6 over v4 access as is being specified by the design
team (MIP6/NEMO).
So in the above scenarios the last two require some additional or new infra
to be added. But with MIP4 as well it does not come for free. You need to
upgrade the MIP4 HA as well as upgrade the MIP4 clients. So there is a cost
involved irrespective of which path you take.

> currently Mobile IPv4 based.

Hmmm... I wish this was the magic bullet.  But I am not sure. If operators
want to deploy IPv6, I think existing transition mechanisms are more than
sufficient to enable it. I don't know if DS-MIP4 is the enabler that will
change the status quo.
DS-MIP4 is as I said, yet another transition mechanism that addresses a
small percentage of IPv4 hosts which are MIP4 enabled but I am not so
convinced that it is "THE" feature that is currently missing which is
prohibiting deployment of IPv6.

> providing access to the IPv4 Internet.

True.

-Raj

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 21 Apr 2006 09:54:40 +0200

Hi Vijay,

...
> the MIP tunnel might be inside an IPsec tunnel.

More likely the MIP tunnel would go to the operator, while
any IPsec tunnel would be inside the MIP tunnel and go all
the way to the enterprise.

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Apr 2006 14:30:29 -0700

> the way to the enterprise.

I was under the impression that we are talking
about MIPv4 inside an enterprise network and
carrying IPv6 over MIPv4 inside the enterprise
networks.

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 25 Apr 2006 23:48:52 +0200

Hi Vijay,

> carrying IPv6 over MIPv4 inside the enterprise

I see this as a quite generic functionality, and haven't been
limiting this to MIPv4 inside an enterprise.  And especially
when MIP might be provided by one entity, (operator, maybe)
while another is rolling out IPv6 internally (enterprise,
maybe) it seems that the ability to carry IPv6 in MIPv4 makes
sense.

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Apr 2006 15:45:08 -0700

> maybe) it seems that the ability to carry IPv6 in MIPv4 makes

well, one of the justification that folks were
using was an enterprise network that was using
MIPv4 already and was deploying IPv6 services.
this is what we were discussing and I was
arguing it would be trivial to update the client
and the home agent while updating the network
for IPv6 services.

now talking about an operator using MIPv4 and
wanting to carry IPv6 over MIPv4 tunnels, yes
its possible. but does anybody want to do this?

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 26 Apr 2006 01:19:54 +0200

Hi Vijay,

on 2006-04-26 00:45 Vijay Devarapalli said the following:
...
> and the home agent while updating the network

If I go back and look at the initial posts in this thread,
the only one who mentioned enterprises was I, and if you read
that post again, you'll see that I'm *not* assuming that the
MIPv4 infrastructure is in the enterprise, only that it is
used by the enterprise.  So there seems to have been a bit
of a misunderstanding here...

> its possible. but does anybody want to do this?

One expample:

Currently there are 2 proposals for multi-access mobility in
3GPP, one which proposes MIPv6 with v4trans additions (from
Ericsson) and one proposing MIPv4.  If the MIPv4 proposal
goes through (I don't think that's optimal, but I think it
may happen) then the kind of functionality we're talking about
here will be hotly required in a few years.  About the time we
can have an RFC out and ready for reference if we start now.

Regards,

	Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Apr 2006 16:32:53 -0700

> of a misunderstanding here...

I think it started with Alpesh's incremental
upgrade comment and then George. but never
mind.

> Ericsson) and one proposing MIPv4.  

well, I was one of the people involved in
proposing the MIPv4 solution when I was at
Nokia. :)

> If the MIPv4 proposal

I can say with reasonable confidence that folks
who are pushing MIPv4 for multi-access mobility
in 3GPP like MIPv6 also and would rather deploy
MIPv6. but thats a discussion we can't have on
the mailing list. :)

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Apr 2006 15:20:26 +0200

Henrik Levkowetz wrote:
> 
> on 2006-04-21 01:38 Vijay Devarapalli said the following: ...
>>>> I already disputed this argument. whats incremental about
>>>> deploying IPv6? compared to deploying IPv6 services, upgrading
>>>> your home agent and mobile node from MIPv4 to MIPv6 would be
>>>> trivial. I don't buy this argument.
> aren't the one who will have to upgrade your infrastructure, and some
> people who are deploying MIP4 are asking for this, I don't see that
> we can ignore them because this is not an issue for you...
> 
>>> Whether you as an individual find it trivial to perform an
>>> upgrade is neither here nor there in this context.
>> I am not talking about "myself". I am talking about an enterprise
>> upgrading their clients from MIPv4 to MIPv6 while upgrading them to
>> use IPv6 services.
> 
> You're assuming that the device which is running IPv6 apps is the
> same as the one with the MIPv4 client.  This is not necessarily true.
> 
> 
>>>  deployed low-end devices can hardly be considered 'trivial',
>>> even if the software is available and will fit in the flash
>>> memory of the device, which is not at all guaranteed.
>> the clients are being upgraded for IPv6 services anyway. whats
>> special about upgrading the clients from MIPv4 to MIPv6?
> 

Just to deviate the discussion away from the memory footprint.  There
are at least two mobile phone manufacturers mass-marketing devices
running IPv4.  At least two of those models were demonstrated to running
also MIPv6 over WiFi.

The issue to integrate MIPv6/IPsec in a high-end mobile phone is not a
memory footprint issue.  I.e. there's enough memory to run a MIP6 stack
together with IPsec.  In these kinds of phones there's usually an entire
jvm running, a web browser, a bluetooth stack - all of them largely
overcoming the size of a MIP6/IPsec stack.

The issue with the mobile phones is the need: what user needs MIP when
IPv4 over GPRS/UMTS is mobile enough for the battery it has?  What user
needs IPv6 when there's no deployed cell running IPv6?  Once the need is
clear, there's enough computing cycles and bits available in a phone to
do both native MIP4 and native MIP6.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Apr 2006 15:28:20 +0200

Vijay Devarapalli wrote:
> Henrik Levkowetz wrote:
>> Hi Vijay,
>> 
>> on 2006-04-26 00:45 Vijay Devarapalli said the following: ...
>>> well, one of the justification that folks were using was an
>>> enterprise network that was using MIPv4 already and was deploying
>>> IPv6 services. this is what we were discussing and I was arguing
>>> it would be trivial to update the client and the home agent while
>>> updating the network for IPv6 services.
>> 
>> If I go back and look at the initial posts in this thread, the only
>> one who mentioned enterprises was I, and if you read that post
>> again, you'll see that I'm *not* assuming that the MIPv4
>> infrastructure is in the enterprise, only that it is used by the
>> enterprise.  So there seems to have been a bit of a
>> misunderstanding here...
> 
> I think it started with Alpesh's incremental upgrade comment and then
> George. but never mind.
> 
>> 
>>> now talking about an operator using MIPv4 and wanting to carry
>>> IPv6 over MIPv4 tunnels, yes its possible. but does anybody want
>>> to do this?
>> 
>> One expample:
>> 
>> Currently there are 2 proposals for multi-access mobility in 3GPP,
>> one which proposes MIPv6 with v4trans additions (from Ericsson) and
>> one proposing MIPv4.
> 
> well, I was one of the people involved in proposing the MIPv4
> solution when I was at Nokia. :)

:-)

Guys, from recent history of IETF and other SDO related  to mobile
phones: it's not enough to get some protocol into a spec that it gets
deployed.  Getting MIP4 into 3GPP doesn't mean it will get deployed at
all, at least because IPv6 and MIP6 are already in these SDOs specs -
for quite some time - and there's no deployment.  Also, MIP4 got
deployed in some mobile phones and long before the protocols were in
these SDO specs.

So maybe we should distinguish the clients: is the client of a proposed
protocol just another SDO?  Or one operator?  Or several operators
wishing to inter-operate?  Or some phone manufacturer wishing to deploy
it soon?

>> If the MIPv4 proposal goes through (I don't think that's optimal,
>> but I think it may happen) then the kind of functionality we're
>> talking about here will be hotly required in a few years.  About
>> the time we can have an RFC out and ready for reference if we start
>> now.
> 
> I can say with reasonable confidence that folks who are pushing MIPv4
> for multi-access mobility in 3GPP like MIPv6 also and would rather
> deploy MIPv6. but thats a discussion we can't have on the mailing
> list. :)

I think that's a real problem that we can't discuss it on the mailing 
list.  Many things happen in the non-IEEE SDOs assuming some secret 
enormous deployment plans.  That is not good.

Alex