Re: RFC6724-bis?
Nick Buraglio <buraglio@es.net> Wed, 21 September 2022 05:18 UTC
Return-Path: <buraglio@es.net>
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 1D1CFC14CE22 for <ipv6@ietfa.amsl.com>; Tue, 20 Sep 2022 22:18:07 -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_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=es.net
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 jiZH_QT0JKHL for <ipv6@ietfa.amsl.com>; Tue, 20 Sep 2022 22:18:02 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA1AC14CF1F for <ipv6@ietf.org>; Tue, 20 Sep 2022 22:18:02 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id r18so10978520eja.11 for <ipv6@ietf.org>; Tue, 20 Sep 2022 22:18:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=o5W7cUDunkemtp8G0OonT+Tzz65TKKyyJ0RC0T0b5O8=; b=W73OBuepObmUgsf0cUp3o3+3hl3NT5w+MV1fepilVWrlH2I4ccTC+HM4tjwFnCHqVh rttJGI3CLF+A/ZQEzIdoV9aqMOWOwhGyQVOnonGyXTkg0UG/vWySJ9RU5MsFiVVXAmr+ h9hYE2tX0E6psoR+w0Nxcq5L/ccj1qcf1jNgE6Af3PD9N2qrk7DNJ9QJeMtSMVGlYsS4 fHzIQEfwPTNBG0RhHYa/RYkEoadF4bT3cM81yQUIalH2UaV/P5sVEFw3CANiotlBJ96/ oYBNzkE/0BBLI0Mg72uYlrXYLeuI/ZucGg8iwfDMBd45T3GZGBzF2wSu9/7CNE1wycbx 3I2w==
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:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=o5W7cUDunkemtp8G0OonT+Tzz65TKKyyJ0RC0T0b5O8=; b=6DGM0y3tQ3JmkcdDsTzhn2lTlFEWzazFajNqZbdpbn1bo2YLPfNMbZYNFWKzYLhvmR JvkBKyCsZKElLi0zSJ6FvTZeuK7fgLtd/upcRkvR/BfdP8WoeohAoCgr44OsxOU8Bv0n tFUIWRMepYj2Jnzo5pG/FZXYlmaWGfeMZmPJvxmZOWs98T2jDoFua+b0kDF4gFZnmIjL Dxy02oR4dyk/10+hhx8mtRDPDCEEwuFEdICz8MusBQ8/tATWUn1MD1SY5cfulaSo8ZkU CsDWWFVINpTX9hN1SLiDnboZR6j/Qa920DlZQkrVUVXo0na76CLmxxMboKF+1NW4kOB/ Mxtg==
X-Gm-Message-State: ACrzQf1EjJcRwRA+4d6IIISv5i5HDv6JV0GKLEC1b9t49XUWcsyxme78 VAuiSHFrtUOEI6YPibp0auNto76GBg1B+AgGDW/0OuLUfrZugfciJGJ6wPpK8xcj4ILqHs5emUh Utb8H5kGkaiJH/VpkQsMnyF5jdkN0gQWWlEmmze0W6nNhylzFYjCV5B+fzbOM0ArHfFgrLGoY9B /S8dVo8Kk=
X-Google-Smtp-Source: AMsMyM40pRZbyWLQSEMzhP7D9qZoVvBRzL1/hMSYx612uPwUM4S7I4hWrA62uCtxw+NpRu4JAInyR2yziaNi1V8r0Eg=
X-Received: by 2002:a17:907:75c2:b0:770:7bb7:9412 with SMTP id jl2-20020a17090775c200b007707bb79412mr19702094ejc.638.1663737480536; Tue, 20 Sep 2022 22:18:00 -0700 (PDT)
MIME-Version: 1.0
References: <66892DC8-6DA4-4DC8-85B0-E1E1647CD9F7@gmail.com> <f3b80447394f4eb8b06cc992fde3db6c@huawei.com> <CAM5+tA_zovZtQWs28a8Jnet3-XJFBquq1oEOOp=SH=W7inrUBg@mail.gmail.com> <0b6056a5-c8ac-6240-bfcf-00de8c6ab53a@gmail.com>
In-Reply-To: <0b6056a5-c8ac-6240-bfcf-00de8c6ab53a@gmail.com>
Reply-To: buraglio@es.net
From: Nick Buraglio <buraglio@es.net>
Date: Wed, 21 Sep 2022 07:17:48 +0200
Message-ID: <CAM5+tA-ScXeW0YD2i0E388xYnPPYLMiot+sTLuFSWPniGk=dZg@mail.gmail.com>
Subject: Re: RFC6724-bis?
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000877ea605e9291158"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ChtZMu-pq8FWsNJ9GhUI99MNEkk>
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: Wed, 21 Sep 2022 05:18:07 -0000
On Wed, Sep 21, 2022 at 1:56 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 21-Sep-22 11:39, Nick Buraglio wrote: > > Operationally, I would discourage the scripting approach. As noted in > the draft draft-ietf-v6ops-ula-00 one of the more difficult or impossible > problems are the OT hardware and embedded devices with no mechanism for > adjusting preferences. > > If that were written in as an internally executed, required function, > then perhaps it has some more broad viability. > > Yes, that's why I mentioned that it should be a kernel function IMHO. > +1 > > Brian > > > > > On Tue, Sep 20, 2022 at 6:32 PM Vasilenko Eduard <vasilenko.eduard= > 40huawei.com@dmarc.ietf.org <mailto:40huawei.com@dmarc.ietf.org>> wrote: > > > > What if legalize Brian's script: > > As soon as the new ULA PIO (/64) is received > > The host should automatically insert /48 derived out of it into the > policy table > > With the precedence (45?) and label (6?) above IPv4 and default but > below GUA. > > The old FC/7 could be kept as it is (3/13). > > It needs a little more thinking about what to do if many different > ULAs (/48) is detected. > > Probably, priority and label could be the same (45/6?) for all > specific ULAs. > > > > It would give good compatibility to the old implementation > > Because it is what is needed to do manually now to have ULA > operational. > > The proposal is just automation. > > Eduard > > -----Original Message----- > > From: ipv6 [mailto:ipv6-bounces@ietf.org <mailto: > ipv6-bounces@ietf.org>] On Behalf Of Tim Chown > > Sent: Tuesday, September 20, 2022 7:07 PM > > To: ipv6@ietf.org <mailto:ipv6@ietf.org> > > Subject: RFC6724-bis? > > > > Hi, > > > > As an author of RFC6724 I’ve had the discussions about a possible > update of RFC6724 brought to my attention. > > > > An example thread over on v6ops is > https://mailarchive.ietf.org/arch/msg/v6ops/W6HjHc11JX364soq3t3gFMHSawE/ < > https://mailarchive.ietf.org/arch/msg/v6ops/W6HjHc11JX364soq3t3gFMHSawE/>, > but there are others. > > > > Nick Buraglio has documented the problem in > draft-ietf-v6ops-ula-00. The short of it is that RFC1918 IPv4 addresses > may be preferred to IPv6 ULAs in certain circumstances, which I would agree > is not desired behaviour. > > > > There are a few ways we might look to address this. There is a > proposal from Nick (not yet published outside a git repo) to address it by > changing wording in section 2.1, with a couple of MAYs becoming MUSTs, and > adding an extra explaining paragraph. This basically firms up the > requirement to follow 6.10 on adding an extra precedence line for local ULA > prefix(es). > > > > Now, that may or may not be the preferred solution of the WG, but I > think there’s a few questions to consider: > > > > 1. Is there agreement we should address the problem? I’d assume so > because Nick's problem draft was adopted by v6ops. > > > > 2. If so, is 6man the place to do it? I think it has to be. > RFC6724 was born here. > > > > 3. How do we determine the best solution to the problem? I suspect > there are nuances in play that will make a one size fit all ’simple’ fix > tricky, but I look forward to the discussion. Nick has one proposal that > counts to a couple of word changes and an extra paragraph, which I’d > encourage him to share here, but there are other approaches proposed on > v6ops. I think either way, it will require some update to or for RFC6724. > > > > 4. Does this work warrant a full -bis or would a separate RFC that > updates 6724 be better? A separate Updating draft might better highlight > the issue to implementors. But then RFC6724 is now ten years old, and > RFC3484 which it replaced was nine years before that. > > > > 5. If we choose to open up a full -bis, are there any other worms in > this can? I have a feeling also here I know the likely answer…. > > > > Anyway, over to the WG… thoughts? > > > > Tim > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org <mailto:ipv6@ietf.org> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > <https://www.ietf.org/mailman/listinfo/ipv6> > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org <mailto:ipv6@ietf.org> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > <https://www.ietf.org/mailman/listinfo/ipv6> > > -------------------------------------------------------------------- > > > > -- > > ---- > > nb > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -- ---- nb
- 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