[jakobve]

What is this PR about and why is it needed?

• The current ha_proxy.binding_ip property accepts a single scalar address. Combined with ha_proxy.v4v6: true, it enables dual-stack by creating one IPv6 socket that also accepts IPv4 connections via the kernel's IPv4-mapped IPv6 mechanism (::ffff:x.x.x.x).
• When setting binding_ip: :: ONLY IPv6 traffic will be accepted by setting the v6only flag explicitly.
  • When dual stack is wanted one needs to set v4v6: true
  • When wanting IPv6 only v4v6 has to be false or empty
• When setting multiple binding_ips and one of them is an IPv6 address the v6only flag is set explicitly
• binding_ips cannot be combined with v4v6. The v4v6 property has to be empty. Cannot be set to false

Additional notes for reviewers

+++ This is can be a breaking change +++
When binding_ip is set to :: and the v4v6 flag is not set or false only accept IPv6 traffic by setting the v6only flag.

Which issues does this fix?

#983

Tested real deployment with configurations:

Happy cases

• 🟢 Only binding_ips
• Only one IP in binding_ips
  • 🟢 V4 only
  • 🟠 V6 only (health checks cannot complete as BOSH is running in IPv4 only mode in our tests)
• Only binding_ip
  • 🟢 V4 address
  • 🟠 V6 address (health checks cannot complete as BOSH is running in IPv4 only mode in our tests)
• 🟢 Only v4v6 flag (IPv6 mapped IPv4 addresses)
• 🟢 v4v6 flag and v6 binding_ip

Error cases - Deployment failed

• 🟢 Binding IPs and v4v6

v4v6: true
binding_ips:
    - "::"
    - "0.0.0.0"

• 🟢 v4v6 with binding_ip v4 address
• 🟢 binding_ips and binding_ip

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: jakobve / name: Jakob Bergmeier (0014d2d, 4a24ca4, 791e3bf, 7c1d716, 884a00b, bbbd406, dc3e3ef)

[hoffmaen]

I find the logic with the various new boolean properties, that mutually exclude each other, confusing and error-prune. Also, I don't like the implicit bind mode when omitted. I had a quick look only, please check if my thoughts are applicable and make sense.

My thoughts after reading the doc:

• Having both binding_ip and binding_ips available, but using both at the same time is not possible, is not ideal.
• I see that binding_ip is an existing property that we probably don't want to break. Is it possible to keep the logic and features with binding_ip as is, and implement the new stuff exclusively for binding_ips?

If that is possible, I'd propose logics as follows:

• binding_ips could be renamed to bindings, which always needs two fields:
  ** binding_ip: E.g. :: or any other address
  ** binding_mode: E.g. v4only, v6only, `v4v61, must always be set

Only binding_ip OR binding_ips can be set. With this, we wouldn't break existing scenarios, and the new functionality would only be available with the new bindings parameters. Users can migrate and explicitly define the bindings, not having any implicit binding mode or other magic happening under the hood.

Is that feasible?

[jakobve]

Hi @hoffmaen ,

thanks for taking a quick look at the PR. I have some questions considering your thoughts.

I proposed 3 options in the issue of which one is close to your proposal considering a new bindings property.

• The binding_ips config property was newly introduced here. So it should not break anything yet.

• Why would someone want to use binding_ip and binding_ips at the same time? Considering the migration, if one wants to migrate one can just transition to either property just moving the IP value.

• Sure, we can keep the existing logic for the binding_ip property so we do not break anything in case someone is using this feature.

• We can also rename the binding_ips to bindings if this is to confusing.