Re: [v6ops] Thoughts about wider operational input

Ted Lemon <mellon@fugue.com> Tue, 22 March 2022 20:21 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 AC3F33A0E79 for <v6ops@ietfa.amsl.com>; Tue, 22 Mar 2022 13:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20210112.gappssmtp.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 ddIUWLGBEyGz for <v6ops@ietfa.amsl.com>; Tue, 22 Mar 2022 13:20:56 -0700 (PDT)
Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [IPv6:2001:4860:4864:20::2a]) (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 A0D413A0E67 for <v6ops@ietf.org>; Tue, 22 Mar 2022 13:20:56 -0700 (PDT)
Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-ddfa38f1c1so2859056fac.11 for <v6ops@ietf.org>; Tue, 22 Mar 2022 13:20:56 -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=KD0nKJBaM0OnWX8kIJmLTyRq7oRk4qDMOedxCyNz0Oo=; b=6IZZvYftzoXnb+EDpU3Vs76609GbUpk2e7qMR0no4jufxcqZH0dLJ/YLg+a/BjCz7G Kvm7t1mQlSiY34jC5PUUba36b3nFfMqvV3cd4lHewkD3lp3RS2spRDIXZU9s5CIpp8+U yHZmIP+/jj0CRoba7XAPY0xRR2HhZAgN4/mgNaOixWzNlIClJXiLLpHvDgL/1NQRFJhD 1N0qAsZmhKBPnzdC3Cs951w24DNqIJMF4/sKStA4lz93V+/pVLOAcCHthY0a37ZYfAfT V4gr3J8HYDc/CVMxgkJpCu7h8bwqiMFZDy9Ve1PAc9i6jV/ICVjK22gj5uOpIxiua+k/ wKGA==
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=KD0nKJBaM0OnWX8kIJmLTyRq7oRk4qDMOedxCyNz0Oo=; b=vjkffeU4qCbnrExUpft6Jg9yxZg0wF3PwCIX4xGktNLovbHdq9+2xEV3SQ7uY4XcwU wEZ9c6IJyWIoLcZkJ/HzrCYCndsxRq5ZOn3NVQMlwFIjVjlJp58s6ZyfXA0n9kv49tVz RIhNIjbyMnXIDRZNKI44asZm4w8Rzs+GWFds4eiWZUD39asBsp83oTno48lyhC3yfvkP Qv/8TYEwR7ToyE5kYCWztPsyftgE2lY1qgrvnUo6e6QgaACpXqgO5XvBurxi7R42jQFw QTOxMfjz2PFEAkxxS6ul9Eei1GZ/8neVr8PmaQpQv0zNkzCqNsibRolqZYAkOj049OPE +3EQ==
X-Gm-Message-State: AOAM531Vlpg72h/73heazZiBEULJSkhAbIlOFKFDrMVXhW74BCEpr8dl Am0+HTUiLGcgGNJLavaJvuAbrQ8Q0xEMlJsjua3N1Q==
X-Google-Smtp-Source: ABdhPJy76CxK/ZzdaqSK1lc5iOA0quyKrt0BywSRU/XhZD4EJ4TmEp17i3tGqgafYsak/Y3xxOySoSBgtpZbKSColhU=
X-Received: by 2002:a05:6870:4582:b0:da:b3f:3221 with SMTP id y2-20020a056870458200b000da0b3f3221mr2444657oao.209.1647980455037; Tue, 22 Mar 2022 13:20:55 -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> <fd17a91f-68dc-92b5-0544-51aefa1b7f08@gmail.com> <CAM5+tA-Wq5O4pjQ++VZQi-FTKZGMRAW-LFc6O5dPOyox4QZDEw@mail.gmail.com>
In-Reply-To: <CAM5+tA-Wq5O4pjQ++VZQi-FTKZGMRAW-LFc6O5dPOyox4QZDEw@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 22 Mar 2022 21:20:18 +0100
Message-ID: <CAPt1N1mK=Xgtt+aYa4ga8YqK2XYhCdQUPrwgVU8xstH+F_RAfQ@mail.gmail.com>
To: buraglio@es.net
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, v6ops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009ea17305dad4593b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/m49HdLwhVSScMNYlIda15IVK7is>
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 20:21:02 -0000

I'm sure you believe this assertion, Nick, but you haven't given us any way
of understanding why you believe this. In fact we're using ULAs in the
Thread Border Router to enable IPv6 communication between different
subnets, which literally could not be done with IPv4. So at least for this
use case, ULAs work well. Would it work better to have a GUA? Comme ci
comme ça. On the one hand, prefix delegation and real routing would make
the solution more general. On the other, GUAs are great for reaching out to
the internet, which we may or may not want light bulbs to be able to do.

On Tue, Mar 22, 2022 at 9:13 PM Nick Buraglio <buraglio@es.net> wrote:

> ULA is an operational non-starter in the presence of any dual stacked
> hosts.  Per its design, it just won't ever use IPv6 in any meaningful way
> and that time and effort are better served on adding GUA addressing of one
> kind or another.
>
> nb
>
>
>
> On Tue, Mar 22, 2022 at 2:55 PM Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
>
>> Hi Gert,
>>
>> I see that the discussion has been going on while I was sleeping, but I
>> want to clarify below...
>> On 22-Mar-22 21:30, Gert Doering wrote:
>> > 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...
>>
>> I came up with 10 million quite some years ago as a reasonable estimate
>> of the number of medium to large businesses in the world, all of which
>> might depend on *reliable* Internet access to survive (and WfH during
>> COVID has made this even more important recently). So all of them
>> should have two independent paths to the Internet to assure reliability.
>> That means two different ISPs (or less good, two completely independent
>> paths to the same ISP).
>>
>> So, if PI addressing is the answer, that really does take us to
>> 10M /48s to be routed.
>>
>> If PA is the answer, that's why I worked on SHIM6 (may it rest in
>> peace). Which is why I worked on RFC 8028. If that's not the
>> answer, we're back to NPTv6. Possibly even to ULA+NPTv6.
>>
>> > 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...?"
>>
>> Yes.
>>     Brian
>>
>> _______________________________________________
>> 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
>