At Sat, 01 Feb 2025 06:25:37 +0700, Robert Elz <kre%munnari.OZ.AU@localhost> wrote: Subject: Re: Anita much slower? (IPv6 use is too aggressive) > > Date: Fri, 31 Jan 2025 13:42:18 -0800 > From: "Greg A. Woods" <woods%planix.ca@localhost> > Message-ID: <m1tdymI-00Mo5zC@more.local> > > | One should only have to use IPv6 if one really has to use IPv6! > > I disagree, IPv6 is a much better protocol in general Sure, I agree, but the in the real world, at least in some still significant parts of the real world, IPv6 is either not available, or not well configured, or some such problem, as is evidenced by the ongoing complaints of "NetBSD is slow", with who knows how many going unreported. > | I think forcing IPv6 attempts when it might not work, and when it is not > | necessary, is always wrong. > > Again, I disagree, finding out that something is not correctly configured, > so it can get fixed, is the only way that we ever get things fixed, if the > issues just get "worked around" then nothing ever truly improves. I understand that problem all too well, but the average user will never agree, especially when their IPv4 system had no problem. Use what works now, not what "should" work. Forcing these kinds of issues is for experts, not for Joe User wanting to try a different OS out for the first time. (Just like turning compiler warnings into errors is something that should only be forced on _active_ developers!) > | (I now have IPv6 working so I can't test such things easily any more.) > > Good, that was exactly the right solution to whatever problem you > previously had which has biased your opinions - others should follow > your example and fix their IPv6 configs, or complain to their ISP > or hosting provider and get things fixed. By "I now have IPv6 working" I meant I now have IPv6 connectivity through my ISP -- not that I fixed the problem NTP was having with IPv6. Actually having IPv6 connectivity makes no difference to the problem I was experiencing with NTP -- I don't run IPv6 on my internal server subnet, it's not even in my kernels, so no amount of IPv6 on my gateway would help. I could only fix that particular problem by filtering AAAA results on my DNS resolver (or at least not returning them to the server subnet). In any case Joe User doesn't even know that there is a "network" problem in the first place -- they just see NetBSD as unusably slow. They won't be getting the real problem fixed because it is entirely invisible to them. Maybe if NetBSD was able to detect the problem _quickly_ and print a non-blocking warning that explained the problem..... > My only current problem is that my local "modem" (it isn't, but you > know what I mean) forgets its state completely if it suffers a power > loss, after which it gets me a new IPv6 prefix from the ISP (no idea > why they don't just give the same one as last time) and advertises > that, but never deprecates the no longer working old prefix (as it > has no memory that such a thing ever existed). I suspect that's > just because it is rather cheap... (Of course it gets a new IPv4 > addr as well, but that's only visible outside my network, via the > evil that is NAT, so never directly affects anything internal.) Indeed I have the same problem with IPv4 on my fibre gateway as well. :-) Which reminds me I need to replace the batteries in my big UPS -- it had previously helpt keep the gateway from changing addresses for a couple of years, but the other day it died in less than an hour (it might not have lasted for the full 4-hour scheduled outage anyway, but it should have been close). It changes when the gateway resets mostly because the ISP likes it that way (they sell static addresses, but only on full business accounts), however they don't force address changes if the CPE device is able to keep requesting the same lease. I haven't really used my new IPv6 connectivity enough to even know anything about my IPv6 address prefix. My phone knows it, but I don't! -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp7ybM_Hak0E.pgp
Description: OpenPGP Digital Signature