Re: [PATCH v7 08/13] conf, pasta: Track observed guest IPv4 addresses in unified address array

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 29 Jun 2026 18:39:32 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Thu, Jun 25, 2026 at 12:56:59AM +0200, Stefano Brivio wrote:
> > On Mon, 22 Jun 2026 11:46:45 +1000
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >   
> > > On Sat, Jun 20, 2026 at 12:10:41AM +0200, Stefano Brivio wrote:  
> > > > On Sun, 12 Apr 2026 20:53:14 -0400
> > > > Jon Maloy <jmaloy@redhat.com> wrote:
> > > >     
> > > > > We remove the addr_seen field in struct ip4_ctx and replace it by
> > > > > setting a new CONF_ADDR_OBSERVED flag in the corresponding entry
> > > > > in the unified address array.
> > > > > 
> > > > > The observed IPv4 address is always added at or moved to position 0,
> > > > > increasing chances for a fast lookup.
> > > > > 
> > > > > Signed-off-by: Jon Maloy <jmaloy@redhat.com>
> > > > > 
> > > > > ---
> > > > > v4: - Removed migration protocol update, to be added in later commit
> > > > >     - Allow only one OBSERVED address at a time
> > > > >     - Some other changes based on feedback from David G
> > > > > v5: - Allowing multiple observed IPv4 addresses
> > > > > v6: - Refactored fwd_set_addr(), notably:
> > > > >       o Limited number of allowed observed addresses to four per protocol
> > > > >       o I kept the memmove() calls, since I find no more elegant way to
> > > > >         do this. Performance cost should be minimal, since these parts
> > > > >         of the code will execute only very exceptionally. Note that
> > > > >         removing the 'oldest' entry implicitly means removing the least
> > > > >         used one, since the latter will migrate to the highest position
> > > > >         after a few iterations of remove/add.
> > > > >       o Also kept the prefix_len update. Not sure about this, but I
> > > > >         cannot see how the current approach can cause any harm.
> > > > >     - Other changes suggested by David G, notably reversing some
> > > > >       residues after an accidental merge/re-split with the next
> > > > >       commit.
> > > > > v7: - Changed fwd_set_addr() to only accept keeping one observed-only
> > > > >       address per protocol, as suggested by David.    
> > > > 
> > > > Sorry, I just spotted this in David's review of v6. Actually, I
> > > > think that keeping track of a few multiple observed addresses
> > > > (especially with different scope) might be convenient and it would
> > > > already be useful here together with 4/13 to avoid resolving via ARP
> > > > any of a few addresses recently seen from the guest.    
> > > 
> > > So.. not resolving ARPs is the one thing where we could actualy use
> > > multiple guest observed addresses - mostly we use it for directing
> > > traffic to the guest, for which we need a single address.
> > > 
> > > But.. I feel like switching the ARP resolution from "everything
> > > except" to "only these" would be a better solution.  That also lets
> > > the guest move to a brand new unused address without getting bogus DAD
> > > failures.  
> > 
> > See my follow-up on 2/13 for the general topic. Specifically about
> > duplicate address detection: that's NDP, not ARP,  
> 
> Sorry, I spoke sloppily.  I was meaning all duplicate address
> detection techniques, including both true NDP DAD and using ARP for a
> similar purpose with IPv4.
> 
> > and it already works
> > without failures because of this check in ndp(), ndp.c:
> > 
> > 		if (IN6_IS_ADDR_UNSPECIFIED(saddr))
> > 			return 1;
> > 
> > which is based on the fact that duplicate address detection packets are
> > sent to the unspecified address (RFC 4862, 5.4.2).  
> 
> s/to/from/?

Oops, yes.

> So, I hadn't realised that.  That basically means DAD will always
> suceed, even when it should fail - e.g. if the guest tries to use the
> gateway's address.  That doesn't seem great.

Why should it ever fail?

In that case, if the guest tries to use the gateway address, so be it.
It will be unable to reach the host using default options, but then
it's probably desired. I actually tried it a while ago, it worked.

> > The DHCP / ARP equivalent is also taken care of because we assume we
> > are the relevant DHCP server for any guest / container and in that case
> > we wouldn't resolve duplicate address probes for IPv4 either, as we
> > just assigned that address to the guest / container.  
> 
> If the guest uses DHCP, in which case it should be using the address
> we give it via DHCP.  If it _doesn't_ take the address frome DHCP, but
> does use DAD-like ARP, that will prevent it from changing address.

Right, yes, but I've never ever seen DAD-like ARP implemented by
anything that's _not_ a DHCP client. Linux doesn't do it, ifcfg scripts
/ systemd-networkd / NetworkManager don't do it either, so it sounds
quite unlikely to me.

-- 
Stefano