Hi Fred, I think your draft is now Rev. 44 at https://tools.ietf.org/html/draft-templin-aerolink-44
I don't really have any comments on the text. But if you have been wondering why AERO reminds people Mobile IP or Proxy Mobile IP or MOBIKE? I classify those protocols as 20th century protocols. It seems like AERO is very much like them. I think that in dmm maybe we should look into 21st century protocols. That may mean designing with new concepts like control plane/data plane separation, virtualization, as in vEPC, cloud, and SDN control. Regards, Behcet On Tue, Oct 7, 2014 at 4:20 PM, Templin, Fred L <[email protected]> wrote: > Hi Charlie, > >> -----Original Message----- >> From: Charlie Perkins [mailto:[email protected]] >> Sent: Tuesday, October 07, 2014 1:25 PM >> To: Templin, Fred L; [email protected] >> Subject: Re: [DMM] AERO and Mobile IP comparison >> >> Hello Fred, >> >> A few little follow-up questions... >> >> On 10/7/2014 11:39 AM, Templin, Fred L wrote: >> >> From: Charlie Perkins [mailto:[email protected]] >> >> >> >> ... >> >> This implies local-only mobility, right? >> > Not just local, but global also. Take for example an AERO mobile router >> > that is connecting >> > over an access link provided by some ISP other than its home network. In >> > that case, the >> > node typically remains connected to its home link by setting up a VPN >> > connection via a >> > security gateway connected to its home network. In that case, the AERO >> > link is said to >> > be extended *through* the security gateway. So, the AERO mobile router >> > remains >> > tethered to its home link via the VPN, but it can set up route >> > optimization with Internet >> > correspondents in a manner similar to MIPv6. In that case, communications >> > with the >> > Internet correspondent can bypass the home network. >> >> - Is the VPN setup part of AERO? > > The AERO Client requests a DHCPv6 Prefix Delegation as part of the VPN setup. > The > security gateway (acting as an AERO Server) delegates the prefix and sets up a > neighbor cache entry for the Client. > >> - How does the mobile router know whether or not to do this? > > The AERO Client needs to know whether it is connecting to an access link > provided by > the home network or by an ISP outside of the home network. One way of doing > this is > to examine the connection-specific DNS suffix the Client gets when it > connects to the > access link and comparing it to the home network DNS suffix. > > When I think about my laptop computer user experience, I have to perform a > manual > intervention to select a security gateway and set up the VPN when I am > connecting via > an Internet access link. That would be OK and compatible with AERO as well, > but would > be much better if it were automated. Whether it can be fully automated > depends on > what kind of security credentials are necessary to establish the VPN, e.g., > whether > certificates alone are sufficient or whether some kind of active badge needs > to be > swiped, etc. Do you know more about this? > >> - Why would the external AERO servers admit traffic from the AERO client? > > The external AERO Servers are security gateways that also delegate AERO Client > Prefixes (ACPs) to Clients using DHCPv6 PD. During PD, the Server performs an > additional layer of authentication for the Client above and beyond what is > done > for establishing the VPN. So, the Server has a way of knowing that the Client > is > permitted to source packets from the delegated ACP. > >> Or, is AERO completely out of the picture for external networks? > > External networks as in something that does not have hard perimeters with > security gateways - maybe like a university campus network? I'll have to think > more about that, but in that case there may need to be some other trust basis > besides source address verification and IPsec tunnels. Any ideas? > >> - Is the route optimization simply a matter of VPN to the correspondent >> node? > > VPN to the correspondent node (triggered by AERO mechanisms) is certainly > a use case that we don't want to rule out. > >> Or, did you mean to suggest use of the MIPv6 mechanisms? > > For communications with correspondents that do not require IPsec protection, > the mechanism is the same as the MIPv6 Return Routability, only using IPv6 > ND messaging for signaling. Otherwise, I just studied the RR procedure in > RFC6275 and pretty much borrowed what I saw there for AERO. > > Thanks - Fred > [email protected] > >> Regards, >> Charlie P. >> > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
