Announce INET6 address flag changes to userland

[hrs]

Looks reasonable to add notification when ia6_flags is changed, but why is RTM_ADD used instead of RTM_CHANGE? rt_addrmsg() is for addition/removal of an address and RTM_ADD is translated to RTM_NEWADDR there.

[roy_marples.name]

In D5469#149446, @hrs wrote:

Looks reasonable to add notification when ia6_flags is changed, but why is RTM_ADD used instead of RTM_CHANGE? rt_addrmsg() is for addition/removal of an address and RTM_ADD is translated to RTM_NEWADDR there.

Because rt_addrmsg() will change address announcements to RTM_DELADDR if not RTM_ADD. FreeBSD does not support RTM_CHGADDR so change doesn't really fit either. It can also be argued that the address itself, nor route, are actually changing, just the state of it.

For what its worth, NetBSD and Linux also use the same flags for this - RTM_NEWADDR or equivalent.

[roy_marples.name]

Let me clarify.

BSD uses rt_addrmsg() to announce new and deleted addresses.
It makes perfect sense to use the same function to announce address change states, such as for changes ia6_flags.
Because FreeBSD only has RTM_NEWADDR and RTM_DELADDR we need to use RTM_NEWADDR and the function arguments then dictate that we need to use RTM_ADD.

The alternative is to write a new function which doesn't take a route argument and thus can accept RTM_NEWADDR directly, but I thought that would be too much overhead for little gain.

[kevans]

Adding bz@ for IPv6 relevance; also ping6 for melifaro@ in case this now clashes with recent routing changes.

[melifaro]

In D5469#543714, @kevans wrote:

Adding bz@ for IPv6 relevance; also ping6 for melifaro@ in case this now clashes with recent routing changes.

No, it's ortogonal.
I'll take a look into that review a day or two, as I said in the list.

[melifaro]

Generally looking good, though my primary concern is interaction with the existing applications.

Both bird and frr ignore value of ifam_flags.

Will update the patch and look at the behaviour for both of them.

[roy_marples.name]

In D5469#545864, @melifaro wrote:

Generally looking good, though my primary concern is interaction with the existing applications.

Both bird and frr ignore value of ifam_flags.

Will update the patch and look at the behaviour for both of them.

ifam_flags is the interface flags so it makes sense to ignore it :)
This patch just enables the application to then ioctl SIOCGIFAFLAG_IN6 to get the state of the address when the address updates rather than polling perdiodically.

To really make this work we need ifam_addrflags ..... and ideally ifam_pid to identify the sender.
https://netbsd.gw.com/cgi-bin/man-cgi?route+4+NetBSD-current

[roy_marples.name]

@melifaro any update on this?

[bz]

My immediate concern was the same as @melifaro 's though I am not just thinking about 1 or 2 pieces of software, The ecosystem is more complex.
But I do agree that an "event" mechanism would be good to have and to teach user land software as well. If one enables kernel logging for nd6 and watches the startup system to stay after DAD complete is logged it is painful even after the work @cperciva has already done. That would especially help to get to remove more "sleep" calls.

[melifaro]

In D5469#819186, @bz wrote:

My immediate concern was the same as @melifaro 's though I am not just thinking about 1 or 2 pieces of software, The ecosystem is more complex.
But I do agree that an "event" mechanism would be good to have and to teach user land software as well. If one enables kernel logging for nd6 and watches the startup system to stay after DAD complete is logged it is painful even after the work @cperciva has already done. That would especially help to get to remove more "sleep" calls.

Speaking of the route message type - RTM_CHGADDR seem to get removed from NetBSD. Though, RTM_NEWADDR looks just fine & again - that's what other OSes do already.
I'm doing something around this space at the moment, a will look/test new behaviour this week and hopefully finally merge it.