Subject: [homenet] ISPs using DHCP for individual clients

From: Daniel Migault <[email-masked]>
Date: Fri, 20 Nov 2020 03:37:30 -0500

Hi,

While designing the DHCP options to configure the HNA we asked ourselves
how likely ISP are:

A) How an ISP is likely to perform an action that is user specific based on
a DHCP request. In our case the HNA sends to the DHCP server the
certificate it will use to authenticate itself to a server the ISP has
control on. The action is that the ISP will need to provision the server
with that certificate.

B) How an ISP is likely to provide a DHCP response that is specific to an
individual user. The specific information is typically expected to be
something provisioned for that user.

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 20 Nov 2020 10:06:32 +0100 (CET)

> something provisioned for that user.

I'm not 100% sure I understand your question but let me write some text 
and see if it helps.

In Sweden, ETTH is often delivered with an L2 switch of some kind, can be 
media converter or just CPE. Into this, you can connect a router, an ATA 
(PSTN box), a TV STB, and based on the MAC address and possibly the 
contents of the DHCP request, you'll get different responses, possibly 
even that the device reconfigures ports into different VLANs etc. The term 
used is called "free seating" (I have no idea where this came from) and 
the idea is to reduce customer support calls when customers plug in 
equipment into the "wrong" port, so instead just let customers plug into 
any port and it just works. The DHCP responses might also be different 
depending on type of device etc.

We also have cases where you register your HGW MAC address in a portal and 
depending on this MAC address, your HGW will either receive IPv4 GUA or 
end up behind CGN. So this differentiation is done on MAC address. Don't 
know if you consider this "part of DHCP request" or not.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: [email-masked]
Date: Fri, 20 Nov 2020 16:57:43 +0100

Hi Daniel,

I can’t speak to A), but we have built and tested DHCPv6 infrastructure using ISC’s Kea with a Cassandra based back end with quite a bit of per-subscriber logic. The remote-id option is supplied by the relay and contains a number of flags, depending on the services the customer subscribes to. These indicate which options the response contains, for things like:

Single/multiple IPv6 prefixes for different service types
IA_NA for the CPE WAN interface 
v4 configuration for lightweight 4over6 softwire

For the last item, each subscribed user receives option 96 with unique option content (v4 address, v6 tunnel endpoint hint).

Thanks,
Ian

> On 20. Nov 2020, at 09:37, Daniel Migault <[email-masked]> wrote:
> 
> Hi, 
> 
> While designing the DHCP options to configure the HNA we asked ourselves how likely ISP are:
> 
> A) How an ISP is likely to perform an action that is user specific based on a DHCP request. In our case the HNA sends to the DHCP server the certificate it will use to authenticate itself to a server the ISP has control on. The action is that the ISP will need to provision the server with that certificate.  
>  
> B) How an ISP is likely to provide a DHCP response that is specific to an individual user. The specific information is typically expected to be something provisioned for that user.
> 
> Yours, 
> Daniel
> 
> -- 
> Daniel Migault
> Ericsson
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 21 Nov 2020 16:13:14 +0000

Hi Mikael,

The idea to identity the kind of devices (hence any QoE) based on MAC address (probably on the OUI part) has work for many years; but, now more and more OS do MAC address randomization (cfr the MADINAS BoF at IETF-109), so, I am afraid that this 'easy/smart' technique is a thing of the past... Or, am I missing something ?

Regards

-éric

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 21 Nov 2020 17:43:02 +0100 (CET)

On Sat, 21 Nov 2020, Eric Vyncke (evyncke) wrote:

> The idea to identity the kind of devices (hence any QoE) based on MAC 
> address (probably on the OUI part) has work for many years; but, now 
> more and more OS do MAC address randomization (cfr the MADINAS BoF at 
> IETF-109), so, I am afraid that this 'easy/smart' technique is a thing 
> of the past... Or, am I missing something ?

I doubt STB or ATA box will do MAC address randomization. Why would they?

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 21 Nov 2020 17:30:33 +0000

Probably, but others, could do it and have a collision (unsure whether those set the U/L bit correctly)

-éric

---

From: Daniel Migault <[email-masked]>
Date: Sat, 21 Nov 2020 21:11:28 -0500

Thanks for the response Mikael,

In this case, I have the impression the L2 switch uses the MAC address to
determine what type of devices is initiating the DHCP request and orient
the DHCP request to the appropriated VLN and DHCP server. I suspect that
the type of device is determined the OUIs and the switch has a table of the
corresponding OUI and the potential HWG MAC address and that such table is
loaded as part of the configuration of switch.

If my understanding is correct, this is a bit different from our use case.
I think the situation I was describing would have been closer to the HGW
sends in a DHCP request its MAC address and the MAC address is registered
into the end user account. But that is a useful feedback though, as it
chose having a portal and expecting the end user to provision the CPE is
something common. This will relax the purpose of zero configuration but
sounds more in line with what is currently deployed.

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Sat, 21 Nov 2020 21:11:30 -0500

Thanks for the response Ian,

This seems to confirm that assuming per-subscribers responses is something
widely deployed.

Thanks!

Yours,
Daniel

On Fri, Nov 20, 2020 at 10:57 AM <[email-masked]> wrote:

> Hi Daniel,
>
> I can’t speak to A), but we have built and tested DHCPv6 infrastructure
> using ISC’s Kea with a Cassandra based back end with quite a bit of
> per-subscriber logic. The remote-id option is supplied by the relay and
> contains a number of flags, depending on the services the customer
> subscribes to. These indicate which options the response contains, for
> things like:
>
>
>    - Single/multiple IPv6 prefixes for different service types
>    - IA_NA for the CPE WAN interface
>    - v4 configuration for lightweight 4over6 softwire
>
>
> For the last item, each subscribed user receives option 96 with unique
> option content (v4 address, v6 tunnel endpoint hint).
>
> Thanks,
> Ian
>
>
> A) How an ISP is likely to perform an action that is user specific based
> on a DHCP request. In our case the HNA sends to the DHCP server the

-- 
Daniel Migault
Ericsson