I am operating a public NAT64 service with support for the NAT64 handoff protocol. The purpose of this service is to aid the adoption of both IPv6 and the NAT64 handoff protocol.
The service can be used in multiple different ways. You can use the public DNS64 operated together with the NAT64s. You can use your own DNS64 in a static configuration or your own DNS64 in a dynamic configuration.
To use the public DNS64+NAT64 service configure your clients to use these DNS servers:
These can be autoconfigured using router advertisements or DHCPv6, or they can be manually configured on each client.
Configure your recursive DNS server to use these DNS64 prefixes:
2a00:1098:2b::/96 2a00:1098:2c:1::/96 2a01:4f8:c2c:123f:64::/96 2a01:4f9:c010:3f02:64::/96
If your recursive DNS server runs BIND9 you can add the following fragment to the options section of /etc/bind/named.conf.options
dns64 2a00:1098:2b::/96 {
clients { any; };
exclude { 0::/3; 4000::/2; 8000::/1; 2001:db8::/32; };
};
dns64 2a00:1098:2c:1::/96 {
clients { any; };
exclude { 0::/3; 4000::/2; 8000::/1; 2001:db8::/32; };
};
dns64 2a01:4f8:c2c:123f:64::/96 {
clients { any; };
exclude { 0::/3; 4000::/2; 8000::/1; 2001:db8::/32; };
};
You can run a local DNS64 which health checks each NAT64 prefix and uses the results to decide which prefixes to use for synthesized AAAA records. If your locan DNS64 is running BIND you can use the NAT64 health daemon.
If you run your own local DNS64 it is also possible to combine both the prefixes offered by this service and prefixes offered by your own ISP or other public NAT64 services.
When communicating with IPv4 hosts which support the NAT64 handoff protocol you will get a more reliable connection than through other NAT solutions. This is because the server will take over the responsibility to maintain the authoritative connection tracking table.
When the NAT64 needs to purge idle connections to free up table space it can be retrieved from the server next time it is needed. With other NAT implementations such an event would have caused your connection to be closed.
With the NAT64 handoff protocol it is possible to keep connections alive even across NAT64 reboots.
Apart from the reliability benefit you may want to use this service as a way to signal to service owners that there is a demand for IPv6 support. Each connection tracking entry is communicated to the IPv4 host in a UDP packet. If the host is running the server component of the NAT64 handoff protocol, it will maintain a log of which clients have accessed it through a NAT64 with handoff support. If the host does not run the server component it will still receive the UDP packets and each UDP packet will contain a human readable string explaining the need for IPv6 and the purpose of the NAT64 handoff protocol.
The NAT64 itself will log packet counts per IPv6 /32. Packets which cannot be associated with any IPv6 address are counted per IPv4 /24. These usage stats are logged to help me understand how widely used this service is and in case I am approaching the bandwidth limit of my hosting plan I can use that information to know which ISPs I should reach out to in order to make other arrangements.
The NAT64 does not log connection tracking entries. However it will send connection tracking entries to the IPv4 host which the connection tracking entries concerns. If that host has installed the server component of the NAT64 handoff protocol it will log your IPv6 address. So you cannot use this service to hide your IPv6 address from the IPv4 services you are accessing.
The service is rate limited. I rate limit traffic to ensure I don't exceed the permitted traffic on my hosting plan. If you are an individual end user with a typical usage the rate limit should not be a concern to you. If you are planning on configuring DNS64 for a large number of users please get in touch about your planned bandwidth usage beforehand such that we can work out an arrangement that will work for everybody.
Home