Re: [v6ops] Thoughts about wider operational input

Simon <linux@thehobsons.co.uk> Tue, 22 March 2022 17:47 UTC

Return-Path: <linux@thehobsons.co.uk>
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 221093A0D6F for <v6ops@ietfa.amsl.com>; Tue, 22 Mar 2022 10:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 OMgu_A3PX03q for <v6ops@ietfa.amsl.com>; Tue, 22 Mar 2022 10:47:40 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0853A0D6C for <v6ops@ietf.org>; Tue, 22 Mar 2022 10:47:39 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from smtpclient.apple (MacBook-Pro.thehobsons.co.uk [192.168.137.121]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 890701A021 for <v6ops@ietf.org>; Tue, 22 Mar 2022 17:47:34 +0000 (UTC)
From: Simon <linux@thehobsons.co.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Tue, 22 Mar 2022 17:47:32 +0000
References: <52661a3d-75dc-111a-3f23-09b10d7cb8d4@gmail.com> <A72CDDDB-CDCE-4EAF-B95E-997C764DB2C4@gmail.com> <9175dc32-45c1-e948-c20a-3bcc958b77b9@gmail.com>
To: v6ops@ietf.org
In-Reply-To: <9175dc32-45c1-e948-c20a-3bcc958b77b9@gmail.com>
Message-Id: <A4DDC829-A355-43A0-82FD-0480C2AFC3BA@thehobsons.co.uk>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/YeS6HLphUT1Px69nDvctGYLcxjo>
Subject: Re: [v6ops] Thoughts about wider operational input
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 22 Mar 2022 17:47:45 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> As has been said, in different words, many times on The Register forums. I think there are several IPv6ists who respond there, under various pseudonyms. (The Register is not a place where many people care to use real names.)
> 
> But unfortunately the usual reply is to repeat that we were idiots not to make IPv6 backwards-compatible (often accompanied by one of the many ideas proposed but found impossible in the early 1990s). Either that, or a plaintive "too hard" argument.

I’m one of those IPv6 supporters (under my real name !) - and often get the usual responses. Funnily enough, every time I’ve challenged someone to state how they would add address bits to IPv4 without breaking compatibility with *everything*, I never get an answer though I generally get a load of downvotes !
I also get plenty of responses (and downvotes) telling me I’m wrong and that NAT doesn’t break anything at all.



Gert Doering <gert@space.net> wrote:

> The reason why I prefer "host has multiple GUAs" better, in theory, is
> that it gives the *user* more control on what he wants - like, "I can
> run my bittorrent via the cable ISP, and SSH out via LTE", by selecting
> the corresponding source IP = selecting the outgoing ISP.

Flipping that around, what if there are good business reasons to route certain traffic via certain routes ? Users will always pick what “works best for them” and ignore any instructions they are given - and not to mention most IoT stuff probably won’t even offer any options in that regard.
One upside (and I think it’s the only upside) of NAT is that the network admin can set the policy of which traffic uses which link - so, for example, routing some traffic via a fast link and other traffic via a cheap link; or just routing certain traffic via one link to avoid contention with other traffic (a common way to make VoIP work reliably in the presence of not-unlimited-bandwidth links).
That’s not to say I’m any fan of NAT - but IMO that is one area where it does actually have a benefit.



Gert Doering <gert@space.net> wrote:

> Apps today are "https to cloud" anyway, which is very NAT friendly.


Which as Jordi points out, is a big problem.
Apart from the “vendor has turned off the infrastructure, you now own a pile of door stops” issue (ask Revolv owners how that works out), it’s putting the internet under the control of fewer and fewer larger and larger organisations. We’re already a long way down the road to never actually owning anything we’ve bought, and that’s a bad thing.

But IMO one of the big reasons why users have accepted it without question is that there are too many roadblocks (configuring NAT being one of them) for the average users to do some of the remote access stuff that the IoT stuff is bought for.

I doubt that anyone other than niche vendors are going to do anything that reduces vendor control - or worse, allow a user to decide for themselves how something should work and be used.

Simon