From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=fail (p=quarantine dis=none) header.from=redhat.com 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 1A5CC5A0265 for ; Mon, 02 Nov 2026 01:58:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1793581129; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UVkrWmpd5kYX9ZtihbAN6ycNjirs9muMZKcHtJ29tyU=; b=XQfGWV/XO50GI0nDnMB4qpDzAuagMOdK/I+VSIYK2bt3+fQp9lHBqcI3S8zlMehuPAVca+ AcVNZOKmVUua+h7ZsH1AiMJ9d/vb6FYNzYrX/IOVyYB83cn08iXeRB+AiyRXXQ7tMZnMKK ubh7+QZvcWA9zWhgp/nI8TC6bmb52YI= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-651-q_ZyiXG6MrCLVumEbYIYXA-1; Sun, 01 Nov 2026 19:58:47 -0500 X-MC-Unique: q_ZyiXG6MrCLVumEbYIYXA-1 X-Mimecast-MFC-AGG-ID: q_ZyiXG6MrCLVumEbYIYXA_1793581127 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-48e0c896d05so2082992f8f.1 for ; Sun, 01 Nov 2026 16:58:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793581127; x=1794185927; h=date:content-transfer-encoding:content-type:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=UVkrWmpd5kYX9ZtihbAN6ycNjirs9muMZKcHtJ29tyU=; b=vxO5TrfN5liN+D6WXi5eeTQahsxPMbDzgXUe2/jFND1JD00jFbAmjHw3tjVJq8Heod OiAUU6ZgepjL+WGs7FDIhek0ZnTKaCkr2teLkDV17ccCeN7dYZAIkb/VeoVihWq0hYzs 6j82MkxQZPRL4HrnaRAFHCumUiX8rGmPM/etZ03hAS5E5P1RwJfGO1JuY9jdegczP3yM dUki1tRJGvC3+RXHSdMrAs9otCORqGnBU15Tm24JHUIMlwJYEAQlHIAz0f3CkrDky7v8 VnDa/eMdElIFthrHWWoMHM2mexuD/NgiXv03UwvER+jONKP5gjr72cIVwofsSbUwC0t0 e3dQ== X-Forwarded-Encrypted: i=1; AKwUvBzjqKLog0AtpPb4tPmmnNUOf2UFKdHFJOPQDDlKl61zNTn2P/RjtUxBfErBg4+jruxr6/YaYN16lo0=@passt.top X-Gm-Message-State: APuU4Z9s/QbT+YSKqY56Bh6C6rwmQw2rTyF8soZNt3z3mJTWhKUb6Fmx 4ayTLYPg9LKQM7q0ofXFBjbT58G7dQaA4iPHkelIdy+9PE9mizCSe33PGI9dxmkVNwPBw7ZSo9s smoMBKfjhDmBhwRPUTqPKnqn0qn2hpvKFbq1De3RDpN5UF9OfGFvq9g== X-Gm-Gg: AYBFou1/UTWYAUT+0xGjq5LvvwuofiLJTwgW4weJcI8QjBca5oNsUNABJ6jVbYEcbcQ tk2L7LjeeCVntPm+qxokRDrWh4/8KJNJy6d3ur1hhupENsx47a95fQyX8kt8M+1x+JoeKpgFHvk c5yKN/pLrzs6t4RmLPeao1KbaMQUQWbcQltTlM+bnBZG6acN3uyVJiXofJwHdjCXrYk3c1/Oc9k mTzkkNNFhHjx0iC4/MpAtgraFRBRlb4Fp53WwVwIQpTTaYNWv9GUHdyeBJC97MJ8wvRS6oILuxz rdsZwC6QY7ihEcfpcqBriLH2SNjetq3AiDwkjvYlFxsQDAa6HmI9nihwyyzHm2zlmBS+yU7K34U OSIS1DtqJrTOfzVRyNENyCkiWBxigyXC2IIGE4L9bFVqSoEBz4Qb8YyiWN/io5J9TD1o= X-Received: by 2002:a05:6000:250c:b0:48e:1299:c00f with SMTP id ffacd0b85a97d-48e6e2db606mr20228351f8f.3.1793581126621; Sun, 01 Nov 2026 16:58:46 -0800 (PST) X-Received: by 2002:a05:6000:250c:b0:48e:1299:c00f with SMTP id ffacd0b85a97d-48e6e2db606mr20228340f8f.3.1793581126172; Sun, 01 Nov 2026 16:58:46 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e71b8a5a7sm17858369f8f.37.2026.11.01.16.58.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Nov 2026 16:58:45 -0800 (PST) From: Stefano Brivio To: Jon Maloy Subject: Re: [PATCH v13] passt, pasta: Introduce unified multi-address data structures Message-ID: <20261102015844.5a1f3cc0@elisabeth> In-Reply-To: <20261027231459.3461973-1-jmaloy@redhat.com> References: <20261027231459.3461973-1-jmaloy@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Mon, 02 Nov 2026 01:58:45 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Ma1-sLLBpvm0bVTraFiZSb5kbDr5PipdZPI-UMhAaxg_1793581127 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 2EKEY32CJ747HE4MFIKACLP7AOQHB4VX X-Message-ID-Hash: 2EKEY32CJ747HE4MFIKACLP7AOQHB4VX X-MailFrom: sbrivio@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 CC: david@gibson.dropbear.id.au, passt-dev@passt.top 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: On Tue, 27 Oct 2026 19:14:59 -0400 Jon Maloy wrote: > [...] > > +++ b/dhcpv6.c > @@ -318,7 +318,7 @@ static bool dhcpv6_opt(struct iov_tail *data, uint16_t type) > * false otherwise and @data is unmodified > */ > static bool dhcpv6_ia_notonlink(struct iov_tail *data, > - struct in6_addr *la) > + const struct in6_addr *la) > { > int ia_types[2] = { OPT_IA_NA, OPT_IA_TA }; > struct opt_ia_addr opt_addr_storage; > @@ -567,6 +567,7 @@ int dhcpv6(struct ctx *c, struct iov_tail *data, > struct opt_hdr client_id_storage; > /* cppcheck-suppress [variableScope,unmatchedSuppression] */ > struct opt_ia_na ia_storage; > + const struct guest_addr *a; > const struct in6_addr *src; > struct msg_hdr mh_storage; > const struct msg_hdr *mh; > @@ -574,6 +575,8 @@ int dhcpv6(struct ctx *c, struct iov_tail *data, > const struct udphdr *uh; > size_t mlen, n; > > + a = fwd_get_addr(c, AF_INET6, true, CONF_ADDR_ANY); > + > uh = IOV_REMOVE_HEADER(data, uh_storage); > if (!uh) > return -1; > @@ -627,7 +630,7 @@ int dhcpv6(struct ctx *c, struct iov_tail *data, > if (mh->type == TYPE_CONFIRM && server_id) > return -1; > > - if (dhcpv6_ia_notonlink(data, &c->ip6.addr)) { > + if (a && dhcpv6_ia_notonlink(data, &a->addr.a6)) { > > dhcpv6_send_ia_notonlink(c, saddr, data, > &client_id_base, > @@ -667,6 +670,14 @@ int dhcpv6(struct ctx *c, struct iov_tail *data, > default: > return -1; > } > + > + /* No address: INFORMATION_REQUEST can still be answered. For other Nit: it's called Information-request in the RFC (our define can't be called that way, but this is a comment about the message type). > + * types RFC 8415 requires a NoAddrsAvail reply, but silently dropping Nit: RFC 8415 was obsoleted by RFC 9915. > + * is acceptable here as this is a transient state. > + */ > + if (!a && mh->type != TYPE_INFORMATION_REQUEST) > + return 1; Partially pre-existing problem with Information-request: we're always including the IA_NA option, but we shouldn't, see Appendix B. of RFC 9915: +=========+========+========+=====+=====+===+====+=====+=====+=====+ | | Client | Server |IA_NA|IA_PD|ORO|Pref|Elap.|Relay|Auth.| | | ID | ID | | | | |Time |Msg. | | +=========+========+========+=====+=====+===+====+=====+=====+=====+ [...] +=========+--------+--------+-----+-----+---+----+-----+-----+-----+ | Inform. | * | (see | | | * | | * | | | | | | note) | | | | | | | | +=========+--------+--------+-----+-----+---+----+-----+-----+-----+ ...making things conceptually worse, until this patch, the address in the IA_NA option was always considered valid. Now we're sending an option that shouldn't be there (pre-existing) with a previous address that doesn't exist anymore (because it was set in resp.ia_na), if any, and an all-zero address otherwise. This new part of the old issue is just conceptual because we always have an IPv6 address to offer if DHCPv6 is enabled, so in practice this patch doesn't make things worse. Except for those two nits (which I can fix on merge) I wouldn't see a problem merging the patch like this. If we want to solve that issue before proceeding, though: - DHCPv6 doesn't have padding options, so we can't just zero it out. We would need to actually remove it - to do so, instead of a pre-formed IA_NA option, we would need to do something similar to what dhcpv6_dns_fill(), appending it only as needed and increasing the size of the message ('n') as needed. I haven't tried to do that. It doesn't look exceedingly complicated, but, if you think it is, then let's merge it this way for the moment being. Or maybe skip the Information-request reply if (!a), which should be slightly better than the alternative. Let me know what you think. -- Stefano