This is useful work, thanks. My reply is below.
Simon.
Violation 1:
Looks quite straightforward and accurate - I'll work on a fix.
Violation 3:
The server does not have a configuration option to enable or
disable rapid commit. It always allows rapid commit. (There is
a rapid-commit configuration for DHCPv4, but this doesn't apply
to DHCPv6 and is documented as such.) Since the server always
allows rapid-commit, the behaviour is correct. One could argue
that a rapid-comit configuration option would be useful, but it is
not, as far as I can see, required.
Violation 4:
This should probably be altered so that the behaviour is
controlled by the "dhcp-authoritative" option, which controls
the same behaviour in the same way in DHCPv4.
Violation 5:
Looks correct and will be fixed.
Violation 6:
Trivial fix, will be done.
Violation 7:
I think this is not a problem. The MUST condition applies to
clients which are creating messages sent to server.
There is no condition that a server MUST reject messages which
violate this condition, and without that the Robustness Principle
applies and a the server should be liberal in what it accepts.
Violation 8:
Re-reading RFC3315, I can see how I misundertood this when writing
the code originally. It's clearer in 8415. Definitely a problem.
In the fix list.
Violation 9:
Fixing this probably comes for free with violation 8.
Violation 10:
Since dnsmasq doesn't support DHCP-PD, it never assigns delegated
prefixes. The behaviour is therefore arguably correct.
Violation 11:
This needs more thought. dnsmasq's relay system uses local
storage to hold the scope-id over a relay transaction, so
in almost all cases, no Interface-ID option is needed. One
could conceive of a relay which has two distinct interfaces
with the same prefix on which it can recieve DHCPv6 messages.
That would confuse the existing mechanism.
I'm not sure if that's a realistic scenario.
Violation 12: My answer to Violation 7 applies here.
On 7/18/25 03:41, 宋相普 wrote:
Sorry, I’ve just added the PDF report as an attachment.
This is my first time discussing through the mailing list, so I’m not
very familiar with some of the procedures.
发件人：Dan Schaper <[email protected]>
发送日期：2025-07-18 08:48:51
收件人："宋相普" <[email protected]>,dnsmasq-
[email protected]
主题：Re: [Dnsmasq-discuss] DHCPv6 Protocol Compliance Violations in DNSMASQ
Can you provide your report in a PDF please. I'm quite surprised
that a security researcher would provide proof via a zipfile of
unknown provenance and unknown content.
Dan
------ Original Message ------
From "宋相普" <[email protected]
<mailto:[email protected]>>
To [email protected] <mailto:dnsmasq-
[email protected]>
Date 7/16/2025 7:02:19 AM
Subject [Dnsmasq-discuss] DHCPv6 Protocol Compliance Violations in
DNSMASQ
Hi,
We are writing to report the results of a recent analysis we
conducted on the DHCPv6 implementation in |dnsmasq|. Our work
focused on verifying its compliance against the most recent DHCPv6
specification, RFC 8415.
During our analysis, we identified dozens of instances where the
implementation's behavior deviates from the mandatory requirements
of the RFC. While many of these are minor protocol non-
compliances, several have potential security implications that we
believe warrant a high-priority review.
Due to the number of findings, we have compiled a comprehensive
report detailing each issue, which is provided as an attachment to
this email. We hope this report is helpful.
Best regards,
Xiangpu Song
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
