# 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.

## Per-link verdict table

| # | 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.