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

[Pekka Savola <pekkas@netcore.fi>]

Note, I don't think continuing this thread is likely going to be 
productive, so this is probably my last message on this subject.

On Sun, 24 Aug 2003, Soliman Hesham wrote:
>  > >  > ==> 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?
> 
> => In other words there is no fundamental reason.

Well, I'm not sure what you'd call a fundamental reason, but different 
protocol design seems like one to me.

>  > 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.
> 
> => Are these comments in the context of the two drafts
> or in general? I think they can be extended with very 
> little work as we showed in the drafts. Others might 
> have even simpler ways.

In general.

>  > >  > ==> 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.
> 
> => This is factually wrong for MIPv4 and MIPv6.
> Neither has any requirement for IPsec protection
> of the tunnel. It's an IP in IP tunnel!

MIPv4 not, MIPv6 requires it for signalling at least .. and if you MUST
have it for signalling, why not use the same for the rest?  It would seem
to be *much* simpler if it was done that way.

>  > > 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.
> 
> => Again, factually wrong. RO in MIPv6 is effectively
> a tunnelling mechanism that instead of using IP in IP, 
> uses RH and HAO to save bits. This was discussed many
> years ago and discussed again when Erik published his draft.

Nope.  If you look at RH and HAO (applied together) you note that they
don't really save bits.  There are MUCH more important points to consider,
for example, being open tunnel decapsulation points from everywhere.

>  > >  > ==> 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.
> 
> => Not as far as the MN-HA relationship is concerned. That
> part is very similar. RO is the only real difference IMO.
> RO is not impacted in our proposals.

I'm not sure what you're saying with the latter -- that your proposals 
will not enable route optimization with dual-stack MIP at all, just the 
HA-MN communication?  (i.e., doing bidirectional tunneling, that's all.)

>  > >     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.
> 
> => I think this is becoming a bit argumentative. You do
> acknowledge that one protocol can do the job and I've shown
> you examples of how to do it using either MIPv4 and MIPv6.

No, you're hacking in a part of the MIP support for the other MIP 
protocol.  That's not the same as having a solution which would natively 
support both IPv4 and IPv6 from the start.

>  > > => 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.
> 
> => This is a baseless argument though because they are not
> that different if RO for IPv4 is ignored.

Well, I see no words on this -- that you're only interested in
bidirectional tunneling between MN (or maybe FA in MIP4) and HA -- in the
problem statement.

>  > >  > ==> 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, 
> 
> => MIPv4 is widely deployed today and used by on a commercial 
> level. 

I hope I could believe that.. :-)

> My point was that there are not many implementations with 
> both MIPv4 and MIPv6. You took that to another meaning and 
> the conclusion isn't accurate.

Yes, but the question is, why there are no such implementations.  There
might be reasons for those, like the market segmentation (e.g.,
implementors don't think their product will be used in places where MIP4 
is deployed, so any MIP4-in-MIPv6 or vice versa seem irrelevant too).
  
>  > IMHO, this seems to just prove that there is no MIPv4 
>  > deployment except 
>  > perhaps in very restricted scenarios w/ very small set of 
>  > hosts.  
> 
> => Factually wrong. It is deployed on a large scale.

I guess someone's large scale could be someone else's very restricted 
scenario. :-)

>  > >  > ==> 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.
> 
> => If you have a proposal I suggest you write something 
> up; designing it on email won't work. The above suggestion
> won't work in the reverse tunnel ,I've already said that
> many times...

Unfortunately I don't see this as a serious problem and thus writing up a 
proposal like this is not all that high on my priorities list :-)

>  > > - 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? 
> 
> => No. You didn't show how MIPv6-only can be used 
> for both IPv4 and IPv6.

I'm still not sure what you're asking, but my position is that I don't see 
this as a necessity.

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