Re: RFC6724-bis?

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

On 21-Sep-22 04:31, Vasilenko Eduard wrote:
> What if legalize Brian's script:

Just to be clear, I posted two different approaches:

1) A modified version of what Karl Auer did 10 years ago at
http://biplane.com.au/blog/?p=122. That's to say, attempting
more or less static configuration (which works differently
in Windows and Linux, and I don't really know how it works
elsewhere).

Found at https://github.com/becarpenter/misc/blob/main/enable_ula.py

2) A more dynamic approach that is simply a Python wrapper for
getaddrinfo() which detects the presence of a ULA.

Found at https://github.com/becarpenter/misc/blob/main/gai_wrap.py

I do believe the second one could be generalized, but whether that
should be described in an RFC is open to debate.

     Brian




> 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]] On Behalf Of Tim Chown
> Sent: Tuesday, September 20, 2022 7:07 PM
> To: [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/, 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]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------