RE: Network merge [Re: RFC6724-bis?]

[Vasilenko Eduard <[e-mail]>]

Let’s assume that all ULA labels are the same (for /7 or /64) – it is possible to provision.
Then next rule 6 (DA precedence) would prioritize ULA_DA (derived from /7) below IPv4.

ULA-specific prefixes (/64) look like not possible to fix. They would stay below IPv4.
/48 looks minimum for ULA to work.

Ed/
From: Vasilenko Eduard
Sent: Monday, September 26, 2022 11:01 AM
To: 'David Farmer' <farmer=[e-mail]>; Brian E Carpenter <[e-mail]>
Cc: 6man WG <[e-mail]>; David Farmer <[e-mail]>; [e-mail]
Subject: RE: Network merge [Re: RFC6724-bis?]

> I’ve been thinking that either a PIO or a RIO from within fc00::/7 should trigger an entry in the table. If the prefix in the PIO or RIO is longer than /48, the covering /48 should be added to the table. Otherwise, if the prefix is /48 or shorter the prefix should be added to the table as-is. In most case unless a PIO is a /64 it will likely have L=0 and A=0.

Adding more specific prefixes (for example /64) would not work for the “label” reason. It would still keep ULA priority below IPv4.
Even IPv4_DA/IPv4_SA would be preferred over ULA_DA/ULA_SA because ULA_DA would have a different label than ULA_SA.
Prove: Rule 5 section 6 RFC 6724.

Ed/
From: David Farmer [mailto:farmer=[e-mail]]
Sent: Sunday, September 25, 2022 2:39 AM
To: Brian E Carpenter <[e-mail]<mailto:[e-mail]>>
Cc: 6man WG <[e-mail]<mailto:[e-mail]>>; David Farmer <[e-mail]<mailto:[e-mail]>>; Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: Network merge [Re: RFC6724-bis?]



On Sat, Sep 24, 2022 at 15:38 Brian E Carpenter <[e-mail]<mailto:[e-mail]>> wrote:
Just focusing on the corner case:

On 25-Sep-22 07:47, Nick Buraglio wrote:
>
>
> On Fri, Sep 23, 2022 at 8:12 PM Brian E Carpenter <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:

...
>     But there is still a corner case: if two networks using ULAs are
>     merged, and the necessary routes are installed, the individual
>     hosts would still need manual intervention. A high precedence for
>     fc00::/7 would avoid that.
>
>
> At least to me at this time it seems that although this use case is real, it should just be noted as an edge case that is out of scope.

I think we need to say a little more, since the network merge case was one of the original motivations for ULAs in the first place (otherwise, statistical uniqueness has no real value).

At least, we need to say that in the case of a network merge, human intervention to configure ULA precedence will be needed. I still find that unsatisfactory, since the idea was always that unplanned merges might happen (in unmanaged networks, not in enterprise networks). If we decide to leave that unsolved, I think we'll be back to this problem later.

Now as to how to fix this without a global precedence for ULAs, I am wondering about a PIO with L=0 and A=0 (exactly as recommended in RFC 8028, but for other reasons). If a host sees such a PIO for a ULA prefix, it could serve as a signal that the prefix is to be given a suitable precedence, even though it is not on-link and not used for SLAAC.

(Credit where credit is due: Ted Lemon suggested this.)

I’ve been thinking that either a PIO or a RIO from within fc00::/7 should trigger an entry in the table. If the prefix in the PIO or RIO is longer than /48, the covering /48 should be added to the table. Otherwise, if the prefix is /48 or shorter the prefix should be added to the table as-is. In most case unless a PIO is a /64 it will likely have L=0 and A=0.

While probably not recommended, it would be possible for a network operator to signal the entire ULA range as being local, using a PIO for fc00::/7 with L=0 and A=0, for example.

Finally, there should probably be a short discussion of managing the table, such as removing an entry when the PIO is no longer valid and similarly for a RIO.

Thanks
--
===============================================
David Farmer               Email:[e-mail]<mailto:[e-mail]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================