[fChk]

I think it's time to document my experience with the free EUServ VPSs from the perspective of being IPv6-only.

Running an IPv6-only VPS in today's still predominantly IPv4-based has challenges of its own. Of course, the degree will vary depending on your situation's specifics. Thus, I'll not try in anyway to be exhaustive but just document my steps at addressing them, given my own use-cases, starting with the most important in this OP.

Connecting you to an IPv6-only VPS: not that easy!
First things first; it happens that my ISP connectivity is still IPv4-only and, to make matters worse, it's heavily using NAT (Network Address Translation). In this situation you're already running into your first problem of not being able to reach your VPS.

IPv4 and IPv6 are 2 incompatible protocols, but there are ways that try to make them communicate with each other. IPv4/IPv6 interoperability is a large subject that I won't get into here. Suffice it to say that there are two ways to address the issue in my own situation:

1. Use of a dual stack VPS that will serve as your 'private gateway' to the IPv6-only VPS. The most basic way to do this is just to SSH into your dual stack VPS; and from there SSH again into your IPv6-only VPS. It can't get simpler than this.
   
2. use of IPv6 Teredo Tunnelling (RFC-4380.) -On linux machines, by installing and running miredo, you create a pseudo-interface called 'teredo' -by default- that will get assigned a dynamic IPv6 address, thus exposing you to the Internet -after been practically invisible inside your ISP's NAT (this is important and you should consider shoring up your defences while merido service is running.)
   

Code: (Select All)

ifconfig teredo
teredo: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280
        inet6 fe80::269e:709d:c56f:964d  prefixlen 64  scopeid 0x20<link>
        inet6 fe80::ffff:ffff:ffff  prefixlen 64  scopeid 0x20<link>
        inet6 2001:0:53aa:64c:***:****:***:****  prefixlen 32  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 50  bytes 7458 (7.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 73  bytes 8446 (8.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I won't get into the details but just saying that the Teredo IPv6 address is recognizable by its 2001:0 prefix and the 53aa:64c part is mapped to the Teredo server IPv4 address while the rest is user's related (IPv4 address + ports used.)


So now we've finally did it and logged into this IPv6-only VPS; then what?!

Connecting IPv6-only VPS to the IPv4-Internet :
This part was easy to sort out, thanks to @'Hidden Refuge' tip in his OP of the free EUServ VPSs Offer. From the links he provided, I ended up here (Public NAT64 service) and here (NAT64/DNS64 public test.)

My systemd-resolved config file @'/etc/systemd/resolved.conf' looked like this:

Code: (Select All)

[Resolve]
DNS=2a01:4f8:c2c:123f::1 2a01:4f9:c010:3f02::1 2a00:1098:2c::1
FallbackDNS=2001:67c:2b0::4 2001:67c:2b0::6

Using a NAT64/DNS64 gateway is a matter of redirecting your traffic via their routers by simply using their nameservers.

Now that this is out-of-the-way, what about running a Web server?

Running a Web Server:
Not much of a difference configuration-wise, just make sure to make HTTPD/Nginx listen to the adhoc-interfaces that are IPv6-enabled and let CloudFlare (CF) do the routing of the IPv4-traffic for you, because in this case nothing else work, AFAIK.

Thus, you'll need to use both CF DNS and proxying services for your website to be universally accessible. I'm  assuming that this is trivial knowledge, thus I won't dwell on it much longer.

For a TLS-enabled website, I always opt for the full strict option when it comes to CF-enabled websites.

One important issue I faced in the case of Nginx is that OCSP Stapling fails on IPv6-only hosts!!..

Code: (Select All)

2020/03/25 09:52:20 [error] 7371#0: unexpected response for ocsp.int-x3.letsencrypt.org
2020/03/25 11:04:46 [error] 7371#0: connect() to 23.55.163.68:80 failed (101: Network is unreachable) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, peer: 23.55.163.68:80, certificate: "/etc/letsencrypt/live/srvxyz.blue.kundencontroller.de/fullchain.pem"

The cause is Nginx prioritizing IPv4 addresses over IPv6:

Code: (Select All)

[root@ipv6VPS ~]# host ocsp.int-x3.letsencrypt.org
ocsp.int-x3.letsencrypt.org is an alias for ocsp.int-x3.letsencrypt.org.edgesuite.net.
ocsp.int-x3.letsencrypt.org.edgesuite.net is an alias for a771.dscq.akamai.net.
a771.dscq.akamai.net has address 23.55.163.68
a771.dscq.akamai.net has address 23.55.163.48
a771.dscq.akamai.net has IPv6 address 2a01:4a0:1338:28::c38a:ff10

The fix:

Code: (Select All)

server {
   ...
   ssl_stapling on;
   ssl_stapling_responder http://[::1]:8082;
   ...
}

server {
   listen [::1]:8082;

   location / {
       proxy_pass http://ocsp.int-x3.letsencrypt.org;
   }
}

For more on this issue, please see 'OCSP stapling non-functional on IPv6-only host'


I'll stop at this point, and may add other IPv6-specific issues when they come to light, so can anyone else who has found something of his own. Please share!

[rudra]

Miredo code is old.

Windows has teredo client implementation inbuilt. can be set up from command line. did you know that ?

also Microsoft has free teredo servers in Seattle. many others provide that too.

[fChk]

Miredo code is old.

The question is does it implement RFC-4380 or not?.. Of course if the RFC is frozen and the technology is being slowly phased out due to an increasingly widespread deployment of IPv6, then there is no incentive in doing anything with the already existing code unless keeping its dependencies up-to-date, which is the case for miredo, hence it's still running and got the job done!

Windows has teredo client implementation inbuilt. can be set up from command line. did you know that ?

Of course!... Did you know that it's MS engineers that wrote the first draft of the Teredo protocol, in the first place ? :-)

Check this post:
https://post4vps.com/Thread-Up-to-3x-fre...4#pid34504

also Microsoft has free teredo servers in Seattle. many others provide that too.

I highly doubt that!.. I've only come across one that's still working, ie  teredo.remlab.net. But it would be nice if you provide some working examples of Teredo servers, M$'s or otherwise.

I think the majority has phased out their service.