Re: [v6ops] Thoughts about wider operational input

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 22 March 2022 20:51 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 6FAEC3A10E5 for <v6ops@ietfa.amsl.com>; Tue, 22 Mar 2022 13:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, 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 9CfkLVG3E99K for <v6ops@ietfa.amsl.com>; Tue, 22 Mar 2022 13:51:38 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 9F3953A10DC for <v6ops@ietf.org>; Tue, 22 Mar 2022 13:51:38 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id mm17-20020a17090b359100b001c6da62a559so4322323pjb.3 for <v6ops@ietf.org>; Tue, 22 Mar 2022 13:51:38 -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=N73RbJ+td9GCKEzI7QRuYZIbaAMQoasqvYd+N839Mgo=; b=S2tub+oRx57bEeKBu6c9LSL9fuAtwzokEowCC1rqtpTuQLIQIk0fsZpxNWxuwb4QTC UeIPrJlGu34oF+FBtGtBK1f0glu9zfeMOmPpVOCpae/goIV8104bUpObSJ3LNKfep6rh cCTN3Mp9uupvOji4hQq9Y+LQavpVC7vLd3UaEwDpqdII3N30Tcegr8h/K+VjboSxxN01 1Zxm+BHqU6W44huxZwDi7NCdVsIxUTYKa/hULSFuzoHnJgF6NVq00OS6jlVL5tti+0ON k9wi6uoI1TorWqyZXt7UD/7XXHbpMdYypTzPQHy0DEMeNLgiiVs+VZU+G81roCqbUsFc nYcw==
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=N73RbJ+td9GCKEzI7QRuYZIbaAMQoasqvYd+N839Mgo=; b=H1EJ62RqPijXgHsT5m8Jjhq+SvYtYJKmD1ao//XBiPsg80HhnlmNjgt9lQw2WD0K45 UUcVXGUoFZTFRPj6nMHfpWF4C0qBZe9sBn+m12h3kG5p5zw/fxxVbwIKWHOyaKk6dP8Y VN6KFSV7U2Nlhk25KZ55V0hrAdK1q8aKk0Hl9DcFSiR3JvD9A4iNEDvdjjJ2xtYgTgt9 GOajQupM6NNMO33Q6jK0joJaummzuWVs7dXKzmdsNmd7cxk4b9uusAjW2T7k0yajLAFR FBdjrXubnKkoQWjMa6z5uIz0oW32IlVNk0o1XQnxZ6osbLvhVCmRZcUdHj6exClQxl8Y yViQ==
X-Gm-Message-State: AOAM5310dWkklsqV3l85u1dzecW5d1kcR+4w4xL6B/VkOJc6FaXX9iRG Jwpu8gRHbtxDwXc/BMcw+5VHfOmL44XshA==
X-Google-Smtp-Source: ABdhPJzpQaAz1+NIbKBXHNpOn/bt3oc+uSqN/O8T+RAAK2wEz5bfK04e56/oMJ8evLg5IBRGtXc30Q==
X-Received: by 2002:a17:90b:3508:b0:1c6:e4f9:538b with SMTP id ls8-20020a17090b350800b001c6e4f9538bmr7437781pjb.158.1647982297130; Tue, 22 Mar 2022 13:51:37 -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 f30-20020a63755e000000b00381f6b7ef30sm17173440pgn.54.2022.03.22.13.51.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Mar 2022 13:51:36 -0700 (PDT)
To: Toerless Eckert <tte@cs.fau.de>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Cc: 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> <Yjme0qf6KVOWDrqL@faui48e.informatik.uni-erlangen.de> <E015C1CC-88D2-4675-BF9E-B186FF9A2F52@consulintel.es> <YjnGk3P5BQGYto17@faui48e.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <cdf51645-d146-e65a-15e4-2ac9a0b37436@gmail.com>
Date: Wed, 23 Mar 2022 09:51:32 +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: <YjnGk3P5BQGYto17@faui48e.informatik.uni-erlangen.de>
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/gQQ9qK6yn4Ua2GYDIsfl7januBI>
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:51:45 -0000

Hi Toerless,
On 23-Mar-22 01:52, Toerless Eckert wrote:
> When you are saying that IPv6 at home is not a problem, does that
> include homes with SP multihoming ? Because i for once don't think
> that support for DNS especially in the large amount of IoT equipment
> is good enoough to really make hiding of multiple addresses behind
> DNS names work well enough in practice.

What are you saying? That it's too hard to add AAAA records, or that
IoT stacks can't deal with multiple AAAA replies?

    Brian

> 
> Cheers
>      Toerless
> 
> On Tue, Mar 22, 2022 at 11:43:01AM +0100, JORDI PALET MARTINEZ wrote:
>> I don't think is a matter of being purist or not, it is a matter of ensuring that we don't create same or similar problems for apps.
>>
>> Of course, as everything, it is a balance with what is feasible and not.
>>
>> I believe in the homes, deployment is not a problem at the time being - CPEs with IPv6 are being provided by the ISPs that want to turn it on. The problem in enterprises is, most of of the cases, because, they didn't 
entered the proper "learning cycle for IPv6" (no need for it, no incentives, troubles if we don't have NAT, multihoming, etc.), so there is no request from IT to the managers and then there is no budget. Of course, there are exceptions, but I see this everyday specially in countries where the government mandated IPv6 in the public administration.
>>   
>> Regards,
>> Jordi
>> @jordipalet
>>   
>>   
>>
>> El 22/3/22, 11:03, "Toerless Eckert" <tte@cs.fau.de> escribió:
>>
>>      Jordi, *:
>>
>>      Isn't the main reason why we are not seeing more IPv6 in "enterprises" or even "homes"
>>      exactly because NAT (even from rfc1918 addresses to IPv6) does work well enough
>>      that those networks are happy to stick to it ? Why else would we likely have a huge
>>      number of edge routers doing exactly that ?
>>
>>      If we'd overcome architectural purity desires, maybe we find more 
practical ways
>>      to steer the evolution:
>>
>>      For example, if one can show benefits for e.g.: multihoming to different IPv6 services
>>      by use of (call it what you want) address translation from IPv6 on-site to the different
>>      IPv6 addresses in the Internet - then we might have created an incentive to upgrade from
>>      IPv4 to IPv6 already. That's to me already one step. Its IMHO not 
creating more NAT
>>      in the process, unless that NAT actually turns out to be providing more benefits for
>>      the users than downsides. But thats just what we have to deal with: actual user
>>      experience as opposed to architectural preferences.
>>
>>      Btw: To me as an end-user, a NAT/FW is great when i can control it (for my edge-network),
>>      and it is terrible when somebody in "the Internet" forces it on me. I have no idea why
>>      we're not even starting to think about these tools from exactly this perspective. Alas
>>      RFC8990 does not recognize this difference.
>>
>>      Cheers
>>          Toerless
>>
>>      On Tue, Mar 22, 2022 at 10:34:22AM +0100, JORDI PALET MARTINEZ wrote:
>>      > You’re right. Let’s say it in a different way, as may be my first email was not clear on this.
>>      >
>>      >
>>      > I don’t think we want again to repeat the NAT problems, 
so NPT is not a valid solution for me.
>>      > 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.
>>      > This means that renumbering is not (probably) a valid choice in 
any cases.
>>      > Can we make PI work in such “huge scale” scenario?
>>      > 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
>>
>>
>>      --
>>      ---
>>      tte@cs.fau.de
>>
>>
>>
>> **********************************************
>> 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
>