Re: WGLC for draft-ietf-dhc-addr-notification - Respond by December 11, 2023
Bernie Volz <[email protected]>
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <[email protected]> |
If you want to report upstream, why not just relay the notification? Happy Holidays. - Bernie > On Dec 24, 2023, at 11:39 AM, 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. > > 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. > > There are a bunch of enterprise-y situations where an enterprise acts as an > ISP for it's branch offices, and use stock CPEs. But, in those cases, the > enterprise usually has some kind of management interface (TR[3]69) that would > allow it to turn this behaviour on. > > We have a way for the upstream to turn ADDR-REG-INFORM on/off > (OPTION_ADDR_REG_ENABLE), and we should recommend that ISPs turn it off. We > should also recommend that CPE routers ignore upstream requests to report by > default. But, MAY be configured otherwise. > > Meanwhile any non-edge home routers, which might get deployed in the home > (including SNAC Stub routers) should probably proxy the information upwards. > > 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. > > 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. > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > dhcwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/dhcwg