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

[Soliman Hesham <H.Soliman@flarion.com>]

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