[166921] in North American Network Operators' Group
RE: NAT64 and matching identities
daemon@ATHENA.MIT.EDU (Ian Smith)
Tue Nov 19 18:53:53 2013
From: Ian Smith <I.Smith@F5.com>
To: "Justin M. Streiner" <streiner@cluebyfour.org>, "nanog@nanog.org"
<nanog@nanog.org>
Date: Tue, 19 Nov 2013 23:53:30 +0000
In-Reply-To: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
It depends on what direction your are translating to:=0A=
=0A=
IPv6-only host to IPv4 Internet: This isn't a problem if you are dual-stac=
k 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 log=
ged 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 on=
e message, depending on the AAA and IPAM architecture) and invest in log se=
rvers. 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. =0A=
=0A=
There is obviously a long tail of ip4 destinations, but nearly all of 500 o=
f the Alexa global 500 have ip6 listeners, so the majority of your connecti=
ons from ip6 only hosts should be leaving your network without NAT and if t=
hey aren't, you should figure out why as part of reassessing the problem.=
=0A=
=0A=
=0A=
IPv6 Internet to IPv4-only host: Just do LB64 with an IP proxy. Most comm=
ercial SLB/ADC vendors do this today and offer varying degrees of ALG to fi=
x-up protocols that have multiple channels. Your server doesn't need to kn=
ow that there is a IPv6 portion of the connection unless they are doing som=
ething absurd like trying to initiate connections to IPv6 only hosts, and t=
he 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 wil=
l do header inserts with the original client ip, others might not be, but b=
y not having dual-stack applications, you are committing yourself to the te=
dium of protocol by protocol fix-ups. You can help out that particular hea=
dache by using name lookups instead of address lookups (getaddrinfo instead=
of gethostbyaddr on POSIX systems)=0A=
=0A=
=0A=
________________________________________=0A=
From: Justin M. Streiner [streiner@cluebyfour.org]=0A=
Sent: Monday, November 18, 2013 3:06 PM=0A=
To: nanog@nanog.org=0A=
Subject: NAT64 and matching identities=0A=
=0A=
It's looking more and more like NAT64 will be in our future. One of the=0A=
valid concerns for NAT64 - much like NAT44 - is being able to determine=0A=
the identity of a given user through the NAT at a given point in time.=0A=
How feasible this is depends on how robust/scalable $XYZ's translation=0A=
logging capabilities are, and possibly how easily that data can be matched=
=0A=
against a source of identify information, such as RADIUS accounting logs,=
=0A=
DHCP lease logs, etc.=0A=
=0A=
Other IPv6 transition mechanisms appear to be no less thorny than NAT64=0A=
for a variety of reasons.=0A=
=0A=
I'm curious to see how others are planning to tackle (or already have=0A=
tacked) this issue. Discussing vendor-specific solutions is fine, but I=0A=
think keeping things as platform/vendor agnostic as possible for the time=
=0A=
being would allow this thread to be more beneficial to a wider audience.=0A=
=0A=
The floor is open...=0A=
=0A=
jms=0A=
=0A=
