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

I think the SNAC use case would have to be clearly motivated: someone would
have to be asking for it not because they think it should happen in theory,
but because they need it to deploy stub networks in their specific
environment. Personally I’m skeptical that there is a need for this, but it
will be interesting to see.

Op vr 29 dec 2023 om 07:02 schreef Jen Linkova <[email protected]>

> On Sun, Dec 24, 2023 at 5:39 PM Michael Richardson
> <[email protected]> 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
>
> _______________________________________________
> dhcwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg