I have a working ipv6 configuration at home and was wondering if HE considered providing a cloud based DNS64/NAT64 solution so that I could get rid of dual stack locally?

I have tested using the following site, and see that it would work for me, but since it is based in Eastern Europe (I am USA), it adds significant lag.

https://go6lab.si/current-ipv6-tests/nat64dns64-public-test/

It seems this would be a service that would enable more wide spread usage of IPv6.

Yup, tried the HE script in v1809 and it works!

10/10 and 20/20 (with an ICMPv6 Echo Request exception in firewall) for www.test-ipv6.com and www.ipv6-test.com, respectively.   

Best of all, it survives a reboot. 

Odd thing is, the "Microsoft Direct Point-to-point Adapater" doesn't show up in Device Manager, even with Show Hidden Devices.   

Anybody tried the tunnel on the final 1809? I ended up setting up a router after all...but because it's very very old (2003 or so) it can't handle more than 20 MBit/s. However, it works and it doesn't rely on my main machine running all the time.

Back since 02:10 am

I confirm the down time.
Any way to get information from HE?

Seems down since 22h51

"good 127.0.0.1" is the defined Dyn API reply for a request which doesn't conform to the requirements.  Most of the time this is thrown because the supplied IP address isn't pingable.

The Client IPv4 address is not updating on my Tunnel Details page of:
https://www.tunnelbroker.net/tunnel_detail.php?tid=xxxxxx

I have been using the instructions here:
https://forums.he.net/index.php?topic=1994.0

https://<USERNAME>:<PASSWORD>@ipv4.tunnelbroker.net/nic/update?hostname=<TUNNEL_ID>

I also tried setting the IP specifically via:
https://<USERNAME>:<PASSWORD>@ipv4.tunnelbroker.net/nic/update?hostname=<TUNNEL_ID>&myip=<IP ADDRESS>

In all cases, the responses are:
good 127.0.0.1
Which is weird even when I specify the myip=

Which is clearly the wrong IP, and it's not updating the Tunnel Details - so my Tunnel no longer works because the server doesn't recognize my IP (which changes frequently from ISP).  I have a curl -4 script running with the URL on a daily basis to keep it updated, but I just discovered my tunnel has been down.

Glad to see your issue is resolved.  However, note:  A failing traceroute can also occur when someone is blocking ICMP packets and/or their replies.  When traceroutes fail, they should be tested with both UDP packets and ICMP echo packets, with both failing.  Even so, direct connections (via TCP, e.g.) sometimes still work.

Note also that many admins limit or firewall drop ICMP echo packets at destination hosts.  I do drop them, except I have a list of IP addresses (v4 and v6) which may ping and receive replies (my own network ranges and some friends).  ICMP packets should never be dropped by routers, but some admins do that also (whether intentional or by misconfiguration).

And it's back working...