Re: [Captive-portals] User equipment identification

Erik Kline <> Mon, 06 July 2020 06:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F37BF3A1113 for <>; Sun, 5 Jul 2020 23:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i2Mo0wxuJkLH for <>; Sun, 5 Jul 2020 23:18:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6861F3A1110 for <>; Sun, 5 Jul 2020 23:18:47 -0700 (PDT)
Received: by with SMTP id h1so8668446otq.12 for <>; Sun, 05 Jul 2020 23:18:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mcBlLL/5MnDq7wnQjSv6MdsN/JUq71iPQDd5JAapco8=; b=BKM+yzpUOAu8vF/2GFGjOE9GnTbfQgDCuANxLpU99jxgY6+e6z5DckzGpC62GSkBoD P/lCHLd+PahduDcfBOnwVSlK8tJANRwroz/+AKmC5yevfd5olNTYF6bYCPiH/D50iUyV wEyP39SSbLP/pSAmtCU+zJLwvpI2YMYIhjwlBDIn4m440wJPoHy2hCZ/dVd5u7JRc3S3 bZo6c4m4sWbnCVXDZqE8pfvku8R97fA0YdlT1mnn/YGyML1TchZlOShQCV8A0K2/wOHr m4Fk6jyqzdJ8ymKeHyKlXYTiIsjHuB2PL7Wq9BCS+64rrbTcIr1BiW9y5/KPMjPd2iEA bQ0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mcBlLL/5MnDq7wnQjSv6MdsN/JUq71iPQDd5JAapco8=; b=D/5iM0upO4xO6QjgM2Dt3eKMtwdSfMHel7SKyaZgkcgxWra4xxyXOIfgVuObKhLOLC WW3FpHUpmYzXb1onKblleLTHVGBxfp9yT/css/+efUesIGAI48SQ4+UBtGKGUzmZ51oU xTBAs9pJvVrp3Y42Dl4lXe9AzKL7f9Sgkhrj2YI0xJJ36CF9GPTXu6jkdxWn42BonG/P ROtfaw7DP1izXI2mNMAaOHSa6xhHXMzPEFUpSustQhrdwMxhEgaLcRSYX6bAHQ8IU+3i b0/YXkNCYgpJ6Nwh/P6orIuT+8k+d3Z37Kvt6ds4zOF/IEx7syDIJ3BKy6g2FlSY2xxq HoVw==
X-Gm-Message-State: AOAM53398wtTAmc2NaGsA9F3qUBOWsRRizkUb23T1XGO56w5YeZu9JGC ENH0mo7xDQpZQR40AAsubCg3+RHuTLUVR7OjY/2nNrSFRy4=
X-Google-Smtp-Source: ABdhPJxbwQko6OfKu97JshZAE5Pum/X4uzKEgXXd5TF34eIxDDtCz4AUZpllJb/JDz4pPwErUL9qzTu27ecvUU1hIrs=
X-Received: by 2002:a9d:6a12:: with SMTP id g18mr16860706otn.155.1594016326559; Sun, 05 Jul 2020 23:18:46 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Erik Kline <>
Date: Sun, 5 Jul 2020 23:18:35 -0700
Message-ID: <>
To: Michael Schneider <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Captive-portals] User equipment identification
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jul 2020 06:18:49 -0000

On Fri, Jul 3, 2020 at 1:27 PM Michael Schneider
<> wrote:
> Hi,
> I have read the documents about CAPPORT and as a Captive Portal vendor I find the current drafts very reasonable and well thought out. But a question came up when I was thinking about a dual stack user equipment. How does the client behave if it has an IPv4 and an IPv6 address and one of the two addresses is captive=false and the other captive=true. Do you see ways for the enforcement device to match these two addresses and allow both if one of them gets captive=false? Furthermore, a user equipment can hold more than one IPv6 address at a time and/or change it frequently.

I had often thought that it's going to take mapping clients by L2
identifiers to really pull this off.  However, even if the on-site
infrastructure live-streamed the neighbor table to the enforcement
device/other elements, there's always the possibility it will not
really be sure about the MAC address of an IPv6 client until it has to
do ND for it to deliver a reply packet.

One client per L2 domain is an approach that I think solves this: each
IPv6 client gets its own /64 (see
and then I think you can identify the IPv4 address and the IPv6 /64
addresses easily enough as being the same client.  This has some other
nice security properties as well.

2 cents,