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

[Pekka Savola <pekkas@netcore.fi>]

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.

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