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

From: Soliman Hesham <[email-masked]>
Date: Wed, 20 Aug 2003 23:48:05 -0400

> 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

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Aug 2003 14:28:07 +0300 (EEST)

Hi,

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

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

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

Same as above.
 
>  > > solution that you think we might propose? >  > 
>  > Let's see.
>  > 

Good question :-)

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

> in the problem statement draft that might help us 

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

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

> I explained above it doesn't do anything for us. 

Yes, it fixes the problem altogether, see above.

> It doesn't setup

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. 
 
> => But we're talking about *_mobile_* nodes. A configured tunnel

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

> 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 

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

> 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

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Aug 2003 14:58:02 +0300 (EEST)

Hi,

I did a quick pass on the dsmip-problem draft.

I tried to concentrate only on a couple of specific sections.  There are a 
lot of issues in the others as well, but it isn't worth the time to argue 
about the rest at this point.

To summarize:
 - most of the problems are not important or portrayed with specific 
assumptions
 - the most important remaining issue seems to be duplicate hand-off 
signalling
 - it might be best to change this to a requirements/goals document and 
give better coverage to other features which speak against any changes 
like these
 - I think you have to spell out your assumptions more explictly
 - I think you have to consider what your aim is in more detail: do you 
want bidirectional tunneling through the HA or do you want some more 
advanced mobility as well (the latter is probably highly problematic using 
your proposals, consider e.g. return routability checks)
 - based on this, I do not think the problem statement can be taken 
seriously, and I would recommend not starting any activity based on it.

I'll just argue the problem description and it's subsections.

2.0 Problem description
 
   Mobile IP (v4 and v6) uses a signaling protocol (Registration
   requests in MIPv4 and BUs in MIPv6) to set up tunnels between two end
   points. At the moment MIP "signaling" is tightly coupled with the
   "address family (i.e. IPv4 or IPv6)" used in the connections that it
   attempts to manipulate. There are no fundamental technical reasons   
   for such coupling. 

==> the last statement is wrong.  The fundamental technical reason is that 
MIPv4 and MIPv6 are *two* different protocols.

                             If Mobile IP were viewed as a tunnel setup
   protocol, it should be able to setup IP in IP tunnels, independently 
   of the IP version used in the outer and inner headers. 

==> this is a very flawed analogy.  MIP is *not* a tunnel setup protocol.  
If you wanted a tunnel setup protocol, you would not need MIP in the first 
place, just dynamic VPN mechanism.

                                                                   Other
   protocols, for example SIP, are able to use either IPv4 or IPv6 based
   signaling plane to manipulate IPv4 AND IPv6 bearers.

==> there is a fundamental difference there.  SIP was architected *from 
the start* to deal with two protocols (AFAIK).  As I stated, if we want to 
do it, something like HIP is possible a right direction (not necessarily 
THE right direction, though).

==> A more correct analogies would be plugging H.323 interoperability to 
SIP and SIP interoperability to H.323.  Architecturally, this seems like a 
very similar approach..

   A mobile node using both Mobile IPv4 and Mobile IPv6 to roam within
   the Internet will require the following: 

   - Both implementations available in the mobile node 

==> analogy: Both IPv4 and IPv6 must be implemented in the mobile node, 
and it is a problem.

   - The network operator needs to ensure that the home agent supports
     both protocols or that it has two separate Home Agents supporting
     the two protocols, each requiring its own management.

==> analogy: The network operator must manage both DHCPv4 and stateless 
address autoconfiguration (or more closely, DHCPv6) and this is a problem.

   - Double the amount of configuration in the mobile node and the home
     agent (e.g. security associations).

==> analogy: applications must manage the access controls (like IP 
addresses, etc.) for both IPv4 and IPv6 nodes, and this is a problem.

   - Local network optimizations for handovers will also need to be
     duplicated. 

==> roughly ok, even though I don't really think it's a major problem 
myself.

==> See?  Even though the analogies are not 100% accurate, you are
describing issues inherent to dual-stack deployment (which are not
considered serious problems in general, but in all fairness, there hasn't
been much discussion on this in v6ops), and extrapolating them to be
serious Mobile IP problems which must be addressed.  Want to run both IPv4
and IPv6 but any new configuration is unacceptable? Tough.

2.1. Implementation burdens 
    
   As mentioned above, a dual stack mobile node would require both 
   mobility protocols implemented to roam seamlessly within the
   Internet. Clearly this will add implementation efforts, which we
   argue are not necessary.

==> implementations are already there; the same argument as IPv4/6 
dual-stack deployment.

2.2. Operational burdens
    
   As mentioned earlier, deploying both protocols will require managing
   both protocols in the mobile node and the home agent. This adds 
   significant operational issues for the network operator. It would
   certainly require the network operator to have deep knowledge in both
   protocols. This might add a significant cost for deployment that an  
   operator cannot justify due to the lack of substantial gains.

==> "significant" --> these certainly aren't
==> "deep knowledge" --> operators generally don't need such deep 
knowledge, the basics are enough.  The experts are another subject, but 
they already know both protocols and that's no news.

2.3. Mobility management inefficiencies 

==> I can kind of see the point in some of the issues of mobility 
management.

2.4. The impossibility of maintaining connectivity
    
   A final point to consider is that even if both mobility protocols are
   supported by a mobile node seamless connectivity would not in fact be
   guarantied since that also depends on the IPv4/IPv6 capabilities of
   the networks the mobile is visiting i.e.: a dual stack node
   attempting to connect via a IPv4 only network would not be able to   
   maintain connectivity of its IPv6 applications and vice versa. 

==> this is totally incorrect as shown many, many times; you are just 
assuming that the mobile node could not run a transition mechanism on its 
own to enable IP protocol access.