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

[Bernie Volz <[e-mail]>]

You can always create situations where something won’t work. We’re not trying to solve all networking problems with this.

- Bernie (from iPad)

> On Dec 27, 2023, at 11:36 AM, Michael Richardson <[e-mail]> wrote:
> 
> 
> 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