Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
Networking / Open Source / Service Mesh

TAYGA: Bridge an IPv6 Network Back to IPv4 using NAT64

Use Tayga to form a bridge between an enterprise Ipv6 network to an IPv4 environment.
Sep 25th, 2020 10:46am by
Featued image for: TAYGA: Bridge an IPv6 Network Back to IPv4 using NAT64

Every network admin on the planet knows this dirty little secret: We’re running out of IPv4 addresses. This was an inevitability, given how wide-spread the network and network devices have become. Even on your LAN, you sometimes have to use subnetting, simply because you’ve found the devices on your massive enterprise network have gobbled up all the 192.68.1.x addresses.

It’s a problem.

Which is why IPv6 was developed. IPv6 offers a larger pool of addresses from which to use. The problem is that IPv6 isn’t nearly as easy to employ as IPv4. After all, is much easier to remember than 0:0:0:0:0:ffff:c0a8:101.

But what’s a network administrator to do? Migrate all of those servers and various hardware devices from IPv4 to IPv6? In theory, yes, that is exactly what should happen. However, that’s not nearly as easy as one would like to think it would be. After all, you might have hundreds upon hundreds of devices and numerous locations. On top of which, there’s always that pesky DNS that must be updated (which could equate to downtime).

Oh, and let’s not forget that IPv6 is not backward compatible with IPv4. Why was this decision made? Who knows, but it has caused a lot of admins to avoid deploying IPv6. Why? They already have enough on their plates. To add that insult to that particular injury could do serious damage to their productivity and, well, sanity.

What’s a network admin to do?

NAT64 could be the solution for those woes.

What Is NAT64?

To put it simply, NAT64 is considered a transition tool for IPv4 and IPv6 network addressing. Just like Network Address Translation (NAT) can translate WAN to LAN addresses, NAT64 can translate IPv6 to IPv4 addresses. Or, more to the point, NAT64 facilitates the communication between IPv6 and IPv6 hosts through an IPv4 network, by way of NAT.

To make this happen, a device using IPv6 embeds an IPv4 address into a packet, using the host portion of the IPv6 network segment. In the end, it creates an IPv4-embedded IPv6 address. This embedding happens within a 32-bit address space of the IPv6 address.

With this in place you could have a server that is reachable by both WAN and LAN. Say you have desktop machines in your company that all use IPv6, but your servers are using IPv4. Between those desktops and servers, you would have a gateway running a NAT64 translator that would make it possible for those IPv6 addresses to be translated to IPv4 addresses that could then be seen by the server.

The one problem with this is that the translation is not symmetrical. Why? Because there are far more addresses to be had with IPv6 than IPv4. Because of that, one-to-one address mapping isn’t possible. To get around that (or adjust for that), the NAT64 gateway uses a special algorithm for stateless mapping or can do manual translations for stateful mapping.

It should also be noted that NAT64 was designed to translate from IPv6 to IPv4, not the other way around.

Now that you have a rudimentary understanding of NAT64, let’s take a look at one way to get it working.

I’ll be demonstrating on Ubuntu Server 18.04, using TAYGA, an open-source solution for NAT64.

Install TAYGA

The first thing we need to do is install a couple of dependencies. Log into your Ubuntu server and issue the command:

sudo apt-get install build-essential bind9 -y

Once that installation completes, we need to modify the sysctl.conf configuration file. Open that file with the command:

sudo nano /etc/sysctl.conf

At the bottom of that file, add the following two lines:

Save and close the file. Reload the file with the command:

sudo sysctl -p

With the dependencies out of the way, let’s download and install TAYGA. Download the source with the command:


Uncompress the file with the command:

bzip2 -dk tayga-0.9.2.tar.bz2

Unpack the file with the command:

tar xvf tayga-0.9.2.tar

Change into the newly-created directory with the command:

cd tayga-0.9.2

Run the configuration command with:


Compile the source with the command:


Finally, install TAYGA with the command:

sudo make install

Final Configurations

Now that TAYGA is installed, there are a few more configurations to make. Be aware, you must modify the configurations you see below to match your network topography. Do not use the exact configurations shown below (as they probably won’t work on your network). Because of that, these are just suggestions.

NOTE: You might also have to make adjustments on your router for this to work. What adjustments you do (and how you do them) will depend on the router you are using.

First, copy the sample TAYGA configuration file with the command:

sudo cp /usr/local/etc/tayga.conf.example /usr/local/etc/tayga.conf

Now open the new configuration file with the command:

sudo nano /usr/local/etc/tayga.conf

In that file, locate the line:

Change that line to the tunneled IPv4 address you’ll use for the TAYGA server. This is not the router’s address.

Next, look for the line:

Replace the above IPv6 prefix address with one that is unused on your network. Make sure this address is globally routable.

Look for the line:

Change the above line to match the IPv4 address range on your network.

Save and close the file.


With the configuration out of the way, it’s time to start TAYGA. From the terminal window, issue the following commands:

sudo tayga --mktun

sudo ip link set nat64 up

sudo ip route add 2002:c0a8:01fe::c0a8:01fe dev nat64 (REPLACE IPV6 ADDRESS WITH YOUR ROUTER'S ADDRESS)

sudo ip route add dev nat64 (REPLACE IPv4 ADDRESS WITH YOUR ROUTER'S ADDRESS)

sudo route add 2002:c0a8:01a7::/96 dev nat64 (THIS THE PREFIX LINE FROM THE TAYGA CONFIGURATION FILE)


You might also want to firewall your NAT64 prefix from outside access. Do this with the commands (modifying the addresses to match your network scheme):

Finally, start TAYGA with the command:

sudo tayga

All messages will be logged to /var/log/syslog. If you find things aren’t working properly, make sure to check the logs. If syslog doesn’t help you, you can run TAYGA in foreground mode (so all output is sent to the terminal window in real time) with the command:

sudo tayga -d

And that’s the gist of using TAYGA for NAT64. It’s certainly not the easiest solution, but if you need a bit of help transitioning from IPv4 to IPv6, this might be just the tool you need.

Feature image by Manfred Antranias Zimmer from Pixabay.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.