RE: RFC6724-bis?
Vasilenko Eduard <vasilenko.eduard@huawei.com> Fri, 23 September 2022 07:27 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 8657DC1522D3 for <ipv6@ietfa.amsl.com>; Fri, 23 Sep 2022 00:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 X_xMak5M6Ogu for <ipv6@ietfa.amsl.com>; Fri, 23 Sep 2022 00:27:48 -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 8D192C1522C5 for <ipv6@ietf.org>; Fri, 23 Sep 2022 00:27:48 -0700 (PDT)
Received: from fraeml704-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MYkH26kFmz685x5 for <ipv6@ietf.org>; Fri, 23 Sep 2022 15:26:38 +0800 (CST)
Received: from mscpeml500002.china.huawei.com (7.188.26.138) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.31; Fri, 23 Sep 2022 09:27:45 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500002.china.huawei.com (7.188.26.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 23 Sep 2022 10:27:45 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.031; Fri, 23 Sep 2022 10:27:45 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Ted Lemon <mellon@fugue.com>, David Farmer <farmer=40umn.edu@dmarc.ietf.org>
CC: 6man WG <ipv6@ietf.org>
Subject: RE: RFC6724-bis?
Thread-Topic: RFC6724-bis?
Thread-Index: AQHYzQsTYjAQjrj/LUqdQU83Wias3q3pVHuAgAAGaoCAAAE6AIAABQoAgAFZtQCAANuko///zt0AgAA2QhCAAGcYJP//+wCAgAAC0oCAAA/jAIAAjjxQ
Date: Fri, 23 Sep 2022 07:27:44 +0000
Message-ID: <29689d645d22409b962f6c361d71e098@huawei.com>
References: <66892DC8-6DA4-4DC8-85B0-E1E1647CD9F7@gmail.com> <CAM5+tA9kttCKrZaoB7UzNdE6TU1qGNMaxDmWvFtRvpB4A8+WHA@mail.gmail.com> <8FE71499-D155-4853-A964-6617F6EA2069@gmail.com> <CAM5+tA9QuYxVs+NXBD3dAYr_Y=95bWt63WjmEMDOfegL0Z4otA@mail.gmail.com> <CAM5+tA_hg2sXXsYw6Tcx-ytRAMkKQcFw8a3N7SfEXwbuPm0LMw@mail.gmail.com> <00ea3b70-ba8e-b6ef-e1ce-fdd56828f506@gmail.com> <CAPt1N1=_9Rwj-HnUZKWfatARbHWptArmSAV-qdi8MKyoBf9R0A@mail.gmail.com> <CAO42Z2xZ_-mDh66A9DK+3ieEqGMqW0Pt+mZzVOmzz4cDRUTEXA@mail.gmail.com> <CAPt1N1nqwMvVHvEGAx0jxgWhbW9ZUQfAZSDn-qRYQ0CDy-EGKQ@mail.gmail.com> <17a28c173ed640e68b1cbf504bbeae49@huawei.com> <CAPt1N1=xR_2Xw+1KL6vbzZ69N+vonhcTNvO=DBceeApfoS2bMQ@mail.gmail.com> <e76267b6101146cf8a1bd6fa567c6b77@huawei.com> <CAN-Dau2QO5sxevJwUbOj+_wyiCdOjnPEZM14Jhevvkq4YZqU7Q@mail.gmail.com> <bc85e623-ef89-d2e2-4e33-b8ce0a4ec343@gmail.com> <CAN-Dau0Wbki6xwcEdy8ZK-pO9jeT6+8TKZgbmXWUgnkR+dRhBg@mail.gmail.com> <CAPt1N1=OmC+HNVGWbgj9JtGbpcuzKOgjZ1KXJm5mXgpji-G4Mw@mail.gmail.com> <6edcc5d8-edf1-51de-103c-a4ac6060fef6@gmail.com>
In-Reply-To: <6edcc5d8-edf1-51de-103c-a4ac6060fef6@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.206.137]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mC9e1Wh98bAxXaf1eadk0yONhr0>
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, 23 Sep 2022 07:27:52 -0000
I still do not understand why Ted and David care about "remote ULA". If this ULA has been delivered to the local host by DNS Then it has been done intentionally. Such a type of misconfiguration does not make sense to optimize. Hence, it is possible to operate FC/7 as a whole, no need to split it for /48s. Hence, why not install permanent precedence to FC/7 in gai.conf? It would not play any role on the host till the local router would deliver ULA PIO. And even after this, it would not be used till DNS would show the ULA destination Because rule 5 (matching labels) would make GUA_DA/ULA_SA a low priority, GUA/GUA would be chosen. What is the problem with permanently changed FC/7 precedence even above GUA? Eduard -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Friday, September 23, 2022 4:47 AM To: Ted Lemon <mellon@fugue.com>; David Farmer <farmer=40umn.edu@dmarc.ietf.org> Cc: 6man WG <ipv6@ietf.org> Subject: Re: RFC6724-bis? On 23-Sep-22 12:50, Ted Lemon wrote: > Op do 22 sep. 2022 om 20:40 schreef David Farmer <farmer=40umn.edu@dmarc.ietf.org <mailto:40umn.edu@dmarc.ietf.org>> > > I think leaving unknown, most likely remote, ULA at a lower priority and adding the /48 or other known local ULA to the table at a higher priority automatically should help mitigate ULA in the public DNS and the possible response of turning off IPv6. > > In someways those that put ULA in the public DNS get what they deserve, I’m just worried about the remote user’s response to the brokenness, causing even more brokenness. > > > Hm, okay. I think we are all actually in agreement then, since I heard Brian admitting earlier that it might be better to dynamically update the table. Indeed, which was exactly why I wrote gai_wrap.py as a userland proxy for that approach. Brian > I must have misunderstood what you meant by optimizing for the uncommon case—sorry about that! > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- RFC6724-bis? Tim Chown
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Nick Buraglio
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Tim Chown
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Bob Hinden
- Re: RFC6724-bis? Brian E Carpenter
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Mark Smith
- Re: RFC6724-bis? Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Michael Richardson
- Re: RFC6724-bis? David Farmer
- RE: RFC6724-bis? Vasilenko Eduard
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Michael Richardson
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Mark Smith
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? David Farmer
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Brian E Carpenter
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? David Farmer
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? David Farmer
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Nick Buraglio
- Network merge [Re: RFC6724-bis?] Brian E Carpenter
- Re: Network merge [Re: RFC6724-bis?] David Farmer
- Re: Network merge [Re: RFC6724-bis?] Michael Richardson
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Brian Carpenter
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- RE: RFC6724-bis? Vasilenko Eduard
- RE: RFC6724-bis? Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Michael Richardson
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Nick Buraglio
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- Re: Network merge [Re: RFC6724-bis?] Mark Smith
- Re: Network merge [Re: RFC6724-bis?] Ted Lemon
- Re: Network merge [Re: RFC6724-bis?] David Farmer
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- Re: Network merge [Re: RFC6724-bis?] Mark Smith
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Michael Richardson
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] David Farmer
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] David Farmer
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- Re: Network merge [Re: RFC6724-bis?] Ole Troan
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Ole Troan
- Re: Network merge [Re: RFC6724-bis?] Timothy Winters
- Re: Network merge [Re: RFC6724-bis?] Nick Buraglio
- Re: Network merge [Re: RFC6724-bis?] Brian Carpenter
- Re: Network merge [Re: RFC6724-bis?] Ole Troan
- Re: Network merge [Re: RFC6724-bis?] Brian Carpenter
- Re: Network merge [Re: RFC6724-bis?] Ole Troan
- Re: Network merge [Re: RFC6724-bis?] David Farmer
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- Re: Network merge [Re: RFC6724-bis?] Michael Richardson
- Re: Network merge [Re: RFC6724-bis?] Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Michael Richardson