NAT64 and matching identities

Tue Nov 19 16:48:29 UTC 2013

From: Justin M. Streiner [mailto:streiner at 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.