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

[Jen Linkova <[e-mail]>]

On Sun, Dec 24, 2023 at 5:39 PM Michael Richardson
<[e-mail]> wrote:
> It seems to me that a DHCPv6 server, which has received it's prefix via
> DHCPv6-PD *could* turn around and forward any ADDR-REG-INFORM it received up
> one level.  I think it need to reform ("proxy", application-level) the
> messages and take responsability for them itself.  It should not blindly
> forward or rely upon the "end" client to stop and/or retransmit.

I'm not aware of any generic proxy mechanism. Defining it just for
this specific message sounds like an overkill (and it would introduce
some
privacy considerations indeed).

> While an RFC7084 fits squarely into the "gets DHCPv6-PD", and might even
> delegate DHCPv6-PD, I strongly think that it should never, in the residential
> situation, send ADDR-REG-INFORM from the home lan to the ISP.

In the current text it would not - unless it acts as a DHCPv6 relay,
not as DHCPv6 server. But in the latter case the endpoints located in
a given household would be sending DHCPv6 packets to the ISP server
anyway, right?

[skip]
> The challenge here is that we have to send one ADDR-REG-INFORM message for
> each downstream host, and we have to do that from the address of the host!
> I think we should rethink this in some way.

TBH, I'd rather say "don't do this".

> I wrote some text:
>   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.

I have some concerns.
1. The desired result can be achieved by relaying the messages - and
it would using the standard DHCP mechanism. What you are proposing
requires developing a new mechanism for proxying (and we'd need to
either sacrifice security, or let the proxy use a spoofed source
address).
2. If I understand you correctly, you see the following use cases when
the current text doesn't work:
2.1 an enterprise remote office with a CPE acting as DHCPv6 PD client.
The enterprise administrator might want to know the registration data
for endpoints.
2.2 a SNAC router (so the home network administrator has information
about addresses used by the devices in the stub network.

For #2.1  I'd expect the enterprise to collect that data from the
router (the same way they would need to do it for DHCPv[46] assigned
addresses). That information doesn't need to be collected  in real
time, so existing monitoring/telemetry mechanisms would do.
Not sure about SNAC case, but I'm still not convinced we shall
complicate things so drastically (as to invent a proxy mechanism) to
solve it.


>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 what you mean about "permissionless' '. As long as the
server delegates the prefix, the administrator knows which device that
prefix was delegated to.
So accountability is there.

-- 
Cheers, Jen Linkova