Humm. Unfortunately the WireGuard driver can't quite reuse this as-is (even though I asked for it) because it wants to preserve a non-persistent tag (the tag id of 0 used to detect tunnel loops by if_tunnel_check_nesting). I'm not sure if the right answer is for if_tunnel_check_nesting to instead use a persistent tag ID instead of 0 (and really, it would be better to use a real tag id for those tags instead of 0 which is supposed to be PACKET_TAG_NONE?)

Humm, seems like PACKET_TAG_GIF/GRE aren't used anymore and instead these special 0 id tags are used instead? Or rather, it seems PACKET_TAG_GIF has _never_ been used, and that the original commit to add mbuf tags to, e.g if_gif(4) just accidentally used the value 0 (in this case for another constant MTAG_GIF_CALLED) along with a made up cookie value for MTAG_GIF. Later the CALLED constant was removed and replaced with an outright 0. I still don't know if we would want these "tunnel" tags to be persistent or not (e.g. do we want an mbuf that crosses an epair(4) to "forget" about any GRE/GIF encapsulation or are we worried about the packet looping?).

I’d say generally we want to protect from endless loops in our networking configuration, be it lagg/bridge/vlan/gre/tun or any other logical interface moving mbufs to the next interface. It is possible to perform control plane loop-check for some combinations, but not for all. Maybe it’s worth approaching it similarly to IP - by having a TTL budget of, say, 16 hops and simply decreasing it on every *logical interface* traversal? Can be 4 bits in the mbuf or a common tag, not cleaned until the mbuf gets destroyed. Thoughts?

I think we're going to have to distinguish the epair case from wireguard/gif/...

In the epair case we're interested in ensuring that whatever configuration is applied by one vnet does not carry over to another one. I ran into issues testing pf as a consequence of this, but I'm sure there are other ways for this to go wrong if we don't remove the tags. if_epair probably wants to remove all tags, even the persistent ones.

In the wireguard/gif/... cases we may want to preserve some tags. I can imagine QoS settings being attached in a tag, for example.

As for a loop check, I'm not sure where we'd apply it to ensure there is no possible path through the stack where we do not decrement the relevant counter.

To be clear, I think what might resolve my issue with the tunnel tags is adding a PACKET_TAG_TUNNEL which is persistent and changing if_tunnel_check_nesting to use that tag id instead of 0.