Hi Sri, > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:[email protected]] > Sent: Thursday, September 11, 2014 5:59 PM > To: Templin, Fred L; Jouni Korhonen; [email protected] > Cc: Dapeng Liu; [email protected] > Subject: Re: [DMM] DMM Interim call #2 - agenda forming > > Hi Fred, > > Thanks again for your responses. > > Lets zoom into the following two points. > > > > > > On 9/11/14 4:07 PM, "Templin, Fred L" <[email protected]> wrote: > > > > >> > >> > >> 9.) Are you aware of implementation of a Aero client on iPhone ? Can > >>Aero > >> client be implemented in today's Apple iOS device, using standard API > >> interface ? Will the Apple iOS allow an application to setup a tunnel > >>and > >> setup policy routes to steer a IP flow through that tunnel ? > > > >We have AERO Client implemented on linux in a lightweight > >user-level daemon and have it on our TODO list to port to > >Android. This is all user-level code and no kernel changes > >required. We haven't really looked at Apple iOS yet. > > > >However, our target integration goal is OpenVPN since we will > >then be able to use the same tool for AERO Client whether going > >across a VPN or non-VPN connection. I haven't checked yet, but > >if OpenVPN works on iOS, then AERO will also work on iOS when > >we get this integration done. > > > I understand, this can be realized in Android and in Linux based > platforms. However, from what I understand, the Apple's published SDK does > not allow applications to create IP tunnels and setup forwarding of IP > packets through those tunnels. Essentially, we may not be able to build a > Aero client for the currently deployed millions of iOS devices.
I'll be honest that I have not had a chance to look into iOS, but surely those devices must support some form of VPN solution - I guess OpenVPN? If an iOS phone can be made to do OpenVPN, then it can be made to do AERO. > Forget alone the tunnel part, the MIP community over the years realized > that managing a client-eco system is not trivial. In the glory days of > Microsoft window's rule, Microsoft they never integrated MIP stack in > their windows operating system and the industry struggled to see the MIP > client eco-system and eventually that forced us to look at network-based > approaches. We invested in mobility models that did not require client > support. All thought MIP flourished during the CDMA days, as Qualcom > integrated the stack into the chipset, but however operators chose a > network-based approach for 4G architectures. I don't mind talking about proxy-AERO - which should be a trivial extension of the base mechanisms. The only problem with that is that it has to exist in the access routers, and AFAICT it would be difficult to switch between different data link technologies on the fly, e.g., going from a wired LAN to WiFi, going from WiFi to 4G, going from non-VPN to VPN, etc. Do the proxy solutions talk about this? > >> >> 3.) Can the Aero solution support IP nodes that do not have Aero > >>client > >> >> stack ? > >> > > >> >Proxy AERO could be applied in the same manner as for PMIP, > >> >but the document does not fully investigate that option at > >> >this time. > >> > > > > Ok. So, the current experimental AERO RFC does not support network-based > approaches and we cannot build client for a platform with most dominant > market share. This version of AERO is far evolved from the experimental RFC. If you want it to talk about proxy AERO, then I don't mind talking about new text to add to the current draft. > Based on these points #3 and #9, can we conclude that we cannot apply AERO > for DMM ? If not, how do we apply and deploy Aero for DMM networks ? I don't think so. Surely we can do proxy AERO, and surely iOS phones can do VPN. So, pick one or both of these alternatives and I think the concern is addressed? Thanks - Fred [email protected] > > > > > Regards > Sri > > > > > > > > > > > > > > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
