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
- Re: [v6ops] Google Alert - IPv6 Paul Marks
- Re: [v6ops] Google Alert - IPv6 Fred Baker
- Re: [v6ops] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Brian E Carpenter
- Re: [v6ops] Google Alert - IPv6 Rajiv Asati (rajiva)
- Re: [v6ops] Google Alert - IPv6 Ca By
- Re: [v6ops] Google Alert - IPv6 Erik Kline
- Re: [v6ops] Google Alert - IPv6 Mikael Abrahamsson
- Re: [v6ops] Google Alert - IPv6 Tore Anderson
- Re: [v6ops] Google Alert - IPv6 Mikael Abrahamsson
- Re: [v6ops] Google Alert - IPv6 mohamed.boucadair
- Re: [v6ops] Google Alert - IPv6 Ca By
- Re: [v6ops] Google Alert - IPv6 Lorenzo Colitti
- Re: [v6ops] Google Alert - IPv6 Alexandre Petrescu
- Re: [v6ops] Google Alert - IPv6 Warren Kumari
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 Ca By
- Re: [v6ops] Google Alert - IPv6 Ole Troan
- Re: [v6ops] Google Alert - IPv6 mohamed.boucadair
- Re: [v6ops] [SUSPECTED SPAM] RE: Google Alert - I… Ole Troan
- Re: [v6ops] [SUSPECTED SPAM] RE: Google Alert - I… mohamed.boucadair
- Re: [v6ops] Google Alert - IPv6 Lee Howard
- Re: [v6ops] Google Alert - IPv6 Erik Nygren
- Re: [v6ops] Google Alert - IPv6 Lee Howard
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Ole Troan
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Fred Baker
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Ole Troan
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Fred Baker
- Re: [v6ops] Google Alert - IPv6 Fernando Gont
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Gert Doering
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Mark Smith
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Fred Baker
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Ole Troan
- Re: [v6ops] Google Alert - IPv6 Fred Baker
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 Ole Troan
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 Ole Troan
- Re: [v6ops] Google Alert - IPv6 Mark Smith
- Re: [v6ops] Google Alert - IPv6 DY Kim
- Re: [v6ops] Google Alert - IPv6 Fred Baker
- Re: [v6ops] Google Alert - IPv6 DY Kim
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Mark Andrews
- Re: [v6ops] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Lee Howard
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 t.petch
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 Ole Troan
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Mark Smith