Re: [v6ops] Thoughts about wider operational input

Mark Smith <markzzzsmith@gmail.com> Sat, 02 April 2022 04:48 UTC

Return-Path: <markzzzsmith@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 7E7453A18F1 for <v6ops@ietfa.amsl.com>; Fri, 1 Apr 2022 21:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.389
X-Spam-Level:
X-Spam-Status: No, score=0.389 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.998, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 71-UyJ9LOzYU for <v6ops@ietfa.amsl.com>; Fri, 1 Apr 2022 21:48:22 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 B87743A118D for <v6ops@ietf.org>; Fri, 1 Apr 2022 21:48:22 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id j8so4062600pll.11 for <v6ops@ietf.org>; Fri, 01 Apr 2022 21:48:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z0k0dErRlEcEb87vaTxmMb+gVfftR7YgDYcvjo2T24A=; b=YKm0ANMXuHiZ0O7hc+Keta/gz1Mh3FOaIEj+7O7tW/v14CoRnjfO3EKwhk78C34sh2 2VOFy7Z2ZXNwvI5cU90uZt9IGInMX00ifot+2K++ZqPsYaUwJ2Ty2lE4ODP7LHanWSGD KztCIMeOwQSGGVBHh3EdeKY5gAPMcZKHedgLFZ2njvC53kiz2N3oYdistIVIcGy1v0Bw Ss6iYDCSuQsX3pACDPG2qgPOawi9p5Li4jQ0QiF7a4FgRw6RzKg/dU7fLBRb6rf2nW3f ooit/9+6qoRbNC9uqTUWr2hUWJum6/rTakYfYO09uygmdFMG5CGL/ZjVAfQo95/9MhOo MpAw==
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=Z0k0dErRlEcEb87vaTxmMb+gVfftR7YgDYcvjo2T24A=; b=MUHI3VR5TMpPunGHbJdgR/aeNtJ/Rh/BsmDVLSptQD2pV1ALSNOWe59QAikXSdnoxB qGfSc3SZBfAfyi38CfETpedkdKl5j4bMKHE84iE8fxWmgA/EpzUm7vpzWYJswkECeQ0O +BbjuOiqh71n1dB/Xej7DY612ejVHkxs/Fd1iO877/xS+brhtUlgyaYsxFYUM6oDeySk /cBe/oVTtEIg+AOYUWorCJJn6lHQSdfV6tW2SzqhccDL/m0VOnHLXJInwEl+Jr46yCOh Pq5T/Amx0366ku+CXrTWAlS0915x2RgdIpplNHkuDtdsROOSh9okLpipZPXT7HPAbTdN HY8g==
X-Gm-Message-State: AOAM530KC7sFdqH9EzhnlLNSGUz4GDwrAPz+zcTrpQg3QNl9phnVgqLM LlDO7evIIChmXJEHZkC+/c8c5aUlG+6TRF+CUTNjD2l7
X-Google-Smtp-Source: ABdhPJwN3kYYcN429aWNvPRhwMMJ6whM+/VE276mRKBjQ5JhfO/15eF6OwxgsLY1AgAOsHjn6pydGGDRiszqL3/8lls=
X-Received: by 2002:a17:90a:4749:b0:1be:ea64:4348 with SMTP id y9-20020a17090a474900b001beea644348mr15400791pjg.231.1648874901289; Fri, 01 Apr 2022 21:48:21 -0700 (PDT)
MIME-Version: 1.0
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> <4a9981c11c48425b92a6afa9bce992e8@huawei.com>
In-Reply-To: <4a9981c11c48425b92a6afa9bce992e8@huawei.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 02 Apr 2022 15:47:53 +1100
Message-ID: <CAO42Z2zpNunW=Chou+QDvOxd94r7WPqCdUg-3cODs9OCbiuGMg@mail.gmail.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c53ce605dba49ab5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/w1ezQXyWQwdXNRt91y2u-wbLZGo>
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: Sat, 02 Apr 2022 04:48:28 -0000

Hi Eduard,

On Thu, 31 Mar 2022, 00:36 Vasilenko Eduard, <vasilenko.eduard@huawei.com>
wrote:

> Hi Mark,
>
> NPT+ULA are much better than NAPT44 (no port translation), but not ideal
> (applications may encode address too).
>
> The problem is that Business (from small to big) needs Carrier’s redundancy
>
It is mandatory and NAPT44 is the solution for it now.
>
> The “normal” solution needs heavy modification in “Default address
> Selection”, “ND”, prefix distribution (HNCP?),
>
> That is nobody interesting to push.
>
> Hence, NPT is the only alternative. That would be greatly welcomed by
> Businesses that are comfortable with NAT.
>

None of this is going to change IPv6 adoption.

Imagine a company that makes golf balls. Imagine that it would take say $20
000 of staff time to deploy IPv6+NPT (ignoring and assuming there aren't
network equipment IPv6 upgrade costs).

How would having spent that $20 000 on IPv6+NPT (or just IPv6 without NPT)
made or saved the company money? How would it have made golf balls cheaper
to make, or how would have it increased sales of golf balls if there was
unsatisfied golf ball demand?

Now do the same "how does IPv6 save or make money for my business" for any
other type of business.

Even ISPs that deploy IPv6 are doing it for business and financial reasons.
The two first hand instances I have experience with are (a) for marketing
reasons around 10 years ago, because the company liked to consider itself a
technology leader and (b) to save IPv4 CGNAT costs.


Regards,
Mark.



> Eduard
>
> *From:* v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Mark Smith
> *Sent:* Wednesday, March 30, 2022 6:22 AM
> *To:* JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
> *Cc:* v6ops list <v6ops@ietf.org>
> *Subject:* Re: [v6ops] Thoughts about wider operational input
>
>
>
>
>
> On Wed, 23 Mar 2022, 01:55 JORDI PALET MARTINEZ, <jordi.palet=
> 40consulintel.es@dmarc.ietf.org> wrote:
>
> Hi Eduard,
>
>
>
> What I meant is that I will like to avoid the issues that NAT creates for
> apps. We must aim for something better.
>
>
>
> This.
>
>
>
> IPv6+NAT creates a lot of the issues that IPv4+NAT does, so why bother
> deploying IPv6 when you've already got the equivalent via IPv4 today?
>
>
>
>
>
> People need to understand why enterprises go to the expense of deploying
> technologies.
>
>
>
> Technology is a means to an end, not the end itself. Technology in
> business either saves money or makes money for the business.
>
>
>
> Enterprises in the 1990s didn't really deploy IPv4, they deployed global
> email and WWW access. Deploying IPv4 was the means to reaching those ends,
> because IPv4 underpinned them.
>
>
>
>
>
> So the questions to think about in the context of businesses and
> enterprises and IPv6 are:
>
>
>
> - What business problem does or can IPv6 solve better than existing IPv4?
>
>
>
> - IPv6 is the technology means to an end, so what is or are the ends that
> are of value to a business, where IPv6 is the better underpinning
> technology than IPv4 to reach those ends?
>
>
>
> - How can deploying IPv6 save or make money for a business?
>
>
>
> Regards,
>
> Mark.
>
>
>
>
>
>
>
>
>
> On the other side, using an experimental protocol for production networks,
> in my opinion is a big “NO”.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 22/3/22, 13:04, "v6ops en nombre de Vasilenko Eduard" <
> v6ops-bounces@ietf.org en nombre de vasilenko.eduard=
> 40huawei.com@dmarc.ietf.org> escribió:
>
>
>
> Hi Jordi,
>
>
>
> I understand the desire to fix broken things. (I doubt it is possible)
>
> But why NPT+ULA is not enough for MHMP now?
>
> It is very similar to what Enterprises and small businesses have now.
>
> They would be happy.
>
>
>
> Eduard
>
> *From:* v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *JORDI PALET
> MARTINEZ
> *Sent:* Tuesday, March 22, 2022 12:34 PM
> *To:* v6ops@ietf.org
> *Subject:* Re: [v6ops] Thoughts about wider operational input
>
>
>
> You’re right. Let’s say it in a different way, as may be my first email
> was not clear on this.
>
>
>
> 1.      I don’t think we want again to repeat the NAT problems, so NPT is
> not a valid solution for me.
>
> 2.      I think in the future almost every site could want to be
> multihomed, in some cases “n” links active, many other cases just as a
> backup.
>
> 3.      This means that renumbering is not (probably) a valid choice in
> any cases.
>
> 4.      Can we make PI work in such “huge scale” scenario?
>
> 5.      Can source-address forwarding work and solve all that, or we need
> that and/or something else.
>
>
>
> Only if we solve this, organizations could learn that NAT with IPv6 is not
> the solution, but something better that provides the same results, and no
> need to have “private” addresses, because the way NAT is offering a
> “different” addressing inside and outside is not NAT per-se, but statefull
> firewalling.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 22/3/22, 10:27, "v6ops en nombre de Ted Lemon" <v6ops-bounces@ietf.org
> en nombre de mellon@fugue.com> escribió:
>
>
>
> Is it really hncp that we needed here?  I think the key tech we need is
> source-address-based forwarding, and babel i think has delivered that.
> Granted, getting that into soho routers is a problem.
>
>
>
> On Tue, Mar 22, 2022 at 10:11 JORDI PALET MARTINEZ <jordi.palet=
> 40consulintel.es@dmarc.ietf.org> wrote:
>
> Maybe the terminology is not the most appropriate and we should talk about
> "organizations", because there are many types of networks that have the
> same problem and those are not enterprises (such as government sites, NGOs,
> etc.).
>
> The problem is the same regardless of the "size" of the organization. The
> difference is that "today" most SMEs don't have that problem because they
> don't have PI, but it may turn the same when they realize that not being PI
> have renumbering issues if changing the ISP. Of course, again, if we talk
> about a "small" SME, then may not be an issue, they only have 40 or 50
> devices to renumber (your mileage will vary), not easy but not "terrible".
>
> On the rest of Gert comments, definitively I agree, and specially on our
> big mistake not working further on HNCP.
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 22/3/22, 9:31, "v6ops en nombre de Gert Doering" <
> v6ops-bounces@ietf.org en nombre de gert@space.net> escribió:
>
>     Hi,
>
>     On Tue, Mar 22, 2022 at 11:42:12AM +1300, Brian E Carpenter wrote:
>     > I agree with Jordi that multihoming is a genuine impediment. What
> isn't generally realised is that it's a problem of scale when considering
> at least 10,000,000 enterprises, much more than it's a problem of IPv6
> itself.
>
>     What is "an enterprise"?
>
>     My stance on this is that for "largely unmanaged SoHo networks" - which
>     could be called "small enterprise" - dual-enduser-ISP with dual-/48 or
>     NPT66 gets the job done in an easy and scalable way (HNCP would have
>     been great, but IETF politics killed it).
>
>     "Enterprise that truly need their own independent fully managed network
>     with multiple ISP uplinks and fully routed independent address space"
>     are probably way less than 10 million...
>
>     Half of them do not want Internet access anyway, just access to their
>     ALGs that will do the filtering and TLS inspection and everything, and
>     then out to the Internet as a new TCP session (= could be done with
>     DMZ islands of upstream-provider-allocated space just fine).
>
>
>     We need to work on our marketing regarding multihoming.  "What is it
> that
>     you get, what is the cost, which of the variants do you want, and
> why...?"
>
>     Gert Doering
>             -- NetMaster
>     --
>     have you enabled IPv6 on something today...?
>
>     SpaceNet AG                      Vorstand: Sebastian v. Bomhard,
> Michael Emmer
>     Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A.
> Grundner-Culemann
>     D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
>     Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
>
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>