Re: [v6ops] Google Alert - IPv6

Dave O'Reilly <rfc@daveor.com> Thu, 02 November 2017 17:17 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 48C5813F758 for <v6ops@ietfa.amsl.com>; Thu, 2 Nov 2017 10:17:01 -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 w3ZoMvqlQrtl for <v6ops@ietfa.amsl.com>; Thu, 2 Nov 2017 10:16:59 -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 8D22213F503 for <v6ops@ietf.org>; Thu, 2 Nov 2017 10:16:59 -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=2gi6dP8JdFDIVyDtnjDxXZkubsdSegOYZivc9CP90ec=; b=ktSYNIXoiTiR3GjZgMHciccdkl X4X5XpCYANFEUjMWmmxBxWIakVLHZruDyd/r5FD/hP65Aj7j4u2m4jFzAycNyTKomeVnQMfI8X1Q5 G6iStYbcjEXWScYhXIdNArbWSYBFqIeXgrA4OEObK0c2eJCkdr7yjOboqY9rNINDfiJw=;
Received: from [83.103.212.135] (port=62332 helo=[172.16.102.121]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from <rfc@daveor.com>) id 1eAJ6v-0002xP-E1; Thu, 02 Nov 2017 17:16:57 +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: <D61F4B20.8AF09%lee@asgard.org>
Date: Thu, 02 Nov 2017 17:16:58 +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: <4371DA07-BEE2-4CD3-B6AC-8D2547F8360B@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> <DC812180-D32F-4DA6-A74D-22ACBB0576C8@daveor.com> <D61F4B20.8AF09%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/Q-9guUSfaysvi_xTHJ2bJ4T9Q8w>
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: Thu, 02 Nov 2017 17:17:01 -0000

> On 1 Nov 2017, at 14:07, Lee Howard <lee@asgard.org> wrote:
> 
> 
> 
> On 10/29/17, 8:32 PM, "Dave O'Reilly" <rfc@daveor.com> wrote:
>> 
>>> 
>>> 
>>>> 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-a
>> doption&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.
> 
> 
> My understanding, which is indirect, is that Belgian law enforcement and
> telecom regulators sat down with ISPs and said, “Our reading of EU law
> says CGN is illegal.” And ISPs said, “We have to do CGN, or turn off the
> Internet, (or maybe increase Internet prices to buy IPv4 addresses).”  So
> the regulators agreed to forebear enforcement of the no-CGN law unless
> address sharing exceeded 16 users per address.
> 
> I have been unable to find this agreement in writing, though. That might
> be intentional.
> 
> So, yes, I suppose it is regulatory intervention, but it’s not new
> regulation, it’s a different inteprpretation than other EU member states
> have of EU law. And it’s not a regulation, it’s an unwritten understanding
> (or forebearance). 
> 
> I would welcome correction if my understanding is inaccurate our outdated.
> 
> 

I know it was a regulatory intervention alright but I don’t know the details of the discussion, perhaps it is a voluntary code of practice. In either case, such interventions are unlikely to be broadly applicable as a solution to the crime attribution problem.

>> 
>>>> 
>>>> 
>>>> 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.
> 
> Do you mean IPv6 is no better than CGN for attribution, or do you mean
> IPv6 is no better than native IPv4?
> 

What I meant was that at some point IPv6 to IPv4 translation will need to take place, which is essentially a form of large scale address sharing, similar but not identical to the CGNAT problem (similar enough to form part of this discussion in any case). Until IPv6 is ubiquitous and IPv4 is no longer routable this problem will remain to a greater or lesser extent.

>> 
>>>> 
>>>> 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.
> 
> I do think it has been a good discussion. You might propose it as a talk
> at NANOG, RIPE, or whatever your local NOG is. Even better would be to get
> in front of web server operators, but I don’t know whether or where they
> meet.
> 

Good idea, I will investigate this further. I have been trying to find out how best to approach OWASP and the apache software foundation to try and get the discussion going with them at least. No success so far, but I’ll keep going.

daveor