Intention to enable IPv6 by default in 2017

I’m planning to sometime in 2017 finally making IPv6 (AAAA records) the default for the NTP Pool.

My intention is to allow vendor zones to choose how they want to get AAAA records (or not) for their names, but the default behavior of {0.,1.,2.,3.,}pool.ntp.org will be to return AAAA records like 2.pool.ntp.org does today (and have for a few years).

10 Likes

I am not familiar with IPv6, hence the question: if a client computer has IPv6 stack available but does not acquire IPv6 ip from ISP (as most modern computers in Taiwan do), will it be able to send and receive NTP packets to and from pool servers with AAAA addresses?

Image from [Google IPv6 survey] (https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption)

To reach IPv6 servers the end machine will need an IPv6 address, or use one of the translation schemes.

If a machine has no IPv6 Internet connectivity the AAAA records will be ignored and the machine will use IPv4.

1 Like

It wouldn’t (unless you have a tunnel of sorts). The scenario you describe is really the risk for adding IPv6 to all the DNS records (and why I haven’t despite most of the big services doing IPv6).

If your local system thinks it has IPv6 it might ask for the AAAA record, get an IPv6 address and then have it timeout. You can test by configuring your client to use “2.pool.ntp.org” (which will offer IPv6 addresses when available).

1 Like

I occasionally encounter this problem during web browsing, or wgetting, when IPv6 is supported by the DNS but not the network. Eventually after a minute, the correct A record would be tried. Why wasn’t NTP designed to try all the possible A and AAAA records before giving up?

I was not aware that only the 2. entry returned anything when you did query for AAAA… I just checked and yeah if you query any of the 0., 1. or 3. zones for AAAA you just get back SOA…

Curious why was not like this from the get go? I know my ipv6 does get queries… guess the ipv6 traffic will go up if all the zones start returning AAAA when asked…

Great! Nice to seem more an more use of IPv6…

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Perhaps it’d be worth only enabling IPv6 for zones of countries with decent IPv6 adoption?

1 Like

Yeah, that might be a reasonable stepping stone until we’re at some tipping point where IPv6 is the default for more users than not.

I have opened a new thread (held by the spam filter) to try to raise awareness of this again.

Is there anything I (as a developer, and IPv6 nerd) can do to help? I had a bit of a browse of the git repo, and it looks like all that needs to happen is that line 162 of lib/NP/Model/DnsRoot.pm needs to be tuned to put a default AAAA record on the zones and then whatever’s left over smeared over the rest?

1 Like

Dunno why the system bumps this thread, but since it is bumped anyway…

Then we can start by enabling AAAA reply on in zone. India had more ivp6 users than ivp4 users since last (2018) October. People who want to test their ipv6 ntp service can join in zone and have their service stormed!
https://www.akamai.com/us/en/resources/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp

1 Like

Test test, can I post now? If so, the bump was because I posted here, and my post was immediately marked as spam 8-(

Edit: Looks like I can! I’ve submitted a pull request on Github to enable this, because I thought it was just easier to write the code than bike-shed about it 8)

2 Likes

It’s 2021, any news?

2 Likes

Bump! …???

Here are enough characters to meet the 20 minimum :slight_smile:

2 Likes

Nah, IPv6 is a poor protocol and has no future the way it’s now.

I keep running into troubles with it, where as IPv4 just works.

It’s a poor and bad designed protocol, it will never take over.

Try to ban abusers from your system, it’s almost impossible.

IPv6 should have a gateway being announced, so you can ban abusers based on their subnet, but you can’t.

Also, you should be able to direct traffic to this gateway if you wish, but you can’t.

I abandoned many IPv6 services again, as it’s crap, it’s crap. No other word for it.

In fact, if all IPv4 addresses would have been limited to 1 for a building only, we would never run out of IP’s at all.

The problems that you report just indicate that you don’t understand IPv6. They are no problems at all.

6 Likes

This absolutely needs to happen but I hope when it does there will be a notification to server owners. I have all my server “net speeds” set to 1000 Mbit for IPV6 and 10 or 25 Mbit for IPV4, to compensate for the bizarre decision to only have AAAA records on the “2.” DNS names which most people don’t know about or use. This gives me about a 50/50 split of IPV4 and IPV6 traffic to my servers. But when the other DNS names are implemented properly I’ll probably need to turn down the IPV6 net speeds to avoid a huge traffic spike. I might also shut off IPV4 on my servers entirely once the pool is distributing AAAA records properly; haven’t decided yet.

1 Like

Most DNS servers don’t even properly report IPv6.
IPv6 will not take over the way it is now.
Even in Linux it’s a mess, often you have to tell software it should use IPv6 else it doesn’t.

Just think about it, why do we even need AAAA records and the old record don’t understand IPv6.
There should be no need for new records.

It will take a long time before IPv6 will be used as standard, as they have to resolve their mess.
Let me show you and my system is IPv6 enabled:

2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether a8:a1:59:64:80:0b brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 192.168.1.111/24 brd 192.168.1.255 scope global dynamic noprefixroute eno1
       valid_lft 852272sec preferred_lft 852272sec
    inet6 fd00::ffca:b42f:3ddd:4fa9/64 scope global dynamic noprefixroute 
       valid_lft 6850sec preferred_lft 3250sec
    inet6 2a02:578:440e:0:49ae:9130:98a2:940d/64 scope global dynamic noprefixroute 
       valid_lft 6850sec preferred_lft 3250sec
    inet6 fe80::ee12:2314:af41:9cce/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Now look what happens:

nslookup ntp.heppen.be
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	ntp.heppen.be
Address: 77.109.90.72
Name:	ntp.heppen.be
Address: 89.207.129.63
Name:	ntp.heppen.be
Address: 212.187.8.48
Name:	ntp.heppen.be
Address: 5.196.189.119

Huh? I use IPv6…right?

Now look:

nslookup ntp.heppen.be 1.1.1.1
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
Name:	ntp.heppen.be
Address: 89.207.129.63
Name:	ntp.heppen.be
Address: 77.109.90.72
Name:	ntp.heppen.be
Address: 5.196.189.119
Name:	ntp.heppen.be
Address: 212.187.8.48
Name:	ntp.heppen.be
Address: 2a00:7b80:477:21::9dcb:d174
Name:	ntp.heppen.be
Address: 2a02:578:440e:0:aaa1:59ff:fe3d:5b53
Name:	ntp.heppen.be
Address: 2001:41d0:303:1585::718e:a506
Name:	ntp.heppen.be
Address: 2a02:578:440e:0:5f05:fa04:1720:d90f

Strange is, my modem gives the IPv6 adres and has it enabled. but it doesn’t resolve IPv6 adresses.

But hey…let’s try this:

nslookup ntp6.heppen.be
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	ntp6.heppen.be
Address: 5.135.125.103
Name:	ntp6.heppen.be
Address: 2001:41d0:203:654d::8f37:5630

Oh it does resolve IPv6…but not as a priority.

How much more stupid things you want to see?

It will not replace IPv4 if it keeps doing this stuff.

Sorry, I rather not use it. IPv4 for me and I will not change that if I do not have to do so.

Testing 123…

for a in $(dig +short ntp.heppen.be AAAA); do ./ntpdetail $a; done [1]

Your IPv6 addresses (except for 2001:41d0:203:654d::8f37:5630 [2]) work fine.

Thank you.

[1] ntpdetail.go
[2] This is ntp6.heppen.be, of which IPv4 also does not work

1 Like