"Quote from: YordiDR on March 06, 2026, 01:52:55 PMI've got the same issue.
I'm running ISC DHCP on separate containers. This is working fine with DHCrelay on IPv4.
On IPv6, the DHCP servers are failing to assign addresses because they cannot map the incoming relayed DHCP request to a DHCP pool.
I also saw the OPNsense DHCrelay set the link-address to it's link-local address. If it would send it's GUA address instead, the DHCP server could map it to the correct GUA pool.
I got the same problem as you described. For reasons I am running a Kea DHCP server in a different subnet as the clients are on a different machine so I relay the traffic via opnsense's dhcp relay. The problem is that it uses the link-local address instead of the global ipv6 as link-address to forward the relay's and Kea won't be able to properly select a subnet. I do use correct class selection in Kea for subnet selection but it doesn't come to that stage yet.
/edit
When I go through the RFC 8415 it states that using a link-local address is not recommended but GUA is. Kea expects a GUA address as link-address. It is not a hard requirement though that a relay agent MUST use a GUA and may use a link-local instead.
https://datatracker.ietf.org/doc/rfc8415/
19.1.1. Relaying a Message from a Client
If the relay agent received the message to be relayed from a client,
the relay agent places a globally scoped unicast address (i.e., GUA
or ULA) from a prefix assigned to the link on which the client should
be assigned leases into the link-address field. If such an address
is not available, the relay agent may set the link-address field to a
link-local address from the interface on which the original message
was received. This is not recommended, as it may require that
additional information be provided in the server configuration. See
Section 3.2 of [RFC7969] for a detailed discussion.
This address will be used by the server to determine the link from
which the client should be assigned leases and other configuration
information.
The hop-count value in the Relay-forward message is set to 0.
If the relay agent cannot use the address in the link-address field
to identify the interface through which the response to the client
will be relayed, the relay agent MUST include an Interface-Id option
(see Section 21.18) in the Relay-forward message. The server will
include the Interface-Id option in its Relay-reply message. The
relay agent sets the link-address field as described earlier in this
subsection, regardless of whether the relay agent includes an
Interface-Id option in the Relay-forward message.
And RFC 7969 has also some discussion about this
https://datatracker.ietf.org/doc/html/rfc7969#autoid-5
3.2. DHCPv6-Specific Behavior
The DHCPv6 protocol [RFC3315] defines two core mechanisms that allow
a server to distinguish which link the relay agent is connected to.
The first mechanism is the link-address field in the Relay-forward
and Relay-reply messages. The link-address field uniquely identifies
the link and should not be mistaken for a link-local address. In
normal circumstances, this is the solution that is easiest to
maintain, as existing address assignments can be used and no
additional administrative actions (like assigning dedicated
identifiers for each relay agent, making sure they are unique, and
maintaining a list of such identifiers) are needed. It requires,
however, for the relay agent to have an address with a scope larger
than link-local configured on its client-facing interface.
