MSOs logging subscriber flows, what could possibly go wrong? Drive slow, like a Sandvine under load, Paul Wall On Mon, Nov 18, 2013 at 8:03 PM, Tom Taylor <tom.taylor.stds@gmail.com>wrote:
On 18/11/2013 3:06 PM, Justin M. Streiner wrote:
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
For logging, the following IETF Behave WG drafts are nearly complete. The IPFIX version will be updated soon (I hope) to more closely match the SYSLOG based one. They both will match the new NAT MIB document, also listed below:
http://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/
http://datatracker.ietf.org/doc/draft-ietf-behave-syslog-nat-logging/
http://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib/
There is also work being done on reducing log volumes by bulk allocation of ports. The following drafts will be combined to meet a Sunset WG milestone:
http://datatracker.ietf.org/doc/draft-chen-sunset4-cgn-port-allocation/
http://datatracker.ietf.org/doc/draft-tsou-behave-natx4-log-reduction/
http://datatracker.ietf.org/doc/draft-donley-behave-deterministic-cgn/
Tom Taylor