Re: RFC6724-bis?

I think it is a problem, and I agree that this is a very risky (and
probably incorrect) change.

On Fri, Sep 23, 2022 at 6:10 PM David Farmer <farmer=
40umn.edu@dmarc.ietf.org> wrote:

> To be honest, I don't understand the nuances of RFC 6724 well enough to
> judge what may or may not break by changing the priority for the whole ULA
> prefix (fc00::/7).
>
> RFC 6724, section 10.6, states the following;
>
>    By default, global IPv6 destinations are preferred over
>    ULA destinations, since an arbitrary ULA is not necessarily
>    reachable:
>
>   .....
>
>    Since ULAs are defined to have a /48 site prefix, an implementation
>    might choose to add such a row automatically on a machine with a ULA.
>
> I've been told that implementations that follow the suggestion quoted
> above don't have the problem we are discussing. Therefore, I think the most
> conservative change to RFC 6724 is to change the above from a suggestion to
> a mandatory and automatic feature. This really doesn't change how RFC 6724
> operates, and I feel this change is completely consistent with RFC 6724.
> It's not likely to break anything, it is already part of RFC6724, and there
> are successful implementations of it.
>
> Whereas changing the priority for the whole ULA prefix (fc00::/7) seems
> like a much larger change to me, fraught with much more uncertainty, and
> I'm much more worried about unintended consequences. It's quite common to
> fix one bug and create three others. However, if the authors of RFC 6724
> are comfortable with changing the priority of the whole ULA prefix
> (fc00::/7) and essentially eliminating the need for section 10.6. I guess
> I'd be ok with that.
>
> Nevertheless, the concern that "arbitrary ULA is not necessarily
> reachable" stated in RFC 6724 or that I've been calling remote ULAs, still
> rings true for me, and I need to understand why that isn't a problem if we
> change the priority of the whole ULA prefix (fc00::/7), as you are
> suggesting.
>
> Thanks
>
> On Fri, Sep 23, 2022 at 7:31 AM Vasilenko Eduard <vasilenko.eduard=
> 40huawei.com@dmarc.ietf.org> wrote:
>
>> Hi David, thanks. But it is not enough for an explanation.
>>
>>
>>
>> Section 2.2.2 RFC 5200 example is just not relevant to the current
>> situation, it was relevant to RFC 3484.
>>
>> It is solved by default because the separate label has been attached to
>> ULA in RFC 6724.
>>
>> Now, IPv4_DA/IPv4_SA would be prioritized above GUA_DA/ULA_SA because of
>> rule 5 (label match).
>>
>> No problem.
>>
>>
>>
>> If you have any other scenario that may affect static ULA prioritization
>> above anything else – please show it.
>>
>>
>>
>> Why do you believe that address expansion above 2000::/3 would be
>> affected?
>>
>> If people would continue to use ::/0 as the default and RFC6724 has it in
>> the RC6724 table
>>
>> Then how the problem could happen?
>>
>> I do not understand this use case too.
>>
>>
>>
>> > Let’s only fix the problem and not make new problems for the next
>> generation of network engineers and operators.
>>
>> I claim that the ULA problem is very small. It may be treated as a pure
>> configuration problem. Just add static:
>>
>>      fc00::/7               45    13
>>
>> to gai.conf. Hence, the draft in v6ops is enough.
>>
>>
>>
>> PS: it does not solve MHMP but it is a problem that possible to separate
>>
>>
>>
>> Eduard
>>
>> *From:* ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *David Farmer
>> *Sent:* Friday, September 23, 2022 2:17 PM
>> *To:* Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
>> *Cc:* 6man WG <ipv6@ietf.org>
>> *Subject:* Re: RFC6724-bis?
>>
>>
>>
>> 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.
>>
>>
>>
>> Let’s only fix the problem and not make new problems for the next
>> generation of network engineers and operators.
>>
>>
>>
>> Thanks
>>
>>
>>
>> On Fri, Sep 23, 2022 at 02:27 Vasilenko Eduard <vasilenko.eduard=
>> 40huawei.com@dmarc.ietf.org> 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:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
>> Sent: Friday, September 23, 2022 4:47 AM
>> To: Ted Lemon <mellon@fugue.com>; David Farmer <farmer=
>> 40umn.edu@dmarc.ietf.org>
>> Cc: 6man WG <ipv6@ietf.org>
>> 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=
>> 40umn.edu@dmarc.ietf.org <mailto:40umn.edu@dmarc.ietf.org>>
>> >
>> >     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
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>> --
>>
>> ===============================================
>> David Farmer               Email:farmer@umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE        Phone: 612-626-0815
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>>
>
>
> --
> ===============================================
> David Farmer               Email:farmer@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>