IPv6 Support

[brk0v]

Context

Tinkerbell's provisioning flow is currently centered on IPv4.

As a result, in IPv6 environments, operators who want IPv6-only bare metal provisioning still need to maintain an IPv4 island for discovery, netboot, or early OS installation, even when the target environment is otherwise IPv6-native.

Goals / Non-goals

Goals:

• Add first-class IPv6 support.

Non-goals:

• Redesign Tinkerbell's provisioning architecture. The goal is to evolve the existing model so that IPv6 is supported, documented, and tested.

Proposal

• Extend Smee to support new DHCPv6 modes.
  • We can start with stateless DHCPv6 with SLAAC and RA for addresses.
• Extend other components to be able to listen on and serve over IPv6.
• Update Helm charts and templates to support IPv6.

Open Question

• Is IP dual-stack support needed? The dual-stack could be beneficial in theory, but it would make the system more complex.

Rationale

One alternative is to keep Tinkerbell IPv4-only and require operators to maintain an IPv4 provisioning network even for IPv6-native infrastructure. That is the lowest-effort option from an engineering perspective, but it pushes cost and operational complexity onto users.

[rpardini]

Hmm. I've a feeling that most people looking into IPv6-only netbooting are skipping directly to UEFI HTTP Boot, with some variation of ra-stateless and DHCPv6's option 59? This requires SLAAC/DHCPv6 coordination (thus out-of-scope for Smee?), and, once attained, IPv6 becomes a bit of a detail given proper IPv6 support in the low-level firmware.

There is indeed probably quite a bit of work ref supporting ipv6-only when matching/looking up packets to Hardware via IP -- AFAIK that is only ever done for IPv4.

[brk0v]

Thank you for your time and thoughts.

Hmm. I've a feeling that most people looking into IPv6-only netbooting are skipping directly to UEFI HTTP Boot, with some variation of ra-stateless and DHCPv6's option 59? This requires SLAAC/DHCPv6 coordination (thus out-of-scope for Smee?), and, once attained, IPv6 becomes a bit of a detail given proper IPv6 support in the low-level firmware.

From my point of view, one of the main strengths of Tinkerbell, and Smee as part of it, is the ability to orchestrate the netboot flow through the Kubernetes CRD API: from the very first network boot step all the way to the workflow execution.

It gives us one ring to rule them all :)

So I would say that Stateless DHCPv6 support in Smee could still be beneficial, even in an IPv6-only HTTP Boot world.

With Stateless DHCPv6, Smee/Tinkerbell can still control things like:

• Which iPXE binary to return: architecture, platform, and version.
  This gives us a clean place to build release cycles for boot artifacts.
• Which iPXE script content to return.
  Same idea: releases, experiments, rollouts, and hardware-specific behavior can be driven from the Tinkerbell API.

If the idea is to avoid iPXE entirely because UEFI already supports HTTP Boot, I agree that’s possible. However, keeping iPXE in the flow can still be useful because it reduces how much we depend on each vendor’s firmware implementation behaving correctly and consistently.

There is also value in staying close to the DHCPv6 exchange itself, because real hardware and software do not always follow the specs perfectly. Being in that path gives Smee the ability to add compatibility guards for different firmware implementations.

For example:

• In this Kea issue, the DHCPv6 client expects HTTPClient to be present in the server response in option 16, Vendor Class: https://gitlab.isc.org/isc-projects/kea/-/issues/3700
• The current QEMU/EDK2 IPv6 HTTP Boot implementation appears to do the same kind of validation: https://github.com/tianocore/edk2/blob/fcac2f3a6dfc7d7ba24ae12c70264e9caca1bf53/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c#L247

If we go with an external DHCPv6 server, then we likely need additional services/scripts, or a dedicated custom controller to translate Tinkerbell CRD state into that external DHCPv6 configuration.

There is indeed probably quite a bit of work ref supporting ipv6-only when matching/looking up packets to Hardware via IP -- AFAIK that is only ever done for IPv4.

If you're talking about:

type HardwareFilter struct {
	InNamespace  string
	ByName       string
	ByAgentID    string
	ByMACAddress string
	ByIPAddress  string
	ByInstanceID string
}

In case of stateless DHCPv6, Smee doesn't need to know the IPv6 address, so the logic should build around other filters. I don't know if there is any issues with this, tho.