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

[Pekka Savola <pekkas@netcore.fi>]

Sorry for the delay in responding, there was a load of work piling, 
(and I'm not sure it's getting much lower.. :-)

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

True, but you write this the other way than it's normally written, that 
is:

By default, if you have a working IPv6 care-of address, you have IPv6
connectivity.  If you can reach the HA, you also have session
survivability.

By changing the typical assumptions around, you build a case on top of 
HA-centralized IPv6 connectivity.  IPv6 connectivity is independent of the 
HA.
 
> >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. 

Possibly partially, yes.

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

Let's see.

I think I can see why some people see these issues as problems.  However,
I can't see why some people see these as really important issues,
requiring changes.

However, I do not think there is sufficient justification in the document 
why those are problems _worth_ solving, or how big problems they actually 
are (even small problems could be used to justify work).

For example, how do we evaluate the solutions whether they are justified
to solve the perceived problems?

I guess I don't understand the problem, then.

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

Please see below, I think I've managed to answer this.
 
> >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?

I'm not sure if I understand your question.  Assume the node uses MIPv4,
and has a configured home IPv4 address HADDR_v4.  Why couldn't it just
start (e.g.) 6to4 using that address, generating the prefix
2002:HADDR_v4::/48 and use an address from there?

Then, when the node moves and executes IPv4 mobility management, the
network where HADDR_v4 is routed automatically changes with it -- and
2002:HADDR_v4::/48 stays the same.  There is no need to run any IPv6
mobility management protocol at all.

The node need not have any _IPv6_ care-of addresses at all.  Hey, it's you 
who want simplicity, not me! :-)

Obviously, you could just replace 6to4 and 2002:HADDR_v4 with any 
(configured) IPv6-over-IPv4 tunneling mechanism whose end-point is 
HADDR_v4 -- and again it would be "sticky" and you would have to do 
nothing at all.
 
> 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).

Nothing prevents that, but that's not the point here.
 
> >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?  

What I'm saying (badly, sorry -- took me while to figure out what I meant
:-) that we can reduce the the problem, with above to the case where we
have to figure out whether we want to run MIPv6 or not.  It may not be
necessary, but would be beneficial in some cases.

Beneficial where? I guess I can think of one.

When native IPv6 is available in the visited networks so you wouldn't have
to do the extra IPv4 mobility roundtrip home (which may or may not be a
problem) -- but isn't this whole point about networks where MIPv4 is
deployed and NOT IPv6?  It seems to me that when IPv6 would be deployed in
those networks, you could retire MIPv4 -- and problem solved ! :-)
 
> >>  >  - 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

Different people often think differently, especially if there is no 
dialogue to try to share the views :-)

> 2. You think that such thinking requires us to know
> how long the transition will take.

I think, yes -- a ballpark figure would be quite useful.  The worse the 
hack one is proposing, the bigger the need is to consider ("how long do we 
have to live with this?").
 
> 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. 

I'm not sure what you're referring to, but IMHO we should try to avoid
doing EITHER:

 1) short-term fixes to solve long-term problems, or
 2) long-term fixes to solve short-term problems.

2) is probably even worse (and what I'm fearing here), because if we come 
across with 1), and the fix proves to be too short-term, we can just try 
again.  This of course has its pitfalls too.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings