Re: [v6ops] Thoughts about wider operational input

otroan@employees.org Thu, 31 March 2022 21:43 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 2A0F13A15E8 for <v6ops@ietfa.amsl.com>; Thu, 31 Mar 2022 14:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 FiZnewZdWoPA for <v6ops@ietfa.amsl.com>; Thu, 31 Mar 2022 14:43:36 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6FC3A15CC for <v6ops@ietf.org>; Thu, 31 Mar 2022 14:43:36 -0700 (PDT)
Received: from astfgl.hanazo.no (ti0389q160-1689.bb.online.no [212.251.183.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id A06E64E11ADA; Thu, 31 Mar 2022 21:43:35 +0000 (UTC)
Received: from smtpclient.apple (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id D8D2A6FAD563; Thu, 31 Mar 2022 23:43:32 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: otroan@employees.org
In-Reply-To: <67762447-43D4-4393-851C-99370D3BF623@thehobsons.co.uk>
Date: Thu, 31 Mar 2022 23:43:32 +0200
Cc: v6ops list <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F3E4570-1A67-45F9-9D86-CA73016815D8@employees.org>
References: <52661a3d-75dc-111a-3f23-09b10d7cb8d4@gmail.com> <A72CDDDB-CDCE-4EAF-B95E-997C764DB2C4@gmail.com> <9175dc32-45c1-e948-c20a-3bcc958b77b9@gmail.com> <YjmJQMNgnJoSInUw@Space.Net> <D75EF08F-6A41-41B2-AFB2-649CBCC1D83E@consulintel.es> <CAPt1N1nRnYUFA=yyJHx6t52yqWbmcd2Tf1H8gQuCZBd3Q3VqJw@mail.gmail.com> <7F4AEB43-4B24-4A21-AE9D-3EB512B98C46@consulintel.es> <8fac4314b8244ba6b33eea68694296d0@huawei.com> <9A13E47B-75D0-443F-9EE9-D2917ACB2D0F@consulintel.es> <CAO42Z2xUG+BXj+VQpajed9aGjH+q-HR7RX7C-T4DsTbouz7xWQ@mail.gmail.com> <F6A90BBF-7F44-403E-960A-8F756353B562@chinatelecom.cn> <B49417F7-3EFB-4A4D-9D1A-0D21574EA4F2@consulintel.es> <44B01ACA-3D5C-4618-B608-3B3479D29875@consulintel.es> <62447DCB.1010206@jmaimon.com> <7228D9A7-54A8-4BAE-9299-204C049F600B@consulintel.es> <6244BA91.3060306@jmaimon.com> <67762447-43D4-4393-851C-99370D3BF623@thehobsons.co.uk>
To: Simon <linux@thehobsons.co.uk>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/xItntm9oQGN6xygNbPWZaU39lQY>
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: Thu, 31 Mar 2022 21:43:43 -0000

> ONLY if you start from the premise that NAT is not in fundamental conflict with IP basics - namely that “packets can be routed from any end point to any other end point” (with the modern security proviso of “subject to administrative policies”.)
> In any case, I’m used to configuring a firewall anyway. Most CE devices come with a stateful firewall installed and configured - most of them even with sensible defaults !

My views on this has evolved over the last couple of decades.
I have come to believe that freedom to rewrite the locator at various network edges is an important property of IP.
NAT is a somewhat unfortunate implementation of a locator / identifier split. But we have tried many others 8+8, LISP, ILNP...
The need for protecting your network against global address changes in smaller networks, or providing a service abstraction (VIP) in DCs. Or making your network appear like a host for permissionless extensions of the network are valid use cases, regardless of version of the IP protocol.

O.