Index | Thread | Search

From:
Carsten Strotmann <carsten@strotmann.de>
Subject:
OpenBSD dhcrelay6 and Kea-DHCPv6
To:
tech@openbsd.org
Date:
Wed, 19 Mar 2025 10:59:26 +0100

Download raw body.

Thread
  • Carsten Strotmann:

    OpenBSD dhcrelay6 and Kea-DHCPv6

Hello,

I'm debugging an issue between OpenBSD "dhrelay6" as an DHCPv6 relay agent and the Kea-DHCPv6 server.

Kea-DHCP ist the successor of ISC-DHCP.

When receiving a "RELAY-FORWARD" message via "dhcrelay6", Kea-DHCP is not able to identify the client subnet.

"dhcrelay6" places the link-local address of the client facing network interface into the "link-address" field. The client facing network interface has an ULA address configured.

RFC 8415 states: https://www.rfc-editor.org/rfc/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.

In my view "dhcrelay6" is not fully compliant with the RFC, because despite an ULA or GUA address on the client facing interface, it is using the link local address in the link-address field.

In the code I've found in function "relay6_pushrelaymsg" (dhcrelay6.c line 581)

	/*
	 * XXX RFC 6221 Section 6.1: layer 2 mode does not set
	 * linkaddr, but we'll use our link-local always to identify the
	 * interface where the packet came in so we don't need to keep
	 * the interface addresses updated.
	 */

     dsr->dsr_linkaddr = intf->linklocal;

This puts the link-local address into the link-address field, which is correct for RFC 6221 "Lightweight DHCPv6 Relay Agent", but maybe not for a RFC 8415 "Fat DHCPv6 Relay Agent".

As a proof-of-concept I've changed the code to put the hardcoded IPv6 ULA-address of the client-facing interface into the link-address field:

	struct in6_addr ip6addr;
	inet_pton(AF_INET6,"fd00:100::1",&ip6addr);
	dsr->dsr_linkaddr = ip6addr;

Using this code, the "client - relay - server" works without issues and the client gets the IPv6 ULA address from the server.

Possibly a conditional switch that either sets the first ULA/GUA address of the client facing interface into the link-address field (or an address given as a parameter on the command line), in case LDRA is not enabled, will help solving this issue between Kea-DHCP and "dhcrelay6".

I would appreciate if someone here could take a look and let me know if my assessment is correct. Maybe the dhcrelay6 places the link-local address on purpose.

I'm not a good C-Coder, but I could try to come up with a patch, but maybe it is quicker if someone with experience with OpenBSD network code could create a fix.

Best regards

Carsten Strotmann