Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.74.3.189  netmask 255.255.255.252  broadcast 10.74.3.191
        inet6 2a00:1098:8:bf::1  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::ba27:ebff:feeb:6b01  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:eb:6b:01  txqueuelen 1000  (Ethernet)
        RX packets 33609450  bytes 2152188359 (2.0 GiB)
        RX errors 2  dropped 0  overruns 0  frame 2
        TX packets 33742813  bytes 1964729036 (1.8 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Since docker wants to manage the IP addresses itself, I can not give it the entire subnet.
That would also be wrong in many ways.  So I must give it part of the subnet to use.

galadriel# docker network create -d macvlan \
    --subnet=10.0.1.0/24 \                   
    --subnet=2a00:1098:8:bf::1:0/116 --gateway=2a00:1098:8:bf::2 \      
    -o parent=eth0 \
    --ipv6 \
    mythic0

no matching subnet for gateway 2a00:1098:8:bf::2

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Unresolved.

   * What was the outcome of this action?

the network is not created

   * What outcome did you expect instead?

the network should have been created.

Docker thinks that IPv6 works like IPv4, and it does not.
The default gateway in IPv6 can be anything, and is often an IPv6 Link-Local address (scoped to that interface).
There is no requirement that the addresses be on-link, so it is entirely reasonable to specify a gateway that is
not within the provided subnet.

*** End of the template - remove these template lines ***

Thank you for your report.

<mcr@sandelman.ca> writes:

To proceed, we first need to determine if this is still an issue with
the current software. Please try to reproduce the problem with the
latest version of the docker.io package in Debian, which is
26.1.5+dfsg1-9.

If the problem persists with the current version, please report it
directly to the upstream developers at the Moby project's GitHub
repository: https://github.com/moby/moby/issues which is the appropriate
place for fixes to the core Docker engine. Once done so, please follwup
to this bug with that reference.

Best,
-rt

Not submitted as:
https://github.com/moby/moby/issues/51057

Control: tag -1 -moreinfo
Control: severity -1 normal

Thanks for reporting this issue upstream.

It turns out that the current behavior is designed to behave this way,
and there are workaround to acheive the specific use-cases you had in
mind.

This issue is not Debian centric and as such needs to be handled
upstream, which is what you started. I'd like to encourage you to
continue working with upstream towards a solution so that all Linux
Distros can benefit as soon as a new version becomes available.

Best,
-rt