This service is different from many others. There is no way for you to report abuse to me. Instead I provide you with the relevant tools to see exactly which IP addresses you are communicating with on the other side of the NAT64. Moreover I provide controls that will allow you to block traffic as you see fit.

Which of the tools are relevant to you depend on whether your system is an IPv6 client host or an IPv4 server host.

For IPv4 servers

This NAT64 can exchange connection tracking information directly with your server. This will not only allow you better control over the reliability your users will experience but will also give you a logfile of all connection tracking entries including the real IPv6 address of clients.

Read more and download the needed software on the NAT64 handoff page.

If your IPv4 address isn't a server or if your server already has full IPv6 support you can block all traffic from the NAT64 using this tool.

Be aware that this NAT64 primarily has legitimate users and abusers is a minority. If you use the tool to block traffic on a server without IPv6, you will cause collateral damage by locking out some of your legitimate users.

To use the tool type ./ followed by the IPv4 addresses of the NAT64 gateways you wish to block. All IPv4 traffic between your server and the NAT64 will remain blocked until the next time the NAT64 is restarted. Using this tool will consume less of your bandwidth than blocking the traffic on your end of the connection.

Theese tools are primarily intended to block packet floods. They are by no means a replacement for good security practices on your servers.

For IPv6 clients

When you communicate through this NAT64 pool a port number on the IPv4 address of the NAT64 will be mapped to a port number on your IPv6 address. As long as this mapping exists it can be used by IPv4 hosts to send packets to that port number on your IPv6 address.

Due to the small number of IPv4 addresses it's feasible for bad actors to scan the entire IPv4 address space. Such scanning happens quite frequently and they can find the port number which the NAT64 has mapped to your host.

This is generally harmless. These mappings will point to ephemeral ports on your IPv6 address and as such they will under normal circumstances not reach any listening service on your host.

Using the NAT64 pool will not increase your exposure. If you have services exposed to the internet those could be reached more easily through regular non-NATed connections than through the NAT64. You can use a firewall to protect your network from attacks through both channels.

Even though unwanted traffic arriving to your host through the NAT64 is generally harmless it can in rare cases be a nuisance. For that reason I will let clients remove mappings they no longer need by responding with ICMPv6 administratively prohibited (type 1 code 1) messages. To remove such a mapping respond to both TCP and UDP packets on the port number with that type and code.

If you are using ip6tables you can achieve that effect using: -j REJECT --reject-with adm-prohibited

If IANA allocates an official code number for this particular purpose I will switch from code 1 to the official code number as soon as possible.

You will always be able to see which IPv4 address traffic to your host originated from since that will always be embedded in the lowermost 32 bits of the IPv6 address.