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

[Michael Richardson <[e-mail]>]

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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide