kube-router Stops Processing networkpolicy When IPv6 Address Added to ipBlock

[aauren]

What happened?
A user on our system recently created a network policy with an egress networkpolicy that contained:

- ipBlock:
    cidr: 2603:1026:3000::/48

When this happened, kube-router stopped being able to sync networkpolicy to the host do to an ipset error:

E0204 21:15:05.569840    5655 network_policy_controller.go:259] Aborting sync. Failed to sync network policy chains: %!v(MISSING)failed to perform ipset restore: ipset v7.15: Error in line 3139: Syntax error: '48' is out of range 0-32

What did you expect to happen?
Ideally kube-router would be able to handle both IPv4 and IPv6 addresses in NetworkPoicy. However, since kube-router isn't compatible with IPv6, I expected it to just ignore IPv6 addresses and still keep syncing the policy that it could.

It would also be nice if kube-router would log something if it encounters address types that it isn't able to process as a warning.

** System Information (please complete the following information):**

• Kube-Router Version (kube-router --version): v1.4.0
• Kube-Router Parameters: --run-firewall=true
• Kubernetes Version (kubectl version) : 1.21.9
• Cloud Type: On Prem
• Kubernetes Deployment Type: Custom
• Kube-Router Deployment Type: System Service

[arianvp]

The netpol controller doesn't seem to handle ipv6 yet. Among other things it currently only creates ipsets for ipv4 addresses.

e.g. https://github.com/cloudnativelabs/kube-router/blob/master/pkg/controllers/netpol/network_policy_controller.go#L561 the false here means the ipset is for ipv4 addresses only

I think the code will need some work to also support ipv6.

[vadorovsky]

I have a working implementation of IPv4/IPv6 dual-stack for netpol controller here:

k3s-io#7

The main reason why I didn't upstream it yet is that we only made a change in netpol, not in any other component. But since this issue is about network policy controller only, would you be fine with upstreaming it as it is?

[arianvp]

Also see #1249 (review) comment

[aauren]

This will be fixed when #1386 makes it to a main release