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

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

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

=> No probs, I can do with more time ;) 

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

=> sure, and the reason I twisted it is this: While your
statement above is correct, it is not a reality and will not
be for a very long time (I mean the part about IPv6 CoA) as 
far as mobile nodes are concerned. Obviously this is due to
the fact that mobiles can be basically anywhere. Therefore, 
the only IPv6 address that a MN is sure exists everywhere
is its home address. So I suppose I assumed all that when
I made the statement above.


 > 
 > By changing the typical assumptions around, you build a case 
 > on top of 
 > HA-centralized IPv6 connectivity.  

=> Correct, this is intentional for MNs because you cannot
assume otherwise.

IPv6 connectivity is 
 > independent of the 
 > HA.

=> Correct as a general statement, but not completely correct for 
MNs.

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

=> What does it take for a problem to be worth solving?
George and I think it's worth solving because of the 
problems listed in the draft. If you try to deploy 
MNs on a large scale, using a wireless network, the 
problems in the draft become quite serious. There
are two ways to avoid them with current standards:

- Avoid IPv6 deployment
- Move to IPv6-only networks

The latter is not going to happen this decade. I'm
sure we don't want the first bullet to happen either.

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

=> Solutions are the next step, I get the feeling that
you don't think it's a worthwhile problem. 
Perhaps others can shed more light on this better than 
I can.

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

=> I'm happy to help. If you can pick on specific sections
in the problem statement draft that might help us 
move forward.

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

=> Sure it can...see below though.

 > 
 > Then, when the node moves and executes IPv4 mobility management, the
 > network where HADDR_v4 is routed automatically changes with it 

=> Now... this is not clear. HADDR_v4 belongs to the home link.
If the MN generates a 6-to-4 address then an IPv6 node contacted
it using that address after the MN has left the home network, how
does the HA forward those IPv6 packets to the MN? 
The same goes for traffic sent from the MN using 2002:HADDR_v4::/48. 

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

=> You could replace 2002:.... with any other prefix because as 
I explained above it doesn't do anything for us. It doesn't setup
a tunnel between the MN and the HA in any way.

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.

=> But we're talking about *_mobile_* nodes. A configured tunnel
is not useful. 
if you're saying that you could have a configured tunnel inside
the HA to tunnel IPv6 to the MN's IPv4 _home_ address which then
gets tunneled to the MN's IPv4 care-of address (the MIP part)
then yes this is possible and it is explained in the draft
that George announced on the list. But there is a more 
BW effifcient scenario that would require some assistance 
from the FA. Both options are explained in the solutions
draft (MIPv4 one) that George sent to the MIP mailing list.

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

=> This is a binary transition mechanism :) 
You're basically saying that "today V4 is used, tomorrow
we will have dual stack networks and we can retire MIPv4."
Hmmm...not that simple unfortunately because there is more
than one network and there is a different "tomorrow" for each
of those networks. So what is going to happen is that we will
have v4-only and dual stack networks at the same time. 

Also, we can't just "retire" MIPv4 unless there is a flag
day. So we can phase it out. From the two solutions drafts
that we have (second one coming soon), you could conclude
that we assumed the following scenario:

1. Use MIPv4 (present)
2. Extended MIPv4 to allow for IPv6 home address (near future)
3. Extended MIPv6 to allow for v4 home addresses (future)

2) and 3) can coexist (i.e. in different MNs). 
That's a more likely transition IMHO. 


 > > 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?").

=> I'm not assuming that a hack is being proposed.

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

=> I'm not going to anticipate how long a solution will last
because I know that people who do that are usually wrong.
So, if you want to answer those questions I think you
should say what is "short term problem", "long term problem", 
"short term fixes" and  "long term fixes". 
I think this is a can of worms.... I don't think we'll go anywhere
trying to answer those questions. Worse, we won't 
get consensus on those definitions (just call it a hunch ;) ).


Hesham