Net: Add IPv6 Link-Local Address Support

mruddy commented at 5:20 am on February 21, 2016: contributor

Adds support for binding and listening, as well as connecting to, scoped IPv6 addresses.

I wanted to be able to use IPv6 link-local addresses on 4.2+ GNU/Linux (sin6_scope_id was added in 2.4). So, that’s what I’ve tested. It seems to work. If I missed something, please let me know and I’ll fix it. I haven’t tried with Windows or Mac, but I think the support is present in many versions of those systems too. Hopefully, this does not simply fail for the automated Windows build (fingers crossed). IPv6 scoped addresses are also known as link-local and site-local addresses. The Linux docs say, “Linux supports it [sin6_scope_id] only for link-local addresses”. Windows may support site-local addresses.

Note that if you test this, it’s easier to see the bound address with something like: sudo netstat -pantu --wide | grep bitcoin Also, here’s an example of an easy way to find nodes accessible on your local link: ping6 -I eth0 -n ff02::1

Basically, commands similar to these should work now, instead of failing with "Unable to bind to [fe80::1234:5ff:fe67:89ab]:8333 on this computer (bind returned error Invalid argument (22))" or "socket send error Broken pipe (32)":

bitcoin-qt/bitcoind -listen -bind/-whitebind='[fe80::1234:5ff:fe67:89ab%eth0]:8333'
bitcoin-qt/bitcoind -connect='[fe80::1234:5ff:fe67:89ab%eth0]:8333'

This should still fail due to missing the scope ID:

bitcoin-qt/bitcoind -listen -bind/-whitebind='[fe80::1234:5ff:fe67:89ab]:8333'

This should still fail due to the scope id being misplaced:

bitcoin-qt/bitcoind -listen -bind/-whitebind='[fe80::1234:5ff:fe67:89ab]%eth0:8333'

References: http://man7.org/linux/man-pages/man7/ipv6.7.html http://research.microsoft.com/en-us/um/redmond/projects/msripv6/docs/config.htm https://msdn.microsoft.com/en-us/library/windows/desktop/ms739166(v=vs.85).aspx https://tools.ietf.org/html/draft-ietf-ipv6-scope-api-00

jonasschnelli added the label P2P on Feb 21, 2016

laanwj commented at 9:05 am on February 24, 2016: member

Potential nit, haven’t looked at the code in detail: by their local nature there’s no way that scoped addresses can work in the P2P address advertising logic - so from a privacy angle, does this make sure that these can’t leak to the P2P network?

mruddy commented at 3:05 am on February 25, 2016: contributor

For the link-local addresses I believe that is accounted for already because CNetAddr::IsRFC4862 matches them and thus CNetAddr::IsRoutable returns false for them.

About the site-local category of scoped addresses, upon more investigation, their usage is already deprecated by RFC 3879 (https://www.ietf.org/rfc/rfc3879.txt) and Linux does not support them. I only mentioned them because the Windows documents mentioned them and I’m inclined to think that we don’t need to concern ourselves with them. If we do, then we could maybe add another method to match them and then make that part of the IsRoutable check too.

laanwj added the label Feature on Feb 29, 2016

mruddy renamed this:
~~Net: Add IPv6 Scoped Address Support~~
Net: Add IPv6 Link-Local Address Support
on Mar 29, 2016

mruddy force-pushed on Mar 29, 2016

mruddy force-pushed on Mar 30, 2016

petertodd commented at 12:45 pm on March 30, 2016: contributor

Concept ACK

Net: Add IPv6 Link-Local Address Support eda3d92489

mruddy force-pushed on Apr 5, 2016

mruddy commented at 10:48 pm on April 5, 2016: contributor

I rebased and re-worked this commit to make it easier to review. Previously, I tried to be complete. This only changes the minimum needed to get it to work.

Also, circling back on the site-local addresses… Their original behavior has been deprecated for many years. I tested fec0/10 and fec0/64 addresses with Bitcoin Core 0.12.0, and it already binds them with no problem and does not treat them as local (it advertises them). That existing behavior is in line with RFC guidance: https://tools.ietf.org/html/rfc4291#section-2.5.7

0"The special behavior of this prefix defined in [RFC3513] must no longer be supported in new implementations (i.e., new implementations must treat this prefix as Global Unicast)."

That’s good. It means this PR only has to concern itself with link-local (which was the original intent).

The link-local fe80/64 [https://tools.ietf.org/html/rfc4291#section-2.5.6] addresses are treated as being local/non-routable/non-advertisable already. Discovery of our own addresses does not add/include link-locals. As stated before, CNetAddr::IsRFC4862 matches link-locals and thus CNetAddr::IsRoutable returns false for them. This ultimately stops them from being advertised.

The motivation for this change is to make it easier to deploy and manage a cluster of nodes on a local network. For example, I was spinning up multiple nodes on an adhoc WIFI network for a simulation and IPv6 link-local addressing made that process easier by a few steps for each node.

laanwj commented at 2:08 pm on April 6, 2016: member

Thanks for the explanation. I was indeed curious what one would use this for in practice.

utACK https://github.com/bitcoin/bitcoin/pull/7570/commits/eda3d9248971a1c3df6e6c4b23ba89be30508b51

sipa commented at 2:46 pm on April 6, 2016: member

utACK https://github.com/bitcoin/bitcoin/pull/7570/commits/eda3d9248971a1c3df6e6c4b23ba89be30508b51

laanwj merged this on Apr 8, 2016

laanwj closed this on Apr 8, 2016

laanwj referenced this in commit 232592a71f on Apr 8, 2016

mruddy deleted the branch on Apr 8, 2016

codablock referenced this in commit 823afc6905 on Sep 16, 2017

codablock referenced this in commit 0a45bf463e on Sep 19, 2017

codablock referenced this in commit b2d659f199 on Dec 20, 2017

MarcoFalke locked this on Sep 8, 2021

Net: Add IPv6 Link-Local Address Support #7570