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

> On 27 Dec 2023, at 17:47, Bernie Volz <[email protected]> wrote:
> 
> You can always create situations where something won’t work. We’re not trying to solve all networking problems with this.

But it is unclear what problems this is actually solving. 
If any. 

Is the problem to solve is to register the addresses of the subset of hosts implementing it and volunteering to submit that information to the network?

That sounds quite unlikely. If the problem instead is that all addresses in use in the network must be registered, then I don’t quite see how this helps.

At best this looks like a harmless distraction. 

I think time would be better spent on improving SLAAC with something like (E)ARO to make addresses more tractable. Or defining a protocol between the first-hop router and backend system. 

O. 

> 
> - Bernie (from iPad)
> 
>> On Dec 27, 2023, at 11:36 AM, Michael Richardson <[email protected]> wrote:
>> 
>> 
>> Bernie Volz <[email protected]> wrote:
>>>>>> On Dec 26, 2023, at 5:59 PM, Michael Richardson <[email protected]> wrote:
>>>>> 
>>>>> 
>>>>> Bernie Volz <[email protected]> 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 <[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