[ntp:questions] multicast - TTL
David L. Mills
mills at udel.edu
Sat Feb 24 00:55:17 UTC 2007
The TTL support in ntpd was specifically designed for an expanding-ring
search. It has nothing to do with the specifications NTPv3 or NTPv4.
With current Unix semantics, it is operative only in multicast/manycast
modes. I haven't verified recently, but for a long time it didn't work
in IPv4 broadcast.
There is no intent to bring into discussion the time-to-live/hop-count
issue, but if you read RFC 760 carefully:
"Time to Live: 8 bits
This field indicates the maximum time the datagram is allowed to
remain the internet system. If this field contains the value zero,
then the datagram should be destroyed. This field is modified in
internet header processing. The time is measured in units of
seconds. The intention is to cause undeliverable datagrams to be
It was the habit at that time, including the gateway code I wrote, to
decrement the ttl for each 30-second interval the packet was held on a
queue. Once upon a time the Internet was like that.
As I said, it is a simple matter to seed the ttl table with whatever
values seem useful. It does not seem like a good idea to change the
rules between unicast, multicast and manycast.
Danny Mayer wrote:
> David L. Mills wrote:
>>The descrete values used for the TTL is consistent with the
>>administrative scoping rules spelled out in the RFC cited in the
> Dave, this is a case where the rules are totally wrong. TTL here is a
> HOP count and not a time-to-live, in spite of the label. In IPv6 it's
> really called a hop count rather than ttl but we should not propogate
> this error. I can't find anything either in the NTPv4 Draft RFC or RFC
> 1305 so I don't know what RFC you mean. Can you clarify? Multicast
> doesn't work the way that it was originally designed. It also make no
> sense to specify a value other than what you want the ttl be set to.
> questions mailing list
> questions at lists.ntp.isc.org
More information about the questions