NEM & SYMBOL: IPv6 Support

Technical Discussion
#1

As we all now, IPV4 public addresses are running out. Upgrading to IPV6 (with almost idefinitely many addresses available) mitigates this bottleneck.
People don’t really use it yet.
At the moment, most legacy system configurations opt to “switch off IPV6 Support” (i bet your home routers and various devices have IPV6 support but you never turned it on).

Which brings me to the question(s):
1. Is Symbol fully IPV6 compatible?
2. Can we choose and configure not to use IPV4 but only the new standard?
3. Would IPV4 nodes be talking & in sync with IPV6 nodes?

It could be easier to host one larger physical server, get a block of IPV6 public IPs and then host 100 VMs inside the server (hint: to host SYMBOL Testnet nodes :slight_smile: ) and not need to expensively purchase 100 IPV4 public IPs.

Disclaimer: I did not read through all the NEM&SYMBOL documentation and might have overlooked configuration and behaviour info on IPV6. If that’s the case, please someone guide me to the right resources.

For completeness: Link to the previous community member question regarding this (Sep/2015): Does Nem network supports IPV6?

7 Likes
#2

Good question.

1 Like
#3

Only IPV4 is supported at the current time.

You can open a GitHub issue for IPV6 support.

1 Like
#4

Done. https://github.com/nemtech/catapult-server/issues/63

2 Likes
#5

Screenshot 2020-04-09 at 15.53.54
Screenshot 2020-04-09 at 15.53.54753×768 69.9 KB

OK, Gimer gave thumbs-up in Github.

I hope this “issue” will stay in the queue and be considered for next improvement upgrades.

3 Likes
#6

@Jaguar0625 Perhaps my suggestion should rather go into https://github.com/nemtech/NIP/issues/ ?

Not sure…
I don’t want to duplicate it. Leaving it to you guys.

#7

Hi @r3n3,

Thanks for opening the issue! The suggestion is correctly tracked as an issue. Issues are monitored regularly and taken into account while open. It makes sense to open a NIP as well if you want to lead the improvement. This includes driving the discussion, designing the proposal, and providing a possible implementation.

Note that core devs publish NIPs for every breaking change and improvement since the first RC release v0.9.0.1. If the core devs pick the issue, you will see a new NIP published once there is a draft solution designed.

1 Like
#8

there are 2 ipv6 nodes in Japan
http://[2a02:c207:2036:500::1]:3000/node/info
http://[2401:2500:102:3007:153:126:143:201]:3000/node/info

But they don’t support HTTPS.

2 Likes
#9

I think https-portal works with both IPv6 and IPv4
https://symbol-testnet.u2yasan.com:3001/node/info

You can check it by turning IPv4 off.
mac
System Preferences > Network [Advanced…]
[TCP/IP] Configure IPv4 : Off
windows
Control Panel > Network and Internet > Network Connections
[Properties] check off ( TCP/IPv4 )

3 Likes
#10

Cool! Thanks for the info @utsu_jp and @TakaNobu .

On 14/Mar the core developer Jaguar informed in this thread that only IPv4 is supported. So I assume we can access the Symbol Webserver (and API listener) via IPv6 now, but the catapult server still requires IPv4.

Next to find out, (probably most interesting for me to know now) is whether the node-sync and peer discovery would work without an IPv4 WAN IP. If yes, there can be one bottleneck removed for running many nodes within one server.
(We could virtualise tens of servers in one hypervisor without the need for public IPv4 IPs).
Could we set an FQDN in config-node.properties and configure it with an AAAA DNS entry to point to the IPv6 address only?

That way, public testing could perhaps be accelerated, too.

I have to admit I did not test it myself before asking… Am quite busy with business matters at this moment of this worldwide virus crisis.
Be safe everybody!

Rene / LuxTag.io

3 Likes
#11

I just found this post while looking for something else entirely - IPV6 is supported now for anyone who reads it later

2 Likes