Ip6 dual stack support

Problem:
I recently checked the Foreman 3.4 docs regarding the support of IPv4 and IPv6 and it states, that dual stack configurations are not supported. We are running dual stack here for years, without any issues. Granted, our environment is limited to F/K functionality, including tftp to set up new hosts, Ansible for maintaining the state and the VMware plugin to handle virtual machines. Maybe the issue is with other parts or plugins.

Am I missing something?

Expected outcome:
Have full support for dual stack configurations in the docs.

Foreman and Proxy versions:
F 3.4
K 4.6

Foreman and Proxy plugin versions:

Distribution and version:
Rocky 8

Why do you think dual stack isn’t supported? If you quote, it’s very helpful to post the url for verification…

Installing Foreman nightly Server with Katello nightly Plugin on RHEL/CentOS says:

  • You can install Foreman and Smart Proxies in IPv6-only systems, dual-stack installation is not supported.

As you point out, this actually works fine (and that’s also the developer expectation), but it was never formally verified. I think this limitation should only be shown in Satellite documentation, not upstream Foreman/Katello, as there we have a difference what is defined as “supported”.

Yes, @gvde, I should have quoted the current installation manual. Thank you @evgeni for filling that gap.

Thank you for the clarification. Is there anything I can do to help in that verification process or is it dev-internal?

I guess, I have never read that part. All our servers and hosts have IPv4 and IPv6 addresses and foreman/katello works just fine with it. Unless you start using ip addresses instead of hostnames foreman uses DNS to resolve hostnames and connects with whatever the systems decides to use.

Interface settings/facts etc. can use both.

The only limitation I know of is the provisioning template kickstart_kernel_options which fails if you have set an ipv4 and ipv6 subnet for a host.

Other than that I don’t have any issues and I am really surprised that dual-stack isn’t officially supported…

I actually submitted a pull request about that template about 2 years ago:

It got merged into

However, looking at my current F 3.4/K 4.6 install, I still see inside of the template:

  # networking credentials
  raise("Dual-stack provisioning not supported") if subnet4 && subnet6

So I am not sure this is really applied.
@lzap @ezr-ondrej Could you please verify, if the merged pull request has made it into 3.4? It says merged on May 7, 2021. Thank you :slight_smile:

I think it got merged into

Which never got merged. I guess it would need another person to take it over the finish line and probably asking @ekohl what issues there were left off preventing merge. :slight_smile:

Thank you Ondrej! At least now I know why I am missing the new template :slight_smile:

Foreman 3.5 has this patch:

The raise is there because Dracut doesn’t support dual stack static IPs:
https://bugzilla.redhat.com/show_bug.cgi?id=1008076
It’s reported against an old Fedora, but as part of Fixes #35779 - Correct generated provision snapshots by ekohl · Pull Request #9516 · theforeman/foreman · GitHub I looked at the Dracut sources and it still holds true.

Since I was involved in the discussions, allow me to elaborate a bit.

The context of recent(ish) IPv6 support is that Red Hat had a large customer with a requirement for IPv6-only. So a lot of focus was on a pure IPv6 setup. There was no attention to a dual stack setup, even though for the most part it just works.

What you should also know is that docs.theforeman.org is based on the open sourced Red Hat Satellite documentation. I still consider it incomplete because it doesn’t always reflect the upstream project’s stance on things. This is an example.

Red Hat has its own definition of supported. If RH calls it supported, customers can ask customer support and it should be resolved. One guidance on that is that if it’s documented, it has to be supported. Then there are also things which are undocumented and unsupported. This doesn’t mean it can’t work, it’s just that if it breaks, you get to keep the pieces. There have been discussions about creating some “known to work” category, but I’m not sure that ever went anywhere.

Bringing this back to the Foreman community, there is no customer support so everything is unsupported if we follow Red Hat’s definition of supported.

A complete review of docs.theforeman.org is very high on my wish list. Many things may not be true (anymore) or are Satellite-focused. I’d encourage people to use GitHub - theforeman/foreman-documentation: Documentation for the Foreman Project and its ecosystem to create issues or submit PRs. This should help us to make it high quality documentation.

Thank you Ewoud for chiming in.

Please correct me if I am wrong, but during the kickstart (Dracut) phase we could fall back to a single IP address, like you do in the patch for 3.5, and then during the host configuration the (static or DHCP) network setting get set, leading to a provisioned dual stack host.
So basically, only the corresponding foreman/katello server and smart proxies need to be reachable via the chosen dual_stack_fallback address, after the host is deployed it will have access to the entire network.
If that holds true in your perspective, I am happy to raise a documentation issue to change the paragraph in the documentation to include this statement.

Fully understood, I am only talking about the documentation for the community release.

For kickstart the host in foreman can only either have ipv4 or ipv6 subnet (it can have addresses for both set, both the subnet field for one of them must be empty). Otherwise it fails. After the host has been built you can set subnets for both ipv4 and ipv6 on the host.

With the patch above, that case is handled differently.

Your foreman servers and proxies are simply dual stack and have both ipv4 and ipv6 addresses.

So beyond the limitation during kickstart, it’s all dual-stack. At least I haven’t seen any other limitation, yet. All connections are handled via hostnames…

Currently I am using my own cloned version of the kickstart template, which doesn’t require this step. It will automatically fall back to ipv4, if both are selected. That was the original idea of my PR above, which has evolved to the latest PR mentioned by Ewoud.

I actually only very recently saw the patch, but I’m wondering if we can have a default. For that we need to know the impacts.

There are a few steps:

  • Kernel parameter is passed to Dracut to set up Anaconda
  • Anaconda receives a kickstart with network definitions
  • Host is booted in the final network config

The first step can’t set up dual stack statically, but I wonder if Anaconda reconfigures the network using the network definitions. If it does, then you only need the Dracut environment to retrieve the kickstart, which means the only factor is whether Foreman has IPv6, IPv4 or both. We can actually determine that using DNS lookups to the Foreman hostname: if there’s AAAA, we prefer IPv6. Then the user isn’t burdened by an additional step.

Now I don’t know the actual interactions here. If Anaconda doesn’t reconfigure the network and only uses the Dracut environment then the implications are bigger, since it also needs to retrieve content.

Last week some RH Satellite engineers had a meeting with the Anaconda team and networking was an area that we wanted to dive into. @lstejskal can we put this on the agenda for the follow up meeting for networking?

It would be good to have more documentation around this topic. Documenting this parameter in the provisioning hosts guide is a good step, even if we at some point automatically determine it.

To be honest, Ewoud, I am not really sure if we need to have answers to all those questions. If I am wrong, I am happy to stand corrected :slight_smile:

From my perspective, right now you have to make a choice between v4 and v6 on both the network definitions and your environment. So either a) all your servers plus the content plus whatever is needed during kickstart is available via ipv4 or b) via ipv6.
If you would have a mix of servers and/or services reachable only by one or the other, you are in trouble today anyway.

The fall-back approach proposed about 2 years ago and the better version (the patch in 3.5 above) do not change that requirement at all, they only provide you with the option to have a dual-stack config applied to the host while still running on a single IP during kickstart.

I fail to see the difference of those scenarios:

  • current approach
    host is configured with one subnet only (ipv4 or ipv6)
    kickstart runs with that IP
    all servers/services reachable via that selected IP address

  • approach with the patch in F 3.5
    host is configured with two subnets, however, only the selected IP address is used
    kickstart runs with that IP
    all servers/services reachable via that selected IP address

But somehow I have the feeling I am missing something, maybe because I don’t know Fedora at all.

We can actually determine that using DNS lookups to the Foreman hostname: if there’s AAAA, we prefer IPv6. Then the user isn’t burdened by an additional step.

True, however, we should still have an option to force v4 or v6 in the config. Maybe the admin is in a middle of a migration and the F/K server is already on v6, while most other network services are not.

It’s true that 3.5 will have a much better experience, but I was thinking about how to make it even more automatic. We have a lot of information and if we can autodetect the setup so the user doesn’t have to think about it, that would be an even better experience. On the other hand, perhaps you’re right that it’s good enough and it’s not a crucial thing to solve.

Perhaps it’d help if people shared their IPv6 migration strategies, especially if they work in larger organizations.

1 Like