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

Fred Baker <fredbaker.ietf@gmail.com> Sat, 28 October 2017 05:19 UTC

Return-Path: <fredbaker.ietf@gmail.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 3CCB013F691 for <v6ops@ietfa.amsl.com>; Fri, 27 Oct 2017 22:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OlOrfAlYVDkP for <v6ops@ietfa.amsl.com>; Fri, 27 Oct 2017 22:19:48 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE0213F692 for <v6ops@ietf.org>; Fri, 27 Oct 2017 22:19:47 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id z3so6943205wme.5 for <v6ops@ietf.org>; Fri, 27 Oct 2017 22:19:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ml2gmEmfGrnu1MGmVyCbLqXfSRnnSGeT1rTqZ18055g=; b=lyyrwdoCiacsdXh/WYNcA5pSC3iOfFuI2VJa7ZND5f3IJvGHtx1nna21xikvJkmx+b 2fuFsavjmEIBuYN9cAyUoQKNhGtzIR98kw+w0yevvq+G+jI7sUEs8SfOruYap/0NkrzK Y84lysSz3gCm8tZuL+fMMg/lr7XQBTiAh8y1D5ITIh7hcTVgelJaSNOUBFwArAmEUVFr gusoQjrEUl0vGQggdC1zemuaoRYKWhdcInzR2W4lmq2lkTn23YF8GgLiQjOp4abpwDP7 qyzwrm5k1VIklNPqvbUZt2jwZZV6OawYDDYcZ7ZAhvrk1w+Q1Qe5ltsRUL00zhyFEorf cEAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ml2gmEmfGrnu1MGmVyCbLqXfSRnnSGeT1rTqZ18055g=; b=laeM7lM8eEUN0q/2uB7yK/v4/ud2jc4NjLXYOyt8dn3ctel+3UILAWp0J3hAlX38Dw 12DarSxTE+H2hcvZmWTl3e3ALrj03y1xp+lKSJNpiEfypboeV0Sk9i6x9s1xBtCc4uj1 KPKBV2tyhBvH4J2pYzjkGs8rEYWQA0/UI1qYhTICH8vpW196C7wHS6NoHcMxNEUhNdBj UG28UTl6dYe4layhCM27K/4MbpgDmqows9mZPW1Alca8zsiAWELZauflSfDAdcOru0Br lh8f31l+LReDGvwxPCaRQPgJ/MW8y9z/FhMSF+9HG1wfLr8iBkzxEDTdxZkYIQLo+zr2 lreg==
X-Gm-Message-State: AMCzsaULJanVL6OdSPSDOvdPHjEvsZTKAvs/0xD0Q+gAAP387R/bvxaS 6PmfRunImvZYb8LiuKEY+JA=
X-Google-Smtp-Source: ABhQp+SzI9J5JVIVX3O2+goMCXDZlJIsFxaXfEvkB/RmgwywmBwR3WzD13TPCgR55QPTv7EtdUzVVA==
X-Received: by 10.28.128.194 with SMTP id b185mr1857099wmd.152.1509167986393; Fri, 27 Oct 2017 22:19:46 -0700 (PDT)
Received: from ?IPv6:2620:f:8000:210:34ce:94cb:61c6:8fde? ([2620:f:8000:210:34ce:94cb:61c6:8fde]) by smtp.gmail.com with ESMTPSA id o20sm9355781wro.6.2017.10.27.22.19.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Oct 2017 22:19:45 -0700 (PDT)
From: Fred Baker <fredbaker.ietf@gmail.com>
Message-Id: <5FA44821-D6C2-4A9C-A1A5-59BECB65B4F4@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F84EDAF6-3CAB-4DAC-ADA7-C10AD7A81FB1"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Sat, 28 Oct 2017 09:19:42 +0400
In-Reply-To: <95274753-7241-47DE-B463-0341248FAE38@employees.org>
Cc: Lee Howard <Lee@asgard.org>, "v6ops@ietf.org" <v6ops@ietf.org>, Tore Anderson <tore@fud.no>, Dave O'Reilly <rfc@daveor.com>
To: Ole Troan <otroan@employees.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> <22C655A9-AE02-4885-98B5-7515C49E7F2B@employees.org> <B20ECDCB-1EFD-4265-BE13-5AE1E92335AE@gmail.com> <95274753-7241-47DE-B463-0341248FAE38@employees.org>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ShOx-sBVqS5GppHxrOavovSKm2A>
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 05:19:50 -0000


> On Oct 28, 2017, at 7:15 AM, Ole Troan <otroan@employees.org> wrote:
> 
> 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?

What I'm thinking about specifically is slide 6 of https://www.ietf.org/proceedings/92/slides/slides-92-v6ops-3.pdf, and some of the other slides around it. I got the number wrong: he saw issues when he had more than 512 addressed machines sharing a single address using NAT address. I believe that the context was splitting the port number so that any given address had a certain number of ports that could be tracked to it rather than fussing with logging.

> 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