Re: [v6ops] Thoughts about wider operational input

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 30 March 2022 04:23 UTC

Return-Path: <brian.e.carpenter@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 93D303A085B for <v6ops@ietfa.amsl.com>; Tue, 29 Mar 2022 21:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 pEAyvznch_xl for <v6ops@ietfa.amsl.com>; Tue, 29 Mar 2022 21:23:54 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 40AD33A0817 for <v6ops@ietf.org>; Tue, 29 Mar 2022 21:23:54 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id b130so15146086pga.13 for <v6ops@ietf.org>; Tue, 29 Mar 2022 21:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3hz6bevggQZOF0NA423g3/DM60+gWX62948USMHPaAw=; b=mtJQsRkHykVgpRKtgzq+KJasERh+WWCr9J9PkVTXkUvmzzJoWG0tC40bG8cNl6Mn0D EsekFK5Vlbi2PUdjNuBdhu0wZP3UkS4a24BvufCoEk9P3ffO7AdkgY3zPPkniTIHy0PX OSAGq4y/WSXAR1cXt5/qLpdJiPHaUImfXK6+LQu1zlpQ4QCPnjIxwNibForGhfJtTWkE +PPgBww9iNYiKE/OakOXJtMlBuDR8aDR28yN5Mmwlx5RPqEL1hW6n5/fb1c38qZn2Fz7 4ix+Squo8nns6M//9lVk8WLgZzugkBHza0hz4I8hPHeliPoPTHciU/fRV5LkrHvpb7kh D/tA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3hz6bevggQZOF0NA423g3/DM60+gWX62948USMHPaAw=; b=i1hCUP96LqRLiwmrQutNsDeROeBfPfIUP0kzxWM1YbIzJkGGudz2hPE+WS1tumopoG 501WbeqtLta7FcsgkalMkHl/RJJqslcAQcd0IIjOz+5cQSGw5Si2v4MbOY6S59qXFskE 2TATkqf6Z1BbZfUI8LqXvgHR9IssvwnNaQSLliKqgyuxQqrkhnUFWgm/DVDBliMYWPAL J3V7qTM/6ejDTPH3hf8gObnm61TP3vt4lcVA+tmEViFNykFa0WpD5/DJYLqpvEmwV/76 0xHqjoP1JeJ0PMVX+VaDWgcyVVUXSfsXS/oV1VnJH8tDCfl1JPXrMRXMHvkTSPqyHkw1 yLQw==
X-Gm-Message-State: AOAM5304sUlxi/FugsZ7yMQYum0yUPa8RVm4ONUt1qFsLONh5WBrb+ao i4+GeUMZhkIh9/L5zClKpTbcHnewf1VdHw==
X-Google-Smtp-Source: ABdhPJyrSQ42KV5eViWlIVa0h7N48NNSDeT2M+4522uZiKBPO7tfc79qhrLmQJrfZFodEap6Rq8VxQ==
X-Received: by 2002:a65:5083:0:b0:382:3b02:9799 with SMTP id r3-20020a655083000000b003823b029799mr4685984pgp.302.1648614233046; Tue, 29 Mar 2022 21:23:53 -0700 (PDT)
Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id e19-20020a637453000000b003821bdb8103sm17925595pgn.83.2022.03.29.21.23.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Mar 2022 21:23:52 -0700 (PDT)
To: "E. Marie Brierley" <ebrierley@saatvikadvisors.com>, Mark Smith <markzzzsmith@gmail.com>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Cc: v6ops list <v6ops@ietf.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> <db66fe14-4391-b3ca-2219-e435d7e9cb28@gmail.com> <CO6PR19MB54670882EC43B8FEB8BF5666BA1F9@CO6PR19MB5467.namprd19.prod.outlook.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <d1c5fd30-8ce4-b413-d4c7-60311eaafad8@gmail.com>
Date: Wed, 30 Mar 2022 17:23:47 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <CO6PR19MB54670882EC43B8FEB8BF5666BA1F9@CO6PR19MB5467.namprd19.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LeXaWf-YhEWwHCCmXbc1520e06k>
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: Wed, 30 Mar 2022 04:24:09 -0000

E. Marie,

I don't know how it can quantified; that might be an interesting research 
project.

I do see this (in a report from ~2015)[1]:
"Average Shopping Cart Abandonment Rate: BI Intelligence reports the average rate for ecommerce shopping cart abandonment across the globe is 71.2%."

A lot of that is of course users deciding not to buy. Does anybody know how to measure how much of it is due to session failure (per IP version)?

Regards
    Brian Carpenter

[1] https://guidingmetrics.com/content/ecommerce-industry-most-critical-metrics-kpis/

On 30-Mar-22 17:10, E. Marie Brierley wrote:
> Great point. If you can quantify that issue by some means, I can add it 
to my comms to digital marketers (along with geolocation deterioration). Cart conversion is extremely low <3%, so any factor that can be incrementally quantified and improved is welcome in that audience.
> 
> E. Marie
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* v6ops <v6ops-bounces@ietf.org> on behalf of Brian E Carpenter <brian.e.carpenter@gmail.com>
> *Sent:* Tuesday, March 29, 2022 9:06 PM
> *To:* Mark Smith <markzzzsmith@gmail.com>; JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
> *Cc:* v6ops list <v6ops@ietf.org>
> *Subject:* Re: [v6ops] Thoughts about wider operational input
>> - What business problem does or can IPv6 solve better than existing IPv4?
> 
> That suggests to me that an even earlier question is:
> 
>    - What business problems does IPv4 cause today?
> 
> For example, I'm convinced that multiple layers of NAT44 (today's reality) cause problems, whose symptoms are often (from the end user's view) failed sessions that have to be repeated. These are *never* reported to any help desk and so don't appear in anybody's statistics - but they do detract from user experience and so presumably have an impact: lost or delayed
> business.
> 
> Others have mentioned the OPEX cost of diagnosing NAT-induced problems even with the enterprise.
> 
> What else?
> 
> Regards
>      Brian Carpenter
> 
> On 30-Mar-22 16:22, Mark Smith wrote:
>> 
>> 
>> On Wed, 23 Mar 2022, 01:55 JORDI PALET MARTINEZ, <jordi.palet=40consulintel.es@dmarc.ietf.org <mailto:40consulintel.es@dmarc.ietf.org <mailto: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 <mailto:v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org>> en nombre de vasilenko.eduard=40huawei.com@dmarc.ietf.org <mailto:40huawei.com@dmarc.ietf.org <mailto: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 <mailto:v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org>>] *On Behalf 
Of *JORDI PALET MARTINEZ
>>     *Sent:* Tuesday, March 22, 2022 12:34 PM
>>     *To:* v6ops@ietf.org <mailto:v6ops@ietf.org <mailto: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 <mailto:v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org>> en nombre de mellon@fugue.com <mailto:mellon@fugue.com 
<mailto: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 <mailto:40consulintel.es@dmarc.ietf.org <mailto: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 <mailto:v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org>> en nombre de gert@space.net <mailto:gert@space.net <mailto: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 <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>>         https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> <https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>>
>> 
>> 
>> 
>>         **********************************************
>>         IPv4 is over
>>         Are you ready for the new Internet ?
>>         http://www.theipv6company.com <http://www.theipv6company.com> <http://www.theipv6company.com <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 <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>>         https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> <https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>>____
>> 
>>     _______________________________________________ v6ops mailing list v6ops@ietf.org <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> <https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>> ____
>> 
>> 
>>     **********************************************
>>     IPv4 is over
>>     Are you ready for the new Internet ?
>>     http://www.theipv6company.com <http://www.theipv6company.com> <http://www.theipv6company.com <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 <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> <https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>> ____
>> 
>> 
>>     **********************************************
>>     IPv4 is over
>>     Are you ready for the new Internet ?
>>     http://www.theipv6company.com <http://www.theipv6company.com> <http://www.theipv6company.com <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 <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>>     https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> <https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>>
>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>