Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

Vasilenko Eduard <vasilenko.eduard@huawei.com> Fri, 12 April 2024 06:13 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E693C14F61F for <ipv6@ietfa.amsl.com>; Thu, 11 Apr 2024 23:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9meH_038Udc for <ipv6@ietfa.amsl.com>; Thu, 11 Apr 2024 23:13:22 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BEBC14F61C for <ipv6@ietf.org>; Thu, 11 Apr 2024 23:13:22 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VG5ml62sGz6K6P7; Fri, 12 Apr 2024 14:11:35 +0800 (CST)
Received: from mscpeml500003.china.huawei.com (unknown [7.188.49.51]) by mail.maildlp.com (Postfix) with ESMTPS id 13CEE1408FE; Fri, 12 Apr 2024 14:13:19 +0800 (CST)
Received: from mscpeml500004.china.huawei.com (7.188.26.250) by mscpeml500003.china.huawei.com (7.188.49.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Fri, 12 Apr 2024 09:13:18 +0300
Received: from mscpeml500004.china.huawei.com ([7.188.26.250]) by mscpeml500004.china.huawei.com ([7.188.26.250]) with mapi id 15.02.1258.028; Fri, 12 Apr 2024 09:13:18 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Ted Lemon <mellon@fugue.com>, Kyle Rose <krose@krose.org>
CC: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Thread-Topic: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>
Thread-Index: AQHai1v2iINrSQjA3UewoPevk/DBrrFhd+mAgADAMICAAIyhgIAAAkwAgAAFtwCAAAU2gIAAAtiAgAAKqwCAAUp8sA==
Date: Fri, 12 Apr 2024 06:13:18 +0000
Message-ID: <108ace0318d642a48d186dd69580bb7f@huawei.com>
References: <6A5E5F35-B35F-4358-8EE1-3BD82329141E@jisc.ac.uk> <6FBC1B5A-BF28-4B05-B2B2-A60DA4707755@gmail.com> <CAPt1N1m-Ye8vfOVnsPesFshLMV5QuVoxWqM=HVZiJ37zaBg6AA@mail.gmail.com> <CAKD1Yr1NTvFj0zB0=+nnUKck7TBtwHFz2XoFkD1smx4yCuZohQ@mail.gmail.com> <CAJU8_nWyE5TqBTXB9wfSkn6refaqYNVN967YAtCp-0VMk-5qWQ@mail.gmail.com> <CAPt1N1mqszfafMMY=54ezpoRymoy=bBjeVnWzxj6A27smR1eig@mail.gmail.com> <CAJU8_nWDDfwWEoahU4dqTEh3_HCq2UfpkFjefnXohb+5DAbjew@mail.gmail.com> <CAPt1N1nTJ1sDEQrn1iNUbvreu5bt0BweWgX7iOw6fmPgNBvUqw@mail.gmail.com> <CAJU8_nWsg=eGxu59akfB0+pOTJ-TYud-a_wGhtgnpp1RizVhrw@mail.gmail.com> <CAPt1N1nbTuSH4GGrimFAxe3YqTLbhiTX5KVjYsw+JRjoadzzrw@mail.gmail.com>
In-Reply-To: <CAPt1N1nbTuSH4GGrimFAxe3YqTLbhiTX5KVjYsw+JRjoadzzrw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.199.56.41]
Content-Type: multipart/alternative; boundary="_000_108ace0318d642a48d186dd69580bb7fhuaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/T6FplccEdFEmhEbaQ21gEs6KMzk>
Subject: Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2024 06:13:24 -0000

It looks like:
Somebody did something wrong (ULA in global DNS).
Everybody should support him now because he was first to act.
Ed/
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Ted Lemon
Sent: Thursday, April 11, 2024 16:29
To: Kyle Rose <krose@krose.org>
Cc: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>; Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
Subject: Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

On Thu, Apr 11, 2024 at 8:51 AM Kyle Rose <krose@krose.org<mailto:krose@krose.org>> wrote:
On Thu, Apr 11, 2024 at 8:41 AM Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote:
But this is counterfactual. Rght now if you publish a ULA in the global DNS, it will not cause a delay because no host with IPv6 connectivity will try to connect to it. We only run into a problem if we decide to prefer all ULAs over all IPv4 addresses. That /will/ in fact cause delays.

Because something is misconfigured. Right now, that misconfiguration is hidden, and becomes visible only when IPv4 connectivity is broken for whatever reason. Fix the glitch, which is the ULA in global DNS.

Kyle, I don't know if you can see this from where you're sitting, but you are making a religious argument here. It is not a misconfiguration to put a ULA in the DNS right now in the sense that it causes a problem. It's a misconfiguration because it doesn't match your mental model of How Things Should Be.

I don't entirely disagree with you about this—I don't think that we ought to put ULAs in the global DNS. But I don't actually have a solid argument against Lorenzo's position—I just don't happen to agree with it.