[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] client identifying info between API and enforcement

We shouldn't be requiring devices to request permission from the network every time they create a new IPv6 address. See RFC 7934 for rationale and best current practices.

As for changing MAC addresses at will - captive portals are usually deployed on wifi, and 802.11 is very much tied to a single MAC address. On typical host platforms it's sometimes possible to change the MAC address, but it's very hard to use more than one at the same time.

On Tue, Oct 17, 2017 at 12:41 AM, Dave Dolson <[email protected]> wrote:

Or change MAC addresses at will?

Each change could be handled as a new capport session.

 

 

From: Lorenzo Colitti [mailto:[email protected]]
Sent: Monday, October 16, 2017 11:01 AM
To: Dave Dolson
Cc: Erik Kline; Kyle Larose; [email protected]; David Bird
Subject: Re: [Captive-portals] client identifying info between API and enforcement

 

On Mon, Oct 16, 2017 at 11:23 PM, Dave Dolson <[email protected]> wrote:

I infer you mean the MAC address is required so that the portal can open/close the firewall using it as a filter.
I'd prefer to see this done at the Internet layer (AKA layer3), with IPv4/6 addresses, to avoid limiting usefulness to a particular access technology.

 

How do you do that when devices can create new IPv6 addresses at will?