Subject: RE: [Mip6] review of draft-ietf-mip6-dsmip-problem-00.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 13 Oct 2005 18:15:00 -0400

Jari, 

Thanks for the detailed review. Some responses inline:

 > I reviewed this draft. Overall, its pretty easy to agree
 > with what is said. My main concern is that the draft is taking a
 > relatively narrow view into this problem. For instance, its 
 > likely that
 > we need NATs, corporate VPN compatibility, various extra
 > mobility features developed over the years, etc. as well
 > as basic mobility. How do we achieve this? And I don't think
 > the real issue is minor differences in amount of signaling,
 > even if us researchers and engineers would like to optimize
 > everything... the real issue is getting a mobility solution
 > that works, no matter what environment you are in.
 > I don't mean that we necessarily need to develop everything
 > right now, but I'd like to see a description of the whole
 > problem, and some ideas about how we are going about
 > addressing it.

=> I like the general tone of what you're saying but it's not 
clear to me how to incorporate this type of comment in the draft. 
Let me give some context first. This statement is intended to 
be narrow in terms of the types of problems encountered. draft-larsson
(which you refer to below) provides a very detailed and solid analysis
of all potential issues of incompatibility for almost all permutations
of MIPv4 and MIPv6. Of course not all those scenarios are relevant
in the real world. So, we decided to focus on the most important
scenarios. Bearing in mind that we are only extending the current
MIP specs. So the idea is that in such a way of working, the dependency
is on the latest MIP protocol. If there is a problem when dealing 
with VPNs/NATs ...etc and MIP, then this should be done at the 
root of the dependency tree. At the same time, if the solutions to
the problems outlined in the draft introduce new problems for 
VPNs/NATs....etc then this should be resolved at the new leaf of
the dependency tree (i.e. if those problems are specific to the 
new solution). 

There is evidence for both cases today; for example MIP4 did some
work on NAT traversal independently of the MIP4/MIP6 incompatibilities. 
So this was done at the root of the dependency tree. On the other hand, 
the solution we're working on now for MIP6 includes NAT traversal, because
it is specific to the problem we're dealing with and is not a general
issue for MIP6. I hope this gives more context to the discussion.

 > More comments below:
 > 
 > >    This draft discusses the issues associated with 
 > mobility management
 > >    for dual stack mobile nodes. Currently, two mobility management
 > >    protocols are defined for IPv4 and IPv6. Deploying both 
 > in a dual
 > >    stack mobile node introduces a number of inefficiencies
 > 
 > I do not think this is just about ineffiency! We have no connectivity
 > or at least session survivability without some form of interworking
 > between different mobility mechanisms.

=> Well, in some cases it's an inefficiency problem, but in other 
cases (like tunnelling IPv4 in IPv6 on the fly) it's a problem of 
no connectivity. I think we should reword this paragraph to reflect
that. 

 > > 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, to me, is the main problem in fact. 

=> I can't resist a comment on this :) To some people (George
and myself included) running MIP6 and MIP4 in parallel is almost equally bad.
I'm saying this because I think it's important for us to think
about MIP as a local mobility solution as well as a global mobility
one. 

    If you assume you have
 > v4 and v6 everywhere, why not just use Mobile IPv6? But the
 > reality is that we'll find ourselves more or less forever locked
 > in a situation where there are at least some networks that
 > are v4 only. From a commercial standpoint, we do not want
 > to deploy technology that only works some of the time, so I think
 > people are looking for solutions that work in all cases.
 > And "work" = "works for the user's ongoing sessions", not
 > just "we can send mobility protocol signaling messages".

=> Agreed.

 > 
 > >    - it should be possible to create IPv4 extensions to 
 > Mobile IPv6 so
 > >    that a dual stack mobile node can register its IPv4 and 
 > IPv6 HoAs to
 > >    a dual stack Home Agent using MIPv6 signaling only.
 > 
 > >    - it should be possible to create IPv6 extensions to 
 > MIPv4 so that a
 > >    dual stack mobile node can register its IPv4 and IPv6 
 > HoAs to a dual
 > >    stack Home Agent using MIPv4 signaling only.
 > 
 > >    - it should also be possible to extend MIPv4 and MIPv6 so that a
 > >    mobile can register a single CoA (IPv4 or IPv6) to 
 > which IPv4 and/or
 > >    IPv6 packets can be diverted to.
 > 
 > Yes. These are all things that we should do, I think.
 > 
 > But this list is also quite short in comparison to what
 > has been documented elsewhere, e.g., 
 > draft-larsson-v6ops-mip-scenarios.
 > E.g. transition mechanism-based approaches have not been
 > mentioned.

=> Right, intentionally. The assumption is that we can
reference draft-larsson for the entire study. I'm hoping
that draft-larsson is going to be published soon. I talked
to Henrik about this and he's going to pursue that option.

 > 
 > Also, there's a body of work that relates to various kinds
 > of additions over the basic protocols. It would be interesting
 > to understand the bigger picture of how we are going to
 > use the additional components (RO, fast handovers, various
 > auth schemes, ...) in a mixed environment.

=> Agreed. We can elaborate on that. Personally, after looking at 
this for some time, I find it difficult to do this with FMIP
alone. Also, RO is obviously out of the question for IPv4 - IPv4
communication. But I agree it should be detailed a bit more.

 > 
 > > 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.
 > 
 > Duplicate user credentials are a possibility at this time
 > (e.g. MIPv4 shared secrets, MIP6 auth option, MIPv6 IKE/IPsec
 > SAs or keys, IKEv2-based EAP credentials, ...). Probably 
 > worthwhile to
 > mention as a separate item.

=> Agreed.

 > 
 > > 4. References
 > 
 > References to other work in this space might be appropriate.
 > Can't give you a good list, but I'm sure there are some items
 > that could be mentioned here. In fact, even the existing references
 > in the text such as [MIPv4] are not listed here.

=> Sure, sloppy writing. We'll fix that. 

Hesham

 > 
 > --Jari
 > 
 > 
 > _______________________________________________
 > Mip6 mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/mip6
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 14:14:45 +0200

Hello Hesham, I have the draft too, please allow me to interfere below.

Soliman, Hesham wrote:
>>> 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.
>> 
> => I can't resist a comment on this :) To some people (George and
> myself included) running MIP6 and MIP4 in parallel is almost equally
> bad.

To me, running both MIP6 and MIP4 simultaneously on the MN is no bad.
It is no worse than running both the IPv4 stack and the IPv6 stack.

If we can't imagine a future where all nodes are exclusively IPv6 we
can't imagine a future where all nodes are exclusively MIP6 either, IMHO.

Alex