But when this is implemented then NAT should be restored to allow people that are able to configure manually their router to participate. Those who can’t wouldn’t burden the network because their node will be killed.
STUN-like connectivity, hole punching, IGD,… should be delayed later.
I think the launch may well look like that. NAT is such a PITA and causes folk to try loads of weird and wonderful things. So manual port forward should be fine and if the network detects an issue a suitable error should make that clear to the user.
This does not bode well for the prospects of SAFE, imo. Most people don’t want to be bothered with technical rabbit holes like port forwarding and I would venture to say that the majority of our potential participants do not even know what NAT is, they just accept it is as part of the necessary way they connect to the network if they even understand it or are aware of it. If NAT users are excluded or prohibitively inconvenienced they will just go away, no SAFE for them.
FYI, in my location a home user cannot even get a static (public) IP address, only business customers who pay a higher monthly fee.
So we launch and look to get an effective critical mass of non-NAT participants and grow the network from there which will hopefully buy us enough time to solve the NAT issue?
As I understand, there are 2 separate issues here:
NAT/port forwarding. This is not a big issue in my view. Most p2p services need ports to be opened, and that’s typically handled manually or automatically through upnp/IGD. Sure hole punching would be great, but not a priority imo
static IP. I have a static IP I pay 5$ a month for, but I understand this could be very limiting. The typical solution is using Dynamic DNS services such as no-ip (often often integrated in the router). So the question is, does the current protocol work with DDNS services?
I think --skip-auto-port-forwarding simply doesn’t force IGD/hole punching, but the ports still need to be opened (manually) in order for the node to be reachable
Fair enough I should have said safe node join --local-addr <ip of device running node>:<port> \ --public-addr <your internet public ip>:<port opened on router> \ --skip-auto-port-forwarding
If we join in this manner is there still a problem?
Probably better if @dirvine clarifies that, but if you have 1) a static IP, and 2) open ports, I can’t see why behing behind NAT would be a problem, since port forwarding effectively bypasses the NAT. Unless the problem is with the local IP assignment.
Does the network use specific ports or random ports. Because you could set a device behind the router and have the router send specific posts to that device (virtual server). That way NAT is bypassed for those ports at the internet facing IP address.
Many gamers (torrents too) know how to do this now. So the available audience would be much larger if at least this can be done.
Its a mixed bag for many. For instance here with 2nd biggest ISP the IP address remains the same for a long time (years if router is left on and only off for short periods) for non-static IP accounts.
I wonder if long term there couldn’t be a function for a node to report a new IP address if the ISP changes IP address on it. @dirvine would this be an issue, could it even be done without too much problems.
You still get non-static public IPs? Interesting. Here in Czech Republic standard is you either pay extra for static public IP or you get private IP and you are behind ISPs NAT.
And ISPs sometimes use exotic solutions. Here I have public IP, but in the form of 1:1 NAT (public IP is somewhere out of my reach and all ports are translated to private IP on my router). It works 95% fine, but some programs get confused. IPv4 connectivity is a minefield.
Well the virtual server from the outside is seen at the public IP address. The only issue is the device still has a NAT assigned IP address for its local IP address, so if you test for public IP == device IP then it would fail. But otherwise for those ports it is being a virtual server for, it will be seen as having the public IP address and the router fixes the NAT IP to public IP on the outgoing packets.
As far as I know the virtual server will be seen as being at the public IP address. Its only if you test Public = device IP that it would fail
Yes Australia is small population in comparison to most other countries. We had a large allocation of IP addresses given to the large ISPs early on. We may still have issues with the way the NBN routes things, but the NBN router has its public IP address allocated by the ISP. The NBN is basically a big L2 switch with the usual funnies to do some L3 routing for the ISPs. But to date the translations they may do still has it working properly for my router to have a semi static IP address and no problems so far.
But I’d love to see if virtual server will work. Obviously this will only allow one device to be a node, but hey it’d be good. Also virtual servers would allow most (semi) tech/game/etc literate people here to participate from home.
I am starting to think even trying to understand is too much of a headache. Bring the block.
After reading all replies, I am still not sure what the actual problem is.
So is the/a problem that even with manually configured ports the ISP may change your ip and the node can no longer be connected to?