NAT64 and matching identities

Tue Nov 19 23:53:30 UTC 2013

It depends on what direction your are translating to:

IPv6-only host to IPv4 Internet:  This isn't a problem if you are dual-stack at the host, but if you really do have ip6 only hosts, you aren't looking at any requirement that is different than LSN44 or providing a IPv6 tunnel broker service (like he.net).  Since NAT64 is necessarily predicated by a DNS64 operation and you know who you gave an IP address to because they logged in (in some fashion) so you could bill them, you can log {subID,src_ip6,xlat_ip4:port,dst_ip4:port,fqdn} using syslog or ipfix (in as little as one message, depending on the AAA and IPAM architecture) and invest in log servers.    Port block allocation and deterministic schemes are possible here as well, but really, the only way to know you aren't going to be surprised by a lost or inaccurate data set under subpoena is to just log everything and write it off as a statutory expense. 

There is obviously a long tail of ip4 destinations, but nearly all of 500 of the Alexa global 500 have ip6 listeners, so the majority of your connections from ip6 only hosts should be leaving your network without NAT and if they aren't, you should figure out why as part of reassessing the problem.

IPv6 Internet to IPv4-only host:  Just do LB64 with an IP proxy.  Most commercial SLB/ADC vendors do this today and offer varying degrees of ALG to fix-up protocols that have multiple channels.  Your server doesn't need to know that there is a IPv6 portion of the connection unless they are doing something absurd like trying to initiate connections to IPv6 only hosts, and the ADC will help you deal with it as well.  Conveying the xlat information is protocol specific - HTTP and SIP are super easy, since that same ADC will do header inserts with the original client ip, others might not be, but by not having dual-stack applications, you are committing yourself to the tedium of protocol by protocol fix-ups.  You can help out that particular headache by using name lookups instead of address lookups (getaddrinfo instead of gethostbyaddr on POSIX systems)

________________________________________
From: Justin M. Streiner [streiner at cluebyfour.org]
Sent: Monday, November 18, 2013 3:06 PM
To: nanog at nanog.org
Subject: NAT64 and matching identities

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.

Other IPv6 transition mechanisms appear to be no less thorny than NAT64
for a variety of reasons.

I'm curious to see how others are planning to tackle (or already have
tacked) this issue.  Discussing vendor-specific solutions is fine, but I
think keeping things as platform/vendor agnostic as possible for the time
being would allow this thread to be more beneficial to a wider audience.

The floor is open...

jms