RPC: conf var rpcallowip=::/0 stopped working when upgrading to 0.21 #21070

TL;DR: When upgrading from Bitcoin Core 0.20.1 to Bitcoin Core 0.21.0, a downstream application using the HTTP JSON-RPC API started getting HTTP 403 "Forbidden".

Turns out it is because I have rpcallowip=::/0 in bitcoin.conf which used to work but does not anymore. As a workaround, rpcallowip=0.0.0.0/0 works.

I run bitcoind in docker container1, and some application using the HTTP JSON-RPC API of bitcoind is in docker container2. They are on the same "docker network".

In bitcoin.conf I have:

rpcauth=<...>
rpcbind=0.0.0.0:8332
rpcallowip=::/0

(bitcoind RPC is not actually exposed to the public internet; it is up to the docker layer and above to ensure this.)

The application in container2 is connecting through HTTP accessing an URL such as http://user:pass@172.19.1.10:8332/.

This setup used to work when running Bitcoin Core 0.20.1 in container1.

It no longer works with Bitcoin Core 0.21.0.

If I change my bitcoin.conf as below, it starts working again using 0.21:

rpcauth=<...>
rpcbind=0.0.0.0:8332
rpcallowip=0.0.0.0/0

So rpcallowip=::/0 used to work but does not anymore; rpcallowip=0.0.0.0/0 works.

Easy way to test: curl --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getblockchaininfo","params":[]}' -H 'content-type:text/plain;' http://user:pass@172.19.1.10:8332/

I think the new behaviour is correct. You're allowing all IPv6 hosts, but only binding to IPv4.

hit this issue a few days ago.. but i saw kylemanna already fixed it in his repo https://github.com/kylemanna/docker-bitcoind/pull/72

I'm seeing this behavior as new as of 0.21.0 also. Definitely an unpleasant user experience.

Perhaps the user experience thing could be solved with better documentation and/or a warning in relevant situations?

Regardless of the historical behaviour it feels risky to make it so that adding what looks like an "IPv6 allow" also implies an "IPv4 allow" (or vice versa).

In other words: if rpcallowip=::/0 used to imply also rpcallowip=0.0.0.0/0 then that feels like buggy behaviour :)

@MarcoFalke should this be closed now that the old behaviour is buried under 3 releases?

Although, perhaps we keep it open as I don't see any test which would check for regression of this behaviour...

Maybe the docs or a warning can be improved, see the previous comment: #21070 (comment)