Fork: 0
OpenStack / openstack-caracal-dc-dc
Transfer to URL with SHA Find file
Newer
Older
openstack-caracal-dc-dc / docs / audit / container-elim-pass / pass6-w1-maas-ipv6-feasibility.md
@JANeumatrix JANeumatrix 4 hours ago 10 KB IPv6 FEASIBILITY re-check (pass6, web-researched) -- CORRECTS pass5's reliance on prior rulings
Raw Blame History

Pass 6 / W1 -- MAAS 3.7 IPv6 feasibility (fresh capability research, no prior-ruling deference)

Date: 2026-08-10 Scope: per orchestrator instruction -- assess actual platform capability for IPv6 on MAAS provisioning/control-plane links, independent of any prior repo ruling (D-101/D-139/D-143). A prior ruling that a link "is v4" is not treated as evidence v6 is infeasible. Deployed targets: MAAS 3.7.2, Ubuntu 24.04/22.04 nodes, kernel 5.15/6.8.

Web research: SUCCEEDED (WebSearch + WebFetch, ~20 queries/fetches against docs.maas.io / canonical.com/maas/docs, Launchpad, GitHub canonical/maas source, Ubuntu wiki, Intel support). Current canonical.com/maas/docs pages proved thinly-populated on IPv6 specifics (several fetches returned "no IPv6 content in this section"), so findings lean on: (a) Launchpad bug history showing which IPv6 code paths were fixed and in what version, (b) the MAAS source tree itself (regionservice.py / clusterservice.py / network.py) for RPC address-family handling, and (c) vendor/firmware documentation (Intel, Ubuntu wiki) for boot-ROM-level IPv6 constraints that sit below MAAS entirely. Each row below is sourced individually.

# Link Verdict The work / the exact blocker Capability citation Disagrees with prior ruling?
1a DHCPv6 for enlistment/commissioning FEASIBLE-WITH-WORK MAAS has supported IPv6 subnets/DHCPv6 since the 2.x line (rack-controller interface with a static IPv6 range; MAAS does not rely on RAs, configures static v6 routes). Two historical MAAS-side bugs that would have blocked this are both closed well before 3.7.2: LP#1718209 (DHCPv6 PXE conditional always evaluated false -> wrong bootloader) fixed 2017 in MAAS 2.2.3/2.3.0beta1; LP#1939034 (commissioning assigned IPv6 /128 instead of /64, causing manual DB cleanup) fixed in MAAS 3.1.0-beta1. MAAS's DHCP backend is isc-dhcp-server (not dnsmasq), which matters because dnsmasq explicitly lacks the DHCPv6 TFTP-boot extensions per Ubuntu's own netboot docs -- isc-dhcp-server is the one that supports them. Net: the enlistment/commissioning DHCPv6 path is architecturally present and its known defects are old and closed; what's missing is a measured test on this deployment (3.7.2, real NICs) -- it has never been run here. docs: canonical.com/maas/docs (rack ctrl IPv6 static-range requirement, no-RA design) via Canonical MAAS Discourse "IPv6 addressing" series (2.8/3.0); LP bugs #1718209, #1939034 (canonical.com/maas + bugs.launchpad.net/maas); Ubuntu Wiki UEFI/SecureBoot/PXE-IPv6 (dnsmasq DHCPv6-TFTP gap, isc-dhcp-server requirement); GitHub canonical/maas debian/control (isc-dhcp-server dependency) YES. Repo (D-143 note, docs/design-decisions.md:8332-8333) already correctly frames this as "UNVERIFIED, not asserted impossible" -- that framing matches this finding. But the operational ruling in D-101/D-139 (docs/design-decisions.md:2308, "PXE is v4-first... IPv4 retained: MAAS PXE / provisioning") reads as a settled constraint. Fresh research finds no MAAS-side capability blocker for DHCPv6 commissioning at 3.7.2 -- the gap is "never tested here," not "cannot work."
1b UEFI HTTP boot over IPv6 FEASIBLE-WITH-WORK, but UNVERIFIED at the doc level UEFI's HTTP-Boot feature (distinct from PXE/TFTP boot) is a firmware-and-network-stack capability that has supported IPv6 since UEFI added HTTP Boot (Intel Ethernet UEFI drivers explicitly support IPv6 for "remote boot solutions using UEFI"). MAAS 3.x does support HTTP boot as a boot method (added in the MAAS 3.1/3.2 era for UEFI targets generally), and the region controller's boot-resource HTTP server is the same HTTP service the docs say is reachable "the same way on IPv4 and IPv6" for the Web UI/API. However, none of the current canonical.com/maas/docs pages fetched (about-networking, about-maas-networking, what-maas-can-do, commissioning-machines/3.7) explicitly document IPv6 for the HTTP-boot path specifically -- it is inferred from (a) UEFI firmware-level v6 support and (b) MAAS's HTTP service being dual-stack-capable elsewhere, not confirmed end-to-end for boot. The work: a live test (NIC + firmware known to support UEFI HTTPBoot IPv6, e.g. modern server NICs on the deployed hardware) is needed to convert this from "should work" to "verified." Intel: "Discover If Intel Offers IPv6 Version of PXE" (intel.com/content/.../000007666) -- confirms UEFI drivers are IPv6-compatible for PXE/HTTP remote-boot, contrasted with legacy Boot Agent (row 1c); MAAS docs (region API/UI dual-stack claim) as corroborating but not boot-specific evidence Partial -- prior ruling never distinguished HTTP-boot from legacy PXE; this is a finer-grained finding the repo hasn't captured either way.
1c Legacy BIOS PXE over IPv6 INFEASIBLE Not a MAAS limitation at all -- it's a firmware/spec limitation below MAAS. Legacy PXE (Intel Boot Agent, PXE spec 2.1) is defined entirely within the IPv4 protocol suite; Intel states explicitly it has "no plans to update Intel Boot Agent for IPv6." There is no ratified PXE-over-IPv6 equivalent in the legacy-BIOS boot ROM world -- IPv6 netboot requires UEFI firmware (which uses a different boot protocol, not classic PXE). If any deployed node's NIC/firmware only offers legacy BIOS PXE (not UEFI), that specific node is a hard IPv4-only case regardless of anything MAAS does. Intel Support: "Discover If Intel Offers IPv6 Version of PXE" (intel.com, explicit "no plans... for IPv6"); corroborated by Cleverence "Legacy BIOS PXE Boot vs. UEFI" and Ubuntu Wiki UEFI/SecureBoot/PXE-IPv6 (IPv6 netboot documented only under the UEFI heading) No -- this one confirms a real constraint exists, but it's narrower than the repo's blanket "PXE is v4-first": it's specific to legacy-BIOS boot mode, not to MAAS or to UEFI nodes. If the fleet is UEFI-only (need to confirm against actual firmware mode in use), this blocker doesn't apply at all.
2 Rack controller <-> region controller RPC/websocket over IPv6 FEASIBLE-NOW No blocking work identified. The MAAS source tree treats IPv6 as a first-class RPC transport: provisioningserver/rpc/clusterservice.py's _build_rpc_info_urls() explicitly resolves and prefers AF_INET6 over AF_INET (sorts resolved addresses so IPv6 entries are tried first) and constructs bracketed IPv6 RPC URLs ([addr]:port). maasserver/rpc/regionservice.py likewise handles both AF_INET and AF_INET6 for the ports MAAS advertises. The one real historical bug in this area -- LP#2020142, "commission fails if maas-url uses an IPv6" (a Python socket.getaddrinfo() v4-first resolution quirk breaking ::-based MAAS_URLs) -- was Fix Released in MAAS 3.5.0-beta1 (2024-03-05), which is before the deployed 3.7.2. Region API URLs with IPv6 require bracket notation (http://[::1]:5240/MAAS/), a syntax detail, not a capability gap. GitHub canonical/maas src/provisioningserver/rpc/clusterservice.py and src/maasserver/rpc/regionservice.py (source-level AF_INET6 handling, IPv6-preference sort); Launchpad bug #2020142 (fix version 3.5.0-beta1); Canonical MAAS Discourse "IPv6 addressing" series (bracket-URL requirement) YES, materially. This directly contradicts treating the MAAS control plane as PXE-coupled-to-v4-forever. Rack<->region RPC is dual-stack-capable and IPv6-preferring in the current codebase, with the one known blocking bug fixed two minor versions before what's deployed. This is the strongest FEASIBLE-NOW finding in this set and should be surfaced as a real decision point, not filed under the same "v4-first" umbrella as PXE.
3 MAAS region API/UI over IPv6 FEASIBLE-NOW (minor, as scoped) Documented directly: "You can access the Web UI and the MAAS CLI (that is, logging in to the API server) in the same way on both IPv4 and IPv6." No firmware/boot-ROM dependency here (unlike rows 1a-1c) -- this is a normal dual-stack HTTP service. Only caveat is the bracket-notation requirement for IPv6 literals in MAAS_URL/CLI targets. Canonical MAAS Discourse "IPv6 addressing" series (2.8/3.0 CLI+UI docs, still architecturally current -- no code removed this capability between 2.8 and 3.7 in anything found) No direct repo ruling found narrowly on region API/UI address family; consistent with the repo's general v6-primary posture for non-PXE/non-boot surfaces.

Repo cross-check (read-only) -- ruling vs. measured test

  • docs/design-decisions.md:2307-2308 (D-101, amended 2026-07-09): rules "PXE itself stays v4-first regardless" and "IPv4 retained: MAAS PXE / provisioning (PXE is v4-first, unaffected by the metal-admin amendment above)". This is a judgement/ruling, not a report of a measured test -- no ping/dhclient/tcpdump-style evidence is cited alongside it in that section.
  • docs/design-decisions.md:2319: rationale text frames the v4-retention on PXE and datastore east-west as "explicitly justified rather than incidental" -- again policy language, not a test result.
  • docs/design-decisions.md:8332-8333 (2026-08-10 IPv6-unlock design note, pass5): the repo's own most recent language is more careful and matches this report's finding almost exactly -- "metal-admin PXE stays v4 by ruling (v6-only MAAS commissioning is UNVERIFIED, not asserted impossible)." This is the accurate framing; it is the older D-101/D-139 "PXE is v4-first" language elsewhere in the doc that reads more absolute than the evidence supports.
  • No grep hit anywhere in docs/design-decisions.md or the audit tree shows a MAAS-side DHCPv6/commissioning/HTTP-boot test ever having been run against this deployment (3.7.2) -- every reference found is policy language or the 2026-08-10 note flagging it as untested.

Bottom line for the orchestrator

  • Legacy-BIOS PXE-over-IPv6 is a genuine, vendor-confirmed INFEASIBLE (below MAAS, firmware spec-level) -- but only for nodes actually booting in legacy BIOS mode, not UEFI.
  • DHCPv6 commissioning and UEFI HTTP-boot-over-IPv6 are FEASIBLE-WITH-WORK: no MAAS-side capability blocker found for 3.7.2, all historically-blocking bugs closed years/versions before this deployment's version; the work is a live measured test on this repo's actual hardware, which has not happened yet.
  • Rack<->region RPC over IPv6 is the standout: FEASIBLE-NOW, source-level IPv6-preferring behavior, last blocking bug fixed in 3.5.0-beta1 (two minors before 3.7.2). This is the clearest disagreement with treating "MAAS control plane" as uniformly v4-first.