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? >
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
