Have you observed any of the following?
If you have observed any of the above then this page exists to explain you what the nature of the traffic you observed is and what I am doing to help you know the real origin of the traffic that you have observed.
The NAT64 handoff protocol will soon be deprecated and replaced with Geneve tunnels. This change will be transparent to clients. Only those who downloaded the server software from this page will be affected.
As you have likely heard the supply of IPv4 addresses has run out. For more than 20 years IPv6 has been available as a good long term solution to this problem, but in spite of that there are still many networks running only IPv4. Because of this NAT is seeing widespread use and often two or more layers of NAT are being used.
The use of NAT has a few shortcomings. With the NAT64 handoff protocol I am aiming to address two of those shortcomings. Due to the finite amount of resources available to any NAT it will sometimes have to expire connection tracking entries which were still in use, this results in users experiencing unreliable connectivity. Servers will only see the IPv4 address of the NAT and not the IP address of the real user, this makes it harder to debug software bugs as well as investigate abuse cases.
NAT64 is one of multiple standardized ways to do NAT. NAT64 is used by some internet providers who have upgraded their own network to IPv6 but still have customers who need to reach services which are only on IPv4.
As with other kinds of NAT the IPv4 address visible to the IPv4-only service is that of the NAT. The difference is that the real IP address not seen by that service is an IPv6 address rather than an IPv4 address.
The advantages of NAT64 are that the internet provider can mostly avoid the need to support IPv4 and thus have a simple IPv6-only infrastructure. And with the vast amount of IPv6 addresses available the need for multiple layers of NAT to address shortage of IP addresses is avoided.
NAT64 handoff is an extension of NAT64. With this extension the NAT64 will send information about the connection tracking entries it is creating to UDP port 62863 on the IPv4 addresses it is communicating with.
On UDP port 62863 you can run a server which when receiving these packets will take responsibility to maintain the connection table and will log each entry being created in the connection table or removed from it. Here is an extract showing what that log could look like:
2019-03-18 10:06:28.436754 Initialized 192.0.2.7 2019-03-18 10:06:28.491727 Created 192.0.2.7:3719 [2001:db8::17]:53186 2019-03-18 10:07:07.333900 Created 192.0.2.7:12191 [2001:db8::3]:53716 2019-03-18 11:41:06.362189 Created 192.0.2.7:28965 [2001:db8::5]:41660 2019-03-18 15:22:02.062254 Deleted 192.0.2.9:47102 [2001:db8::75]:33131 2019-03-18 15:22:02.062478 Created 192.0.2.9:47102 [2001:db8::55]:34643
In order to aid deployment of this protocol as well as IPv6 in general I am operating a public NAT64 service. If you see unexpected traffic originating from the NAT64 I operate I encourage you to first use the information on this site to understand the traffic. Once you have read the information on this site I am happy to engage in any constructive dialogue about ways in which I can improve these tools.