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

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Mon, 17 Apr 2006 10:02:37 -0700

I believe leveraging the MIPv4 signaling to support dual IPv4/IPv6 is a
good idea.

Kent 

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Monday, April 17, 2006 8: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/
> 

-- 
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: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 18 Apr 2006 18:46:25 -0400

In principle, I support this work to progress in IETF. However, I think
that we need to have a discussion on which approach to adopt. We also
wrote a draft on this line with a somewhat different approach:

http://www.ietf.org/internet-drafts/draft-navali-ip6-over-netmip4-00.txt

I see a value in pursuing both the approaches as they address specific
deployment scenarios. 

-Kuntal

> Sent: Monday, April 17, 2006 10:44 AM
> To: Tsirtsis, George
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
> 
> 
> > 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.
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > [email-masked] with the word unsubscribe in the body
of
> > username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail
> > readers

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 19 Apr 2006 18:37:22 -0700

Are you guys satisfied with the response on the list or do you want to
give it a few more days?

Thanks
George

> Sent: Monday, April 17, 2006 11:44 AM
> To: Tsirtsis, George
this
of

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 20 Apr 2006 17:13:32 -0700

Catching up with this thread, I would support the draft. 

While some of us may feel that MIP6 deployment is trivial, in the real
world, things more trivial than that have been a big deal. So, I am not
at all surprised that this would be a big deal. 

So, letting deployments decide if they want to use DSMIP4 or DSMIP6
suits their needs makes a lot of sense to me. 

Regards,
Vidya

> Sent: Thursday, April 20, 2006 4:59 PM
> To: Vijay Devarapalli
> Cc: Tsirtsis, George; [email-masked]
> 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.
> >> 
> >> 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.
> > 
> > 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...
> 
> >> 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.
> 
> >> 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.
> > 
> > the clients are being upgraded for IPv6 services anyway. 
> whats special 
> > about upgrading the clients from MIPv4 to MIPv6?
> 
> 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: "Tsirtsis, George" <[email-masked]>
Date: Fri, 21 Apr 2006 15:23:42 -0700

You are doing DS-MIPv6 in MIP6 WG. It stands to reason that DS-MIPv4
should be done in MIP4 WG.

> From: Basavaraj Patil [mailto:[email-masked]]
> Sent: Friday, April 21, 2006 8:53 AM
> To: Tsirtsis, George; [email-masked]
> Okay...
> From a logistical perspective, if you believe this is a transition
> mechanism
> for IPv6 and given that Ngtrans no longer exists maybe it should be
> discussed or work done between the MIP4 and v6ops WGs? Just a
suggestion.
> The chairs can decide what makes the best sense.
> 
> -Raj
> 
> 
> On 4/21/06 6:35 AM, "ext Tsirtsis, George" <[email-masked]>
wrote:
> 
> > Raj,
> >
> > I am not claiming that DS-MIPv4 is a magic bullet for anything. I am
> > only suggesting that it may be the most sensible way to go for a
network
> > that is MIPv4 based today and wants to start moving to IPv6.
> >
> > Yes, there are many ngtrans tools defined (some think too many) but
> > DS-MIP is the obvious one that was missed. It was missed because at
the
> > time ngtrans was defining tools, Mobile iP was not nearly as much
> > deployed as it is today and because the IETF had and still has big
> > problems with understanding mobility.
> >
> > But think about it. Virtually every other ngtrans tool defines a
> > mechanism that automatically or semi-automatically configures
tunnels.
> > Well, Mobile IP is nothing but a tunnel manager with a lot of bells
and
> > whistles (for access control, authentication, configuration, network
> > mobility etc) and with mobility support for free. If a have a
network
> > that already uses Mobile IP, and all the back-end systems to make it
> > work, why would I want to use some other tunnel management protocol
on
> > top of it with all its additional complexity and overhead? Its just
> > makes no sense!
> >
> > George
> >
> >> From: Basavaraj Patil [mailto:[email-masked]]
> >> Sent: Thursday, April 20, 2006 11:52 PM
> >> To: Tsirtsis, George; [email-masked]
> >> Inline:
> >> On 4/20/06 5:28 PM, "ext Tsirtsis, George" <[email-masked]>
> > wrote:
> >>
> >>> 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.
> >>
> >> 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.
> >>
> >>>
> >>> 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.
> >>
> >> 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.
> >>
> >>>
> >>> Think of it this way:
> >>>
> >>> - DS-MIPv4 extensions will ease transition to IPv6 for networks
that
> > are
> >>> 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.
> >>
> >>>
> >>> - DS-MIPv6 will allow green field IPv6 deployments to happen while
> >>> providing access to the IPv4 Internet.
> >>
> >> True.
> >>
> >>>
> >>> George
> >>
> >> -Raj
> >>
> >>>
> >>>> From: Basavaraj Patil [mailto:[email-masked]]
> >>>> Sent: Thursday, April 20, 2006 6:18 PM
> >>>> To: Tsirtsis, George; [email-masked]
> >>>> 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
> >>>>>>>> Based on the discussion during the WG meeting we are
requesting
> >>>>> for
> > during
IPv4
> >>>>>>>> [MIPv4] protocol. The extensions allow a dual stack node to
use
> >>>>> IPv4
> > message
> >>>>> to
the
> >>>>> body
> >>>>>>>> Internet-Drafts are also available by anonymous FTP. Login
with
> >>>>> the
> >>>>>>>> username
> >>>>>>>> "anonymous" and a password of your e-mail address. After
> > logging
> >>>>> in,
> >>>>>>>      Charter page:
> >>>>> http://www.ietf.org/html.charters/mip4-charter.html
> >>>>>> "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."
> >>>>>      Charter page:
> >>> http://www.ietf.org/html.charters/mip4-charter.html
> >>>      Charter page:
> > http://www.ietf.org/html.charters/mip4-charter.html

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 25 Apr 2006 16:30:11 -0700

I am in fact interested in applying this to operator networks but there
are many different scenarios this applies to. The mechanism is the same
and it is generic, as it should be. 

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Tuesday, April 25, 2006 6:45 PM
> To: Henrik Levkowetz
> Cc: [email-masked]
> Henrik Levkowetz wrote:
> > Hi Vijay,
> > on 2006-04-25 23:30 Vijay Devarapalli said the following:
> >> Henrik Levkowetz wrote:
> >>
> >>>> 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.
> >>> 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.
> >> I was under the impression that we are talking
> >> about MIPv4 inside an enterprise network and
> >> carrying IPv6 over MIPv4 inside the enterprise
> >> networks.
> >
> > 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.
> 
> 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
> 
> 
> --