Notice these nodes do not need a default route. This is a consequence of them being in the same network as the NAT64; T will be masking the IPv6 nodes, so V through Z think they’re talking directly to it.
In previous versions of Jool, T used to need two or more IPv4 addresses. Because pool4 now stores port ranges, this is no longer the case.
Remember you might want to cross-ping T vs everything before continuing.
Even though they share a lot of code, because of kernel quirks, the NAT64 module is separate from the SIIT one. The name of the NAT64 module is jool.
Though the meaning of pool6 is slightly different than in SIIT, the instance configuration looks pretty much the same:
iptables JoolNetfilter Jool
The iptables configuration, on the other hand, needs to use the JOOL target and match more specific transport addresses in the IPv4 side. Ports 61001-65535 of T’s owned IPv4 addresses are Jool’s default reserved mask range. More information can be found in pool4.
Obviously, users should not need to be aware of IP addresses, much less know they need to append a prefix whenever they need to speak to IPv4. The DNS64 document will tell you how to make the prefix-address-hack transparent to users.
Because a NAT64 is stateful, only IPv6-started tests can be run at this point. See port forwarding if 4-to-6 translation is relevant for you.
More complex setups might require you to consider the MTU notes.
Please note that none of what was done in this tutorial survives reboots! Documentation on persistence will be released in the future.