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

[Vasilenko Eduard <[e-mail]>]

It still needs the code change on all OSes.
They should insert /48 policy into SASA after receiving /64 PIO with L=A=0.
Moreover, would be a problem with many VPN solutions that install prefixes not as a PIO.
Ed/
-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]] 
Sent: Tuesday, September 27, 2022 10:48 PM
To: Ole Troan <[e-mail]>
Cc: Vasilenko Eduard <[e-mail]>; Mark Smith <[e-mail]>; Ted Lemon <[e-mail]>; 6man WG <[e-mail]>; Michael Richardson <[e-mail]>
Subject: Re: Network merge [Re: RFC6724-bis?]

On 28-Sep-22 08:40, Ole Troan wrote:
> 
>> (It is the presence of a ULA /48 prefix in local routing that we care 
>> about. The PIO for a /64 within that /48 is the trigger that it needs 
>> high precedence.)
> 
> Extending and overloading existing protocol fields is problematic. The proponents of this need at least to consider the consequences for existing implementations and future extensibility of the protocol. As well as the deployability of this, compared to existing standardized solutions.

There isn't a standardized solution, since the mechanism for updating the RFC6724 table is not standardized. A=L=0 is already standardized to mean "I can route this prefix" and the proposal builds on that exact semantic.

     Brian

> 
> O.
> 
> 
>>
>>> On 27-Sep-22 21:02, Vasilenko Eduard wrote:
>>> I am not so scared "on every interface". It is not good too (no automation), but tolerable for the Enterprise environment, not tolerable for SMB/home.
>>> If I understand the context of this discussion (I am not sure) It is 
>>> proposed here to have hundreds of PIOs (A=L=0) on every interface! 
>>> (separate prefix announcement for every remote prefix on different links) It looks like the consequence of /64 ULA policy table modification instead of /48 (A=L=0 PIO looks for this, right?).
>>> If my guess is right - then it is terrible.
>>> Eduard
>>> -----Original Message-----
>>> From: Brian E Carpenter [mailto:[e-mail]]
>>> Sent: Tuesday, September 27, 2022 7:39 AM
>>> To: Mark Smith <[e-mail]>; Ted Lemon 
>>> <[e-mail]>
>>> Cc: 6man WG <[e-mail]>; Michael Richardson 
>>> <[e-mail]>; Vasilenko Eduard 
>>> <[e-mail]>
>>> Subject: Re: Network merge [Re: RFC6724-bis?]
>>>> On 27-Sep-22 17:02, Mark Smith wrote:
>>>>
>>>>
>>>>> On Tue, 27 Sept 2022, 09:46 Ted Lemon, <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>>      The use case we are talking about here is a managed enterprise network. It should be no problem for the network operator to configure some local ra options.
>>>>
>>>>
>>>> On every existing and every new internal interface of every router in the network?
>>> Yes, but I assume that enterprises need ways to do network-wide config anyway. If not, that's why we're working on autonomic networking, to provide an ecosystem for smart enterprise-wide config.
>>>    
>>>> For many networks that's 100s if not 1000s of interfaces to configure with this parameter. That's a lot of work for *every* enterprise network to perform to work around somebody else's occasional error of putting ULA AAAAs in global DNS.
>>> I can't disagree (but it suggests a big gap in DNS tooling if that's even allowed except inside a split horizon DNS).
>>>      Brian
>>>>
>>>> This work around is going to be far more costly than teaching people not to put ULA AAAAs in global DNS.
>>>>
>>>> You don't teach people not to do something bad by hiding the consequences when they do, and placing the costs of tolerating that bad behaviour onto everybody else other than the person who created the problem.
>>>>
>>>> Regards,
>>>> Mark.
>>>>
>>>>
>>>>      Op ma 26 sep. 2022 om 19:17 schreef Mark Smith 
>>>> <[e-mail] <mailto:[e-mail]>>
>>>>
>>>>
>>>>
>>>>>          On Mon, 26 Sept 2022, 21:15 Vasilenko Eduard, <vasilenko.eduard=[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>>               >    > But how remote ULA prefix would be known to the local router?  If
>>>>               >It can't, which is fine.
>>>>               >If there are multiple ULAs after a merger, then we do what Brian and David described and send RIOs or PIOs.
>>>>
>>>>              It is evident that A=0 is for something non-local.
>>>>
>>>>
>>>>          A=0 means the opposite of A=1, and A=1 has a specific meaning, nothing to do with non-local.
>>>>
>>>>          Define another flag if this is going to be the solution to the fault of putting ULA AAAAs in global DNS.
>>>>
>>>>          (Can it be adapted to the fault of putting link-local 
>>>> addresses in DNS?)
>>>>
>>>>
>>>>              It would be especially needed if /64 would be put into the SASA policy table (then the remote prefix would be /64 too).
>>>>              It may be needed for different /48 after the company merge.
>>>>
>>>>              How to know what to put in this special PIO (A=L=0)? It looks like not automated at all.
>>>>
>>>>
>>>>          A sign that it's not solving the problem where it exists.
>>>>
>>>>
>>>>
>>>>              Ed/
>>>>              -----Original Message-----
>>>>              From: Michael Richardson [mailto:[e-mail] <mailto:[e-mail]>]
>>>>              Sent: Monday, September 26, 2022 1:45 PM
>>>>              To: Vasilenko Eduard <[e-mail] <mailto:[e-mail]>>; 6man WG <[e-mail] <mailto:[e-mail]>>
>>>>              Subject: Re: Network merge [Re: RFC6724-bis?]
>>>>
>>>>
>>>>              Vasilenko Eduard <[e-mail] <mailto:[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.
>>>>
>>>>                   > But how remote ULA prefix would be known to the 
>>>> local router?  If
>>>>
>>>>              It can't, which is fine.
>>>>
>>>>              If there are multiple ULAs after a merger, then we do what Brian and David described and send RIOs or PIOs.
>>>>
>>>>                   > proper routing is in place then no problem exists in the first place,
>>>>                   > the whole FC/7 could be prioritized.
>>>>
>>>>              I don't think that non-local ULAs *should* be prioritized.
>>>>              I think that it's actually a problem as more and more sites use ULA for significant internal things, and those addresses leak into other sites.
>>>>
>>>>
>>>>              --
>>>>              Michael Richardson <[e-mail] 
>>>> <mailto:[e-mail]>>, Sandelman Software Works  -= 
>>>> IPv6 IoT consulting =-
>>>>
>>>>
>>>>
>>>>              --------------------------------------------------------------------
>>>>              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>
>>>>          
>>>> -------------------------------------------------------------------
>>>> -
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> - 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
>> --------------------------------------------------------------------