A hallway conversation with Lorenzo and Jean Rickard [Rickard Jean], led me to re-read the API and rfc7110bis documents. https://tools.ietf.org/html/draft-ietf-capport-api-03 }4.1. URI of Captive Portal API endpoint } } The URI of the API endpoint MUST be accessed using HTTP over TLS } (HTTPS) and SHOULD be served on port 443 [RFC2818]. The client } SHOULD NOT assume that the URI for a given network attachment will } stay the same, and SHOULD rely on the discovery or provisioning } process each time it joins the network. Depending on how the Captive } Portal system is configured, the URI MIGHT BE UNIQUE FOR EACH CLIENT } HOST AND BETWEEN SESSIONS FOR THE SAME CLIENT HOST. It is typical the case today that the URL that the client is sent to includes the MAC address of the client system, or a token that refers to or contains the (encrypted) mac address. This is often the case because the Portal web server is *not* located on the same L2 network as the client. The discussion was how can this be implemented in IPv6 RAs. The options seem to be: 1) IPv6 RAs will have to be unicast with unique URLs, and the unique info needs to be remembered across clients. (This might be a win on WIFI anyway) 2) The client will need to post it's MAC address to the captive portal URL. How can the captive portal know it's not lying? (Is there an incentive to lie?) 3) It's not work for IPv6-only SLAAC-only networks. 4) There will need to be mechanism to map L3 addresses to L2 addresses between portal system and first-hop router 5) captive mechanism will have to be done for L3 addresses, which means doing it for v4, v6 and each privacy address..... -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature