Re: [v6ops] Vicious circle [ULA precedence [Thoughts about wider operational input]]

David Farmer <farmer@umn.edu> Fri, 29 April 2022 14:16 UTC

Return-Path: <farmer@umn.edu>
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 EFED7C15E406 for <v6ops@ietfa.amsl.com>; Fri, 29 Apr 2022 07:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=umn.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsEClO7EhQBl for <v6ops@ietfa.amsl.com>; Fri, 29 Apr 2022 07:16:01 -0700 (PDT)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B726AC157B55 for <v6ops@ietf.org>; Fri, 29 Apr 2022 07:16:01 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 4KqZKD3wnZz9vKN3 for <v6ops@ietf.org>; Fri, 29 Apr 2022 14:16:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coSJijpWcMNG for <v6ops@ietf.org>; Fri, 29 Apr 2022 09:16:00 -0500 (CDT)
Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 4KqZKD0n6Vz9vKMl for <v6ops@ietf.org>; Fri, 29 Apr 2022 09:15:59 -0500 (CDT)
DMARC-Filter: OpenDMARC Filter v1.3.2 mta-p8.oit.umn.edu 4KqZKD0n6Vz9vKMl
DKIM-Filter: OpenDKIM Filter v2.11.0 mta-p8.oit.umn.edu 4KqZKD0n6Vz9vKMl
Received: by mail-ed1-f71.google.com with SMTP id ee56-20020a056402293800b00425b0f5b9c6so4565487edb.9 for <v6ops@ietf.org>; Fri, 29 Apr 2022 07:15:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zn9v9ZrLLHPTIddYOxVTPD0be/NqfaQ2p/FPSfW5w3o=; b=S0mYARmfSLkIv7AzZJpjl2U7n27Lqorg+R70hL/Oh3S94wPuaFfBebkOs+z4aem/ld Q0OQKYYkroOskZXI9amr7BGTBinEN9R0pp5wl651bSnyO601iSjZE60HslcD+v02dEHr +WUaC55tCHAJ9K4X3NQkKV+qjov2CYqm5taLZDRNSyPmTPx1yX2kHqY0WYhbBuF0bWpv TzdSe4zypdsA+rsfLJBpQjVbm2zf5CLy6ask6vvR6wMiC5WSNA8laEV7OqgBYy1ksDEF KCPGXfhYH2usTGlDmyxzJsbuFjE7DYdQoaB8TuyBTSWMb5VEs1WdDgzy2Cvz77EUasL/ N9jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zn9v9ZrLLHPTIddYOxVTPD0be/NqfaQ2p/FPSfW5w3o=; b=IqgxmM1rW3mW8kGN9NXuiCWCgf0m6Lfto1uCTThmJvko28GFzoKa/Oo7LCxH3J11D9 YbyML2AS0AAgrJh0JsYvb1GDrHnMGn3llPEyGHNs3Rv9QmOYVUdGuWGuI/bfyBTeTWLZ tBLOyPvsawzgB1UK2t8rj5hcq+foARKLONnnDAeRrASWoAu7JoEKVWhsW0X0hmVxWaeb bsOOqXIrMMcPzJVdJitJTC9uraRYJl28beUB4NqgF9nmhrfFW+eE0UTZwy0VIvTlZB9N 0dnz02YzFAJ6W9YW/442MUuEBGPFRtG5sKlHwr+5TQo0huaESdRwYB7PYYaOmWhOy0/+ +VTQ==
X-Gm-Message-State: AOAM531zg4aN1ZHHNHEDfW1yvnX8PlNRekM+Y3wasc8SRKgwzqgoNUcB ojjSWI4r/RX97P8Kh8X7XsuzUPCCJ0grj//ZsaLklw0z9Y3jViARkKsPLI3xmsqrdxBj0K9o+/4 rNs4hxUP5Iv34W3NvCBvjJaekDQ==
X-Received: by 2002:a05:6402:128b:b0:425:d1d7:b321 with SMTP id w11-20020a056402128b00b00425d1d7b321mr34600681edv.179.1651241757779; Fri, 29 Apr 2022 07:15:57 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJxFvB3qxo4RI7qoknguIEpDV3dE2H3VtU+UlJCu7WqyIo6ynI6jXYFGnhD86PqkluOk7x7jrVgMr8KUAW6E27s=
X-Received: by 2002:a05:6402:128b:b0:425:d1d7:b321 with SMTP id w11-20020a056402128b00b00425d1d7b321mr34600648edv.179.1651241757413; Fri, 29 Apr 2022 07:15:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAM5+tA8WvjvWirxqE6kQ9LQAG0NcpWyCLGVooB=G7gZ9ETb2zQ@mail.gmail.com> <20220424172743.GA218999@fg-networking.de> <CAKD1Yr1v0Tkh+pWD-ts=PL3gZf7Qj6OHW6Cuvj8iGcSSMibjew@mail.gmail.com> <0afe25f5-52b7-a438-0696-cf8b0a83c2dc@gmail.com> <BN8PR07MB70760D9693580F5BDCB61DD995F89@BN8PR07MB7076.namprd07.prod.outlook.com> <CAKD1Yr3Z9wGQ+uiA2WcW00MrOiLyHs+bSoFjHVtrixCi2qp4DA@mail.gmail.com> <BN8PR07MB7076A6456CAB48EF428D6E8695F89@BN8PR07MB7076.namprd07.prod.outlook.com> <65d0d9ac-77fc-c200-09e3-0c3949ca1541@gmail.com> <CAN-Dau2FS99ewfgH8xk-jSJFCnO92CJV9ZC98DUE2UDR7V1Eww@mail.gmail.com> <CANMZLAYbpZBDA8uFnJqfWfWTQ4S9RN4a-DqWe36qzfAfDtXiQA@mail.gmail.com> <CAN-Dau0BjRR2_7xz38DpJsz0Y=Z_8bV5n-=Eh1QUVEDzqVxmaA@mail.gmail.com> <CAPt1N1=H=eAyRu0JcHnLpZEUizDZ4Kj0VwPu=0nM=Wn+y3Ho1w@mail.gmail.com> <CAM5+tA_4rtSkgEuRUFZ2LYr6i8a7vWeKODYieVARF3RbRvgRww@mail.gmail.com> <BN8PR07MB7076DE3E745CB916FB81879595FA9@BN8PR07MB7076.namprd07.prod.outlook.com> <ADAE42CE-448F-42F5-89BE-692F493E2DC8@consulintel.es> <CAM5+tA_ksJ+agY1tze1-zPHLsgYFgjEYtnuPs+ffZbnRqiHytw@mail.gmail.com> <BAD082DA-0958-4926-B3E5-4E4599A75078@consulintel.es> <BN8PR07MB7076564E50C0DAFBFAB950FD95FA9@BN8PR07MB7076.namprd07.prod.outlook.com> <CAPt1N1ncVkekecS=dBHSR3WtaEMruy55Udxy0WSMGTgbN24pKw@mail.gmail.com> <CAM5+tA8-Zqka-vZ9jRL3wn0dtfuJj0ECx_k9prwyS2ypisaPtw@mail.gmail.com> <FB031B76-7E88-4824-876F-D1A05F8D2215@thehobsons.co.uk> <CAFU7BAST-oNGpy4JvODDsf=8eS69hV8XCi8OgEHBkkoujRN3Rw@mail.gmail.com> <699f556a3eac41179a80d2cc8749a191@huawei.com> <CAO42Z2wiebCOPmtcEOJ3rOaZEpHE7qFZZTf5KLWybSsL6rOd9Q@mail.gmail.com>
In-Reply-To: <CAO42Z2wiebCOPmtcEOJ3rOaZEpHE7qFZZTf5KLWybSsL6rOd9Q@mail.gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Fri, 29 Apr 2022 09:15:41 -0500
Message-ID: <CAN-Dau1FV-uEkX1S7vOEVxggjcNvUVTmokPAEOiapxPTySN-vw@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org>, 6man list <ipv6@ietf.org>, v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000063aad905ddcbae0c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ThkzJmkRgjVrg81ukslmhGjtTxM>
Subject: Re: [v6ops] Vicious circle [ULA precedence [Thoughts about wider operational input]]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.34
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: Fri, 29 Apr 2022 14:16:06 -0000

On Thu, Apr 28, 2022 at 6:02 PM Mark Smith <markzzzsmith@gmail.com> wrote:

> On Fri, 29 Apr 2022 at 07:37, Xipengxiao
> <xipengxiao=40huawei.com@dmarc.ietf.org> wrote:
>
> > My point is, given PCI DSS 4.0 (what Jen wrote as PCR DSS 4.0), we
> should tell enterprises they no longer need NAT. But if some enterprises
> still insist, respect their decision.
>
> Ignore them. IPv6 doesn't solve any problem they have, and adding NAT
> to IPv6 still won't solve any problem they have, because IPv6 still
> won't solve a problem they have.
>
> ...
>
> Even government mandates to get enterprises to adopt a networking
> protocol don't work - the Internet is supposed to be running CLNS by
> now as mandated by governments around the world. (I expect Vint Cerf
> was being nice while working on this rather than truly believing OSI
> would take over.)
>
> Explaining the Role of GOSIP
> https://www.rfc-editor.org/rfc/rfc1169.html
>
>
>  It's more important to get enterprises to use IPv6 ASAP, than to
> insist that they use the "right" IPv6 solution.
> >
>
> Why is it important to get enterprises to use IPv6 ASAP?
>
>
> Regards,
> Mark.
>

Ignore credit cards and enterprises, that's your advice for IPv6?

So, no one using IPv6 wants to get paid for anything? Or, are you
suggesting we maintain a quaint IPv4 network in the corner, so we can do
credit cards and can get paid?

As for enterprises, Google and AWS are enterprises, are you suggesting they
should be ignored too? Most of the valuable things on the Internet are run
by enterprises.

Supporters of IPv6 need to very much care about enterprises; We need them
to make their content available via IPv6. We need them to enable IPv6 on
the Internet-facing parts of their networks.

Do we need them to enable IPv6 on their internal networks, maybe or maybe
not. However, if enterprises are not comfortable with IPv6 why would they
enable their content over IPv6?

I'm not suggesting we have to do NAT66 or even NPTv6, however, I think we
should have something to tell those doing NAT44 today and want to maintain
an internal private network. Maybe ULA with application gateways and
proxies instead of NAT. But I don't think the internal private network
model is just going to go away, too many people are comfortable with it.

Furthermore, ignoring NAT44 from a standardization point of view worked so
well the last time. "Ignore them, and they will go away," didn't work last
time and it's not going to work this time either.

Thanks


-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================