[PULL] IPv6 support

[Pieter Wuille]

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.

[1715468076]

1715468076

[1715468076]

1715468076

[1715468076]

1715468076

[1715468076]

1715468076

[1715468076]

1715468076

[kokjo]

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.

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!

[Pieter Wuille]

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.

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.

[error]

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?

[kokjo]

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: ?