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

Now that I think about it. This 'can', could get very complicated.

In a service provider network, we definitely don't care what host or
anything else that's happens beyond the customer router, regardless if it's
enterprise or residential. Our legal liability stops at customer KYC,
meaning, if my router gives them a /56 or /48 PD, and this PD information
is logged via AAA/RADIUS, that's enough for an SP to comply with the law.
So yes, an option to disable/ignore addr-reg fully, should be available. Or
better yet, have it disabled by default on server-side. Customer edge
router side should probably be disabled by default too.

However, you're right that there are some enterprises that use stock random
CPEs for branches etc. And this is where we'll run into problems. If there
are say n number of hierarchical routers, that are doing exactly what you
described, are we supposed to "proxy" it all the way from the bottom of the
hierarchy to the top most DHCPv6 server? That sounds terrible and a good
way to create problems with BUM traffic in a network (Just M in IPv6).

I think this responsibility should fall on the operator. I.e, we should
grant the same standardised DHCPv6 server functionality to CPEs which
includes this addr-reg. Meaning now the CPE running DHCPv6 server for its
LAN, will maintain the local table of addr-reg info. The enterprise can
then pull this information via various available methods from the CPE
vendor.

I think the "proxy" idea overcomplicates things vs letting the
responsibility fall upon the enterprise operator.

I'm still not clear overall, how the configuration of this addr-info on
server side would look like, while I understand the M flag, should my link
prefix /64 still be "autonomous" or not though?

--
Sent from my iPhone


On Sun, 24 Dec 2023 at 10:09 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.
>
> 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
>
>
>
>
> [image: dad806703346ec960ea2f67237f882ea1db0de4d]
​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

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