Thanks, feels good to not be alone. I see this kind of hardware and just shrug. But I'd really love to be the kind of person who sees the possibilities and says "wow this is super nice!" (-:
I am sure there is one as the project looks very well done and comprehensive, but I'm sorry, I don't quite understand the use case for this? Where would one use this instead of SSH or even SSH over a http proxy?
Contributor here! (Only one PR but still!) At Automattic we use GoTTY to allow customers to run subcommands of the WordPress CLI on their web container in their browser. Having them connect via SSH would have been much harder due to things like keys and routing. With GoTTY we can use our existing web-based auth and routing systems. The support burden is extremely low compared to ssh.
Web browsers are available on practically every PC but SSH clients less so (especially on older Windows, I think Windows 10 has one now but still). This seems like a great way to check in on long running tasks from wherever you are (e.g. on a mobile phone or hotel computer), and being able to disable input means you don't have to worry too much about someone finding the URL and running malicious commands.
This is perfect for integrating into a web app behind a proxy that adds authentication, SSL, etc. Put it on a small cloud instance, add your favorite text editor, install all your development CLI tools and you've got a completely productive and 100% mobile development environment for example. You could load it up on a tablet while lounging in the sun and get real work done.
I've been using it for a few months to host a few terminal based games, and for that it has worked very well. I can also imagine it being useful for quickly throwing up a status page using top or whatever other tool you want.
- A component of the main electric trim system became inoperative. Our pilots ran the appropriate checklist, which included manually trimming the aircraft. They returned to MIA and landed uneventfully. The issue was not related to MCAS.
NAT64 is useful to allow IPv4 services to work in an IPv6-only environment. It's nice to only have one stack to administrate, and IPv6 is generally more flexible, but you often need to fall back to IPv4.
NAT64 is more and more used instead of CGNAT (well, it's still CGNAT to an extent), but I don't really see one being advantageous over the other. Only that there are only IPv6 semantics when using NAT64, so stuff like roaming, privacy extensions, etc. works, and you don't have to rely on dual-stack.
I think the big advantage to NAT64 is identifying the pain points (incompatible equipment, applications, etc) in an IPv6-only world. And it really is a clear transition path to IPv6.
Thank you for your comprehensive and thoughtful answer. I agree with everything you said, except for the idea that we are transitioning, we will always live in a hybrid ipv4 ipv6 world (;
Ah, but those who live behind NAT64 are already living in an IPv6-only world ;)
Do you really think there will never be IPv6-exclusive services? I personally think it's bound to happen, if only some private websites here and there. Maybe some country will make a bit push? At this point, not having IPv6 connectivity starts being a liability.
Going forward, whether everyone adopts IPv6 or not doesn't really matter I think. Legacy equipment will carry on under IPv4, even if it is just NATed IPv6. Servers, intranets and VPN can keep on using v4 if they prefer, but servers will need to be dual-stack if they need to contact IPv6 hosts (databases, APIs, websites). NAT64 (with a dedicated IPv4) is a clean way to handle dual-stack, I wonder if it will be, or is already available in datacenters?
Thinking more about it, these semi-public API endpoints is where the transition might happen first: some services already leverage IPv6, like smart power meters. If both endpoints are controlled by the same entity, it's quite easy to make them IPv6-only, especially if public access is possible, but not a priority.
Keep in mind those are my opinions, I am not a network professional!
---
I wonder how much longer it will take for publicly available IPv6-only services to appear? 10 years? 20 years? Once they start appearing, how long will most ISPs take to deploy IPv6? 5 years? What if, say Belgium mandates its ISP to provide IPv6 connectivity? Would that boost adoption in the Netherlands?
In the end, it's easy to contact IPv4 hosts if you only have IPv6, but the opposite isn't true, because only one can encapsulate the other.
If IPv6+NAT64 starts being a viable and widely adopted option, will we have a surplus of IPv4 addresses? Will websites start to block IPv4 due to spam issues?
If enough people like me are eager to transition, we will transition somewhat... due to network effects :)
I doubt that we will always live in a hybrid world. IPv4 address space exhaustion is a growing problem and NAT is at best a partial solution. As more ISPs resort to things like NAT64 and 464XLAT the shortcomings of NAT (of whatever form) will become a larger problem and developers will start writing IPv6-only applications. After enough time IPv4 service will become optional, and shortly thereafter irrelevant.
They're different things. NAT64 is useful for bridging between ipv6 and ipv4 networks, it's just a way of encoding ipv4 addresses in ipv6 addresses. It's more straightforward than ipv4 nat because there's no port rewriting.
Avoiding dual-stack is one big reason. NAT64 is also a key component of 464XLAT, which is technically superior to NAT444 as it only requires one NAT gateway instead of two.
