FS#59806 - [systemd] Prioritize 2.arch.pool.ntp.org for IPv6 support

Attached to Project: Arch Linux
Opened by Mortan (Mortan1961) - Saturday, 25 August 2018, 17:24 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 05 January 2019, 14:10 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
systemd-timesyncd will contact servers in turn until one is found that responds. Arch uses the zones in the order of 0, 1, 2, 3. However, all pool.ntp.org zones only have IPv6 and IPv4 enabled on the 2 subdomain. All others are IPv4 only. Therefore, 2 should be placed first in order to properly provide support for IPv6/IPv4 hosts.

Additional info:
* package version(s)
systemd 239.0-2
This task depends upon

Closed by  Dave Reisner (falconindy)
Saturday, 05 January 2019, 14:10 GMT
Reason for closing:  Deferred
Additional comments about closing:  This should be fixed in the pool, not in systemd. Until then, this is a sane default and administrators are free to adjust their config as desired.
Comment by Dave Reisner (falconindy) - Saturday, 25 August 2018, 17:27 GMT
Why does only '2' provide ipv6 support? Isn't this something for the pool to fix?
Comment by Mortan (Mortan1961) - Saturday, 25 August 2018, 17:54 GMT
It is intentional: https://stefanchrist.eu/blog/2015_01_12/www.pool.ntp.org%20and%20IPv6.xhtml

I have not found any real rational for it though. There seems to be a concern of bad clients using only IPv6 when the network does not support it, although I am not aware of any clients that have this problem including systemd-timesyncd. When I was working on the chrony configuration for Arch I looked at the configuration for Fedora, Debian, and Ubuntu and they all use 2.
Comment by Dave Reisner (falconindy) - Saturday, 25 August 2018, 21:01 GMT
> There seems to be a concern of bad clients using only IPv6 when the network does not support it
This isn't a matter of bad NTP clients, but buggy IPv6 deployments by ISPs causing the OS to think the IPv6 stack is functional when it isn't. I don't think it should be up to Arch to "enforce" use of IPv6 when these cases exist. Just reorder your FallbackNTP servers (or override in NTP) in /etc/systemd/timesyncd.conf
Comment by Mortan (Mortan1961) - Saturday, 25 August 2018, 21:59 GMT
It is a matter of bad clients. The client would resolve both the A (IPv4) and AAAA (IPv6) DNS records for 2.arch.pool.ntp.org. In the scenario of a dual stack IPv6/IPv4 where the IPv6 connection is not functional, the IPv6 connection would fail and the IPv4 would succeed. A bad client would only try to resolve and connect via IPv6; this is not the case with systemd-timesyncd.

To be clear, this is not enforcing IPv6. It is enforcing IPv6 and IPv4 at the same time. This is the exact same mechanism that web browsers use for handling dual stack connections. Currently, www.archlinux.org has both A and AAAA DNS records and that works.

My point is that having support for both IPv6 and IPv4 will not cause any issue in the event that either protocol is not working. However, the current configuration does cause issues with IPv6/IPv4 dual stack and IPv6 only situations because it enforces IPv4 only behavior.
Comment by Dave Reisner (falconindy) - Saturday, 25 August 2018, 22:05 GMT
> However, the current configuration does cause issues with IPv6/IPv4 dual stack and IPv6 only situations because it enforces IPv4 only behavior.

Could you expand on this? Why wouldn't the client simply move onto the next server, as you suggest it does when IPv6 fails in the IPv4-only case?
Comment by Mortan (Mortan1961) - Saturday, 25 August 2018, 23:12 GMT
Let me explain how this works in greater detail. There are three ISP connection situations: IPv4 only, both IPv4 and IPv6, and IPv6 only.

There is of course the problem of determining what a server (NTP, SNTP, HTTPS, and everything else) supports. In the typical IPv4 only situation there is one A DNS record per domain. This is what the 0, 1, 3 NTP pool domains do.

In order to solve the problem of supporting both IPv4 and IPv6 there are two DNS records per domain. One A record for IPv4 and one AAAA record for IPv6. This is what the 2 NTP pool domain does. This is also what www.archlinux.org, www.google.com, and everything else does if they support both IPv4 and IPv6.

When connecting to 2.arch.pool.ntp.org in any ISP connection situation the client will check for both A and AAAA records and attempt to connect to both IP address for the one domain at the same time. Only in the event that there are no IP addresses that can be reached (both IPv4 and IPv6 fail) will the SNTP client move on to the next in the list. This is called Happy Eyeballs is a well tested and widely deployed IETF standard.

NTP is notorious for bad and misconfigured clients (like really bad embedded, proprietary, custom implementations that can not be updated) which is why the NTP Pool project is worried about using both A and AAAA records. But these concerns do not apply to any of the SNTP and NTP clients (and most software) packaged with Arch.

This brings us to the problem with the current configuration in Arch. Having the 0 domain first means that for IPv4 only connections everything is fine. In the IPv4 and IPv6 situation the 0 domain will still work, but it will be over IPv4 and it is the IETF standard to prefer IPv6 over IPv4. In the IPv6 only situation the 0 domain will fail followed by the 1 domain failing and the 2 domain succeeding.

By putting the 2 domain first it works well in every situation. Having 0 first is bad for everything but IPv4 only.

Thanks for having the patience to read through this.
Comment by Dave Reisner (falconindy) - Saturday, 25 August 2018, 23:39 GMT
> In order to solve the problem of supporting both IPv4 and IPv6 there are two DNS records per domain. One A record for IPv4 and one AAAA record for IPv6. This is what the 2 NTP pool domain does. This is also what www.archlinux.org, www.google.com, and everything else does if they support both IPv4 and IPv6.
I understand how DNS works. The pool addresses aren't singular, they're round robin load-balanced DNS and advertise 4 A records and 4 AAAA records. Different clients do different things with the resolver results of each RR type.

> This is called Happy Eyeballs is a well tested and widely deployed IETF standard.
No, not quite. Happy Eyeballs describes a specific scheme intended to minimize latency. As such, ipv4 and ipv6 connection attempts are made concurrently, with a small delay between the ipv6 and ipv4 connections. systemd-timesyncd doesn't do this, it just iterates over the resolver results, using the system resolver config (/etc/gai.conf) to sort the results. It's behavior is *serial*, not anything resembling the parallel requirements laid out in RFC 6555.

I was hoping you'd describe a case where this actually fails for IPv6-only hosts, not where some matter of milliseconds are spent. I'd very strongly like to see this fixed in the pool (such that they provide ipv6 on all endpoints, as per the IETF preference), rather than fixing every single downstream client.
Comment by Mortan (Mortan1961) - Sunday, 26 August 2018, 00:24 GMT
>The pool addresses aren't singular, they're round robin load-balanced DNS and advertise 4 A records and 4 AAAA records. Different clients do different things with the resolver results of each RR type.
I am well aware of that. I was just trying to explain A and AAAA records without over complicating it, sorry.

>I'd very strongly like to see this fixed in the pool (such that they provide ipv6 on all endpoints, as per the IETF preference), rather than fixing every single downstream client.
So would I. But until/if they do, the current configuration prefers IPv4 and it is simple fix. I will start a dialog with the NTP Pool Project on enabling IPv6 but it is probably going to be more involved and take some time.

Thanks again for your time.

Loading...