Podman vs Docker networking: IPv4, IPv6 and Dual Stack

[aojea]

/kind bug
/kind feature

Description

I do not think that podman and docker network will behave similar, simple because this is a long history between containers networking, CNM/libnetwork vs CNI https://kubernetes.io/blog/2016/01/why-kubernetes-doesnt-use-libnetwork/

Docker network ALWAYS use IPv4, if you enable IPv6 then it creates dual-stack networks..

docker network inspect kind
[
    {
        "Name": "kind",
        "Id": "979f492554fd8b8dc94d58f8e989dd5878ea410b4ff0b75457359d00cfa19ee6",
        "Created": "2020-07-28T13:01:45.860343319+02:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": true,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                },
                {
                    "Subnet": "fc00:f853:ccd:e793::/64",
                    "Gateway": "fc00:f853:ccd:e793::1"
                }
            ]
        },

With podman network you can only have single stack networks for the containers, because you can only specify one range as parameter:

$ sudo podman network inspect kind
(snipped)
        "bridge": "cni-podman5",
        "hairpinMode": true,
        "ipMasq": true,
        "ipam": {
          "ranges": [
            [
              {
                "gateway": "fc00:8866:27d0:bd7e::1",
                "subnet": "fc00:8866:27d0:bd7e::/64"
              }
            ]
          ],
          "routes": [

CNI allows dual-stack configurations, something we already have in KIND, as you can see in this snippet

https://github.com/kubernetes-sigs/kind/blob/afe54f7eb52c902ff5bdb23e522bc38e00a71e27/images/kindnetd/cmd/kindnetd/cni.go#L34-L64

I'm happy to submit a PR to implement this, but I'm interested in hearing what are the expected semantics for podman network,
I do see value in creating IPv6 only containers, but in the other hand I recognize that this is far from being a reality and most people use dual stack on containers.

• Should we pluralize the parameters for ranges in the podman network create
  

  podman/pkg/domain/entities/network.go

  Lines 40 to 50 in 588df90

  	// NetworkCreateOptions describes options to create a network
  	// swagger:model NetworkCreateOptions
  	type NetworkCreateOptions struct {
  	DisableDNS bool
  	Driver string
  	Gateway net.IP
  	Internal bool
  	MacVLAN string
  	Range net.IPNet
  	Subnet net.IPNet
  	}

  ?
• or just implement docker behavior assigning always IPv4 subnets to containers?
• ...

[rhatdan]

@aojea Are we any closer on this one?

[aojea]

Sorry @rhatdan I forget to follow up, I need your opinion first, right now the situations is:

podman does ipv4 OR ipv6.
docker does ipv4 OR (ipv4 and ipv6)

what do you prefer to imlement?

1. ipv4 OR ipv6 OR (ipv4 and ipv6)
2. same as docker: ipv4 OR (ipv4 and ipv6)

I personally will go with the 2nd option, is simpler and is what people is used to use ... and we can always implement 1. later

[rhatdan]

Sure let's do 2.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[zajdee]

Please go for option 1. The Docker implementation is screwed up and people do want IPv6-only containers, therefore allowing all three networking options (IPv4 OR IPv6 OR dual-stack) does make sense.
Thank you.

[aojea]

Please go for option 1. The Docker implementation is screwed up and people do want IPv6-only containers, therefore allowing all three networking options (IPv4 OR IPv6 OR dual-stack) does make sense.
Thank you.

I've implemented ALL, you can use ipv4 only, ipv6 only and dual-stack ;)

[zajdee]

I've implemented ALL, you can use ipv4 only, ipv6 only and dual-stack ;)

Amazing! Will try, thank you. :-)
(Apologies for commenting here, I've got a bit confused by no follow ups here and didn't open the referenced issue. Didn't have my morning coffee yet. :D)

[aojea]

Amazing! Will try, thank you. :-)
(Apologies for commenting here, I've got a bit confused by no follow ups here and didn't open the referenced issue. Didn't have my morning coffee yet. :D)

No need to apologise, is a fair comment ....
This was a bit tricky because the goal is to maintain the docker compatibility and keep the command semantics.
So, the result is that the podman network create command now means "single stack" and is IP family agnostic, you can use it to create IPv4 only or IPv6 only, this is the difference with docker and maintains the command semantics.
The --ipv6 flags means dual-stack, this is fully compatible with docker ...
This implementation keeps the semantics and compatibility, and avoids the limitation that has docker where single-stack means IPv4 only :)

sudo podman network create --subnet fd00:1:2::/64 newipv6
/etc/cni/net.d/newipv6.conflist
$ more /etc/cni/net.d/newipv6.conflist
{
   "cniVersion": "0.4.0",
   "name": "newipv6",
   "plugins": [
      {
         "type": "bridge",
         "bridge": "cni-podman5",
         "isGateway": true,
         "ipMasq": true,
         "hairpinMode": true,
         "ipam": {
            "type": "host-local",
            "routes": [
               {
                  "dst": "::/0"
               }
            ],
            "ranges": [
               [
                  {
                     "subnet": "fd00:1:2::/64",
                     "gateway": "fd00:1:2::1"
...