RFC: Supporting IPv6 in Provisioning, Registration & KEA

Development RFCs
1

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.

5 Likes
2

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.

3 Likes
3

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

4

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

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.

2 Likes
5

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

Added to the backlog. cc @nofaralfasi @Shimon_Shtein

6

Hello everyone,

I wanted to share an update on our ongoing discussions about implementing the Kea provider to replace ISC. Initially, the proposal was to have users configure and manage their own Kea servers, while we developed a new smart proxy plugin to enable Foreman to communicate with Kea through the Kea API.

However, we’ve encountered a challenge: the open-source version of Kea doesn’t offer full API support. Some API requests require Kea’s hook libraries, which are only available with a premium subscription. For example, the Host Commands hook library, critical for managing reservations, is part of the premium version.

Given these limitations, we’re considering an alternative approach: implementing the Kea provider directly within Foreman. This would involve managing the installation and configuration of the Kea server on the smart proxy. While this adds complexity and requires more work, it may be necessary to deliver complete DHCP provider functionality.

Looking forward to your thoughts and feedback!

7

This is what I already noticed a few years ago, but I was told by someone that it was no longer a concern. Looks like it still is.

This is why I was suggestion to reconsider the whole model where we don’t need specific host reservations. I’m not sure if it’s feasible.

And fundamentally, we can also question if we want to integrate with an open-core DHCP server by default. You can treat it Infoblox and only support it for users who bought the premium version while defaulting to something smaller like dnsmasq.

Another alternative is to implement your own Kea hook plugin that provides the API you need.

Still, all not great.

This is what https://rubygems.org/gems/smart_proxy_dhcp_kea already does. I think it needs an update because Kea’s DB schema changed. I’m sure we can talk about ownership with CERN.

8

Following up on that, I see 8. The DHCPv4 Server — Kea 2.7.4-git documentation documents how to configure the database for lease storage and is available in the free version. As long as the schema remains the same that probably works reliably.

2 Likes
9

Hi all,

As mentioned, we’ve encountered limitations with the basic Kea API subscription, such as missing host reservations and advanced subnet configuration. Our current suggestion is to access the Kea DB directly, either by using the existing smart_proxy_dhcp_kea plugin or creating a new one for this purpose.

We’re also considering reaching out to the Kea team to explore potential collaboration opportunities and other solutions they may offer.

Any feedback or thoughts would be appreciated!

Note: I’ll be on PTO for the next week and a half and will continue working on this when I’m back.