Subject: Re: [Mip6] On a network-mobility solution based on Mobile IPv6

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Oct 2006 00:05:14 +0300

Behcet,
> Have you read
> draft-soliman-netlmm-harmful-00.txt?
> Some people say this is an IAB quality draft.
>
> BTW I am not a member of int-area ML, so I do not know if you already
> commented on this draft in int-area. Maybe you could kindly share your
> views (possibly again) on this ML?
The discussion went on the internet area mailing list
(http://www1.ietf.org/mail-archive/web/int-area/current/mail11.html
-- feel free to subscribe!) and a few other lists as I recall.
It was largely a back and forth discussion between Hesham
and netlmm defenders, and, unsurprisingly, they did not
agree at the end. There was, however, support for the
notion that local and global mobility in can co-exist.

My own opinion? I also believe local and global mobility
management can (and should) co-exist. And I worry about
the economics of the security needed to set up lmm when
the  host is involved. (In fairness I want to say that I also keep
worrying about NETLMM's security model until I see their
mobile node interface draft in front of me.)

I have some sympathy for Hesham's arguments in Section 3.
But its not clear to me that these problems exist in the actual
NETLMM protocol, or at least not all of them. For instance,
all of the network-control related issues appear to assume
that NETLMM is in charge of handover decisions. This is
not the case in the design that the NETLMM WG is working
on; it only attempts to retain the IP environment if the mobile
node decides to use another access link. Of course, there
are L2 control mechanisms but that seems orthogonal
to whatever we do in upper layers.

Anyway, I would like to repeat my request for getting
back to the requirements and problems that we want
to solve. Are the functional or architectural requirements
that cannot be handled by existing protocols or ongoing
work?

--Jari

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 2 Oct 2006 21:19:13 -0400

Hi Stefano,

I understand the performance benefit of PMIPv6 (i.e., eliminating one
IP encapsulation at MN), but it seems that security implications of
changing the SA termination points from "HA and MN" to "HA and a set
of ARs" are quite substantial especially from key management
perspective.  I would suggest doing deep security analysis before
taking any decision on this matter.

Best regards,
Yoshihiro Ohba

On Wed, Sep 20, 2006 at 06:59:18PM -0700, Faccin, Stefano M wrote:
> Hello all,
> 
> I'm sending this e-mail to start a thread of discussion on the need and
> opportunities for a network-mobility solution based on Mobile IPv6. 
> 
> As a result of offline discussions between interested parties, we would
> like to submit the following to begin a discussion on this mailing list.
> 
> =================================================================
> Recent developments in network architectures in SDOs such as WiMAX forum
> and 3GPP2 have identified a need to support IP mobility for hosts
> without the host playing a role in managing mobility. Significant
> interest exists for a network based IP mobility solution based on Mobile
> IPv6. The choice of Mobile IPv6 as the mobility protocol for IPv6 is
> driving the need to have a solution for network based mobility that is
> also based on or derived from MIPv6. One of the key benefits that been
> identified for a network based MIP6 solution (referred to as Proxy MIP6)
> is the optimized use of the air interface resulting from no MIP6
> signaling and no tunneling of packets over the air interface.
> 
> The WiMAX network architecture currently supports Proxy MIP4 for
> enabling mobility for hosts that may not have a MIP4 client. MIPv6 has
> been adopted as the mobility solution for IPv6. There exists a
> requirement to support mobility for IPv6 hosts without having any
> explicit expectations of the host IPv6 capability. Proxy MIP6 is a
> solution that is aligned with the architectural direction of WiMAX,
> given the specification of Proxy MIP4 for IPv4 mobility and hence a
> similar approach for IPv6 mobility.
> 
> In 3GPP, there has been some degree of interest in Proxy MIPv6 as well,
> primarily in the SAE (System Architecture Evolution) work item. No
> decision or protocol choices have been made yet.
> 
> 3GPP2 has expressed some interest in pursuing a network-based IP
> mobility protocol in order to support hosts with no mobility stack
> (those that use Simple IP) to take advantage of some form of mobility
> provided by the same entities that handle host-based (MIPv6-based)
> mobility. No decision on the specific protocol has been finalized yet,
> although a network-based IP mobility solution based on MIP6 has been
> identified as a viable option.
> 
> There are several key benefits to using PMIPv6 as the network-based
> mobility management protocol: 
> - The same MIPv6 home agent can be used be used at the same time with
> little or no modifications for clients that support MIPv6 and for
> clients that don't have host mobility software and would like the
> network to handle mobility for them.
> - Re-use of supporting work that has been done for MIPv6. This includes
> the ability to establish security associations, RADIUS and Diameter
> extensions, bootstrapping, dual stack support, reliability, fail over
> and HA switching.
> 
> So we would like to propose adding a new item to the MIP6 WG charter to
> standardize proxy MIPv6. The goal of this work would be to specify a
> simple extension to MIPv6 that would support network based mobility for
> IPv6 hosts and reuses MIP6 signaling and features. It is not intended to
> be a new network-based mobility protocol solution.
> 
> A couple of I-Ds specifying network-based mobility management protocol
> derived from MIPv6 exist today and can be used as the baseline for the
> work.
> 
> In conclusion, we think that the MIP6 WG should take on this work in
> order to meet a requirement of networks that will be deployed in the
> near future.
> 
> ========================================================================
> 
> Comments are welcome.
> Stefano
>