For many purposes, it is been a while since I wanted to have a NAT64 gateway inside my LAN. Sadly, at the time of this writing, my home router does not propose that kind of service. So why not trying to run it on a Raspberry Pi ?
NAT64 gateway is mainly used to reach IPv4 network from IPv6 network. There are many possible applications, such as opening an IPv6 access to a server farm that was only designed to operate through IPv4, or giving an access to IPv4 Internet for hosts only having an IPv6 configuration.
This article describes how to configure a Raspberry Pi as a working NAT64 gateway with the help of the Tayga software.
Table of contents
- Table of contents
- Tayga addressing scheme
Disclaimer 1: If you are not using a Debian Linux (or Raspbian) nor installing Tayga through aptitude software, I could not guarantee that you will match the same conditions that I have encountered.
Disclaimer 2: This article only focus on NAT64 and Tayga. Topics as DNS64, Router Advertisement, or firewall are voluntary avoided and would be explored through future articles.
Hardware and software used
- Router: Mikrotik hEX S model RB760iGS with firmware 6.47.1.
- Switch: unmanaged NETGEAR GS108 switch
- Raspberry Pi: model 4B with 4 gigabytes of ram, a quad-core CPU, and with Raspbian 10.4.
- NAT64 software: Tayga 0.9.2-8
Here is a simplified representation of the LAN used. This is a really common dual stack LAN that could be found at any home. The default gateway is the router for both IPv4 and IPv6. Everything has access to Internet through IPv4 and IPV6. The router provide an Internet access through a NAT44 gateway because the Internet service provider provides only a single IPv4 address. Every hosts have a public IPv6 address because the Internet service provider provides a /64 IPv6 prefix.
The Raspberry Pi is not directly connected to the router simply because there are only two interfaces on this router model. It would have been more practical to have it directly attached to the router but a router with more than 2 interfaces is pretty expensive for a home usage.
What does the software Tayga ?
This software has one major purpose: converting incoming packet from IPv6 to IPv4 or from IPv4 to IPv6.
To achieve this goals, Tayga uses a Linux kernel feature called TUN devices. The principle of a TUN device is to link a Virtual Network Interface (VNI) to a file descriptor. On the file descriptor side, an application can make raw communication with the network world. And on the VNI side, the kernel can exchange packets between the VNI and the other network interfaces.
For the understanding of the rest of this article, it is important to realize that a TUN device has two ends:
- The VNI that appears on the interface list and is used by the kernel to exchange data between Tayga and the other network interfaces
- The file descriptor that is used by Tayga to exchange data with the kernel
From a Kernel point of view, a TUN device could be represented like this:
In terms of OSI model, Tayga interacts with two layers: the network layer and the transport layer.
At the network layer, Tayga only manages IPv4 and IPv6 protocols, if something manages to send another network protocol inside the VNI, it is dropped. (see function read_from_tun in file tayga.c)
At the transport layer, Tayga manages ICMPv4 if network layer is IPv4, ICMPv6 if network layer is IPv6, TCP with both network layers, and UDP with both network layers too. If the payload is something else, it is just copied from IPv4 to IPv6 payload or from IPv6 to IPv4 payload. (see functions xlate_payload_6to4 or xlate_payload_4to6 in file nat64.c)
Tayga addressing scheme
To operate properly, Tayga needs four things: an IPv6 prefix, an IPv4 pool, an IPv6 address and an IPv4 address.
The IPv4 pool
This pool is used to map IPv6 source addresses from the LAN to IPv4 addresses. It is better to pick a different subnet than any subnet used in the LAN. And the pool must be big enough to be mapped to every host in the LAN.
The default configuration of the Debian package comes with the following pre defined pool:
This subnet is different than any subnet used in the LAN and allow 254 mapping, that is more than enough, so let’s use it!
The IPv4 address
For control purpose, and more precisely error management, Tayga must be able to send ICMPv4 packet. To do so, it needs an IPv4 source address. The default configuration coming with the Debian package suggests the use of the address
192.168.255.1. Even if this address is included in the IPv4 pool, it is allowed to use it. This address will be removed from the pool and won’t be used for any translation. The pool size has now a length of 253, still more than enough.
The IPv6 prefix
The IPv6 prefix is the most interesting part because it embeds the IPv4 destination address to translate. And Tayga needs to know from which prefix it has to extract IPv4 addresses.
Because an IPv4 address is 32-bit long, the IPv6 prefix can not be bigger than 96 bits. (an IPv6 address of 128 bits minus an IPv4 address of 32 bits is equal to 96 bits) Tayga follows the rules defined by RFC 6052, the prefix must have one of the following sizes: 32, 40, 48, 56, 64 or 96 bits.
The RFC 6052 also proposes an IPv6 prefix reserved for embedded IPv4 and NAT64 gateway:
It is called the Well-Known Prefix. Even if it is not mandatory to use it, why not taking that one.
The RFC 6052 comes with a set of rules and good practices that justify some of the implementation choices of Tayga. This is not the purpose of this article to talk about it, but that RFC remains an interesting reading.
The IPv6 address
The reason why Tayga needs an IPv6 address is the same as for the IPv4 address. It needs an IPv6 source address to send ICMPv6 packet in case of issue. But this address is more complicated to determine because of all the rules it has. It can not be an address from the prefix
64:ff9b::/96, not a link local address, not a multicast address, not an address from the prefix
I am adding one more rule! I do not want it to be a Global Unicast Address (GUA). The reason is quite simple, the NAT44 gateway to reach Internet is managed by the router and not by Tayga. Because of that, Tayga never exchanges directly with hosts out of the LAN. It only exchanges data with LAN hosts or with the router. So there is no need to set an IPv6 that could be forwarded on Internet.
What’s left ? Unique Local Address (ULA). It is not against the rules and it is not a Global Unicast Address.
The IPv6 address of Tayga will be
Simplified use case
With all these settings defined, here is a simplified use case of how things should occur.
A packet arrives at the VNI interface with the IPv6 source address
2001:DB8::100 and the IPv6 destination address
64:ff9b::0808:0808. Tayga translates the source address to the IPv4 address
192.168.255.2 and the destination address to the IPv4 address
126.96.36.199. The payload remains mostly unchanged.
192.168.255.2 is randomly picked. Let’s say it is the first available address in the IPv4 pool.
During the process, Tayga also maps the address
2001:DB8::100 during at least 2 hours. So if any IPv4 packet comes back, it will be sent to the correct IPv6 destination.
And the destination IPv4 address
188.8.131.52 is extracted from the IPv6 address
64:ff9b::0808:0808. Even if is not obvious, the last 32 bits of the IPv6 address
0808:0808 are the IPv4 address. Groups of 4 hexadecimal characters are used to represent an IPv6 address while the Dot Decimal Notation is used to represent an IPv4 address, this is why it does not look exactly the same, but it is the same value.
The next section describe a more complete and detailed use case.
The test case scenario consists of sending an ICMPv6 request (ping) to Google DNS (
184.108.40.206) through the NAT64 gateway and then receiving the ICMPv6 reply. The corresponding IPv6 address of the IPv4
220.127.116.11 embedded into the Well-Known IPv6 prefix is
Part 1: the ICMP request
The first part of the scenario is the ICMPv6 request being sent from a random host inside the LAN, then being converted into an ICMPv4 request, and finally being sent to Internet.
The host sends an ICMPv6 request to the router and not the Raspberry Pi because the only routing rule known by a host is the default route. That means sending every traffic not “on link” to the default gateway. Then the router sends the frame containing the ICMPv6 request to the Raspberry Pi. The Raspberry Pi converts the ICMPv6 request into an ICMPv4 request and sends it to the router. And finally the router sends the ICMPv4 request on Internet.
The router also sends an ICMPv6 redirect (type 137) telling the host it was not the best routing decision to send this ICMPv6 request to the router, it should send it directly to the Raspberry Pi. With that information, the host will send future ICMPv6 request directly to the Raspberry Pi.
The following table describes MAC addresses, IP addresses and payload used at each step:
|Step||MAC src||MAC dest||IP version||IP src||IP dest||Payload|
|1||01-00-5E-00-00-64||01-00-5E-00-00-01||6||2001:db8::100||64:ff9b::808:808||ICMP6, echo request|
|2||01-00-5E-00-00-64||01-00-5E-00-00-02||6||2001:db8::100||64:ff9b::808:808||ICMP6, echo request|
|3||01-00-5E-00-00-02||01-00-5E-00-00-01||4||192.168.255.219||18.104.22.168||ICMP echo request|
|4||….||…||4||203.0.113.1||22.214.171.124||ICMP echo request|
Part 2: the ICMP reply
The second part of the scenario is an ICMPv4 reply coming back from Internet, being converted into an ICMPv6 reply, and being sent back to the specific host that was at the origin of the ICMPv6 request.
The reply path is a little bit simpler than the request path for two reasons:
- The router knows a route to the IPv4 range used by the NAT64 via the Raspberry Pi
- The Raspberry Pi replies the ICMPv6 reply to an IPv6 “on link” address and sends it directly to the host on the LAN
The following table describes MAC addresses, IP addresses and payload used at each step:
|Step||MAC src||MAC dest||IP version||IP src||IP dest||Payload|
|1||…||…||4||126.96.36.199||203.0.113.1||ICMP echo reply|
|2||01-00-5E-00-00-01||01-00-5E-00-00-02||4||188.8.131.52||192.168.255.219||ICMP echo reply|
|3||01-00-5E-00-00-02||01-00-5E-00-00-64||6||64:ff9b::808:808||2001:db8::100||ICMP6 echo reply|
With all these informations in mind, the configuration is pretty straightforward.
On the Raspberry Pi
Step 1: installing Tayga
Install Tayga through Aptitude packet manager.
pi@raspberrypi:~$ sudo apt install tayga Reading package lists... Done ... Setting up tayga (0.9.2-8) ... pi@raspberrypi:~$
Step 2: configuring Tayga, application side (file
The configuration file of Tayga is located at
tun-device nat64 ipv4-addr 192.168.255.1 ipv6-addr 2001:db8::2 prefix ::/96 dynamic-pool 192.168.255.0/24 data-dir /var/spool/tayga
Almost all of these settings are discussed in the Tayga Addressing Scheme section:
tun-device is the VNI interface created and used by Tayga. Except if you know what you are doing and want to do some experimentation, the best is to keep the value
nat64. There is no need to manually create this interface, scripts provided with the Debian package do it for you.
data-dir is a path to a directory where Tayga keeps track of dynamic mappings. So in case of a reload of Tayga or if the Raspberry Pi restarts, informations about existing mapping are resilient.
Step 3: configuring Tayga, VNI side (file
Another configuration file that needs to be updated is
/etc/default/tayga, this is not an official Tayga configuration file, but an extra configuration file added by the packaging team. This file is used by the script
/etc/init.d/tayga mainly to set the VNI side. To be precise, this is the configuration of the Linux side of the TUN device, Tayga does not read nor use that file at all. (see section explaining how Tayga works)
Here is the content of this file:
CONFIGURE_IFACE="yes" CONFIGURE_NAT44="no" IPV4_TUN_ADDR="" IPV6_TUN_ADDR="" DAEMON_OPTS=""
CONFIGURE_IFACE must be kept to
yes. It instructs scripts to create and set up the VNI interface defined in Tayga configuration file, see
tun-device parameter. If this setting was set to
no, it would have need to be done manually.
CONFIGURE_NAT44 must be set to
no. The authors of this script have though the service would have been use on a computer with an interface directly connected to IPv4 Internet. With this setting set to
yes, these scripts automatically attempt to create a NAT44 rule in iptable. But with the current situation, the NAT44 function is assumed by the router and is not needed on the Raspberry Py.
The three last settings,
IPV4_TUN_ADDR, are not used with the current design and must stay empty.
DAEMON_OPTS allows to pass extra argument to the Tayga binary when it starts as a daemon process. Right now, only the
--pidfile argument is used but there are others. For example, it is possible to increase process isolation with arguments like
--chroot. See Tayga manpage for more details.
IPV4_TUN_ADDR are respectively used to assign an IPv6 address and an IPv4 address to the VNI interface. The NAT64 gateway works without them, but for more advanced and persistent configuration it is nice to have a way to assign addresses to the VNI.
Step 4: enabling ip forwarding
To allow IP packet to be exchanged between the VNI interface and the physical interface of the Raspberry Pi, forwarding must be enabled inside the Linux kernel.
Add or uncomment the following lines inside the file
net.ipv4.ip_forward = 1 net.ipv6.conf.all.forwarding = 1
And then apply the change to the kernel with the following command:
pi@raspberrypi:~ $ sudo sysctl -p net.ipv4.ip_forward = 1 net.ipv6.conf.all.forwarding = 1 pi@raspberrypi:~ $
Step 4: starting Tayga
Tayga is now ready to be started!
pi@raspberrypi:~$ sudo systemctl start tayga.service pi@raspberrypi:~$
Step 5: enabling Tayga
To be sure Tayga starts in case of the Raspberry Pi reboot, it needs to be enabled through systemd with the following command:
pi@raspberrypi:~$ sudo systemctl enable tayga.service tayga.service is not a native service, redirecting to systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable tayga pi@raspberrypi:~$
The command output may look strange. This is because Tayga was designed to work with initd and not systemd. But it does not change anything in the end.
On the router
A few routing rules need to be added on the router. These are really simple rules that could be adapted for any other router brand.
Step 1: Adding a route to the IPv4 pool
[admin@MikroTik] > /ip route add dst-address=192.168.255.0/24 gateway=192.168.1.2 [admin@MikroTik] >
192.168.255.0/24 the IPv4 pool used by Tayga to convert IPv6 to IPv4. And
192.168.1.2 the IPv4 LAN address of the physical interface of the Raspberry Pi.
Step 2: Adding a route to the IPv6 prefix
[admin@MikroTik] > /ipv6 route add dst-address=64:ff9b::/96 gateway=fe80::2%bridge [admin@MikroTik] >
64:ff9b::/96 the IPv6 prefix used to carry embedded IPv4 addresses. And
fe80::2%bridge the link local address of the physical interface of the Raspberry Pi. It is needed to specify the outgoing interface
bridge because of the use of a link local address and also because the Raspberry Pi is reachable through the
bridge interface of the router .
No route to fdaa:bb:1::1
I choose not to add a route to
fdaa:bb:1::1 inside this infrastructure, so it is not possible to reach Tayga directly through its IPv6 address. I did that for two reason:
- It reduces the configuration complexity, less to configure means a reduced risk of issue.
- It does not provide any more feature to have it, common operation does not need to reach Tayga through its IPv6.
Even if it breaks a part of the end-to-end principle, I assume that choice.
For this test, traffic is captured at two points on the network: on the Raspberry Pi on the eth0 interface, and on the test computer on the eth0 interface.
Then from the test computer, an ICMPv6 request is sent with the
user@computer:~ $ ping -6 -c 1 64:ff9b::184.108.40.206 PING 64:ff9b::220.127.116.11(64:ff9b::808:808) 56 data bytes 64 bytes from 64:ff9b::808:808: icmp_seq=1 ttl=114 time=26.3 ms --- 64:ff9b::18.104.22.168 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 26.288/26.288/26.288/0.000 ms user@computer:~ $
On the Raspberry Pi at the interface eth0
pi@raspberrypi:~ $ sudo tcpdump -teni eth0 icmp or icmp6 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 01:00:5e:00:00:64 > 01:00:5e:00:00:02, ethertype IPv6 (0x86dd), length 118: 2001:db8::100 > 64:ff9b::808:808: ICMP6, echo request, seq 1, length 64 01:00:5e:00:00:02 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 98: 192.168.255.219 > 22.214.171.124: ICMP echo request, id 2, seq 1, length 64 01:00:5e:00:00:01 > 01:00:5e:00:00:02, ethertype IPv4 (0x0800), length 98: 126.96.36.199 > 192.168.255.219: ICMP echo reply, id 2, seq 1, length 64 01:00:5e:00:00:02 > 01:00:5e:00:00:64, ethertype IPv6 (0x86dd), length 118: 64:ff9b::808:808 > 2001:db8::100: ICMP6, echo reply, seq 1, length 64 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel pi@raspberrypi:~ $
The information captured on the
eth0 interface are really similar to the information that could have been captured on the
nat64 interface of the Raspberry Pi. The main advantage to make the capture on the
eth0 interface is to get the MAC addresses used on the LAN.
On the test computer at the interface eth0
user@computer:~$ sudo tcpdump -teni eth0 icmp or icmp6 [sudo] password for djo: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes 01:00:5e:00:00:64 > 01:00:5e:00:00:01, ethertype IPv6 (0x86dd), length 118: 2001:db8::100 > 64:ff9b::808:808: ICMP6, echo request, seq 1, length 64 01:00:5e:00:00:01 > 01:00:5e:00:00:64, ethertype IPv6 (0x86dd), length 214: fe80::1 > 2001:db8::100: ICMP6, redirect, 64:ff9b::808:808 to fe80::2, length 160 01:00:5e:00:00:02 > 01:00:5e:00:00:64, ethertype IPv6 (0x86dd), length 118: 64:ff9b::808:808 > 2001:db8::100: ICMP6, echo reply, seq 1, length 64 ^C 3 packets captured 3 packets received by filter 0 packets dropped by kernel user@computer:~$
On the test computer, only two packets could have been expected: ICMPv6 echo and ICMPv6 reply. But because of the topology used, a third packet is captured, the ICMPv6 redirect. (See the scenario section)
My Internet connexion is not really fast comparing to modern technologies. This is a good old ADSL2+ connexion with a downlink of 16Mb/s (2000KB/s) and an uplink of 1Mb/s (125KB/s). The limit of Tayga won’t be reached with that. The goal here is to check if there is any loose of bandwidth while using the NAT64 gateway. The tool iperf3 was run three times for each combination, the average values are presented in the following table:
The difference between each situation is marginal, so I can tell without hesitation that using the gateway has absolutely no impact on the bandwidth.
I simply use the
ping command for these tests and 200 ICMP request/reply has been sent for each three cases.
As for bandwidth, there is no significant loose of delay while using NAT64 gateway.
Raspberry Pi CPU load while testing bandwidth
It is also interesting to monitor the Raspberry Pi CPU while doing bandwidth tests. Remember that Tayga is a software, meaning its limits are the CPU and the RAM of the computer where it runs.
The ram consumption is really limited and that is why only the CPU is represented here.
The huge CPU activity difference between receiving and emitting is just caused by difference of bandwidth. Receiving is almost at 1400KB/s while emitting is around 92KB/s. Tayga works way more while receiving.
The percentages presented are just for a single core of the Raspberry Pi CPU. The three other core of the CPU are not used at all by Tayga.
More performance test ?
More performance test could be done to discover where the limit of the gateway is. A more powerful Internet access is required and I don’t have one right now. It could also have been possible to exchange data between two hosts on the LAN through the NAT64 gateway, but that would required to tamper settings at different places.
The gateway clearly operate at ease with my actual Internet connexion, it is all I wanted to know.
The bottleneck is more than likely the CPU. By looking at its usage at 1400KB/s (around 10% of CPU usage), the bandwidth limit of Tayga should be around 14MB/s with that kind of hardware.
Because this kind of deployment could came with issues, here is a few debug methods.
Checking the service status
Once the service has been started, the status should be active (running), it can be checked with the following command:
pi@raspberrypi:~ $ sudo systemctl status tayga.service ● tayga.service - LSB: userspace NAT64 Loaded: loaded (/etc/init.d/tayga; generated) Active: active (running) since Mon 2020-08-17 09:42:38 BST; 1 weeks 5 days ago Docs: man:systemd-sysv-generator(8) Tasks: 1 (limit: 4915) CGroup: /system.slice/tayga.service └─30744 /usr/sbin/tayga --pidfile /var/run/tayga.pid pi@raspberrypi:~ $
If there is any error or strange ouput while retrieving the status, the next step is to check the service log.
Checking the service log
The log file can be checked at any time with the following command, even if there is no issue:
pi@raspberrypi:~ $ journalctl -xe -u tayga.service -- Subject: A start job for unit tayga.service has begun execution -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- A start job for unit tayga.service has begun execution. -- -- The job identifier is 12061. Aug 29 11:28:11 raspberrypi4 tayga: Created persistent tun device nat64 Aug 29 11:28:11 raspberrypi4 tayga: starting TAYGA 0.9.2 Aug 29 11:28:11 raspberrypi4 tayga: Using tun device nat64 with MTU 1500 Aug 29 11:28:11 raspberrypi4 tayga: TAYGA's IPv4 address: 192.168.255.1 Aug 29 11:28:11 raspberrypi4 tayga: TAYGA's IPv6 address: fdaa:bb:1::1 Aug 29 11:28:11 raspberrypi4 tayga: NAT64 prefix: 64:ff9b::/96 Aug 29 11:28:11 raspberrypi4 tayga: Note: traffic between IPv6 hosts and private IPv4 addresses (i.e. to/from 64:ff9b::10.0.0.0/104, 64:ff9b::192.168.0.0/112, etc) will be dropped. Use a translation prefix within your organization's IPv6 address space instead of 64:ff9b::/96 if you need your IPv6 hosts to communicate with private IPv4 addresses. Aug 29 11:28:11 raspberrypi4 tayga: Dynamic pool: 192.168.255.0/24 Aug 29 11:28:13 raspberrypi4 tayga: Starting userspace NAT64: tayga. Aug 29 11:28:13 raspberrypi4 systemd: Started LSB: userspace NAT64. -- Subject: A start job for unit tayga.service has finished successfully -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- A start job for unit tayga.service has finished successfully. -- -- The job identifier is 12061. pi@raspberrypi:~ $
The output presented here is the output of a normal and working situation. If any troubles were happening, the output would have been slightly different.
Any unwanted NAT44 rule on the Raspberry Pi ?
With the configuration set, no NAT44 should have been created, it is possible to confirm that with the following command:
pi@raspberrypi:~ $ sudo iptables -t nat -L POSTROUTING Chain POSTROUTING (policy ACCEPT) target prot opt source destination pi@raspberrypi:~ $
There is no NAT44 rule in the previous output, but if the output retrieved would have look like the following, an unwanted NAT44 has been created.
pi@raspberrypi:~ $ sudo iptables -t nat -L POSTROUTING Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 192.168.255.0/24 anywhere pi@raspberrypi:~ $
Check the configuration part to be sure to have disabled the NAT44 rule creation. It is also possible to remove it with the following command:
pi@raspberrypi:~ $ sudo iptables -t nat -D POSTROUTING 1 pi@raspberrypi:~ $
Be careful with the last argument of the command, it is the index of the rule to remove in the list, if there are more rules in the list, this index could need to be updated to remove the unwanted nat44 rule.
Does Tayga answer to ICMP request ?
A basic test in network science to determine if a host is operating normally is to send it an ICMP/ICMPv6 echo request. Even if Tayga is more a service than a host, it is design to answer to echo requests.
Ping its IPv4 address
Tayga has the IPv4 address
192.168.255.1 assigned in its configuration and there is a route to reach that subnet, so it should answer to it.
user@computer:~$ ping -c 4 192.168.255.1 PING 192.168.255.1 (192.168.255.1) 56(84) bytes of data. 64 bytes from 192.168.255.1: icmp_seq=1 ttl=63 time=16.1 ms From 192.168.1.1 icmp_seq=2 Redirect Host(New nexthop: 188.8.131.52) 64 bytes from 192.168.255.1: icmp_seq=2 ttl=63 time=2.88 ms 64 bytes from 192.168.255.1: icmp_seq=3 ttl=63 time=37.6 ms --- 192.168.255.1 ping statistics --- 3 packets transmitted, 3 received, +1 errors, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 2.880/18.860/37.648/14.332 ms user@computer:~$
ping its IPv6 address
It is a little bit more complicated to ask Tayga to answer to an ICMPv6 request because there is no route to
fdaa:bb:1::1 and because Tayga has no address defined inside the Well-Known prefix
Because of the RFC 6052, Tayga does not translate IPv6 address carrying a RFC 1918 address and replies with an error. With this trick, it is possible to check if Tayga answers to IPv6 without reaching a host on Internet.
user@computer:~$ ping -c 4 64:ff9b::192.168.1.1 PING 64:ff9b::192.168.1.1(64:ff9b::c0a8:101) 56 data bytes From fdaa:bb:1::1 icmp_seq=1 Destination unreachable: No route From fdaa:bb:1::1 icmp_seq=2 Destination unreachable: No route From fdaa:bb:1::1 icmp_seq=3 Destination unreachable: No route From fdaa:bb:1::1 icmp_seq=4 Destination unreachable: No route --- 64:ff9b::192.168.1.1 ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3005ms user@computer:~$
The answer comes from
fdaa:bb:1::1, the IPv6 address assigned to Tayga. It shows Tayga is able to exchange IPv6 traffic.
There is now a working NAT64 gateway in my LAN meeting all of my expectations. It wasn’t always easy to understood each part of it at first but the configuration was really short and not so difficult. Tayga seems to be a really simple, powerful and efficient tool. And now it is time to work on a DNS64 service… 🙂