[166902] in North American Network Operators' Group
Re: NAT64 and matching identities
daemon@ATHENA.MIT.EDU (Lee Howard)
Tue Nov 19 09:46:51 2013
Date: Tue, 19 Nov 2013 09:46:31 -0500
From: Lee Howard <Lee@asgard.org>
To: "Justin M. Streiner" <streiner@cluebyfour.org>, <nanog@nanog.org>
In-Reply-To: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 11/18/13 3:06 PM, "Justin M. Streiner" <streiner@cluebyfour.org> wrote:
>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.
Bulk port allocation. Your NAT logs then approximate your DHCP (or
whatever) logs in size and scope.
Unless you mean to use it to front a web service. Then just use
x-forwarded-for, and make sure your logs and log parsers can handle it.
Might want to write a correlation script.
>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.
Ask the vendors; it took them a while, but they all have techniques for
reducing logs.
>
>Other IPv6 transition mechanisms appear to be no less thorny than NAT64
>for a variety of reasons.
Yes; see rfc7021.
Once you've deployed it, an experience report at a NANOG meeting would be
welcome.
Lee
