Danny,
I've said very many times the reference ID is solely and exclusively
intended to detect timing loops. A server can itself be synchronized to
only one source and that source is revealed in the reference ID. There
is no need nor no intent to interpret that field for any other purpose.
The same reference ID goes out to all clients, regardless of the number
of interfaces. A client of this server doesn't know whether this is an
IPv4 or IPv6 address. The well-spoken client can check whether the field
coincides with (any of) its IPv4 addresses or hashes to (any of) its
IPv6 addresses, birthdays notwithstanding. There is no need to change
any aspect of the reference ID as specified in rfc2030 and now implemented.
Dave
Danny Mayer wrote:
David L. Mills wrote:
Guys,
I'm answering Danny's message only because it is short. Bear in mind:
1. The protocol design originated over 25 years ago. There are estimates
of over 25 million clients on the planet now. Changing the IPv4 refid
compatibility is simply not in the cards. Certainly it is possible to
accidently configure two associations with the same server and I have
done that for test. It may be duplicative, but it is not fatal and does
not impair good timekeeping.
Dave, the reason to change the way it currently is defined is that you
frequently have multiple IP addresses and this is even more true with
IPv6 in addition to IPv4 becoming the norm. Choosing any 32-bit number
will do the same job including the first non-loopback IP address as long
as the same ID goes out on all interfaces. There is nothing sacred about
the refid as long as we just treat it as a 32-bit number. Such a number
will interoperate with all previous versions of NTP since it cannot
distinguish an IPv4 address from a hole-in-the-wall otherwise the MD5
hash of IPv6 addresses would never have worked. By making it unique
across all interfaces and addresses that a system services you have
better opportunities to ensure that you are preventing loops. It's the
only real use that I'm aware of.
Danny
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
