RE: Comments on draft-tsirtsis-dsmip-problem-01.txt

[Pekka Savola <pekkas@netcore.fi>]

On Sun, 24 Aug 2003, Soliman Hesham wrote:
>  > 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??

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.

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

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)

> proposed that IP in IP is used between the MN and CN instead
> 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.

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

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.

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

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
> us arguing about it now.

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

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

One protocol, designed from scratch, could 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.

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.

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

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

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

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

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

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

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

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?

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

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

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