[Cerowrt-devel] Recording RF management info _and_ associated traffic?

Chuck Anderson cra at WPI.EDU
Sun Jan 25 10:03:06 EST 2015


On Sun, Jan 25, 2015 at 01:39:32AM -0800, David Lang wrote:
> On Sun, 25 Jan 2015, Dave Taht wrote:
> 
> >I want to make clear that I support dlang's design in the abstract... and
> >am just arguing because it is a slow day.
> 
> I welcome challenges to the design, it's how I improve things :-)
> 
> >On Sat, Jan 24, 2015 at 10:44 PM, David Lang <david at lang.hm> wrote:
> >>On Sat, 24 Jan 2015, Dave Taht wrote:
> >>
> 
> to clarify, the chain of comments was
> 
> 1. instead of bridging I should route
> 
> 2. network manager would preserve the IPv4 address to prevent
> breaking established connections.
> 
> I was explaining how that can't work. If you are moving between
> different networks, each routed independently, they either need to
> have different address ranges (in which case the old IP just won't
> work), or they would each need to NAT to get to the outside (in
> which case the IP may stay the same, but the connections will break
> since the new router wouldn't have the NAT entries for the existing
> connections)

To keep your IP when roaming:

3. The old school way: use mobile IP or some other tunneling mechanism
   (or VPN) so you can keep your same IP.

4. Use a "virtual subnet" model similar to:

https://tools.ietf.org/html/draft-ietf-l3vpn-virtual-subnet-03

The draft is focused on data centers and VM migration, but the problem
is the same with client migration/mobility.  I would argue that it is
even easier to "discover" the location of a client with Wi-Fi because
of the association/authentication handshake with the AP rather than
relying on a Gratuitous ARP/ND or LLDP, VSI, etc.

5. Use LISP:

http://en.wikipedia.org/wiki/Locator/Identifier_Separation_Protocol
http://lispmob.org/ (supported on OpenWRT)

Has anyone played with this?



More information about the Cerowrt-devel mailing list