IPv6 Beta Feedback

[binman-docker]

Hello, the purpose of this ticket is to track feedback for Docker Hub Registry's beta IPv6 support.

Information and background: https://www.docker.com/blog/beta-ipv6-support-on-docker-hub-registry/

The IPv6-only endpoint is registry.ipv6.docker.com. If you wanted to pull the latest Ubuntu image on an IPv6 machine, for example, you would run "docker pull registry.ipv6.docker.com/library/ubuntu:latest".

Note that Docker Engine only supports shortened image names on our normal domains, so to pull official/library images on the beta IPv6 domain, you need to add the library namespace ("ubuntu"->"library/ubuntu").

Please note this new endpoint is only a beta – there is no guarantee of functionality or uptime and it will be removed in the future. Do not use this endpoint for anything other than testing.

[telmich]

@binman-docker I can certainly confirm that it works. The rate limiting approach looks to be sane as well.

[20:50] bridge:~% dig +short registry.ipv6.docker.com aaaa 
2600:1f18:2148:bc01:6c07:dc0:c4d8:ebcc
2600:1f18:2148:bc00:cec:e441:76aa:4346
2600:1f18:2148:bc02:be0d:cab7:aea4:5fbb

And it not only works:

[20:50] bridge:~% docker pull registry.ipv6.docker.com/ungleich/ungleich-certbot:0.3.2 
0.3.2: Pulling from ungleich/ungleich-certbot
Digest: sha256:0b44ac98ec77600829391e75ceb3432a915b1fb969c2e8563911832c6f717fa8
Status: Downloaded newer image for registry.ipv6.docker.com/ungleich/ungleich-certbot:0.3.2
registry.ipv6.docker.com/ungleich/ungleich-certbot:0.3.2

But is significantly faster than pulling through NAT64 and then reaching docker via IPv4. This is not measured by time, but just seeing a sub-second pull while NAT64 pulls towards IPv4 take super-second time.

Well done, this is a very welcome change and I congratulate team docker for finally making this available.

[A1bi]

I am testing this on an IPv6-only host. Logging in to the new endpoint worked fine. But when I try to pull an image as described it tries to download from an IPv4-only host:

$ docker login registry.ipv6.docker.com
Authenticating with existing credentials...
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

$ docker pull registry.ipv6.docker.com/library/ubuntu:latest
latest: Pulling from library/ubuntu
7b1a6ab2e44d: Pulling fs layer
error pulling image configuration: Get "https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sha256/ba/ba6acccedd2923aee4c2acc6a23780b14ed4b8a5fa4e14e252a23b846df9b6c1/data?verify=1635363984-4ba8A5LzvbQB3f0YMjPU2lexOF8%3D": dial tcp 104.18.124.25:443: connect: network is unreachable

[binman-docker]

Nice catch @A1bi, we'll update the thread once we've got the Cloudflare stuff sorted.

[mxmehl]

Thank you for enabling this. I have two questions:

1. Is there the possibility to pull from this registry by default, e.g. by customising daemon.json? Or do we always have to prepend registry.ipv6.docker.com?
2. Is a login required? (I cannot test it as I run into the same problem as @A1bi)

[ingshtrom]

• Is there the possibility to pull from this registry by default, e.g. by customising daemon.json? Or do we always have to prepend registry.ipv6.docker.com?

Unfortunately, you always need to prepend registry.ipv6.docker.com/.

• Is a login required? (I cannot test it as I run into the same problem as @A1bi)

Nope, you can login or not, depending on what you want to pull and if you are reaching rate limits, as described here.

[ingshtrom]

Sorry this took so long, but we wanted to make sure that this wouldn't harm users using the default registry. You should be able to pull from the registry at registry.ipv6.docker.com on an IPv6 only network. Please test it out and give us feedback!

[A1bi]

I tried several different images. Pulling them on my IPv6-only host worked flawlessly for all of them now. Awesome! Thank you for your hard work!

[danopia]

I also had success using this registry on an IPv6-only host. Great to see attention on this!

[binman-docker]

Hi all - after monitoring IPv6 performance on Docker hub during this beta release, we are happy to announce that registry.ipv6.docker.com is no longer in beta phase!

Feel free to use this endpoint for any environment for long-term purposes while we continue to roll these changes out to the rest of Docker hub to make it fully dualstack compatible.

[sgryphon]

This is excellent! The endpoint is working for me on my IPv6 only host, and on a dual stack machine.

It is similar to how Google, Facebook, etc originally had a separate IPv6 endpoint until they switched over; although that was more during a period when clients might be poorly configured and returning AAAA records for the primary domain might break them; that is no longer the case (otherwise Google, etc would not work).

The network paths for IPv4 and IPv6 can be completely separate, so now that you have the IPv6 hosts functioning, it would be good to see the primary domain simply return both A and AAAA records, and so the clients can pick which to use (IPv4 only clients will use the A record and not see anything different).

Do you have a time frame on when AAAA will be added to the main DNS records?

(Note that this has nothing to do with dual stack on your end, the A and AAAA records can point to completely different destinations, e.g. the AAAA record for my domain points directly at my server, which is IPv6 only, whilst the A record points to a separate incoming IPv4 reverse proxy).

====

In response to an earlier comment, I didn't see any significant difference in direct IPv6 vs NAT64, from my IPv6 only host (located in the UK), I was seeing 2-3s for either, after clearing the local images (the two hosts get different entries, so you have to clear both):

docker image rm registry.ipv6.docker.com/library/hello-world -f
docker image rm hello-world -f

time (docker pull registry.ipv6.docker.com/library/hello-world)

docker image rm registry.ipv6.docker.com/library/hello-world -f
docker image rm hello-world -f

time (docker pull hello-world)

[binman-docker]

The main concern with enabling AAAA on the existing domains is that users who access Hub on a dual-stack network will suddenly see their traffic switch from IPv4 routes to IPv6 routes. It's possible they may have unforeseen issues with their IPv6 stack which previously went unnoticed. Given the nature of Hub, that could cause issues for users who depend on us, without them having changed anything.

Further rollout will be slow and methodical, including notifications to the community. We don't have a timeline currently.

[sgryphon]

@binman-docker yes, this was the concern when IPv6 started to roll out, and why early on google, facebook, wikipedia, etc, started with a separate endpoint for ipv6, then had a World IPv6 Day when they turned it on for real, just for a day, to try and shake out dual-stack issues. https://en.wikipedia.org/wiki/World_IPv6_Day_and_World_IPv6_Launch_Day

If, 10 years later, people have broken dual stack implementations then large parts of the Internet would not be working for them, including www.docker.com and docs.docker.com, both of which are served by cloudfront and have both A and AAAA records.

IPv6 brokenness was a real problem (so valid to raise as a concern) -- but 10 years ago -- but if you are worried about it in 2022 as a technical problem, then it is probably simply a case of old information (they aren't wrong, it is a real issue, just out of date). See https://en.wikipedia.org/wiki/IPv6_brokenness_and_DNS_whitelisting

If you are still worried, then ensure there is an ipv4 only fallback address, and/or add an "-4" option to the docker CLI to only use IPv4.

EDIT: P.S. It really is excellent that you are moving on the IPv6 front; I just want to try and reassure you that while issues about IPv6 brokeness were real, they were generally considered fully fixed 5+ years ago.

[J0WI]

Why is https://github.com/docker/roadmap/issues/89 already closed?

While most hosts on docker.com are now accessible over IPv6, docker.com itself (without subdomain), hub.docker.com and everything on dckr.io and docker.io (especially registry-1.docker.io) are still not accessible over IPv6.

[EmilyShepherd]

Just releasing an ipv6-only endpoint and not dualstacking the original is pretty much guaranteeing not many people will be able to use this. Asking people to change their build / deployment / CI systems everywhere by prefixing a domain name to their containers creates a far bigger problem than the risk of IPv6 brokenness would in [current year].

We don't have a timeline currently.

May I suggest you come up with one. You had users requesting IPv6 as back as at least 2 years and even back then it was kind of bizzare not to be dual stack already. I completely understand that you need to be cautious due to the high usage nature of docker hub but pessimestic delay is not the same as sensible caution. It is especially disappointing you still can't even give a timeline for GA for IPv6.

[moreiras]

Further rollout will be slow and methodical, including notifications to the community. We don't have a timeline currently.

I'm glad you took this step. But Docker's lack of IPv6 support is the real problem to be addressed seriously and methodically. A timeline should be set to have dual stack support for default. If you need help from the technical community to perform specific tests, please indicate which ones and ask. A unnecessary slow approach is not a good way to deal with something that should have been done at least 10 years ago.

[sgryphon]

Docker's lack of IPv6 support

Just to be clear, this issue is about docker.com, docker hub, and other internet host endpoints; not about Docker itself. Docker itself does support IPv6 and dual stack, although the network side is a bit limited (e.g. it has built in NAT44, but you need to add a third party service for NAT66 and may need to set up something like NDP proxy daemon if you don't want to list all your addresses individually). = on Linux hosts, so Windows users still need to be added.

There are probably other issues open for that (Windows, NAT66, NDP).

[moreiras]

this issue is about docker.com, docker hub, and other internet host endpoints

Thanks for expressing the real issue more precisely than in my generic observation. Yes, this is the issue I was talking about when I gave my opnion that it should be taken more seriously, with a well defined timeline. This thread is about "Docker Hub Registry's beta IPv6 support", so it should be clear. But your comment is very welcome.

I would like to understand what specifically is worrying Docker (the company) about a dual stack environment. Maybe there is some real cause of worrying yet to be specifyed. Maybe Docker (the software) do not implement RFC 6555 or similar algorithms? (it's only a suposition here, I don't know about that...)

[swoop124]

hello,

i have deployed a ipv6 only host, and would like to create some docker-containers so i tested registry.ipv6.docker.com but i get this error:

root@dockerext1:~# docker pull registry.ipv6.docker.com/library/portainer/portianer-ce
Using default tag: latest
Error response from daemon: pull access denied for registry.ipv6.docker.com/library/portainer/portianer-ce, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

do i realy have to sign up for a user?

[unixfox]

You misspelled portainer

[danopia]

i have deployed a ipv6 only host, and would like to create some docker-containers so i tested registry.ipv6.docker.com but i get this error:

root@dockerext1:~# docker pull registry.ipv6.docker.com/library/portainer/portianer-ce
Using default tag: latest
Error response from daemon: pull access denied for registry.ipv6.docker.com/library/portainer/portianer-ce, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

I believe the first post here mislead you; the library/ path prefix is only needed for the official "shortened image names".

This is in addition to the typo mentioned above, so try docker pull registry.ipv6.docker.com/portainer/portainer-ce

[swoop124]

thank you, very much.

i dobble and tripplechecked the portainer part but didn't see the missspell ;-)

[sixcorners]

The main concern with enabling AAAA on the existing domains is that users who access Hub on a dual-stack network will suddenly see their traffic switch from IPv4 routes to IPv6 routes. It's possible they may have unforeseen issues with their IPv6 stack which previously went unnoticed. Given the nature of Hub, that could cause issues for users who depend on us, without them having changed anything.

Further rollout will be slow and methodical, including notifications to the community. We don't have a timeline currently.

@binman-docker I understand the desire to keep registry-1.docker.io ipv4 so it doesn't instantly change other people's stuff. Why not create a new domain like registry-2.docker.io, make it dual stack, and then update the default domain in the client? That way the change would be entirely based on what version of docker you are using.

[qeba]

how can i make docker automatically used the registry.ipv6.docker.com instead registry-1.docker.io when i run the docker run command?

[jensens]

I can confirm a docker run registry.ipv6.docker.com/library/hello-world:latest works fine on a Hetzner Cloud CX11 with IPv6 only and also on my DSLite connected computer (provider Magenta Austria).

It would be favorable to soon have some way to configure it as default drop-in replacement for the IPv4 default registry to not have to modify existing scripts, compose files and so on.

[emilylange]

Both @qeba and @jensens

You could add https://registry.ipv6.docker.com to your /etc/docker/daemon.json (or pass --registry-mirror)[^1][^2]:

{
  "registry-mirrors": [
    "https://registry.ipv6.docker.com"
  ]
}

And reload the daemon (or restart).

A docker run hello-world will then automatically try to use registry.ipv6.docker.com/library/hello-world:latest. This is happens in dockerd, so the same applies to docker-compose or so on, not just docker run.

It will also fall back to the IPv4-only endpoint^3 (registry-1.docker.io) if the IPv6 mirror is down or for whatever reason not reachable, which might helpful in dualstack situations.

But this could also enable one to share the same daemon config across IPv4-only, DS and IPv6-only hosts, because the IPv4-only ones will just fall back to the usual IPv4-only endpoint, if one wants to do that for whatever reason :shrug:

The actual blob downloads are always dualstack, even when using registry-1.docker.io btw.

[^1]: https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file [permalink] [^2]: https://docs.docker.com/registry/recipes/mirror/#configure-the-docker-daemon [permalink]

[Manouchehri]

For those using Podman on IPv6-only systems, here's what your config should look like:

/etc/containers/registries.conf

unqualified-search-registries = ['docker.io']
[[registry]]
prefix = "docker.io"
location = "registry-1.docker.io"

# You can remove the two lines below if you don't want to use Google's caching mirror; in my experience it's faster (but doesn't have many images).
[[registry.mirror]]
location = "mirror.gcr.io"

[[registry.mirror]]
location = "registry.ipv6.docker.com"

[maflcko]

Currently it seems there is one ipv4-only, and one ipv6-only endpoint, and both can be provided as registry mirrors. Would it be possible to have a single, fixed endpoint that supports both and thus works on any system?

[ryanhristovski]

Hi everyone, just wanted to update here that we have officially rolled out dual-stack networking capabilities across all of our Docker Hub Registry, Docker Docs, and Docker Scout endpoints!

Read more about it here: https://www.docker.com/blog/docker-hub-registry-ipv6-support-now-generally-available/

[tinco]

hi @ryanhristovski, that's awesome news! But also since about an hour our CI/CD has been breaking with the following error:

#3 ERROR: failed to authorize: failed to fetch anonymous token: Get "https://auth.ipv6.docker.com/token?scope=repository%3Aaeroscan%2Fruby-proj%3Apull&service=registry.docker.io": dial tcp [2600:1f18:2148:bc01:c4:4967:28eb:1824]:443: connect: cannot assign requested address

We're on Hetzner, not sure if that matters.

If I run:

tinco@builds:~$ docker pull registry.ipv6.docker.com/aeroscan/ruby-proj:3.2.0_9.1.1

On the build server directly it works fine, but I can't ping 2600:1f18:2148:bc01:c4:4967:28eb:1824, is that supposed to work? I'm not super well versed in ipv6 configuration so I'm not sure if this is a problem in our build server configuration or on your side.

[tinco]

Actually, I think it's got to do with the Docker daemon running on this system. It's a freshly installed Docker on Ubuntu, just installed this machine a week or so ago following the official Docker instructions (using the Docker apt repository).

if I run:

docker run it ubuntu bash
apt update && apt install -y wget; wget registry.ipv6.docker.com/aeroscan/ruby-proj:3.2.0_9.1.1

It says:

--2023-08-23 16:32:54--  http://registry.ipv6.docker.com/aeroscan/ruby-proj:3.2.0_9.1.1
Resolving registry.ipv6.docker.com (registry.ipv6.docker.com)... 2600:1f18:2148:bc01:c4:4967:28eb:1824, 2600:1f18:2148:bc00:e947:5a7f:a49f:9126, 2600:1f18:2148:bc02:4bf0:3a98:55ae:e3d5
Connecting to registry.ipv6.docker.com (registry.ipv6.docker.com)|2600:1f18:2148:bc01:c4:4967:28eb:1824|:80... failed: Cannot assign requested address.

So I guess the default Docker configuration on Ubuntu doesn't support ipv6?

[tinco]

Ok so I fixed it by following the "Enable IPv6 support" guide in the Docker docs. Specifically I created this file:

/etc/docker/daemon.json

{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64",
  "experimental": true,
  "ip6tables": true
}

And then ran:

sudo systemctl restart docker

And that made this:

docker run it ubuntu bash
apt update && apt install -y wget; wget registry.ipv6.docker.com/aeroscan/ruby-proj:3.2.0_9.1.1

Return

2023-08-23 16:41:02 ERROR 404: Not Found.

As it is supposed to.

@ryanhristovski maybe make the IPv6 support enabled by default in Docker now as well? Maybe the guide needs some more prominence somewhere.

[ryanhristovski]

Hi @tinco we were able to replicate this on our side, thank you for your detailed responses!

From what we found, it seems like docker dind requires those parameters on the host side in order to pull from the ipv6 only endpoint (eg: registry.ipv6.docker.com) - with that said it still worked without additional configuration when we used the dual-stack endpoint.

Wondering why the dual-stack rollover affected your CICD pipeline, do you have any ideas?

[tinco]

Yeah I wonder about that as well, why is it preferring the ipv6 endpoint when ipv6 isn't even enabled? Our CI/CD is orchestrated by Gitlab. We're using the docker executor in their gitlab-runner.

Also I was a bit too early in celebrating, as the CI/CD failed in the next step, where it tries to connect to a PostgreSQL server in a different container using an ipv4 address and it fails to reach it. So now I'm a bit stuck on how to approach this.

[tinco]

Actually, it seems like the problem might be with the docker client itself. I'm sorry for not posting more of a log earlier. Here's the full log of the CI/CD run:

$ echo "Going to build using registry $CI_REGISTRY"
Going to build using registry registry.gitlab.com
$ docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
$ if [[ -z "$CI_COMMIT_TAG" ]]; then # collapsed multi-line command
$ echo "Going to tag as $IMAGE_NAME:$CI_COMMIT_SHA, $IMAGE_NAME:$CI_COMMIT_REF_SLUG, $IMAGE_NAME:latest"
Going to tag as registry.gitlab.com/aeroscan-nl/assets-backend/master/baseimage:7a05534cf1ff2f6651aae06702f89[83](https://gitlab.com/aeroscan-nl/assets-backend/-/jobs/4935247154#L83)7e3294e49, registry.gitlab.com/aeroscan-nl/assets-backend/master/baseimage:master, registry.gitlab.com/aeroscan-nl/assets-backend/master/baseimage:latest
$ docker build -t "$IMAGE_NAME:$CI_COMMIT_SHA" -f baseimage.Dockerfile .
#0 building with "default" instance using docker driver
#1 [internal] load build definition from baseimage.Dockerfile
#1 transferring dockerfile: 412B done
#1 DONE 0.1s
#2 [internal] load .dockerignore
#2 transferring context: 726B done
#2 DONE 0.1s
#3 [internal] load metadata for docker.io/aeroscan/ruby-proj:3.2.0_9.1.1
#3 ERROR: failed to authorize: failed to fetch anonymous token: Get "https://auth.ipv6.docker.com/token?scope=repository%3Aaeroscan%2Fruby-proj%3Apull&service=registry.docker.io": dial tcp [2600:1f18:2148:bc02:4bf0:3a98:55ae:e3d5]:443: connect: cannot assign requested address
------
 > [internal] load metadata for docker.io/aeroscan/ruby-proj:3.2.0_9.1.1:
------
WARNING: buildx: git was not found in the system. Current commit information was not captured by the build
baseimage.Dockerfile:1
--------------------
   1 | >>> FROM aeroscan/ruby-proj:3.2.0_9.1.1
   2 |     
   3 |     ARG environment=production
--------------------
ERROR: failed to solve: aeroscan/ruby-proj:3.2.0_9.1.1: failed to authorize: failed to fetch anonymous token: Get "https://auth.ipv6.docker.com/token?scope=repository%3Aaeroscan%2Fruby-proj%3Apull&service=registry.docker.io": dial tcp [2600:1f18:2148:bc02:4bf0:3a[98](https://gitlab.com/aeroscan-nl/assets-backend/-/jobs/4935247154#L98):55ae:e3d5]:443: connect: cannot assign requested address

Each line prefixed with $ is the actual command that's going to be run, the rest is the output.

Note how it actually logs in to the gitlab registry just fine, but fails when trying to build like this:

$ docker build -t "$IMAGE_NAME:$CI_COMMIT_SHA" -f baseimage.Dockerfile .

And the baseimage depends on an image that resolves to docker.io/aeroscan/ruby-proj:3.2.0_9.1.1 but for some reason it tries to get an anonymous login token from auth.ipv6.docker.com/ instead.

It looks like there is one person who also had this problem a year ago: https://forums.docker.com/t/docker-pull-requires-auth-using-ipv6-but-our-ipv6-is-blocked/131327

EDIT: oh this comment seems interesting: https://github.com/gitpod-io/gitpod/issues/6810#issuecomment-975598549

[bawr]

We're seeing the same problem with a slightly different setup, but the core issue is that we're unconditionally being sent to auth.ipv6.docker.com, which only has an ipv6 DNS record - given that plain auth.docker.com seems to be properly dual-stacked now, likely these issues would go away if that was always the auth target. Presumably that's something y'all could fix on the registry side?

EDIT: Our setup is similar to what @luryus is describing, except it's not on Gitlab CI - passing a docker socket, host is ipv6-capable, container is not (and shouldn't be), building directly on the host works, fails from within a container.

Weirdly enough it also works if you manually docker pull the public images you depend on, even if the pull happens from within a container, it just has to happen before building.

[luryus]

Our CI builds started failing after yesterday, too. We're using Gitlab CI with the Docker executor and mounting /var/run/docker.sock to containers so that we can run docker build inside them.

IPv6 and docker pull works fine on the host, but as the containers themselves only have IPv4, connections to auth.ipv6.docker.com fail inside them.

I wonder if this comes from a mismatch between the daemon (running with IPv6 supported on the host) and the client (running with IPv4-only in the container)?

[vctls]

We're having the same error as https://github.com/docker/hub-feedback/issues/2165#issuecomment-1690690704 on our self-hosted Gitlab CI.
There are already a couple related questions on StackOverflow too.
https://stackoverflow.com/search?q=auth.ipv6.docker.com

By the way, also using Hetzner.

[Neverous]

I found a workaround by enforcing ipv4-only mirror in the daemon settings on the instance /etc/docker/daemon.json:

{
  "registry-mirrors": ["https://registry.ipv4.docker.com"]
}

The issue seems to be as @luryus mentions. The server is connecting to registry over IPv6, getting back the IPv6 only auth endpoint and then docker client side tries to authenticate with it and fails as its running in IPv4 only network... I think it would be better if registry server kept returning dual-stack DNS name instead of directing clients to IPv6-only one when it detected the availability :thinking:

[tinco]

I just wanted to comment that disabling IPv6 on the host fixes the problem, but I think @Neverous solution is better for now.

Considering those solutions, the best would be to just enable IPv6 support in Docker, but for some reason that broke IPv4 connections and I unfortunately don't have time to debug what's going on there.

[sven-codeculture]

Ok so I fixed it by following the "Enable IPv6 support" guide in the Docker docs. Specifically I created this file:

/etc/docker/daemon.json

{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64",
  "experimental": true,
  "ip6tables": true
}

And then ran:

sudo systemctl restart docker

And that made this:

docker run it ubuntu bash
apt update && apt install -y wget; wget registry.ipv6.docker.com/aeroscan/ruby-proj:3.2.0_9.1.1

Return

2023-08-23 16:41:02 ERROR 404: Not Found.

As it is supposed to.

@ryanhristovski maybe make the IPv6 support enabled by default in Docker now as well? Maybe the guide needs some more prominence somewhere.

activating ipv6 on the hetzner server did work for us too

[mtovmassian]

I confirm the @Neverous temporary workaround is working! Thanks! And as mentioned by @tinco, his solution will be wiser as soon as Docker will add a more stable and global IPV6 support.

[adzlocal]

We have a similar setup with gitlab-runner on a Hetzner server and @Neverous workaround works for us as well, thank you.

[ryanhristovski]

Thank you for your patience while we worked on this fix. We've just finished rolling out the solution to use a dual-stack authentication endpoint, as the ipv6 only auth endpoint was setup for the beta release.

Did this solve the issue for you?

[ghaffaru]

for a quick workaround using gitlab ci, modify this section in your .gitlab-ci.yml like so

services:
  - name: docker:dind
    entrypoint: ["dockerd-entrypoint.sh", "--ipv6"]

[binman-docker]

Closing out this issue as IPv6 dualstack is now fully supported by Hub. If you encounter any problems, please open a new issue in this repository.

https://www.docker.com/blog/docker-hub-registry-ipv6-support-now-generally-available/