NAT64 and matching identities

Tue Nov 19 23:23:21 UTC 2013

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