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

[Michael Richardson <[e-mail]>]

Bernie Volz <[e-mail]> wrote:
    >> On Dec 26, 2023, at 5:59 PM, Michael Richardson <[e-mail]> wrote:
    >>
    >> 
    >> Bernie Volz <[e-mail]> wrote:
    >>> If you want to report upstream, why not just relay the notification?
    >>
    >> a) because often the local server actually needs to keep it's own database.

    > There’s no reason the notification cannot be consumed both locally and
    > forwarded. Obviously the forwarded request’s reply likely should be
    > dropped if a locally generated reply is being sent - but that’s easy
    > enough for relay to handle by adding something into the Interface ID
    > option?

Well, does the local processing result in an acknowledgement?
What if the forwarded copy gets lost?
If so, then the client stops sending, and the upstream does not get updated.

    >> b) because it might need to filter based upon which addresses are being
    >> reported about.  For instance, filter out ULAs, but keep GUAs.
    >>
    > No reason that device couldn’t filter out ones it doesn’t want to relay.

    >> c) it seems to me like the local server should perhaps be taking
    >> responsability for the delivery.

    > That is perhaps the one benefit for not relaying (see a) but I guess
    > you could change it so relayed Reply is delivered back to client (not
    > local one). This mechanism isn’t expected to be perfect since it may be
    > a while before clients even add the support (and some may never).

In domains where they care, it will get done, I think.
There is also a question of connectivity:  if the enterprise wants to collect
the ULAs that are being used in the branch office, but those ULAs are not
routed, then the replies might not come back if they are unicast.

There is another situation worth dealing with: ULAs are supposed to be routed
(and DHCPv6-PD into the branch office), but there is some "rogue" ULA at the
branch office which the printer has adopted as it's only address.  Knowing
this would be really useful in diagnosing why stuff doesn't work.
(Maybe SNAC is involved)

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide