Re: RFC6724-bis?
David Farmer <farmer@umn.edu> Fri, 23 September 2022 11:17 UTC
Return-Path: <farmer@umn.edu>
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 B4E20C14CF09 for <ipv6@ietfa.amsl.com>; Fri, 23 Sep 2022 04:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 7BXGcaZx9uvY for <ipv6@ietfa.amsl.com>; Fri, 23 Sep 2022 04:17:12 -0700 (PDT)
Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96FFC14F74D for <ipv6@ietf.org>; Fri, 23 Sep 2022 04:17:11 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 4MYqP33fp9z9vCBm for <ipv6@ietf.org>; Fri, 23 Sep 2022 11:17:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVYZrsYPqO2h for <ipv6@ietf.org>; Fri, 23 Sep 2022 06:17:11 -0500 (CDT)
Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 4MYqP3092Nz9vCBR for <ipv6@ietf.org>; Fri, 23 Sep 2022 06:17:10 -0500 (CDT)
DMARC-Filter: OpenDMARC Filter v1.3.2 mta-p6.oit.umn.edu 4MYqP3092Nz9vCBR
DKIM-Filter: OpenDKIM Filter v2.11.0 mta-p6.oit.umn.edu 4MYqP3092Nz9vCBR
Received: by mail-ed1-f72.google.com with SMTP id m13-20020a056402510d00b004519332f0b1so8529907edd.7 for <ipv6@ietf.org>; Fri, 23 Sep 2022 04:17:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=W2aRhMcw9pE5tvbOpPwCxzgjdrihSIWn85xySSdTaDw=; b=LsEKRulGQdS/UzWWmXp0fFDIcslTa1NeG//0uVNvUsSv9zWiXJxo/RNWT90ujvazR6 HMf9GAJPIEOgUupa11wfR0jaQ5TkV9jHu+xuIAqcN4U9WsfD2910ja2J8Y5r3ZFTqY6O a1ZgphZLFkOvdEL1EbRqEYo73F9qqx9V2u7qAw3nedn5kPQyMElrAkeGycHt0ZGHEZ8Q OQ/ZYaUrm+wsfkw3Ati4WvQ6oPEFD27Pgh+dX87OWW5v7E4kQFCKek3eQ7qrUoKeGyUp qfbbVQ4FdINBomtDjlDDuycV9xw2+OGjUSCuFPuAUbeH3S40GLlN25OvZ2IiU6iw/nSe sryA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=W2aRhMcw9pE5tvbOpPwCxzgjdrihSIWn85xySSdTaDw=; b=veVcZubaPRQ8ojRQQmDflbfkwAHeikgA3naiyfcQZTFI+bSyrK03WK8WXRZbZF7Aan nMKn532hiLxYUxUSIvnmtB8AwUhHF7oUpG5u3hVqvw4t+7GxdA4u/N3S8fZBzf1CfCLz 1x1pojLi0l5EgqLocveO5w7uK5Olx9gp++PwRMgr7UoB8nRjcPb/I6kzgI/RyGsQxz4p +0Yl1p+nmqQhTjIcVhMBB9lynviFgX0RP+pg5U168TynDuBac8ppTBznb/5WP+VUEFcx KqHqFyOxWslxT+15PXUhrhhC0OmKkpb9tNzJT98Bp9WrG1Qung6Yda/FesY+4KwCLM9Z jgfg==
X-Gm-Message-State: ACrzQf3DrRwLnqlIPkxZGtbWAv5Hv5lF9Kwx4t63cpxglu4PN97SOCSZ P+zhtbxvW3lObF0P1hrFMx6HJpnQ+RP62E50clqBjjFgE77yKoz0/u8HFY5vSPL8EMNC3Vr3sqQ AncqPpL0iyUPqjyMm2TM7QA9E
X-Received: by 2002:a17:906:ee8e:b0:730:4a24:f311 with SMTP id wt14-20020a170906ee8e00b007304a24f311mr6622471ejb.420.1663931829301; Fri, 23 Sep 2022 04:17:09 -0700 (PDT)
X-Google-Smtp-Source: AMsMyM6H+JUAwONCa2cB3YlXKh1ABWbCG3QSe1kfzB6mdzztwbSi3lTz8vTSn/8DkOxj7mT2+79mIZOWVG0nOxNgSLQ=
X-Received: by 2002:a17:906:ee8e:b0:730:4a24:f311 with SMTP id wt14-20020a170906ee8e00b007304a24f311mr6622445ejb.420.1663931828866; Fri, 23 Sep 2022 04:17:08 -0700 (PDT)
MIME-Version: 1.0
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> <29689d645d22409b962f6c361d71e098@huawei.com>
In-Reply-To: <29689d645d22409b962f6c361d71e098@huawei.com>
From: David Farmer <farmer@umn.edu>
Date: Fri, 23 Sep 2022 06:16:57 -0500
Message-ID: <CAN-Dau3rwi4X4NqLbHMmPQQ=i7y23Kz70JK09ggsXSxkJfT5xA@mail.gmail.com>
Subject: Re: RFC6724-bis?
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
Cc: 6man WG <ipv6@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ted Lemon <mellon@fugue.com>
Content-Type: multipart/alternative; boundary="00000000000097312505e956512e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/itSQuWa-0uwkHO2QX9GKrRHl-6k>
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 11:17:15 -0000
Please read the first paragraph of RFC6724 section 10.6 and all it’s references very carefully. In particular, read 2.2.2 of RFC 5220. Your argument contradicts the conclusions of 2.2.2 of RFC 5220. In short, your argument is only true today while we are using 2000::/3 for GUA. When that eventually changes, and it will some day, we would have to yet again rejigger the table. RFC 6724 is almost correct, the only thing it got wrong is that the section 10.6 modifications must be mandatory and automatic, and not optional, otherwise ULA is broken and dysfunctional. Let’s only fix the problem and not make new problems for the next generation of network engineers and operators. Thanks On Fri, Sep 23, 2022 at 02:27 Vasilenko Eduard <vasilenko.eduard= 40huawei.com@dmarc.ietf.org> wrote: > I still do not understand why Ted and David care about "remote ULA". > If this ULA has been delivered to the local host by > 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 > -------------------------------------------------------------------- > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
- 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