From: Justin M. Streiner [mailto:streiner@cluebyfour.org]
It's looking more and more like NAT64 will be in our future. One of the valid concerns for NAT64 - much like NAT44 - is being able to determine the identity of a given user through the NAT at a given point in time. How feasible this is depends on how robust/scalable $XYZ's translation logging capabilities are, and possibly how easily that data can be matched against a source of identify information, such as RADIUS accounting logs, DHCP lease logs, etc.
... snip ... We implemented a product around this. What we found in doing so was that a) you need to use port-block allocation to make it feasible (cannot do unbounded NATP where every flow gets its own port), That AAA works well when the NAT is a gateway device, and that Otherwise DHCP works ok, and syslog is the fallback. All devices Supported one of those three. We also found there was a need for IPV6 identification (e.g. some customers used DNS reverse lookup in ipv4 to find the ID of a user for e.g. single-sign-on type solutions, and this no longer worked in a NAT44/NAT64/IPv6 environment. We found there was a need for both real-time (e.g. query who is this right now, e.g. sign-on), and after the fact (who had this @ this time). The general purpose coordinates we called 'session qualifiers', and we found that sometimes it included VLAN or MPLS or other tunnels. Let me know if u want more info and I can follow up offline.