RE: NAT64 and matching identities

[Don Bowman <don () sandvine com>]

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.