Use of TTL values by 'ntpd'

ntpd uses a table with up to 8 TTL values, called sys_ttl.

The ttl values that can be specified as option for certain operating modes (broadcast …, manycastclient …, etc.) are intended as index numbers to the sys_ttl table.

According to the bitkeeper repository of the NTP project, this has been introduced by a patch that was applied on 2001-12-31, so this should be in the release versions since ntp-4.1.1.

Anyway, as of ntp-4.2.8p15, the HTML documentation partly differs from the implementation, and the implementation behaves in a somewhat unexpected way.

The default entries of the sys_ttl table are values with a multiple of 32, i.e.:

0, 32, 64, 96, 128, 160, 192, 224

The HTML doc at the bottom of miscopt.html says:

It's not clear what the 31 at the end of the sentence means. Obviously, the first table entry is 0.

Anyway, a line with the ttl keyword at the beginning can be added to the config file to override the default values. For example, a line

ttl 3 5 7 9

in the configuration file results in a table with only 4 entries, i.e.:

3 5 7 9

The HTML page confopt.html explains the options that can be used to specifiy the TTL value to be used for specific modes of operation. So this option can be appended to other configuration lines like broadcast …, manycastclient …, etc.

This documentation is wrong in several ways.

In fact, the ttl value specified as an option to other commands is an index to the 'sys_ttl' table mentioned above. If the specified value exceeds the maximum suitable index (e.g. 7 for a table with 8 entries), the index number is clamped to the maximum value (e.g. 7 in this example).

The documentation distinguishes between different types of IP addresses with specific characteristics:

• Type s: remote server or peer
• Type b: the IPv4 broadcast address of a local interface
• Type m: a multicast address (IPv4 class D or IPv6)
• Type r: a reference clock address (127.127.x.x)

So the sentence “This option is invalid with type r addresses.” implies that the option can be used with all modes where a specific IP address needs to be specified, except with the pseudo-IP addresses used for refclocks (type r).

Also, the HTML page discover.html says:

However, in fact these docs aren't quite correct.

According to some tests, all of the following types of UDP packets always use a TTL value of 64 (not even the 127 mentioned in the docs quoted above):

• Client requests sent to remote servers (type s)
• Server responses sent in reply to client requests (type s ?)
• Broadcasts to an IPv4 broadcast address (type b)

Also, the ttl option has no effect on broadcast packets to IPv4 broadcast addresses.

The only modes of operation that make use of the sys_ttl table are:

• Broadcasts to a multicast address (type m), as multicast server
• Broadcasts to a multicast address (type m), as manycast client

According to some tests, client requests sent to remote servers as well as server responses sent in reply to client requests are always sent with TTL 64.

Even though it seem legitimate to specify a ttl option with a server command, e.g.

server a.b.c.d ttl 4

the ttl option doesn't seem to have any effect, neither as direct value, nor as index to the sys_ttl table.

There doesn't seem to be a way to change the TTL that is used.

Unlike mentioned in the docs quoted above, some tests revealed that broadcast packets sent as server to an IPv4 broadcast address are always sent with TTL 64, not even with TTL 127.

So the ttl option doesn't seem to have any effect, neither as direct value, nor as index to the sys_ttl table. This is similar to the behavior of the normal unicast packets, and there doesn't seem to be a way to change the TTL that is used.

Please note that broadcast packets to a multicast address are handled differently.

In multicast server mode, the contents of the sys_ttl table is taken into account.

If a ttl option is specified in the configuration, as in

broadcast 244.0.1.1 ttl 4

the value 4 in this example is used as index to the sys_ttl table, so with the default TTL table, the effectice TTL value is 128.

If no ttl option is specified above, the default ttl option (index) seems to be 0, and if the first value in sys_ttl (with index 0) is 0, as by default, the effective TTL value in the transmitted packets is incremented to 1.

Multicast packets sent in 'manycastclient' mode as well as broadcast packets to IPv4 broadcast addresses are handled in different ways.

Unlike broadcast and normal multicast packets which are sent by NTP servers, manycast packets are multicast packets sent by NTP clients to discover NTP servers in the network neighborhood.

The HTML page discover.html says:

Also, RFC-5905 chapter 3.1., 'Dynamic Server Discovery' says:

But in fact, ntpd starts with index 1, and the index number is incremented if subsequent packets are being sent. The index is incremented until the maximum index (sys_ttlmax) for the sys_ttl table is reached, and due to the start with index 1 instead of 0, the first entry of the sys_ttl table is completely ignored.

So with the default 'sys_ttl' table the TTL values in subsequent multicast packets sent by a manycast client after start are:

32, 64, 96, 128, 160, 192, 224, 224, 224, …

This looks pretty inappropriate for a discovery scheme for the local network neighborhood.

Things are even worse if you specify a ttl option for the manycastclient command, e.g.

manycastclient 224.0.1.1 ttl 4

In this case, the TTL values in subsequent multicast packets sent by a manycast client after start are

128, 160, 192, 224, 224, 224, …

This doesn't sound like the intended behavior for the manycast server discovery scheme.

— Martin Burnicki martin.burnicki@meinberg.de, last updated 2021-08-12