[Dnsmasq-discuss] [PATCH] DHCPv6: Information-request containing IA_PD is answered instead of discarded

[Qingyang Zhou]

Hi,

RFC 8415 section 16.12 requires a server to discard any Information-request
that includes an IA option. dnsmasq's check tests IA_NA and IA_TA but not
IA_PD, so an Information-request carrying an IA_PD option is answered with a
Reply rather than dropped.

Present in current master: 1f12252 ("Make configuration for DHCPv4 options
and DHCPv6 options consistent.", 2026-07-27), i.e. v2.93-16-g1f12252.

Section 16.12:

    Servers MUST discard any received Information-request message that
    meets any of the following conditions:

    -  the message includes a Server Identifier option (see
       Section 21.3), and the DUID in the option does not match the
       server's DUID.

    -  the message includes an IA option.

IA_PD is an IA option: section 12 defines an Identity Association as
covering addresses *or* delegated prefixes, so IA_NA, IA_TA and IA_PD are
all in scope.

In src/rfc3315.c, the DHCP6IREQ case:

      case DHCP6IREQ:
        {
          /* 3315 para 15.12 */
          if (opt6_find(state->packet_options, state->end, OPTION6_IA_NA, 1) ||
              opt6_find(state->packet_options, state->end, OPTION6_IA_TA, 1))
            return 0;

OPTION6_IA_PD is missing. The comment's reference explains how: RFC 3315 had
no prefix delegation (that was RFC 3633), and the merged RFC 8415 renumbered
the clause to 16.12 and brought IA_PD into its scope.

The server-id half of 16.12 is implemented correctly, and IA_NA and IA_TA are
both discarded as they should be -- so only the IA_PD arm of the test is
absent.

What I see: an Information-request carrying IA_PD gets a Reply that is
byte-for-byte identical to the Reply for the same message with no IA option
at all. The IA_PD is simply ignored rather than acted on.

Patch below. With it applied, the IA_PD case is dropped, IA_NA and IA_TA stay
dropped, and an Information-request with no IA option still gets its Reply --
so it does not over-correct.

If it is useful I can send a small standalone reproducer: it compiles
dnsmasq's own sources plus a ~150-line driver that calls dhcp6_reply()
directly, needs no root or network, and prints each reply. Happy to post it
or put it somewhere fetchable.

Found with a conformance checker that builds a reference model from RFC 8415
and compares dnsmasq's response against the response class the RFC requires.
This one is invisible to differential testing, since the reply dnsmasq sends
is a perfectly well-formed Reply with no error status.

Best regards,
Zhou Qingyang

--- a/src/rfc3315.c
+++ b/src/rfc3315.c
@@ -1126,9 +1126,14 @@

     case DHCP6IREQ:
       {
-     /* 3315 para 15.12 */
+     /* RFC 8415 para 16.12: discard an Information-request that includes an
+        IA option. Para 12 defines an IA as covering addresses *or* delegated
+        prefixes, so IA_PD counts alongside IA_NA and IA_TA. (The older
+        reference was to RFC 3315 para 15.12, which predates prefix
+        delegation.) */
      if (opt6_find(state->packet_options, state->end, OPTION6_IA_NA, 1) ||
-         opt6_find(state->packet_options, state->end, OPTION6_IA_TA, 1))
+         opt6_find(state->packet_options, state->end, OPTION6_IA_TA, 1) ||
+         opt6_find(state->packet_options, state->end, OPTION6_IA_PD, 1))
        return 0;

      /* We can't discriminate contexts based on address, as we don't know it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20260809/a7e9534a/attachment-0001.htm>