Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Jul 2003 11:23:48 +0200

... A dual stack
   mobile in a v4 only foreign network would then be able to create a v4&v6
   over v4 (forward and reverse) tunnel with its HA and thus maintain all its
   connectivity.
   
=> as a cross-version tunnel will never be "optimized" (i.e., MN-CN direct
communication is not possible), IMHO mobile-ip solutions are clearly
overkilling in this kind of environments: a smart "road warrior" IPsec
VPN will be enough. Today two parts are missing:
 - cross-version IPsec tunnels are not commonly available (note for
   IPsec implementors: they are specified in RFC 2401, why do you not
   support them?)
 - a peer address (aka care-of address here) update mechanism is needed
   to make hand-off support more efficient.
I don't consider the side-effect to get communications protected on
the wireless section as bad (:-).

Thanks

[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Aug 2003 16:47:27 +0300 (EEST)

Sorry for a late reply..

On Thu, 31 Jul 2003, Tsirtsis George wrote:
> I am not sure where Mipv6/Ipv6/Mipv4/IPv4 comes from in your e-mail and I am
> not even sure what it means. MIPv4 and MIPv6 are signaling protocols....and
> do not introduce overhead in the data path.

That is incorrect.  MIPv6 and MIPv4 do introduce a data path overhead, in 
the form of the inclusion of IP-in-IP encapsulation, Routing headers and 
Home Address options (etc.).  I think this is what Alain was referring to.

> We can always complicate things but why not deal with the simple and by far
> most important issue.
> 
> Today Mobile IP signals HoA to CoA bindings of the same version resulting in
> either IPv4 over IPv4 encapsulation or IPv6 over IPv6 encapsulation.
> 
> All I am suggesting is that Mobile IP should be able to signal HoA to CoA
> bindings of different versions so that IPv4 over IPv6 encapsulation or IPv4
> over IPv6 encapsulation is also possible.

And what benefit, exactly, would the change in encapsulation have?  The 
Home Agents and the nodes would still have to support both versions, you 
would just end up with two Mobile IP protocols which (to some extent) 
supported both IPv4 and IPv6.

Looking briefly at the conclusions section gives me an impression you want
a transport-protocol independent MobileIP++ that's agnostic of IPv4 or
IPv6, with an understanding that you would not have to solve the problem
of the direct communication between IPv6-only and IPv4-only nodes.

It seems like HIP fits the bill quite nicely, and would be architecturally 
better approach than trying to glue MIPv4 and MIPv6 together somehow.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Tsirtsis George <[email-masked]>
Date: Tue, 5 Aug 2003 11:10:44 -0400

Inline...

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2003 9:47 AM
To: Tsirtsis George
Cc: 'Alain Durand'; Mobile-Ip ([email-masked]);
[email-masked]
Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0
0.txt

...

> We can always complicate things but why not deal with the simple and 
> by far most important issue.
> 
> Today Mobile IP signals HoA to CoA bindings of the same version 
> resulting in either IPv4 over IPv4 encapsulation or IPv6 over IPv6 
> encapsulation.
> 
> All I am suggesting is that Mobile IP should be able to signal HoA to 
> CoA bindings of different versions so that IPv4 over IPv6 
> encapsulation or IPv4 over IPv6 encapsulation is also possible.

GT> Running IPv6 over MIPv4 today means that you need to somehow encapsulate
IPv6 over the existing IPv4 over IPv4 tunnel created by MIPv4 i.e.: double
tunnel. With the suggested approach MIPv4 is itself able to create IPv6 over
IPv4 tunnels as well as IPv4 over IPv4 tunnels i.e.: single tunneling. And
yes, if we extend both MIPv4 and MIPv6 with dual stack extensions then we
will have two protocols but a network or a mobile can choose to utilize only
one of the two which will take it long way towards ubiquitous connectivity.

Looking briefly at the conclusions section gives me an impression you want a
transport-protocol independent MobileIP++ that's agnostic of IPv4 or IPv6,
with an understanding that you would not have to solve the problem of the
direct communication between IPv6-only and IPv4-only nodes.

GT> I am clearly not suggesting transport independency since I am basing the
extension on transport dependant MIPv4 and MIPv6. I am merely suggesting
that these transport dependant protocols should be able to set up  version
independent tunnels

GT>...with the addition that I view this as an *evolutionary* approach. The
extensions I am talking about are suitable for networks that already utilize
or want to utilize MIP (v4 or v6) for mobility management. 

GT> With respect, HIP has a long way to go before it becomes real and in any
case I have never seen how HIP is going to solve the mobility management
problem...if it does fantastic and the market I am sure will look at this
when it becomes available...in the mean time people are deploying Mobile IP.

Regards
George

---

From: Soliman Hesham <[email-masked]>
Date: Wed, 13 Aug 2003 22:05:31 -0400

I've cut the first parts of the email because
I'm hoping that my answer below will address
the earlier comments.

>> => I'm really confused. This is the problem we are trying to
>> solve! I thought you said it's not the biggest worry. How can
>> you get IPv6 services when you don't have an IPv6 address and you're
>> mobile...?

>What I basically said was, "if you don't even have IPv6 connectivity, IPv6 
>session survivability is not your biggest worry".

=> By default, if you have an IPv6 home address then you _do_
have IPv6 connectivity unless you cannot reach the HA. If this 
happens you lose connectivity and session survivability. 

>We agree that enabling v6 is the most important thing to do first.

>But I guess the question is, "how?".

>As I understood your description, you wanted to use MIPv6 signalling to 
>set up an IPv6-in-IPv4 tunnel to enable that IPv6 connectivity.

=> This is one of the solutions we're about to publish. 
You could also use MIPv4 to setup an IPv6 in an IPv4 tunnel.
This is another solution that we're publishing.
I get the impression that you've made "intelligent guesses"
about what solutions we want to do and based on these guesses
you have decided that this problem is not worth solving. 
The reason that we published a problem statement
was that we wanted to see whether people agree and understand
the problem. Discussing solutions is another step.
So do you agree/understand the problem independently of the 
solution that you think we might propose? 

>My view is that you can enable the same using e.g. 6to4 or some other 
>mechanisms, _independent_ of any mobility management.

=> And my (persistent) question is: how?

>Now, assume that one is using MIPv_4_ to enable mobility management for 
>IPv4.  If 6to4 or such is used on top of that mobility-managed IP address, 
>we don't actually have to do anything MIPv6-wise when we move, as the IPv4 
>address stays the same.

=> Do you mean 6-to-4 in the home network or in the visited
network? Obviously we cannot expect anything from the visited
network. If 6-to-4 is in the home network what does that buy
us? How does the MN receive traffic in the visited network
and send in the reverse direction?

Of course, as I'm sure you know, 6-to-4 is not intended
to be used for end hosts (i.e. a separate v4 address for 
each host).

>Then we've reduced the problem back to plain old regular MIPv6. :-)

=> I don't understand :( Please elaborate, what does MIPv6 have to
do with your proposal?  

>>  >  - transition for _how long_?
>> 
>> => Not sure why this question is relevant. I think trying to
>> answer this is an exercise in futility. At least we never
>> had an answer for it so far. Why is this needed?

>Because we're trying to think what's the right thing to do (also in the
>longer term), not just what works (or could be made to work :-).

=> I don't see why :
1. You assume that I'm not thinking the same way
2. You think that such thinking requires us to know
how long the transition will take.

If we need to do a clean job then we just do it. Assuming
that we know when a solution will stop being deployed
and making design shortcuts based on that is a really 
bad idea IMHO. There is no point in figuring out what
the future holds. 

>That's one reason why e.g. IAB has required UNSAF considerations sections 
>(including e.g. the sunset strategy) in NAT traversal mechanism proposals.

=> I bet the IAB thought this was a short term solution
as well :/. People might have also thought that NATs were a short
term solution and that they'll go away when IPv6 is 
in DS :( 
 
>I.e., if a hack has a very limited applicability and lifetime, it might be 
>much easier to accept it; 

=> Again I don't know who proposed a hack. Also see my 
comment above about the hack's lifetime. 

Hesham

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 14 Aug 2003 23:27:03 -0400

there is not point of even worrying about Mobile IPv4 it will not be
widely deployed and the market will wait for Mobile IPv6 is my view.
also the address space limitation of IPv4 will prevent MObile IPv4 and
with NAT it simply will not work.

/jim

> From: Tsirtsis George [mailto:[email-masked]] 
> Sent: Tuesday, August 05, 2003 11:11 AM
> To: 'Pekka Savola'
> Cc: 'Alain Durand'; Mobile-Ip 
> ([email-masked]); [email-masked]
> Subject: RE: [mobile-ip] Re: FW: I-D 
> ACTION:draft-tsirtsis-dsmip-problem-0 0.txt
> 
> 
> Inline...
> 
> Cc: 'Alain Durand'; Mobile-Ip 
> ([email-masked]); [email-masked]
> GT> Running IPv6 over MIPv4 today means that you need to somehow 
> GT> encapsulate
> IPv6 over the existing IPv4 over IPv4 tunnel created by MIPv4 
> i.e.: double tunnel. With the suggested approach MIPv4 is 
> itself able to create IPv6 over IPv4 tunnels as well as IPv4 
> over IPv4 tunnels i.e.: single tunneling. And yes, if we 
> extend both MIPv4 and MIPv6 with dual stack extensions then 
> we will have two protocols but a network or a mobile can 
> choose to utilize only one of the two which will take it long 
> way towards ubiquitous connectivity.
> 
> Looking briefly at the conclusions section gives me an 
> impression you want a transport-protocol independent 
> MobileIP++ that's agnostic of IPv4 or IPv6, with an 
> understanding that you would not have to solve the problem of 
> the direct communication between IPv6-only and IPv4-only nodes.
> 
> GT> I am clearly not suggesting transport independency since 
> I am basing 
> GT> the
> extension on transport dependant MIPv4 and MIPv6. I am merely 
> suggesting that these transport dependant protocols should be 
> able to set up  version independent tunnels
> 
> GT>...with the addition that I view this as an *evolutionary* 
> approach. 
> GT>The
> extensions I am talking about are suitable for networks that 
> already utilize or want to utilize MIP (v4 or v6) for 
> mobility management. 
> 
> GT> With respect, HIP has a long way to go before it becomes 
> real and in 
> GT> any
> case I have never seen how HIP is going to solve the mobility 
> management problem...if it does fantastic and the market I am 
> sure will look at this when it becomes available...in the 
> mean time people are deploying Mobile IP.
> 
> Regards
> George
> 
>

---

From: Soliman Hesham <[email-masked]>
Date: Mon, 25 Aug 2003 08:50:45 -0400

> On Mon, 25 Aug 2003, Soliman Hesham wrote:
 > >  > >  > So, it seems pretty reasonable to expect many (most?) 
 > >  > > 
 > >  > > => More like "none" than "most". Even if they implement
 > >  > > it, the encapsulation is normally done in the FA otherwise
 > >  > > the local domain's ingress filter will drop the packets.
 > >  > 
 > >  > Have you even ever deployed MIPv4?  MN would encapsulate 
 > >  > packets using its
 > >  > care-of address, and local domain's ingress filter would 
 > >  > certainly NOT
 > >  > drop those packets.  Or what are you referring to?
 > > 
 > > => Have you read RFC 3220? 
 > 
 > No.

=> Then it's more productive to delay this discussion till you
do. 

 > 
 > > Which CoA are you referring to?
 > > When you have an FA (almost always) the MN doesn't get a 
 > > colocated CoA. Please read 3220.
 > 
 > I'm referring to the local address (obtained e.g. through 
 > DHCP) configured 
 > on the mobile node, whether given by FA or not.

=> When you read the RFC you will see that if an FA exists
and is used as a CoA by the MN there is NO COA from DHCP.
The rest of the comments below do not apply to MIPv4 as we 
know it in 3220 unless you have colocated CoAs. I have yet to
see any serious deployment/standards (3GPP2, 3GPP, our (Flarion) young
cellular link layer ...etc) that deploys MIP without an FA.
I don't know where you refer to by "here" below.

Hesham

 > 
 > That seems to be the only reasonable way to deploy Mobile 
 > IP, as you can't
 > be sure that the hosts implement or enable Mobile IP (so you 
 > will have to
 > provide DHCP service giving local addresses), and you can't 
 > be sure the
 > routers implement Mobile IP (so the hosts have to be able to reverse
 > tunnel back to HA).
 > 
 > That's how Mobile IP is deployed here, and works.
 > 
 > You probably have some specific specialized networks in mind.
 > 
 > --