Re: [v6ops] Google Alert - IPv6

[Dave O'Reilly <[e-mail]>]

More comments inline below:

> On 27 Oct 2017, at 15:59, Lee Howard <[e-mail]> wrote:
> 
> Still offering solely my personal opinion.
> 
> On Oct 27, 2017, at 6:21 PM, Erik Nygren <[e-mail]> wrote:
> 
>> On Fri, Oct 27, 2017 at 4:51 AM, Lee Howard <[e-mail]> wrote:
>> >
>> >One possible solution frequently cited to the problem of CGNAT is
>> >migration to IPv6.However, does migration to IPv6 ACTUALLY solve the
>> >problem of crime attribution due to large-scale address sharing?
>> 
>> Only if content providers deploy IPv6, including logging.
>> 
>> I'll note that that one of the major limitations for content providers deploying IPv6 
>> (perhaps the #1 limitation?) has been making sure all systems that handle IP addresses
>> can handle IPv6 addresses well.  This includes for logging, storing in databases,
>> client reputation, ip-geo, bot detection, fraud management, authentication cookies, 
>> parsing to partially pseudonymize (eg, stripping off bottom N bits), and the like.
>> Plumbing "port" through many of these systems (even just logging and storage)
>> is a non-trivial effort in many places (perhaps larger in some places than supporting
>> IPv6 as now there is a {timestamp,IP,port) tuple that must be transported and stored
>> rather than just an IP.
> 
> I think you're saying that logging IPv6 address is not trivial, but neither is logging IPv4 + port. Maybe not the same cost, but same order of magnitude?
> 

I think the short answer to this is that nobody knows. As I mentioned in an email response I just wrote, I have recommended that further research is required in this area to assess the downstream consequences of logging source port, and these should be considered in the context of a comparably sized project to migrate to IPv6.

>> 
>> It would be much better if we can get onto a path where IPv6 can be relied on
>> enough of the time to avoid having to make a large push on source port logging.
>> A worst case would be if content providers had internal budget/resources to chose between
>> one of "log source port" and "enable IPv6 and support logging IPv6", especially since
>> some might decide to pick just the former and then might say "I went through a big
>> project to log IPv4 source port, why should I also go through the effort to support IPv6?"
>> despite the other good reasons to do so...
> 
> Yes, that would be a worst case.
> As a general rule, regulation should describe what is needed (attribution) not how to do it (log format or IPv6). So, make content providers, ISPs, mobile companies, and consumer electronics (IoT) manufacturers liable for failing to comply with a subpoena if they are unable to provide attribution information in sufficient detail. Content providers (e.g.) can look at their budgets and Vyncke's projection of IPv6 eyeballs and say, "More than half of all users will be IPv6 capable in X months." They can even look at APNIC's data and think about which countries' users generate the most traffic. Then they can do the math on how many subpoenas they'll see requiring IPv4+source+timestamp versus how many they'll see for IPv6, and rationally decide which to deploy, if not both.
> 
I can imagine the conversation, however, where an ISP using CGNAT says that I COULD identify the suspect with my logs but it is YOUR problem (law enforcement/content provider/victim) that there is insufficient information available. The point is that there is an information gap, as I have mentioned in several responses, and we need to consider how we’re going to fill it.


> That way, IPv6 becomes a sort of safe harbor, or at least safer than not. Of course, it only applies if you move toward regulation. Personally, I don't want regulators thinking they understand the Internet well enough to regulate it. 
> 

Also don’t forget that regulatory regimes (and indeed competence levels) vary across the world so a regulatory solution is unlikely to be a general solution.

daveor