[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