In Network Service Mesh (NSM) a common use case involve cross connecting an incoming interface to an outgoing interface in vpp.  The incoming/outgoing interface could be one of a number of 'mechanisms' including kernel interfaces, memif, vxlan, wireguard, and others.

Network Service Mesh also distinguishes between the payload to be conveyed by these cross connects: IP or Ethernet.  For Ethernet a l2xc in each direction is the right tool.  For IP a pair of l3xc (one for IPv4 and one for IPv6) is the right tool in each direction.

Complications arise in the case of kernel interfaces.  Naively, tapv2 allows us to cleanly solve this by using either a 'tap' mode (L2) or 'tun' mode (L3) interface.  In practice however, since tapv2 requires the presence of /dev/vhost-net, which is not present on any of the Nodes for the major public clouds managed K8s instances (GKE,AKS, EKS have all been checked), we cannot rely on tapv2.  While it can and is used preferentially when available, a fallback is needed.

The best fallback proposed to date is AF_PACKET attached to one end of a veth pair, with the other end of the veth pair placed into the kernel network namespace of a Pod.

This works fine for the Ethernet payload type (l2xc).  It fails however for the l3xc case, because the veth pair still requires arp in both directions for both vpp to resolve the mac address of the kernel network namespace side of the vethpair, and for the kernel network namespace side of the veth pair to resolve the mac address of the vpp interface.

For the kernel network namespace end of the vethpair to vpp arping, we can use vpps proxy arp.

For vpp to kernel network namespace end of the vethpair however we have a problem: arp resolution needs to glean a source IP address, typically from the IP address of the interface, or in the case the interface is 'unnumbered' from the interface its associated with.

Naively, this would suggest a solution of either assigning an IP address to the interface, or associating it with as an unnumbered interface with an interface that does have an IP.

Sadly, neither are workable, as the appropriate IP for using as a source for arping may be repeated between cross connects (ie, we'd get collisions for IP assignment), and the cross connects are logically separate and intentionally mutually ignorant, so trying to manage them as unnumbered interfaces against a single interface having that same IP does not work.

This proposal is to add a feature 'reverse' proxy arp, that allows specifying that for a specific interface a particular IP should be used as source IP for arping.  This is not the IP of the interface, it should not be used for routing, it should not be checked for conflicts with other interfaces.  Its only for use so that when we get to arping we can resolve a mac address.