The time has come: we must enable IPv6 entirely

Pool Development
21

@Bas your ignorance about IPv6 is not an excuse for us not to use-it. You can have your own opinions but the reality is that you are wayyy off of what the actual usage and use-case of IPv6 is. So please don’t continue with you anti-v6 bullshit and v4 ignorance on this thread and lets debate about the original question.

Personally I’m all for it. As for really good load-related question, we could “canary-release” the AAAA record starting with one continent (or country) first, and see how it goes ?

6 Likes
22

If we do not add IPv6 addresses to the names other than 2.pool.ntp.org, the world will circumvent us. For example, on CentOS 8, in the file /etc/chrony.conf contains the following default entry:
pool 2.centos.pool.ntp.org iburst
(There isn’t 0, 1, 3.centos.pool.ntp.org entry there.)
The number 2 is not accidental, for the time being only that has IPv6 addresses.

If we add to 3.pool.ntp.org IPv6 addresses, the usage of the IPv6 NTP servers will not double. The modern client systems configured like CentOS 8 will not increase their access over IPv6, since they are already fully doing it.

5 Likes
23

Sorry for my ignorance with the DNS / NTP / pool backend setup but the network guy in me try to understand.

“2.pool.ntp.org” is answering some AAAA records that are load-balancers, servers, something!. The fact that [0,1,3].pool.ntp.org is not doing the same is a question of performance to avoid an overload of the same bunch of “equipment” ? Is there an overload caused by the fact those servers answers IPV4 and IPV6 ?

24

One more observation: documentation suggests to use pool.ntp.org preferably. However, there is never an AAAA-record handed out in that case. So once we are happy and confident with AAAA’s on 3.pool.ntp.org (and maybe at some point 0 and 1 as well), the next step would be to look at pool.ntp.org.

3 Likes
25

Marco, don’t you get it? Nobody uses IPv6 on purpose, all systems are reachable via both.
As such IPv6 and IPv4 are the same and this will not change.
There is also no need to change as almost everybody uses NAT/PAT for their private network.
The problem of exhausting IP’s has long been solved.
As more and more companies release reserved IP4-ranges, the need for IPv6 will become absolete.

World IPv6 Day was announced on January 12, 2011, we are 10 years further, it has not been adopted.
Ergo it will never be adopted and probably replaced in the near future.

If the majority of people reject something, you can push all you like, it will not be the dominant system.

Look at VHS, Betamax and V2000… :slight_smile:

26

I recently added a new server to the US Pool with support for ipv4 and ipv6. Even setting netspeed at most, I get on average only 250pps of NTP ipv6 traffic, while ipv4 traffic is around 6000 pps.
I would be happy to see more efforts to add AAAA records to pool domains.

2 Likes
27

Pretty much the same here… almost nothing on IPV6 side and it’s supposed to be the way to go.

28

Are they?

You probably know just as well as I do, that running two separate servers in a homework that should both be reachable on port 80 from the outside isn’t a trivial thing to do with NAT-ed IPv4. You have probably also seen the many topics here of people finding it hard to run a pool-server behind NAT.
Why? Because NAT is a hack. A workaround, invented to combat the shortage of IPv4 on the short term, while a new addressing scheme was being developed. Yes, it does the trick - to some extend - but it still is a hack. And with ‘Carrier Grade NAT’, it’s becoming an even dirtier hack too.

Experts (like Vint Cerf himself, but many others as well) have acknowledged this already a long time ago and this led to the development of a new scheme; IPv6.

Making the switch from IPv4 to IPv6 hasn’t been easy. Partly because of the succes of NAT that reduced the urgency for change, partly because they didn’t make it backward compatible and partly because of people like you, who resist change.

But although progress is perhaps slow, it is steady.

Please inform yourself and look at the many independent statistics that where presented to you in this thread:

https://www.google.com/intl/en/ipv6/statistics.html
https://stats.labs.apnic.net/ipv6/

But also:
https://www.facebook.com/ipv6/
https://www.akamai.com/us/en/resources/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp
etc.

I assume you are also aware that many of the populair sites on the internet are available over IPv6. Like LinkedIn, Facebook, Google, Netflix and quite a few others. Even this forum is reachable over IPv6.

Simply because you want IPv6 to be a failure, doesn’t mean it is.

2 Likes
29

Well, this is exactly my point!

If the DNS of the NTP-pool hardly hands out any AAAA-records, how are you supposed to receive any clients via IPv6?

3 Likes
30

I just don’t know what to say, somebody has to say something about IPV6 because the pool is saying " ok folks, let’s join your IPV6 server to the pool ", but nobody is polling it.

I don’t get the point to only have 2.pool.ntp.org with AAAA records. A lot of systems devices are not supporting 4 ntp servers or people are just using " pool.ntp.org " or " [country-code].pool.ntp.org " but no AAAA records are being answered for any of those 2 entries…

We need an update related to that news dated from 2013 :
https://news.ntppool.org/2013/06/ipv6-monitoring-problems-for-german-servers/

[…] Also this is the answer to “why don’t we have IPv6 servers by default on all the pool zones” yet. As you might know only “2.pool.ntp.org” (and 2.debian.pool.ntp.org, etc) returns AAAA records currently. […]

So, nothing since 2013 ? No AAAA records because of a monitoring problem that happened in 2013 ?

1 Like
31

Neither do I as well as others who have responded in this and various other threads. Even @ask has been wanting to improve this since 2017, but still it didn’t happen. :disappointed:

@Kyle, @NTPman, @frank, @Clock and @ebahapo proposed to start conservative and add another AAAA on 3.pool.ntp.org for instance. Excellent idea!

And it should be a trivial (and harmless) thing to do, when looking at:

https://github.com/abh/ntppool/blob/main/lib/NP/Model/DnsRoot.pm#L168

Adding AAAA’s to pool.ntp.org at some point would also be a very good idea, in my mind. Although this might be just a bit trickier and require a little more thought.

3 Likes
32

I have asked somewhere in the forum but forget where it was… AFAIK if a system has both IPv4 and v6 connectivity, connections will prefer using IPv6. So in SNTP scenario:

  1. Is it possible for a system to think it has IPv6 connectivity but in fact it does not (say, leased IPv6 address from router without actual route)? If true, the client may try to query IPv6 pool servers first and cannot get a response, or need more time waiting for its timeout before fallback trying IPv4 pool servers.
  2. For clients with usable IPv6 connectivity, will they stick with IPv6 pool servers unless none are available? Since we may have less “IPv6 pool server/ all pool server” ratio than “IPv6 enabled user/ all user” ratio in a given zone, enabling full IPv6 reply in such zone may cause the traffic be concentrated on IPv6 servers and cause disruptions.

Disclaimer: I am not familiar with IPv6 (not an IPv6 user), these are impressions only.

33

Hi Alica,

Yes.

Unless Happy Eyeballs is implemented properly this is indeed the case. What will happen is: try IPv6 first, than try IPv4. This works without causing big problems. For instance, ‘ntpdate’ does this, so do ‘debian-ntpdate’ and ‘systemd-timesyncd’.

So does Mac OSX (not able to test Windows, since I have no access to such a device).

But ‘ntpdig’ (with and without the “-c” option) didn’t do the trick for me. It also has the “-4” option though, by which a problem can be solved. But ‘sntp’ on the other hand does a good job (I tried 1:4.2.8p12+dfsg-3ubuntu4.20.04.1).

The ntp-daemons (both NTPd en NTPsec) tend to stick to a (non-functional) IP address (v4 or v6, doesn’t matter) when the ‘server’ option is given, but when the ‘pool’ option is used instead, NTPsec is perfectly able to switch from (broken) IPv6 to (functional) IPv4 quickly. NTPd took a little longer, according to some preliminary testing[1] I did. Chrony works well too with the pool directive, not so much with the server directive, so it seems. Same for openntpd; using the servers directive (with the ‘s’) recovers faster than ‘server’ (without the ‘s’).

I presume the behavior is the same as with IPv4.

The good news is; these ratios seem pretty good. From global, to regional, all the way to country-level; it’s actually pretty nice. Maybe some exceptions, like Brazil (25% IPv6 pool servers, compared to 40% IPv6 users), but that doesn’t seem to be a major problem. I already receive quite some IPv6-traffic on my IPv6-only servers in Europe from Brazil, so apparently this is covered by GeoDNS also.

Long story short; things are looking good. We could definitely add at least one more AAA to the pool (say 3.pool.ntp.org or so - probably 1.pool.ntp.org as well) and then gradually take it from there via region/country-zones, vendor-zones, 0.pool.ntp.org and finally pool.ntp.org itself.

Finally: let’s not forget; many major services are already reachable via IPv6 for a long time (Youtube, Google, Facebook and many others). Users will notice if their IPv6 is broken. So non-functional IPv6 connections, even though happy eyeballs tends to hide them from the user, are not nearly as common today as they where like a decade or so ago.

[1] If you want to test for yourself, here are three hostnames with broken (unreachable) IPv6-addresses: eyeball.forfun.net, eyeballs.forfun.net and happyeyeballs.forfun.net. Disclaimer: I may not keep them present in the zone forever, but for now I will leave them there for a while.

34

You can show numbers from big tech sites that have enabled IPv6.
But there is no adoption of IPv6, a client can try to connect via IPv6 when it’s enabled in the router.
However, there is no content that is different or make anybody need IPv6.

From a client side IPv6 is just a easy as IPv4 is, but from the server-side it’s a nightmare.
Therefor many sysop’s ask for 1 entrypoint and a form of NAT.
Because if you change your Lan-adapter the MAC will change and IPv6 will alter the WAN-IP in a lot of cases.
If you set the IP totally manual, you can, but if you change ISP, you need to reprogram all machines as well as all DNS-entries.

You can not simply change the entry-point like you can with IPv4.

I do not resist change, I installed and used IPv6 and ran in all those troubles, in the end costing me many days to fix it all again.
Change is fine by me, if they didn’t smoke a lot of crack and then release it on the world :slight_smile:

35

Just to make sure we are on the same page; the statistics in the urls’ show the percentage of clients connecting to big tech (and other) sites. You do realize that, right?

Luckily there isn’t. Because that means it works as designed.

2 Likes
36

So, the same as DHCP if your mac address changes right ?
You have static v4 assigned to your servers ? well, you should do to for v6 and not use autoconf.

So, like ipv4 right ? :joy:.

Seeing what you said above, I can only imagine. If you use brick to drive a nail you’re going to have a hard time

3 Likes
37

Summarizing a rather long discussion:

There seems to be consensus regarding a change towards more AAAA records. It has a number of benefits as mentioned in this thread.

@bas has a strong opinion about IPv6 (clearly not a big fan) but he hasn’t explained what exactly would break if AAAA-records were added to 1.pool.ntp.org and 3.pool.ntp.org. Maybe he agrees that nothing would break, but he just doesn’t want IPv6 to thrive? He’s entitled to that opinion of course, but it is beside the point (of this topic).

At the moment the amount of IPv6 servers in the pool grows harder than the amount of IPv4 servers.The current ratio of IPv6-servers is already good in pace with the (global) ratio of IPv6-clients, actually a bit better. It would really be interesting to look at total capacity too (for instance; I have my IPv4-server behind NAT at a very low connection speed while via IPv6 it is set to maximum, so just counting servers is maybe not enough. I also have some IPv6-only VPS-es running in the pool by the way, because they are very cheap).

So really there is nothing in the way of adding AAAA-records to 1.pool.ntp.org (and 3.pool.ntp.org). It seems a perfectly safe thing to do. We can take it from there at a later point.

I am sure @ask agrees and would have gotten this done already back in 2017, if it weren’t for his busy schedule.

So let’s hope he will find some time to do this soon.

(in any case before the Chinese go wild: Notice on Accelerating the Large- scale Deployment and Application of Internet Protocol Version 6 (IPv6))

2 Likes
38

No, as I only need to change the DNS to my router-IP, after NAT/PAT nothing needs to change.
You pinpoint our problem with IPv6 exactly, we want 1 entry-point if we choose to do so, but you can’t.

If I change ISP and get a new static-IP, all I have to do is change the DNS entries to that IP only.
With IPv6 you can’t.

39

Bas,

You have clearly expressed your opinions about IPv6.

But this topic is about something different. It’s about whether or not we can safely add some more AAAA-records to the DNS of pool.ntp.org. Currently only 2.pool.ntp.org has an AAAA record. I propose to extend this to at least 1.pool.ntp.org (and probably to 3.pool.ntp.org as well) and I have substantiated with arguments, facts and figures why I believe this is a sensible thing to do.

Perhaps you can spend your time trying to explain to the audience what exactly would break if we did this?

That seems more constructive than what you have contributed to this topic thus far.

Thank you.

1 Like
40

As an operator of several servers in the pool, I’d like to see more traffic move from IPv4 to IPv6. Currently IPv6 is just a fraction of the IPv4 traffic.

I’m not sure how much impact would have enabling IPv6 in the other numbered zones. IIRC most of the NTP traffic comes from the non-numbered zones and enabling IPv6 there would likely break some clients.

A safer approach would be to add a completely new zone, e.g. all.*.pool.ntp.org. It would contain both IPv4 and IPv6 addresses, and it would be explicitly meant for clients that can handle broken IPv4 or IPv6 connectivity. The pool directive implemented in some of the clients would be an ideal use case for this zone.

The new zone could also try to solve the problem with removed servers having a long tail of old ntpd-like clients that don’t reresolve the address when it stops responding. The zone could be meant only for clients that can refresh the address. This would allow more servers to join the pool. They could be marked as “can be removed at any time” and their address returned only in this zone. As the clients are required to refresh the address, the traffic should stop quickly.

1 Like