LGTM (original author hat on)

I'm the original author of this code. I have run into exactly the same issue you have called out, but at COMEX/CME in Chicago with IGMPv3 being seen upstream of a demarc boundary where only PIM traffic was expected. This was on Linux, and we ended up filtering outgoing IGMP traffic with iptables; ~2010.

Taking glebius' requested style changes.

In D58597#1345174, @kevans wrote:

In D58597#1344902, @bms wrote:

This is directly in the line of fire of my GSoC student's MPLS work.

This should be pretty easy to rebase around, at least.

This is directly in the line of fire of my GSoC student's MPLS work.

OK, so the parent revision got pushed by me accidentally already. Squashing at this point is probably out of the question, because rebasing in that way on main would be Very Bad.

In D58590#1344748, @glebius wrote:

Can you please just squash this revision into D58585? It is a straight one liner bug fix of it.

In D58585#1344817, @pouria wrote:

Nice work, do you have plan to create an I-D for it?

In D58588#1344732, @glebius wrote:

Makes sense to wait for jhb@ for a few days.

@glebius "In lieu of" is typically taken to mean "instead of", "in place of", "with respect to". I was hoping to delegate Kyua-ifying the test to another volunteer so I can defer having to deal with Kyua upfront right now and keep the momentum, but if you insist, I guess we will have to do it that way.

I think this is a wrap.

In actual fact, https://reviews.freebsd.org/D58591 was informative, but the swizzle was happening in the *wrong place*.

Good catch, this was being munged elsewhere. The ntohl() for the 0x0000FFFF component is definitely needed.

Root cause analysis revealed 2 kernel-space issues:

I added ntohl() to the corresponding kernel path for conversion from v6 to v4 sockopts, as was done for the 0xFFFF interstitial value normally found in IPv4-mapped addresses. This seems to be due to how values are assigned to s6_addr32[] array members.

In D58588#1344538, @pouria wrote:

I'm not sure whether they can be static or not, but the naming is definitely not right.

Mend and make do.

Address all review comments, caveat the addition in the HISTORY section.

The #ifdef INVARIANTS conditional for _Static_assert() is mostly a no-op, because GENERIC enables them via "include "std.debug"".

This change has been exercised with bird3. And the tcpdump dissector I forgot I wrote almost ~22.25 years to the day...

Compile tested for amd64 GENERIC.
The next Differential will contain the netipsec/xform_tcp.c refactoring to use ip6_hdr_pseudo{}.

Inlined as glebius requested, but this counter-intuitively adds more churn as declarations then need to be moved further up in the main translation unit touched by this change.

Incorporating Gleb's requested changes.

a number of these are things I introduced, no objection

+1 for utility.

The rationale is pretty clear. Whilst it would be preferable to be default-deny (for much the same reasons as security models built on top of this are also default-deny) it cannot be so for compatibility reasons (yet; perhaps in future).

In D56750#1313882, @pouria wrote:

The reason was BIRD, I saw @melifaro's commits on it and learned he wanted FreeBSD's netlink to remain as close to Linux's version as possible.
Please keep this review open if possible. the use case will come up soon, though I don't know exactly when or for what.

Ah. This more or less removes an item from my TODO list. Thank you. The intent was always to profile first, add Minshall later.

This makes things nice and clean for SRv6 in future, if and when that happens. Thank you.

I have plans to add Delayed ACK profiling eventually, does this collide with anything, or is someone going to beat me to it?

This is giving me 2003 flashbacks.

Surely the point is moot though and SSRR/LSSR accepted only for feature-completeness in IPv4? E.g. SR-MPLS and SRv6 do not use it.

Yeah let's get stinko!

In D56947#1304518, @glebius wrote:

In the commit text, in the phrase it'll drop packets from the queue but fail to remove them, I'd suggest to change drop to free or m_freem.

I concur that commit-id 855239e56 of xnu/bsd/netinet/igmp.c from https://github.com/apple-oss-distributions/xnu appears to have a similar fix, but they explicitly split the conditional further. The "fog of war" of xnu imports in "git log" prevents further instrumentation beyond the obvious "git blame" "where the bodies are buried" action. (Hey, I had a git sparse-checkout lying around in my primary FreeBSD VM dev instance. Go ME! But that was also part of the ongoing xnu dissection, "Take what is useful, destroy the rest." Developer Hegemony is currently looking like a bit of a pipe dream, unless people start taking what Dijkstra said in 1975 about "complexity generators" seriously.)
Gotta go, I'm out of actual food, so I need to go to the shop, respond to my other GSoC student meaningfully, and tune in to "Auntie" (Prof.) Emily Bender at 2000BST on Twitch.
UPDATE: OK, that was not as cool as I thought it would be, and I've eaten too many crisps and cheap sushi. She was mostly poking fun at people's huge AGENTS.md files on GitHub.

Yeah. Don't have much to offer here, I'm afraid, ironic being the instigator, but just so much is going on at the moment, and I'm literally RAMMED every DAY. The mental map of this code is long gone from the forebrain, but probably lingers somewhere, but I'm not about to pop Piracetam or Choline Inositol to find out this week. (Those are nootropics; the latter are nutraceuticals.)

Testing any of it outside of simulation might be difficult. I left my Madge 10BASE-T/ATM25 dual-mode switch behind in Berkeley in 2005...

Userland impact believed non-existent, these are kernel-space structures and are not generally exposed outside of in_mcast.c/in6_mcast.c.

LGTM with caveats. any plans for a Kyua test to catch the strafe fire in the ISN space this looks like it should close against?

Just fired up one of my Haswell-based Dell Optiplex 3020 test boxes... and there's no DEBUG for their onboard Intel C200 xHCI.

Just fired up one of my Haswell-based Dell Optiplex 3020 test boxes... and there's no DEBUG for their onboard Intel C200 xHCI. So, I cannot even test any of it any more.