Bitcoin Forum
November 04, 2024, 02:48:40 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [PULL] IPv6 support  (Read 852 times)
Pieter Wuille (OP)
Legendary
*
qt
Offline Offline

Activity: 1072
Merit: 1181


View Profile WWW
July 24, 2011, 03:18:29 PM
 #1

See https://github.com/bitcoin/bitcoin/pull/427

General changes (even when IPv6 support is not compiled in):
  • Valid, routable IPv6 addresses are stored and forwarded
  • Name lookups are done using the general getaddrinfo() call
  • The detection system for the local address is improved. (addresses are classified according to their 'reachability', and the most reachable local address encountered is used).
  • The rule that no two connections to addresses within the same /16 should be attempted, was generalized by defining address groups:
    • IPv4 addresses are grouped in /16 blocks
    • IPv6 addresses are grouped in /32 blocks
    • Tunneled IPv6 addresses use the encapsulated IPv4 address (teredo, 6to4, SIIT, well-known prefix)
  • Hostnames can be given using the "[host]:port" format.
  • Support for the "checkorder" message was removed (obsolete, and not worth porting)

Behaviour changes when IPv6 support is enabled:
  • DNS lookups also return IPv6 matches
  • The listening socket is bound to the IPv6 ANY address (::/128) instead of the IPv4 ANY address (0.0.0.0)
  • Connections to non-IPv4 addresses are attempted, using IPv6 sockets (connections to IPv4 addresses still use IPv4 sockets)
  • A local IPv6 address is used instead of an IPv4 one if no routable IPv4 address is available. In this case, it is not advertized through IRC (obsolete).

For internal changes, see the commit message.

I do Bitcoin stuff.
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
July 24, 2011, 04:25:17 PM
 #2

Quote
The rule that no two connections to addresses within the same /16 should be attempted, was generalized by defining address groups:
IPv4 addresses are grouped in /16 blocks
IPv6 addresses are grouped in /32 blocks
that just sucks, sorry. i can see why, but it still sucks.

Quote
A local IPv6 address is used instead of an IPv4 one if no routable IPv4 address is available. In this case, it is not advertized through IRC (obsolete).
how the hell are nodes going to find each other then? just asking, im trying to make an alternative client.
the way im finding nodes now are connecting to the official client at 127.0.0.1:8333 , and send a getaddr.


overall: good work! Cheesy

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
Pieter Wuille (OP)
Legendary
*
qt
Offline Offline

Activity: 1072
Merit: 1181


View Profile WWW
July 24, 2011, 04:33:24 PM
 #3

Quote
The rule that no two connections to addresses within the same /16 should be attempted, was generalized by defining address groups:
IPv4 addresses are grouped in /16 blocks
IPv6 addresses are grouped in /32 blocks
that just sucks, sorry. i can see why, but it still sucks.
It's far from optimal, but we need some measure to prevent sybil attacks. The problem is the diversity of the IPv6 network... in some ranges the user-specific part is below /48, in others it is below /16.

Quote
Quote
A local IPv6 address is used instead of an IPv4 one if no routable IPv4 address is available. In this case, it is not advertized through IRC (obsolete).
how the hell are nodes going to find each other then? just asking, im trying to make an alternative client.
the way im finding nodes now are connecting to the official client at 127.0.0.1:8333 , and send a getaddr.

Such nodes will still get IPv4 nodes from IRC, and connect to those. It will also advertize its own IPv6 address on the network, which will hopefully propagate that address (current clients don't). Eventually, its address will hopefully end up in DNS seeds, where it can be found by all IPv6-capable nodes.

I do Bitcoin stuff.
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
July 24, 2011, 07:35:17 PM
 #4

Quote
The rule that no two connections to addresses within the same /16 should be attempted, was generalized by defining address groups:
IPv4 addresses are grouped in /16 blocks
IPv6 addresses are grouped in /32 blocks
that just sucks, sorry. i can see why, but it still sucks.
It's far from optimal, but we need some measure to prevent sybil attacks. The problem is the diversity of the IPv6 network... in some ranges the user-specific part is below /48, in others it is below /16.

Wait, somebody got an IPv6 /16 block?! That sounds like a monstrous waste of address space. Didn't they learn anything from how fast the IPv4 addresses ran out?

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
July 24, 2011, 07:39:44 PM
 #5

Quote
The rule that no two connections to addresses within the same /16 should be attempted, was generalized by defining address groups:
IPv4 addresses are grouped in /16 blocks
IPv6 addresses are grouped in /32 blocks
that just sucks, sorry. i can see why, but it still sucks.
It's far from optimal, but we need some measure to prevent sybil attacks. The problem is the diversity of the IPv6 network... in some ranges the user-specific part is below /48, in others it is below /16.

Wait, somebody got an IPv6 /16 block?! That sounds like a monstrous waste of address space. Didn't they learn anything from how fast the IPv4 addresses ran out?
2001: ?

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!