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

[Pekka Savola <pekkas@netcore.fi>]

On Sat, 9 Aug 2003, Soliman Hesham wrote:
>  > > => 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.

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

>  > > => 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 it be beneficial if we could avoid Yet Another Endless 
Transition? :-)

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

There seem to be two issues here, enabling IPv6 access and enabling smooth
roaming with IPv4/IPv6 mobile-Ip environment.  See below for more.
 
>  > >  > 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...?

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

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

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