A lot of the time once you get into multi-gig+ territory the answer isn't "make the kernel faster," it's "stop doing it in the kernel."
You end up pushing the hot path out to userland where you can actually scale across cores (DPDK/netmap/XDP style approaches), batch packets, and then DMA straight to and from the NIC. The kernel becomes more of a control plane than the data plane.
PF/ALTQ is very much in the traditional in-kernel, per-packet model, so it hits those limits sooner.
I think a more accurate version of this is: unit tests were not only per-method but also per functionality. This was often called BDD (Behavior Driven Development), e.g. Ruby's cucumber. Your intuition here is correct though.
I don't believe I suggested getting rid of the MAC address altogether. Ethernet isn't going away anytime soon.
The suggestion is simply this: Don't embed your MAC address into your IPv6 address because it's a unique identifier that can deanonymize you even if you shift networks.
Most IPv6 packets are encapsulated in Ethernet frames which use MAC addresses. What may change is the vendor specific MAC address could be replaced with a MAC address generated by a cryptographic hash to preserve privacy.
MACs can be spoofed. There are entire companies which begin their sales pitch with "So, I can poison the ARP cache to take over your DNS in your Kubernetes Cluster" due to the NET_RAW capability required to respond to ICMP (ping). :)
You'll want to use a crypto based identity if you want to ensure spoofing isn't occurring. Even then, you can still be DOSed by a malicious actor. Tools like eBPF may be able to help here by filtering out source MAC addresses that don't match the source interface's hwaddr.
edit: Sorry, I didn't read this comment properly. In ZeroTier I can believe that they cannot be spoofed across the VPN due to relying on a cryptographic hash. :)
In most scenarios, you want to avoid L2 tunnels to reduce complexity and/or performance issues.
The chain of thought typically goes like this:
* Remote networks are connected via L2 tunnel.
* ARP requests are broadcasted over L2 tunnel to all connected networks, introducing scalability issues
* Proxy ARP is introduced to cache ARP responses
* Proxy ARP may become out of date or not scale as the L2 domain grows.
* BGP is introduced to keep track of and broadcast all topology changes
* How do you mitigate issues caused if Proxy ARP fails?
Most of these issues go away if you use IP tunnels instead of Ethernet because IP was designed to be routable.
For your point on security... Whitelisting MAC addresses doesn't provide security. These are trivial to spoof. Same with IP. Please start relying on cryptographic primitives to establish workload identity instead. I highly suggest looking at SPIFFE to get started here.
If you must send L2 over the VPN, please go use a L2 EVPN which is designed to handle the complexity and provide fault tolerance. There are numerous SDNs out there you can use to implement this including Tungsten Fabric and OpenDaylight. No need to complicate Wireguard to support EVPN.
[edited to improve formatting of bullets and clarity of wording]
You end up pushing the hot path out to userland where you can actually scale across cores (DPDK/netmap/XDP style approaches), batch packets, and then DMA straight to and from the NIC. The kernel becomes more of a control plane than the data plane.
PF/ALTQ is very much in the traditional in-kernel, per-packet model, so it hits those limits sooner.