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

Ole Troan <otroan@employees.org> Sat, 28 October 2017 03:15 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 D09FD13F659 for <v6ops@ietfa.amsl.com>; Fri, 27 Oct 2017 20:15:58 -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 8NWiRmIdpaak for <v6ops@ietfa.amsl.com>; Fri, 27 Oct 2017 20:15:57 -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 6FAAC13AF75 for <v6ops@ietf.org>; Fri, 27 Oct 2017 20:15:57 -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 747642D510F; Sat, 28 Oct 2017 03:15:55 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C93A42007CE164; Sat, 28 Oct 2017 05:15:22 +0200 (CEST)
From: Ole Troan <otroan@employees.org>
Message-Id: <95274753-7241-47DE-B463-0341248FAE38@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_60394AF1-3760-4639-B963-99DB241EA0C4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Date: Sat, 28 Oct 2017 05:15:21 +0200
In-Reply-To: <B20ECDCB-1EFD-4265-BE13-5AE1E92335AE@gmail.com>
Cc: Lee Howard <Lee@asgard.org>, "v6ops@ietf.org" <v6ops@ietf.org>, Tore Anderson <tore@fud.no>, Dave O'Reilly <rfc@daveor.com>
To: Fred Baker <fredbaker.ietf@gmail.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> <22C655A9-AE02-4885-98B5-7515C49E7F2B@employees.org> <B20ECDCB-1EFD-4265-BE13-5AE1E92335AE@gmail.com>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/o2qmK7mkk0E5QTuiE2u4QuMuMWM>
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 03:15:59 -0000

Fred,

>> The bitter truth is that we can make IPv4 'scale' forever. ;-(
> 
> Actually, from what I have been told, we can't. We can make it work for a number of sources per translated address (Xing Li gave a talk on his experiments in that regard a few years back, although I would have to do some research to find it). As I recall, he started getting user complaints when he had 100-or-so active sessions on each external address. That's far from "forever".

Complaints about what?
You might be assuming the IPv4 Internet isn't changing to accommodate address sharing. And there are many ways of building NAT.
The mechanisms I described earlier do work. It's on my todo list to get hold a sufficiently large traffic sample to run the numbers of how what sharing ratio you could achieve. It is orders of magnitude more than 1:100 (if you intended s/sessions/users).

Each session to 8.8.8.8:53 would burn a port.
But a single port could be reused for millions of connections as long as DA+DP was different.
(And you could of course be nice to things like SIP and give those endpoint-independent behaviour).

That said the path, of extending A+P to the end host is also open to us. Similarly to what Brian C proposed at IETF 29.
No state in network. Each host gets a single port. I.e. we have expanded the address space to 48 bits.
Requires new transport protocol on top of IP+UDP of course. With it's own name space. But that's pretty much happening over in transport now anyway, right?

Ole