🐛 Fix DHCPv6 PXE boot: use option6:61 for arch detection

[holmboe]

Summary

• Fix DHCPv6 PXE boot by replacing option:client-arch (DHCPv4-only alias for option 93) with option6:client-arch (DHCPv6 option 61, RFC 5970)
• Replace impossible BIOS fallback (undionly.kpxe over IPv6) with x86_64 EFI fallback for PXE clients whose architecture could not be determined

Root cause

The IPv6 section of dnsmasq.conf.j2 used option:client-arch in dhcp-match directives. In dnsmasq, option: is a DHCPv4-only prefix — it resolves client-arch to option 93 via opttab[] and adds the match rule to daemon->dhcp_match. The DHCPv6 server code (rfc3315.c) only iterates daemon->dhcp_match6, so these rules were silently ignored. The amd64/arm64 tags were never set, the EFI bootfile was never served, and UEFI nodes could not PXE boot over IPv6.

The correct syntax is option6:client-arch, which resolves to DHCPv6 option 61 via opttab6[]. Both EDK2/OVMF and iPXE send this option in DHCPv6 SOLICIT messages.

Note: option6:client-arch requires the client-arch entry in dnsmasq's opttab6[] table. Upstream dnsmasq is missing this entry, but Red Hat has carried a downstream patch adding it since 2021, which is included in the CentOS Stream 9 base image used by this container.

Test plan

• make build succeeds (w/ CONTAINER_ENGINE=docker make build)
• Deploy with IPV=6 and verify dnsmasq config renders correctly
• UEFI amd64 node with EDK2/OVMF (libvirt) PXE boots over IPv6 and receives snponly-x86_64.efi
• UEFI amd64 node with igb (Gigabyte server) PXE boots over IPv6 and receives snponly-x86_64.efi
• UEFI arm64 node PXE boots over IPv6 and receives snponly-arm64.efi -- will not be tested, no access to relevant hardware
• iPXE chainloading (boot.ipxe) still works when IPXE_TLS_SETUP != "true" -- will not be tested, hoping for relevant e2e tests

Fixes: #916

---

UPDATE: Play it safe re. upstream dnsmasq vs Red Hat patches by using option6:61 in favor of alias option6:client-arch.

[metal3-io-bot]

Hi @holmboe. Thanks for your PR.

I'm waiting for a metal3-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[holmboe]

https://opendev.org/openstack/ironic-inspector/commit/29dce28b13323970e1e0b0b56b29b6162b8dfbf2 is relevant to anyone reviewing this PR.

[holmboe]

The DHCP options does not carry the same option number in DHCP for IPv4 and DHCPv6.

client-arch is number 61 in DHCPv6:

bash-5.1$ dnsmasq --help dhcp6
Known DHCPv6 options:
 21 sip-server-domain
 22 sip-server
 23 dns-server
 24 domain-search
 27 nis-server
 28 nis+-server
 29 nis-domain
 30 nis+-domain
 31 sntp-server
 32 information-refresh-time
 56 ntp-server
 59 bootfile-url
 60 bootfile-param
 61 client-arch
 62 client-interface-id

client-arch is number 93 in DHCP for IPv4:

bash-5.1$ dnsmasq --help dhcp
Known DHCP options:
  1 netmask
  2 time-offset
  3 router
  6 dns-server
  7 log-server
  9 lpr-server
 13 boot-file-size
 15 domain-name
 16 swap-server
 17 root-path
 18 extension-path
 19 ip-forward-enable
 20 non-local-source-routing
 21 policy-filter
 22 max-datagram-reassembly
 23 default-ttl
 26 mtu
 27 all-subnets-local
 31 router-discovery
 32 router-solicitation
 33 static-route
 34 trailer-encapsulation
 35 arp-timeout
 36 ethernet-encap
 37 tcp-ttl
 38 tcp-keepalive
 40 nis-domain
 41 nis-server
 42 ntp-server
 44 netbios-ns
 45 netbios-dd
 46 netbios-nodetype
 47 netbios-scope
 48 x-windows-fs
 49 x-windows-dm
 58 T1
 59 T2
 60 vendor-class
 64 nis+-domain
 65 nis+-server
 66 tftp-server
 67 bootfile-name
 68 mobile-ip-home
 69 smtp-server
 70 pop3-server
 71 nntp-server
 74 irc-server
 77 user-class
 80 rapid-commit
 93 client-arch
 94 client-interface-id
 97 client-machine-id
119 domain-search
120 sip-server
121 classless-static-route
125 vendor-id-encap
150 tftp-server-address
255 server-ip-address

[diconico07]

I don't think we have IPv6 e2e tests, but these changes are looking good to me

[tuminoid]

/ok-to-test
/cc @Rozzii

[tuminoid]

/test metal3-centos-e2e-integration-test-main
/test metal3-ubuntu-e2e-integration-test-main

[kema-dev]

Comming from #924, I can confirm that this works fine for amd64 IPv6, thank you

[tuminoid]

LGTM too but I'm not dhcp guy.
/cc @Rozzii @elfosardo @dtantsur

[Copilot]

Pull request overview

Updates the dnsmasq Jinja2 template to correctly detect PXE client architecture during DHCPv6 so UEFI nodes can receive an appropriate bootfile URL and successfully PXE boot over IPv6.

Changes:

• Switch DHCPv6 architecture matching from option:client-arch (DHCPv4-only) to DHCPv6 option 61 via option6:61.
• Replace the IPv6 “BIOS fallback” (undionly.kpxe over IPv6) with an x86_64 EFI fallback when arch detection fails.
• Add template comments clarifying why numeric option 61 is used instead of the client-arch alias.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[elfosardo]

/hold
I would like to test this before merging

[elfosardo]

/unhold
/approve

I've tested it with ipv6 only and it looks good

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: diconico07, elfosardo, kema-dev

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [elfosardo]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tuminoid]

/lgtm