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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.