> On Oct 12, 2015, at 2:43 PM, Anton Samsonov <[email protected]> wrote: > > Hello! > > When I first bothered with configuring a 6to4 address on my server a couple > of years ago, I also tried to add that to the pool, but got the following: > > 2002:xxxx:yyyy::z > Bad IP address: 6TO4 > > As recommended for comments and questions, I wrote to Ask Bjørn Hansen > for an explanation, but he just said that this topic was not for discussion > and redirected me to this mailing list as the only source of information. > Quite some time passed since then, one of my IPv4 addresses has changed, > so I retried again recently, but the result was no different. > > If someone here has any insight on why 6to4 (and probably other transitional > technologies) addresses are not eligible to be included in the pool, it would > be interesting to know the reasoning behind this blacklisting. > > Yes, I do understand that 6to4 is, by definition, less "straightforward" than > a "true" IPv6. Theoretically, it may introduce large and asymmetric delays, > decreased reliability. But, practically, is it really any different from > regular networking? If a time server is contacted across the continent, > or even in the same city, who guarantees that the delay will be low and equal > in both directions, or that the routes taken will ever be the same? > > Particularly, when I contact "true IPv6" servers in the same city (to be > more precise, on the same Internet exchange site as my local 6to4 gateway), > delays are in the range from 4 to 7 milliseconds. Taking into account that > typical delays for IPv4 are from 2 to 5 milliseconds (again, within an IX > that my ISPs are connected), I consider the overhead as negligible. > > At the same time, I also stumble on IPv6 servers that are allowed in the pool > while being no more than just a tunnel to a IPv6 broker, with entry nodes > no closer than a few countries away, or even across the ocean, so resulting > delays are as large as 110 milliseconds. Why are those considered any better > than 6to4, if they are actually inferior? If the intention of the pool masters > is to blacklist any tunneling technology, then why not blacklist all tunnel > providers (including VPN operators), as their addresses are not secret?
I similarly have found this frustrating with people who pretend that a tunnel to someone is valuable enough to be in the pool vs native connectivity. Regarding 6to4 addresses, these are not widely reachable on networks. There were a lot of issues with 6to4 relays that could lead to abuse or other problems when they are port scanned or otherwise due to the ‘natural’ background radiation of the internet. It was a neat solution for a problem that turned out to not be of large enough of a problem to be solved by anything more than the geeky. > But the thing that puzzles me the most is why to blacklist anything at all? > NTP is able to select the best of the best of the best servers automatically > and keep all falsetickers, unreliable and simply too distant servers out. > Then why the pool places own artificial restrictions atop of that? There are issues with the NTP Pool. there’s no good way for me to link my v4 and v6 host that are the same together. This means you might get answers from 3.pool.ntp.org and 2.pool.ntp.org that are the same host which is not desirable for a robust set of answers. There’s a lot of politics in the NTP community that exist as it’s a very esoteric thing to write an implementation that can’t face a time skew risk. Options like -g which are default are not helpful if you want to avoid being lied to but most servers need their time to be set by automation in the first place. Plus most admins are lazy and prefer to do what ‘just works’. Myself I would cron ntpdate -u against some servers on really bad hardware that couldn’t keep time properly. As for the network part, most networks are getting IPv6 these days. I’m seeing traffic around 2% and growing at my $dayjob. 2% gets quite large when you’re talking about Tb/s as the base units :) You should try and seek out networks that do IPv6 and make it available to you. Most networks have an IPv6 plan and per measurements at Facebook when the infrastructure is properly enabled you see about a 15% speedup compared to IPv4. This is likely due to less latency through NAT or similar techniques. I would suspect that anything like NAT64 or 6to4 would introduce comparable delays and negate the IPv6 speedup. The same goes for if someone is doing 6PE to work around non-IPv6 enabled or capable equipment. http://www.lightreading.com/ethernet-ip/ip-protocols-software/facebook-ipv6-is-a-real-world-big-deal/a/d-id/718395 https://youtu.be/_7rcAIbvzVY I can say that blocking 6to4 as it’s of limited use is the right thing to do. This was already documented in https://tools.ietf.org/html/rfc7526 as well. Hopefully this is helpful for you. - Jared _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
