Re: RFC6724-bis?

[Nick Buraglio <[e-mail]>]

----
nb

On Fri, Sep 23, 2022 at 6:17 AM David Farmer
<farmer=[e-mail]> wrote:
>
> Please read the first paragraph of RFC6724 section 10.6 and all it’s references very carefully. In particular, read 2.2.2 of RFC 5220.
>
> Your argument contradicts the conclusions of 2.2.2 of RFC 5220. In short, your argument is only true today while we are using 2000::/3 for GUA. When that eventually changes, and it will some day, we would have to yet again rejigger the table.
>
> RFC 6724 is almost correct, the only thing it got wrong is that the section 10.6 modifications must be mandatory and automatic, and not optional, otherwise ULA is broken and dysfunctional.

This is where my mind was going, "mandatory and automatic" feels
useful, appropriate, and achievable.

>
> Let’s only fix the problem and not make new problems for the next generation of network engineers and operators.

Agreed.

>
> Thanks
>
> On Fri, Sep 23, 2022 at 02:27 Vasilenko Eduard <vasilenko.eduard=[e-mail]> wrote:
>>
>> I still do not understand why Ted and David care about "remote ULA".
>> If this ULA has been delivered to the local host by
>> Then it has been done intentionally.
>> Such a type of misconfiguration does not make sense to optimize.
>> Hence, it is possible to operate FC/7 as a whole, no need to split it for /48s.
>>
>> Hence, why not install permanent precedence to FC/7 in gai.conf?
>> It would not play any role on the host till the local router would deliver ULA PIO.
>> And even after this, it would not be used till DNS would show the ULA destination
>> Because rule 5 (matching labels) would make GUA_DA/ULA_SA a low priority, GUA/GUA would be chosen.
>>
>> What is the problem with permanently changed FC/7 precedence even above GUA?
>>
>> Eduard
>> -----Original Message-----
>> From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
>> Sent: Friday, September 23, 2022 4:47 AM
>> To: Ted Lemon <[e-mail]>; David Farmer <farmer=[e-mail]>
>> Cc: 6man WG <[e-mail]>
>> Subject: Re: RFC6724-bis?
>>
>> On 23-Sep-22 12:50, Ted Lemon wrote:
>> > Op do 22 sep. 2022 om 20:40 schreef David Farmer <farmer=[e-mail] <mailto:[e-mail]>>
>> >
>> >     I think leaving unknown, most likely remote, ULA at a lower priority and adding the /48 or other known local ULA to the table at a higher priority automatically should help mitigate ULA in the public DNS and the possible response of turning off IPv6.
>> >
>> >     In someways those that put ULA in the public DNS get what they deserve, I’m just worried about the remote user’s response to the brokenness, causing even more brokenness.
>> >
>> >
>> > Hm, okay. I think we are all actually in agreement then, since I heard Brian admitting earlier that it might be better to dynamically update the table.
>>
>> Indeed, which was exactly why I wrote gai_wrap.py as a userland proxy for that approach.
>>
>>     Brian
>>
>> > I must have misunderstood what you meant by optimizing for the uncommon case—sorry about that!
>> >
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --
> ===============================================
> David Farmer               Email:[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
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------