I don't think this has any particular security implications, but adding the secteam as reviewer just in case.

Update the man page as suggested by jilles in review.

Somehow inadvertently removed jilles when I posted that last comment; add jilles back.

@vangyzen gave his approval out-of-band; he is having some Phabricator access issues right now and suggested I mention his approval here.

Example run:

Incidentally, I believe there is a typo in the description. The Differential Revision: should be D6685, not D6885.

• Cleanup suggested by code review.

• Revise the test script to ensure that legacy logs do not simply contain no RFC-5424 formatted lines but that they /do/ have RFC-3164 formatted lines.

• Revise RFC5424 test so it both verifies that the RFC-5424 timestamp feature works and that the legacy timestamp format also continues to work.

• Rebase on HEAD
• Add a test for RFC5424 functionality.

Update to respond to review comments.

Just a couple style nits.

• Additional minor tweaks to grammar and wording suggested by vangyzen@

• Additional minor tweaks to grammar and wording suggested by vangyzen@

Yep; did manioc -Tlint and igor. Neither have any complaints (well, igor complains about a contraction, but that is in the literal text of an error message, so I cannot do anything about that):

• Additional changes suggested by review.

Further comments and follow-up on the arp(4) man page are directed to D8183.

@hrs (or anyone else): Can you supply any answers to the questions I asked wrt your comments? This review has been languishing for a while. If I did take a wrong turn with this change, I'd like to make the appropriate course corrections. Right now I don't think I have the information needed to do so.

Thanks, @markj; fixed.

• Leave out parenthetical numbers (e.g., "zero (0)").

Thanks, @badger.

• Fix typo.

I think several things point to this belonging in the kernel:

• It's a fairly fundamental responsibility of the network stack to generate a GARP when an address is added. The first (and currently only) GARP is generated by the kernel.
• Pushing it to user land doesn't fix the general case. Each application/system would have to implement a solution.
• While the particular circumstance that gave rise to this solution was on a floating cluster address, I do not think that the potential problem exists only for such a circumstance. It seems that this could happen when adding any address under any circumstances.
• The generation and retransmission of the IPv4 GARP is similar in nature to IPv6 ND/DAD, which is also done in the kernel.

If you compare this with my similar change in our local highlander tree, you will find a couple primary differences:

@hrs : Thanks for your comments. My specific use case is a system that is using stateful DHCPv6. It is entirely possible that I have simply missed other facilities for handling this configuration. I'm not familiar with the rtsold method to which you refer (the -O option). I have played around with this a bit and can't seem to get it to work based on just the man page. Can you point me to some description of how to use the method you reference? I'm happy to abandon this method if there is one already in place that I can get working!

• Update the rc.conf(5) man page for DHCP6. While here, fix a few problems pointed out by igor(1).

In D6885#144452, @cem wrote:

David, did you remove mav@ on accident?