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

[Pekka Savola <pekkas@netcore.fi>]

Hi,

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

Yes, you made that assumption -- and also assumed that using 
IPv6-over-IPv4 tunneling to the home agent would be the way to fix that.

This is a critical difference in our opinions, and how people think of 
operating Mobile IP.  It needs to be spelled out, even though it is not an 
DSMIP-specific issue.

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

As I've shown, you certainly can (i.e. that MNs obtain IPv6 connectivity 
independent of that HA).
 
> IPv6 connectivity is 
>  > independent of the 
>  > HA.
> 
> => Correct as a general statement, but not completely correct for 
> MNs.

Same as above.
 
>  > > 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?

Good question :-)

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

The draft lists several problems, some of which I don't agree with, some 
of which I think can be solved with other approaches, and some of which I 
agree may be potential issues but which I don't see really huge problems.

I think these separate problems have to be teased out from one big lump 
leading to your conclusion.

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

I had a closer look at parts of it, and I'll be sending some comments 
shortly.
 
>  > 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.

More to the point: HADDR_v4 is part of the home link address space.  Home 
agent proxies it for the mobile node, and the address itself is configured 
on the mobile node.

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

Easily.  Note that those are *NOT* IPv6 packets.  They're proto-41 IPv4 
packets :-).

It's double encapsulation, but hey.. it works and is trivial!

> The same goes for traffic sent from the MN using 2002:HADDR_v4::/48. 

Works equally well, as above.

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

Yes, it fixes the problem altogether, see above.

> It doesn't setup
> a tunnel between the MN and the HA in any way.

For some weird reason, you keep having this fixation that tunnel MUST BE 
between MN and the HA.  There is *NO* reason for that.  The tunnel can be 
to whatever box in the network, as long as it provides IPv6 support.

However, it could very easily be the HA too, just by being the 6to4 relay 
or the (somehow) configured tunnel's endpoint.  But that's certainly *not* 
a requirement. 
 
> 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. 

It is very useful if it's between the Home agent's IPv4 address and the 
Mobile Node's home address.  No need to reconfigure everything, always 
works if MIPv4 works, etc :-).

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

Yes, that's exactly the possibility.  It needs to go to the problem 
statement (if you keep considering there being a problem) to be taken 
seriously.

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

Bandwidth efficiency is just ONE trade-off here.  What I'd like is that
the problem statement would list all the issues so that the readers could
have better idea of the tradeoffs.

Actually, maybe the document should be called "goals" or "requirements", 
not a problem statement, because "problem statement" doesn't give enough 
coverage on other tradeoffs of finding a solution.
 
>  > 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. 

Sure, but there are multiple problems in your problem statement.  I agree 
with about one of them (to an extent :-) -- the double signalling.

It's all about tradeoffs.  As long as things work to some extent, we can 
accept a bit more overhead, a bit more unoptimized connectivity, etc. -- 
if the costs of solving those issues would have costs of its own.

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

Yes, these can be problematic :-).  But if we can restrict the problems 
somewhat, it may be easier to get a feeling about this.  First we just 
have to figure out the exact scenarios where these apply to.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings