Enable IPv6 Support in Concourse Containers for Upcoming silk-release Integration Tests

[plamen-bardarov]

Proposed Change

We are in the process of introducing new integration tests in silk-release that require IPv6 support within the containers used by the Concourse CI pipeline.

At this time, it is unclear what changes are needed to support IPv6 in this environment. Specifically, we are seeking clarity on the required configuration for IPv6 support within Concourse-executed containers.

Context

The integration tests will depend on functional IPv6 networking within the container runtime environment.
These tests are executed via Concourse jobs using Docker-based containers.
Initial investigations suggest that IPv6 is currently not enabled or accessible inside the test containers.

Initial Research

Currently what seems to work when running the tests locally is simply changing the docker daemon configuration as following:

{
  "fixed-cidr-v6": "2001:db8:2::/64",
  "ipv6": true
}

Open Questions

• Is enabling IPv6 in the Docker daemon configuration (e.g., "ipv6": true, fixed-cidr-v6, etc.) sufficient?
• Does the host operating system need to have IPv6 explicitly enabled and configured for this to work?
• Does Concourse or the container runtime configuration require additional steps to pass through or support IPv6?
• Are there specific Docker network settings or bridge configurations that must be updated?

Acceptance criteria

Identify and implement the necessary changes (whether in Docker, host networking, or Concourse configuration) to ensure containers within the Concourse pipeline have functional IPv6 networking. This is required to support the upcoming test changes.

Related links

• RFC0038
• IPv6 Support #989
• [RFC0038] IPv6 support for Silk CNI and VXLAN policy agent silk-release#155

[winkingturtle-vmw]

@plamen-bardarov I am having some difficulty understanding the problem here. Let me reiterate your question and see if I understand it correctly.

You have a silk-release integration test that will test IPV6 support and you are wondering how this gets tested in our concourse.

If I understand this correctly, concourse is able to run a worker node with IPV6 and guardian supports this.

Is enabling IPv6 in the Docker daemon configuration (e.g., "ipv6": true, fixed-cidr-v6, etc.) sufficient?

I don't know how this would relevant in concourse world.

Does the host operating system need to have IPv6 explicitly enabled and configured for this to work?

I think so. I would think you'd need a worker that supports this.

Does Concourse or the container runtime configuration require additional steps to pass through or support IPv6?

I don't know. We are not running those workloads currently, so it's hard to tell what else needs to be configured.

[plamen-bardarov]

@winkingturtle-vmw that's right, there are some new ipv6 related integration tests in silk-release, which should be able to run in concourse. Could you point me to the repo or script that configures the worker? Also, what’s the best way to validate the environment before merging these tests into silk-release?

[winkingturtle-vmw]

@plamen-bardarov We are in the process of moving our CI from internal to a new concourse. We are not running IPV6 workers on our internal concourse. I will leave this issue open until we have moved to OSS concourse. I don't know exactly how that's configured or where it is at the moment.

[PlamenDoychev]

Hi @winkingturtle-vmw , @ameowlia,

We had a team discussion about the IPv6 test environment enablement, as IPv6 for egress is on the critical path for SAP we must have it in EOM June. The fact that there is a relocation of the infrastructure towards OSS Concourse seriously worries us given the short timeline we have.
What are your expectations with regards to the infra shift, do we have some timeline?
More generally how we can mitigate this risk for us?

FYI: @peanball

[winkingturtle-vmw]

I'd like to re-iterate that the feature you are looking to merge might just work in our current workers. I haven't had to deal with IPV6, so I am not sure of the complexity involved.

One suggestion that might be worth having on the table is to run a duplicate pipeline or test the functionality you care about separately in a different infrastructure. Realistically speaking, we can't test every configuration possible for a given release, given that we'd be even more limited to how much we can spend for the infrastructure after the move to an OSS account.

I personally think moving to a model where we test the happy path for a default configuration in OSS and asking different vendors to test the customizations could be one way to ensure the long-term success of the project.

[peanball]

@winkingturtle-vmw, we (SAP) are preparing a CATS environment in parallel with the ARD WG.

@plamen-bardarov and @PlamenDoychev are concerned merging things that were not tested in the community.

My personal point of view is that as long as the IPv4 standard scenario doesn't break (i.e. the tests we currently have), everything else is behind feature flags and configuration so it won't (shouldn't) impact anybody.

@ameowlia, maybe you have an opinion from a process point of view...
Would it be viable to include something "experimental" that we're working on and that might not be 100% error free yet, when it's the operator's choice to use it or not?

[peanball]

Summary from Slack: https://cloudfoundry.slack.com/archives/C02HNDJB31R/p1746184945419829?thread_ts=1744814403.452589&cid=C02HNDJB31R

@winkingturtle-vmw mentions that it would be OK to put the IPv6 features behind an experimental feature flag and disable them in the community pipeline, with the condition that the authors test locally. Once the community's environment can also run the tests and the feature is stable we can remove the "experimental" nature of it and run the tests in the community also.

The default behavior should remain backwards compatible, i.e. the experimental flag should not have any side effects when it's disabled by default.

FYI: @plamen-bardarov @PlamenDoychev @ameowlia @sklevenz