The last one seems to be really interesting - it's a kernel module, should be fast and so on.

@mickvav @dmbaturin @EwaldvanGeffen
should we write to that jool tool developers?
It's looks pretty nice

I've just tested TAYGA installed on VyoS 1.2 (Beta) and it seems to work fine even though there is no configuration for it in VyOS.

I just followed the instructions to add Jessie distribution to VyOS install and then said "apt-get update" and then "apt-get install tayga" and it installed it.

Then I configured /etc/tayga/default.conf and then started it with "systemctl enable tayga" and "systemctl start "tayga" and tested it out and it seemed to work fine.

Well, I think I can some day do some things on adding this to CLI, if someone points me to known-working config for this feature. Am I right that this IPv4 - IPv6 NAT can not be implemented by iptables/ip6tables stuff? If netfilter already can do it - it's much better to do this things in kernel (as netflow, in my opinion).

@dsummers jool seems to be kernel-level and tayga seems to be userspace-level. The first one should be faster, and I expect package loss in the second one on high packet rate.

I've been running Tayga on a debian box for the last year or so and have not noticed any performance problems, but I haven't compared Tayga with Jool.

In my previous comment I was just commenting that Tayga was working fine *now* with VyOS 1.2 (Beta) rather than having to wait for some other implementation.

I've got a couple of uses for it that I could use right now so was trying to come up with something quick.

I suspect they both have the same functionality, as long as Jool is stateless and can do both dynamic and static mappings.

As long as they both have same functionality I don't care which is chosen for VyOS, but Tayga seemed a faster way to get there for now.

The last nine months or so I've been running Tayga on VyOS Beta 1.2 (latest versions) in my production network.

This enabled me to go from three separate routers (debian (for NAT64), VyOS, PfSense) down to two separate routers (VyOS, PfSense).

Step 1: Follow the Wiki instructions on how to update/install packages on VyOS Beta 1.2.

Step 2: apt-get install tayga

Step 3: Edit the /etc/default/tayga and change to RUN="yes".

Step 4: Use the following /etc/tayga.conf file (modified for your own network):

#
# Sample configuration file for TAYGA 0.9.2
#
# Modify this to use your own addresses!!
#

#
# TUN device that TAYGA will use to exchange IPv4 and IPv6 packets with the
# kernel.  You may use any name you like, but `nat64' is recommended.
#
# This device may be created before starting the tayga daemon by running
# `tayga --mktun`.  This allows routing and firewall rules to be set up prior
# to commencement of packet translation.
#
# Mandatory.
#
tun-device nat64
#
# TAYGA's IPv4 address.  This is NOT your router's IPv4 address!  TAYGA
# requires its own address because it acts as an IPv4 and IPv6 router, and
# needs to be able to send ICMP messages.  TAYGA will also respond to ICMP
# echo requests (ping) at this address.
#
# This address can safely be located inside the dynamic-pool prefix.
#
# Mandatory.
#
ipv4-addr 10.X.Y.1

#
# TAYGA's IPv6 address.  This is NOT your router's IPv6 address!  TAYGA
# requires its own address because it acts as an IPv4 and IPv6 router, and
# needs to be able to send ICMP messages.  TAYGA will also respond to ICMP
# echo requests (ping6) at this address.
#
# You can leave ipv6-addr unspecified and TAYGA will construct its IPv6
# address using ipv4-addr and the NAT64 prefix.
#
# Optional if the NAT64 prefix is specified, otherwise mandatory.  It is also
# mandatory if the NAT64 prefix is 64:ff9b::/96 and ipv4-addr is a private
# (RFC1918) address.
# 
#ipv6-addr 2001:XXX:YYYY:6:ffff::2

#
# The NAT64 prefix.  The IPv4 address space is mapped into the IPv6 address
# space by prepending this prefix to the IPv4 address.  Using a /96 prefix is
# recommended in most situations, but all lengths specified in RFC 6052 are
# supported.
#
# This must be a prefix selected from your organization's IPv6 address space
# or the Well-Known Prefix 64:ff9b::/96.  Note that using the Well-Known
# Prefix will prohibit IPv6 hosts from contacting IPv4 hosts that have private
# (RFC1918) addresses, per RFC 6052.
# The NAT64 prefix need not be specified if all required address mappings are
# listed in `map' directives.  (See below.)
#
# Optional.
#
prefix 2001:XXX:YYYY:64::/96
# prefix 64:ff9b::/96

#
# Dynamic pool prefix.  IPv6 hosts which send traffic through TAYGA (and do
# not correspond to a static map or an IPv4-translatable address in the NAT64
# prefix) will be assigned an IPv4 address from the dynamic pool.  Dynamic
# maps are valid for 124 minutes after the last matching packet is seen.
#
# If no unassigned addresses remain in the dynamic pool (or no dynamic pool is
# configured), packets from unknown IPv6 hosts will be rejected with an ICMP
# unreachable error.
#
# Optional.
#
dynamic-pool 10.X.Y.0/24

#
# Persistent data storage directory.  The dynamic.map file, which saves the
# dynamic maps that are created from dynamic-pool, is stored in this 
# directory.  Omit if you do not need these maps to be persistent between
# instances of TAYGA.
#
# Optional.
#
data-dir /var/spool/tayga

#
# Establishes a single-host map.  If an IPv6 host should be consistently
# reachable at a specific IPv4 address, the mapping can be specified in a
# `map' directive.  (IPv6 hosts numbered with an IPv4-translatable address do
# not need map directives.)
#
# IPv4 addresses specified in the `map' directive can safely be located inside
# the dynamic-pool prefix.
#
# Optional.
#

# map 10.X.Y.3 2001:XXX:YYYY::3

Step 5: mkdir /var/spool/tayga

Step 6: systemctl enable tayga

Step 7: systemctl start tayga

Step 8: Test by pinging a IPv6 mapped IPv4 address

ping6 2001:XXX:YYYY:64::8.8.8.8

Wiki instructions for system package settings now seem to be gone.

Probably because system package settings are no longer supported.

Edit /etc/apt/sources.list file contents to contain:
deb http://httpredir.debian.org/debian jessie main contrib non-free # jessie #

Then:
apt-get update
apt-get install tayga

If you want have a better NAT64 solution take a look to jool. (http://jool.mx/en/index.html).

jool 4.0.0 has been released.
http://jool.mx/en/index.html

jool 4.0 added "JOOL" as iptables target.
Does not it make sense to vyos?
For example, i think iptables configuration script can be diverted.

To be fair, the things we're need to make this work is

1. Debianize Jool along with the kernel module as a dkms package
2. Implement the configuration either in Perl or the newer Python
3. Operational commands to display the status of NAT64

@TriJetScud please see :

https://github.com/NICMx/Jool/issues/243

for 1.

I'm thinking about trying to run either tayga or jool as a docker container inside of VyOS. Has anyone tried something like this? If I wrote a guide on how to do this I wonder if it would be an OK temporary solution until it's integrated into VyOS.

Isn't anyone implementing this feature right now?

@jack9603301 I tried building jool into the VyOS image but because their deb packages uses DKMS which is not compatible with VyOS so somebody has to create a VyOS specific deb package.

Jool can handle 2 times as many packets.
https://link.springer.com/article/10.1007/s11235-020-00681-x

@dmbaturin @artooro Come on, remember not to forget NAT46

They are a pair

Regarding the command line, I recommend the following:

set nat64
set nat46

Because I have completed the implementation of NAT66, the command line is as follows:

set nat66

Although it cannot be merged into the main line for the time being

I would suggest going with tayga if this feature is planned to be implemented.

I tried jool in my testing environment.
Jool is feature-rich and very performant, however it is tricky to get the firewall setup correct because jool itself is a kernel module that extends the netfilter subsystem.
When jool is enabled, normal firewall filtering on INPUT and FORWARD is skipped. So NAT64 traffic will always be permitted.
In order to get NAT64 traffic going to the firewall, you have to run jool in a separate network namespace and filter on the interfaces that connects the network namespaces.
This will add a lot of complexity to VyOS to maintain and such a complicated iptables/nftables configuration and such an out-of-tree kernel module.

However for tayga, things will be much more easier. Tayga just adds a new tap interface to the host network stack. We can reuse the existing VyOS firewall commands to filter traffic on that interface.

I've been running TAYGA inside VyOS with absolutely no problems for the last several years.

In my own builds, I just added the "tayga" package so that it would automatically be there without having to add it manually each time I upgrade.

JOOL looks nice but is a much bigger effort to integrate.

TAYGA could be integrated NOW.

Please consider adding TAYGA now and then if someone can take the time to integrate JOOL then that is fine as well, as long as it has the same capabilities as TAYGA.

Prototype PR using Tayga: https://github.com/vyos/vyos-1x/pull/1408

While i like the inclusion of NAT64 inside vyos (And the effort vfreex has made), i believe that tayga is not the way to go, it was last updated on 2010-12-12 according to the readme in it. Jool on the other hand has a bigger throughput being kernel module. The only issue i believe is the module compilation cause configuration is quite easy.

@aaliddell I am not too concerned about tayga's maintenance. It have been proved to work well for years, and the package is already a part of the official repository of debian. Actually debian's tayga package includes a few patches: https://salsa.debian.org/debian/tayga/-/tree/debian/master/debian/patches

The only downside of tayga is its performance. I would like to see Jool to be included in VyOS however that will be a muck bigger effort to integrate. At least kernel module integration and firewall filtering for jool is complex. Let me know if you have more insights more about Jool.

Just adding here that Jool.mx is no longer maintained.

"The project’s development has slowed down to essential maintenance. Bugfixing and support will remain active, but there will be no new features in the foreseeable future." - Source: https://nicmx.github.io/Jool/en/index.html

However latest release has been on Mar 21, 2022.

It sounds like people prefer jool, and in my personal opinion, if there is a package that is still active up to now, like jool, then jool is probably better. But whatever it is, it's foreign to me

Jool is still being maintained for bugfixes etc. and it has all the features we're looking for, then it sounds fairly ideal. If no new features are being added to it, it's less likely to break in future releases too

Jool package was added to the vyos-build repo in https://github.com/vyos/vyos-build/commit/d9f711f500ea21288a50f54640dff833cd1da153

Great, maybe we can use jool to build it!

In T160#147889, @frebib wrote:

Jool package was added to the vyos-build repo in https://github.com/vyos/vyos-build/commit/d9f711f500ea21288a50f54640dff833cd1da153

I started working on a jool nat64 implementation at https://github.com/vyos/vyos-1x/pull/1993 for anyone that would like to try it out. Not everything is implemented yet, but I have been running this for the past few weeks with no issues. Any comments or feedback on the UX would be appreciated