Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by December 11, 2023

[Daryll Swer <[e-mail]>]

>
> Regarding your "enterprises won't be happy without this" comment... why do
> you say this? One of the goals of this document is to get roughly
> equivalent forensics and logging abilities to what we have with IA_NA today
> (assuming cooperating hosts). But AFAICT the hierarchical notifications you
> describe aren't something that exists today with IA_NA. The enterprise
> either uses a local DHCPv6 server that is authoritative for the local
> prefix, or it uses a centralized DHCPv6 server to assign all addresses. In
> the former case, the only information about which addresses are assigned
> locally is in the logs of the local DHCPv6 server. The mechanism being
> proposed in this draft has the same properties.
>

The more I thought about this, the more I think, most enterprises will just
opt to stick with ia_na (possibly with added ia_pd for CLAT etc). Even if
this draft becomes approved and finalised, I have my doubt, enterprise will
opt for the mechanism here vs plain old ia_na.

Most enterprises I know and heard of are just using plain ia_na, of course
Android is excluded and gets no IPv6. Some enterprises will have a “Guest
SSID” and there's SLAAC on that one (which may or may not have internet
reachability), and it's an untrusted network, Android devices will get IPv6
there, but will need to VPN-in to get access to the internal services and
network.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/link/8156cee82832ae3cd2ee8812d4b91b5ce3cf32f0?url=https%3A%2F%2Fwww.daryllswer.com&userId=2153471&signature=e42a88a14e15872d>


On Tue, 9 Jan 2024 at 06:01, Lorenzo Colitti <lorenzo=
[e-mail]> wrote:

> On Mon, Dec 25, 2023 at 1:39 AM Michael Richardson <[e-mail]>
> wrote:
>
>>
>> I wrote some text at:
>>   https://github.com/wkumari/draft-wkumari-dhc-addr-notification/pull/68
>>
>> and I'm sorry to open this can of worms, but I don't think that
>> enterprises
>> will be happy without this.  In particular, our desire to enable more
>> (permissionless) DHCPv6-PD downstream will get the same pushback that has
>> lead to this document.
>>
>
> I'm not sure we should take the document in that direction. Jen's concerns
> about removing the security and defining a general proxy mechanism are very
> valid. If we do want to do this I think it will require a lot more work:
> when will the messages be sent? What's the authentication model? What about
> privacy? And so on.
>
> Regarding your "enterprises won't be happy without this" comment... why do
> you say this? One of the goals of this document is to get
> roughly equivalent forensics and logging abilities to what we have with
> IA_NA today (assuming cooperating hosts). But AFAICT the hierarchical
> notifications you describe aren't something that exists today with IA_NA.
> The enterprise either uses a local DHCPv6 server that is authoritative for
> the local prefix, or it uses a centralized DHCPv6 server to assign all
> addresses. In the former case, the only information about which addresses
> are assigned locally is in the logs of the local DHCPv6 server. The
> mechanism being proposed in this draft has the same properties.
>
> Am I missing something?
>