Re: [PATCH v7 01/13] dhcpv6: Fix reply destination to match client's source address

[Stefano Brivio <sbrivio@redhat.com>]

On Sun, 12 Apr 2026 20:53:07 -0400
Jon Maloy <jmaloy@redhat.com> wrote:

> tap_ip6_daddr() selects the reply destination based on our source
> address type (link-local), so it always returns addr_ll_seen. But if
> the client sent from a global address, we would reply to an address
> different from what the client is expecting. Since RFC 8415 allows
> clients to use global addresses for DHCPv6, we now correct this, and
> always respond to the address the client was using.

I don't have much to add on top of David's comments, just two remarks
about the commit message:

- as far as I understand, you need this patch to simplify the rest of
  the series, but the way this is written makes it look like you're
  fixing something concrete.

  Somebody looking at the revision log in a while (including myself)
  will think so, at least. Are you actually fixing something you've
  ever seen in practice? If not, I think you should state that this is
  theoretical and it's simply needed by further changes, but doesn't
  fix any practical issue.

- I think it's time to start referring to RFC 9915 (it obsoleted RFC
  8415 in January 2026) and maybe a reference to section 18.3.10 would
  be appropriate here, as that's the one clarifying that "[...] the
  server unicasts the Advertise or Reply message directly to the client
  using the address in the source address field from the IP datagram
  in which the original message was received."

-- 
Stefano