Re: RFC6724-bis?

Agreed, and understood - pardon my misunderstanding (jet lag is a mental
processing governor).

----
nb

On Wed, Sep 21, 2022 at 9:35 AM Vasilenko Eduard <
vasilenko.eduard@huawei.com> wrote:

> 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> 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
>