The NAT64 handoff protocol is a NAT64 extension which allows a NAT64 to offload parts of its responsibilities to a server running on the IPv4 hosts with which it communicates.
When an IPv4 host runs the NAT64 handoff server component it accepts the responsibility to maintain the authoritative connection table and log connection tracking entries when they are created and deleted. When the server has taken this responsibility the NAT64 will maintain a cache of connection table entries. When a cache miss occurs rather than losing the connection it just costs one roundtrip between NAT64 and IPv4 host to retrieve the connection from the authoritative table.
When a NAT64 supports this protocol and IPv4 host does not support it, the NAT64 will operate as a standard NAT64 and maintain its own connection table. The NAT64 will keep sending messages about connection tracking entries to the IPv4 host even if the port is closed. This is done to ensure that a packet capture on the IPv4 side will contain this relevant information as well as ensure the NAT64 will discover if the IPv4 host starts supporting the protocol.
When an IPv4 host supports this protocol but the NAT64 does not, the server component of NAT64 handoff will simply not receive any packets from that NAT64 and communication will be exactly identical to the case where the IPv4 host did not support the protocol.
By running the server component of this protocol the service can be made more reliable to the users since the NAT64 handoff server component running on the IPv4 host is in full control over purging connection tracking entries. Thus users will no longer experience broken connections when the NAT64 purges connections from its connection table.
By running the server component of this protocol a log of connection tracking entries is available on the IPv4 host. This means the usual server logs as well as connection tracking entry logs are both available on the same host. This will make certain debugging scenarios and investigation of abuse cases easier for the service owner.
It's possible to support protocols which would normally be impossible to use through a NAT.
Logs give an additional signal about the level of IPv6 usage among users than what is commonly available to an IPv4-only service.
By making connection tracking information available up-front to the IPv4 hosts they concern it's expected that the number of inquiries for logs of this information can be reduced and potentially the need for maintaining such logs by the NAT64 can be completely eliminated.
By offloading responsibilities to IPv4 hosts there is the possibility of reducing the amount of memory needed to maintain connection tracking entries.
Improved reliability compared to using a regular NAT64 to reach an IPv4 host.
The protocol provides a way to send a signal to the service owner about the demand for IPv6.