Erik, 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.
So then, (a) one of the user's IP addresses would be used to make the request, but we might expect to include multiple addresses in the body of the request itself. E.g., to provision IPv4 and (multiple) IPv6 at the same time. Or, (b) we could say that provisioning must be repeated from each IP address to be used. Then the address could be implicit in the connection used for communication--which also serves as proof of ownership. Just some thoughts. -Dave -----Original Message----- From: Erik Kline [mailto:[email protected]] Sent: Monday, October 16, 2017 8:20 AM To: Kyle Larose; Dave Dolson Cc: [email protected]; David Bird Subject: client identifying info between API and enforcement <hat-free /> Kyle, Dave, (David, all,) When a client is trying to talk to an [architecture-2.3] API server, using the URL is learned in [architecture-2.2], will it need to present some token that the API server can ultimately use when communicating back to the enforcement box? I'm effectively wondering about how we get (something like) the MAC address of a client into this URL, /especially/ when the URL might not be custom crafted for each client (i.e. in the case of the URL in an ICMPv6 RA or learned via PvD mechanics). What's required here and how do we think it should work? _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
