Currently even if the OPI device has proper IPv6 globally routable address, the op-i.me name created for the device only has IPv4 address. I did verify that my OPI device did get IPv6 address and that IPv6 address pingable from outside, but unfortunately the https service is not running on the IPv6 address.
This causes some problems for me, as the default setup does not work. In my home I have proper globally routable IPv6 which are not NATed, but the IPv4 addresses are NATed by my firewall. When I try to configure the OPI it creates name only for my external IPv4 address for my device. As I do not have NAT reflection configured on in my firewall, I cannot access my public IPv4 addresses from home, only outside the network, which means the op-i.me name created for me is useless when I am at home (I think I saw some other people complaining similar issues).
In my case the problem could be solved if the OPI would include proper IPv6 support, and also would put AAAA record for the op-i.me name.
Another option would be to include both internal and external IPv4 address in the A record, i.e. the OPI box could also send the IPv4 address seen from the inside to the server, and server could put both address to the name. So when connecting to opname.op-i.me you would get both internal and external address, and then browser can try both and use whatever works.
Is the IPv6 support on the roadmap?
Proper IPv6 support?
Hi kivinen,
IPV6 is of course on the roadmap. Unfortunately a bit further down the road (My apologies for this)
Regarding multiple IPs or round robin for the OPI-name. This could definitely be a solution. I'm just worried that connection times would be terrible if the browser first tries the "wrong" IP.
/Tor
IPV6 is of course on the roadmap. Unfortunately a bit further down the road (My apologies for this)
Regarding multiple IPs or round robin for the OPI-name. This could definitely be a solution. I'm just worried that connection times would be terrible if the browser first tries the "wrong" IP.
/Tor
Actually when thinking this more today, I realized that as the op-i.me uses very short TTL and all the requests to it come to the ns{1,2}.openproducts.com, it would be possible to do the requests so that it will reply differently depending on the IP-address where the request is coming.
I.e. if the request comes from the same IP-address what is the public IP-address of the opi box, then it will return internal IP-address instead of the external IP-address. This would fix the situation for the users who has just one IP-address (very common setup at home).
This would not solve the situation for those of us who has larger IP-address block, but in that case the IP-address block is static anyways, so in our case we should just configure the what is the local network, i.e. say that all requests coming from the 83.145.195.0/28 should return internal address, and all others should use external address.
This would solve the problem with connection times, as the network would have only one IP-address.
And currently the connection times are really terrible, as it cannot connect at all
I.e. if the request comes from the same IP-address what is the public IP-address of the opi box, then it will return internal IP-address instead of the external IP-address. This would fix the situation for the users who has just one IP-address (very common setup at home).
This would not solve the situation for those of us who has larger IP-address block, but in that case the IP-address block is static anyways, so in our case we should just configure the what is the local network, i.e. say that all requests coming from the 83.145.195.0/28 should return internal address, and all others should use external address.
This would solve the problem with connection times, as the network would have only one IP-address.
And currently the connection times are really terrible, as it cannot connect at all