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

[Vasilenko Eduard <[e-mail]>]

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

>I really like this.
>I think it is the best solution.

But how remote ULA prefix would be known to the local router?
If proper routing is in place then no problem exists in the first place, the whole FC/7 could be prioritized.

Ed/
-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Michael Richardson
Sent: Monday, September 26, 2022 12:19 AM
To: 6man WG <[e-mail]>
Subject: Re: Network merge [Re: RFC6724-bis?]


Brian E Carpenter <[e-mail]> wrote:
    > 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.

I really like this.
I think it is the best solution.

(I think that really what we are asking for is that L/A bits are simply ignored when it comes to adjusting the prefix precedence)

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

I actually think that the uniqueness has value even when the networks do not merge :-)

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

It seems that we are all agrement on this part.

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

That's an interesting possibility.

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

Would you want to wait at all after the lifetime of the PIO/RIO expired?
As long as active sockets are not killed,  then if it comes back soon, it's not a problem. (Android has kernel patches to be able to kill things like that quickly)

--
Michael Richardson <[e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-