Re: RFC6724-bis?

Ted Lemon <mellon@fugue.com> wrote:
    > To summarize, I think the disconnect we have here is over several
    > assumptions you are making that I do not think are widely accepted:

Thank you for this summary.

    > 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.

I'm not a fan of gai.conf.  It's a configuration for a libc call getaddrinfo().
It's totally unclear to me that it should even be global for a host, and
there are no overrides (environment variables) that are standard.  It really
feels to me like it should have been done by a kernel setting, which the
kernel could be told to tune differently for different users/environments/etc.
I'm thinking NFS vs SMTP-Submit usage for instance.

    > 2. That a static configuration on a host is the right idea—that the host
    > never goes to another network.

On this we agree very strongly.
One of the complex examples is a laptop from org A, which is located on org
B's network, and has VPNs up to orgA *AND* orgC.  It's not fictional, and
it's not just me.   ULAs for VPNs is one of the killer-aspects for IPv6.
{This afternoon, I have to help some people at a TLA.GOV reach 192.168.1.x
network from their other 192.168.1.x 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.

On this I totally agree.
I don't accept that ULA in DNS is a mistake.  I think it's why we have ULA,
and not a repeat of RFC1918.

    > 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

POSIX speaks of it, but I imagine Apple was smart enough not to have an
actual file.

    > 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)?

I'm for inserting the /48 for any directly connected /64, and also having
some RIO/PIO L=0/A=0 extension that adds a second one.

    > On Sun, Oct 9, 2022 at 11:54 PM Vasilenko Eduard <vasilenko.eduard=
    > 40huawei.com@dmarc.ietf.org> 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' <mellon@fugue.com>
    >> *Cc:* David Farmer <farmer@umn.edu>; 6man WG <ipv6@ietf.org>
    >> *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:mellon@fugue.com <mellon@fugue.com>]
    >> *Sent:* Friday, September 23, 2022 10:15 PM
    >> *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com>
    >> *Cc:* David Farmer <farmer@umn.edu>; 6man WG <ipv6@ietf.org>
    >> *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 <
    >> vasilenko.eduard@huawei.com> 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:mellon@fugue.com]
    >> *Sent:* Friday, September 23, 2022 8:44 PM
    >> *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com>
    >> *Cc:* David Farmer <farmer@umn.edu>; 6man WG <ipv6@ietf.org>
    >> *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 <
    >> vasilenko.eduard@huawei.com> 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:mellon@fugue.com]
    >> *Sent:* Friday, September 23, 2022 4:37 PM
    >> *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com>
    >> *Cc:* David Farmer <farmer@umn.edu>; 6man WG <ipv6@ietf.org>
    >> *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=
    >> 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
    >> --------------------------------------------------------------------
    >>
    >> --------------------------------------------------------------------
    >> IETF IPv6 working group mailing list
    >> ipv6@ietf.org
    >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    >> --------------------------------------------------------------------
    >>

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > ipv6@ietf.org
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

Re: RFC6724-bis?

Attachment: signature.asc