parallel IPv4/6 support and future backup links

[gufmar]

A current node's config file has one public_address field allowing to set either one IPv4 or one IPv6 address being announced to other nodes.

Describe the solution you'd like Have at least one public_address field for IPv4 and IPv6 in order to allow inter v4/6 networking at all.

trusted_peers:
    - "/ip4/52.208.94.64/tcp/80"
  public_address: 
    - "/ip6/2a02:2f01:0:e200::1001/tcp/8299"
    - "/ip4/1.2.3.4/tcp/8299"

The given order in the config file should be used as a preference.

If there is one connection established between two nodes who both talk v4 and v6, the second one should become active only as a failover link.

a future extension could be to allow multiple IPv4 and IPv6 addresses that can be enabled as a backup connection if necessary.

[mark-stopka]

I am not sure users should be forced to set the advertised IP anyway, there are discovery methods that let application determine IP addresses (unless asymmetric routing is used), I think auto-discovery should be default for both IPv4 and IPv6 at a same time.

At least on servers that have IP addresses configured directly in the interfaces and don't use NAT with port forwarding, but even in simple NAT with port forwarding scenario the node should at least try to determine it's public facing IP and provide IP discovery result in the log...

[mzabaluev]

I am not sure users should be forced to set the advertised IP anyway, there are discovery methods that let application determine IP addresses (unless asymmetric routing is used)

There is a whole lot of application layer complexity and fragility there, as known to developers that had to deal with SIP or decentralized P2P applications. We probably should also do what everyone else does and try UPnP IGD, NAT-PMP, and maybe PCP, for hole punching and public address discovery.

In the brave new world of IPv6 where we should all end up, we could try to advertise all of host's addresses with global scope unless the user overrides. There may be privacy considerations against doing that, though. Hole punching will likely still be needed for users in firewalled local networks.

[mark-stopka]

@mzabaluev, I was not brave enough to suggest UPnP support, but was thinking it would be cool :).

[Willburn]

I also wish for discovery method (But let users who want to specify static IP do so). I think this scales better for future phone / IOT usage and gives the pool redundancy (for example in ability to switch IP if need be during say an attack).