On Tue, 19 Nov 2013, Ian Smith wrote:
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.
Much of our initial deployment will be dual-stack, however I also want to
plan for situations where we won't have enough v4 addresses to dual-stack
(or we reach a point where we need to hold some of our routable v4 space
in reserve for transition mechanisms), plus dual-stack on its own provides
no incentive for users to migrate completely to v6.
That said, I need to plan for the eventuality of v6-only hosts being able
to reach the v4 Internet. While many of the Alexa global 500 sites have
some sort of v6 capability today and the percentage of global Internet
traffic that is v6 is increasing every day, the need for reachability to
what remains of the v4 Internet will not go away any time soon.
jms
