Re: [MEXT] Rethink on Mobile IPv6

[Hesham Soliman <[e-mail]>]

Hi Raj, 

A couple of thoughts.
First, you've redefined the purpose of MIPv6 to be about setting up a tunnel
between the MN and the HA. Whether this is correct or not, it's worth noting
that your basis for such definition is unknown. It certainly doesn't match
our reference for MIPv6 (RFC 3775).

Regarding the complexity of DSMIPv6. Arnaud is 100% right in his response
and this was discussed on the mext list more times than I can remember. The
complexity is due to NAT traversal. Yes, we could have reduced the
complexity if we relied on MIP-only traversal techniques instead of having
both MIP and IPsec traversal run simultaneously, but what is the other
alternative for negotiating a security association behind a NAT?
The problem *is* NAT. I'm afraid that once you plant the seeds of hackiness
(if that's a word) by using NATs you have to harvest the output at some
point. There is no free lunch when you have a deployed base of 2 billion
users. 

I continued to suggest (for about 6 years now) that we use CGAs for MIPv6.
It's by far the cleanest solution we have. My best description to the
resistance of adopting CGAs is: Politics. There is no technical reason for
not using them and we all know that. So if you want to come up with
alternatives, you'd be doing the community a disservice if you don't
seriously consider CGAs. In fact, I'd go further and say you need to explain
why not. We've already seen what happens when we produce half cooked
security proposals tailored to a specific SDO's needs (read: RFC 4285).

I look forward to the continuation of these discussions.

Hesham


On 4/03/10 2:55 AM, "[e-mail]" <[e-mail]>
wrote:

> 
> Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack
> Mobile IPv6 (RFC5555) since 2009. Implementations of the protocol has
> been lacklustre to say the least. Several SDOs have considered MIP6
> and DSMIP6 as a solution for interworking and mobility between
> different access technologies and only 3GPP has adopted it in a very
> limited manner for Rel 8 (for use on the S2c interface) with the
> likelihood of it being actually deployed quite low (IMO).
> 
> While there are many reasons that can be attributed to the lack of
> implementations and use, one that I would like to raise is the the
> concern with the overly complex security model that MIP6/DSMIP6 relies
> on today. MIP6/DSMIP6 requires IPsec and IKE/IKEv2 (RFC3776/4877) to
> secure the signaling between the MN and HA. The fundamental purpose of
> MIP6/DSMIP6 is to provide mobility to hosts. At a very high level the
> MIP6/DSMIP6 protocol boils down to the ability to setup a tunnel
> between the MN and HA and update the MN tunnel end-point whenever
> there is a change in the associated IP address (CoA). The signaling to
> establish the tunnel needs to be secure. But using a protocol like
> IKEv2 and IPsec to achieve this security is just an overkill. It
> increases the complexity of the implementation as a result of many
> factors that have been captured in I-D:
> draft-patil-mext-mip6issueswithipsec and discussed in the MEXT WG
> meetings. 
> 
> Given the objective of the protocol is to enable IP mobility for hosts,
> it should focus on doing that well in a manner that makes it easy to
> implement/adopt/deploy/scale. My opinion as a result of implementation
> experience is that MIP6/DSMIP6 can be significantly simplified,
> especially the security architecture. The protocol as specified
> currently in RFC3775/RFC5555 is a kitchensink of features. Getting back
> to basics of simply establishing a tunnel between the MN and HA and
> managing that tunnel is all that is needed and would potentially see
> the light of day in the real world.
> 
> You may want to call it as Mobile IPv6-lite if you wish. But I do
> believe that a simplification of the protocol is needed without which
> I fear it will remain an academic exercise with many years spent in
> developing a spec. I hope the working group and people who are
> involved in mobility related work would consider undertaking such an
> effort in the IETF.
> 
> -Basavaraj
> 
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext