RFC: Supporting IPv6 in Provisioning, Registration & KEA

[lstejska]

Hello Community,

My team and I are preparing for the future support of the IPv6. As the title says, Provisioning and Registration are going to be the main challenges, but that’s not all; we also want to take care of these components:

• Foreman Ansible
• Compute resources
• Bootdisk, Discovery
• … and others

We are still in the investigation phase, with many unknowns and questions unanswered. So please take this RFC as an introduction to our effort. Your feedback, ideas, and involvement are welcomed; every help is much appreciated.

IPv4, Dual-stack, IPv6 only

Our effort aims to support and work in IPv4-only, Dual-stack, and IPv6-only setups.

Provisioning - KEA DHCP

ISC announced the End of Life for the older ISC DHCP system in 2022. This means that we must prepare to transition to a new system. Because of this, we would like to create a new Smart Proxy plugin for the KEA DHCP, allowing managing IPv4 and IPv6. The KEA plugin could later become a default DHCP provider for the Foreman and replace the ISC.

For the IPv6, we’d like to support stateful (DHCP) and stateless (SLAAC) host definition modes.

Host registration

Registering hosts from facts, discovery, or via global registration should work regardless of network setup. However, the current implementation only partially supports IPv6, particularly in handling multiple IPv6 addresses for one interface. We’ll also have to check the support of IPv6 in the provisioning templates.

Questions / To investigate

• IPv4 mapped IPv6 addresses.
• We must support stateful (DHCP) and stateless (SLAAC) modes of host definition.
• We use MAC addresses to render templates and detect hosts. This won’t work in DHCPv6 because it doesn’t store the MAC <> IPv6. KEA may have a solution for this (?)
• The file option in DHCPv6 cannot be set per record; it is only for all.
• We will focus on the EL family only; who will test others?

There is more to investigate, like specific settings required for IPv6 support, additional installer options, packaging, handling of different subnets, and so on. The mentions above are just the highlights of our effort now; more will surely come.

[Dirk]

@lstejska

We will focus on the EL family only; who will test others?

So this needs someone to test:

• Debian
• Ubuntu
• SLES
• (Windows and others)

Is also a testing for different Compute Resources and Bare Metal required?

I think testing the other Linux distributions is something I can help, will just need to find a way to enable IPv6 in my local setup and then route to our company network like with IPv4. IPv6 is already fully functional in our company network and I can perhaps get some assistance from those managing the network (and knowing IPv6 much better than I do). But this would only be a local system.

I know ATIX has a demo which is publicly available, but not sure if there is an IPv6 option. But asking @Bernhard_Suttner will cost nothing, so perhaps he knows or knows who knows and I think ATIX is also interested in having IPv6 support not only working for EL but all supported distributions.

[lstejska]

I created a Redmine task for tracking the effort: Tracker #37808: IPv6 support in Provisioning, Registration & Host management - Foreman

[ekohl]

I found a recent blog by Infoblox to be full of useful information: DHCP and DHCPv6: Commonalities and Differences | Infoblox

@lstejska

We use MAC addresses to render templates and detect hosts. This won’t work in DHCPv6 because it doesn’t store the MAC <> IPv6. KEA may have a solution for this (?)

For this I’d consider a solution where you don’t need to manage specific DHCP records anymore.

Today we modify it to point to a specific TFTP server with a specific filename. For IPv6 I’d consider always pointing to the same HTTPBoot server and modify the HTTP response based on the host state. I don’t know if you can do that, but not having to manage the DHCP server would be a major benefit for environments where the Foreman admin isn’t allowed by the networking team to manage DHCP.

Either way, we’ll need to design this area because the current DHCP module in smart-proxy is IPv4-only. How we want to solve it really depends on the design we create for IPv6. This is a big task with lots of open questions.

[lstejska]

@ekohl

I don’t know if you can do that, but not having to manage the DHCP server would be a major benefit for environments where the Foreman admin isn’t allowed by the networking team to manage DHCP.

Yes, this benefit was mentioned several times during discussions, plus it would save us a lot of effort and maintenance.

@ekohl

Either way, we’ll need to design this area because the current DHCP module in smart-proxy is IPv4-only. How we want to solve it really depends on the design we create for IPv6. This is a big task with lots of open questions.

Added to the backlog. cc @nofaralfasi @Shimon_Shtein