NAT64 and matching identities
don at sandvine.com
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
Let me know if u want more info and I can follow up offline.
More information about the NANOG