David Gibson wrote:
Looks good to me. It would be nice to also send an Neighbour Discovery request to accomplish the same thing for IPv6 only guests, but that could be a separate patch.
Good point! I'd prefer to do it in the same patch, as I'd also like fix another minor detail in this one. Just for the sake of clarity: I had a look at RFC4861 and there are many types of Neighbour Discovery requests. For our purpose, I believe that we want to send a "Neighbor Solicitation Message" described in section 4.3: https://datatracker.ietf.org/doc/html/rfc4861#section-4.3 Do you agree, or did you have something else in mind?
Note that even with this patch, active TCP connections (and in some cases UDP flows) will be broken by a passt restart.
Indeed, that is unavoidable for a user-space tool opening TCP and UDP connections, I guess, unless "passt" itself is wrapped into another process or system tool that keeps those connections open. But let's not go into that. If I really needed that level of independence, there is still the option to use a VPN like Wireguard, and then have a fixed passt process that is never restarted, and forwards only the wireguard UDP port. The service discrimination would then happen on IP rather than port level, so that (re)configuration of the service assignments to VM could happen always on-the-fly directly by the Cryptokey Routing table. (And maybe there are even better options for that use case, this is just the first simple solution that came to my mind, even though it would incur some crypto overhead unless you are already using wireguard anyways.) Best regards, Volker -- .---<<<((()))>>>---. | [[||]] | '---<<<((()))>>>---'