Re: [v6ops] Thoughts about wider operational input

Nick Buraglio <buraglio@es.net> Tue, 22 March 2022 17:51 UTC

Return-Path: <buraglio@es.net>
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 8B21A3A0D78 for <v6ops@ietfa.amsl.com>; Tue, 22 Mar 2022 10:51: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, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=es.net
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 ksAYt6GFKVmu for <v6ops@ietfa.amsl.com>; Tue, 22 Mar 2022 10:51:54 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 E12B03A0D72 for <v6ops@ietf.org>; Tue, 22 Mar 2022 10:51:53 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id u3so25098541ljd.0 for <v6ops@ietf.org>; Tue, 22 Mar 2022 10:51:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=28N47K+pdMGPILUVoD4zSmNnuFevdeVVcEDBNfqossI=; b=L4ZBIZNuUrBwL7xsMJBSTNivtNu7mRZ1R5vn7a3vWaTxxL9Gx3nXN/pVxz2Kr6vE5e v+B5eehNVcJbTM8kgxTeF0T9awgnUTYlduCsoRbKfAakpp6lKpDAxLD7Efi0N9lRNksF nwiQWwuWl3UEC4lgL0gZ4GAnNToHW3eIfv61O0Z8mRD28Fi5xNvZslg3K56V6JRNATFS 2Ei1Vs1B4PEu5OrLHngGiEacwAcwuTgX7z0wO7KMIUZMHjrc9R/PpFo9sXOCWdH6bbL5 zk3uU4oU5adAz5brZr7LpuNp1Lldt0/ngpZLoqWePqQ0O4wbQc1PElHVtmfl15o3tccw R2dQ==
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:reply-to :from:date:message-id:subject:to:cc; bh=28N47K+pdMGPILUVoD4zSmNnuFevdeVVcEDBNfqossI=; b=01eDjegUoPt4scamBZecrs69/XSY5YRkruXGnzDl/AT9I5ZFtDdOvcjkLMvKAS/rcq 9dNzxxVCtQNnlATmR+3M6FnSbGKiQbjXM3TIDg0dzltcfMGVdMrkCRQu5ukIzSYBbqdG NC3cEjSDgVA783vZn3TMr1kH/stJwFTGB8xVPvzhwqWAOacJI8igYrU+rhCa5rG2Tqba 9DROkUqyYix/HZ7RWEgORoQnIlIrkKhJB+55oHGjAOOV90dtKZJEFyGEqf1geFvs/WEl Ee5FHeMo/xcb2CZBzkh5Aud0GdTx+eANlaZNN8knYd0MsNcoaiNXWngGj07IwgYhIpbr 9TGg==
X-Gm-Message-State: AOAM531Sdqm1nuqoc1C2/2kbEIgjNiRscqOk4iByvQMX1TR9NSm14uRj YbsnxTmOU9rXpCIaENZgd3bteZNO/nhGfEcvJTxAkMpNuKlrs38+xmF8Yi48cwJsnDi9fqhH8W/ uUzVJto8kBplBBvJVsdjdaVyh//XzuEYWMX5gD27E2CW6Fpn+/FC8rVsy28a6PkcLkp2Jzl6qLG E=
X-Google-Smtp-Source: ABdhPJw+sDeUfmo0T1Y8h1vanFWE1NxSMBPZL/NVqOGMPa8v8qNjz+PwjjLeYKYsNYuGsxZ4xvkKWAG39ME4PEVPiXg=
X-Received: by 2002:a05:651c:b11:b0:249:9504:e929 with SMTP id b17-20020a05651c0b1100b002499504e929mr2048324ljr.0.1647971511444; Tue, 22 Mar 2022 10:51:51 -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> <3773b73715be4145a67a7c2b3150afee@huawei.com> <C27958C6-557C-4FF6-90B2-0577BC81D5AE@consulintel.es> <0f7acf497f914e3683f6d38c1e8b65a0@huawei.com>
In-Reply-To: <0f7acf497f914e3683f6d38c1e8b65a0@huawei.com>
Reply-To: buraglio@es.net
From: Nick Buraglio <buraglio@es.net>
Date: Tue, 22 Mar 2022 12:51:39 -0500
Message-ID: <CAM5+tA8DVZUiNEn_0ADL3Qohncajen-xcR4+n+yTEDkKQFqgSQ@mail.gmail.com>
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
Cc: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008ab05d05dad2448a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/KprO71GsKuDtU3I8virVvjQZErY>
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: Tue, 22 Mar 2022 17:52:00 -0000

The issue with ULA + NPT is that if there is an A record, ULA + translation
will rarely if ever be used unless the application dictates it as the ULA
addressing is de-prioritized in nearly every operating system - but that's
a very specific technical implementation issue and I don't believe that it
is fundamental to the lack of enterprise deployment.

nb



On Tue, Mar 22, 2022 at 11:53 AM Vasilenko Eduard <vasilenko.eduard=
40huawei.com@dmarc.ietf.org> wrote:

> Experimental is just a label. Change it if it is the only problem.
>
>
>
> Yes, maybe some protocol would embed the IP address, extremely rare.
>
> UDP/TCP ports are not touched.
>
>
>
> NPT+ULA is “low hanging fruit” in business consultants' terminology.
>
> It does not preclude developing something better.
>
> Because as Gert said: it is better to have a policy on what Carrier to use
> for what type of traffic.
>
>
>
> *From:* v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *JORDI PALET
> MARTINEZ
> *Sent:* Tuesday, March 22, 2022 7:44 PM
> *To:* v6ops@ietf.org
> *Subject:* Re: [v6ops] Thoughts about wider operational input
>
>
>
> I don’t think app developers will agree with you.
>
>
>
> I will re-read anyway NPT RFC, I recall it has a specific warning section
> on that … and anyway, it is an experimental protocol.
>
>
>
>
>
>
>
> Saludos,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 22/3/22, 17:37, "v6ops en nombre de Vasilenko Eduard" <
> v6ops-bounces@ietf.org en nombre de vasilenko.eduard=
> 40huawei.com@dmarc.ietf.org> escribió:
>
>
>
> Hi Jordi,
>
> NPT is not NAT – it is not a so big problem for applications (stateless,
> even connection could be initiated 2 way).
>
> Meanwhile, it is possible to think about a better solution.
>
> Eduard
>
> *From:* v6ops [mailto:v6ops-bounces@ietf.org <v6ops-bounces@ietf.org>] *On
> Behalf Of *JORDI PALET MARTINEZ
> *Sent:* Tuesday, March 22, 2022 5:55 PM
> *To:* v6ops@ietf.org
> *Subject:* Re: [v6ops] Thoughts about wider operational input
>
>
>
> 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.
>
>
>
> 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 <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
>
>
> **********************************************
> 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
>