From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=aDpxeYpX; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 1309B5A0269 for ; Fri, 26 Jun 2026 04:45:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782441924; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9+X/sNP93Op3lXOp6X8kuIaWiAo6FRlaPd7rVgbWH6s=; b=aDpxeYpX0N7Xp1n2iTqDSY/XxC/y8kXX/FDA5P2hTc16AQr7gjpKx5V4Mq7f9nto+gdf/0 hIK/uv5bLkOrY5VAzq2hKzriqVL3h7V/kECcSjeXO2dDyGOazeHYu05mh4O7p5RnjUs8nA d1NZ8sWne+6oIAu9HFH7FLoSpezdRKY= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-401-tHXnC5ZvPCSscsCrR-0inA-1; Thu, 25 Jun 2026 22:45:23 -0400 X-MC-Unique: tHXnC5ZvPCSscsCrR-0inA-1 X-Mimecast-MFC-AGG-ID: tHXnC5ZvPCSscsCrR-0inA_1782441922 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B75E91954121; Fri, 26 Jun 2026 02:45:22 +0000 (UTC) Received: from jmaloy-thinkpadp16vgen1.rmtcaqc.csb (unknown [10.22.88.44]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 985F91956087; Fri, 26 Jun 2026 02:45:21 +0000 (UTC) From: Jon Maloy To: sbrivio@redhat.com, david@gibson.dropbear.id.au, jmaloy@redhat.com, passt-dev@passt.top Subject: [PATCH v8 01/14] dhcpv6: Fix reply destination to match client's source address Date: Thu, 25 Jun 2026 22:45:06 -0400 Message-ID: <20260626024519.3701556-2-jmaloy@redhat.com> In-Reply-To: <20260626024519.3701556-1-jmaloy@redhat.com> References: <20260626024519.3701556-1-jmaloy@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: CAEJVBjx8UuzC4J04tuuglWozmF7OkvRyPh-bpJDWyk_1782441922 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true Message-ID-Hash: EY7MTXGNCL7LEA5Y6PWHCSDY4XVMF2LT X-Message-ID-Hash: EY7MTXGNCL7LEA5Y6PWHCSDY4XVMF2LT X-MailFrom: jmaloy@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 9915 (section 18.3.10) allows clients to use global addresses for DHCPv6, we now correct this, and always respond to the address the client was using. We also remove a redundant addr_ll_seen assignment, since this is already done by tap.c when processing IPv6 packets. Note: if the client uses a global source address, our reply will still have a link-local source, creating a scope mismatch. Fixing this properly would require a mechanism to allocate a global address for the DHCPv6 server, which we currently don't have. Responding to the client's actual source address is still a net improvement over the previous behavior of replying to an unrelated cached address. Note 2: This commit isn't actually a fix to an observed problem, but rather an answer to a theoretical issue, adding completeness to the mechanism and simplifying subsequent changes in this series. Signed-off-by: Jon Maloy --- v8: -Updated commit log, acknowledging concerns expressed by David and Stefano. -Some minor changes also addressing feedback from the same persons. --- dhcpv6.c | 16 ++++++++-------- dhcpv6.h | 2 +- tap.c | 15 --------------- tap.h | 2 -- 4 files changed, 9 insertions(+), 26 deletions(-) diff --git a/dhcpv6.c b/dhcpv6.c index 97c04e2c..29c7e320 100644 --- a/dhcpv6.c +++ b/dhcpv6.c @@ -370,12 +370,14 @@ notonlink: /** * dhcpv6_send_ia_notonlink() - Send NotOnLink status * @c: Execution context + * @caddr: Source address of client message (reply destination) * @ia_base: Non-appropriate IA_NA or IA_TA base * @client_id_base: Client ID message option base * @len: Client ID length * @xid: Transaction ID for message exchange */ static void dhcpv6_send_ia_notonlink(struct ctx *c, + const struct in6_addr *caddr, const struct iov_tail *ia_base, const struct iov_tail *client_id_base, int len, uint32_t xid) @@ -405,8 +407,7 @@ static void dhcpv6_send_ia_notonlink(struct ctx *c, resp_not_on_link.hdr.xid = xid; - tap_udp6_send(c, src, 547, tap_ip6_daddr(c, src), 546, - xid, &resp_not_on_link, n); + tap_udp6_send(c, src, 547, caddr, 546, xid, &resp_not_on_link, n); } /** @@ -590,8 +591,6 @@ int dhcpv6(struct ctx *c, struct iov_tail *data, if (mlen + sizeof(*uh) != ntohs(uh->len) || mlen < sizeof(*mh)) return -1; - c->ip6.addr_ll_seen = *saddr; - src = &c->ip6.our_tap_ll; mh = IOV_REMOVE_HEADER(data, mh_storage); @@ -630,8 +629,10 @@ int dhcpv6(struct ctx *c, struct iov_tail *data, if (dhcpv6_ia_notonlink(data, &c->ip6.addr)) { - dhcpv6_send_ia_notonlink(c, data, &client_id_base, - ntohs(client_id->l), mh->xid); + dhcpv6_send_ia_notonlink(c, saddr, data, + &client_id_base, + ntohs(client_id->l), + mh->xid); return 1; } @@ -680,8 +681,7 @@ int dhcpv6(struct ctx *c, struct iov_tail *data, resp.hdr.xid = mh->xid; - tap_udp6_send(c, src, 547, tap_ip6_daddr(c, src), 546, - mh->xid, &resp, n); + tap_udp6_send(c, src, 547, saddr, 546, mh->xid, &resp, n); c->ip6.addr_seen = c->ip6.addr; return 1; diff --git a/dhcpv6.h b/dhcpv6.h index c706dfdb..1015a1a7 100644 --- a/dhcpv6.h +++ b/dhcpv6.h @@ -7,7 +7,7 @@ #define DHCPV6_H int dhcpv6(struct ctx *c, struct iov_tail *data, - struct in6_addr *saddr, struct in6_addr *daddr); + const struct in6_addr *saddr, const struct in6_addr *daddr); void dhcpv6_init(const struct ctx *c); #endif /* DHCPV6_H */ diff --git a/tap.c b/tap.c index 6d93c7ce..d4189617 100644 --- a/tap.c +++ b/tap.c @@ -160,21 +160,6 @@ void tap_send_single(const struct ctx *c, const void *data, size_t l2len) } } -/** - * tap_ip6_daddr() - Normal IPv6 destination address for inbound packets - * @c: Execution context - * @src: Source address - * - * Return: pointer to IPv6 address - */ -const struct in6_addr *tap_ip6_daddr(const struct ctx *c, - const struct in6_addr *src) -{ - if (IN6_IS_ADDR_LINKLOCAL(src)) - return &c->ip6.addr_ll_seen; - return &c->ip6.addr_seen; -} - /** * tap_push_l2h() - Build an L2 header for an inbound packet * @c: Execution context diff --git a/tap.h b/tap.h index 07ca0965..b335933f 100644 --- a/tap.h +++ b/tap.h @@ -96,8 +96,6 @@ void tap_udp4_send(const struct ctx *c, struct in_addr src, in_port_t sport, const void *in, size_t dlen); void tap_icmp4_send(const struct ctx *c, struct in_addr src, struct in_addr dst, const void *in, const void *src_mac, size_t l4len); -const struct in6_addr *tap_ip6_daddr(const struct ctx *c, - const struct in6_addr *src); void *tap_push_ip6h(struct ipv6hdr *ip6h, const struct in6_addr *src, const struct in6_addr *dst, size_t l4len, uint8_t proto, uint32_t flow); -- 2.52.0