[Captive-portals] API and URL problems for IPv6 RA

[Michael Richardson <[e-mail]>]

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-