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

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: Pekka Savola <[email-masked]>
Date: Wed, 20 Aug 2003 21:41:39 +0300 (EEST)

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

> 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.
 
> you have decided that this problem is not worth solving. 

Possibly partially, yes.

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

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

Please see below, I think I've managed to answer this.
 
> 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.
 
> to be used for end hosts (i.e. a separate v4 address for 

Nothing prevents that, but that's not the point here.
 
> => I don't understand :( Please elaborate, what does MIPv6 have to

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

> 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?").
 
> bad idea IMHO. There is no point in figuring out what

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