Quick follow-up. If the premise "the peer public key is sort of the peer's lladdr" is correct, here's an idea off my chest. (Beware that I am blissfully unawa

Quick follow-up. If the premise "the peer public key is sort of the peer's lladdr" is correct, here's an idea off my chest. (Beware that I am blissfully unaware of wireguard internals, just brainstorming.) If the peer pubkey identifies the port on the other end, just like a MAC address would identify the NIC on the other end of a switched network; Then would it be possible to give the kernel the peer pubkey as the lladdr when it asks for a next-hop's lladdr? If so, all the IP routing stuff could be moved out of wireguard and taken care of by the kernel's IP router. Without the internal IP routing function, L2 traffic could possibly be forwarded. If the lladdr field is not large enough, maybe allow the user to give to wg a mapping between fx. a 6-byte locally assigned peer lladdr, and the 32-byte peer pubkey. Or ask Linus to extend the field. ;-) Could be hidden behind an "l2-mode" flag or something. In my opinion, being able to forward L2 would help a lot towards building a GUI in a sensible way, but yeah, just an idea. I'll find an IRC client soon, promise.