Subject: [mobile-ip] RE: Comments on draft-tsirtsis-dsmip-problem-01.txt

From: Soliman Hesham <[email-masked]>
Date: Sun, 24 Aug 2003 09:00:06 -0400

Pekka, 

Thanks for the specific commments. Answers below
(I don't have comments on the ommitted text):

 > 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 can't argue against any of the points above...too vague
for me. I'll answer the specific comments below

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

=> And what is the fundamental reason for having those 2??
See draft-soliman-v4v6-mipv6 for example

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

=> That's news to me. How do you describe the relationship between
the MN and the HA? What is the relationship between the 
MN and CN in MIPv6? 
I remember a couple of years ago draft-nordmark-foresight..
proposed that IP in IP is used between the MN and CN instead
of the current spec, no technical opposition was given.
So what do you call it if it's not setting up tunnels?

 > If you wanted a tunnel setup protocol, you would not need 
 > MIP in the first 
 > place, just dynamic VPN mechanism.

=> Like what ?? MIP sets up tunnels dynamically between the 
MN and HA (v4 and v6) and any-to-any (MIPv6 RO). 

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

=> So because it was designed like that from the start
you are arguing that it's not analogous? The only difference
here is foresight on the SIP designers' behalf and the ease
of doing so on the application layer.

I wish we had that foresight in MIPv6, it would have saved
us arguing about it now.

    As I stated, 
 > if we want to 
 > do it, something like HIP is possible a right direction (not 
 > necessarily 

=> I'm confused, so you do agree that one protocol can do the job?

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

=> But we argue that you don't need both MIPv4 and MIPv6.

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

=> Yes it is, different WG. But clearly there are no 
significant performance issues here compared to mobility.

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

=> Finding analogies does not mean that there is no 
problem and doesn't tell me whethere you agree/understand
that there are problems and how serious.

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

=> Tough for v6 I suppose...
Who said _any_ new configuration is not acceptable?  
We are saying that there are significant performance
and service quality issues involved. And the only 
answer I'm getting from you is a dismissive 
"not a significant problem". Even if that's your opinion
I don't know what scale is used to decide what is significant
and what's not. In the cases I'm talking about these performance
and service quality problems are very significant by a wireless
operator's standard.

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

=> Which implementations ?? Have you seen commercial MIPv4 running
on windows? how widely deployed is it? 

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

=> You have not shown that at all. the solution you showed:

- Lacks Bidirectionality (6-to-4). 
- BW inefficient
- Only runs with MIPv4 (or at least you didn't explain it
for MIPv6). 

Hesham

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Aug 2003 17:57:26 +0300 (EEST)

> => And what is the fundamental reason for having those 2??

Probably that MIPv4 was developed before they could seriously consider 
IPv6?

If we were designing Mobile IP *today*, we'd probably intergrate the two 
versions somehow.   But we aren't, what's done is done.  The possiblity 
that if we would now design it differently doesn't automatically mean that 
it would be useful to to try to enhance the two protocols or re-engineer 
them to work together.

> the MN and the HA? 

An IPsec tunnel.

> What is the relationship between the 
> MN and CN in MIPv6? 

Direct communication between two nodes (sharing the same IP protocol), if
route optimization is used.

[...]
> So what do you call it if it's not setting up tunnels?

Maybe "method for enabling connection survivability for the IP protocol".

> I remember a couple of years ago draft-nordmark-foresight..

(it was hindsight, a year or so ago)

> of the current spec, no technical opposition was given.

I do not think it was reviewed that much (I don't recall many comments), 
but as your remember, it was _hindsight_.  If we could go back to when 
Mobile IP(v6) was designed, we could certainly do things differently but 
that doesn't mean we should (r)evolve Mobile IP to the same outcome as it 
would be if we designed it from scratch.

> MN and HA (v4 and v6) and any-to-any (MIPv6 RO). 

If you just wanted MN<->HA communication, all you would need is a VPN 
which updates your care-of address to the HA regularly.  RO is the thing 
that sets it apart.  I would not call MIPv6 RO a tunnel, and it is not 
parcticularly useful in this context as the transport is heavily 
IPv6-specific.

> of doing so on the application layer.

Yes, we don't have two entirely differently specified protocols, SIPv4 and 
SIPv6 which we would like to merge to some extent.

Note that it's just not about the address family used, the differences in 
the design and the details are significantly different with MIPv4 and 
MIPv6.
 
> I wish we had that foresight in MIPv6, it would have saved

That would not be enough, we'd then be arguing about MIPv4 -- we would 
have needed the foresight with MIPv4 too :-)

> => I'm confused, so you do agree that one protocol can do the job?

One protocol, designed from scratch, could do the job.

> => But we argue that you don't need both MIPv4 and MIPv6.

Yep, but another argument might be that it would be  better to have them 
separate because they were designed to be two separate protocols, and 
that they are in fact quite different.

> significant performance issues here compared to mobility.

We were discussing menagement and operations here, and I fail to see the 
difference in this specific case.

> => Tough for v6 I suppose...

Sure, that's probably an indicator that they do not care about v6 all that
much in the first place.

> "not a significant problem". 

You do not seem to spell out those problems clearly in the problem 
statement.

> on windows? how widely deployed is it? 

Right.  That's the other point: if there has been no interest to implement 
and deploy MIPv4, why should we care to add the support in MIPv6?  Isn't 
this a clear indication that a) MIPv4 isn't sufficiently deployed to be 
worth implementing in the majority systems, b) MIPv4 may be technically 
flawed to be interesting (FA requirements) for general deployment, and c) 
MIPv6 may be the much better direction all-in-all?

IMHO, this seems to just prove that there is no MIPv4 deployment except 
perhaps in very restricted scenarios w/ very small set of hosts.  And why 
then MIPv6 would have to care?

> - Lacks Bidirectionality (6-to-4). 

By adding 6to4 on HA, you should be able to obtain that.

> - BW inefficient

Just one tradeoff, it's a transition mechanism after all.

> - Only runs with MIPv4 (or at least you didn't explain it

I'm not sure if I understood your point.  Did you mean that I didn't
describe how to enable MIPv4 mobility in an IPv6-only network?  Seems like
a non-problem to me, due to how IPv6 is deployed (nodes that don't cope
with MIPv6 are retired before IPv6-only networks are deployed).

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