Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6

Ole Troan <otroan@employees.org> Sat, 28 October 2017 02:22 UTC

Return-Path: <otroan@employees.org>
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 BB7F213F63C for <v6ops@ietfa.amsl.com>; Fri, 27 Oct 2017 19:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 outuQqchu85N for <v6ops@ietfa.amsl.com>; Fri, 27 Oct 2017 19:22:25 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8C313F638 for <v6ops@ietf.org>; Fri, 27 Oct 2017 19:22:24 -0700 (PDT)
Received: from h.hanazo.no (unknown [104.153.224.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 3981C2D5109; Sat, 28 Oct 2017 02:22:23 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id CB2982007CC632; Fri, 27 Oct 2017 19:21:55 -0700 (PDT)
From: Ole Troan <otroan@employees.org>
Message-Id: <22C655A9-AE02-4885-98B5-7515C49E7F2B@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_286CCE49-C4D3-4710-ABF8-31DFB65D2D83"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Date: Fri, 27 Oct 2017 19:21:54 -0700
In-Reply-To: <D618D79F.8AA1A%lee@asgard.org>
Cc: Dave O'Reilly <rfc@daveor.com>, Warren Kumari <warren@kumari.net>, "v6ops@ietf.org" <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
To: Lee Howard <Lee@asgard.org>
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>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/OBeFoIDkNTdkEHQPmM3bpMAw5ZU>
Subject: Re: [v6ops] [SUSPECTED SPAM] 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: Sat, 28 Oct 2017 02:22:27 -0000

>> 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.

We are digressing from the draft in question, but since I'm sitting somewhere over Oregon at the moment I have ample time.
It is not at all clear that the number of subscribers behind a CGN is "limited".

I'd certainly would have liked to see some research on this.
If you are clever and use endpoint dependent connections where you can. You can stretch address sharing very very far.
Since you can reuse source ports for multiple connections, assuming the destination port is largely constant at 443, the number of connections for a single port is bounded by the distribution of destinations on the Internet.

You will burn one source port for each concurrent connection to the _same_ destination address.

The bitter truth is that we can make IPv4 'scale' forever. ;-(

Best regards,
Ole