splitNetwork and addIntToIP fails for IPv6 addresses on /64+ size pools

[aaliddell]

Description

When attempting to create the pools for IPv6 addresses ranges, the output of splitNetwork produces the same CIDR N times rather than the N different CIDRs if the output network size is >= 64 bits. This is due to the value passed to addIntToIP being a 64 bit int, which is insufficient to contain the required value to offset IPv6 ranges.

Steps to reproduce the issue:

1. Add an IPv6 range to default-address-pools in config and enable IPv6.

For example:

   "default-address-pools": [
      < IPv4 pools >
      {
        "base": "fd00:0000:0000::/48",
        "size": 64
      }
    ]

2. Attempt to create two IPv6 networks, the second will fail with could not find an available, non-overlapping IPv6 address pool among the defaults to assign to the network, suggesting there is only one pool available

Describe the results you received:

Only a single IPv6 pool is available per entry in default-address-pools

Describe the results you expected:

The output of splitting fd00:0000:0000::/48 into /64 networks should yield 2^16 pools, not one.

Additional information you deem important (e.g. issue happens only occasionally):

This is caused by splitNetwork and addIntToIP, which works OK for IPv4 but fails for IPv6 networks of /64 or larger due to the ordinal argument to addIntToIP being a 64 bit int, which ends up being zero when using a /64 or larger. Crucially, the statement uint(i<<s) yields zero here, since s > 64

For example, fmt.Println(splitNetworks([]*NetworkToSplit{{"fd00:0000:0000::/48", 50}})) yields the same CIDR repeated 4 times rather than 4 separate CIDRs:

[fd00::/50 fd00::/50 fd00::/50 fd00::/50]

To fix this, those two functions need to be amended to allow values up to 128 bits to be added to an IP, perhaps with an ordinalUpper and ordinalLower as two 64 bit uints.

I believe this issue may be the underlying cause of #41438

Output of docker version:

Client:
 Version:           18.09.1
 API version:       1.39
 Go version:        go1.11.6
 Git commit:        4c52b90
 Built:             Sun, 21 Feb 2021 18:18:35 +0100
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.09.1
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.11.6
  Git commit:       4c52b90
  Built:            Sun Feb 21 17:18:35 2021
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker info:

Containers: 27
 Running: 27
 Paused: 0
 Stopped: 0
Images: 31
Server Version: 18.09.1
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: journald
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
runc version: 1.0.0~rc6+dfsg1-3
init version: v0.18.0 (expected: fec3683b971d9c3ef73f284f176672c44b448662)
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.19.0-14-amd64
Operating System: Debian GNU/Linux 10 (buster)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 11.4GiB
Name: 
ID: GXW4:VDGE:BS4J:AY3S:5DHN:COS3:TCUC:JOBN:KRPG:V6MW:YO37:A2GO
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 191
 Goroutines: 192
 System Time: 2021-08-30T22:44:47.757633368Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
None

[aaliddell]

Here's some checks I ran to find this, which might be helpful for tests:

fd00:0000:0000::/63 split into /65: [fd00::/65 fd00::8000:0:0:0/65 fd00:0:0:1::/65 fd00:0:0:1:8000::/65
fd00:0000:0000::/48 split into /50: [fd00::/50 fd00:0:0:4000::/50 fd00:0:0:8000::/50 fd00:0:0:c000::/50]
fd00:0000:0000::/80 split into /82: [fd00::/82 fd00::4000:0:0/82 fd00::8000:0:0/82 fd00::c000:0:0/82]

This may also be an opportunity to address #40275, where using a large base pool and a large split size leads to generating huge amounts of output from splitNetwork and potentially consuming all RAM when preallocating the pools. Either limiting the number of pools directly or limiting the difference between base size and pool size. e.g. /48 split into /64s is allowed, but /48 split into /96s is not.

[Xyaren]

This seems to be quite a big issue for me and is blocking me from using ipv6 auto created networks right now.

[gucki]

This bug is more or less a complete show stopper when using docker-compose 👎