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=G9FDJqD0; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 342F85A0265 for ; Wed, 01 Jul 2026 19:00:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782925222; 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=eS5VVSqYH/EKANK1cG7/Z3t2ACp+9RwKlUbcqlRvxiY=; b=G9FDJqD00/ygd19H77uScDiVWKtU+QJwYQt3vG+LTDDaOAD557En65t+5Lu9oO2+5dcSw9 MqhIWvUx9br6RG6xyID9IcUllvEzIx494l3CaSfgaxohlXhvl5neNXUxRWnLm2pz9FOi0E B0xxi78bUODPhz5jzim8fgPKckFAtFY= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-448-O6HGze-zO6acsjKs00sAAg-1; Wed, 01 Jul 2026 13:00:20 -0400 X-MC-Unique: O6HGze-zO6acsjKs00sAAg-1 X-Mimecast-MFC-AGG-ID: O6HGze-zO6acsjKs00sAAg_1782925219 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-493bb6a4336so8342085e9.3 for ; Wed, 01 Jul 2026 10:00:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782925219; x=1783530019; h=date:content-transfer-encoding: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; bh=eS5VVSqYH/EKANK1cG7/Z3t2ACp+9RwKlUbcqlRvxiY=; b=Zehi8cyrNH46zUNH5ixQapyqYDcYsRqQ3W8DlhngM+3zOJHWPdlUlG/V/FqudU578j BTYInDlVe+KLOexcdYtqso/KnP3K9ynxAxx/2dbTvShgB01WU9f+BqmnG9vURkJx/ehp 3UuYZXMjZ02Qvmg9nK2UR+bYQVVRAIBYq8xxiiIMtbbGr1oJhP6ly0a08DbWVY7ro6FC Z2LWqRNeti4qlPpEs4x0CPkB2tHKYupu0mpIuzJRGWU2l3UjiMoE6eGGUi7yf6CevQrc IDeNnNkUtXWYbVuxocWCaM6/6fc1dNu3LhZsYf3Qv4+IVBoMUd2ETDfRvETDiycHQlRZ XcsQ== X-Forwarded-Encrypted: i=1; AFNElJ+iPE2/n/5U0PqbYOP2KNNwuBHtdKyBxqX4AXp+qfq4e2Dkpl5dyrAzNG4ff4mWaO4JuQTeyxd851o=@passt.top X-Gm-Message-State: AOJu0YxnJxCjegtRQuqqTCnHO7wtOfjA16qI8iCZcv7hwv+dvV8WiIRR D4WNx/+yNAptQ4RFj2a9BaIB14I91y6x1E4Fm/Jj7rMa58HkXLUElKc7HIj9NCo2DV3s9Ky9TTR SqmRkUuHJ28aTpESpbic8V+ipoN2fzM+FmQfBuTlj1aeQfSCK4ZtpyHUs69FaiA== X-Gm-Gg: AfdE7cnHzDYnMFZpjwLoKiR5Fj/fb3mhxm55Hsgow0J1h4vBJ68cBiNdZu2O1wFrcDZ TiqEiBeEoCpjUk6n4ImiJST9njuoPCWlRFdAIaATA6kvO0PdO0c0r2uLdjoCJz6mZ8/Mesg0W9C +JdQRVBSVGgUuL6FVtvjaxdZd5z5niyEgmvCirMt9nsXqvDxGif1lqcGeydYskRSV4uV/8hiiJ8 Iw6XHV55FinT9qCyHR86bB/BIvLvsXQw699mWkiMfB/bpmKxCAk2lz/NGiJ/sykzkabnQCy6sXG jr3JLogjlM2X9uCRNXUjiwjtr+I+Y0PKfu1jZ2Dy0YSFuEew5zGoTpuYfrK+Ohi1LPehqUBOHus izrkGHJZj6U4WCP5guhWNag== X-Received: by 2002:a05:600d:c:b0:493:aa28:38ad with SMTP id 5b1f17b1804b1-493c2b4442emr30066925e9.10.1782925218951; Wed, 01 Jul 2026 10:00:18 -0700 (PDT) X-Received: by 2002:a05:600d:c:b0:493:aa28:38ad with SMTP id 5b1f17b1804b1-493c2b4442emr30066605e9.10.1782925218362; Wed, 01 Jul 2026 10:00:18 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-477dbe617b1sm1209205f8f.16.2026.07.01.10.00.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jul 2026 10:00:17 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v2 2/2] dhcpv6: Inject custom options into DHCPv6 replies Message-ID: <20260701190011.0247be2b@elisabeth> In-Reply-To: References: <20260618120529.1768765-1-anskuma@redhat.com> <20260618120529.1768765-3-anskuma@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: Wed, 01 Jul 2026 19:00:11 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: LX4ItbGhCuHbl0U94jPio47jkYPSUdXEEkbzxZT7kCY_1782925219 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: DNV4OJ7SXXYNVSOGD4YR73KKQZH257UL X-Message-ID-Hash: DNV4OJ7SXXYNVSOGD4YR73KKQZH257UL 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: Anshu Kumari , passt-dev@passt.top, lvivier@redhat.com, jmaloy@redhat.com 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 Fri, 19 Jun 2026 14:03:10 +1000 David Gibson wrote: > On Thu, Jun 18, 2026 at 05:35:29PM +0530, Anshu Kumari wrote: > > Append user-specified options from --dhcpv6-opt to DHCPv6 reply > > messages. Options are parsed from the stored string value at reply > > time using dhcpv6_opt_parse(), and skipped with a debug message if > > they exceed the available space. > > > > Link: https://bugs.passt.top/show_bug.cgi?id=192 > > Signed-off-by: Anshu Kumari > > --- > > v2: > > - Updated dhcpv6_custom_opts_fill() to parse str at reply time > > using dhcpv6_opt_parse() instead of copying cached val/len. > > As with DHCPv4, it's not that I'm against storing the parsed values > persistently, just that I'm against storing them twice. With this revision, they're not stored, but still parsed twice, and: > The existing > data structures for DHCPv6 are different, so maybe there's not an > obvious place to store pre-parsed options. ...yes, I guess this is one reason, but as we only let users specify options we have in the table, we could actually make space for that by declaring an array of 64 KiB * 84 entries. The highest option number we currently support is 83, and IANA only registered up to number 150, so I would expect it to remain within a reasonable range, and in any case only memory initialised here is actually used / allocated. Another bit missing would be the rendering of binary values back to human-readable ones for conf_print() purposes. That looks like a bit more effort. On the other hand, one day we'll probably want to have pesto(1) configure this stuff at runtime, and sharing binary values between processes looks more practical than sharing configuration strings... so I'd tend to say that it's effort we will need anyway at some point. If it's too complicated for whatever reason, I'm fine with the current approach as well. I'd just suggest to make enough room for all the options we support, because that part is simple. -- Stefano