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

From: Soliman Hesham <[email-masked]>
Date: Sat, 9 Aug 2003 22:50:43 -0400

> > => Why not? Let's take a simple example:
 > > A dual stack node that wants to be reachable on IPv4
 > > and IPv6 addresses. It gets one v4 and one v6 home 
 > > address. If it uses both MIP versions, every time
 > > it moves it will send two separate messages to its
 > > HA. Even worse, if we try to get a decent handover performance
 > > then another two messages will need to be sent to
 > > routers in the local network. 
 > 
 > You gave a description of a case where there seems to be unnecessary
 > signalling that one could try to optimize away (using some means). My
                                                  ^^^^^^^^^^^^^^^^^^
 > feeling is that there are workarounds (operational ones, i.e. no
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 > extensions for mobility management protocols) for this non-optimized
 > signalling problem so the actual problem does not seem particularly
 > attractive.

=> if you can solve this problem operationally please elaborate.
It will be enlightning for me to see how. I.e. please elaborate on
the underlined points above. Otherwise, I woulodn't be able to
follow your conclusion.

 > 
 > Here, however, my point was not that: but rather, whether 
 > the two mobility 
 > management protocols are similar enough so that their 
 > signalling would be 
 > interchangeable or reasonably well doable with the other 
 > protocol (without 
 > significant drawbacks). 

=> And my answer is that they certainly have commonalities
but not everything done in v6 can be done in V4. So we cannot
get every feature if MIPv4 is used.

 My feeling is that this is not 
 > worth the effort.

=> I don't understand how you reach this feeling.
But then again, feelings don't have to be logical :) 

 > > => We're not trying to get the full advantage of each
 > > one, this is a transition mechanism. Just like any
 > > tunnelling mechanism will make you lose some of IPv6's
 > > feature. This mechanism is not a goal, it's a mean to short
 > > term deployment for mobile nodes. 
 > 
 > Transition to *WHAT*?  IPv6-only mobility management and 
 > IPv6 being run on
 > every subnet where a mobile node might roam to?  I suspect both;  the
 > latter could take a very long while..

=> Of course it will take time.

 > 
 > Wouldn't then it be just so much simpler to require the 
 > IPv6-capable node
 > to always use IPv6?

=> Huh? How does this help with the problem we're trying to
solve? It's not about "using v6", it's about using it
while you're moving.

 > >  > Already happens if you enable e.g. 6to4 to gain IPv6 
 > >  > connectivity.  If you 
 > >  > had IPv6 connectivity in the past, but move somewhere where 
 > >  > there is none, 
 > >  > I think surviving the connections is not your biggest worry.
 > > 
 > > => What is your biggest worry then? 
 > 
 > When IPv6-capable node uses IPv6 but moves to a subnet where 
 > IPv6 is not
 > supported, and IPv6 services are required for some purpose, 
 > it's first and
 > primary problem is re-establishing IPv6 support in that 
 > subnet, in any
 > means necessary.

=> 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...?

 > 
 > > I can't imagine a wireless
 > > operator deploying a service that works sometimes. This is
 > > a key problem to address.
 > 
 > I'm not sure of the context you're referring to, so I can't 
 > comment on
 > whether I would see this as a problem or not.  What kind of 
 > devices are we
 > talking about here?  

=> Doesn't matter, any host as defined in 2460.

  And what kind of networks?  

=> Wireless IP networks.

   Would the network
 > terminal devices be smart enough to be used (and expected to 
 > work) in the
 > Internet by themselves (e.g. laptop with a WLAN)

=> This is not the only example of a device, but yes this is one example.

 > In transition, it's good to try to figure out questions like: 
 >  - transition to _where_,
 >  - transition _how_, and

=> Agreed.

 >  - 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?

 > (for example).
 > 
 > With IPv6 (ngtrans/v6ops) we haven't always been too successful in
 > figuring that out though 
  (and I'm not saying we're 
 > necessarily enlightened
 > at the moment either :-).. :-/

=> I thought the scenarios docs were going to enlighten everyone ;) 

Hesham

---

From: Pekka Savola <[email-masked]>
Date: Wed, 13 Aug 2003 08:54:20 +0300 (EEST)

>  > signalling that one could try to optimize away (using some means). My

See below ("just run MIPv6 over MIPv4?").

> => Of course it will take time.

Wouldn't it be beneficial if we could avoid Yet Another Endless 
Transition? :-)

> solve? It's not about "using v6", it's about using it

There seem to be two issues here, enabling IPv6 access and enabling smooth
roaming with IPv4/IPv6 mobile-Ip environment.  See below for more.
 
> you get IPv6 services when you don't have an IPv6 address and you're

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

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.

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

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.

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

> 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 :-).

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.e., if a hack has a very limited applicability and lifetime, it might be 
much easier to accept it; if it's open-ended, the requirements are likely 
much stricter because we have to consider it in the context of "ok, if 
we'll specify this, we'll have to live with it for a long time..".

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