Re: [v6ops] Google Alert - IPv6

Dave O'Reilly <rfc@daveor.com> Sun, 29 October 2017 16:32 UTC

Return-Path: <rfc@daveor.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019A513F5C4 for <v6ops@ietfa.amsl.com>; Sun, 29 Oct 2017 09:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=daveor.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcwMTlDru-iN for <v6ops@ietfa.amsl.com>; Sun, 29 Oct 2017 09:32:55 -0700 (PDT)
Received: from vps.ftrsolutions.com (vps.ftrsolutions.com [5.77.39.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B0913F5BD for <v6ops@ietf.org>; Sun, 29 Oct 2017 09:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daveor.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=CelzqqhwdCyvjR0zpzyVt9yHO4fcxZLtxDP+VfwfazY=; b=jSRk8AaG4VyAkiDGubHel8pI1y KN90bVQ0GGMOfl942o7x+819SSp66w6UBbFUoFx9kcUWR189CY9Ot0ZQ3uc8Pi0jMYWJ7Andq3GUu eMBs1NDclnH5qs9ChgcOHicYhWuH7laW3aKarJCrVmvwkFUaHml7IOI+4AId1Zcez3Gg=;
Received: from 86-44-56-31-dynamic.agg7.bsn.cld-dbn.eircom.net ([86.44.56.31]:55055 helo=[192.168.1.25]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from <rfc@daveor.com>) id 1e8qW5-0002Dx-5B; Sun, 29 Oct 2017 16:32:53 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave O'Reilly <rfc@daveor.com>
In-Reply-To: <D618D79F.8AA1A%lee@asgard.org>
Date: Sun, 29 Oct 2017 16:32:52 +0000
Cc: Warren Kumari <warren@kumari.net>, "v6ops@ietf.org" <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC812180-D32F-4DA6-A74D-22ACBB0576C8@daveor.com>
References: <f403045ef57ac52962055bd88b84@google.com> <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <alpine.DEB.2.20.1710190655260.31961@uplift.swm.pp.se> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <alpine.DEB.2.20.1710190856530.31961@uplift.swm.pp.se> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAHw9_iLWAMexrfXwsdB8duGa5ueJMofqVRqNck6DeOzA=KChqA@mail.gmail.com> <C4E37677-A2FB-49F8-B362-C29B28DFD570@daveor.com> <D618D79F.8AA1A%lee@asgard.org>
To: Lee Howard <lee@asgard.org>
X-Mailer: Apple Mail (2.3124)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - vps.ftrsolutions.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - daveor.com
X-Get-Message-Sender-Via: vps.ftrsolutions.com: authenticated_id: dave@daveor.com
X-Authenticated-Sender: vps.ftrsolutions.com: dave@daveor.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/yNppMVecLI2Rq6zIMHUD-HUiNV8>
Subject: Re: [v6ops] Google Alert - IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Oct 2017 16:32:57 -0000

Hi Lee,

some comments inline below,

daveor

> 
> 
>> Can we regulate our way out of this problem?
>> ——————————————————————————————
> 
> Probably not. Countries with the highest IPv6 deployment have had either
> no government influence, or little more than government talking with
> industry about their IPv6 deployment plans. Countries with IPv6 mandates
> on industry seem to have very low actual deployment.
> 

I completely agree with you that there are too many regulatory models around the world for a recommendation of regulatory solutions to this problem to be likely to meet with much success. However, Belgium has the highest IPv6 adoption rate on the planet according to https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption and I understand that the reason for this is that the telecoms regulator in Belgium required that a maximum of (I think it was) 16 people can be sharing a single IP address on a CGNAT at any given time. I forget the exact figures but it was definitely a regulatory intervention.

>> 
>> Considering regulation as a way to adjust economic incentives, there is
>> indeed an opportunity to help to shift things along in one or more
>> countries through regulation, but to what extent will this help with the
>> global issue of crime attribution?
> 
> To the degree that IPv6 and/or proper port/timestamp logging is adopted.
> Either will work, but this is becoming much more of a content operator
> problem than an ISP or mobile carrier problem.

Actually I see it as a “people helping themselves" versus a “wait for the problem to go away” solution. True to say, however, that the solution (source port logging) needs to be implemented by content providers rather than ISPs.

> 
> 
>> It is clear that if the number of subscribers that can be simultaneously
>> behind a CGNAT is limited, the deployment of IPv6 increases, and the IPv6
>> adoption in Belgium bears that out.
> 
> Yes, and I think you’re right, but the Belgian interpretation that address
> sharing must not exceed 16:1 may not be generalizable. That is: Belgium is
> one country, and we don’t know if their rule would work everywhere.
> 

Absolutely agree with you - regulatory solutions are not general solutions.

>> 
>> 
>> However, the obvious question to ask is - are the Belgian authorities
>> catching any more criminals now that they have such a high adoption rate
>> of IPv6? Has the problem of crime attribution due to CGNAT gone away for
>> them, or does it actually require global adoption of IPv6?
> 
> The question is more like, “Are Belgian authorities catching more
> criminals than other countries in proportion to their IPv6 deployment?”
> They’re probably not catching more bad guys than they were before CGN,
> they’re just trying not to lose ground.
> And the answer is probably not good, because although Belgium has great
> numbers on eyeballs, their IPv6 deployment on content sites is still weak
> (https://www.vyncke.org/ipv6status/detailed.php?country=be ).
> 
> 

Exactly! So they can attribute domestic IPv6 activity to domestic IPv6 addresses but the second IPv4 to IPv6 transition takes place they’re no better off than anyone else.

>> 
>> 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.
> 
>> The problem is that law enforcement agencies do not have the required
>> information to be able to ask the ISP for the subscriber identity -
>> because source ports are required and not logged anywhere.
>> 
>> So the question becomes how to address this information gap. One
>> possibility is that ISPs must record all destination IP addresses for all
>> TCP connections, 
> 
> If the problem is that content providers are not logging enough
> information to identify users reaching their content, why in the world
> would this gap become the ISPs' problem? Regulate the content providers if
> they’re the ones providing insufficient information.
> 

Well, here again we’re back to regulation as a possible solution. Practically everywhere in the world there is already a regulatory framework in place for ISPs and therefore the easy answer is to enforce additional regulation on ISPs - requiring them to solve this problem. 

As I mentioned in a previous email response that I just wrote, I see this as an information gap problem - there is a gap between the records ISPs are keeping and the available records at (most) content providers. The question is how best to fill this gap.

>> 
>> The role of the IETF in this
>> ——————————————————————————————
>> 
>> Right from the front page of the IETF website: "The mission of the IETF
>> is to make the Internet work better by producing high quality, relevant
>> technical documents that influence the way people design, use, and manage
>> the Internet.”
>> 
>> Large scale address sharing technologies present a challenge to the
>> management of the Internet so that seems to fit right within the remit of
>> the IETF to me. Correct me if I’m wrong...
> 
> Not entirely, but this seems more operational to me, and might be better
> targeted as a recommendation for how to manage servers.
> 

Well, the IETF has already published such recommendations (RFC6302). The question is what, if anything, else the IETF can/should do. 

I wrote this document and I didn’t really know what to do with it, so I published it as an internet draft and have been trying to collect input on what/where the best places to progress the conversation are…and here we are.

daveor