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

Ted Lemon <mellon@fugue.com> Fri, 29 April 2022 14:37 UTC

Return-Path: <mellon@fugue.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 261A3C15E6D6 for <v6ops@ietfa.amsl.com>; Fri, 29 Apr 2022 07:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.com
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 8boGTd_eTWOM for <v6ops@ietfa.amsl.com>; Fri, 29 Apr 2022 07:37:21 -0700 (PDT)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449B6C15EB33 for <v6ops@ietf.org>; Fri, 29 Apr 2022 07:37:09 -0700 (PDT)
Received: by mail-oi1-x234.google.com with SMTP id z8so8723602oix.3 for <v6ops@ietf.org>; Fri, 29 Apr 2022 07:37:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=93uXkThLBxlsGdp+Ey9mdDSdFHVDjX3MLnWYOBerrq0=; b=KQNUrT2SdixWfXjr0bGveiLZUG/sI6so0OtBLqMEDVvHtuwzIa8u0DjNRdd9h5v2w7 pH/fRbL8qDAdJP9dSOkH3mc2ndfN6g3DMcUl8ARwTDWxAgtA6BouoCatANbW6KVlkBUg YFyb1tRc8ffhgH8Ld9t5mWG8euinCgnYolpRQ5bVToCncDYZVP+QXiSKBsNKMASDkEEU 3pMt1U8B8YG8pG0XWcMVfZhF2s8kjQ/6M60eeHOwV/ot63E4Zd37PakuVWtnjXvzgTgb XStTnDBFauXa8aJbPqVIm+UFTGQzrC6V4fj3DIn2yWhx/DCTQoqljkhO8Qfx6rOLKfti Fxlw==
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=93uXkThLBxlsGdp+Ey9mdDSdFHVDjX3MLnWYOBerrq0=; b=2ujEADJqwLUurLujj22mYi76ItBVLlg/pDehUk/D8OtOvnSpvRi1TYZdAgZB33Dhq0 AhlzXi1slcDbS6LRteOBlxaSgN6BYa0R3eBcbxRgIgDAH1iF8A04ByYYGrzJAxPa+5pG w2Wd6UoPklNfCCyz9NMvX7VhBCzGNMZ51BasX2+uTY841Em8FCupf54XIkN39Q681UtA /wzqLPZqNSjtqZ/C56SMoncIZl+dPjZcmCv4x6dwKgBIFX8m3ppVLC10H9MSadD/p2q2 gC/0a3hG2ybv8ld+TtivUvnCFSjnf+l1DN/KIJe9WpI+pD7cA9ZziRkTERWctWW7ce0I e3fg==
X-Gm-Message-State: AOAM532KatUxx4Ravz+J0p5r9Ke2hHT7Xz73f3DoWRD+horgWJb98a9o qYzzCc+Wi7cscy4q5W/dSwLF2q9xiHqAgRpBT4FZOA==
X-Google-Smtp-Source: ABdhPJwoF4FwWWfsSv0KE2ktGJvlqq8bgA4ADDfMy9TzkjXdZAQAMGQMqvc300kvo7+eoO9gnv53SXmAz+C0KTmeNiM=
X-Received: by 2002:a05:6808:2129:b0:322:6501:49ea with SMTP id r41-20020a056808212900b00322650149eamr1548529oiw.209.1651243027981; Fri, 29 Apr 2022 07:37:07 -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> <CAN-Dau1FV-uEkX1S7vOEVxggjcNvUVTmokPAEOiapxPTySN-vw@mail.gmail.com>
In-Reply-To: <CAN-Dau1FV-uEkX1S7vOEVxggjcNvUVTmokPAEOiapxPTySN-vw@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 29 Apr 2022 10:36:56 -0400
Message-ID: <CAPt1N1mk8Qv1anXohCJaiH0WWn-BkS4mr=ffyF0cCaE7CM314w@mail.gmail.com>
To: David Farmer <farmer=40umn.edu@dmarc.ietf.org>
Cc: 6man list <ipv6@ietf.org>, Mark Smith <markzzzsmith@gmail.com>, Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org>, v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001efd1805ddcbfaba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/RvFrVx0_gdw3cL3F6NBbFjYbZEA>
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:37:25 -0000

The difference is that NAT44 made things better. NAT66 arguably doesn’t.
Pretty clearly there is a better alternative for the specific pci case
we’ve been discussing.

This doesn’t mean people won’t do nat66 out of habit anyway, but it will
cost extra and add no value, so I don’t see any reason why it would become
and remain a best practice.

On Fri, Apr 29, 2022 at 10:16 David Farmer <farmer=40umn.edu@dmarc.ietf.org>
wrote:

>
>
> 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
> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>       Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>