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

[Captive-portals] customizing API URLs vs ???



Chris Spencer <[email protected]> wrote:
    > Would not a feed of option 82 rather than create a new API work? option
    > 82 can carry MAC/IP (it could create a GUID/UUID) and other location
    > identifiers? if the external portal could get a feed of this, the
    > portal at layer 3 could look up the device MAC from the option 82
    > elements by the IP?  or if the DHCP server is centralised along with
    > the portal architecture and DHCP relay is used on the local site?

Option 82 is usually inserted by a DHCP relay when forwarding to a
centralized DHCP server.  It certainly could be used to customize the URL,
but in many systems this isn't going to work.

In a vast majority of "coffee shop" systems, the DHCP/RA function occurs on
premises in the router there, but the captive portal is out in the "cloud".
This is particularly prevalent in the smallest multisite installations
(10 locations across a single city), and the biggest multisite installations
("Harbucks" with 10,000 locations) where the operation of the captive portal
itself is outsourced to another company, or just centralized.

It probably occurs less in places like airports, hotels and enterprises where
there is more local operational clue.

So I just don't see how option 82 helps with IPv6 RAs.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [

Attachment: signature.asc
Description: PGP signature