Re: RFC6724-bis?

Eduard, I think the first thing to say here is that you're pretty clearly
in the rough. If you want to get your point across, you need to explain
your objection in a way that sways the consensus, not simply insist that we
explain ourselves better.

That said, I think it's reasonable to ask for a better explanation,
regardless, so let me see if I can do that. I'm looking at this as an
implementer of a product of which millions of units will be sold. The
product has to work in situations where the network administrators are
completely nonexistent. So a "network misconfiguration" in this context is
actually just the interaction of two different products the implementers of
which made different base assumptions.

What I want, in this situation, is for things to work in as many cases as
possible. I don't want to be inundated with bug reports, simply put. Of
course, it's possible that something will go wrong, but if we can
anticipate a particular sort of dysfunction, and do something to address
it, that's definitely going to make things better. And I have seen this
particular dysfunction happen in bug reports, so it's not the case that I'm
just theorizing here.

Now, it's entirely possible that what I'm doing in the product I'm talking
about is incorrect, and that you know why it's incorrect and can say so.
But you haven't done that yet—you haven't said something that makes me
think "oh boy, I should change my product." So that's why I see you as
being in the rough.

I don't actually know what your motivation is here. Are you a network
administrator? An IPv6 stack implementer? Are you concerned about code
complexity? It would help if you were to express an actual situation where
the current consensus would affect a specific thing that you feel
responsible for, whether that's an implementation, a network, or something
else.

On Fri, Sep 23, 2022 at 8: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
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>