Re: RFC6724-bis?

[Ted Lemon <[e-mail]>]

To summarize, I think the disconnect we have here is over several
assumptions you are making that I do not think are widely accepted:

1. That it's easy (or even possible) to change the configuration of all the
hosts in the network in order to address this problem.
2. That a static configuration on a host is the right idea—that the host
never goes to another network.
3. That the address that we can't reach was published in the DNS.
4. That the publisher of the address stands to lose if it is not reachable.

I think that these assumptions, while they may be correct in some isolated
cases, are generally not correct, and this is why you think that editing
the gai.conf file (wihch I have never heard of before, by the way) is a
solution to this problem, whereas other participants in the discussion are
dismissing this as a possible solution. Does that make sense (not asking
you to agree with me—just does it make sense that this is why we aren't
agreeing)?


On Sun, Oct 9, 2022 at 11:54 PM Vasilenko Eduard <vasilenko.eduard=
[e-mail]> wrote:

> I would like to say thanks to Michael Richardson who has shown me
> something relevant to the discussion.
>
> IMHO: it still does not discard my proposal but needs to be disclosed.
>
>
>
> Use case:
>
> A)      My proposal accepted: fc00::/7     45    13
>
> B)      Some company uses internally ULA and announced it to the global
> DNS (by mistake) for the webserver (together with GUA).
>
> C)      The second company (in a different part of the globe) uses ULA
> too (/48 prefix is different)
>
> D)     The second company host is trying to access the Webserver of the
> first company
>
> It looks like the company merge for the host: it has a local ULA prefix
> and DNS has shown different ULA prefixes.
>
> ULA_DA/ULA_SA have the same label (13) and precedence (45) above GUA (40).
>
> The host would fail to connect to the web server.
>
> IMHO: it is not a problem: the admin of the DNS in the first company is
> punished – his resources are not available because he has announced ULA to
> the Internet. Nobody else was hurt except the guilty one.
>
>
>
> But it is possible to change a little gai.conf to resolve this case:
> fc00::/7     37    13
>
> Precedence 37 is below 40. Hence, GUA/GUA would be chosen. The host would
> connect by GUA.
>
>
>
> I still believe that static “fc00::/7     45    13” is better.
>
>
>
> Eduard
>
> *From:* Vasilenko Eduard
> *Sent:* Monday, September 26, 2022 11:34 AM
> *To:* 'Ted Lemon' <[e-mail]>
> *Cc:* David Farmer <[e-mail]>; 6man WG <[e-mail]>
> *Subject:* RE: RFC6724-bis?
>
>
>
> Agree, RFC 6724 looks very complex but right anyway. That says something
> about authors.
>
>
>
> But I am proposing to keep it as it is. Just change one number in the
> configuration file (gai.conf).
>
> Other people propose to modify it more radically.
>
> Hence, I am more in line with the message “see how good is the document”.
>
>
>
> By the way, it is VERY bad that IPv6 needs such complex documents. KISS is
> completely broken.
>
> Ed/
>
> *From:* Ted Lemon [mailto:[e-mail] <[e-mail]>]
> *Sent:* Friday, September 23, 2022 10:15 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* David Farmer <[e-mail]>; 6man WG <[e-mail]>
> *Subject:* Re: RFC6724-bis?
>
>
>
> What I mean by saying the document is incredibly good is just that it
> anticipated every single issue I ran into while implementing the initial
> Thread Border Router work and had a correct solution for it, which worked.
> Except for the foreign ULA issue. Where I've run into problems, it's where
> the implementation did not follow the RFC.
>
>
>
> On Fri, Sep 23, 2022 at 2:02 PM Vasilenko Eduard <
> [e-mail]> wrote:
>
> I missed the message when the consensus on “how to return ULA into active”
> has been achieved.
>
> If it is the case – then not many reasons to continue the discussion.
>
>
>
> But I hope that if consensus did happen then many people should understand
> the use case when
>
> fc00::/7     45    13
>
> does not work.
>
>
>
> IMHO: Refernece to “how genius some authors are” is not an answer to the
> technical question.
>
> By the way, I agree about “genius”.
>
>
>
> Eduard
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Friday, September 23, 2022 8:44 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* David Farmer <[e-mail]>; 6man WG <[e-mail]>
> *Subject:* Re: RFC6724-bis?
>
>
>
> You aren't required to be a developer with a million devices in the field.
> At all. I don't know if any of the authors of 6724 were in that situation
> when they worked on the document, and the document is incredibly good.
>
>
>
> However, you should have some reason for objecting to a solution that has
> rough consensus, if only for the practical reason that if you don't, there
> is no chance that what you say will have any bearing on the consensus. I
> mention my situation because it helps to explain why I think what I do
> about this problem. But be careful not to put words in my mouth. I'm not
> saying I don't think networks should be managed. I'm saying, realistically,
> we have to handle situations where the network may be in a somewhat
> ambiguous or incorrect state, and this is not fixable. Our protocols are
> not perfect, and our implementations are not perfect, and our operators
> don't always do the right thing.
>
>
>
> To put this in perspective, if "don't bother to address the uncommon
> situation" were a convincing argument, I could argue that ND should not
> retransmit. If there's no response to the original NS, then the neighbor is
> not present. This would definitely reduce the amount of useless multicast
> traffic sent. And in the common case, where the network is lightly
> utilized, we almost always get a response to the first NS. So
> retransmission is only for the uncommon case. I know you were not
> suggesting this, and I'm definitely using reductio ad absurdum here, but
> there's a reason why this is a useful tactic in a debate. :)
>
>
>
> On Fri, Sep 23, 2022 at 1:17 PM Vasilenko Eduard <
> [e-mail]> wrote:
>
> Hi Ted,
>
> Thanks for the long message.
>
> Unfortunately, it is not an explanation what is the problem with a simple
> solution: fc00::/7     45    13
>
> Should be a use case that does not work. I do not see any. RFC 6724 has
> resolved RFC 5200 concerns, at least in respect of ULA.
>
> My motivation: it is a very simple solution and it should work now.
>
>
>
> About your case from IETF 113 that is related to ULA:
>
> You have presented a routed network (with many hops) where you do not want
> the complexity of routing.
>
> In a normal routing network, all routers know the best path to any
> particular prefix (especially routers on the default routing path).
>
> You would like to have a solution that would not need routing.
>
> As you said, “The product has to work in situations where the network
> administrators are completely nonexistent”.
>
> It is a perfectly good reason.
>
> Anyway, routers should converge somehow on the common view about available
> prefixes. Else they would forward not appropriate.
>
> Just I am not sure that it is possible to tweak on-link protocols to help
> with off-link information (especially multi-hop).
>
> Maybe https://datatracker.ietf.org/wg/anima/about/ would help.
>
> Maybe MLSN (multi-link subnet) would help ( integrate all links into one).
>
> Maybe something else is needed (HomeNet2?).
>
> Maybe ULA-specific prefixes (/48) would help somehow. I do not have enough
> imagination to understand why (and you are not ready to explain yet).
>
> Should Enterprise wait till you would develop and disclose the solution?
>
> Maybe. Because your task is very important (I am serious here!).
>
>
>
> IMHO: chances are good that even after you would find a solution for the
> problem,
>
> Just changing precedence “3” to “45” in gai.conf would be still the best
> for ULA.
>
> Then maybe you would permit to use ULA now while you are thinking over the
> big challenge.
>
> Modification for RFC 6724 may be done later if your solution would need it.
>
>
>
> > I'm looking at this as an implementer of a product of which millions of
> units will be sold.
>
> Is it mandatory to be equal for the discussion?
>
>
>
> > 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?
>
> I had an assumption that everybody here is thinking about “public good”,
> not a person's or company's interests.
>
> IMHO: It is the root cause.
>
>
>
> > "oh boy, I should change my product." So that's why I see you as being
> in the rough.
>
> Agree. It is better not to stress any point so tough – people do not like
> it.
>
> But I was asking only technical questions … nothing personal.
>
> My bad. Sorry. I need to do something about it.
>
>
>
> Eduard
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Friday, September 23, 2022 4:37 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* David Farmer <[e-mail]>; 6man WG <[e-mail]>
> *Subject:* 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=
> [e-mail]> 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:[e-mail]] *On Behalf Of *David Farmer
> *Sent:* Friday, September 23, 2022 2:17 PM
> *To:* Vasilenko Eduard <vasilenko.eduard=[e-mail]>
> *Cc:* 6man WG <[e-mail]>
> *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=
> [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
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>