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 [strei...@cluebyfour.org]
Sent: Monday, November 18, 2013 3:06 PM
To: nanog@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
