IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 31 July 2019 16:29 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE69120158 for <captive-portals@ietfa.amsl.com>; Wed, 31 Jul 2019 09:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbLIz2ao4At7 for <captive-portals@ietfa.amsl.com>; Wed, 31 Jul 2019 09:29:16 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBF812013C for <captive-portals@ietf.org>; Wed, 31 Jul 2019 09:29:16 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 3B52E380BE for <captive-portals@ietf.org>; Wed, 31 Jul 2019 12:28:49 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2BB369BC for <captive-portals@ietf.org>; Wed, 31 Jul 2019 12:29:15 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: captive-portals@ietf.org
In-Reply-To: <CAFaTyiG_LxmyaSvBcqKgkYb9-SiaMcDr1khPV7oV-AVs85_x8g@mail.gmail.com>
References: <CAKD1Yr32DXr8fYHP_x7z9pQWwSchey8zQW11vw02bW9ONEV8Kg@mail.gmail.com> <01ad5bf0-1f60-4dbb-aa83-31d14fce6082@www.fastmail.com> <CAKD1Yr08LmfDhmDLqpR87iQQ4Z61CVpR9BTDeRHobpsvVxFJvA@mail.gmail.com> <CADo9JyW6TmBnr5f0AuSXKnKMXnMxGhMkgYbGQ1WYOQjSMefy=w@mail.gmail.com> <CAKD1Yr1Zo0NQod=p4ZqT6fJYJ=Xqh1q8eJT2+ich+p7Jmg1WiA@mail.gmail.com> <CADo9JyX1T8AnxirXLfGdcJzmjvy5_UGJktnbYByAuO7H++y8uA@mail.gmail.com> <CAKD1Yr0C_KEUpGUC-wbAV-ufG_VpNposecmzNQU5rEXaCeSZNQ@mail.gmail.com> <26405.1564182227@dooku.sandelman.ca> <CAKxhTx_CngPfs3V8sZ5n0SYbTN4zcu3L_cvGuLpbLJOZYu-1Kg@mail.gmail.com> <14eba834-e18a-4324-8baa-3a8b90cdaec4@www.fastmail.com> <CAFaTyiG_LxmyaSvBcqKgkYb9-SiaMcDr1khPV7oV-AVs85_x8g@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 31 Jul 2019 12:29:15 -0400
Message-ID: <16883.1564590555@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/0rzS3r_S4ZNiYW-1yXHBSRfXK4s>
Subject: [Captive-portals] customizing API URLs vs ???
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2019 16:29:19 -0000

Chris Spencer <chris.spencer@globalreachtech.com> 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   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

v2.23.0 | Report a Bug | By Email