Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification

> surely, this is true of any new DHCPv6 option, and given that we already
> support vendor options.

New options are much different than messages.

A server ignores new options as it would have no code to process them. Most clients don’t see new options as they wouldn’t send nor request them, but even if they do they should ignore them.

Yes, someone could write a server that iterates through the received options and hiccups when it runs into one it doesn’t understand, but that’s unlikely to be very effective server code, IMHO. Most servers I suspect look for options to process them.

- Bernie (from iPad)

> On Sep 13, 2023, at 5:49 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Bernie Volz <bevolz@gmail.com> wrote:
>> Maybe if consenus is for a PIO flag (when A bit set) that if set, say’s
>> don’t send server “global scope” SLAAC address notifications would be
>> something to consider. That means existing routers don’t have to change
>> for clients to send notifications (as flag would be clear - meaning to
> 
> If only there were an RA option which was easy to set without recompiling
> router code, and which could be extended trivially with minimal agony about
> chewing up scarce resources.
> 
> Maybe: https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/ ??
>   :-) :-) :-)
> 
>> And yes, I suspect that lots of servers (and maybe even some relays)
>> will log about the unknown packets and could clutter up logs. It may be
> 
> surely, this is true of any new DHCPv6 option, and given that we already
> support vendor options.  We even say:
> 
> }   Clients, relay agents, and servers MUST NOT discard messages that
> }   contain unknown options (or instances of vendor options with unknown
> }   enterprise-number values).  THESE SHOULD BE IGNORED AS IF THEY WERE
> }   NOT PRESENT.  This is critical to provide for future extensions of
> }   DHCP.
> 
> (emphasis mine)
> 
>> for the registration message is worth it — though minimal support of
>> the message by logging details of the notification request and sending
>> a reply may not be significantly more work and would eliminate logging
>> retransmissions except when a client fails to receive reply.”
> 
> That's one way to implement it.
> But it requires action, and I think you are concerned about already deployed
> code.
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

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