IPv6 node support #1021
IPv6 node support #1021
Conversation
|
I can't really comment on your code changes, but I'm interested in some of the changes. You removed / changed how the global var addrLocalHost worked. There is now a list / an array which holds all local addresses, which can be used for bitcoin network connections. That one can be queried via GetLocal(), right? I understand this is needed for IPv6, but could that be used if a client had more than 1 NIC with internet connection, too? Is IPv6 external address detection possible like with IPv4 or is there a new mechanism in the protocol? |
|
@Diapolo: yes you can use it with multiple NICs; it's even in a separate commit named "Support for multiple local addresses". IPv6 external address detection works the same way as IPv4, though IRC and whatismyip.com will obviously only tell you about IPv4 addresses. |
|
Thanks for the infos @sipa. How would I query or list all interfaces that are used for connections, is this possible with a single GetLocal() call somehow? |
|
GetLocal() queries the mapLocalAddress database; this contains the routable addresses detected on local interfaces, but also addresses discovered through UPnP, IRC, website lookups, or manually specified. There's not really a way to link them back to interfaces anymore (though you can find those in debug.log, lines of the form "ipv4 eth0: 192.168.1.1"). |
|
I'm asking, because I have a small commit in the pipe, which displays the external IP as a tooltip when you hover the connection symbol in the Qt client. This would get broken by your commit and I wanted to know if I could make it work again (if it ever get's accepted - but it would be an added value to the GUI). To query all used IPs via a foreach or sth. like that would be nice. |
|
You can query which potentially local addresses bitcoin knows about (just check the mapLocalAddress), but that is not the same as the addresses it's reachable on (no way to know that for sure) or the address of local interfaces. Edit: you could just use GetLocal(addrBest, NULL), which will return the most likely publicly reachable address. |
|
Needs rebasing. Sipa broke everything using locks. >_< |
|
Yeah, I'm a lock breaker. Rebased. |
| @@ -62,6 +62,12 @@ contains(USE_DBUS, 1) { | |||
| QT += dbus | |||
| } | |||
|
|
|||
| # use: qmake "USE_IPV6=1" | |||
There was a problem hiding this comment.
Why should IPv6 be disabled by default for Bitcoin-Qt? :/
There was a problem hiding this comment.
Also, note that USE_* flags currently represent optional dependencies. I'm not sure IPv6 is a dependency, just a feature?
There was a problem hiding this comment.
I intended it to be disabled by default everywhere, but at least it should be consistent.
|
I'm sure IPv6 support is one of the biggest infrastructure things in the "Internet" ... would it perhaps be a good idea to offer an IPv6 enabled beta instead of merging directly into master? That's no NACK btw! |
|
IPv6 is basically deployed by now. Even in the rare cases of ISPs behind the times or ancient routers, Windows will still setup a Teredo tunnel and Linux users can trivially configure 6to4. |
|
Ok, updated.
|
|
as soon as support for tor/i2p hidden services is added, you'll probably need -externalip=something.onion to make your node advertize that address as well. It seems a bit strange to limit the function to IPv4 when the semantics are exactly the same for every network. |
|
ACK |
|
Socks version is now selectable using -socks=. |
|
I would like to merge this sooner rather than later... we can always merge this with !USE_IPV6 for 0.6.1, for example, and then turn on USE_IPV6 on 0.7. |
|
I just split off the SOCKS-related changes to another pullreq. |
|
is the -externalip=blahblah.onion working yet? |
|
No, that requires onioncat-style IPv6 addresses support. |
This will make bitcoin relay valid routable IPv6 addresses, and when USE_IPV6 is enabled, listen on IPv6 interfaces and attempt connections to IPv6 addresses.
There are plans to let Bitcoin function as Tor/I2P hidden service. To do so, we could use the established encoding provided by OnionCat and GarliCat (without actually using those tools) to embed Tor/I2P addresses in IPv6. This patch makes these addresses considered routable, so they can travel over the Bitcoin network in 'addr' messages. This will hopefully make it easier to deploy real hidden service support later.
Introduce a boolean variable for each "network" (ipv4, ipv6, tor, i2p), and track whether we are likely to able to connect to it. Addresses in "addr" messages outside of our network get limited relaying and are not stored in addrman.
|
Added -bind=[addr]. |
|
FWIW, I don't seem to be getting any IPv6 connections with this |
|
@luke-jr how do you mean? |
|
I mean, I expect running with this should get me at least a few IPv6 connections..? |
|
You're probably the only one besides sipa running an IPv6 node, so connection success seems doubtful |
|
I'm running this also, and I think I have IPv6 enabled. |
…KVOTE -> NetMsgType::TXLOCKVOTE (bitcoin#1021)
control which config params add to bitcoin.conf
a3dea2f [CMake] Search for and include system includes dir containing endian.h (Fuzzbawls) 675ae85 Update `crypto/common.h` functions to use compat endian header (Fuzzbawls) Pull request description: instead of using the ambiguous `endian.h` header include in `crypto/common.h`, specify our in-tree intermediary header. At the same time, make use of `config/pivx-config.h` and fixup the CMake builds on linux that previously used forced defines. ACKs for top commit: random-zebra: ACK a3dea2f furszy: utACK [a3dea2f](PIVX-Project@a3dea2f) Tree-SHA512: 6c82890a574c8c5ebb3e16503840dea692589697e24f0101df97ccb31641b2931f663afbbfff6134d6dd7a5e39165acba23490f009fc63341c66d986daa8660e
This will make bitcoin relay valid routable IPv6 addresses, and when USE_IPV6 is enabled, listen on IPv6 interfaces and attempt connections to IPv6 addresses.