RE: RFC6724-bis?

I have pointed already that script would not work
Because ULA PIO may be announced and deprecated
Then who would run the script? (at the proper moment)
IMHO: specification should be derived from last Brian’s proposal.
Script or not – should not be discussed, as usual.
I hope nobody would choose a script for implementation.
Eduard
From: Nick Buraglio [mailto:buraglio@es.net]
Sent: Wednesday, September 21, 2022 8:18 AM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com>; ipv6@ietf.org
Subject: Re: RFC6724-bis?

On Wed, Sep 21, 2022 at 1:56 AM Brian E Carpenter <brian.e.carpenter@gmail.com<mailto: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> <mailto: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> <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> <mailto: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> <mailto: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> <mailto: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<mailto:ipv6@ietf.org>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--
----
nb