Re: RFC6724-bis?

[Brian E Carpenter <[e-mail]>]

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.

    Brian

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