Re: RFC6724-bis?

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.

On Tue, Sep 20, 2022 at 6:32 PM Vasilenko Eduard <vasilenko.eduard=
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] On Behalf Of Tim Chown
> Sent: Tuesday, September 20, 2022 7:07 PM
> To: 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/,
> 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
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 
----
nb